Hadoop 版本演进
概述
接触大数据集群，绕不开版本话题：Apache Hadoop 1/2/3 的架构差异、CDH/HDP 等商业发行版的合并史、以及云原生形态的兴起。本文梳理版本演进脉络，帮助在选型与迁移时做出判断。
一、Apache Hadoop 版本演进
1.1 Hadoop 1.x：奠基
| 特性 | 说明 |
|---|---|
| HDFS | 单 NameNode，元数据全内存，无 HA |
| MapReduce | 集群资源管理由 JobTracker/TaskTracker 承担 |
| 局限 | JobTracker 单点 + 吞吐瓶颈；资源管理耦合在 MR 内部 |
Hadoop 1.x 的 JobTracker 同时管调度与任务跟踪，规模一大就成瓶颈，直接催生了 YARN。
1.2 Hadoop 2.x：资源解耦
| 特性 | 说明 |
|---|---|
| YARN | 资源管理独立成层，MR 只是 YARN 上的一个应用框架 |
| HDFS HA | NameNode 主备（QJM + ZKFC），元数据可用性大幅提升 |
| 多引擎 | Spark/Flink/Tez 都能跑在 YARN 上 |
| Federation | 多 NameNode 联邦，突破单点元数据上限 |
2.x 是生产部署最广的版本基线，绝大多数老集群基于它。
1.3 Hadoop 3.x：现代能力
| 特性 | 说明 |
|---|---|
| 纠删码（Erasure Coding） | RS-6-3 等策略，存储利用率从 3 倍降到约 1.5 倍 |
| 多 NameNode 联邦 | 联邦架构完善，支持独立 ZKFC 集群 |
| 容器化支持 | 原生支持 Docker 容器运行任务 |
| 性能改进 | 缩短 RPC 协议、部分读放大优化 |
| Java 8+ | 不再支持 Java 7 |
3.x 修复了 2.x 的不少性能与可用性短板，新集群应优先考虑。
1.4 版本对比表
| 维度 | 1.x | 2.x | 3.x |
|---|---|---|---|
| 资源管理 | JobTracker | YARN | YARN |
| NameNode 高可用 | 无 | 主备 HA | HA + 多联邦 |
| 存储效率 | 3 副本 | 3 副本 | 3 副本 / 纠删码 |
| 容器化 | 无 | 有限 | 原生支持 |
| 适用 | 淘汰 | 存量 | 新建 |
二、商业发行版合并史：CDH / HDP / Cloudera → CDP
2.1 为什么需要发行版
Apache 各组件版本独立演进、互相兼容性靠社区自行验证。商业发行版做版本对齐、补丁、认证、管理工具，让企业开箱即用。
2.2 三大发行版与合并
| 发行版 | 主导方 | 特点 |
|---|---|---|
| CDH | Cloudera | 部署成熟（Cloudera Manager），Hive/Impala 深度优化 |
| HDP | Hortonworks | 开源度最高（Apache 原生 + Ambari），社区活跃 |
| MapR | MapR | 自研 MapR-FS，性能强但生态封闭 |
2019 年 Cloudera 与 Hortonworks 合并，统一路线为 CDP（Cloudera Data Platform）：
CDH + HDP → 合并 → CDP（Cloudera Data Platform）
├── CDP Private Cloud Base（本地私有云）
├── CDP Public Cloud（公有云）
└── CDP Data Center2.3 CDP 的技术要点
- 统一在 Cloudera Manager 下管理，Ambari 逐步退役。
- 默认组件栈：HDFS 3.x + YARN + Hive/Tez + Spark + Kafka + HBase + Flink。
- 引入混合云/多云能力：本地与公有云（AWS/Azure/GCP）统一数据平台。
- 数据治理整合：Ranger（安全）+ Atlas（元数据）作为内置组件。
2.4 发行版选型
| 场景 | 建议 |
|---|---|
| 新项目、要求商用支持 | CDP（Cloudera） |
| 开源可控、社区维护 | Apache 原生组件自行部署 |
| 已有 Ambari 存量 | 评估迁移到 CDP，或保留 HDP 维护期 |
| 中小规模 | 考虑云厂商托管（EMR/Databricks） |
三、云原生 Hadoop
3.1 形态演进
传统自建集群 → 云厂商托管（EMR）→ 存算分离（对象存储 + 弹性计算）→ Serverless| 形态 | 代表 | 特点 |
|---|---|---|
| 托管集群 | AWS EMR、阿里云 E-MapReduce | 快速开通、按小时计费、组件预装 |
| 存算分离 | S3/OSS + HDFS 客户端适配 | 存储与计算独立扩缩容，节省成本 |
| 对象存储上的 HDFS | s3a/oss 文件系统、JuiceFS | 通过 HDFS 兼容层读写对象存储 |
3.2 关键适配技术
- s3a / oss 连接器：把 Hive/Spark 的 HDFS 路径直接指到对象存储。
- 元数据服务：对象存储无目录语义，靠 Hive Metastore 或 Hudi/Iceberg 管理结构。
- 计算弹性：按需拉起临时集群跑批，跑完释放，数据留在对象存储。
- 成本模型：把存储成本（对象存储）与计算成本（弹性实例）解耦，低频数据更省钱。
3.3 选型判断
| 因素 | 自建 | 云原生 |
|---|---|---|
| 初始成本 | 高（硬件+运维） | 低（按需付费） |
| 长期成本 | 规模化后低 | 常驻负载偏高 |
| 弹性 | 差 | 好 |
| 可控性 | 高 | 受云厂商约束 |
| 适合 | 大厂、数据合规本地化 | 中小团队、业务波动大 |
四、迁移与升级建议
4.1 升级评估清单
- 检查依赖组件兼容性（Hive/Spark/Kafka 与 Hadoop 版本矩阵）。
- 验证配置项变更：3.x 部分参数改名，需回归
core-site.xml等。 - 备份元数据（FsImage/Edits、Hive Metastore 数据库）。
- 小流量灰度：先升级测试集群，跑对账与基准。
4.2 常见坑
| 坑 | 说明 |
|---|---|
| 版本混跑 | HDFS 客户端与服务端版本不匹配导致协议异常 |
| 纠删码误用 | 对热点数据开 EC 反而拖慢读取 |
| 发行版停更 | 未维护的 CDH/HDP 版本存在已知漏洞无补丁 |
| 云上误配 | 对象存储权限/加密配置错误导致数据泄露 |
总结定位
版本演进的主线是资源解耦（YARN）、可用性（HA）、存储效率（EC）与部署形态（云原生）。选型的本质是权衡：自建控成本，商业版控风险，云上控弹性。