performance - 如何在 Spark SQL 中加入大数据帧？ (最佳实践、稳定性、性能)

Question

我得到的错误与 Missing an output location for shuffle 相同在 Spark SQL 中加入大数据帧时。那里的建议是设置 MEMORY_AND_DISK 和/或 spark.shuffle.memoryFraction 0 .但是，spark.shuffle.memoryFraction 在 Spark >= 1.6.0 中被弃用，如果我没有缓存任何 RDD 或 Dataframe，设置 MEMORY_AND_DISK 应该没有帮助，对吧？此外，我收到了许多其他 WARN 日志和任务重试，这让我认为工作不稳定。

因此，我的问题是:

在 Spark SQL >= 1.6.0 中加入巨大数据帧的最佳实践是什么？

更具体的问题是:

如何调音执行人数量和 spark.sql.shuffle.partitions 以获得更好的稳定性/性能？

如何在 之间找到适当的平衡并行级别 (执行程序/核心数量)和 分区数 ?我发现增加执行程序的数量并不总是解决方案，因为它可能会产生 I/O 读取超时 由于网络流量异常。

是否有任何其他相关参数要为此目的进行调整？

我的理解是加入数据存储为 兽人或 Parquet 为连接操作提供比 text 或 Avro 更好的性能。 Parquet 和 ORC 之间有显着区别吗？

有没有优势SQLContext 对比 HiveContext 关于连接操作的稳定性/性能？

当连接中涉及的数据帧以前是 时，性能/稳定性是否存在差异？ registerTempTable() 或 saveAsTable() ?

到目前为止，我正在使用 this is answer和 this chapter作为起点。还有一些与此主题相关的 stackoverflow 页面。然而，我还没有找到这个流行问题的全面答案。

提前致谢。

Answer 1

这是很多问题。请允许我一一回答:

在生产环境中，执行者的数量大部分时间都是可变的。这取决于可用资源。执行 shuffle 时，分区数很重要。假设您的数据现在有偏差，您可以通过增加分区数来降低每个任务的负载。
理想情况下，任务应该减去几个。如果任务花费的时间太长，您的容器可能会被抢占而工作丢失。如果任务只需要几毫秒，启动任务的开销就占主导地位。

关于并行度和调整执行器大小，我想引用 Cloudera 的优秀指南:https://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-2/

ORC 和 Parquet 只对静态数据进行编码。在进行实际连接时，数据采用 Spark 的内存格式。自从 Netflix 和 Facebook 采用并投入大量精力以来，Parquet 越来越受欢迎。 Parquet 允许您更有效地存储数据，并具有 Spark 使用的一些优化(谓词下推)。

您应该使用 SQLContext 而不是 HiveContext，因为 HiveContext 已被弃用。 SQLContext 更通用，不仅适用于 Hive。

执行 registerTempTable 时，数据存储在 SparkSession 中。这不会影响连接的执行。它存储的只是在执行操作时调用的执行计划(例如 saveAsTable )。执行 saveAsTable 时数据存储在分布式文件系统上。

希望这可以帮助。我还建议观看我们在 Spark 峰会上关于加入的演讲:https://www.youtube.com/watch?v=6zg7NTw-kTQ .这可能会为您提供一些见解。

干杯，福科