Question

我有一个群集并执行wholeTextFiles，这应该可以提取大约一百万个文本文件，总计大约10GB个我有一个NameNode和两个DataNode，每个RAM 30GB，每个4个核心。数据存储在HDFS。

中

我没有运行任何特殊参数，作业需要5个小时才能读取数据。这是预期的吗？是否有任何参数可以加快读取（火花配置或分区，执行器数量？）

我刚刚开始，我从来没有需要在

之前优化工作

编辑：此外，有人可以准确解释整个文本功能的工作原理吗？（不是如何使用它，而是如何编程）。我对理解分区参数等非常感兴趣。

编辑2：基准评估

所以我尝试在fullTextFile之后重新分区，问题是一样的，因为第一次读取仍然使用预定义数量的分区，因此没有性能改进。加载数据后，集群执行得非常好......在处理数据时（对于200k文件），在整个文本文件中我有以下警告消息：

15/01/19 03:52:48 WARN scheduler.TaskSetManager: Stage 0 contains a task of very large size (15795 KB). The maximum recommended task size is 100 KB.

这会是表现不佳的原因吗？我该如何对冲呢？

此外，在执行saveAsTextFile时，我根据Ambari控制台的速度是19MB / s。当使用wholeTextFiles读取时，我的速度为300kb / s .....

似乎通过增加wholeTextFile(path,partitions)中的分区数量，我的性能会有所提升。但是仍然只有8个任务同时运行（我的CPU数量）。我正在进行基准测试以观察极限......

Answer 1

总结评论中的建议：

HDFS不适合存储许多小文件。首先，NameNode将元数据存储在内存中，因此您可能拥有的文件和块的数量是有限的（典型服务器的最大约为100m块）。接下来，每次读取文件时，首先查询NameNode的块位置，然后连接到存储该文件的DataNode。这种联系和反应的开销非常大。
应始终检查默认设置。默认情况下，Spark在YARN上启动，有2个执行器（--num-executors），每个执行器有1个线程（--executor-cores）和512米RAM（--executor-memory），每个只有2个线程，每个512MB RAM，对于现实世界的任务来说真的很小

所以我的建议是：

使用--num-executors 4 --executor-memory 12g --executor-cores 4启动Spark，这将为您提供更多的并行性 - 在这种特殊情况下有16个线程，这意味着16个并行运行的任务
使用sc.wholeTextFiles读取文件，然后将它们转储到压缩序列文件中（例如，使用Snappy块级压缩），这里有一个如何完成此操作的示例：{{3} }。这将大大减少下次迭代读取它们所需的时间