hdfs块行为
我将尝试通过示例来突出显示块分割与文件大小之间的差异。在hdfs中，您有：

Splittable FileA size 1GB
dfs.block.size=67108864(~64MB)

针对此文件Map的作业：

16 splits and in turn 16 mappers.

让我们看看压缩（不可拆分）文件的这种情况：

Non-Splittable FileA.gzip size 1GB
dfs.block.size=67108864(~64MB)

针对此文件Map的作业：

16 Blocks will converge on 1 mapper.

最好主动避免这种情况，因为这意味着tasktracker必须获取16个数据块，其中大部分数据块不是tasktracker的本地数据块。
spark读取hdfs可拆分文件： sc.textFile 不会开始阅读。它只是定义了一个驻留在驱动程序中的数据结构，可以用于进一步的处理。
直到对rdd调用了一个操作，spark才会建立一个策略来执行所有需要的转换（包括读取），然后返回结果。
如果有一个操作被调用来运行这个序列，而读取之后的下一个转换是Map，那么spark将需要读取文件的一小段行（根据基于核心数的分区策略），然后立即开始Map它，直到它需要将结果返回给驱动程序，或者在下一个转换序列之前洗牌。
如果你的分区策略( defaultMinPartitions )由于分区的java表示（一个 InputSplit 在hdfs术语中）大于可用的执行器内存，则需要指定要读取的分区数作为要读取的第二个参数 textFile . 您可以通过将文件大小除以目标分区大小（允许内存增长）来计算理想的分区数。检查文件是否可以读取的简单方法是：

sc.textFile(file, numPartitions)
      .count()