hadoop - 有没有人发现 Cascading for Hadoop Map Reduce 有用？

Question

我一直在尝试 Cascading，但我看不出在编写作业时比经典的 map reduce 方法有任何优势。

Map Reduce 工作给了我更多的自由，而 Cascading 似乎设置了很多障碍。

可能会使简单的事情变得简单，但复杂的事情..我发现它们非常难

有什么我想念的吗？与经典方法相比，级联是否有明显的优势？

在什么情况下我应该选择级联而不是经典方法？有人使用它并且开心吗？

Answer 1

记住我是 Cascading 的作者......

如果 Pig 或 Hive 对您的问题有意义，我的建议是使用它们，尤其是 Pig。

但是，如果您从事数据业务，而不仅仅是浏览数据以获取见解，您会发现对于大多数问题而言，级联方法比原始 MapReduce 方法更有意义。

原始 MapReduce 的第一个障碍是在 MapReduce 中思考。琐碎的问题在 MapReduce 中很简单，但如果您可以使用更容易映射到您的问题域的模型(过滤这个、解析那个、排序那些、加入其余部分等)，那么开发复杂的应用程序就会容易得多。

接下来您将意识到 Hadoop 中的一个正常工作单元由多个 MapReduce 作业组成。将作业链接在一起是一个可以解决的问题，但它不应该泄漏到您的应用程序域级代码中，它应该是隐藏和透明的。

此外，如果您必须不断地在映射器和缩减器之间移动函数，您会发现重构和创建可重用代码会更加困难。或者从映射器到之前的 reducer 以获得优化。这导致了脆性问题。

级联相信尽可能快地失败。规划器试图在 Hadoop 集群开始工作之前解决并满足所有这些字段名称之间的依赖关系。这意味着 90% 以上的问题将在您的作业在执行过程中等待发现问题的等待时间之前被发现。

您可以通过创建域对象(如 Person 或 Document)在原始 MapReduce 代码中缓解这种情况，但许多应用程序并不需要下游的所有字段。考虑一下您是否需要所有男性的平均年龄。当您只需要二进制性别和数字年龄时，您不想支付在网络中传递整个 Person 的 IO 惩罚。

借助 fail fast 语义和接收器和源的惰性绑定(bind)，在 Cascading 上构建框架变得非常容易，这些框架本身创建 Cascading 流(成为许多 Hadoop MapReduce 作业)。我目前参与的一个项目每次运行都会有 100 个 MapReduce 作业，其中许多是根据正在处理的数据的反馈在运行中途创建的。搜索 Cascalog查看用于简单创建复杂流程的基于 Clojure 的框架示例。或者 Bixo用于比 Nutch 更容易定制的 Web 挖掘工具包和框架。

最后，Hadoop 永远不会单独使用，这意味着您的数据总是从某个外部来源提取并在处理后推送到另一个来源。关于 Hadoop 的肮脏 secret 是它是一个非常有效的 ETL 框架(所以听到 ETL 供应商谈论使用他们的工具将数据插入/拉出 Hadoop 是愚蠢的)。级联允许您编写独立于集成端点的操作、应用程序和单元测试，从而在一定程度上减轻了这种痛苦。级联在生产中用于加载 Membase、Memcached、Aster Data、Elastic Search、HBase、Hypertable、Cassandra 等系统(不幸的是，并非所有适配器都由其作者发布。)

如果愿意，请将您在使用该界面时遇到的问题列表发送给我。我一直在寻找更好的方法来改进 API 和文档，用户社区随时提供帮助。