自定义映射器和Reducer与HiveQL

Question

问题陈述： -

我需要比较两个表Table1和Table2，它们都存储相同的内容。因此，我需要将Table2与Table1进行比较，因为Table1是需要进行比较的主要表格。所以在比较之后我需要做一个Table2有某种差异的报告。这两个表有很多数据，围绕TB数据。所以目前我写了HiveQL来进行比较并获取数据。

所以我的问题是PERFORMANCE更好，写CUSTOM MAPPER and REDUCER来做这种工作，或者我写的HiveQL会很好，因为我将加入数百万条记录中的这两个表。据我所知HiveQL内部（幕后）生成优化的自定义map-reducer并提交执行并返回结果。

Answer 1

你的问题的答案是双重的。

首先，如果您可以在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程序。