大数据项目的存储层里，HDFS 通常是最先被塞满、却最后一个被优化的组件。大多数团队在容量告警触发之前，并不会认真考虑副本数、文件格式、冷数据沉降这些事，等磁盘真的快满了，第一反应往往是再加节点。这篇文章是我在生产环境里做过的 HDFS 数据存储优化算法与配套策略的复盘，按落地效果和风险展开，覆盖纠删码、压缩算法、列式存储、小文件治理与分层存储，适合正在背存储成本或者集群扩容预算的工程师参考。
内容偏实操，阅读前不要求你掌握多深的底层原理，但希望你对 block、DataNode、NameNode 这些基础名词不陌生。我会把每一步选型背后的原因讲清楚，因为这些原因比结论本身更值得迁移到你自己的环境里。存储优化从来不是某个单一开关能解决的，它是一连串取舍的叠加。
1. 存储优化不是“省钱”问题，而是“吞吐能力”问题
1.1 为什么我先从容量和 IO 之间的关系讲起
大多数团队优化 HDFS 存储时，列出的理由几乎都是“磁盘快满了”。这时候大家的首选方案是加节点、加磁盘，把容量水位压下去就完事。但做过几轮之后你会发现，纯粹靠扩容解决存储问题，等于让系统用一种更贵的方式掩盖策略缺失。那些被“塞”进集群的数据，该占的写路径、读路径、元数据内存一点都不少，只是你把冲突延后了。
HDFS 的设计初衷很有意思：它把文件切成固定大小的 block，把 block 以多副本形式分散在多台 DataNode 上。这个模型解决了两个核心问题：单机磁盘容量有限，以及单点故障导致数据不可用。但它从来不是为了“省空间”设计的。所以在讨论 HDFS 数据存储优化算法之前，应该先接受一个前提：HDFS 的默认配置追求的是可靠性、吞吐量和实现简单，不是空间效率。任何优化工作如果一上来就把目标单纯定义成“压缩存储”，很容易在后期被 IO 性能打脸。
还有一个容易忽略的点是吞吐能力。存储优化的本质不是把数据变小，而是让同样的物理资源能支撑更大的逻辑数据量和更稳定的读写。假设集群里 90% 的数据是写入后就不再访问的归档数据，三副本模型就把这些归档数据变成了吞掉磁盘的怪兽，直接挤压热数据可用的 IO 带宽。你在存储层省下来的空间，其实是为计算层抢出了吞吐余量。
1.2 存储优化前要盯住哪几个指标
我习惯把 HDFS 存储优化分成三层来看：第一层是冗余策略，回答“同一份数据到底放几份”；第二层是存储格式与压缩，回答“落盘的字节到底有多少是有效数据”；第三层是数据生命周期，回答“哪些数据值得留在热路径上，哪些应该降级甚至删除”。
对应这三层，衡量优化效果时我至少会盯住这几个指标：DataNode 使用率、各节点使用率的均衡程度、单文件平均大小、Block 总量、NameNode 堆内存占用、读取任务的本地化命中率，以及 CPU 与网络带宽的开销。只盯容量会掉进一个陷阱，比如某天你发现容量从 70% 回到 45%，但计算任务普遍变慢了，随后一查才发现是压缩参数把每个读任务的解压 CPU 成本抬高了好几个量级。
用生活里的事来类比就是家里收纳：把东西用真空压缩袋封起来确实省柜子，但下次要穿某件衣服时，你可能要把整个袋子翻出来。HDFS 也是同一个道理，冗余、编码、压缩、归档，都是在空间和取用成本之间做交换。所谓优化算法，其实就是把这种交换用显式规则固定下来，而不是让系统随机发生。
2. 纠删码（EC）取代三副本：数学原理、性能代价与选型边界
2.1 三副本块模型：最可靠也最奢侈的默认值
默认情况下，HDFS 在写一个 block 时会选择三个 DataNode，写入三个副本。这个策略带来两个直接结果：一是任意两台机器同时坏掉也不会丢数据，二是每个 block 需要三倍物理磁盘空间。
简单算一笔账：同样 100TB 逻辑数据，三副本需要 300TB 物理空间，空间利用率只有 33%。数据量小的时候，33% 利用率不是问题，因为磁盘便宜；但当集群从几十台扩展到几百台机器时，多出来的 2/3 冗余会成为每年最高的硬件支出之一。三副本读取时还有一个容易被忽略的优点——本地化。同一份数据有多个地理位置不同的副本，计算框架在分配任务时能大概率拿到本地或者近距离的副本，减少跨网络拉数据。既然三副本有这么多好处，为什么要动它？因为很多数据是写入之后长期不读的。让这些冷数据常年占三倍空间，相当于为“永远不会发生的三台同时宕机”买了份每年都在付费的保险。
这里还要说清楚一个概念：EC 不是简单的“少存几份”，而是一种纠删编码。你要的不是把副本数从 3 改成 2，而是把原来的“完整数据复制”换成“原始数据加校验信息”。这玩意的底层逻辑和传统 RAID 有些相似，但作用范围从单机阵列扩大到了跨节点的文件系统层面。
2.2 EC 的数学模型：Reed-Solomon 与 XOR 两种选择
EC 纠删码相当于单位保险：把一份数据切成 k 个数据块，再算出 m 个校验块，总共 k+m 个块。任意丢失不超过 m 个块时，都能通过剩余块恢复出完整数据。Reed-Solomon 是经典方式，运算依托有限域 GF(2^8)，编码和解码涉及矩阵和多项式计算，能容忍的丢失块数就是校验块个数。XOR 可以看成 RS 的特例，参与计算的数据块之间直接做异或运算，性能开销极小，但容错能力通常限制为只能坏一个块。
HDFS 3.x 里常见的策略有 RS-6-3-1024k、RS-3-2-1024k、XOR-2-1-1024k。以 RS-6-3 为例，表示数据块 6 个、校验块 3 个、条带大小 1024KB，存储利用率为 6/9 约等于 66.7%，比三副本的有效空间提高了一倍。XOR-2-1 是 2 个数据块加 1 个校验块，利用率 2/3，同样比三副本省不少，但容错能力明显下降。
在实际选型中，我习惯把“容灾等级”作为输入条件。如果业务允许单盘或者单节点故障重建，XOR 级别已经够用；如果要求至少抗住两个节点同时故障，RS-6-3 往往比 RS-3-2 更合适。RS 的校验块越多，容错越强，但每个条带的额外存储开销也越大，计算成本越高。不存在绝对最优，只有“在指定故障概率下最省空间”的那一个。
2.3 生产环境里的 EC 适用边界：不是所有目录都能转
我在把 EC 真正套到目录级别之后发现一个规律：适合 EC 的数据必须具备两个特征——写后几乎不变、读取频率低。前者满足 HDFS 对文件不可变或少变的要求，后者让解码开销对业务影响降低到可接受范围。典型例子是离线备份的原始日志、已经下线但暂时不能删除的结果表、半年前的数仓中间层。
不适合的则更多：需要频繁读取的在线报表表、持续追加写入的流式表、小于条带大小的零碎文件。小文件一旦做 EC，反而要付出编码块分片带来的额外复杂度，收益很容易被过程本身抵消。我在生产里推荐先选择“冷目录 + 大文件”作为试点，用数据迁移把三副本文件重写成 EC 文件。之所以先挑大文件，是因为 EC 的存储优势主要在数据块数量上体现；文件只有几 MB 时，光是把本地编码、远端读、解码恢复的时间算进去，就很不划算。
还有一点容易被忽略：EC 文件在读的时候可能触发“重建读”。也就是说，一个条带组里只要有一个 block 所在节点繁忙，读路径就可能需要从其他数据块和校验块临时重建目标块，这会显著增加延迟。所以“读频次很低”这个条件不是建议，而是硬门槛。
3. 压缩算法与文件存储格式的组合拳：从 SequenceFile 到 Parquet/ORC 的实测对比
3.1 压缩算法必须先回答一个关键问题：能不能切片
大部分刚接触 HDFS 的人会觉得压缩很简单：选压缩率最高的算法把文件变小。但把时间拉长你就知道，只看压缩率会出事。
Hadoop 生态的计算框架读取模型通常以 block 为输入分片单位。如果是一个 2GB 文本文件用 gzip 整体压缩，gzip 的流式压缩格式不支持从任意位置解压，那计算框架只能把它看成一个整体，最多用一个处理进程去解压全部数据，并行度直接废掉。而支持切片的格式，比如 LZO、bzip2 的 block 模式或者容器格式，允许任务从不同偏移量进入，就能把一个大文件切成几十个分片并行处理。
所以第一原则是：压缩算法选型要和“下游计算是否需要切片”挂钩。永远按顺序读取、不涉及切分的文件可以随便追求高压缩率；反过来，但凡要参与分布式并行读的文件，就必须优先保证可切片性。
3.2 主流压缩算法的实测对比与选型
以下是我自己的使用感受，整理成一张对比表供参考：
| 算法 | 压缩比 | 压缩速度 | 解压速度 | 可切片性 | 典型使用场景 |
|---|---|---|---|---|---|
| gzip | 高 | 中 | 中 | 否，需借助容器或特殊包装 | 冷数据归档，一次性读取 |
| snappy | 中 | 很快 | 很快 | 需配合列式格式或容器 | Spark、Hive 常用默认 |
| lz4 | 中偏低 | 极快 | 极快 | 否 | 对写入延迟敏感的场景 |
| zstd | 高 | 快 | 快 | 配合列式格式 | 推荐的大多数场景 |
| bzip2 | 极高 | 很慢 | 中 | 单独格式支持按块切分 | 极冷且极少读取的数据 |
不要把这些数字当绝对结论，因为压缩比高度依赖数据类型。日志文本的重复度高，压缩后体积可能只剩五分之一；数据库导出文件如果已经是随机文本，压缩比就不一定好看；列式存储的某些字段经过内部编码器处理后，再叠加通用压缩，效果会非常夸张。
我的经验判断大致如下：如果集群 CPU 本身很紧，先把 LZ4 或 Snappy 用起来，宁可多占一点磁盘；如果磁盘才是第一瓶颈，zstd 默认 level 3 在性价比上通常比 gzip 更值得选，因为它的压缩和解压速度都更快，压缩比也能接近 gzip。Bzip2 我一般只在“写了就永远不会再读”的历史归档分桶里用，并且配合生命周期转冷。
3.3 配合列式格式：Parquet 与 ORC 的存储表现
只谈压缩算法不谈文件格式，远远不够。现在的主流做法是把文件预先组织成列式存储格式，再在列式格式内部指定压缩算法。这样既保留了行式格式难以做到的列裁剪能力，又让同一文件内部的块大小变得可控。
Parquet 和 ORC 都能做到“只在需要的列内做扫描”，底层还自带字典编码、位图、游程编码等优化。比如一张用户表有 80 个字段，但分析任务只频繁查 5 个字段；如果以文本格式存，每次查询都要把整行全字段扫一遍，而 Parquet/ORC 能只在读路径上拉取那 5 列，HDFS 内部的磁盘 IO 自然大大减少。这一层优化有时候比压缩还管用，因为省掉的不只是空间，还有传输带宽和计算量。
在压缩选择上，Parquet 推荐 zstd 或 snappy，ORC 对 zstd 的支持也不错。实测中，如果把一张 100GB 的原始文本文件转成 Parquet 并用 zstd 压缩，最终物理体积看数据分布，往往在 15GB 到 35GB 之间。这里有个前提：建表时要把压缩参数一并设置到未来新增文件上也生效，否则新写的数据会退回默认未压缩格式，导致同一张表内部有的分区压缩，有的分区不压缩，后续优化等于白做。
3.4 老格式迁移的实践路径：SequenceFile 转型
很多老集群里还躺着大量 SequenceFile 或者自定义二进制格式。对于这批文件，我建议先做一版迁移评估：统计文件格式分布、文件平均大小、被上层任务读取的频次。如果确认是长期保留且需要归档的，可以直接走 EC 而不是格式迁移；如果仍然被日常口径读取，那迁移到列式格式是划算的。
迁移过程要小心任务风暴。我通常选当天主链路跑完后的低峰时段，用独立调度任务去做迁移，并且盯紧临时文件释放，避免 tmp 目录堆积。分区文件迁移完成后不要立刻删除原始文件，先保留一个短周期，等新格式被验证无误，再执行一次性的清理。这个短周期长短取决于业务校验节奏，我一般放 72 小时到一周。
4. 小文件治理与分层存储：命名节点瓶颈的真正解法
4.1 小文件为什么能拖垮整个集群
HDFS 的元数据把每个文件、目录和每个 block 的副本信息都放在 NameNode 内存里。这个设计让目录操作非常快，但也意味着文件数量本身会成为瓶颈。一个 128MB block 在 NameNode 里占的元数据和一个 1MB block 差不多，但后者数量会是前者的 128 倍。当一个目录下堆积了几百万个 KB 级小文件，NameNode 的堆内存就开始线性膨胀，最终导致集群整体响应变慢。
小文件问题在读取侧更直接。Spark、Hive 启动任务时，每个文件或 block 都可能被分配成输入分片，几百万个小文件等于几百万个 task。调度、序列化、连接分配等成本全部爆发，日常运维里的 NameNode RPC 超时、任务进程数过多、Driver 内存被打爆，很多时候都与小文件高度相关。
从这个角度看，小文件治理本质上也是一种存储优化算法，它不直接减少逻辑空间占用，而是减少元数据条目数量和后续计算任务的规模。别小看这个，很多集群存储没满，但任务已经跑不动了，就是小文件数量惹的祸。
4.2 小文件合并的具体操作方法
合并操作本质上就是“把小文件读出来，写进更大、更规整的目标文件”。以 Spark 为工具时，推荐按目标大小控制输出文件数量。比如目标希望每个输出文件在 256MB 左右，对一个 5GB 输入目录，比较合理的是写 20 到 25 个输出文件。至于是用 coalesce 还是 repartition，要看数据分布：数据均匀用 coalesce，避免 shuffle 开销；数据倾斜明显则要按业务 key 重新分区，用分区键约束每个文件不要出现极端偏斜。
合并过程中有几个容易出问题的点：
- 合并任务和正常业务任务同时跑，会让写入放大。建议挑空窗期执行，或者放到独立队列。
- 小文件之间的数据顺序不敏感时，可以关闭多余的重试机制，按任务特征调低内部参数，能省不少时间。
- 合并后文件的副本数要和原文件保持一致，尤其注意目录级副本策略是否被新目录继承。
- 合并完成后校验文件总数和目录总大小，确认无误再删原目录，并且保留至少一个可回溯的删除前快照。
4.3 分层存储管理：把冷数据安置到廉价介质
HDFS 从 2.6 开始支持 Storage Policy，也就是存储策略。策略允许你把文件放在 HOT、WARM、COLD 不同层级，分别对应 SSD、DISK、ARCHIVE 这类介质。ARCHIVE 一般用高密度但低性能的磁盘，价格便宜，但吞吐不一定高。策略配置后，后台的 Mover 进程会按策略把数据迁移到目标介质，不需要手工搬运。
我通常在数据接入层就完成打标：新写入的热数据默认放 HOT 策略，保留窗口内的近期数据；窗口外的离线结果转移到 WARM 或 COLD；超过 90 天的历史数据只保留一份有效副本，并配合 EC 使用。这样做之后，最明显的效果是热数据读取延迟变得稳定，磁盘扩容频率从“每季度头痛一次”降到“一年一到两次”。
分层存储最适合的数据是“越老越冷”的类型。时间越久，被访问概率越低，也就越值得从高性能介质挪到廉价介质。这个动作不需要业务方频繁介入，关键是提前把目录规划好，接数据的时候就设定对应策略，而不是数据堆满后再手工找。
4.4 生命周期脚本化：没有删除的优化只是整理
很多团队把存储优化做成了“大扫除”，而不是持续机制。大扫除的问题是，过两个月小文件又堆起来了，冷数据又开始乱飞。所以我在最后强调：存储优化必须配套数据生命周期，让任务在写数据时自动带上清理步骤。
一条比较实用的策略是：每个业务目录定义一个保留时限和访问热度预期。写入当天走 HOT；第 30 天转到 COLD；第 180 天进入待删除清单。保留期为 0 的临时目录要求任务结束后必须清空。同时建立周度巡检：扫描 NameNode 里所有文件的最近访问时间、最近修改时间、大小和路径，反推每个业务目录的“无效数据占比”，输出排名前 20 的目录清单。拿到清单后，配合业务方把确定不需要的目录彻底删除。
这个过程比任何压缩算法都更直接地释放空间，性价比最高。很多人一谈 HDFS 存储优化就想到压缩和 EC，但真正常年被忽略的，是那些已经废弃却一直没人删的任务中间结果。删掉一个废弃分区，可能比压缩十个大表更省。
5. 我在生产环境中踩过的坑：EC 不是万能药，压缩也要看场景
5.1 EC 上线第一天就把 CPU 跑穿
第一次上 EC 时，我们选了一个近 100TB 的冷数据目录，计划用十天窗口把数据缓慢转成 RS 编码。结果转到第二天，监控告警显示集群 CPU 使用率突然翻了三倍，所有离线任务的平均运行时间被拉长。排查之后发现，EC 的编码过程在写入阶段要吃大量 CPU，而那时候集群本来就有两个准点开始的大批处理任务，资源互相争抢。
如果你没有专门的冷数据处理集群，我建议把 EC 迁移任务放到相对空闲的周末，或者用流控把迁移速度调低。现在 Hadoop 的 EC 配置可以限制迁移并发，不要一上来就全速跑完。同样的问题也存在于读取侧：EC 文件如果被频繁读取，解码会占用额外 CPU。所以目录进入 EC 之前，最好先做一次读频率统计，把“读写都比较热”的文件留在三副本区。
5.2 压缩率提上去之后，查询却变慢了
另一件事是压缩格式切换。当时某张数仓大表从 Snappy 改成 gzip 压缩，物理体积降了一半，大家都很高兴。结果到了凌晨例行报表，原本 20 分钟跑完的任务变成了 47 分钟。原因很典型：该报表读取量并不大，瓶颈不在磁盘 IO 而在解压，gzip 解压的 CPU 成本远高于 Snappy，在相同资源下把任务拖慢了。
后来我们改用 zstd，物理体积接近 gzip，解压速度只比 Snappy 略慢，任务时间重新回到 25 分钟以内。这里要提醒所有正在做存储治理的团队：优化是否成功不能只看磁盘占用，还要看计算侧的核心延迟指标。我把这类问题叫做“存储和计算之间的压缩跷跷板”，你压得越狠，解压就要花越多计算能力。
如果要给一个可复用的判断标准：单次读取量大的扫描型任务，优先考虑高压缩率；单次读取量小但频率高的点查型任务，优先考虑快速解压算法；跑批链路长且资源紧张的任务，一定先做解压 CPU 测算再决定压缩方案。
5.3 重复优化不如先做治理
还有一次，我们花了一周时间把一堆历史表迁移到 Parquet 加 zstd，释放了大约 30% 存储。但同一天发现某个业务线的 HDFS 上还有大约 8TB 临时中间结果，已经滞留超过三个月。也就是说，真正该删除的数据没有机制去删，而我们却在另一边花大力气压缩另一批数据。
这个经历让我很受触动。存储优化算法再好，也只是治理体系的执行工具。应当先把路径规范、生命周期、配额管理这三件事搭好，再让具体算法各司其职。统一数据接入路径、统一保留期限、统一目录规则，用最小执行粒度避免“路径之下，各自为政”。具体算法能不能落地，最后往往取决于这些基础规则是否明确。
我在实际使用中还有一个体会：任何存储优化方案上线前，先在小目录上做灰度，把容量收益和任务延迟的账目都算清楚，再决定是否全量铺开。看似慢了半拍，其实避免了把整个集群变成实验环境的尴尬。
