Hadoop 生态

• YARN 主从架构与组件职责划分
• 应用提交、资源申请、容器分配的生命周期
• 容量调度器与公平调度器的资源分配策略差异

YARN 采用两层调度架构。ResourceManager（RM）是全局资源主控，负责集群资源统一管理、调度与心跳仲裁；NodeManager（NM）是每个节点上的从属进程，负责启动/监控容器并向 RM 上报本节点资源；ApplicationMaster（AM）是每个应用专属的调度协调者，负责向 RM 申请资源、把任务切分并调度到对应 NM 的容器中执行，并负责任务失败重试。协作流程为：客户端提交应用给 RM，RM 分配一个 AM 容器，AM 启动后根据任务图向 RM 的 Scheduler 异步申请资源（Container），RM 返回容器所在节点，AM 再通知对应 NM 启动容器运行任务，任务完成或失败后 AM 向 RM 注销。Capacity Scheduler 将集群按队列划分并保证每个队列 "容量下限"（minimum capacity），资源充足时可弹性占用超额（elasticity），队列内部按 FIFO 或优先级排队，约束是 "硬性容量保证 + 排队等待"；Fair Scheduler 则按活跃任务数在队列间公平共享资源（类似多进程 CPU 公平调度），新任务会抢占以获得公平份额，更适合多租户共享场景。

记住 RM 是大脑、NM 是执行单元、AM 是应用的中间人，调度是 "AM 申请 - RM 分配 - NM 执行" 的闭环。容量与公平的本质区别在于：容量调度保证最低配额、超额弹性、不抢占；公平调度追求动态均分、可抢占。面试时用 "银行额度 vs 多人分蛋糕" 类比即可。

• 默认副本放置（第 1 副本同机架、第 2 副本异机架、第 3 副本与第 2 同机架异节点）
• 容错与带宽/写入代价的权衡
• 副本数对可靠性、存储成本、写入吞吐的影响

HDFS 默认副本数为 3，放置策略为：第 1 个副本放在客户端所在节点（就近写入）、第 2 个副本放在与第 1 个不同机架的节点、第 3 个副本放在与第 2 个相同机架的另一个节点（或另一机架）。这样既保证"一个机架整体故障"时数据仍可用（跨机架容错），又降低跨机架复制带宽的开销（第 3 副本同机架，减少跨机架网络流量）。该策略在"机架故障容错"与"跨机架带宽"之间折中：副本数越多容错越强、读取本地化率越高，但写放大成倍、存储成本线性上升、写入时需同步的副本数越多吞吐越低。调大副本数（如 4-5）用于高可靠性/热读场景，调小（如 2）用于备份或对象存储冷数据归档场景。

核心是记忆"三副本放置公式"：1 本机架、2 异机架、3 同第 2 副本机架。回答时强调"机架是故障域"，副本必须跨机架才算真正容错，同时说明存储成本 = 数据量 × 副本数，是存储-吞吐-可靠性的三角权衡。

• 小文件对 NameNode 内存（每个文件/块约 150 字节元数据）与亲和性的影响
• HAR / SequenceFile / 合并写入治理方案
• 对象存储（OSS/S3）对小文件的天然优势

HDFS 中每个文件、目录、块都要在 NameNode 内存中维护元数据（约 150 字节/项），小文件问题在于每个文件可能只占一个块，导致"文件数=块数"地膨胀，NameNode 内存被元数据耗尽（内存瓶颈），且 MapReduce/Spark 读取时每个小文件启动一个任务，task 启动开销远大于数据量，吞吐骤降。治理方案各有利弊：HAR（Hadoop Archive）把多个小文件打包成一个归档文件，减少元数据项，但归档不可变、读取单文件需额外寻址，适合冷数据归档；SequenceFile 把 key-value 小文件顺序写入一个文件，省元数据且可压缩，但只适合写后读、不支持随机小文件更新；最常用的是"上游合并"即写入前把数据按 partition 合并成适当大小（如 128MB）的块式文件；规模大、低频访问时可直接落到对象存储（OSS/S3），对象存储无 NameNode 内存瓶颈，按对象而非块管理，天然抗小文件。工程上通常"源头合并 + 周期归档 + 冷热分层"组合使用。

紧盯"NameNode 内存 = 文件数 × 元数据大小"这个公式，小文件的核心代价是元数据内存与 task 启动开销，而非存储本身。治理思路排序：优先源头合并（最有效），其次 HAR/SequenceFile 归档，最后对象存储兜底。

• Balancer 的作用（跨 DataNode 数据量均衡）与执行方式
• Mover 的作用（跨存储层/存储策略迁移）
• 二者维度不同：Balancer 管"节点间"，Mover 管"存储层级间"

Balancer 用于平衡集群中各 DataNode 之间的数据分布，当新增节点或数据写入不均导致某些节点磁盘占用过高时，通过迁移块使各节点使用率趋于均衡，避免热点节点带崩集群。它通过 hdfs balancer 命令执行，按"配比（ratio）"阈值控制，默认只移动超出阈值的块，可指定 -threshold 控制均衡程度。Mover 用于在存储层级（Storage Tier：DISK、SSD、ARCHIVE）之间迁移数据，配合 HDFS 的存储策略（Storage Policy）把热数据放 SSD、冷数据放 ARCHIVE，通过 hdfs mover 执行，按存储策略把块移动到对应层级。二者侧重点不同：Balancer 是"节点间横向均衡"，Mover 是"存储层级间纵向/分层迁移"，可配合使用实现"分层 + 均衡"的完整治理。

一句话区分：Balancer 平衡"节点间"磁盘占用，Mover 迁移"存储层间"数据。二者都产生数据移动、占用带宽，通常低峰期执行。

• Active/Standby 双 NameNode 架构
• JournalNode（QJM）共享日志与元数据同步
• 故障转移（自动/手动 Failover）与 Fencing

HDFS 的 HA 通过"双 NameNode（Active/Standby）+ 共享日志"实现。两个 NameNode 共享一份 EditLog：Active 节点把修改记录写入一组 JournalNode（QJM，通常 3 个，过半写成功即算提交），Standby 节点持续从 JournalNode 读这些 EditLog 并应用到自身的 FsImage 上，从而在内存中保持与 Active 一致的状态，能在秒级内接管服务。Standby 还周期性执行 Checkpoint 合并 FsImage，减轻 Active 负担。故障切换由 ZKFC（基于 ZooKeeper 的故障控制器）监控并通过 ZK 选举实现，避免"双主"（split-brain）依靠 Fencing（隔离旧 Active）机制保证，例如通过更新 ZK 锁或调用旧 Active 的 transitionToStandby 强制其退出。客户端通过一组 NameNode 的地址或 NameService 自动发现 Active。相较传统 SecondaryNameNode 只做 checkpoint 不参与热备，HA 提供真正的元数据热备与秒级切换。

抓住"QJM 共享日志"是 HA 的数据同步核心，ZKFC 是选主与 Fencing 的核心。理解"过半写成功"保证一致性，Fencing 防止脑裂。

• NameNode 元数据与 DataNode 数据块的职责分离
• 读流程（客户端→NameNode 定位→就近 DataNode 读）
• 写流程（客户端→NameNode 建块→管道复制）

HDFS 采用 Master/Slave 架构：NameNode 是主节点，只管理元数据（文件→块映射、块→DataNode 映射、目录结构），不存数据；DataNode 是从节点，实际存储块数据并周期性心跳上报块位置与健康状况。读流程：客户端向 NameNode 请求文件块位置，NameNode 返回块所在 DataNode 列表（按就近优先排序），客户端直接与 DataNode 建立连接读取数据，数据不经过 NameNode。写流程：客户端向 NameNode 申请创建文件并分配块，NameNode 返回一个 DataNode 管道（通常 3 个）、客户端按序把数据分包写入第一个 DataNode，第一个再转发给第二个、第二个转发给第三个（流水线复制），全部确认后客户端向 NameNode 汇报块完成。整个流程数据流与元数据流分离，保证千兆/万兆带宽下 NameNode 不成为瓶颈。

记忆"元数据走 NameNode、数据走 DataNode 管道"的关键分离。读是"就近直读"，写是"流水线复制"。面试常问"为什么 NameNode 不转发数据"——因为那会变成瓶颈。

• 纠删码原理（RS 编码：数据块 + 校验块）
• 与 3 副本的存储开销对比（1.33x vs 3x）
• 编码/解码的 CPU 代价与适用场景

传统 3 副本存储开销为 300%，纠删码（EC）用数学冗余替代多副本：如 RS(6,3) 把数据切成 6 个数据块再生成 3 个校验块，任意 6/9 块存活即可恢复原始数据，存储开销仅 1.5 倍；常用 RS(10,4) 为 1.4 倍，Hadoop 3.3 引入的 LRC（本地纠删码）在相同冗余下通过本地校验块显著降低单块重建时的网络带宽开销。读取时只需取所需数据块和校验块即可重建，编码/解码需要额外 CPU 计算（XOR/有限域运算），跨节点读取小块会带来网络开销。因此 EC 适合冷数据、写少读多且对延迟不敏感的数据（如归档、日志、备份），不适合写入频繁或需要低延迟连续读的热数据。Hadoop 3.x 通过 hdfs ec -enablePolicy 对目录启用 EC 策略。

抓住"用 CPU 换存储"的取舍：EC 省大量存储但增加编码解码 CPU 与恢复时的网络读取。默认副本面向热数据，EC 面向冷数据/归档。

• Hadoop 通过 S3A/OSS 连接器访问对象存储
• 对象存储的"最终一致性与无块概念"对 Hadoop 语义的影响
• 冷热分层、成本与性能取舍

Hadoop 通过 S3A（S3）、Alibaba OSS 等文件系统连接器把对象存储挂载为 HDFS 兼容的文件系统，SQL 引擎（Spark/Hive）可直接读写对象存储。相比 HDFS，对象存储无 NameNode、无块管理，按对象寻址，天然抗小文件、无限扩展、成本低，适合冷数据与归档。但存在差异：对象存储是"最终一致"（S3 部分场景强一致），且"目录""重命名""append"等文件系统语义支持弱（S3 无 rename 原子性，需 copy），MapReduce 的落盘/Shuffle 可能需要临时本地目录；对象访问的延迟与请求费用（PUT/GET 次数计费）与 HDFS 的本地块读取也不同。实际工程常做"冷热分层"：热数据在 HDFS，冷数据/归档在对象存储，或用 HDFS 作为计算缓存加速。使用上需配置访问凭证、设置合适的分区大小减少请求数、避免频繁小对象读写。

核心是"对象存储无元数据节点、无块、弱一致性/弱文件系统语义"，计算引擎的语义补偿（如 Spark 对对象存储的 S3 兼容优化）是考察重点。回答强调"冷热分层"与"语义差异"。

• Hive：SQL 数据仓库
• Pig：脚本化处理
• Sqoop：关系型数据导入导出

四者定位不同：Hive 是构建在 HDFS 之上的数据仓库工具，把 SQL 翻译成 MapReduce/Tez/Spark 任务，提供类 SQL 的表查询与 ETL，是离线数仓核心；Pig 是脚本式（Pig Latin）数据处理语言，适合把复杂 MapReduce 封装成简洁脚本的批处理，但现在已被 Spark/Hive 取代，工程使用较少；Sqoop 用于在关系型数据库（MySQL/Oracle）与 HDFS/Hive 之间批量导入导出数据，是结构化数据的 ETL 通道；Flume 是分布式日志采集系统，通过 source/channel/sink 把流式日志实时写入 HDFS/Hive，适合日志管道采集。工程实践上：离线数据入库用 Hive/Spark SQL，关系库与 HDFS 双向同步用 Sqoop，日志流采集用 Flume/Kafka，而 Pig 相对边缘化。

用"干什么"记忆：Hive=查与算、Pig=脚本批处理、Sqoop=关系库搬运、Flume=日志采集。注意生态演进里 Pig 衰退、Hive 逐渐被 Spark SQL 替代。

• Kerberos 的票据（TGT/SGT）与 KDC 认证流程
• Hadoop 服务（NameNode/DataNode）如何用 principal/keytab 认证
• 安全集群的运维（keytab 轮换、代理、跨域）

Kerberos 是一种基于对称密钥的第三方认证协议，核心是 KDC（密钥分发中心）与票据（Ticket）。用户登录时向 KDC 请求 TGT（Ticket Granting Ticket），之后用 TGT 换取访问各服务的 SGT（Service Ticket），服务端用预共享的密钥验证票据，从而避免明文口令传输，实现"单点登录 + 互相认证"。Hadoop 安全模式下，每个服务进程（NameNode/DataNode/ResourceManager）都配置有 principal 与 keytab 列表，用 keytab 免密向 KDC 认证；客户端（如 hdfs shell、Spark）需先 kinit 或配置安全认证。工程注意：keytab 需周期轮换、principal 过期会影响集群读写、跨域（跨 KDC）需要 trust 配置、代理用户（ProxyUser）与组映射（LDAP/AD）需配套管理。Kerberos 主要解决"认证"（你是谁），授权（你能干什么）由 Ranger/Sentry 等配合实现。

分清"认证"与"授权"是两大安全组件。Kerberos 负责认证，核心是"票据 + KDC + keytab"。回答强调 SSL 加密（传输层）与 Kerberos（身份认证）是两层独立安全。

• 块大小与寻道时间/传输时间的比值
• 长条磁盘寻道约 10ms、传输带宽
• 块大小对元数据量与并行度的影响

HDFS 块大小的设计依据是"最小化寻道时间占比"。磁盘寻道约 10ms，若块太小，传输时间与寻道时间相当，寻道开销占比高、吞吐低；块越大，传输时间远大于寻道时间，顺序读吞吐越高。经典推导：若要传输时间占 90% 以上，需块大小使传输时间 ≥ 9×寻道时间，以 100MB/s 带宽计约 100MB，故旧版默认 64MB，后来磁盘带宽提升到 128MB/256MB。块增大带来元数据量减少（每个块占用 NameNode 内存，块大则块数少）、单文件并行度下降（一个文件最多启动与块数相等的 map 任务，块太大并行度低）。所以块大小是"吞吐 vs 并行度 vs 元数据内存"的权衡：大文件/流式读选大块，小文件/高并行选小块。

记住核心公式"寻道时间 10ms，传输应远大于寻道"，块大小随带宽提升而增大。回答时点出"块太小寻道占比高、太大并行度低"的双向影响。

• 推测执行：为慢任务启动备份任务
• 触发条件与参数（mapreduce.map.speculative / reduce.speculative）
• 适用与禁用场景

推测执行（Speculative Execution）是 MapReduce 的"慢任务救赎"机制：当某个 task 明显慢于同 stage 其他 task（如节点故障、CPU 争抢、数据倾斜）时，JobTracker/ResourceManager 会为它在另一个空闲节点启动一个备份任务，谁先完成取谁的结果，从而缩短整体作业时间。控制参数：mapreduce.map.speculative 与 mapreduce.reduce.speculative（默认 true），可全局或按 job 设置。但推测执行并非总是有利：若任务本身已消耗大量资源或慢是因数据倾斜（非节点问题），备份任务重复计算反而浪费资源；对写入外部系统的任务（如连数据库）可能出现重复写入。因此对幂等负担大的任务或确定性的 ETL 作业，常显式关闭推测执行（-Dmapreduce.map.speculative=false）。

核心是"用冗余计算换稳定性"，针对"节点慢"而非"数据慢"。回答要说明何时关闭：任务副作用大、长尾来自倾斜、资源紧张时。

• Federation 的 Namespace/BlockPool 分片
• 解决 NameNode 单点内存瓶颈
• 局限（无全局视角、运维复杂）

Federation 把 HDFS 从"单一 NameNode 管理全部元数据"扩展为"多个 NameNode（Namespace）各自管理一部分元数据"，每个 NameNode 管理自己的 Namespace 与对应的 BlockPool（BlockPool 是块命名空间，DataNode 同时向多个 BlockPool 汇报）。通过挂载表（Mount Table）把不同目录映射到不同 NameNode，实现元数据水平扩展，突破了单 NameNode 内存上限（最大文件数/块数）。但 Federation 不等于全局 HA：每个 Namespace 仍需各自 HA，且多个 NameNode 之间没有全局的"整文件系统视图"，跨 Namespace 的块/文件操作（如移动跨挂载点）不会自动完成，监控与运维复杂度高。它解决的是"NameNode 内存容量瓶颈"，而非"单点可用性"。

明白 Federation 是"按 Namespace 分片元数据"，本质是横向扩展 NameNode 内存。与 HA（解决可用性）不同，Federation 解决容量，二者可叠加。

• Hive 执行流程：解析→AST→逻辑计划→优化→物理计划→执行引擎
• 分区裁剪（Partition Pruning）
• 数据倾斜的常见优化手段

Hive SQL 执行流程为：SQL 词法/语法解析生成 AST（抽象语法树），AST 经语义分析生成逻辑计划（QB），再经逻辑优化器（谓词下推、列裁剪、分区裁剪、常量折叠、合并连接等）优化，逻辑计划转换为物理计划（MapReduce/Tez/Spark 的算子树），最后调度执行。分区裁剪（Partition Pruning）是核心优化：查询加了分区过滤条件（如 WHERE dt='2024-01-01'）时，Hive 只读取匹配的分区目录，避免扫描全表，显著减少 IO，因此建表应优先按常用过滤字段（如日期）分区。数据倾斜（Data Skew）常见于 join 或 group by 时某 key 数据量远超其他，优化手段包括：两阶段聚合（先局部聚合再全局聚合）、对 join 的倾斜 key 加盐（salting）打散、map-join/bucket map join 把小表广播、skew join 自动拆分倾斜 key 单独处理、增加 reduce 并行度等。

记住"解析→优化→执行"三段式。分区裁剪是"谓词下推"在分区表上的体现，最重要。数据倾斜回答"两阶段聚合 + 加盐 + broadcast join"三板斧。

• Map 端：环形缓冲、溢写、分区/排序/合并
• Reduce 端：拉取、合并、分组排序
• Shuffle 的 IO 与网络代价

Shuffle 是 map 输出到 reduce 输入之间的数据搬运与排序过程。Map 端：map 输出写入环形缓冲区（默认 100MB），缓冲区达到阈值（默认 80%）触发溢写（spill），溢写时按分区（partition）划分、分区内按键排序（sort）、可选合并（combiner）与压缩，多次溢写合并成一个大文件（merge），并为 reduce 建立分区索引。Reduce 端：map 完成后，reduce 从各 map 端拉取属于自己分区的数据（fetch），放入内存缓冲，超过阈值落盘，所有数据到齐后按 key 归并排序（merge sort），相同 key 分组后交给 reduce 函数处理。Shuffle 是 MapReduce 最重的 IO/网络环节，数据倾斜、小文件、压缩配置、reduce 数量都直接影响 shuffle 性能。Sort 在 Map 端是分区内排序，Reduce 端是全局按 key 归并。

Shuffle 的核心动词是"分、排、并、拉、合"。Map 端做"分区+排序+合并"（本地），Reduce 端做"拉取+归并排序+分组"。优化方向：压缩、环形缓冲大小、reduce 数量。

• hadoop fs 支持多种文件系统（通用）
• hdfs dfs 特定于 HDFS
• 命令演进与兼容性

hadoop fs 是"通用文件系统 shell"，通过 FileSystem 抽象可操作 HDFS、本地文件系统、对象存储（S3/OSS）等所有 Hadoop 支持的存储，hdfs dfs 则是专门针对 HDFS 的命令，二者在较新版本上功能基本一致（hdfs dfs 内部也委托给通用 shell）。区别在于：hadoop fs 更通用、可跨文件系统，hdfs dfs 语义上明确面向 HDFS，早期版本只有 hdfs dfs 支持 HDFS 特有操作（如 -setrep）而 hadoop fs 则不可用。随着 HDFS 与通用 shell 融合，两者在多数版本行为趋同，官方建议用 hadoop fs（更通用），但真正针对 HDFS 的底层操作（如 -setrep）用 hdfs dfs 更清晰。实际工程两者都能用，选 hadoop fs 更利于脚本复用。

核心是"广度与针对性"：hadoop fs 通用、hdfs dfs 专一。现代版本趋同，面试答"general vs specific"即可。

• 客户端与 NameNode 的元数据交互
• 写入时的副本管道（Pipeline）数据流
• 读取时的就近直连

HDFS 读写采用"元数据（NameNode）与数据（DataNode）分离"的协作模式。写流程：客户端向 NameNode 请求创建文件，NameNode 返回首个块对应的 DataNode 列表（依据机架感知选择），客户端把数据按 chunk 分包写入管道中第一个 DataNode，后者转发给第二个、第二个转发给第三个（流水线），每个 DataNode 逐包确认（ack）回传，客户端收到全部 ack 后向 NameNode 汇报块完成，NameNode 更新元数据。读流程：客户端向 NameNode 请求文件块位置，NameNode 返回块所在 DataNode 列表（按距离排序），客户端直接与最近 DataNode 建立连接拉取数据，若失败则切换下一个副本，数据不经过 NameNode。NameNode 全程只处理元数据请求，不承担数据搬运，从而支撑海量吞吐。

一句话：NameNode 记账、DataNode 搬数据、写走管道复制、读走就近直连。管道是"链式转发"而非"各发一份"，这是理解重点。

• FsImage（全量快照）与 EditLog（增量日志）的分工
• Checkpoint 合并原理
• 防止 EditLog 无限增长

NameNode 用文件系统镜像（FsImage，保存某时刻的完整元数据快照）与编辑日志（EditLog，记录快照之后的增量修改）来持久化元数据。启动时 NameNode 加载 FsImage 并重放 EditLog 得到最新状态。若 EditLog 无限增长，启动时重放时间会越来越长，且 EditLog 文件本身过大。Checkpoint 机制定期把"当前 FsImage + 累积的 EditLog"合并成新的 FsImage，并清空 EditLog，从而控制日志规模、加快重启。在非 HA 模式下由 SecondaryNameNode 执行：它从 Active 拉取 FsImage 与 EditLog，合并后回传；在 HA 模式下由 Standby NameNode 定期执行 Checkpoint（合并后上传给 Active）。触发条件通常是时间间隔（默认 1 小时）或 EditLog 事务数达到阈值（默认 100 万）。

类比"整库备份 + 增量日志"：FsImage 是整库备份，EditLog 是增量，Checkpoint 是"合并还原快照"。理解它解决"启动重放慢 + 日志膨胀"。