Hadoop不是单个软件：HDFS、YARN、Spark等组件如何分工协作

很多人第一次听到"Hadoop"这个词，可能以为它只是一个软件，装好之后就能"处理大数据"。但真正在真实环境里跑过之后你会发现，Apache Hadoop 更像是一套家族体系，里面每一个成员都只负责一件具体的事：有的管数据存哪，有的管怎么算，有的管资源怎么分，有的管任务几点跑。它们单独拿出来可能很单调，合在一起才构成了完整的大数据存储、处理、调度与管理链路。

这篇文章我不打算念一遍官方文档，而是以实际使用者的视角，把 Hadoop 生态里最常见的那些工具挨个拆开，讲清楚每个工具的职责边界、它们为什么要这么设计，以及它们之间是怎么配合工作的。如果你刚接触大数据，或者已经被各种名词绕晕，这部分内容应该能帮你把整张地图拼起来。

1. 先搞清楚一件事：Hadoop 不是一个软件，而是一套"分工协议"

在本世纪初，处理包括海量数据的主要方式还是靠单机扩容——加内存、加硬盘、换更强的 CPU。但当数据量到了 PB 级，单机的硬件成本、扩展天花板都撑不住了。当时业界慢慢形成的共识是：与其造一台无比昂贵的巨型服务器，不如把大量普通服务器组成集群，共同分担存储和计算。Hadoop 的各个组件，就是围绕这一思路，把"分布式"这个宏大概念拆成了几个可以独立演进的实际问题。

分布式系统最核心的难题有三个：数据放哪里、怎么放多份才不丢；计算怎么拆成小任务并行跑；任务多了之后资源怎么分、怎么调度。Hadoop 生态所有的工具基本都是围绕这三大问题展开的。HDFS 解决存储可靠性，MapReduce/Spark 解决计算的并行化，YARN 解决集群资源管理。至于 Hive、HBase、Flume、Zookeeper 这些大家经常听到的名字，更像是"辅助工种"——它们让整个体系更好用、更自动、更贴近实际业务。

有一个非常容易踩的思维误区：很多人以为 HDFS 就是 Hadoop，或者 Hadoop 就是 HDFS 加 MapReduce。实际上，HDFS 只是存储层，MapReduce 也只是众多计算引擎之一。如今我们跑离线任务，更常用的是 Spark、Tez 甚至 Flink，资源调度大多走 YARN，数据仓库可能用 Hive。整个分工关系可以简单描述为：存储层负责"把数据存住"，计算引擎负责"从存储里把数据读出来算完"，资源管理器负责"给计算引擎提供干活的人（容器）"，而外围工具则负责"数据怎么进、怎么出、怎么被组织、按什么节奏跑"。

这样的分层设计有一个非常明显的好处：每一层都可以独立升级。存储层不需要关心上层用的是 MapReduce 还是 Spark；调度层也不需要关心运行的任务是 SQL 查询还是机器学习训练。只要接口一致，各层之间就能自由组合。这也是为什么这么多年来 Hadoop 的核心组件虽然不断被吐槽"重"、"慢"、"复杂"，却依然在很多企业的数据架构里占据重要位置——它不是某一个工具厉害，而是这套角色的分离设计大大提高了系统的可维护性和可演进性。

2. HDFS：海量数据的"地基"，它到底存了什么、怎么存

HDFS（Hadoop Distributed File System）是整个生态的基石。它的设计灵感其实来源于 Google 的 GFS（Google File System），核心目标非常明确：在一堆廉价的普通服务器上，保存海量的大文件，并且能容忍日常的设备故障。

2.1 数据块与副本机制

HDFS 会把一个大文件切分成若干固定大小的块（默认是 128MB），然后分散存到集群中不同的节点上。每个块默认会保存 3 份副本，分布在不同的机器、甚至不同的机架上。这样的好处是：如果某台机器硬盘坏了或直接宕机，系统依然能从其他副本读取数据，不需要人工介入。副本机制本质上是用"空间换可靠性"——为了不丢数据，宁可多占几倍的存储。

我在使用中早就习惯一个事实：在任何分布式系统中，"故障"不是小概率事件，而是每天都在发生的常态。三个副本的意义不只是数据不丢，还在于读的时候可以同时从多台机器取数据，提升吞吐量。一个 1TB 的文件，有 8 个 block 分布在不同节点上，客户端可以并行从多个节点拉取，速度远大于单机硬盘顺序读取。

2.2 NameNode 和 DataNode 的职责划分

HDFS 采用 master/slave 架构。DataNode 负责真正存储数据块，负责本机磁盘上的读写；NameNode 则只负责元数据——记录每个文件由哪些块组成、每个块存放在哪些 DataNode 上。这两个角色相当于图书馆里的"目录管理员"和"书库管理员"：NameNode 只知道书在哪、叫什么，DataNode 才知道书架上具体的书页内容。

因为客户端读写需要先获取元数据，NameNode 的压力直接影响集群性能。如果读写非常频繁，NameNode 容易成为瓶颈。还有一个常见问题是"小文件过多"。小文件太多的时候，NameNode 内存里要维护海量文件的元数据，几百个 G 的文件很容易把 NameNode 内存吃满。我在生产环境一般会建议：尽量把小块合并成大文件，或用 HBase 这类面向随机读写的系统来处理海量小文件，而不是直接把小文件塞进 HDFS。

2.3 高可用与容错

早期 HDFS 只有一个 NameNode，一旦这个节点挂了，整个集群就只读不写，完全是单点故障。后来社区引入了 NameNode HA（高可用）机制：两个 NameNode 一个 Active、一个 Standby，通过 JournalNode 共享元数据变更日志，再靠 Zookeeper 做故障自动切换。所以现实集群中，Zookeeper 往往就在 HDFS 高可用的背后默默工作。

不过要特别提醒：NameNode 不等于数据库。它的元数据变更非常频繁，不适合用传统文件系统加锁的方式存储。JournalNode 数量的布局，以及 QJM（Quorum Journal Manager）的机制，都是为了保证日志写入不丢、不重。这部分理解起来费点劲，但如果你需要自己搭建一套稳定的 HDFS，至少要明白 NameNode 日志的写链路，因为一旦日志损坏，恢复的成本会让你欲哭无泪。

2.4 HDFS 的边界：它不适合什么

HDFS 设计出来就是给"流式读取大文件"的批处理场景用的，不是给在线业务当数据库用的。它有很明显的短板：

• 随机修改文件内容能力很差，更不要说按行 update
• 延迟比较高，单次写请求需要多个节点确认，毫秒级响应非常困难
• 并发写入同一个文件限制严格，通常一个文件同时只有一个写者

所以在真实架构中，HDFS 很少直接暴露给在线服务，而是作为"后台数据底座"使用。需要低延迟随机读写时，上层往往挂一个 HBase；需要实时查询时，往往会从 HDFS 把数据抽取到专用系统。理解了它的边界，你才能明白为什么 Hadoop 生态还需要那么多其他工具去填这些坑。

3. 执行引擎的接力赛：MapReduce、Tez 与 Spark 的取舍

Hadoop 早期的计算引擎是 MapReduce。它的思想非常经典：把任务拆成 Map 阶段和 Reduce 阶段。Map 阶段读取输入数据，产出 key-value 中间结果；Shuffle 阶段按 key 排序归并，并传递到 Reduce 节点；Reduce 阶段再把中间结果汇总成最终输出。整个过程类似"先分再合"，天然适合大规模分布式数据处理。

3.1 MapReduce 为什么被吐槽

MapReduce 最大的问题是中间结果要落盘。换句话说，Map 和 Reduce 之间的数据交换必须经过磁盘，尤其是 shuffle 阶段数据量巨大时，大量时间浪费在磁盘 I/O 上。对离线批处理还算可以接受，但对交互式查询、机器学习迭代等场景就太慢了。每次迭代都要重新读数据、重新写磁盘，效率非常难看。

另外一个痛点是编程模型太"啰嗦"。要统计一个词频，你得写一个 Mapper 类、一个 Reducer 类，再写好配置，非常繁琐。虽然可以用 Hive SQL 掩盖底层，但跑出来的任务本质还是 MapReduce，速度上限就摆在那里。

3.2 Tez 和 Spark 怎么解决这个问题

Tez 的解决思路是消除不必要的中间落盘。MapReduce 把任务切割成多个独立阶段，阶段之间靠磁盘隔开；Tez 则把一个复杂作业描述成一张 DAG（有向无环图），节点之间可以直接用内存管道传递数据，同时允许 Map 和 Reduce 一类的操作以更灵活的拓扑结构组合起来。因此，Hive on Tez 比 Hive on MapReduce 明显更快，早期很多团队用这个优化查速。

Spark 的解决思路更进一步。它提出了 RDD（弹性分布式数据集）概念，将数据抽象成可分区、可并行处理、可缓存的分布式集合。Spark 会把计算过程同样组织成 DAG，但各个步骤之间会尽量在内存中完成，同时支持 cache、broadcast、accumulator 等机制，特别适合需要反复迭代访问同一份数据的计算任务，例如机器学习训练、图计算、交互式分析。

3.3 什么时候选哪个引擎

从我的实践经验看，做一个"唯一定论"是不现实的。决定选择哪种引擎时需要考虑：

• 数据量级、数据结构
• 任务类型（离线批处理、SQL 查询、实时流、迭代计算）
• 集群拥有的资源、网络、内存
• 团队的开发语言和技术栈

下面粗略列一个对比表，方便大伙参考：

实际生产里，很多团队选择"并存"：核心的、要求稳定的批任务可能跑 MapReduce 或者 Hive on Tez；要求快速的 ETL、报表任务交给 Spark；偶尔的有状态流计算，则另起一套流引擎。不要被技术潮流绑架，适合团队维护能力的才是好的架构。

4. YARN：集群资源的"调度室"，任务都从这里起飞

计算引擎有了，但如果多个任务同时提交，资源怎么分配？谁先跑、谁可以等？如果某个任务贪心地把集群占满，其他任务就只能饿死。这就引出了 YARN（Yet Another Resource Negotiator）——Hadoop 生态里的资源管理与任务调度层。

4.1 YARN 的基本架构

YARN 的核心组件是 ResourceManager（RM）和 NodeManager（NM）。RM 是全局的资源仲裁者，维护整个集群的资源使用情况；NM 部署在每一台计算节点上，负责管理本机可用的 CPU、内存等资源，并向 RM 汇报。

真正跑任务时，YARN 会为每个应用启动一个 ApplicationMaster（AM）。AM 负责向 RM 申请容器（Container），然后在 NodeManager 分配的容器里向计算任务或其他执行任务启动和监控。简言之，RM 是"大总管"，AM 是"现场项目经理"，NM 是"包工队队长"。这层设计非常重要，因为它解耦了"资源管理"和"任务执行"，使得 MapReduce、Spark、Flink 等框架都能很方便地接入 YARN。

4.2 调度器的选择与坑

YARN 提供了多种调度策略：

• FIFO（先进先出）：实现简单，但若队头的长任务占满资源，后续任务就得等半天，不实用。
• Capacity Scheduler（容量调度器）：把集群资源划分为多个队列，每个队列保证一定份额，防止单个组织或应用把资源吃光。很多生产集群默认用这个。
• Fair Scheduler（公平调度器）：让所有任务动态均分资源。当新任务提交时，可以抢占正在运行的低优先级任务资源，更灵活。

我遇到过最常见的问题就是，某团队写了一个 Spark SQL 任务，由于配置了很高的 executor 内存，加上存在数据倾斜，执行时间被拉得非常久，整个队列的其他任务全部被拖慢。后来给队列配置了严格的上限并开启抢占，才缓解。说白了，调度策略本身没有绝对的好坏，关键在于你是否理解业务里的资源竞争关系，并基于此去做隔离和限制。另外，YARN 的资源模型现在也支持 GPU，神经网络训练任务也可以纳入统一调度，新增功能不少，但内核思想没有变。

4.3 YARN 和 HDFS 为什么要分开

知名的一句话是"Hadoop 的存储和计算可以拆开"。在 YARN 出现之前，MapReduce 是直接依赖 HDFS 文件块的分布来决定任务放在哪个节点执行，也就是我们说的"计算移动数据"。后来 YARN 引入了通用资源调度，让计算框架可以直接在 YARN 上运行，不需要每套框架都自己实现一套资源管理。于是，存储层和计算层在物理上分离，扩展和调度都更灵活。你可以让一个计算集群只负责跑 Spark，数据则存在另一套 HDFS 集群里；生产中也常见 HDFS 和 YARN 部署在同一批节点上，用于节省网络带宽。

在部署时，我建议仔细考虑"eager"和"lazy"的服务布局，存储与计算分离到底利弊如何，取决于你业务里数据量、网络带宽与成本模型。没有放之四海皆准的答案，但明确"哪些服务跑在同一机架/集群"很重要，不然数据本地性会很差，大量时间耗在跨机架传输。

5. 生态里的"辅助角色"：从数据搬运、数仓到任务编排，一个都不能少

只靠 HDFS、YARN、计算引擎这三层，处理流程仍然很难落地。因为实际业务里数据产生的形态、使用场景都不一样：日志是源源不断的，关系库的数据需要导入，分析师想写 SQL 而不想写 Java，值班的人需要知道任务到底跑没跑成功。于是 Hadoop 生态里衍生出一大批"辅助角色"，它们就像是这个家族的管家、翻译官和司机。

5.1 Flume 与 Kafka：数据如何进入存储层

Flume 是一个分布式的日志采集器，设计初衷是"把日志文件从服务器收集到 HDFS"或其他存储系统。Flume 用 Source、Channel、Sink 三种抽象组件来描述一条数据管道的三个环节，搭配起来可以灵活组织。适合在业务机器上安装一个 Agent，定期监控日志目录，把新增数据追加写入 HDFS。

Kafka 更像是一个"中间蓄水池"。它本身不负责数据落地到 HDFS，而是靠高吞吐的分布式消息队列，把数据生产者和消费者彻底解耦。比如多个应用产生的日志先全部写到一个 Kafka topic，再由一个单独的消费程序决定如何落库。这样即使某个下游系统挂了，数据也不会丢，系统恢复后再消费即可。生产上经常把 Kafka 和 Flume 串联起来：Flume 采集到日志，先送进 Kafka，再由另一个 Flume（或消费者）从 Kafka 转存到 HDFS。这套管道能有效避免突发流量直接把 HDFS 写爆。

5.2 Hive 与 HBase：一个管"分析查"，一个管"实时查"

Hive 的概念很简单：把 HDFS 上的数据映射成"表"，然后用 SQL 去查。这里的 SQL 会被翻译成底层的计算任务交给 MapReduce/Tez/Spark 去执行。Hive 不负责存储数据，它只管"元数据 + 查询翻译"。一套 Hive 表定义，能够大大降低数据分析的门槛，也让 Hadoop 集群真正进入"数据仓库"层面。实际使用中，分区表、分桶表、ORC/Parquet 列式存储这几项优化能带来很大的性能提升，新手应优先掌握。

HBase 则是完全不同的定位。它是一个面向列的 NoSQL 数据库，底层数据依然存储在 HDFS 上，但通过额外索引和内存缓存机制，提供了毫秒级的按 rowkey 随机读写能力。可以用一个类比来理解：HDFS 像大型仓库，所有的货箱按顺序摆放，你要一件件翻才能找到想要的；HBase 在这个仓库上建了一座高速自动检索的货架，它能根据 key 快速定位到你想要的那件货。因此，HBase 适合那些"需要数据能重新读、又要支持高并发短查询"的场景。性能和可用性直接依赖 rowkey 的设计，这是 HBase 使用的基础能力。

5.3 Sqoop 与数据迁移

Sqoop 是传统关系数据库与 Hadoop 之间的"搬运工"。它可以把 MySQL/Oracle 里的整表数据导入到 HDFS/Hive/HBase，也可以把 HDFS 上的结果导回关系库。许多数据仓库的初始化、增量同步，早期就是用 Sqoop 做的。当然，随着技术发展，又出现了 DataX、Flink CDC 等更强的同步工具。但 Sqoop 的作用历史看起来还是值得了解的，尤其在老一套 Hive 数仓体系中，它的痕迹到处可见。

5.4 Oozie/Airflow 与任务的定时调度

离线数仓里最常见的动作就是"凌晨跑任务"。一个完整流程可能是：凌晨 1 点把昨天的日志从 Kafka 拉下来，2 点 Hive 做清洗，3 点 Spark 算指标，4 点把结果回写到 HBase。这种多阶段任务必须由一个工作流调度系统串起来。Oozie 是 Hadoop 生态里经典的调度引擎，支持定义有向无环图，设定定时触发和失败重试；Airflow 是 Python 社区开发的通用任务编排工具，因为编程灵活、UI 友好，现在也越来越多团队使用。调度层虽然不是关键技术，但少了它整个系统基本跑不起来。按时任务、失败通知、依赖关系，这些细节直接影响数据平台可用性。

5.5 Zookeeper 与集群协调

Zookeeper 的作用看起来不起眼，却常常是集群的"定海神针"。它提供分布式命名、配置管理、分布式锁和 Leader 选举等基础服务。HDFS 的 NameNode HA、YARN 的 ResourceManager HA、HBase 的 HMaster 选举都依赖它。很多新手写分布式应用时也会拿 Zookeeper 来选主或保存配置。它暴露给使用者的模型就像一个共享的、支持有序节点的文件系统，通过重重机制在多个节点之间保持一致性。如果 Zookeeper 部署不当，比如节点只有一台，那它本身就是单点，后续所有依赖它的服务都会遭殃。

我用一个表格整理一下这些角色的关系，方便后面串起来：

6. 一个典型的离线分析平台，这些工具是怎么串起来干活的

理论讲得再多，不如看一条真实链路。假设我们要建一个"用户行为日志分析平台"，每天的日志量大概在 20 TB 左右。原始数据来源是手机 App 和 Web 端的埋点日志。

第一步，日志从业务机器直接写入本地目录，由 Flume Agent 采集并发送到 Kafka 的 topic。Kafka 的角色非常重要：线上流量随时会波动，白天高峰期可能每小时产生几亿条日志，如果把数据直接塞进 HDFS，HDFS 会被大量小文件打爆，NameNode 压力骤升，还会拖累计算任务。先放进 Kafka，它既能暂时缓冲数据，又能在不同消费系统之间做广播——既能往 HDFS 写，另一份还能交给实时计算引擎做流处理。

第二步，凌晨 0 点，Kafka 的数据由离线消费者批量消费，写入 HDFS 的原始日志目录。这里写入的时候要特别小心小文件问题，我通常建议按天分区，并且每个 partition 的文件尽量大一些，控制在 200MB 以上，减少 NameNode 的元数据压力。

第三步，Hive 侧建一张外部表指向 HDFS 的原始数据目录，然后执行 SQL 做数据清洗。比如过滤爬虫、解析字段、剔除异常数据，清洗完的结果写到另一个 Hive 表（ORC 存储、按日期分区）。如果想跑得快，可以选择 Hive on Tez 或 Hive on Spark 执行，而不是老式 MapReduce，具体取决于你集群里配置的引擎。

第四步，业务指标计算用 Spark 来完成。读取清洗后的 Hive 表，通过 Spark SQL 聚合计算用户的活跃度、转化漏斗、路径分析等，得到的结果一部分写回 HDFS 供离线报表使用，另一部分写入 HBase，方便线上产品查询。写回 HDFS 时同样要注意文件数和文件大小，很多新手在这一步突然产生海量小文件，导致后面再读的时候每个 task 只处理几十 KB，性能非常差。

第五步，整个任务链路由 Oozie 编排。Oozie 的 coordinator 设置每天 0:30 启动离线入库，依赖前一天的日志是否已经写全；清洗任务依赖入库完成；指标计算依赖清洗完成。每一个任务都有失败重试逻辑。为了方便日常运维，每一步还会在表里写运行日志，失败时发送告警邮件。在实际操作中，我们团队非常看重"任务依赖关系"的正确配置，因为凌晨调度是连锁反应，一个上游任务延迟会导致下游集体排队，假如没有做好超时和重试控制，早上七点前报表出不来就全是告警声。

第六步，数仓任务上线跑通之后，还要有一套集群管理监控的入口，比如用开源的 Ambari 或商业发行版的管理界面来部署和监控集群的磁盘使用率、CPU 负载、YARN 队列里的任务数。监控才是真实运维中最耗时的部分。我见过太多集群平时跑得好好的，一旦磁盘被写满、队列任务堆积，就会出现各种难以排查的"重、慢、错"问题。

把这条链路对照前面提到的角色分工看，就会很直观：HDFS 负责存，Hive 负责把数据组织成表和 SQL，Spark 负责大规模计算，YARN 负责给 Spark 分配资源，Kafka/Flume 负责数据搬运，Oozie 负责定时与依赖，Zookeeper 在背后保证多节点的协调和高可用。任何一个环节掉链子，整个链路的产出都会延迟。因此，这种架构的运维挑战恰恰在于"协作"，而不是单个组件的性能。

7. 一些实操中的体会，可能对你有用

最后分享几个我踩坑后的个人体会，不写大而全的总结，就说真实感受。

第一，不要一开始就上全套生态。刚接触 Hadoop 时，大家都容易有个冲动："反正都开源，全部装上。"结果就是集群里塞满了你根本用不上的服务，内存被白白吃掉，运维复杂度直线上升。我自己经手的项目通常从"HDFS + YARN + Hive + 一套调度 + Zookeeper"起步，先解决存储和离线计算问题，等到确实需要低延迟随机读写了再引入 HBase，需要日志缓冲了再引入 Kafka。每加一个组件，都要问清楚它解决了什么不可替代的问题，避免为凑技术栈而上技术。

第二，监控比调优更重要。Hadoop 生态组件多、指标也多，磁盘容量、DataNode 存活数、NameNode 堆内存、YARN 队列积压、Hive 元数据连接数，这些都是平时要盯的指标。我记得有一年某集群频繁出现凌晨任务大面积延迟，最后排查出来的原因竟然是某台机器磁盘慢 IO，写 block 延迟持续飙高，但 HDFS 明明还能继续工作，只有出现大量慢节点才拖垮整体。没有监控，这种问题基本要靠肉眼猜，难度极大。

第三，数据倾斜和文件数是两个永远绕不开的话题。无论是 MapReduce 还是 Spark，数据倾斜都会让某一个任务一下子跑几个小时，其他任务早已结束，整个应用被拖垮。底层原因不外乎 key 分布不均，通常的处理手段有加盐、两阶段聚合、动态调整并行度等。文件数过多则主要毒害后续读取和 NameNode 元数据。不要在跑完任务一瞬间觉得"成功了"，回头看输出目录是不是又被生成了几千个几百 KB 的小文件。养成习惯：构建数据时尽量按需合并或重分区，数据处理链路永远比某一个单独组件更重要。

第四，组件版本必须认真匹配，别只看新版本好。Hadoop 生态的版本号常常让新手抓狂，例如 Hadoop 2.x 与 3.x 的 YARN 协议、Hive 的引擎版本、Spark 对 Hadoop 客户端的兼容性都有细微差别。我遇到过的坑包括 Hive 1.x 和 Spark 3.x 适配时缺了某种包导致 SQL 直接失败，以及老集群升级时 NameNode 镜像格式不兼容。所以生产环境尽量选一个经过测试的组合，例如某个发行版里捆绑的组件的版本组合是经过 QA 的，虽然不一定最新，但稳定性优先。

第五，权限和安全一定要尽早设计。很多集群搭建初期因为图省事，开着免密登录、开了默认端口、没有 Kerberos。等集群规模大了、用户多起来，再做权限整改会非常痛苦，而且涉及面很广。较好的做法是：集群从第一天起就明确用户和组、设置目录权限、限制 YARN 队列和 HDFS 配额。HDFS 的安全模式、Kerberos 认证、Ranger/Sentry 授权体系，最好在规划阶段就安排进去，不要等出了问题再补。

说到底，Hadoop 生态的繁盛恰恰是建立在"各司其职"四个字上。每个工具都不是万能的，但组合起来后，你可以用普通服务器搭建起一套可靠的大数据体系。对新手来说，不必急于把每一个组件都学会，抓住 HDFS 的数据存储、YARN 的资源调度、以及某个计算引擎的使用，再根据业务场景慢慢补外围工具，就能在真实项目里逐渐游刃有余。