7.1 云计算融合与新兴技术结合

7.1 云计算融合与新兴技术结合

本节摘要：云计算与新兴技术对 Hadoop 的改造集中在三处：存储层用对象存储重构成本模型、计算层用内存引擎重写 Shuffle 的代价假设、时间线上用流处理压缩数据延迟。本节逐项算清这三笔账，并审视云原生与容器化部署对集群形态的影响。

存储账：HDFS 还是对象存储

第 6 章的规划账里有几项被默认接受的成本：机器摊销、机房电力、三副本的 3 倍冗余、以及备份的额外存储。云上的对象存储（S3、OSS、GCS）把这笔账改写成另一种形态：按量付费、跨多可用区冗余内建、11 个 9 的持久性、零运维——2.4 节操心的高可用与 6.4 节操心的备份，在对象存储那里是服务方的责任。

但换轨不是免费的。对象存储与 HDFS 的语义差异直接冲击前几章的机制：

"无本地性"是最深的一条。第 3 章整章建立在"计算去找数据"上；对象存储上每次读都是网络读，Map 任务的节点本地性概念消失。好在计算存储分离后网络成了唯一路径，云内网带宽够大，加上缓存层（Alluxio 类）与每次请求拉更大批次，实践中吞吐反而常常更好。而"rename 非原子"动摇的是 5.1 节 Hive 的提交协议与 5.5 节 _SUCCESS 握手——这正是数据湖表格式（Iceberg、Hudi、Delta）兴起的直接动因：它们用清单文件与快照机制把"原子提交"重新造了出来。

云厂商还提供 HDFS 托管服务（EMRFS、云 HDFS）兼容这条过渡路线：数据放对象存储、通过兼容层访问，存量作业少改。演进判断很实际：增量数据优先落对象存储，存量 HDFS 逐步归档迁移，计算节点全部 ephemeral 化。

引擎账：MapReduce 之外的执行层

第 3 章逐阶段拆过 Shuffle 的代价：每个作业把中间结果落盘两次（Map 端与 Reduce 端），多阶段作业（如 Hive 的复杂分析）每个阶段之间还要写 HDFS 再读回来。Spark 与 Tez 的改造正对着这两处：

• DAG 执行引擎：多阶段计算不再"每阶段一个作业、中间结果落 HDFS"，而是把整个查询编译成一张有向无环图，阶段间中间结果尽量留在内存或本地，一个应用跑完全图。Hive on Tez 相对 Hive on MR 的提速，一大半来自免掉阶段间落盘。
• 内存 Shuffle：Spark 默认把中间分区留在内存（放不下才溢写），配合更紧凑的编码，同一作业的搬运量级下降。第 3 章的 Combiner、压缩、倾斜加盐三板斧在 Spark 里依然有对应物（reduce 端预聚合、shuffle 压缩、加盐重分区）——优化思想是延续的，只是默认更激进。

要害的判断：MapReduce 并没有"错"，它是把内存当缓存、磁盘当信道的保守设计，为不可靠集群时代而生。硬件内存变便宜、集群稳定度提高后，把中间数据放内存的风险收益比反转了。今天新写批处理管道没有人再选 MR API，但它在各引擎中仍作为稳定兜底存在（5.2 节 Pig 的收缩同理——生态位被 Spark 吸收）。

时间账：流批一体的拉扯

数据旅程的"延迟"在前六章里是明码标价的：Flume 收进来的日志要等 Hive 分区挂载、Oozie 到点触发才能被查询，T+1 到 T+5 分钟是常态。流处理引擎（Kafka Streams、Flink）把旅程的时间线压缩到秒级：数据产生即在内存中处理。Kappa 与 Lambda 架构是两种缝合方案——前者激进（全部走流，批只是流的回放），后者务实（流保实时、批保准确，双链路维护成本高）。

流批一体（Flink 的批流统一、Spark Structured Streaming）的目标是同一份代码两条时间线。落到 Hadoop 存量平台的现实：T+1 数仓仍是主流（成本、正确性、审计友好），实时层只加在最痛的几个场景（风控、推荐召回、大促监控）。第 5 章的 Oozie 编排在流世界里对应 Flink SQL 的管道与 Kafka Connect，但"数据就绪触发"的思想没变。

形态账：云原生与容器化

Kerberos 化的静态集群在云原生时代显得笨重。趋势是计算节点容器化、存储外包：Spark on Kubernetes 直接向 K8s 申请 Pod 跑执行器，替代 YARN 的容器分配（4.1 节的四角色在 K8s 里由调度器与算子重演）；HDFS 若仍在，则收敛为专职存储池或干脆被对象存储加数据湖表格式替代。注意这不等于"YARN 无用"——大规模多租户批调度上 YARN 依然高效，K8s 与 YARN 的并存与互操作（Yunikorn 类调度器）是当下真实状态。

一个综合案例：老平台的三年演进

把四笔账放到同一个真实语境里看。某中型电商 2023 年的自建平台：80 台机器的 HDFS（1.2 PB 有效数据）、Hive on MR 夜批管道、Oozie 调度、本地机房。第一年做了两件事：新数据双写对象存储（出口上云），Oozie 管道里最高频的三十个作业改写为 Hive on Tez——不动表定义，只换引擎，夜批窗口从五小时压到两小时。第二年：实时层给风控与大促看板单独建 Flink 链路（只覆盖三个最痛场景），T+1 数仓原样保留；HDFS 冷分区（两年前数据）转纠删码归档，裸容量省出三成。第三年：计算节点逐步迁 K8s，YARN 保留给重批处理。三年下来没有一个"大爆炸式迁移"，每一步都有回退能力，团队也没有一次性重学的断层——这正是 7.2 节演进四步的实证版本。反例同样常见：一步到位的"全面上云"项目因为出口流量费超预算、存量管道重写风险失控而中途搁浅，回到混合架构。差别不在技术判断，在于是否把每一笔账（存储、引擎、时间、形态）分开算、每步可停。

本节要点回顾

• 对象存储改写存储账：冗余与备份外包、按量付费，代价是失去本地性与原子 rename，数据湖表格式是补丁；
• DAG 与内存引擎重写 Shuffle 假设：阶段间不落盘、中间留内存，第 3 章的优化三板斧思想延续；
• 流批一体压缩旅程时间线，但 T+1 数仓在成本与审计上仍占主流，实时层按痛点加装；
• 云原生让计算节点 ephemeral 化，YARN 与 K8s 并存互操作是现状而非过渡；
• 三笔账（存储、引擎、时间）共同指向：分层理念延续，具体实现换代。

下一节把镜头从技术拉到生态：发行版兴衰背后的精选化逻辑，与诚实的挑战机会清单。