HDFS与Yarn深入剖析

一、HDFS核心知识点

（一）HDFS基础认知

1. 定义与起源：源于Google的GFS论文，是其开源版本。它基于普通低成本机器搭建分布式文件系统，自带容错机制，确保数据存储的高性能。

2. 核心优缺点

    - 优点

        - 高容错性：数据自动多副本存储，副本丢失能自动恢复。比如在大规模数据存储场景中，即使部分存储节点故障，数据也不会丢失。

        - 适合批量处理：采用移动计算而非移动数据策略，将数据位置暴露给计算框架，提升处理效率。以MapReduce任务为例，计算任务会被调度到存储数据的节点附近执行。

        - 支持大数据量：能处理TB/PB级数据、百万级文件以及10K+节点规模，满足大数据时代海量数据存储需求。

        - 流式访问：遵循一次写入、多次读取模式，保障数据一致性。许多日志数据存储场景就利用这一特性。

        - 低成本：基于廉价机器构建，通过多副本机制弥补硬件可靠性不足，降低存储成本。

    - 缺点

        - 低延迟差：难以满足毫秒级响应需求，在对响应时间要求极高的实时交易系统中不太适用。

        - 小文件处理弱：大量小文件会占用NameNode过多内存，且寻道时间远超读取时间，影响整体性能。像电商平台中众多商品图片这类小文件的存储管理，就是HDFS面临的挑战。

        - 写入不灵活：不支持并发写入，仅允许单个Writer，且仅支持追加写入，限制了一些对数据写入灵活性要求高的应用。

 （二）HDFS核心设计

1.数据块（Block）设计

    - 默认大小：通常为64MB（可根据实际需求配置），若文件不足64MB，也单独占用一个块。

    - 划分原则：平衡数据传输时间与磁盘寻道时间，以此提高整体I/O效率。

    - 存储方式：文件被切分为多个数据块，默认每个块存储3个副本，且副本分散在不同节点，提升数据容错能力与读取性能。

2. 核心设计思想

    - 分而治之：把海量数据拆分到多节点存储，借助分布式架构提升存储容量与数据吞吐能力。

    - 取舍逻辑：为保障高吞吐、高可靠、高扩展，牺牲部分灵活性，如低延迟访问和随机修改数据的功能。

（三）HDFS架构组成（主从架构）

1. Active NameNode：作为唯一的主节点，承担管理文件系统命名空间、维护数据块与节点映射关系、配置副本策略以及处理客户端读写请求等重任。

2. Standby NameNode：充当主节点热备，定期合并fsimage（文件系统镜像）和editslog（操作日志），并将结果推送给Active NameNode。当Active NameNode故障时，能迅速切换为主节点，保障服务连续性。

3. DataNode：众多从节点中的一员，负责存储实际数据块，执行数据块读写操作，并定期向NameNode发送心跳报告自身状态。

4. Client：客户端组件，写入文件时负责文件切分；与NameNode交互获取文件位置信息；与DataNode直接进行数据读写。

（四）HDFS核心流程

1. 写流程（客户端写入文件）

    - Client向NameNode发送“创建文件”请求，NameNode校验权限等信息后，返回可用DataNode列表。

    - Client将文件切分为数据块，按顺序向第一个DataNode写入数据。

    - 数据通过“DataNode管道”自动复制到其他副本节点（默认3个）。

    - 每个DataNode写入完成后向Client返回确认（Ack）。

    - 所有数据块写入完成，Client向NameNode发送“完成”请求，NameNode更新元数据。

2. 读流程（客户端读取文件）

    - Client向NameNode发送“打开文件”请求，NameNode返回文件对应的数据块及存储节点信息。

    - Client根据节点信息，向距离最近的DataNode读取数据块。

    - 所有数据块读取完成后，Client在本地拼接成完整文件，关闭输入流。

（五）HDFS关键策略

1. 副本放置策略

    - 副本1：存储在与Client相同节点（若Client不在集群内，则随机选一个节点）。

    - 副本2：存储在与副本1不同机架的节点，提升跨机架容错性。

    - 副本3：存储在与副本2相同机架的其他节点，平衡性能与容错。

    - 更多副本：随机分配到集群节点。

2. 可靠性保障策略

    - 文件损坏：利用CRC32校验检测损坏数据，自动用其他副本替换受损块。

    - DataNode失效：DataNode定期向NameNode发送心跳，超时未响应则标记为失效，触发副本补全机制。

    - NameNode失效：依赖FSImage和EditsLog恢复元数据；通过Standby NameNode实现主备实时切换。

3. 小文件处理问题

    - 核心痛点：每个小文件元数据（约150Byte）占用NameNode内存，大量小文件易耗尽内存；且寻道时间长，访问效率低。例如，1亿个10K小文件仅占1TB存储，却需消耗20GB NameNode内存。

（六）HDFS访问与管理

1. 常用Shell命令

    - 本地文件上传到HDFS：`hadoop fs -copyFromLocal /local/data /hdfs/data`

    - HDFS文件下载到本地：`hadoop fs -copyToLocal /hdfs/data /local/data`

    - 创建HDFS目录：`hadoop fs -mkdir /hdfs/data`

    - 删除HDFS文件/目录：`hadoop fs -rmr /hdfs/data`

    - 查看HDFS目录内容：`hadoop fs -ls /hdfs/data`

2. 集群管理脚本（sbin目录下）

    - 启动全集群：`start - all.sh`

    - 停止全集群：`stop - all.sh`

    - 启动HDFS：`start - dfs.sh`

    - 单独启动NameNode：`hadoop - deamon.sh start namenode`

    - 单独启动DataNode：`hadoop - deamons.sh start datanode`

3. 节点增删操作

    - 添加DataNode

        - 复制现有DataNode的安装包及配置文件到新节点。

        - 执行`sbin/hadoop - deamon.sh start datanode`启动新节点。

    - 删除失效DataNode

        - 在NameNode配置文件`dfs.hosts.exclude`中添加待删除节点的IP/主机名。

        - 执行`bin/hadoop dfsadmin -refreshNodes`使配置生效。

4. Java API核心用法

    - 核心类（均来自org.apache.hadoop.fs包）**

        - `Configuration`：封装HDFS配置信息。

        - `FileSystem`：文件系统操作核心类，通过`FileSystem.get(config)`获取实例。

        - `FSDataInputStream`/`FSDataOutputStream`：HDFS文件输入/输出流，分别通过`open()`和`create()`方法获取。

（七）HDFS拓扑结构

集群节点按机架（Rack）划分，每个机架一般包含16 - 64个节点。NameNode、Secondary NameNode、Client等部署在独立节点，DataNode分布式部署在各机架节点，通过交换机连接，形成层级网络结构，兼顾性能与容错。

二、Yarn核心知识点

（一）Yarn诞生背景

在Hadoop 1.X时代，HDFS负责存储，MapReduce同时承担计算与资源管理职能，将计算任务调度到HDFS数据存储节点。但这种架构存在诸多问题，如单点故障率高（job tracker既管理资源又管理作业，任务繁重易挂掉，且无高可用机制，一旦故障集群瘫痪）、资源描述模型简单（仅依据task数量分配固定资源，未考虑CPU和内存实际需求，导致资源浪费和任务运行效率低下，且强制拆分资源为map和reduce，无法兼容其他计算框架，通用性差）。为解决这些问题，Yarn应运而生。

（二）Yarn介绍及架构

1. Yarn概述：Yarn是分布式通用资源管理系统，位于通用计算和数据存储中间位置。解决了MapReduce架构的诸多问题，使资源调度更精细、通用性增强，可调度多种计算框架作业到HDFS运行。

2. 主从架构组成

    - 主节点 - ResourceManager**：负责资源管理，处理客户端请求，监控NodeManager，启动或监控ApplicationMaster，进行资源的分配与调度。它由Scheduler（在容量和队列限制范围内为运行的容器分配资源，是纯调度器，不负责应用程序状态监控与任务重启）和ApplicationsManager（负责接收作业提交，启动ApplicationMaster容器，并在其失败时重启）两个关键组件组成。

    - 从节点 - NodeManager**：所有NodeManager地位平等，无层级管理关系。负责管理单个节点上的资源，处理来自ResourceManager和ApplicationMaster的命令，定时向ResourceManager汇报本节点资源（CPU、内存）使用情况和Container运行状态，当ResourceManager宕机时自动连接备用节点。

3. 作业管理机制

    - 作业提交与资源分配：客户端向resource manager提交作业，后者在node manager中为作业分配资源（包括CPU、内存、环境变量等），并分装到container中。首次提交作业通常分配一个container用于运行作业的管理进程`application master`。

    - 作业解析与资源再申请：application master运行后解析作业，若需更多资源则向resource manager申请，resource manager再次分配container给application master。

    - 任务分发与运行监控：application master获得资源后将作业task分发到container中运行，task实时向application master汇报状态，若有task故障，application master会尝试重启。

    - 资源释放与作业完成：当application master检测到所有task运行完毕，向resource manager申请释放资源，resource manager释放相关container，作业执行流程结束。

4. 架构通用性：该架构具有通用性，客户端可提交map reduce作业、spark作业或自行编写的job。只要任务实现application master接口，就能在集群中运行。例如spark作业提交后，同样先由resource manager分配container运行其application master，后续流程类似其他作业，由application master自主解析任务、申请资源、分发task并监控运行。

（三）Yarn高可用机制

1. 多主节点与状态管理架构：高可用架构由多台主节点构成，其中一台主节点处于active管理状态，其余为stand by热备状态。主节点间状态由zookeeper管控。zookeeper从主节点中选定管理节点并设为active，当active节点故障，zk会将其resource manager状态降为stand by，并从stand by节点中选新管理主节点升级为active，确保管理连续性。

2. 元数据同步策略

    - hdfs同步方式：在hdfs中，原数据通过`journal node`集群实现同步，保障数据一致性与完整性，使新active节点获取最新原数据管理集群。

    - Yarn同步方式：Yarn系统将元数据置于zk内，standby节点可从中获取并同步，同步完成后经ZK切换为active进行集群管理，简化同步流程。

3. 主从切换对任务的影响及应对操作：主从切换期间，集群运行任务会阻塞，直至新active状态的resource manager选出才继续执行，防止数据不一致与错误操作。利用`yarn rmadmin`加参数可执行高可用操作，如获取节点状态，超级管理员可强制切换节点状态（stand by转active或反之），便于灵活调整集群架构。

（四）YARN资源调度策略

1. FIFO调度策略：采用单队列架构，任务依提交顺序依次执行。先提交的作业会独占集群全部资源运行，后续作业需等待前面作业完成才能获取资源启动。这种策略对紧急且执行时间短的小任务极不友好，可能导致小任务长时间等待，错过最佳执行时机，严重影响系统对多样化任务的处理效率。

2. 容量调度策略：基于多队列设计理念，将集群资源预先分配给不同队列。例如划分队列A用于处理大作业，分配集群80%资源；队列B用于处理紧急小作业，分配20%资源。作业提交时按类型进入相应队列获取资源运行，各队列作业可并行处理。每个队列资源占比并非绝对固定，可设置最大资源占用量。例如，可配置队列B在特定情况下（如队列A空闲时）最大可占用集群100%资源，有效避免资源闲置浪费。在配置文件（如yarn - site.xml）中需指定使用容量调度器，并借助自定义配置文件详细设定各队列及子队列资源占比等参数。如在根队列下创建队列A、B，并可在队列A下进一步设置子队列A1、A2，同时明确各队列资源分配比例（如队列A占80%，队列B占20%，队列A1占队列A资源的40%，队列A2占60%等）。

3. 公平调度策略：采用多队列架构，但队列间无预设固定资源占比，资源分配遵循公平原则。基于公平共享的原则，根据各个应用程序的需求和优先级，动态地分配集群资源。在公平调度器中，所有的应用程序被视为同等重要，每个应用程序都有一定的权重。调度器会根据应用程序的权重和资源需求来分配资源，以达到公平和均衡的资源分配。随着时间的推移和各个应用程序的资源需求变化，Fair调度器会动态地重新计算每个应用程序的权重和资源分配，保持公平和均衡的资源调度。