R vs Pentaho Spoon 作为 ETL 工具

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




9年前关闭。




背景(抱歉，太长了):

我的任务是维护一个 ETL，它收集各种在线广告数据，每天大约 20-30 MB，并将其附加到 MySQL 中的表中。外部承包商用 Pentaho Spoon(厨房、水壶？) build 了 ETL。 ETL 由大约 250 个作业和转换 (.ktr,.kjb) 组成，每个都有大约 5 到 25 个步骤。在这个大过程中出现问题是很常见的。我发现编写 R 脚本来进行转换和加载效率更高。事实上，我认为除了使用 RMySQL(即 plyr!)调用之外，ETL 可以减少到 1000 行以下的代码。也许 Python 将用于从网络中提取数据。

我对 R 的使用导致了一些阻力。设计 ETL 的计算机程序员不懂 R，所以如果我离开，就不能叫，而且大量时间都投入在 Spoon ETL 上。此外，与 R 脚本相比，外行可以更轻松地在 Spoon 中直观地遵循这些步骤。就我而言，我认为我们被 ETL 所困。但是，由于我没有计算机科学背景，因此我对此事没有太大的发言权。

如果您对以下内容有任何见解，请发表评论。请知道我已经研究了几个月并阅读了很多意见，但没有像 SO 通常提供的那样简洁或可靠:

公司的一些人称 R 的可扩展性不高。我认为相反的主要原因是日志记录功能。 Spoon 的纯日志输出有限，而所有 R 脚本都可以放入每日日志中。修复和避免 .ktrs 中的错误非常乏味，但通过设置标志和/或搜索 R 日志很容易。对此有什么想法吗？

这就引出了一个大问题。像 Pentaho 这样的 ETL 有什么意义？本帖Do I need a ETL? ，让我相信，如果你使用 R 或其他所谓的 OOL，没有理由拥有像 Pentaho 这样的工具。如果是这样，有人可以确认吗？我在这里真的需要第二个意见。如果是这样，谁使用像 Pentaho 这样的工具？只是没有编程背景的人，还是其他人？我确实看到了很多关于 SO 的 Pentaho 问题。

确实有更多的人使用 R 和 Pentaho，对吧？这个http://www.kdnuggets.com/2012/05/top-analytics-data-mining-big-data-software.html让它看起来如此。老实说，我很惊讶 Pentaho 排在第 5 位，这让我倍加怀疑谁在使用 Pentaho，以及我对它在工作环境中的使用的怀疑是否是错误的。

感谢您的任何回复。我并不是要对 Spoon 或 Spoon 用户有任何屈尊俯就；我真的很困惑，需要外界的意见。

Answer 1

R 作为 ETL 工具？那是一个新的，但不管你的船是什么。

不过，我会这么说，如果你能得到 250 个工作和转换到 1000 行以下的 R，我会说你的 ETL 写得不好。

除此之外，您还必须考虑可支持性和可扩展性。我认为使用 Spoon 这样的图形工具而不是 R 代码会容易得多。

我个人认为你被误导了，你问的问题写得不好，但那是一个不同的论点。

关于您的观点，PDI 的日志记录非常好，如果您喜欢合并日志，您可以随意记录任何内容，全部记录到一个大型数据库表中。

ETL 不会消失，即使随着对 HDFS 等非结构化数据存储池的喜爱出现，也要考虑在 R 之外进行的数据分析，如果您想要在数据之上进行报告或 OLAP，无论如何它仍然需要转换。

是真的，更多的人使用 R 和 Pentaho 吗？那是个什么样的问题？通过 Pentaho，我假设您的意思是 PDI？这怎么能比得上？数据分析工具 vs ETL 工具，你想统计用户？嗯？另一方面，如果您的意思是整个 R 与 Pentaho，那么我猜不是。您正在查看有关 R 与 Weka 的报告，并使其符合您的 ETL 论点。这不会在一个月的星期天洗。

==编辑==
好的，你目前有大约 1000 行 R & Python 代码。随着您的老板需求的扩大，随着时间的推移，这会慢慢增长，并且因为您正在努力 catch 最后期限，所以新代码的编写与您当前拥有的代码一样干净或有良好的文档记录。所以随着时间的推移，它会增长到 5000 行，加上一些 python 脚本。然后有一天你被公共(public)汽车撞了，一些新人必须进来管理你的代码......他们从哪里开始，他们如何进行更改？

如果需要，几乎任何具有少量数据经验的人都可以对 PDI ETL 进行更改。哪里需要一些具有足够深入的 R 知识才能对您所做的事情进行更改。

ETL 工具旨在快速且易于使用，它们在与不同系统(例如非数据库或基于文件)的数据连接方面提供的功能远远超过 R 所能提供的，尽管我想这就是人们求助于 python 的原因等等
也就是说，两者都有空间，我见过的社区中有一个用于 PDI 的 R 插件。

最重要的是，多年来我已经看到了足够多的 TSQL 到 ETL 迁移，从经验中知道，即使在代码中维护 ETL 在短期内看起来很实用，但从长远来看，它只会带来更多的痛苦。

另一方面，如果您可以将 250 个 PDI 转换编码到 1000 行 R，那么您的 ETL 可能会因您的前任的糟糕设计而变得臃肿。

如果您希望我对您现有的 PDI ETL 结构发表意见，也可以安排。

汤姆