Hadoop生态：YARN、HDFS、Hive、Spark、HBase是如何协同工作的？

XR2025-06-182026-02-03

我想刚接触大数据领域的同学，常常被一堆名词砸晕：Hadoop、HDFS、YARN、Hive、Spark、HBase… 【东西也太多了吧】，个个看起来都很有用，但彼此之间到底是什么关系？跑一个作业的时候，数据和指令又是在它们之间如何流转的？

这篇文章不打算讲原理讲概念，我们就从一个开发者的角度，用一个好理解的类比，把这几位的关系捋清楚。

一个公司运作的类比

想象一下，我们开了一家大型的互联网公司，这家公司就是我们的 Hadoop集群。

HDFS (Hadoop Distributed File System)：这是公司的巨型中央仓库。所有部门的数据、资料、历史文档（也就是我们的数据，各种结构化或者半结构化的数据都可以）都堆在这里。这个仓库非常大，由很多个普通的货架（服务器硬盘）组成，但对外看起来是一个整体。它有个管理员（NameNode），知道每个资料（数据块）放在了哪个货架的哪个位置，还做了备份，防止资料丢失。它的特点是：存东西和整批取东西很方便，但你要是想在某个文件中间改个字，就太难了。
YARN (Yet Another Resource Negotiator)：这是公司的行政和人力资源部。它不负责具体的业务，但掌管着公司所有的资源：座位（CPU）、网络（内存）、会议室（计算槽位）等。哪个项目组（比如Spark或MapReduce作业）需要多少人手和地方来干活，都得向YARN申请。YARN批准，然后项目组才能拿到资源开工。它让公司的资源能够被不同项目组共享，大大提高了利用率。
计算引擎 (MapReduce/Spark)：这些就是公司里的各个项目组/业务线。它们是真正干活的。
- MapReduce：可以看作是公司的传统业务线。它做事手法很简单，只有 “分拣（Map）”和”汇总（Reduce）”两个固定步骤，处理海量数据没问题，但就是流程有点死板，速度也比较慢（中间结果要频繁写入仓库HDFS导致速度不行）
- Spark：这是新来的项目组。脑子快（基于内存计算），十八般武艺样样精通（支持批处理、流计算、机器学习等）。它干活效率极高，因为很多中间过程在内存上就完成了，不用总是走HDFS【磁盘】，比较类似flink。
Hive：这是公司的数据分析部。数据分析师们擅长用SQL写报表，但他们不了解生产线（MapReduce/Spark）上复杂的处理。于是Hive就诞生了，它提供了一个SQL查询的窗口。分析师把SQL报表需求给Hive，Hive就会把这个SQL翻译成生产线能听懂的”指令”（MapReduce或Spark任务），然后交给YARN去调度资源执行。所以，Hive本身不计算，它是个翻译官和任务提交工具。
HBase：这是公司的前台实时查询系统/档案室。当客服需要在一秒内查到某个客户的详细信息时，你总不能让数据分析部（Hive）去仓库（HDFS）里把所有客户数据翻一遍吧？那得等到猴年马月。HBase就是解决这个问题的，它也把数据存在HDFS大仓库里，但它用一种特殊的方式（列式存储、索引）整理了这些数据，让你能像查数据库一样，毫秒级地找到你想要的那一行或那几行数据。它专门负责实时、高并发的随机读写。

它们的关系图

用一张图来表示它们的关系，会更清晰：

  graph TD
    subgraph "Hadoop Cluster (基础设施)"
        YARN("YARN (资源调度中心)")
        HDFS("HDFS (统一数据存储)")
    end

    subgraph "Computing Engines (计算引擎)"
        Spark("Spark (快速通用计算)")
        MapReduce("MapReduce (传统批处理)")
    end

    subgraph "Applications (上层应用)"
        Hive("Hive (数据仓库/SQL接口)")
        HBase("HBase (NoSQL实时数据库)")
        OtherApps("其他应用 Flink, etc.")
    end

    Hive -- "翻译成" --> Spark
    Hive -- "翻译成" --> MapReduce

    Spark -- "读写数据" --> HDFS
    MapReduce -- "读写数据" --> HDFS
    HBase -- "底层存储" --> HDFS

    Spark -- "申请资源运行于" --> YARN
    MapReduce -- "申请资源运行于" --> YARN
    HBase -- "服务运行于" --> YARN

    subgraph User
        Developer("开发者/分析师")
    end

    Developer -- "写SQL" --> Hive
    Developer -- "写代码" --> Spark
    Developer -- "实时读写" --> HBase

一个作业的旅程：当你在Hive里敲下回车

现在，我们把上面的所有东西串起来，看看当一个数据分析师执行一个Hive SQL查询时，到底发生了什么。

场景：分析师想统计每个国家的用户数量。

SQL: SELECT country, COUNT(*) FROM user_logs GROUP BY country;

提交查询: 分析师在Hive的客户端（比如Beeline）里输入SQL，敲下回车。
Hive处理: Hive Server接收到这个SQL。它首先会检查语法对不对，然后查询它的元数据（Metastore，记录了user_logs表在哪，什么格式等），生成一个执行计划。这个计划本质上是一个有向无环图（DAG），描述了需要几步、每步干什么才能完成这个计算。
向YARN申请”包工头”: Hive（或者说它配置的执行引擎，比如Tez或Spark）作为一个YARN客户端，向YARN的ResourceManager（资源总管） 发起请求：”我有个大活儿，需要启动一个’包工头’（ApplicationMaster），请给我分配点资源。”
YARN启动”包工头”: ResourceManager一看有名额，就在集群里找一个不那么忙的节点（NodeManager），在上面启动一个Container（容器，可以理解为一个隔离的进程空间），并把ApplicationMaster（AM）给运行起来。
包工头申请工人: 这个AM就是本次作业的总指挥。它会分析刚才Hive生成的执行计划，看看具体需要多少”工人”（计算任务），每个工人需要多少资源。然后它会分批向ResourceManager去申请：”老板，我需要10个工人，每人分配1GB内存和1个CPU。”
YARN分配工人: ResourceManager再次在集群的各个NodeManager上分配Container作为”工位”给这些工人。
工人开工: AM拿到”工位”列表后，直接跟对应的NodeManager通信，让它们在这些Container里启动真正的计算任务（Task）。这些任务会从HDFS上读取user_logs表的数据块。YARN会尽可能地让任务在数据所在的节点上运行，这就是所谓的”计算向数据移动”，以减少网络传输开销。
数据处理与汇总:
- Map阶段：各个任务（工人）读取自己分到的数据，解析出country，然后输出 (country, 1) 这样的键值对。
- Shuffle/Reduce阶段：YARN和执行引擎负责将相同country的数据拉到一起，然后交给Reduce任务去做最终的COUNT(*)汇总。
输出结果: 最终的统计结果，可能会被写回到HDFS的一个新文件里，或者直接通过网络返回给分析师的Hive客户端。
释放资源: 作业完成后，AM向ResourceManager注销自己，所有它申请的Container也都被YARN回收，资源被释放出来给其他作业使用。