Apache Hadoop 生态系统核心组件它们各自承担不同角色协同完成大数据的存储、计算、分析与管理任务YARNYet Another Resource NegotiatorHadoop 2.x 引入的通用资源调度与管理框架负责集群资源CPU、内存等的分配与任务生命周期管理使 Hadoop 不再局限于 MapReduce可支持多种计算框架。MapReduce经典的批处理计算框架基于“分而治之”思想分为 Map映射和 Reduce归约两个阶段适合高容错、大规模离线批处理但存在磁盘 I/O 开销大、延迟高等局限。Tez基于 YARN 构建的有向无环图DAG计算框架专为优化 Hive 等 SQL-on-Hadoop 引擎而设计通过减少中间落盘、复用容器等方式显著提升复杂查询性能相比 MapReduce 可提速数倍。Spark 2.x内存优先的通用分布式计算引擎支持批处理Spark SQL / RDD、流处理Structured Streaming、机器学习MLlib和图计算GraphX。其 DAG 执行引擎 内存缓存机制大幅降低迭代计算延迟是 MapReduce 和 Tez 的重要演进替代者。Hive构建在 Hadoop 之上的数据仓库工具提供类 SQLHiveQL接口将 SQL 自动编译为 MapReduce/Tez/Spark 任务执行支持元数据管理Metastore、分区/分桶、ACID 事务Hive 3适用于即席查询与 ETL。HBase基于 HDFS 的分布式、面向列的 NoSQL 实时读写数据库提供毫秒级随机读写能力适合高吞吐、稀疏数据场景如用户画像、消息日志但不支持复杂 SQL 和强事务仅行级原子性。Pig脚本式数据流处理工具使用 Pig Latin 语言编写数据转换逻辑自动编译为 MapReduce/Tez/Spark 任务比直接写 MapReduce 更简洁适合 ETL 工程师但逐渐被 Spark SQL / Flink SQL 替代。Sqoop专用于在 HadoopHDFS/Hive/HBase与关系型数据库MySQL、Oracle 等之间高效传输结构化数据的迁移工具支持全量导入/导出、增量同步基于时间戳或递增列及并行作业切分。这些组件常组合使用例如✅ Sqoop 将 MySQL 数据导入 HDFS → Hive 建表管理 → Spark SQL 或 Tez 执行分析 → 结果存入 HBase 供实时查询。在 YARNYet Another Resource Negotiator架构中各核心组件职责明确、分工协作共同实现集群资源的统一调度与应用生命周期管理ResourceManagerRM是 YARN 的全局中央调度器运行在主节点Master核心职责包括✅资源管理维护整个集群的可用资源CPU 核数、内存 MB 等视图通过Scheduler如 CapacityScheduler 或 FairScheduler按策略队列配额、优先级、公平性等分配 Container 资源✅应用管理接收客户端提交的应用请求如 MapReduce Job、Spark Application启动并监控对应的 ApplicationMasterAM❌不参与具体任务执行——不运行用户代码也不感知应用逻辑。NodeManagerNM是运行在每个工作节点Worker/Slave上的代理进程核心职责包括✅节点资源监控与上报周期性向 RM 汇报本节点的资源使用情况内存/CPU 占用、磁盘、健康状态✅Container 生命周期管理根据 RM 的指令启动、停止、监控 Container轻量级运行时环境封装了任务所需的资源、环境变量、JAR 包等✅日志管理与安全隔离管理 Container 日志、支持 cgroups 进行资源硬隔离防 CPU/内存超用、配合 Kerberos 实现安全认证。ApplicationMasterAM是每个应用程序Application专属的、运行在某个 Container 中的框架级协调者例如MapReduce 的 MRAppMaster、Spark 的 SparkApplicationMaster其作用是✅应用级资源协商者代表本应用向 RM 申请、释放 Container 资源如“我需要 10 个 2G 内存 1 核 CPU 的 Container”✅任务调度与容错中心在获得 Container 后向对应 NM 发送启动命令调度具体任务如 Mapper/Reducer、Spark Executor监控任务状态失败时自动重试或申请新 Container✅状态汇报与进度跟踪向 RM 汇报应用整体进度、资源使用、健康状态并向客户端如yarn application -status提供查询接口。⚠️ 注意AM 本身是一个可插拔的用户程序不同计算框架MapReduce/Spark/Tez需各自实现 AMYARN 不关心其内部逻辑只提供资源和生命周期托管能力。简言之RM 集群总调度官管资源管应用入口NM 节点管家管本机资源管容器执行AM 应用项目经理管自己任务怎么跑、出错怎么救YARN 的Scheduler如CapacityScheduler是 ResourceManager 的核心插件专为多租户、多团队、多业务线共享 Hadoop 集群而设计。它通过分层队列Hierarchical Queues模型实现资源的逻辑隔离、弹性共享与 SLA 保障而非物理隔离即不独占机器兼顾公平性与确定性。✅ 一、如何通过队列实现多租户资源隔离与保障CapacityScheduler 将集群资源CPU 内存按百分比划分为多个逻辑队列Queue典型结构如下root ├── default # 默认队列兜底 ├── engineering # 工程团队队列capacity40% │ ├── batch # 批处理子队列capacity70% of engineering → 28% total │ └── ml # 机器学习子队列capacity30% → 12% total ├── marketing # 市场团队队列capacity30% └── finance # 财务团队队列capacity30%其保障机制包括机制说明目的硬性容量保障Guaranteed Capacity每个队列配置capacity如engineering.capacity40表示该队列最低可保障获得的集群资源百分比。即使其他队列空闲该队列也能独占这部分资源。✅ 防止“被饿死”保障关键业务基线性能弹性资源共享Elastic Sharing当某队列资源未用满时空闲资源可被其他有配额余量且未超限的队列临时借用需满足maximum-capacity约束。归还策略当原队列有新任务提交时Scheduler 会逐步回收借出资源抢占或等待释放。✅ 提升集群整体资源利用率避免浪费访问控制ACLs可配置acl_submit_applications和acl_administer_queue限制哪些用户/组能向某队列提交或管理应用。✅ 实现权限隔离防止越权使用资源限制与优先级支持设置单应用最大资源yarn.scheduler.capacity.maximum-applications、队列并发任务上限、应用优先级调度等。✅ 防止单应用/单用户霸占全部资源 关键点隔离 ≠ 完全独占。CapacityScheduler 实现的是软隔离—— 有保底、可借用、可回收平衡了确定性与灵活性。✅ 二、capacity与maximum-capacity的本质区别参数含义是否强制典型取值作用对象行为示例capacity队列长期保障的最小资源占比静态配额总和必须 100%root 下所有 direct child queue✅ 是硬约束40,30,30整个队列全局视角若engineering.capacity40则无论集群多空闲它至少能稳定使用 40% 资源maximum-capacity队列允许临时借用的最大资源上限弹性上限防止无限抢占❌ 否软上限可设为-1表示无上限但生产环境强烈不建议80,60,100或-1单次资源分配峰值若engineering.maximum-capacity80则它最多可用 80% 资源即使其他队列全空超出部分将被拒绝或等待重要补充maximum-capacity默认值为 100即最多用满集群但若设为60则即使集群 90% 空闲该队列也无法突破 60%capacity是“保底”maximum-capacity是“封顶”二者共同定义该队列的资源使用区间[capacity%, maximum-capacity%]子队列的capacity是相对于父队列的百分比如engineering.batch.capacity70表示占engineering队列的 70%即集群的 28%修改队列配置后需执行yarn rmadmin -refreshQueues生效无需重启 RM。✅一句话总结capacity是 YARN 对多租户的服务等级承诺SLA确保“你至少能拿到这么多”maximum-capacity是对资源滥用的安全熔断阀防止“你抢太多影响别人”。
Apache Hadoop 生态系统核心组件，它们各自承担不同角色，协同完成大数据的存储、计算、分析与管理任务
Apache Hadoop 生态系统核心组件它们各自承担不同角色协同完成大数据的存储、计算、分析与管理任务YARNYet Another Resource NegotiatorHadoop 2.x 引入的通用资源调度与管理框架负责集群资源CPU、内存等的分配与任务生命周期管理使 Hadoop 不再局限于 MapReduce可支持多种计算框架。MapReduce经典的批处理计算框架基于“分而治之”思想分为 Map映射和 Reduce归约两个阶段适合高容错、大规模离线批处理但存在磁盘 I/O 开销大、延迟高等局限。Tez基于 YARN 构建的有向无环图DAG计算框架专为优化 Hive 等 SQL-on-Hadoop 引擎而设计通过减少中间落盘、复用容器等方式显著提升复杂查询性能相比 MapReduce 可提速数倍。Spark 2.x内存优先的通用分布式计算引擎支持批处理Spark SQL / RDD、流处理Structured Streaming、机器学习MLlib和图计算GraphX。其 DAG 执行引擎 内存缓存机制大幅降低迭代计算延迟是 MapReduce 和 Tez 的重要演进替代者。Hive构建在 Hadoop 之上的数据仓库工具提供类 SQLHiveQL接口将 SQL 自动编译为 MapReduce/Tez/Spark 任务执行支持元数据管理Metastore、分区/分桶、ACID 事务Hive 3适用于即席查询与 ETL。HBase基于 HDFS 的分布式、面向列的 NoSQL 实时读写数据库提供毫秒级随机读写能力适合高吞吐、稀疏数据场景如用户画像、消息日志但不支持复杂 SQL 和强事务仅行级原子性。Pig脚本式数据流处理工具使用 Pig Latin 语言编写数据转换逻辑自动编译为 MapReduce/Tez/Spark 任务比直接写 MapReduce 更简洁适合 ETL 工程师但逐渐被 Spark SQL / Flink SQL 替代。Sqoop专用于在 HadoopHDFS/Hive/HBase与关系型数据库MySQL、Oracle 等之间高效传输结构化数据的迁移工具支持全量导入/导出、增量同步基于时间戳或递增列及并行作业切分。这些组件常组合使用例如✅ Sqoop 将 MySQL 数据导入 HDFS → Hive 建表管理 → Spark SQL 或 Tez 执行分析 → 结果存入 HBase 供实时查询。在 YARNYet Another Resource Negotiator架构中各核心组件职责明确、分工协作共同实现集群资源的统一调度与应用生命周期管理ResourceManagerRM是 YARN 的全局中央调度器运行在主节点Master核心职责包括✅资源管理维护整个集群的可用资源CPU 核数、内存 MB 等视图通过Scheduler如 CapacityScheduler 或 FairScheduler按策略队列配额、优先级、公平性等分配 Container 资源✅应用管理接收客户端提交的应用请求如 MapReduce Job、Spark Application启动并监控对应的 ApplicationMasterAM❌不参与具体任务执行——不运行用户代码也不感知应用逻辑。NodeManagerNM是运行在每个工作节点Worker/Slave上的代理进程核心职责包括✅节点资源监控与上报周期性向 RM 汇报本节点的资源使用情况内存/CPU 占用、磁盘、健康状态✅Container 生命周期管理根据 RM 的指令启动、停止、监控 Container轻量级运行时环境封装了任务所需的资源、环境变量、JAR 包等✅日志管理与安全隔离管理 Container 日志、支持 cgroups 进行资源硬隔离防 CPU/内存超用、配合 Kerberos 实现安全认证。ApplicationMasterAM是每个应用程序Application专属的、运行在某个 Container 中的框架级协调者例如MapReduce 的 MRAppMaster、Spark 的 SparkApplicationMaster其作用是✅应用级资源协商者代表本应用向 RM 申请、释放 Container 资源如“我需要 10 个 2G 内存 1 核 CPU 的 Container”✅任务调度与容错中心在获得 Container 后向对应 NM 发送启动命令调度具体任务如 Mapper/Reducer、Spark Executor监控任务状态失败时自动重试或申请新 Container✅状态汇报与进度跟踪向 RM 汇报应用整体进度、资源使用、健康状态并向客户端如yarn application -status提供查询接口。⚠️ 注意AM 本身是一个可插拔的用户程序不同计算框架MapReduce/Spark/Tez需各自实现 AMYARN 不关心其内部逻辑只提供资源和生命周期托管能力。简言之RM 集群总调度官管资源管应用入口NM 节点管家管本机资源管容器执行AM 应用项目经理管自己任务怎么跑、出错怎么救YARN 的Scheduler如CapacityScheduler是 ResourceManager 的核心插件专为多租户、多团队、多业务线共享 Hadoop 集群而设计。它通过分层队列Hierarchical Queues模型实现资源的逻辑隔离、弹性共享与 SLA 保障而非物理隔离即不独占机器兼顾公平性与确定性。✅ 一、如何通过队列实现多租户资源隔离与保障CapacityScheduler 将集群资源CPU 内存按百分比划分为多个逻辑队列Queue典型结构如下root ├── default # 默认队列兜底 ├── engineering # 工程团队队列capacity40% │ ├── batch # 批处理子队列capacity70% of engineering → 28% total │ └── ml # 机器学习子队列capacity30% → 12% total ├── marketing # 市场团队队列capacity30% └── finance # 财务团队队列capacity30%其保障机制包括机制说明目的硬性容量保障Guaranteed Capacity每个队列配置capacity如engineering.capacity40表示该队列最低可保障获得的集群资源百分比。即使其他队列空闲该队列也能独占这部分资源。✅ 防止“被饿死”保障关键业务基线性能弹性资源共享Elastic Sharing当某队列资源未用满时空闲资源可被其他有配额余量且未超限的队列临时借用需满足maximum-capacity约束。归还策略当原队列有新任务提交时Scheduler 会逐步回收借出资源抢占或等待释放。✅ 提升集群整体资源利用率避免浪费访问控制ACLs可配置acl_submit_applications和acl_administer_queue限制哪些用户/组能向某队列提交或管理应用。✅ 实现权限隔离防止越权使用资源限制与优先级支持设置单应用最大资源yarn.scheduler.capacity.maximum-applications、队列并发任务上限、应用优先级调度等。✅ 防止单应用/单用户霸占全部资源 关键点隔离 ≠ 完全独占。CapacityScheduler 实现的是软隔离—— 有保底、可借用、可回收平衡了确定性与灵活性。✅ 二、capacity与maximum-capacity的本质区别参数含义是否强制典型取值作用对象行为示例capacity队列长期保障的最小资源占比静态配额总和必须 100%root 下所有 direct child queue✅ 是硬约束40,30,30整个队列全局视角若engineering.capacity40则无论集群多空闲它至少能稳定使用 40% 资源maximum-capacity队列允许临时借用的最大资源上限弹性上限防止无限抢占❌ 否软上限可设为-1表示无上限但生产环境强烈不建议80,60,100或-1单次资源分配峰值若engineering.maximum-capacity80则它最多可用 80% 资源即使其他队列全空超出部分将被拒绝或等待重要补充maximum-capacity默认值为 100即最多用满集群但若设为60则即使集群 90% 空闲该队列也无法突破 60%capacity是“保底”maximum-capacity是“封顶”二者共同定义该队列的资源使用区间[capacity%, maximum-capacity%]子队列的capacity是相对于父队列的百分比如engineering.batch.capacity70表示占engineering队列的 70%即集群的 28%修改队列配置后需执行yarn rmadmin -refreshQueues生效无需重启 RM。✅一句话总结capacity是 YARN 对多租户的服务等级承诺SLA确保“你至少能拿到这么多”maximum-capacity是对资源滥用的安全熔断阀防止“你抢太多影响别人”。
