数据仓库自动化工具：好处还是坏处？

Question

今天，在研究 ETL 和Kettle 之类的数据仓库解决方案时，我遇到了一个新概念（对我而言），称为数据仓库自动化工具。

我还查看了此处的白皮书，这表明该领域的供应商很少。

我对这些工具的一个反应是：哇，任何购买这些工具的人都在进行巨大的投资。同时，似乎许多数据仓库项目都失败了，即使它们需要开发人员花费大量时间来实施。

所以，如果有人在那里确实有在真实世界中的项目数据仓库的自动化工具的经验，你能回答这些问题吗？

1. DWA 工具是否极大地减少了启动和运行数据仓库的时间，或者是否占用了原本应该获得的时间来学习该工具所花费的时间？
2. 如果 DWA 工具导致您的数据仓库项目失败，原因是什么？
3. 如果你过去做过数据仓库没有使用 DWA 工具，而你最近也使用过 DWA 工具，你会在下一个数据仓库项目中再次使用 DWA 工具吗？
4. 你什么时候会认为 DWA 工具是矫枉过正的？
5. 您最喜欢使用 DWA 工具的哪一点？你最不喜欢什么？

Answer 1

我会从用户的角度权衡。
我在 SQL Server 后端使用其中一种自动化工具进行了广泛的工作（15 个左右的项目），结果喜忧参半。

1. DWA 工具是否极大地减少了启动和运行数据仓库的时间，或者是否占用了原本应该获得的时间来学习该工具所花费的时间？

答案是一个很大的“视情况而定”。我发现它在很大程度上取决于您正在构建的数据仓库的复杂性，以及您使用本机工具的技能。
我们可以很方便地使用工具，使客户能够设计自己的数据仓库和OLAP很少的培训和基础技术的知识解决方案所提供的要求很简单。
对于使用原生底层工具的经验丰富的数据仓库和 OLAP 开发人员来说，收益要小得多，而且我还没有看到支持 SSIS 和 SSAS 的每一个功能的自动化工具。大多数都提供挂钩，您可以在其中插入 SQL 或 XMLA 脚本，但是随着项目复杂性的增加，您最终编写的脚本比使用自动化工具的次数要多。
此外，由于数据仓库自动化工具支持底层技术的多个版本，我看到 SQL 中的新功能出现较晚或根本没有出现在自动化工具中。

2. 如果 DWA 工具导致您的数据仓库项目失败，原因是什么？

在大型复杂项目中：自动化工具的性能和缺乏灵活性。如果您手动完成所有操作，您可以按照您喜欢的方式完美地配置并行处理，您可以在查询中使用技巧使它们更快，您可以考虑哪些操作符在 SSIS 中阻塞，您的数据流的沿袭是什么等等。

3. 如果你过去做过数据仓库没有使用 DWA 工具，而你最近也使用过 DWA 工具，你会在下一个数据仓库项目中再次使用 DWA 工具吗？

同样的“视情况而定”在这里也适用。这取决于项目。如果我期望有很多数据或很多复杂性，不，我不会，但我可能会考虑BIML生成 SSIS 包以避免重复任务。
如果它是一个简单的项目，一个小的源系统，或者我需要让客户的关键用户在项目上工作并在我离开后接管支持，也许是的。

4. 你什么时候会认为 DWA 工具是矫枉过正的？

当价格明显超过收益时，就会矫枉过正。如果它适合项目，特别是如果经验不足的用户或高级用户可以接管项目而不是支付顾问费，那么成本不一定高得令人望而却步。

5. 您最喜欢使用 DWA 工具的哪一点？你最不喜欢什么？

我最喜欢的也是有时不喜欢它的原因。在你的地方做出的僵化和决定确保项目是“干净的”并遵循一定的方法。特别是与多个开发人员一起工作，每个人都被迫以某种方式工作，这可能是一个好处，您只需打开一个项目并知道会发现什么。
如果您遇到工具未预见到的问题，您被迫以某种方式工作的事实可能会很麻烦。

我想提出的其他一些观点

1. 对底层技术的支持更好。如果你对如何在 SSIS 或 SSAS 中做某事有疑问，你可以谷歌或在这里提问。由于 DWA 工具抽象了该层，因此您需要求助于供应商支持（可能不是免费的）

2. 每个软件都有缺陷。SQL Server 的错误在网上得到了更好的记录。我记得有一种情况，在与我们的供应商的支持人员进行了长时间的讨论后，我最终反编译了 DWA 工具，以弄清楚他们的代码中发生了什么以及为什么它的行为方式如此。

3. 每个 DWA 工具都缺乏 SQL Server 所具有的灵活性和社区，迟早您可能会遇到该工具必然具有的局限性。以版本控制为例。DWA 工具可能会推出自己的工具，这可能或多或少地起作用，但是如果您有一个简单的 Visual Studio 项目，您可以将其添加到 TFS 中其余代码所在的位置，使用 BIDShelper 获取可读差异等。如果您需要SSAS 中的存储过程，您也可能不走运。

Answer 2

埃克森的名单研究得很少。在我们的网站上有一个更全面的数据仓库自动化工具目录，网址为http://ajilius.com/competitors。

我将从供应商的角度回答您的问题。

1. 我们的客户报告显着节省了项目时间。大多数 DWA 产品是由数据仓库人员编写的，他们首先想节省自己的时间，然后将他们的产品商业化。与任何 ETL 工具相比，我想不出任何 DWA 工具实际上需要更长的时间来构建给定场景。

2. 我们在运营的第一年就有两次失败。一位客户试图将我们的产品用于一种非设计的方法论，我们现在在销售对话中强调该方法论 (Kimball)。另一个是我们产品的缺点，（当时）我们没有正确处理桥接表。两位客户都获得了全额退款，我们现在将 30 天的完整产品试用作为付款前的销售功能。

3. 我曾经为一家全球数据库供应商销售数据仓库工作负载，包括供应商的 ETL 工具。我还在许多仓库项目中使用了独立的 ETL 工具。我永远不会回到使用 ETL 而不是 DWA 工具，即使我们自己的产品不存在并且我被迫使用竞争对手的工具。

4. 绝不。嗯……如果您正在构建数据仓库，我希望该工具能够端到端地使用。我们有几个用例，其中该工具仅用于提取和加载，但客户编写了自己的转换代码。这可能有点矫枉过正，但我​​们的价格点（见下文）是成本合理的。

5. 我最喜欢的功能是能够向客户展示他们的要求，然后在他们改变主意时迅速改变解决方案；并在任何时间点生成完整的文档。

你提到了巨大的投资。这仅适用于市场上的传统产品。我们的产品 (Ajilius) 拥有每年 5,000 美元的站点许可，拥有无限的用户、无限的服务器和无限的数据库。其他产品如 Leapfrog 和可能的 Dimodelo（最近价格有所变化）也是低成本的好产品。像 Quipu 这样的产品有免费版本，Optimal ODE（正在开发）也是如此，我认为 Varigence BIML 也可能有免费增值模式。

我希望这看起来不像广告，但它是来自使用过许多数据仓库自动化产品的人的经验的诚实回答。