DataNode磁盘报警了——HDFS存储管理、Balancer和纠删码
本文目录
先说结论
HDFS存储管理有三个核心问题：① 数据均衡——DataNode之间的数据量差异太大要用Balancer均衡；② 存储成本——3副本太贵，纠删码可以降到1.4倍冗余；③ 磁盘管理——多磁盘策略、存储类型分级（SSD/HDD/Archive）。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
HDFS的存储管理是运维的日常工作。在某知名出海硬件品牌用EMR时，有一次几个DataNode的磁盘使用率同时超过90%，而其他DataNode只用了50%——数据分布严重不均。原因是新加了几台DN后没有及时跑Balancer。另一个痛点是3副本带来的3倍存储成本——100TB数据实际占300TB磁盘。Hadoop 3.0引入的纠删码（Erasure Coding）可以把冗余从3倍降到1.4倍，但使用有条件。
DataNode的存储架构
# DataNode的磁盘配置（hdfs-site.xml）
# 一台DataNode通常配多块磁盘
dfs.datanode.data.dir = /data1/hdfs,/data2/hdfs,/data3/hdfs,/data4/hdfs
# 数据在多块磁盘之间的分配策略
# Round-Robin（默认）：轮询写入各磁盘，均匀分布
# Available Space：优先写剩余空间大的磁盘
dfs.datanode.fsdataset.volume.choosing.policy =
org.apache.hadoop.hdfs.server.datanode.fsdataset.
AvailableSpaceVolumeChoosingPolicy
# 磁盘使用率告警阈值
dfs.datanode.du.reserved = 10737418240 # 每块盘预留10GB
# 超过阈值后DN停止接受新的Block写入
# 但已有数据的读取不受影响Balancer——DataNode之间的数据均衡
Balancer是HDFS自带的数据均衡工具，把数据从使用率高的DataNode迁移到使用率低的DataNode：
# 运行Balancer
hdfs balancer -threshold 10
# threshold=10 表示所有DN的使用率差异控制在10%以内
# 比如集群平均使用率60%，那所有DN使用率应在50%-70%之间
# 常用参数
hdfs balancer \
-threshold 10 \
-policy datanode \
-include-nodes /path/to/include_nodes.txt \
-exclude-nodes /path/to/exclude_nodes.txt
# 控制Balancer带宽（避免影响线上查询）
hdfs dfsadmin -setBalancerBandwidth 104857600 # 100MB/s
# 默认10MB/s，太慢；但设太大会影响正常IO
# 建议低峰期设100MB/s，高峰期降到20MB/s
# 查看均衡进度
hdfs dfsadmin -report
# 看每个DN的DFS Used%是否趋于一致什么时候需要跑Balancer？① 新加了DataNode（新节点是空的，旧节点满）；② 部分DN磁盘报警（使用率不均）；③ 某些DN因为机架位置被大量写入。在某知名出海硬件品牌用EMR时，每次Scale Up加节点后都要跑一轮Balancer，否则新节点闲着旧节点满。
纠删码（Erasure Coding）——从3倍降到1.4倍冗余
3副本机制简单可靠，但存储开销是数据的3倍。Hadoop 3.0引入了纠删码（EC），用Reed-Solomon算法把数据编码成数据块+校验块，任何部分丢失都能恢复。
| 维度 | 3副本 | 纠删码（RS-6-3） |
|---|---|---|
| 冗余率 | 3倍（100TB存300TB） | 1.5倍（100TB存150TB） |
| 存储成本 | 高 | 降低约50% |
| 可容忍故障 | 任意2节点 | 任意3节点 |
| 写入性能 | Pipeline写入，延迟低 | 编码计算有开销，延迟稍高 |
| 读取性能 | 任一副本直接读 | 需要多节点数据拼接 |
| 适用场景 | 热数据（频繁读写） | 冷数据（不常访问） |
# 启用纠删码（Hadoop 3.0+）
# 查看支持的EC策略
hdfs ec -listPolicies
# RS-6-3-1024k: 6个数据块+3个校验块，可容忍3个节点故障
# RS-3-2-1024k: 3个数据块+2个校验块，最低9个节点
# 对指定目录启用EC
hdfs ec -setPolicy -path /warehouse/cold_data -policy RS-6-3-1024k
# 之后写入/warehouse/cold_data的文件自动使用EC
# 已有文件不会自动转换，需要重新写入
# 适用条件：
# ① 集群节点数 >= 数据块+校验块数（RS-6-3需要至少9个DN）
# ② 适合冷数据（归档日志、历史分区），不适合热数据
# ③ EC的恢复比3副本慢（需要计算），影响数据可用性SLA存储类型分级（Storage Policy）
HDFS支持给不同数据设置不同的存储策略，实现冷热分级：
| 存储策略 | 存储介质 | 适用数据 | 副本分布 |
|---|---|---|---|
| HOT（默认） | 全部存SSD或高速盘 | 最近7天的热数据 | 3副本全在DISK |
| WARM | 部分SSD+部分HDD | 7-30天的温数据 | 1副本SSD+2副本HDD |
| COLD | 全部存HDD | 30天-1年的冷数据 | 3副本全在HDD |
| ALL_SSD | 全部存SSD | 极热数据（实时查询） | 3副本全在SSD |
# 设置存储策略
hdfs storagepolicies -setStoragePolicy -path /warehouse/hot -policy HOT
hdfs storagepolicies -setStoragePolicy -path /warehouse/cold -policy COLD
# 触发数据按策略移动
hdfs mover -p /warehouse/cold
# Mover工具会把/warehouse/cold下的数据从SSD移到HDD实战经验：EMR存储成本优化
在某知名出海硬件品牌用EMR时，存储成本占了整个数据平台预算的约40%。我做了两个优化：
① S3分层存储：把30天以上的历史数据从S3 Standard移到S3 Infrequent Access（IA），90天以上移到S3 Glacier。这一步就把存储成本降低了35%。虽然这不是HDFS的优化，但原理和HDFS的存储策略分级完全一致。
② 清理冗余数据：很多Spark作业的中间结果和临时表没有设置过期时间，积累了大量垃圾数据。写了一个脚本定期清理超过7天的临时目录。又释放了约20%的存储空间。
最终效果：存储成本降低35%，每月节省约3万美元。这个数字写在了我的述职报告里，也是面试时的亮点。
面试高频追问
追问一：Balancer跑的时候会影响线上查询吗？
会。Balancer迁移数据会占用磁盘IO和网络带宽。可以通过setBalancerBandwidth控制速度——低峰期设大（100MB/s），高峰期设小（20MB/s）或暂停。和Doris的Balance原理一样（Doris那个系列也讲过），核心是控制速度避免影响线上。
追问二：纠删码适合什么场景？
适合冷数据——存储量大但访问频率低的数据（归档日志、历史分区、备份数据）。不适合热数据——EC的读取需要从多个节点拼接数据，延迟比3副本高；写入也需要编码计算，吞吐略低。我的建议是：热数据用3副本保证性能，冷数据用EC降低成本。
追问三：HDFS和S3在存储管理上有什么区别？
最大的区别是：HDFS的存储管理需要手动维护（跑Balancer、配存储策略、管理磁盘），S3的存储管理由AWS自动处理（自动均衡、自动冗余、生命周期策略）。这就是为什么越来越多公司选择S3——不是HDFS不好，而是S3的运维成本低得多。在出海硬件品牌的迁移中，光运维工作量就减少了约60%。
总结
HDFS存储管理面试讲三个方向：① Balancer数据均衡（什么时候跑、怎么控制速度、避免影响线上）；② 纠删码降成本（3倍降到1.5倍，适合冷数据不适合热数据）；③ 存储策略分级（HOT/WARM/COLD，冷热分离）。能讲出EMR存储成本优化35%的实际案例和量化数字，面试官会觉得你有成本意识和运维经验。
下一篇聊YARN资源调度：提交了一个Spark作业等了10分钟才开始跑——YARN的资源分配是怎么回事？
你们HDFS的存储成本优化做了什么？用了纠删码吗？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长