📚 课程目录第4章 HDFS块大小与Spark分区的关系

4、HDFS块大小与Spark分区的关系：剖析dfs.blocksize参数如何影响Spark的默认分区策略，以及如何手动调整

好，咱们今天聊一个非常实在的话题——HDFS块大小和Spark分区之间到底什么关系？

很多同学跑Spark任务，上来就是一顿操作，分区数调来调去，但从来没想过底层HDFS的块大小已经在悄悄影响你的并行度了。我早期做离线数仓迁移时，就踩过这个坑——一个10GB的文件，默认128MB块，算下来80个分区，跑得挺欢。结果换了个集群，块大小是256MB，分区数直接砍半，任务慢了一倍不止。嗯，从那以后我再也不敢忽略这个参数了。

4.1 默认分区是怎么算出来的？

先看一个最简单的场景：你用spark.read.text("hdfs://...")读一个文件，没指定spark.sql.files.maxPartitionBytes，也没调spark.default.parallelism。那Spark到底会生成多少个分区？

说白了，规则就一条：

Spark读取HDFS文件时，默认一个HDFS块对应一个RDD分区。

也就是说，如果你文件在HDFS上占了80个块，Spark就给你生成80个分区。每个分区由一个Task处理，Task再被分配到Executor上执行。

为什么会这样？因为Spark的设计哲学是“数据本地性”——Task尽量调度到存有该块数据的节点上，减少网络传输。一个块一个分区，天然就是最优的本地性匹配。

我们来看一个具体例子：

# HDFS块大小 128MB
# 文件总大小 1GB
# 块数量 = 1024MB / 128MB = 8
# Spark默认分区数 = 8

val df = spark.read.parquet("/user/data/sales")
println(df.rdd.getNumPartitions)  // 输出 8

你想想看，如果这时候你的集群有20个Executor核心，那8个分区只能用到8个核心，剩下12个核心闲着。资源浪费啊！

4.2 dfs.blocksize 参数的影响链条

HDFS的块大小由dfs.blocksize决定，默认是128MB（老集群可能是64MB，新集群很多已经改成256MB了）。这个参数一改，整个链条都会跟着变：

dfs.blocksize	1GB文件块数	Spark默认分区数	每个分区数据量	典型场景
64MB	16	16	~64MB	小集群、IO密集型
128MB	8	8	~128MB	通用默认配置
256MB	4	4	~256MB	大集群、计算密集型
512MB	2	2	~512MB	超大块、减少元数据压力

我个人的习惯是，先看集群的核心数和内存配比，再决定要不要改块大小。比如一个200核心的集群，你搞个256MB块，1GB文件才4个分区，4个Task跑，剩下196个核心看热闹——这显然不合理。

4.3 手动调整分区：绕过块大小的限制

当然，你不可能为了调Spark就去改HDFS全局的dfs.blocksize，那影响面太大了。更常见的做法是在Spark层面手动控制分区数。

Spark提供了几个关键参数：

spark.sql.files.maxPartitionBytes：默认128MB。Spark读文件时，会尝试把多个小文件或小块合并，让每个分区不超过这个值。调小它，分区数变多；调大它，分区数变少。
spark.sql.files.openCostInBytes：默认4MB。小于这个值的文件会被视为“小文件”，合并到相邻分区中。
spark.default.parallelism：shuffle后的默认分区数，对读文件阶段没有直接影响。

举个例子，你想让每个分区处理64MB数据：

spark.conf.set("spark.sql.files.maxPartitionBytes", "64m")

val df = spark.read.parquet("/user/data/sales")
println(df.rdd.getNumPartitions)  // 1GB / 64MB = 16 个分区

这样即使HDFS块大小是256MB，Spark也会把每个块拆成多个分区来处理。代价是什么？跨节点数据读取——一个分区可能要从多个DataNode拉数据，本地性会下降。但有时候为了并行度，这个代价是值得的。

我的建议：如果集群核心数远大于HDFS块数，优先调小maxPartitionBytes，而不是改dfs.blocksize。这样既不影响HDFS全局配置，又能灵活控制并行度。

4.4 避坑指南：块大小与分区的常见误区

我在项目中遇到过几个典型问题，拿出来说说：

误区一：块越大，性能越好
块大确实能减少NameNode元数据压力，但Spark分区数会变少，并行度下降。尤其是ETL任务，IO和计算都有瓶颈，分区太少反而更慢。
误区二：分区数等于块数就万事大吉
不一定。如果块分布不均匀（比如某些块特别大，某些块特别小），分区数据倾斜会很严重。我曾经遇到一个情况，一个文件最后一块只有10MB，其他块都是128MB，结果那个分区的Task跑得飞快，其他Task还在慢慢啃——整个Job等最后一个Task。
误区三：改了maxPartitionBytes就能解决所有问题
这个参数只对文件读取阶段有效。一旦进入shuffle，分区数由spark.sql.shuffle.partitions决定。很多人只调了读文件的分区，忘了调shuffle分区，结果还是慢。

注意：如果你用spark.read.load()读的是压缩文件（比如gzip），那情况又不一样了。压缩文件不可分割，一个文件只能由一个Task处理，分区数等于文件数，跟块大小无关。这时候你再调maxPartitionBytes也没用——嗯，这个坑我后面专门讲。

4.5 核心逻辑图：块大小到分区的映射关系

下面这张图把整个流程串起来了，从HDFS块到Spark分区，再到Task执行：

从图里可以看得很清楚：HDFS块是物理存储单元，Spark分区是计算单元。默认情况下它们一一对应，但你可以通过参数打破这个映射关系。

4.6 实战建议：到底怎么配？

我总结了几条经验，供你参考：

小文件场景（文件数多、每个文件小）：调大maxPartitionBytes，减少分区数，避免Task过多导致调度开销。我一般设256MB或512MB。
大文件场景（文件少、每个文件大）：调小maxPartitionBytes，增加分区数，充分利用集群核心。比如128MB块配64MB分区，分区数翻倍。
混合场景：先用spark.sql.files.mergeSmallFiles合并小文件，再统一调整分区。嗯，这个参数在Spark 3.2之后才稳定，老版本慎用。

记住一句话：分区数不是越多越好，也不是越少越好，而是要和你的核心数匹配。一般建议分区数是核心数的2-3倍，这样既能充分利用资源，又能应对数据倾斜时的负载均衡。