Spark 性能问题与 Hive答案

【问题标题】：Spark Performance Issue vs HiveSpark 性能问题与 Hive
【发布时间】：2019-07-05 10:13:56
【问题描述】：

我正在开发一个每天都会运行的管道。它包括连接 2 个表，例如 x 和 y（分别约为 18 MB 和 1.5 GB 大小）并将连接的输出加载到最终表。

以下是关于环境的事实，

对于表 x：

对于表 y：

现在的问题是：

Hive 和 Spark 的性能相同（所用时间相同）

我为 spark 作业尝试了不同的资源组合。

例如：

所有三种组合都提供相同的性能。我不确定我在这里缺少什么。

我也尝试广播小表'x'以避免加入时随机播放，但性能没有太大提升。

一个关键的观察是：

70% 的执行时间用于读取大表 'y'，我猜这是因为每个分区的文件数量更多。

我不确定 hive 如何提供相同的性能。

请推荐。

【问题讨论】：

1.5GB 的 3200 次拆分有点多，我认为。如果您合并拆分或重新分区，可能会有所帮助。
真的！我明白这一点，但问题是我们只有一份数据副本，我们怀疑对它做任何事情。另外，重新分区会再次引起洗牌，对吗？我已经试过了。
我曾经遇到过同样的问题——主要是因为拆分的数量。一些有用的属性hive.vectorized.execution.enabled=true、hive.auto.convert.join = true、hive.merge.sparkfiles=true。
我也觉得这是由于拆分的数量，我们想使用火花。蜂巢配置在这里有帮助吗？
您在 Hive 中使用哪个执行引擎？

【解决方案1】：

我假设您正在比较 MR 上的 Hive 与 Spark。如果不是这样，请告诉我。因为 Hive(on tez 或 spark) vs Spark Sql 不会有什么不同在性能方面非常重要。

我认为主要问题是小文件太多。大量的 CPU 和时间消耗在 I/O 本身，因此您无法体验 Spark 的处理能力。

我的建议是在阅读 parquet 文件后立即合并 spark 数据帧。请将“x”数据帧合并为单个分区和“y” 数据帧分成 6-7 个分区。

完成上述操作后，请执行join(broadcastHashJoin)。

【讨论】：

我不确定在提供建议时是否有必要。
我认为这也是文件的数量，但是如果我们再次进行合并，将会引发随机播放，对吗？如果我没记错的话，它会进一步增加执行时间。
合并不会导致洗牌，重新分区会。
据我了解，合并和重新分区都会导致洗牌，但合并更快，因为它不会洗牌整个数据。它将数据从其他节点传输到选定节点，其中重新分区会在选定节点之间打乱整个数据。我还是会试一试，让你知道！
另外，如果我合并小表 'x' 并广播它，它将如何提高性能，因为广播 x 将使其在所有工作节点上作为单个副本可用（驱动程序收集所有数据并广播）。为什么要合并？