这是因为数据是如何分布的，单个文档不是一个好的选择，有几个更好的选择，如Parquet地板，如果这样做，您会注意到性能将明显提高，这是因为文件的分区方式，允许您的 Apache Spark 集群将并行读取这些部分，从而提高性能。

这有点违反直觉，但是由于复制因子是3，并且您有16个节点，因此每个节点平均有20%的数据存储在本地hdfs中。那么平均大约6个工作节点就足够在没有任何网络传输的情况下读取整个文件了。
如果您记录了运行时间与工作节点数的关系，您应该注意到，在大约6个工作节点之后，从本地fs和从hdfs读取数据之间没有区别。
上述计算可以使用变量来完成，例如。 x=number of worker nodes , y= replication factor ，但是您可以很容易地看到，因为从本地fs读取文件会强制要求文件位于您最终使用的所有节点上 x=y 以后也不会有什么不同 floor(x/y) 使用的节点。这正是你所观察到的，一开始似乎是违反直觉的。你会在生产中使用100%的复制系数吗？

具体到executor、driver和rdd的参数是什么（关于溢出的ans存储级别）？
来自spark文档
性能影响 The Shuffle is an expensive operation since it involves disk I/O, data serialization, and network I/O. 为了组织无序播放的数据，spark生成了一组任务—Map任务来组织数据，以及一组reduce任务来聚合数据。这个术语来自mapreduce，与spark的map和reduce操作没有直接关系。
某些洗牌操作可能会消耗大量堆内存，因为它们在传输记录之前或之后使用内存中的数据结构来组织记录。 Specifically, reduceByKey and aggregateByKey create these structures on the map side, and 'ByKey operations generate these on the reduce side. When data does not fit in memory Spark will spill these tables to disk, incurring the additional overhead of disk I/O and increased garbage collection .
我对…感兴趣 memory/CPU core Spark作业与 memory/CPU core 限制 Map & Reduce 任务。
hadoop基准测试的关键参数：

yarn.nodemanager.resource.cpu-vcores
mapreduce.map.cpu.vcores
mapreduce.reduce.cpu.vcores
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
mapreduce.reduce.shuffle.memory.limit.percent

将spark参数与hadoop进行等价性基准测试的关键参数。

spark.driver.memory
spark.driver.cores
spark.executor.memory
spark.executor.cores
spark.memory.fraction

这些只是一些关键参数。从spark和map reduce查看详细设置
如果没有正确的参数集，我们就无法比较两种不同技术的作业性能。