1. 从一个看似简单的问题说起“HDFS 的 block 默认存储大小是多少”——这大概是每个刚接触大数据存储的人都会被问到、也都会去问别人的一个问题。标准答案张口就来Hadoop 2.x 及以后是 128MBHadoop 1.x 是 64MB。但如果你只记住这个数字面试官稍微拐个弯问一句“为什么是 128MB 而不是 256MB”或者“这个值能不能随便改”很多人就卡壳了。我自己在这个参数上踩过的坑不算少早期做日志采集的时候天真地把 block size 调到 256MB 想“减少 NameNode 压力”结果小文件场景下 MapReduce 任务数骤减、单任务跑得又慢又容易 OOM后来做冷数据归档又反过来把 block 调小结果 NameNode 元数据暴涨内存直接告急。这些经历让我意识到block size 这个参数绝不是“背个数字”那么简单它背后牵扯的是 NameNode 内存模型、寻址开销、MapReduce 切片逻辑、网络传输效率这一整套东西。这篇内容我打算把 HDFS block 默认存储大小这件事彻底讲透它是什么、默认值从哪来、为什么是这个数、改了会连锁影响什么、不同场景下该怎么选、以及实操中怎么查看和修改。适合正在搭 Hadoop 集群的运维、写 MapReduce/Spark 作业的开发者也适合准备大数据相关面试、想把底层原理理顺的朋友。哪怕你只是好奇“128MB 这个数字是怎么拍出来的”看完也能有个清晰的答案。2. HDFS block 到底是什么为什么需要它2.1 从“文件”到“块”的抽象在单机文件系统里你存一个 1GB 的文件操作系统会把它切成若干个小扇区、簇来管理但对用户来说它就是一个完整的文件。HDFS 借鉴了这个思路但做得更彻底它把一个文件物理上切成固定大小的“块”block每个块独立存储、独立复制、独立寻址。这里有个关键点容易被忽略HDFS 的 block 是逻辑概念不是物理磁盘上的连续扇区。一个 block 在底层可能分散在不同机器的不同磁盘上NameNode 只记录“这个 block 属于哪个文件、存在哪些 DataNode 上”DataNode 则负责实际的数据块文件。这种“元数据与数据分离”的设计是 HDFS 能横向扩展到上千节点的根基。为什么非要切块三个理由缺一不可突破单机容量限制一个文件可以远大于任何单块磁盘因为它是被拆开存的。简化存储管理块大小固定NameNode 只需要管理“块到节点的映射”不用关心文件内部结构元数据量大幅下降。便于并行与容错每个块可以独立复制默认 3 副本、独立校验、独立迁移某个块损坏不影响整个文件。2.2 block size 与 NameNode 内存的隐秘关系很多人调 block size 时只盯着“读写效率”却忘了它和 NameNode 内存是强绑定的。NameNode 在内存里为每个 block 维护一条元数据记录业内经验值大约是150 字节/block不同版本略有差异包含 block ID、副本位置、校验信息等。这意味着什么假设你有 1PB 数据block size 128MBblock 数量 ≈ 1PB / 128MB ≈ 838万个NameNode 内存需求 ≈ 838万 × 150B ≈ 1.2GB。block size 64MBblock 数量翻倍到 1677万个内存需求 ≈ 2.4GB。block size 256MBblock 数量减半到 419万个内存需求 ≈ 600MB。看到没block size 每翻一倍NameNode 的元数据压力就减半。这就是为什么大集群倾向于用更大的 block——不是为了读写快而是为了省 NameNode 内存。但反过来block 太大又会导致小文件浪费、任务并行度下降这就是后面要讲的权衡。2.3 默认值的历史演变Hadoop 版本默认 block size背景0.x / 1.x64MB受限于当时磁盘带宽与内存成本2.x 及以后128MB磁盘顺序读写能力提升元数据压力需要缓解部分发行版如某些云厂商256MB面向超大集群与冷数据场景调优这个演变逻辑很清晰磁盘越来越快、单盘容量越来越大而 NameNode 内存相对昂贵所以默认值往上走是必然。128MB 是 2010 年前后硬件条件下的一个平衡点放到今天其实已经偏保守了很多生产集群会主动调到 256MB。3. 为什么默认是 128MB而不是 64MB 或 256MB3.1 寻址开销与传输时间的平衡HDFS 读一个 block 的过程不是“打开文件就读”而是要先向 NameNode 请求 block 位置再和 DataNode 建立连接、传输数据。这个“握手 寻址”的固定开销业内估算在几十毫秒量级。如果 block 太小比如 1MB那么读 1GB 文件要经历 1024 次寻址光握手就耗掉几十秒磁盘带宽根本跑不满。反过来block 太大寻址次数少了但单个 block 传输时间变长任务粒度变粗并行度下降而且一旦某个 block 传输失败重传代价也大。128MB 的妙处在于在当时的千兆网络和机械盘条件下传输一个 128MB block 的时间约 1 秒级远大于寻址开销几十毫秒寻址开销被摊薄到可以忽略。这就是经典的“让传输时间主导、让寻址开销边缘化”的思路。3.2 与 MapReduce 切片的联动这是最容易被忽视的一环。MapReduce 的 InputFormat 在切分任务时默认是按 block 边界切的准确说是按 block 所在节点做数据本地化。一个 block 通常对应一个 map 任务。block 64MB1GB 文件 → 16 个 map 任务。block 128MB1GB 文件 → 8 个 map 任务。block 256MB1GB 文件 → 4 个 map 任务。map 任务数不是越多越好也不是越少越好。任务太多调度开销、JVM 启动开销累积起来很可观任务太少并行度不够集群资源闲置。128MB 在“任务粒度”和“并行度”之间给了一个相对舒服的默认值。当然Spark 时代这个逻辑有所变化因为 Spark 的 partition 切分更灵活但底层读 HDFS 时依然受 block 影响。3.3 一个具体的计算示例假设集群有 10 个 DataNode每个节点 4 块 2TB 机械盘千兆网络理论 125MB/s实际约 100MB/s。读一个 128MB block理想传输时间 ≈ 128 / 100 ≈ 1.28 秒。寻址 握手开销假设 50ms占比 ≈ 50 / 1280 ≈ 3.9%可以接受。如果 block 32MB传输时间 ≈ 0.32 秒寻址占比升到 ≈ 13.5%明显偏高。如果 block 512MB传输时间 ≈ 5.12 秒寻址占比降到 1% 以下但单任务变重失败重传成本高且小文件场景浪费严重。所以 128MB 不是数学上的最优解而是工程上的舒适区寻址开销占比低、任务粒度适中、元数据压力可控。4. 修改 block size 会连锁影响什么4.1 对 NameNode 的影响前面算过block size 翻倍block 数量减半NameNode 内存压力减半。这是调大 block 最直接的收益。但要注意已经写入的数据不会因为改了配置就重新切块。block size 是“写入时生效”的参数改配置只影响新写入的文件存量文件的 block 还是老大小。所以指望改个参数就立刻缓解 NameNode 内存是不现实的得配合数据重写或迁移。4.2 对小文件问题的影响HDFS 最怕小文件。一个 1KB 的文件如果 block size 是 128MB它依然占用一个 block 的元数据约 150 字节但实际数据只占 1KB。1000 万个 1KB 文件NameNode 要维护 1000 万条元数据内存直接爆炸而实际数据量才 10GB。调大 block size 对小文件问题没有任何帮助反而可能让“一个 block 装很多小文件”的错觉更严重实际上 HDFS 不会把多个小文件塞进一个 block每个文件至少占一个 block。解决小文件要靠归档HAR、合并CombineFileInputFormat或上层治理不是调 block size。4.3 对任务并行度的影响block 调大map 任务数减少单任务处理数据量增加。这在数据量大、单任务逻辑轻的场景下是好事减少调度开销但在单任务逻辑重、容易 OOM 的场景下就是灾难。我见过一个案例某作业把 block 从 128MB 调到 256MB 后单个 map 处理的数据翻倍结果 executor 内存不够频繁 GC整体耗时反而上升了 30%。所以调 block size 一定要结合任务的实际内存模型来评估。4.4 对网络与磁盘 IO 的影响大 block 意味着单次顺序读写的数据量更大对磁盘顺序吞吐更友好对网络带宽的利用也更充分减少了连接建立次数。但代价是故障恢复粒度变粗一个 256MB 的 block 传输失败要重传 256MB而 128MB 只需重传 128MB。在稳定性一般的集群里大 block 的重传成本不容忽视。5. 实操查看与修改 block size 的完整流程5.1 查看当前默认值最直接的方式是看配置文件hdfs-site.xmlproperty namedfs.blocksize/name value134217728/value /property注意单位是字节134217728 128 × 1024 × 1024。如果你看到的是 67108864那就是 64MB。也可以用命令行查看某个已存在文件的 block 情况hdfs fsck /path/to/file -files -blocks输出里会列出每个 block 的 ID、大小和所在 DataNode。如果文件是 128MB 整你会看到一个满 block如果文件是 200MB你会看到 128MB 72MB 两个 block。5.2 修改默认值修改hdfs-site.xml中的dfs.blocksize然后重启 NameNode 和 DataNode部分版本支持滚动重启。注意这是集群级默认值改完只对新写入文件生效。property namedfs.blocksize/name value268435456/value !-- 256MB -- /property5.3 为单个文件指定 block size不想改全局配置可以在写入时按文件指定。命令行方式hdfs dfs -Ddfs.blocksize268435456 -put localfile /hdfs/pathJava API 方式Configuration conf new Configuration(); conf.setLong(dfs.blocksize, 256 * 1024 * 1024L); FileSystem fs FileSystem.get(conf); FSDataOutputStream out fs.create(new Path(/hdfs/path/file));这种方式适合“大部分文件用默认值个别大文件单独调大”的场景灵活性最高。5.4 修改后的验证写完文件后用hdfs fsck确认 block 大小是否符合预期hdfs fsck /hdfs/path/file -files -blocks如果看到 block 大小是 268435456说明生效了。如果还是 134217728检查是不是配置没重启、或者写入时被其他配置覆盖了。提示dfs.blocksize是服务端配置客户端提交作业时如果没显式指定会以服务端为准。但某些计算框架如 Spark有自己的切分逻辑实际读取时未必严格按 block 对齐这点后面会讲。6. 不同场景下 block size 怎么选6.1 场景对照表场景推荐 block size理由通用批处理128MB ~ 256MB平衡元数据与并行度海量小文件不调 block先治理小文件调 block 无效超大文件顺序读256MB ~ 512MB减少寻址提升吞吐冷数据归档256MB 或更大降低 NameNode 内存压力频繁随机读128MB 或更小减少单次读取浪费内存敏感型任务128MB 或更小降低单任务内存压力6.2 一个真实的调优案例某日志分析集群日均新增 2TB 日志文件普遍在 1GB~5GB。最初用默认 128MBNameNode 内存吃紧约 8000 万 block。后来把 block 调到 256MB新数据 block 数减半NameNode 内存增长明显放缓同时因为文件本身较大map 任务数减少带来的调度收益也很明显整体作业耗时下降了约 15%。但同一集群里有个做实时查询的组件读的是随机偏移block 调大后单次读取要拉更多数据延迟反而上升最后给这个组件单独指定了 128MB。这个案例说明block size 没有全局最优只有场景最优。同一个集群里不同业务用不同 block size 是完全合理的。7. 常见问题与排查技巧7.1 常见问题速查表问题现象可能原因排查方向改了配置不生效未重启 / 只对新文件生效检查服务状态确认写入时间文件 block 数异常多小文件过多用 fsck 统计考虑归档NameNode 内存暴涨block 数过多统计 block 总数评估调大 block任务 OOMblock 调大后单任务数据量增加评估 executor 内存或调回 block读取延迟高block 过大导致单次读取浪费检查访问模式考虑调小7.2 独家避坑经验坑一以为改了配置存量数据会重切。这是最常见的误解。block size 是写入时决定的存量文件的 block 布局不会变。要改变存量数据只能重写比如用 DistCp 重新拷贝一遍。坑二盲目调大 block 导致任务倾斜。如果数据本身分布不均大 block 会让“大文件集中在一个节点”的问题更突出某些 map 任务处理的数据量远超其他任务拖慢整体。调 block 前先看数据分布。坑三忽略计算框架的切分逻辑。Spark 读 HDFS 时partition 数不完全等于 block 数它还会考虑spark.sql.files.maxPartitionBytes等参数。只调 HDFS block 不一定能达到预期的并行度要两边一起看。坑四在 NameNode 内存已经告急时直接调大 block。调大 block 只对新数据生效短期内 NameNode 内存不会下降反而可能因为新旧 block 混杂增加管理复杂度。正确做法是先治理存量删冷数据、归档小文件再调新数据的 block。7.3 一个实用的监控指标想知道 block size 设置是否合理盯住两个指标平均 block 大小如果远小于配置值说明小文件多调 block 没用。单 DataNode block 数如果持续增长且 NameNode 内存吃紧考虑调大 block。这两个指标在 Hadoop 的 JMX 或 NameNode Web UI 里都能看到养成定期看的习惯比出事再救火强得多。8. 关于 block size 的几个延伸思考8.1 云存储时代的 block 概念变化对象存储如各类云对象存储里没有“block”这个概念取而代之的是“对象”和“分片上传”。但很多大数据组件在对接对象存储时会模拟出类似 block 的切分逻辑比如按 128MB 分片。理解 HDFS block 的原理对理解这些模拟机制依然有帮助——本质都是“大文件切分 元数据管理 并行读写”这套思路。8.2 纠删码对 block size 的影响HDFS 3.x 引入了纠删码Erasure Coding它把数据切成更小的单元cell再做编码。在纠删码模式下block size 的含义和副本模式略有不同通常建议配合更小的 cell size 使用。如果你的集群启用了纠删码调 block size 前一定要先搞清楚 EC 的条带化逻辑否则容易踩坑。8.3 面试里怎么答这个问题如果被问到“HDFS block 默认多大”别只答数字。可以这样组织默认 128MBHadoop 2.x这个值是在寻址开销、NameNode 内存、任务并行度之间权衡的结果它只对新写入文件生效调大能缓解 NameNode 内存压力但会降低并行度小文件场景调它没用。这样答基本能覆盖面试官想考察的所有点。我个人在实际操作中的体会是block size 这个参数最忌讳“拍脑袋调”。每次调整前先问自己三个问题当前 NameNode 内存压力大不大任务并行度够不够数据是小文件为主还是大文件为主把这三个问题想清楚答案基本就出来了。最后再分享一个小技巧如果拿不准就先用默认 128MB 跑一段时间通过 NameNode Web UI 观察 block 总数和平均大小用数据说话比任何经验公式都靠谱。