HDFS写读全流程拆解：从block到chunk的底层原理

很多数据工程师在HDFS上跑了几百个任务写了几十个TB数据但被问起一条数据到底是怎么写进DataNode磁盘的回答往往止步于一句话文件被切成block复制三份存到不同节点。这个说法没错但粒度太粗。block只是HDFS在逻辑上对文件的切片真正参与内存组装、网络传输、磁盘落盘和完整性校验的是比block小得多的packet和chunk。block是HDFS的户口本单位chunk才是数据的身份证单位。这篇文章打算沿着block到chunk这条链路把HDFS读写全流程完整拆一遍适合想深入理解分布式文件系统读写机制、排查读写性能或数据损坏问题的开发和运维同学。内容不绕弯直接按底层原理和实操经验来讲。1. 先把存储单位这层窗户纸捅破block、packet、chunk各管什么1.1 block只是逻辑切片128MB是怎么来的HDFS的设计目标之一是让单个文件能跨越整个集群的磁盘所以文件必须切片。block就是HDFS自己定义的文件切片单位默认128MB。为什么不设小一点因为分布式系统的寻址成本太高。block太小一个TB文件会切出上万个blockNameNode内存里每个block的元数据至少要占一百多字节文件一多堆内存立刻吃紧。另一个原因是IO模型批处理任务读大文件时希望顺序IO命中率高block太小会让任务调度粒度碎掉block太大又影响并行度。128MB是两者之间的折中。这个值能通过dfs.blocksize配置调整但生产环境基本都用默认值。这里必须澄清一个常见误解block不是物理磁盘块。文件系统层面的磁盘块通常4KB而HDFS的block纯粹是NameNode的元数据概念。DataNode磁盘上不会出现一个正好128MB、带block名字的文件block的内容最终会被拆到更小的传输单位里往下走。1.2 packet是真正在网络上传的单位客户端往DataNode写数据时不可能一次把128MB全扔过去网络socket接不住内存也扛不住。实际做法是DFSClient把block数据切分成一个个packet默认每个64KB。packet是HDFS流式写入的传输单位它在客户端内存里组装在pipeline节点之间转发。一个packet里面有header有多个chunk的data区域整体结构紧凑。打个比方block像集装箱的标准尺寸但真正在高速公路上跑的车是packet——一车一车运而不是把整个集装箱甩上马路。理解了这一层后面看DataStreamer的发送逻辑就顺了。1.3 chunk是校验和计算的最小单元每个packet内部又被分成若干个chunk默认每个chunk 512字节。chunk是HDFS做数据完整性校验的最小单元每512字节数据计算一个4字节CRC32校验和。这里有个值得细品的工程设计如果校验粒度太大比如按整个block计算一旦中间有一小段数据在传输或磁盘上损坏整个block就废了只能整个重新复制。校验粒度太小校验和存储开销和计算开销又会翻倍。512字节配4字节CRC校验和开销只有数据量的1/128是个经典折中。所以整个存储体系的分工是block负责逻辑分片和副本管理packet负责传输组装chunk负责完整性校验。三者层层嵌套一个128MB的block大约包含2048个64KB的packet一个64KB的packet大约包含128个512字节的chunk每个chunk对应一个4字节CRC32。1.4 磁盘上的真相每个block对应数据文件和meta文件当数据真正落到DataNode磁盘上时默认副本数3每个副本分别对应两个文件blk_1073741825这样的数据文件以及blk_1073741825_1001.meta这样的校验和文件。block ID由NameNode全局分配DataNode的volume选择策略决定block放进哪个磁盘目录。meta文件的内容说穿了就是这份数据文件里每个chunk的CRC32校验和列表文件头还记录chunk大小和校验算法类型。所以磁盘上数据文件有多大meta文件差不多就是它的1/128大小。曾经有业务方问我这些.meta文件能不能删我的答复很直接不能。删了meta文件等于丢掉每个chunk的校验依据以后DataNode读这个block时无法做完整性校验数据损坏只能靠重读其他副本兜底跟裸奔没区别。存储单位默认大小职责对应物理实体block128MB逻辑分片、副本管理、NameNode寻址blk_xxx数据文件packet64KB网络传输组装、pipeline转发socket包头载荷chunk512字节数据完整性校验对应meta中4字节CRC322. 写入一条数据从租约、DataStreamer到pipeline的完整链路2.1 写请求的开始create、租约与租约恢复客户端调用FileSystem.create(path)时实际是向NameNode发了一个RPC请求。NameNode会做三件事检查权限、创建文件INode、为文件分配一个租约。租约是HDFS保证单写者写一致性的机制——同一时刻只允许一个客户端持有文件写租约。很多人忽略租约直到写任务挂掉之后重试时抛出LeaseExpiredException才想起来有这回事。如果客户端崩溃租约会超时过期默认软限60秒硬限1小时NameNode会触发租约恢复把文件恢复到上一个完整状态。观察日志时lease recovery通常会伴随一系列block recovery操作这是HDFS把没写完的半截block收尾的核心过程后面2.5节还会讲到。2.2 DataStreamer是写路径的调度中心create成功后客户端拿到的不是普通输出流而是一个DFSOutputStream。很多人以为写数据是主线程直接把数据写进socket其实不是。DFSOutputStream内部有个专门线程叫DataStreamer它维护一份待发送packet队列。主线程只负责把用户数据切块、逐chunk计算校验和、组装packet、把packet放入队列DataStreamer线程再从队列取出packet通过pipeline发出去。这个设计为什么好因为网络写和内存组装是节奏完全不同的两件事。主线程若在write()里同步等待socket发送一次flush就会阻塞很久。拆成独立线程后write()只需把数据放进队列吞吐立刻上来。也就是说你在代码里写的hdfs.write(bytes)和数据真正落到DataNode磁盘中间隔了一整条异步流水线。定位写性能问题时第一步就是看DataStreamer线程是卡在队列消费上还是卡在网络发送上。2.3 chunk校验是写入路径的保险丝chunk校验在写路径上的具体动作是客户端每收到512字节用户数据就计算CRC32把这4字节填进packet中对应chunk的区段。packet的header里还会带offset、seqno等信息DataNode收到packet后把每个chunk的校验和逐条记入meta文件。这里分享一个排查经验某次离线任务频繁报IOException: Packet checksum mismatch查到最后是网络交换机丢小包导致的。因为HDFS的packet带校验数据在传输中只要被改一个bit到达端校验立刻失败。这个机制正是HDFS敢在网络层不做额外完整性保护、也不怕数据漂移的底气。要注意的是HDFS保障的是传输和存储完整性不是业务幂等——应用层经常出现两边对比少几条的问题这类问题不该指望HDFS侧解决。2.4 三副本pipeline转发、ACK与背压当DataStreamer准备写一个block时会向NameNode申请一组DataNode默认3个构成pipelineDN1 - DN2 - DN3。写数据流向是客户端把packet发给DN1DN1落盘到自己的数据文件和meta文件后把同一个packet转发给DN2DN2同样落盘、转发给DN3。最后一个DN写完后ACK包逐级返回客户端。这种链式复制把客户端的写带宽压力降到最低客户端只发一份数据后两份副本由DataNode之间自行复制。但它也带来一个问题pipeline中任一节点慢全链就堵住这就是背压。如果DN2磁盘老化导致每次fsync耗时很长ACK反馈给客户端的时间就会拉长DataStreamer发送队列开始堆积最终写入阻塞。之前跑大批量入库任务时最有效的观测手段就是看DataStreamer线程是否长时间卡在wait/read状态以及DataNode侧数据落盘的fsync耗时。2.5 写失败现场pipeline重建与续传pipeline在block写入途中如果某个节点宕机怎么办举个例子客户端已经发出packet 1到50DN1也转发了大部分此时DN2挂了。客户端的处理方式是先做一次已确认和未确认packet的对齐把DN2从pipeline剔除剩余未写完的packet继续发给DN1同时NameNode会选一个新节点DN3DN1把数据补复制给它最终恢复3副本。HDFS把这个动作叫pipeline recovery。对运维同学来说这段逻辑的价值在于写任务里的IOException不一定是客户端bug。如果日志里出现Recovering pipeline或pipeline closed字样往往意味着那一瞬间有节点故障或网络抖动recovery完成后写入会自动继续。应用层此时疯狂重试同一个失败写请求反而容易把客户端压垮。我的建议是写数据任务把HDFS的retry策略设宽松些让HDFS先内部恢复不要一上来就靠应用层暴力重试。3. 读取一条数据定位、就近、校验与降级3.1 读路径的起点NameNode返回block位置列表读文件比写简单但细节不少。客户端调用open(path)时NameNode返回文件的block列表每个block对应一个BlockLocation数组。BlockLocation里最重要的信息是这个block的副本落在哪些DataNode上以及每个DataNode的机架信息。客户端读取某段数据时会先按偏移量定位到目标block。容易被忽略的一点是BlockLocation给出的是一组副本候选地址不是指定读某一个。客户端需要根据自身位置和候选DataNode的位置计算距离选出最近副本去连接。选择逻辑默认按网络拓扑距离排序本机优先然后是同一机架、同一数据中心最后才是跨数据中心。3.2 读取的数据单位依然是chunk和packet虽然读取方向是DataNode往客户端传数据数据组织仍然沿用写路径的packet和chunk概念。DataNode读取本地block的数据文件按packet粒度封装后通过socket返回客户端客户端按packet解析并逐chunk用CRC32校验和检查。写路径和读路径在数据切分上的默契让校验逻辑完全复用这是HDFS设计里很优雅的一点。读性能上客户端和DataNode之间距离远时瓶颈往往不是磁盘顺序读而是网络带宽。我在跑大表全量扫描时观察到从不同机架读同一批数据吞吐量差接近三成。后来把计算任务调度改成与数据所在机架对齐跨机架流量明显降下来。这就是机架感知在读路径上最实际的价值。3.3 校验失败时的自动降级链读取时如果某个chunk校验失败说明这个副本可能坏了。客户端会先把这块记录为校验失败并向NameNode上报BlockBad状态NameNode收到后把损坏副本标记为corrupt安排从其他副本复制数据复原详见4.2。客户端本身则从BlockLocation列表里选下一个可用副本重新发起读请求。所以只要副本冗余充足读任务通常不会失败只会悄悄变慢。这里提醒一个坑有些用户把replication临时改成2再遇到一块坏盘读任务就开始随机失败。这不是读路径没做降级而是降级空间被压缩没了。核心数据还是建议保持3副本除非你明确接受了数据丢失风险。3.4 短路读数据明明在本机何必绕一圈网络如果客户端进程恰好运行在block副本所在的DataNode上按正常流程数据还是会先从DataNode网卡出去再绕回客户端——同机器绕一圈网络白白消耗带宽和延迟。为了消除这个开销HDFS提供Short Circuit Read短路读客户端通过Unix Domain Socket直接打开本地副本的数据文件按偏移量读取不经过DataNode的socket server。启用方式是在hdfs-site.xml里配置dfs.client.read.shortcircuittrue同时设置dfs.domain.socket.path并确保libhdfs客户端库安装到位。用Spark或MapReduce跑本地任务时短路读一般能带来10%到30%的读吞吐提升尤其适合大量小文件或热点数据场景。但如果配置了短路读又没配好权限客户端会因无法打开socket而回退到正常读路径日志里出现shortcircuit disable提示。此时性能与普通读一致属于保护性降级很多人看到日志误以为集群故障其实是正常回退。4. 数据管家视角副本策略、机架感知、损坏恢复与实操观测4.1 默认的三副本不是随便放的HDFS默认三副本放置策略是第一个副本放在客户端所在的DataNode客户端不在集群里就随机选一个节点第二个副本放在与第一个不同机架的节点第三个副本放在与第二个同机架但不同DataNode的节点。这么放是为了对抗三种故障域机器故障靠同机不同节点机架级故障靠跨机架副本写性能则靠第二个副本合理跨机架换取整体容灾能力。副本放置还和租约、故障转移联动。高可用模式下NameNode主备切换block副本状态会经历epoch管理多副本或少副本的情况由后后台的block replication线程调度补齐。这些机制平时不显眼但每次节点下线维护时都能看到它们在工作。所以我一直建议运维状态巡检不要只看CPU和内存最好定期看一眼副本分布是否均衡。4.2 从损坏发现到自动重建校验和修复闭环当一个DataNode在服务读请求时发现某个block的chunk校验失败会把这个block上报给NameNode。NameNode把该副本标记为corrupt然后启动一个复制任务从其他健康副本把block复制到新节点恢复副本数。因为校验和按chunk粒度保存损坏被定位的精度能到512字节级别读路径可以先发现chunk校验失败提前止损而不必等整个block读完。此外DataNode的BlockScanner会周期性读取本地block并比对meta文件校验和把静默损坏暴露出来。这就是大型集群普遍依赖HDFS完整性机制、不再另做文件校验的原因。meta文件本身损坏的情况理论上也存在HDFS把这种情况视为坏盘并触发副本修复。理解这个闭环后很多为什么某个block健康副本数是2的疑问就有答案了。4.3 用fsck和debug亲眼看到block与chunk讲了这么多原理实际操作怎么观察block与chunk我最常用的命令是这样的hdfs fsck /user/data/demo.csv -files -blocks -locations输出里能看到文件被切成哪些blockblock分布在哪些节点是否健康。如果文件有损坏fsck会直接列出corrupt block数这是排查数据问题时最先应该看的结果。hdfs debug recoverLease -path /user/data/demo.csv -retries 10这条命令用于租约恢复比如写任务崩溃后文件处于pending状态可以通过它人工触发lease recovery。更底层的观测方式是直接进入DataNode数据目录看blk文件ls -l /dfs/data/current/BP-xxx/current/finalized/subdir0/subdir0 | grep blk_你会看到blk_数字开头的数据文件和blk_数字_后缀.meta校验文件。两者体积比例大约128比1正好对应512字节chunk配4字节CRC的设计。这个比例是判断meta文件是否异常丢失的直观依据如果某个blk旁边没有同名meta文件请立刻借助副本冗余恢复不要等它出问题。4.4 一个绕不开的扩展EC纠删码模式下的block与chunk写到这里必须提一嘴EC模式。HDFS从3.0开始正式支持纠删码存储默认策略RS-6-3用约1.5倍冗余换取与三副本同等的容错能力存储成本直降一半。EC模式下依然有block概念但角色变成了block group——一组block拼成一个条带条带内按数据单元和校验单元布局取代了副本模式下每个block三份副本的模式。因为条带内以单元为单位组织读写不再走pipeline式全链复制写路径变成同时写多个数据节点和多个校验节点。EC对运维的要求也不同文件一旦EC化必须保持条带对齐且不支持追加写。把历史文件从副本模式改成EC需要新建文件再迁移不能原地改。生产上我一般建议热数据、频繁追加的数据保留副本模式冷数据、写后不动的数据走EC。但无论哪种模式从block到chunk的完整性校验思想始终一脉相承只是单元名称和放置维度变了。最后给一点私人心得排查HDFS读写变慢或数据异常时别急着调网络参数、换磁盘先看block分布和corrupt状态再顺着chunk校验链路往下查。我见过太多把问题定位到应用层最后发现是meta文件丢失、副本重建缓慢导致的案例。理解了block到chunk这一层很多HDFS黑盒问题其实都能用常识推出来。