我已经围绕ETL进行了大量的开发工作，并且我得出的结论是，ETL的最佳方法是声明性方法（支持自定义命令块/函数）。特别是，声明性方法允许转换的可视化，这可以使与业务/领域专家讨论转换更容易。同样不容忽视的是，声明性方法通常更紧凑，更易于维护。
不幸的是，我见过的唯一一半体面的声明性转换语言/框架是XSLT。而XSLT可能因其他许多无关的原因而变得非常糟糕。 （特别是，它的冗长程度会让任何中等规模的转型项目变得痛苦。）
XSLT真的是声明转换中唯一或最好的游戏吗？
我今天做了一些研究，而且我发现的唯一替代方案似乎主要是放弃软件：
非常感谢任何选项或共享智慧的指示！
答案 0 :(得分：2)
ATL绝对没有死，你可以看到最新的信息here。但他们目前致力于提高执行引擎的性能。 ATL主要是受QVTr启发的声明语言。
QVTr并非完全死亡，Eclipse QVTd project正在积极致力于提供QVTr执行引擎。我不确定他们最终是否会支持可视语法的编辑器。如果他们这样做，我认为计划是支持UMLX。
正如您所指出的，ETL是混合的，但这并不意味着您必须编写混合ETL脚本。纯粹的声明性脚本将起作用，ETL引擎将能够执行它。恕我直言，ATL和ETL都不仅仅是体面的声明性转换语言。
关于可视化语法，我建议你可以使用自己的符号，并让编辑器使用Sirius来支持它。从那里你可以使用模型转换生成等效的ETL / ATL代码，然后运行:)（模型到模型创建AST或模型到代码生成脚本）。定义自己的可视化语法的好处是，您可以定制它以适合您的受众，确保它可以帮助您与他们讨论转换。
答案 1 :(得分：0)
我也发现声明性方法非常有效（正如我在文章here中所解释的那样）。我之所以说这是因为我在过去10年里一直在维护基于代码的声明性ETL，首先使用现在未维护的activewarehouse-etl，并且从2015年开始使用我编写并开源的Kiba ETL。
我很确定其他基于声明代码的基于ETL的ETL也存在！