1. 从一个看似简单的问题说起128MB到底是怎么来的刚接触HDFS那会儿我对block大小的理解就停留在“默认128MB”这个数字上。面试被问到为什么是128MB而不是64MB或者256MB我支支吾吾答了句“官方推荐”结果可想而知。后来在真实集群里调过参数、踩过坑、算过账才慢慢理解这个数字背后其实是一整套关于寻址时间、磁盘吞吐、NameNode内存三者之间的权衡。这篇文章不打算复述官方文档而是把我这些年对HDFS block size的理解拆开揉碎讲清楚默认值是多少、为什么是这个值、不同版本有什么差异、生产环境怎么调、调错了会出什么事。不管你是刚学大数据的在校生还是正在维护集群的运维或者是准备面试的开发者这篇内容应该都能帮你把这块知识补扎实。先说结论Hadoop 2.x及以后版本HDFS的block默认大小是128MBHadoop 1.x时代是64MB。这个值由dfs.blocksize参数控制单位是字节默认值134217728。但真正有价值的不是记住这个数字而是理解它为什么这么设计以及你在什么场景下应该改它。2. HDFS为什么要切块block机制的核心逻辑2.1 不切块会怎样一个思想实验假设你有一个10TB的大文件要存进分布式系统。如果不切块最直接的做法是把整个文件放到一台机器上。但一台机器的磁盘容量有限10TB的单文件可能根本放不下就算放得下读写这个文件时只能从这一台机器走网络带宽成为瓶颈并行计算更无从谈起。切块解决的就是这个问题。把大文件切成固定大小的块每个块分散存储到不同节点上。这样带来三个直接好处单文件大小不再受单机磁盘限制读写可以并行从多个节点进行计算任务可以调度到数据所在的节点上减少网络传输。这就是所谓的“移动计算比移动数据更划算”。2.2 block是逻辑概念还是物理概念这里有个容易混淆的点。HDFS的block和传统文件系统的block不是一回事。传统文件系统的block是磁盘层面的物理概念是磁盘读写的最小单位。HDFS的block是逻辑上的切分单位一个block最终落到磁盘上还是以操作系统的文件形式存在底层磁盘依然按自己的block大小来读写。换句话说HDFS的block是NameNode用来管理文件元数据的单位也是DataNode存储数据的基本单元。一个200MB的文件按128MB切会变成两个block一个128MB一个72MB。第二个block虽然没满但不会去占用别的文件的空间它是独立存储的。2.3 block大小与副本的关系每个block默认有3个副本分布在不同的DataNode上。这里要注意副本的复制单位是block不是文件。一个文件被切成N个block每个block复制3份那么总共占用的存储是文件大小的3倍。block大小影响的是切分粒度不影响副本策略。副本放置策略默认是第一个副本放在客户端所在节点如果客户端在集群内第二个放在不同机架的节点第三个放在第二个副本同机架的另一节点。这个策略和block大小无关但理解它有助于你明白为什么小文件多了会拖垮集群。3. 128MB这个数字是怎么算出来的3.1 寻址时间与传输时间的黄金比例HDFS的设计目标之一是让寻址时间占传输时间的比例足够小。寻址时间指的是找到block起始位置所需的时间传输时间指的是把这个block读完所需的时间。如果block太小寻址时间占比就高读一个块大部分时间花在找位置上效率低如果block太大传输时间长但并行度下降且MapReduce任务处理一个block的时间过长影响整体调度。业界的经验值是寻址时间约为传输时间的1%时比较理想。早期磁盘的寻址时间大约在10ms左右顺序读取速度大约100MB/s。按1%算传输时间应该是1000ms也就是1秒。1秒乘以100MB/s得到100MB左右。取个整就是128MB。这个计算过程不是精确的科学公式而是工程上的经验估算。但它解释了为什么是128MB而不是随便一个数。3.2 与MapReduce的配合在Hadoop 1.x时代MapReduce的一个map任务默认处理一个block或一个splitsplit通常等于block大小。如果block是64MB一个map处理64MB数据如果改成128MB一个map处理128MB。map数量减少任务启动开销降低但单个map运行时间变长。Hadoop从1.x升级到2.x时硬件水平提升了磁盘顺序读写速度从几十MB/s提升到100MB/s以上网络带宽从1Gbps普及到10Gbps。原来64MB的block显得偏小寻址时间占比偏高于是默认值翻倍到128MB。这个调整本质上是跟着硬件走。3.3 不同版本的默认值对照Hadoop版本默认block大小对应参数默认值Hadoop 1.x64MB67108864Hadoop 2.x128MB134217728Hadoop 3.x128MB134217728Hadoop 3.x虽然引入了纠删码等新特性但默认block大小没有变依然是128MB。有些发行版可能会调整这个默认值但社区版保持128MB。4. 生产环境怎么定block大小几个真实场景的取舍4.1 场景一海量小文件小文件是HDFS的噩梦。一个1KB的文件如果按128MB切它只占一个block但这个block在NameNode里要占一条元数据记录大约150字节。1000万个1KB的文件总数据量才10GB但NameNode要存1000万条元数据占用约1.5GB内存。更糟的是每个block的副本是3份DataNode上会有3000万个块文件每个块文件在磁盘上都是一个独立文件磁盘的inode也会被耗尽。这种场景下调小block大小没有意义因为文件本身就小。正确的做法是合并小文件或者用HAR归档、SequenceFile等方式打包。如果非要调可以考虑调小dfs.blocksize但收益有限。4.2 场景二大文件顺序读写如果你的集群主要处理日志、视频、备份这类大文件顺序读写为主那么block可以适当调大。比如调到256MB减少block数量降低NameNode内存压力同时减少map任务数量降低任务调度开销。但要注意block调大后单个map处理的数据量增加如果map逻辑复杂可能导致单个任务运行时间过长拖慢整个作业。另外最后一个block可能很小造成数据倾斜。4.3 场景三随机读写为主HDFS本身不适合随机读写但如果你的业务确实有随机读的需求比如HBase底层用HDFS存储那么block大小需要结合HBase的Region大小来考虑。HBase默认Region大小是10GB一个Region对应多个HDFS block。如果block太大Region分裂时数据迁移量会很大如果block太小NameNode元数据压力大。通常保持128MB或调小到64MB。4.4 参数调整的实际操作修改block大小有两种方式全局修改和按文件指定。全局修改在hdfs-site.xml中配置property namedfs.blocksize/name value268435456/value /property这个值单位是字节268435456就是256MB。修改后需要重启HDFS服务且只对新写入的文件生效已有文件的block大小不变。按文件指定可以在写入时通过API设置Configuration conf new Configuration(); conf.setLong(dfs.blocksize, 256 * 1024 * 1024); FileSystem fs FileSystem.get(conf);或者在命令行写入时指定hdfs dfs -D dfs.blocksize268435456 -put localfile /path/in/hdfs注意block大小一旦写入就不能修改。已有文件的block大小是固定的改参数只影响新文件。5. block大小调优的常见误区与排查技巧5.1 误区一block越大越好有人觉得block大可以减少NameNode元数据于是调到512MB甚至1GB。但block太大有几个问题单个map任务处理时间过长作业整体响应变慢最后一个block可能很小造成资源浪费数据本地化率可能下降因为一个block太大可能跨多个机架存储计算时无法完全本地化。5.2 误区二block大小等于split大小MapReduce的split大小默认等于block大小但可以通过mapreduce.input.fileinputformat.split.minsize和mapreduce.input.fileinputformat.split.maxsize调整。如果split小于block一个block会被切成多个split多个map读同一个block如果split大于block一个map可能读多个block。理解这个区别有助于你优化map数量。5.3 常见问题速查表问题现象可能原因排查方向NameNode内存暴涨block数量过多检查是否有大量小文件考虑合并map任务运行时间过长block太大或map逻辑复杂调小block或增加map数量数据本地化率低block跨机架存储检查副本放置策略和机架配置写入速度慢block太小寻址开销大适当调大block磁盘inode耗尽小文件过多合并小文件或使用归档5.4 一个真实的排查案例某集群NameNode频繁Full GC内存持续上涨。排查发现集群中有大量几KB到几MB的小文件总数据量不到5TB但block数量超过800万。每个block在NameNode中占约150字节元数据800万block就是1.2GB内存加上副本和目录树NameNode堆内存吃紧。解决方案分两步短期调大NameNode堆内存缓解压力长期用MapReduce任务合并小文件将小文件打包成SequenceFile或Parquetblock数量降到50万以下NameNode内存回落到正常水平。这个案例说明block大小本身不是问题小文件才是根源。6. 从block大小延伸出去几个相关参数的联动6.1 dfs.replication与block的关系副本数默认是3和block大小没有直接关系但两者共同决定了存储开销。如果block调大副本数不变总存储量不变还是文件大小的3倍。但如果副本数调小比如冷数据调成2可以节省存储。6.2 dfs.datanode.du.reserved这个参数预留磁盘空间防止DataNode把磁盘写满。block大小影响不大但如果block很大单个block写入时可能触发预留空间不足导致写入失败。建议预留空间至少等于一个block大小。6.3 io.file.buffer.size这个参数控制读写缓冲区大小默认4KB。如果block很大顺序读写时缓冲区可以适当调大比如64KB或128KB提升吞吐。但不要超过block大小否则浪费内存。6.4 参数联动建议参数建议值说明dfs.blocksize128MB-256MB根据文件特征调整dfs.replication2-3冷数据可调小dfs.datanode.du.reserved至少一个block大小防止磁盘写满io.file.buffer.size64KB-128KB大block时适当调大7. 我在实际集群里踩过的坑第一次调block大小是在一个日志分析集群。当时觉得128MB太小直接调到512MB。结果发现日志文件大多是几十MB到一两百MB按512MB切每个文件基本就是一个blockmap任务数量骤减原本100个map变成20个单个map处理时间从2分钟变成10分钟作业整体耗时反而增加了。后来调回256MBmap数量和数据本地化率达到平衡作业耗时降到原来的一半。还有一次集群扩容后新节点磁盘容量大但block大小没变。新节点上单个block文件还是128MB磁盘利用率不高。后来把新节点的block调到256MB但老节点还是128MB导致同一个文件的不同block大小不一致。虽然HDFS允许这样但管理起来很麻烦建议集群内统一block大小。提示修改block大小前先分析集群中文件的平均大小和分布。如果大部分文件小于block大小调大block没有意义如果大部分文件远大于block大小可以适当调大。8. 面试常问的几个问题与回答思路8.1 为什么HDFS block是128MB回答思路从寻址时间和传输时间的比例出发结合硬件发展。早期磁盘寻址约10ms顺序读写约100MB/s按1%比例算出约100MB取整128MB。Hadoop 1.x是64MB2.x硬件提升后翻倍到128MB。8.2 block大小可以修改吗回答思路可以修改参数但只对新文件生效。已有文件的block大小不变。修改需要重启服务或按文件指定。8.3 block大小和split大小的区别回答思路block是HDFS的存储单位split是MapReduce的计算单位。默认split等于block但可以独立配置。一个block可以对应多个split一个split也可以跨多个block。8.4 小文件为什么不好回答思路每个小文件占一个blockNameNode要为每个block维护元数据大约150字节。大量小文件导致NameNode内存压力大同时DataNode上块文件多磁盘inode消耗大读写效率低。8.5 怎么选择block大小回答思路没有万能值。大文件顺序读写可以调大到256MB小文件多则先合并文件随机读写场景保持128MB或调小。关键是分析业务特征平衡NameNode内存、map数量和作业耗时。9. 最后分享几个实操小技巧如果你正在维护HDFS集群这几个技巧可能对你有用。查看某个文件的block大小可以用hdfs fsck /path/to/file -files -blocks输出里会显示每个block的大小和位置。查看集群整体block数量可以用hdfs dfsadmin -report关注“Under replicated blocks”和“Blocks with corrupt replicas”等指标。调整block大小后建议用hdfs balancer重新平衡数据避免新老节点数据分布不均。如果集群有大量小文件可以用hadoop archive命令打包成HAR文件减少block数量。还有一点block大小不是孤立的参数它和副本数、split大小、NameNode内存、磁盘容量都有关联。调优时不要只盯着一个参数要综合考虑。我个人的经验是除非有明确的性能瓶颈否则保持默认128MB是最稳妥的选择。默认值是社区经过大量实践验证的盲目调整往往适得其反。