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