Hadoop 3：存储经济学与资源治理的范式转移

Hadoop 3 的工程意义，不在于“又加了一个版本号”，而在于它同时改写了 HDFS 的冗余成本公式与 YARN 的资源治理粒度。Hadoop 2 时代的三副本策略以 200% 的存储开销换取容错，在冷数据规模膨胀后成为沉重的成本负担；单点写入的 Timeline Server 和粗放的容器资源分配，则让多租户集群的隔离能力停留在“逻辑配额”层面。Hadoop 3 用纠删码把冗余降到 50%，用多 NameNode HA 消除元数据的 Active/Standby 二元约束，用 cgroup 把 CPU 与内存隔离下沉到内核，再用容器动态调整让资源规格不再与生命周期绑定。四条线共同指向一个变化：Hadoop 从“能存能算”的大数据底座，转向“存得便宜、算得干净”的资源运营平台。

HDFS 纠删码：目录级策略，不是集群级开关

纠删码的核心是用 Reed-Solomon 校验替代副本。RS-6-3-1024k 意味着每 6 个数据单元配 3 个校验单元，可容忍任意 3 个单元丢失，存储开销从三副本的 300% 降至 150%，同时需要至少 9 个 DataNode 承载一个完整条带。最容易被误用的地方在于：纠删码是目录级策略，只对设置之后新建的文件生效，已有文件和移入该目录的旧文件不会自动转码。正确的操作顺序是先启用策略、再在目标目录上绑定、最后用新文件做金丝雀验证。

# 1. 确认策略可用，并启用 RS-6-3-1024k
hdfs ec -listPolicies
hdfs ec -enablePolicy -policy RS-6-3-1024k

# 2. 创建窄范围目标目录并绑定策略
hdfs dfs -mkdir -p /warehouse/cold-events
hdfs ec -setPolicy -path /warehouse/cold-events -policy RS-6-3-1024k

# 3. 写入新文件，验证文件级实际生效策略
hdfs dfs -put canary.txt /warehouse/cold-events/
hdfs ec -getPolicy -path /warehouse/cold-events/canary.txt

-getPolicy 作用于文件路径而非目录，才能证明新文件真正拿到了纠删码布局；目录级查询可能返回继承的“有效策略”，掩盖旧文件仍为三副本的事实。纠删码适合冷数据、归档日志、历史分区，不适合小文件密集或写入后频繁随机读的场景——条带的跨机架重建会显著抬高客户端与 DataNode 的 CPU 开销。

多 NameNode HA：从“两个节点”到“可扩展的元数据平面”

Hadoop 2 的 HA 把 NameNode 限制在 Active/Standby 一对，Hadoop 3.0.0 起允许两个以上冗余 NameNode 以 Active/Passive 模式运行，Standby 从 JournalNode 组持续读取编辑日志并应用到命名空间，故障切换时先确保读完全部编辑再晋升。对于读密集型负载，Observer NameNode 可以分担元数据查询而不参与选举，相当于把元数据平面从“高可用”推进到“可水平扩展”。

<property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2,nn3</value>
</property>
<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://jn1:8485;jn2:8485;jn3:8485/mycluster</value>
</property>

配置层面没有额外的“魔法字段”，决策发生在JournalNode 的奇数部署和Observer 是否按读负载独立扩缩上。Observer 不改变写入路径，只扩大元数据读能力，因此不能替代 JournalNode 的法定人数要求。

YARN 资源治理：cgroup 下沉与容器动态调整

YARN 2 的资源隔离停留在“声明”层面：容器申请 4GB 内存，超用可能拖垮 NodeManager，CPU 争抢则完全交给操作系统调度。Hadoop 3 通过 cgroup 强制隔离把限制落到内核，CPU 和内存超用会被直接压制，而非事后补救。

<property>
  <name>yarn.nodemanager.linux-container-executor.cgroups.mount</name>
  <value>true</value>
</property>
<property>
  <name>yarn.nodemanager.linux-container-executor.cgroups.strict-resource-usage</name>
  <value>true</value>
</property>
<property>
  <name>yarn.nodemanager.resource.cpu-vcores</name>
  <value>32</value>
</property>

strict-resource-usage=true 是 cgroup 隔离真正生效的关键，关闭时超用仍然可能发生。与隔离配套的是容器资源动态调整：YARN-1197 引入的 AM-RM 协议变更允许在容器运行期间发起 increase/decrease 请求，Capacity Scheduler 与 NodeManager 协同变更 cgroup 限制，而不是杀掉容器重新分配。对长任务而言，这意味着流处理算子可以在负载峰值临时扩内存，避免了“预估峰值 + 长期超额占用”的粗放模式。

MapReduce 原生输出收集器：shuffle 密集作业的确定性收益

Hadoop 3 将 MapReduce 的 map 输出收集器下沉为原生实现，当 key/value 类型、比较器和 combiner 全部兼容时，MapTask 自动启用 NativeMapOutputCollector，在 shuffle 密集场景下性能提升约 30% 以上。启用方式是按作业指定收集器类，而非全局开关：

Job job = Job.getInstance(conf);
job.getConfiguration().set(
    "mapreduce.job.map.output.collector.class",
    "org.apache.hadoop.mapred.NativeMapOutputCollector"
);

原生收集器不是默认路径，canEnable() 会做兼容性检查，不满足条件时回退到 Java 实现。因此生产环境应当先在代表性 shuffle 作业上做 A/B 对比，确认增益后再写入作业模板，而不是集群级强推。

Hadoop 3 的四项核心演进共享同一个工程逻辑：把粗放的成本与治理模型替换为可量化、可分级、可动态调整的机制。纠删码让冗余从“统一三份”变为“按目录选择编码方案”，多 NameNode 让元数据可用性不再受限于二元拓扑，cgroup 与容器调整让资源隔离从“声明”变成“内核强制”，原生收集器让 shuffle 开销在兼容路径上被系统性削减。理解这些决策的适用边界——纠删码只对新文件生效、Observer 不替代 JournalNode 法定人数、原生收集器需要类型兼容——比记住特性清单更能决定集群在真实负载下的表现。