在Hive中加入是不是很糟糕？

Question

您好我最近加入了一项使用Hive和PostgreSQL的新工作。现有的ETL脚本从日期分区的Hive收集数据，并在PostgreSQL中为这些数据创建表，然后PostgreSQL脚本/查询执行左连接并创建最终表以用于报告目的。我过去听说Hive加入并不是一个好主意。但是，我注意到Hive确实允许加入，所以我不确定为什么这是一个坏主意。

我想使用Talend或Mulesoft之类的东西来创建连接并在配置单元中进行聚合并创建临时表并将该临时表作为最终表传输到PostgreSQL进行报告。

任何建议，特别是如果这不是HIVE的良好做法。我是hive的新手。

感谢。

Answer 1

加入配置单元的主要问题与数据位置有关。

Hive查询作为MapReduce作业执行，并且几个映射器将尽可能地在数据所在的节点中启动。

但是，在连接表时，来自LHS和RHS表的两行数据通常不在同一节点中，这可能会导致节点之间的大量网络流量。

加入Hive本身并不错，但如果加入的两个表很大，可能会导致作业变慢。

如果其中一个表明显小于另一个表，您可能希望将其存储在HDFS缓存中，使其数据在每个节点中可用，这允许连接算法在本地检索所有数据。

因此，在Hive中运行大型连接没有任何问题，您只需要知道他们需要时间来完成。

Answer 2

Hive成熟度增长

反对使用连接的参数可能不再适用于最新版本的配置单元。

我在manual section on join optimization中找到的最明显的例子：

  

Hive 0.11之前的MAPJOIN实现具有以下限制：

     

mapjoin运算符一次只能处理一个键

因此，我建议询问他们不情愿的基础，然后仔细检查是否仍然适用。他们的论点可能仍然有效，或者可能已经解决。

旁注： 我个人认为Pig代码比hive更容易重用和维护，考虑使用Pig而不是hive对你的（hive表）数据进行map-reduce操作。

Answer 3

完全可以在HIVE中加入，我是ETL测试人员，并且在Hive的大表上执行左连接，大多数情况下查询运行顺利但有时候工作因网络流量而卡住或缓慢

还取决于群集的节点数。

由于