问题陈述:-
我需要比较两个表 Table1 和 Table2，它们都存储相同的内容。所以我需要将 Table2 与 Table1 进行比较，因为 Table1 是需要进行比较的主表。因此，在比较之后，我需要报告 Table2 存在某种差异。这两个表有很多数据，大约 TB 的数据。所以目前我已经编写了 HiveQL 来进行比较并取回数据。
所以我的问题是，就PERFORMANCE 而言，编写CUSTOM MAPPER 和REDUCER 来完成此类工作或HiveQL 哪个更好> 我写的会很好，因为我将在数百万条记录上加入这两个表。据我所知，HiveQL 在内部(在幕后)生成优化的自定义 map-reducer 并提交执行并取回结果。
最佳答案
您的问题有两个答案。
首先，如果有一些处理可以用 Hive QL 语法表达，我认为 Hive 的性能与编写自定义 map-reduce 的性能相当。这里唯一的问题是当您有一些关于您在 map-reduce 代码中使用但不通过 Hive 使用的数据的额外信息时。例如，如果您的数据已排序，您可以在映射器中处理文件拆分时使用此信息，而除非 Hive 知道此排序顺序，否则它将无法将此信息用于其优势。通常，有一种方法可以指定此类额外信息(通过元数据或配置属性)，但有时甚至可能没有一种方法可以指定此信息以供 Hive 使用。
其次，有时处理过程可能非常复杂，以至于无法在类似 SQL 的语句中轻松表达。这些情况通常涉及在处理过程中必须存储间歇状态。 Hive UDAFs一定程度上缓解这个问题。但是，如果您需要更多自定义内容，我总是更喜欢使用 Hive Transform functionality 插入自定义映射器和/或缩减器。 .它允许您在 Hive 查询的上下文中利用 map-reduce，允许您将类似 Hive SQL 的功能与自定义 map-reduce 脚本混合搭配，所有这些都在同一个查询中。
长话短说:如果您的处理可以通过 Hive QL 查询轻松表达，我认为没有太多理由编写 map-reduce 代码来实现相同的目的。创建 Hive 的主要原因之一是允许像我们这样的人编写类似 SQL 的查询，而不是编写 map-reduce。如果我们最终编写 map-reduce 而不是典型的 Hive 查询(出于性能原因或其他原因)，有人可能会争辩说 Hive 在其主要目标上做得不好。另一方面，如果您有一些 Hive 无法利用的关于您的数据的信息，您最好编写利用该信息的自定义 map-reduce 实现。但是，话又说回来，当您可以像前面提到的那样使用 Hive 转换功能简单地插入映射器和缩减器时，无需编写整个 map-reduce 程序。
关于performance - 自定义映射器和 Reducer 与 HiveQL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11404163/