问题陈述：-
我需要比较两个表Table1，Table2它们都存储相同的东西。所以我需要Table2与需要Table1进行比较Table1的主表进行比较。因此，在比较之后，我需要制作一份Table2存在某种差异的报告。这两张表有很多数据，大约 TB 的数据。所以目前我已经写信HiveQL进行比较并取回数据。
所以我的问题是哪个更好PERFORMANCE，写一个CUSTOM MAPPER and REDUCER来做这种工作，或者HiveQL我写的那个会很好，因为我将在数百万条记录上加入这两个表。据我所知，HiveQL内部（幕后）生成优化的自定义 map-reducer 并提交执行并取回结果。
你的问题的答案是双重的。
首先，如果有一些处理可以用 Hive QL 语法表达，我认为 Hive 的性能与编写自定义 map-reduce 的性能相当。这里唯一的问题是当您有一些关于您在 map-reduce 代码中使用但不是通过 Hive 的数据的额外信息时。例如，如果您的数据已排序，则您可以在映射器中处理文件拆分时使用此信息，而除非 Hive 知道此排序顺序，否则它将无法将这些信息用于其优势。通常，有一种方法可以指定此类额外信息（通过元数据或配置属性），但有时，甚至可能无法指定此信息以供 Hive 使用。
其次，有时处理可能会非常复杂，以至于无法在类似 SQL 的语句中轻松表达。这些情况通常涉及在处理期间必须存储间歇性状态。Hive UDAF在一定程度上缓解了这个问题。但是，如果您需要更自定义的东西，我总是更喜欢使用Hive 转换功能插入自定义映射器和/或减速器。它允许您在 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 程序。