Spark数据帧写入拼花地板表-更新分区统计信息时速度较慢
当我在所有任务成功后将数据帧中的数据写入拼花地板表（已分区）时，该过程在更新分区统计信息时陷入了困境。
16/10/05 03:46:13 WARN log: Updating partition stats fast for:
16/10/05 03:46:14 WARN log: Updated size to 143452576
16/10/05 03:48:30 WARN log: Updating partition stats fast for:
16/10/05 03:48:31 WARN log: Updated size to 147382813
16/10/05 03:51:02 WARN log: Updating partition stats fast for:
df.write.format("parquet").mode("overwrite").partitionBy(part1).insertInto(db.tbl)
我的桌子有
共有1个答案
我觉得这里的问题是有太多的分区
尝试减少分区的数量（使用另一个分区列，或者如果是日期列，请考虑按月份分区），您应该能够看到性能的显着变化。
-
Spark版本：2.3 hadoop dist:azure Hdinsight 2.6.5平台：azure存储：BLOB 集群中的节点：6个执行器实例：每个执行器6个内核：每个执行器3个内存：8gb 试图通过同一存储帐户上的spark数据框将azure blob（wasb）中的csv文件（大小4.5g-280列，2.8 mil行）加载到拼花格式。我重新划分了大小不同的文件，即20、40、60、10
-
我正在使用Spark 1.6.0。以及用于读取分区拼花数据的DataFrame API。 我想知道将使用多少个分区。 以下是我的一些数据： 2182个文件 Spark似乎使用了2182个分区，因为当我执行计数时，作业被拆分为2182个任务。 这似乎得到了的证实 对吗？在所有情况下？ 如果是，数据量是否过高（即我是否应该使用df重新分区来减少数据量）？
-
我试图利用火花分区。我试图做这样的事情 这里的问题每个分区都会创建大量的镶木地板文件，如果我尝试从根目录读取，则会导致读取缓慢。 为了避免这种情况，我试过 但是，这将创建每个分区中镶木地板文件的数目。现在我的分区大小不同了。因此，理想情况下，我希望每个分区都有单独的合并。然而，这看起来并不容易。我需要访问所有分区合并到一定数量并存储在单独的位置。 我应该如何使用分区来避免写入后出现许多文件？
-
我试图做一些非常简单的事情，我有一些非常愚蠢的挣扎。我想这一定与对火花的基本误解有关。我非常感谢任何帮助或解释。 我有一张非常大的桌子（~3 TB，~300毫米行，25k个分区），在s3中保存为拼花地板，我想给一些人一个很小的拼花文件样本。不幸的是，这要花很长时间才能完成，我不明白为什么。我尝试了以下方法： 然后当这不起作用时，我尝试了这个，我认为应该是一样的，但我不确定。（我添加了，以尝试调试。
-
我很难找到这个问题的答案。假设我为拼花地板编写了一个数据框，并且我使用与相结合来获得一个分区良好的拼花地板文件。请参阅下面： 现在，稍后我想读取拼花文件，所以我这样做: 数据帧是否由分区？换句话说，如果拼花地板文件被分区，火花在将其读入火花数据帧时是否会维护该分区。还是随机分区？ 同样，这个答案的“为什么”和“为什么不”也会有所帮助。
-
我有一个很大的数据框，我正在HDFS中写入拼花文件。从日志中获取以下异常： 谷歌对此进行了搜索，但找不到任何具体的解决方案。将推测设置为false:conf.Set（“spark.投机”，“false”） 但仍然没有帮助。它只完成了几个任务，生成了几个零件文件，然后突然因此错误而停止。 详细信息：Spark版本：2.3.1（这在1.6x中没有发生） 只有一个会话正在运行，这排除了不同会话访问同一位