运维常见题-大数据运维

🤔 大数据运维核心工作有哪些？

• 大数据运维围绕“集群稳、数据准、任务快”三大目标：①集群管理（Hadoop/Spark/Flink 组件部署、扩容、调优、高可用）②数据运维（采集、存储、HDFS 管理、备份恢复、数据质量）③任务运维（调度、YARN/Spark 作业监控、OOM/慢任务排查）④监控告警 + 安全权限。核心：“管集群、护数据、盯任务、保安全”。

  • 集群运维（基础设施）

    • 组件部署/升级（HDFS/YARN/Spark/Flink/HBase/ZooKeeper）、配置管理、高可用
    • 容量规划（HDFS 存储、YARN 计算资源、节点扩缩容）、性能调优（网络/磁盘/参数）

  • 数据运维（数据资产）

    • 数据采集（日志/数据库/消息接入 HDFS）、存储管理（副本、冷热分层）、HDFS 文件策略（NameNode 元数据、DataNode 磁盘）
    • 备份恢复、数据质量校验（完整性/一致性）、垃圾数据清理（Trash/生命周期）

  • 任务运维（计算引擎）

    • 调度运维（YARN/调度器、队列）、Spark/Flink 作业提交/监控/失败重试
    • 性能排查（OOM、慢任务、数据倾斜、资源竞争）、Checkpoint（Spark/Flink）/Savepoint（Flink）管理

  • 监控告警 + 安全

    • 指标监控（HDFS 容量、YARN 资源、节点健康、作业状态——Ambari（HDP 管理面板，现多被 Cloudera Manager 取代）/Prometheus/Grafana）
    • 告警分级（节点宕机/磁盘满/任务失败/NameNode 异常）、日志采集分析
    • 安全（Kerberos 认证、ACL、数据脱敏）、权限治理

• 协助记忆

  • 口诀：“集群稳、数据准、任务快——管集群、护数据、盯任务、保安全”。

• 进阶思考

  • 大数据运维和传统运维最本质区别？
    • 对象从“单机/服务”变成“分布式集群 + 海量数据 + 计算作业”：要考虑数据分布/副本容错、资源调度、任务并行、数据倾斜，故障也从“服务挂”变为“NameNode 失联/DataNode 坏块/作业 OOM/数据倾斜”。更强调数据与计算联动。
  • 大数据集群最常见故障是什么？
    • 磁盘满（HDFS 容量爆）、节点宕机（DataNode/NodeManager 失联触发副本/任务重试）、NameNode 元数据压力、资源不足（YARN 队列抢占致任务饿死）、任务性能差（数据倾斜/OOM）。

• 扩展信息

  • 核心组件：HDFS（存储）、YARN（资源调度）、MapReduce/Spark（计算）、HBase（列存）、Hive（SQL）、ZooKeeper（协调）、Flink（流处理）
  • 监控工具：Ambari（Hadoop 集群管理面板）、Prometheus+Grafana、Cloudera Manager；日志 ELK/Flink 作业 UI

🤔 大数据的核心技术栈有哪些？

• 大数据技术栈按“采集→存储→计算→调度→查询→分析”分层：①采集（Flume/Kafka/Sqoop/Canal）②存储（HDFS/HBase/Kudu/S3）③计算（MapReduce/Spark/Flink）④调度（YARN/K8s/Airflow）⑤查询（Hive/Spark SQL/Presto/Impala）⑥分析（Zeppelin/ECharts/机器学习 MLlib）。核心：“采集进、存储底、计算层『批+流』、调度与查询往上”。

  • 数据采集层

    • 日志：Flume/Logstash；消息队列：Kafka（高吞吐缓冲）；数据库同步：Sqoop（增量，已停更——1.4.7 后入 Apache Attic，现多被 Flink CDC/SeaTunnel/Debezium 取代）/Canal/DataX（增量/实时，现代常选）
    • 作用：把分散数据接入到大数据平台（HDFS/HBase）

  • 存储层

    • 分布式文件：HDFS（海量、批处理基础）；列存：HBase（KV 随机读）/Kudu（实时分析）；对象：S3/OSS（云）
    • 特点：分布式、冗余副本、横向扩展、PB 级存储

  • 计算层（批/流）

    • 批处理：MapReduce（离线、磁盘、慢）→ Spark（内存、快、DAG）
    • 流处理：Flink（实时、低延迟 Checkpoint）/Spark Streaming（微批）

  • 调度与资源层

    • 资源调度：YARN（Hadoop 资源调度）、K8s（云原生容器调度）；任务编排：Airflow/Oozie（工作流调度）——两类层级不同

  • 查询与 SQL 层

    • 离线数仓：Hive（SQL 转 MapReduce/Spark）；跨源查询：Presto/Impala；交互式：Spark SQL（批）；实时流：Flink SQL

  • 分析与应用层

    • Notebook（Zeppelin/Jupyter）、BI 报表、机器学习（Spark MLlib/TensorFlow）

• 协助记忆

  • 口诀：“采集（Kafka/Flume）→ 存储（HDFS/HBase）→ 计算（Hadoop 批、Spark 内、Flink 流）→ 调度 YARN、查询 Hive/Presto”。

• 进阶思考

  • 批处理和流处理的典型技术演进？
    • 早期批处理 MapReduce（磁盘慢）→ Spark（内存快）统一批；流处理早期 Storm/Spark Streaming（微批）→ Flink（真流式、低延迟、Exactly-once）。现代趋势“批流一体”（Spark/Flink 都能做批+流）。
  • 为什么需要 Kafka 这一层（采集和存储之间）？
    • 缓冲削峰（高并发写入不压垮下游）、解耦（采集/消费独立）、持久化（可回溯重放）、多消费（一份数据多方用）。是实时链路的核心枢纽。

• 扩展信息

  • 技术栈全景：采集（Flume/Kafka/Sqoop/Canal）、存储（HDFS/HBase/Kudu）、计算（MapReduce/Spark/Flink）、调度（YARN/K8s）、查询（Hive/Presto）、分析（MLlib/Zeppelin）
  • 选型思路：离线批量归 Spark、实时流归 Flink、SQL 数仓用 Hive/Spark SQL、海量 KV 用 HBase

🤔 Hadoop 的核心组件有哪些？各自的作用是什么？

• Hadoop 四大核心模块：HDFS（分布式文件存储）、YARN（统一资源调度）、MapReduce（分布式计算框架）、Hadoop Common（公共工具库）。加上配套生态 ZooKeeper（协调）/Hive（SQL）。核心：“HDFS 存、YARN 调度资源、MapReduce 算——三驾马车加公共库”。

  • HDFS（分布式文件系统，存储）

    • 作用：海量数据分布式存储（NameNode 管元数据 + DataNode 存数据块），自动副本容错
    • 特点：一次写入多次读取、高吞吐、适合海量离线数据

  • YARN（资源调度管理器，资源）

    • 作用：统一管理集群计算资源（CPU/内存），调度作业（ResourceManager 管全局、NodeManager 管单点、ApplicationMaster 管单个作业）
    • 特点：资源池化、多计算引擎（MapReduce/Spark/Flink）共用

  • MapReduce（计算框架）

    • 作用：离线批处理（Map 分片处理 + Reduce 汇总），Hive 底层可经它；Spark 为独立执行引擎（不经 MapReduce）
    • 特点：磁盘重度、吞吐低（逐步被 Spark 取代），但仍是 Hadoop 经典算法思想

  • Hadoop Common（公共库）

    • 作用：公共工具（FS 文件系统抽象、RPC、Config 配置、序列化），其他模块依赖

  • 生态配套（易问）

    • ZooKeeper（分布式协调，HDFS/HBase 高可用依赖）、Hive（SQL 查询）、Sqoop/Flume（数据进出）

• 协助记忆

  • 口诀：“HDFS 存、YARN 调度资源、MapReduce 算——Common 打底，生态 ZK/Hive 配套”。

• 进阶思考

  • HDFS 为什么适合海量离线不适合实时？
    • HDFS 高吞吐（顺序大文件读）、一次写多次读——适合批处理/归档；但随机小文件读写慢（Block 大/元数据集中 NameNode）、延迟高，不适合实时小查询（那是 HBase/Kafka 的事）。
  • YARN 怎么让多个计算引擎共存？
    • YARN 只管资源（CPU/内存），不管计算逻辑——MapReduce/Spark/Flink 各自提交 ApplicationMaster 到 YARN 申请容器跑任务，共用集群资源，按需分配（队列/优先级）。所以集群“一鱼多吃”。

• 扩展信息

  • Hadoop 发行版：Apache Hadoop、CDH/HDP（商业版，已并入 Cloudera）；运维常基于发行版 + Ambari/CM 管理
  • Hadoop 定位：海量离线数据的基础设施；实时/交互场景外移到 Spark/Flink/HBase

🤔 Hadoop 集群有哪些关键进程及作用？

• HDFS 有 NameNode（元数据）+DataNode（数据块）+（HA 时 ZKFC/JournalNode）；YARN 有 ResourceManager（资源）+NodeManager（节点）+ApplicationMaster（作业）。核心：“NameNode 管目录、DataNode 管块、RM 管资源、NM 管单点”。

  • HDFS 进程

    • NameNode：管理文件系统元数据（目录/文件/块映射），响应客户端请求；是集群大脑，Active/Standby（HA）
    • DataNode：存储数据块（Block），定期上报 NN（心跳+块报告）；坏块检测/副本复制
    • JournalNode/ZKFC（HA 时）：JournalNode 存共享元数据日志（QJM），ZKFC 通过 ZK 自动主备切换
    • SecondaryNameNode：旧版辅助合并 EditLog（非备份，生产多用 HA）

  • YARN 进程

    • ResourceManager：全局资源调度（接收作业、分配 Container、管理队列），Active/Standby
    • NodeManager：单节点资源管理器（上报资源、启动/监控 Container）
    • ApplicationMaster：每作业一个（申请资源、调度作业内任务、管理生命周期）——作业级临时进程（随作业生灭，非集群常驻守护进程，与 RM/NM 层级不同）

  • 其他（生态）

    • ZooKeeper（HDFS/HBase/YARN HA 的协调）、Hive（Metastore）、HBase（HMaster/RegionServer）

• 协助记忆

  • 口诀：“HDFS：NN 管元数据、DN 存块；YARN：RM 管资源、NM 管节点、AM 管作业；HA 靠 ZKFC+JournalNode”。

• 进阶思考

  • NameNode 挂了集群会怎样？
    • NameNode 挂 → HDFS 停止服务（DataNode 还在但元数据不可读），数据不丢（数据在 DataNode）；HA 下由 Standby 经 ZKFC 自动接管（RPO 很小），单 NN 需人工恢复（从 FSImage+EditLog 重启）。所以生产必须 HA。
  • DataNode 宕机一个会丢数据吗？
    • 不丢。DataNode 宕机 → 其上的 Block 副本减少（低于 3），HDFS 检测到后自动在健康节点复制补齐副本（replication），不影响数据可用性（只要副本未降到 min.replication 下限）。

• 扩展信息

  • 进程端口：NameNode 9870/8020、DataNode 9864、ResourceManager 8088/8032、NodeManager 8042、JournalNode 8485
  • 运维检查：jps 看各节点进程、hdfs dfsadmin -report 看数据节点、yarn node -list 看资源节点

🤔 简述 HDFS 的工作原理？

• HDFS 是分布式文件系统：文件被切分成数据块（Block，默认 128MB），块副本（默认 3 份）分布在多个 DataNode 上；NameNode 只需记录元数据（目录/文件→块映射，块→DataNode 映射由 DataNode 上报/心跳动态维护、不持久化），不存数据；读写都先向 NameNode 查询块位置，再与 DataNode 传输数据。核心：“NN 管元数据 + DN 存块副本，读写‘元数据到 NN、数据到 DN’”。

  • 核心设计（主从架构）

    • NameNode：只管元数据（命名空间、块映射），不存数据——数据流与元数据分离
    • DataNode：存数据块（Block），心跳+块报告上报 NN
    • 数据块（Block）：文件切块（默认 128MB），大于 Block 的块自动切分；副本默认 3——放置策略是 1 副本本机架、2 副本异机架、第 3 副本与第 2 副本同机架（跨机架容错，非全部相异）

  • 写入流程（客户端）

    • ①客户端向 NameNode 请求写入（创建文件/申请块）②NN 返回 DataNode 列表（按机架策略选 3 个）③客户端直接与 DataNode 建立管道（pipeline）写入数据（不经过 NN）④逐副本流水线写（DN1→DN2→DN3）⑤写满一个 Block 再申请下一个，全部确认后 NN 提交
    • 特点：数据流不经过 NN（省 NN 压力），管线式写副本

  • 读取流程（客户端）

    • ①向 NameNode 查询文件块位置②NN 返回块所在的 DataNode 列表（含副本）③客户端就近选择 DataNode 直接读，并行读多个块；④DN 断连自动切换到其他副本

  • 副本管理

    • 副本不足自动复制、副本过多自动删除（replication 因子），均衡（balancer），坏块/宕机触发再复制

• 协助记忆

  • 口诀：“NN 管元数据（哪块在哪）、DN 存数据（块副本）；读走 NN 查位置、直连 DN 传数据；块 128M、副本 3、跨机架”。

• 进阶思考

  • 为什么数据流不经过 NameNode（关键设计）？
    • NameNode 是单点/元数据服务，若数据也流经它 → 成瓶颈 + 单点压力大。所以 NN 只做“目录服务”（告诉客户端去哪些 DN 读写），数据直接客户端↔DataNode 传输——吞吐高、NN 轻。
  • Block 为什么设 128MB 那么大？
    • 大块减少元数据量（NN 内存有限，块越小元数据越多）、减少 MapReduce 任务数（块即处理粒度）、顺序读友好（大数据量高吞吐）。但块太大会牺牲小文件/随机读性能。

• 扩展信息

  • 读写命令：hdfs dfs -put/cat/get、hdfs dfsadmin -report（块/节点）、hdfs fsck（文件完整性检查）
  • 关键参数：dfs.blocksize(128M)、dfs.replication(3)、dfs.namenode.name.dir/datanode.data.dir（存储路径）

🤔 HDFS NameNode 高可用是怎么实现的？

• HDFS HA 用“主备 NameNode + 共享元数据 + 自动切换”：两个 NN（Active/Standby）共用共享元数据日志（QJM 或 NFS），ZKFC 经 ZooKeeper 仲裁实现自动故障切换（failover）。核心：“Active 提供服务 + Standby 实时同步元数据（JournalNode），ZKFC 监控并自动切换”。

  • 核心组件（QJM 模式）

    • 两个 NameNode：Active（读写）、Standby（实时同步元数据，随时接管）——消除单点
    • JournalNode（QJM = Quorum Journal Manager）：一组（≥3 个，奇数）存共享的 EditLog——Active NN 写日志、Standby NN 读日志实时应用（保持元数据一致），JN 用仲裁（多数派）
    • ZKFC（ZooKeeper Failover Controller）：每个 NN 旁一个，监控本 NN 心跳、经 ZooKeeper 维护 Active 锁，Active 异常时自动触发切换（Standby 升 Active）
    • ZooKeeper：提供 Active 锁与会话协调（不直接检测 NN 故障/选主——真正监控本 NN 心跳、持 ZK 锁并触发升 Active 的是 ZKFC；fencing 靠 znode 锁 + 纪元号防脑裂双主）

  • 工作流程（HA 原理）

    • ①Active NN 写入时把元数据变更写 JournalNode（多数派确认）②Standby NN 实时从 JN 读 EditLog 并应用（保持同步）③ZKFC 监控，Active 失联 → 抢 ZK 锁，Standby 升 Active（先 fencing 隔离旧 Active）④客户端经 Namenode 虚拟 name（配置自动访问新 Active）

  • 数据保障（关键）

    • fencing：切换前先隔离旧 Active（避免两个 NN 同时写，脑裂）——QJM 的 fencing 机制（fence 旧节点不再接受写）
    • 数据不丢：Standby 已同步元数据（RPO≈0），接管后数据完整；DataNode 同时向两个 NN 汇报块信息

  • 存储构建议

    • NameNode×2 + JournalNode×3（奇数）+ ZK×3 → 提供集群元数据高可用（挂一个 NN/JN/ZK 都不影响）

• 协助记忆

  • 口诀：“双 NN（主备）+ JN 共享日志 + ZKFC 自动切换 + ZK 仲裁——fencing 防脑裂，数据不丢”。

• 进阶思考

  • Standby NameNode 是“热备”还是只是备份？
    • 热备（非备份）：它实时从 JN 同步元数据（EditLog），保持和 Active 一致，故障时能即时接管（不像 SecondaryNameNode 只是周期性合并日志、非实时）。它不做读写，但元数据最新。
  • JournalNode 起了什么关键作用？
    • 它是元数据的“共享存储/传输层”：Active 写、Standby 读——让两个 NN 元数据一致，且用多数派（≥3 挂 1 可用）保证日志不丢。是 HA 的核心（替代旧版 SecondaryNameNode 的定期合并方案）。

• 扩展信息

  • HA 两种共享方式：QJM（JournalNode 多数派，推荐）+ 旧版 NFS 共享 EditLog；新版还有 NameNode 滚动升级（rolling upgrade）
  • 运维检查：hdfs haadmin -getServiceState（看主备）、hdfs haadmin -failover（手动切换）、ZK 状态 zkServer status

🤔 简述 YARN 资源调度流程？

• YARN 资源调度：作业经 ResourceManager（全局）+ ApplicationMaster（作业级）+ NodeManager（节点级）协作——RM 分配 Container，AM 向 RM 申请容器（allocate）、指派给作业内任务，NM 负责启动/监控容器。核心：“RM 管全局资源、AM 管单作业申请、NM 管节点容器”。

  • 核心角色

    • ResourceManager（RM）：全局资源调度（接收作业请求、按队列/容量分配 Container、管理调度器）——集群资源管理员
    • ApplicationMaster（AM）：每作业一个（向 RM 申请资源、把任务切分、向 NM 发起容器、监控作业）——作业的“管家”
    • NodeManager（NM）：单节点资源管理（上报资源、启动/停止 Container、监控）——节点上的“执行者”

  • 作业调度流程（以 MapReduce 为例）

    • ①客户端提交作业到 RM（ApplicationMaster 请求）②RM 分配第一个 Container，启动作业的 AM③AM 初始化作业（切分 InputSplit、规划 Map/Reduce 任务）④AM 向 RM 申请更多 Container（按资源需求）⑤RM 根据调度器（容量/公平）分配 Container（指定节点）⑥AM 联系 NM 启动任务容器（Map/Reduce），NM 执行并回报进度⑦任务完成，AM 回收资源并通知 RM，作业结束

  • 调度器（资源分配策略）

    • 容量调度器（Capacity）：按队列分配（yarn.scheduler.capacity，队列内 FIFO/资源占比）——生产常用
    • 公平调度器（Fair）：队列内公平共享（动态分配、支持抢占），适合多用户共享
    • 调度器决定“给谁、给多少”——租户/队列隔离、优先级

  • Container（资源单元）

    • 资源抽象（CPU 核 + 内存 + 等），流程：AM 申请 → RM 调度器分配 → NM 启动，任务在 Container 里跑

• 协助记忆

  • 口诀：“RM 发资源、AM 作业申请、NM 跑容器——客户端提交→RM 启 AM→AM 申请→NM 执行→回收”。

• 进阶思考

  • 为什么引入 ApplicationMaster（相比旧 JobTracker 集中调度）？
    • 旧 MapReduce v1 的 JobTracker 既管资源又管作业，单点 + 瓶颈。YARN 把“资源管理（RM）”与“作业调度（AM 每个作业一个）”解耦——RM 只管资源，各作业 AM 自行调度，横向扩 + 多计算框架共存（Spark/Flink 各自 AM）。
  • 队列/资源隔离怎么用（多租户）？
    • 容量调度器按队列划分（queue_a/queue_b 各占资源比例），队列内可设最大/最小资源、优先级、ACL（谁可提交）——实现多部门资源共享又互不挤占，关键作业可保底资源。

• 扩展信息

  • 调度相关：CapacityScheduler/FairScheduler、yarn.scheduler.capacity.root.queues 队列配置、elastic/preemption 抢占
  • 运维：yarn application -list/status、yarn node -list、yarn queue -status（队列状态）、ResourceManager UI（8088）

🤔 YARN 的核心组件有哪些？

• YARN 四大核心：ResourceManager（全局资源调度）、NodeManager（节点资源）、ApplicationMaster（作业调度）、Container（资源容器）。核心：“RM 管全局、NM 管节点、AM 管作业、Container 是资源单元”。

  • ResourceManager（RM）

    • 全局资源管理（接收作业、调度 Container、维护集群资源状态）；HA 时 Active/Standby
    • 内含 Scheduler（资源分配策略：容量/公平）+ ApplicationsManager（作业生命周期管理：接纳作业提交、为 AM 协商首个 Container、跟踪并重启失败 AM）

  • NodeManager（NM）

    • 单节点资源管家（上报节点资源、启动/监控 Container、健康检查），一个节点一个
    • 与 RM 心跳保持节点存活/资源可用

  • ApplicationMaster（AM）

    • 每作业一个（向 RM 申请 Container、切分任务、指派给 NM、监控作业）；Spark/Flink/MapReduce 各有 AM

  • Container

    • 资源抽象（CPU+内存+其他），是任务的运行单元（在 NM 上启动的进程）
    • 生命周期：AM 申请 → RM 分配 → NM 启动 → 任务完成回收

• 协助记忆

  • 口诀：“RM 全局、NM 节点、AM 作业、Container 资源——四级协同调度”。

• 进阶思考

  • AM 为什么不是集群级而是作业级？
    • 每个作业一个 AM，作业间调度互不干扰、天然隔离：作业挂只影响自己；多种计算引擎（MR/Spark/Flink）各自实现 AM 即可接入 YARN。这就是 YARN “通用资源调度平台”的关键。
  • NodeManager 失联会怎样？
    • RM 定时收 NM 心跳，超时（yarn.nm.liveness-monitor.expiry-interval-ms）判定节点失联 → 其上 Container 被标记失败、任务重试（AM 在其他 NM 重新分配），资源释放回收。节点恢复后重新上报资源。

• 扩展信息

  • 调度器：CapacityScheduler/FairScheduler（yarn.resourcemanager.scheduler.class）
  • 运维命令：yarn node -list、yarn application -list/-status/-kill、yarn queue -status、jstack/日志（ResourceManager 8088 / NodeManager 8042 UI）

🤔 Hadoop 集群如何扩容？

• Hadoop 扩容分两种：加数据节点（HDFS 存储扩容，DataNode）和加计算节点（YARN 计算扩容，NodeManager）。步骤：新节点准备（环境/依赖）→ 部署 DataNode+NodeManager 进程 → 加入集群（NN/RM 识别）→ 数据均衡（HDFS balancer，新节点填满）。核心：“加 DN 扩存储、加 NM 扩计算，DataNode 自动上报、balancer 均衡数据”。

  • 扩容前准备（新节点）

    • 环境就绪（JDK 版本一致、Hadoop 目录/配置复制、主机名/hosts、SSH 免密（分发用）、时间同步）
    • 配置一致（core-site.xml/hdfs-site.xml/yarn-site.xml 与现有集群一致）、slaves/workers 文件加入新节点
    • 磁盘挂载/数据目录（datanode.data.dir）就绪

  • 部署进程（DataNode + NodeManager）

    • 新节点执行 hdfs datanode（存储）+ yarn nodemanager（计算），通过 start-dfs.sh/start-yarn.sh 或单独启动
    • DataNode 启动后向 NameNode 注册（上报块），NodeManager 向 ResourceManager 注册（上报资源），自动纳入集群

  • 加入与验证

    • hdfs dfsadmin -report：新 DataNode 出现在 Live datanodes；yarn node -list：新 NodeManager 显示
    • 集群状态健康（NN/RM 正常），无异常

  • 数据均衡（HDFS balancer）

    • 新 DataNode 初始为空——HDFS 默认不自动均衡存量数据（不主动把健康副本迁到新节点）；只有新写入按放置策略偏向空闲节点；存量分布靠手动 hdfs balancer（低峰/定时执行）让数据均匀
    • balancer 参数（带宽/阈值），低峰执行（占 IO）

  • 注意事项

    • 只加 DataNode（存）不加 NodeManager（算）也行（按需），反之亦然
    • 扩容后新写入偏向新节点（DataNode 只承接新增数据）；YARN 资源自动增加（NodeManager 上报）；存量数据需 hdfs balancer 迁移

• 协助记忆

  • 口诀：“新节点备环境 → 装 DN/NM → 自动注册上报 → hdfs balancer 均衡数据——加 DN 扩存储、加 NM 扩计算”。

• 进阶思考

  • 扩容会中断集群吗？
    • 不会。Hadoop 支持在线/水平扩容——新节点加入是渐进的（DataNode 上报即服务），旧节点不受影响；数据均衡是后台（balancer）渐进迁移。但要控制 balancer 带宽避免占满 IO 影响业务（低峰执行）。
  • 数据倾斜（扩容后新旧节点不均）怎么办？
    • HDFS 均衡靠 balancer（按 DataNode 磁盘使用率），不均时手动 hdfs balancer -threshold 调；YARN 资源自动均摊（NM 上报）。大数据量迁移慢，分阶段 + 监控磁盘使用率。

• 扩展信息

  • 相关命令：hdfs balancer（数据均衡）、hdfs dfsadmin -report（节点）、yarn node -list、jps（验证进程）
  • 配置：slaves/workers 文件、dfs.replication、yarn.nodemanager.resource.memory-mb（目标节点资源）、datanode.data.dir（磁盘）

🤔 Spark 与 MapReduce 的核心区别是什么？

• Spark 与 MapReduce 的核心区别是计算模型与中间存储：MapReduce 每步 Map/Reduce 都要落磁盘（HDFS），迭代慢；Spark 用内存的 RDD（弹性分布式数据集）+ DAG 调度，中间结果驻内存、多步算子链式执行，比 MR 快 10-100 倍。核心：“MR 磁盘迭代慢、Spark 内存 DAG 快且统一批流”。

  • 计算模型

    • MapReduce：Map（切分处理）→ Shuffle（按 key 分组）→ Reduce（汇总）；每阶段中间结果落本地盘（mapred.local.dir，非 HDFS——仅 Reduce 最终输出写 HDFS），多阶段作业频繁读写磁盘
    • Spark：RDD（内存数据集）算子在 DAG 上链式执行，中间结果默认驻内存（可缓存/持久化），少落盘；Shuffle 也优化

  • 性能（核心差异）

    • 迭代计算（机器学习/多轮 join）：MR 每轮落盘（慢），Spark 内存缓存（快 10-100x）
    • 交互/Spark SQL 查询：Spark 响应快

  • 编程与抽象

    • MR：map/reduce 函数（Java，繁琐）；Spark：RDD/DataFrame/Dataset 高层 API（Python/Scala/SQL），transformation（惰性）+ action（触发）
    • Spark 惰性：转换操作不立即执行，遇 action（count/collect）才按 DAG 调度执行

  • 能力范围

    • MR：仅批量离线（Hive/MR）；Spark：批处理 + Spark SQL + Spark Streaming(微批) + MLlib(机器学习) + GraphX(图)——统一一个引擎
    • 运行模式：Spark 可用 YARN/K8s/Standalone（Mesos 已弃用——3.2 起弃用、4.0 移除）

  • 实际定位

    • 老 Hadoop MapReduce 仍在（历史兼容），新项目普遍用 Spark（内存 + 统一 + 快）

• 协助记忆

  • 口诀：“MR 磁盘慢、Spark 内存快；MR 一步一落盘、Spark DAG 链式算；Spark 批流 SQL 一锅端”。

• 进阶思考

  • Spark 为什么比 MR 快这么多（除了内存）？
    • ①内存缓存中间结果（少磁盘 IO）②DAG 调度（任务间依赖清晰、stage 内并行、避免 MR 的无谓落盘）③算子优化（Spark 把多个操作合并、优化 Shuffle）④DataFrame 有 Catalyst 优化器（列式/谓词下推）。内存 + 智能调度 + 优化器共同作用。
  • Spark 内存不够（OOM）怎么办（和 MR 比）？
    • MR 落盘天然内存安全（慢）；Spark 内存敏感——靠：调 spark.executor.memory、数据分区（repartition/coalesce）、序列化、Shuffle 分区数、避免大 collect。Spark 用空间换时间，内存管理是调优核心。

• 扩展信息

  • Spark 生态：Spark Core（RDD）、Spark SQL（DataFrame）、Spark Streaming（DStream）、MLlib、GraphX
  • MR vs Spark 选型：离线大规模、已有 MR 生态用 MR（兼容）；交互/迭代/流用 Spark（性能）

🤔 Spark 核心组件有哪些？

• Spark 核心：Spark Core（RDD 基础）、Spark SQL（结构化查询/DataFrame）、Spark Streaming（微批流）、MLlib（机器学习）、GraphX（图计算）。运行框架上：Driver（主程序）+ Executor（执行器）+ Cluster Manager（YARN/K8s/Standalone）。核心：“Core 打底 + SQL/Streaming/MLlib/GraphX 四组件 + Driver/Executor 架构”。

  • 核心库（组件）

    • Spark Core：RDD（弹性分布式数据集）+ 调度（DAG+Stage+Task）+ 运行时——一切的基础
    • Spark SQL：DataFrame/Dataset，SQL 查询 + Catalyst 优化器 + Hive 兼容（thriftserver）
    • Spark Streaming：微批流处理（DStream，把流切成小批）；Structured Streaming 基于 DataFrame/Dataset API，属 Spark SQL 引擎（非 DStream 子集）
    • MLlib：分布式机器学习（特征/分类/聚类/推荐算法），Pipeline 流程化
    • GraphX：图计算（PageRank/社区发现），基于 RDD 的图 API

  • 运行时架构（Driver/Executor）

    • Driver：SparkContext/SparkSession——作业入口，切分 DAG → Stage → Task，调度分发；管理作业生命周期
    • Executor：Worker 上的执行进程（跑 Task、缓存 RDD），多个 Task 并行执行
    • Cluster Manager：资源调度（YARN/K8s/Standalone；Mesos 已弃用）——Driver 和 Executor 跑在上面

  • 数据抽象

    • RDD（基础，低层）、DataFrame（Schema 化，优化好）、Dataset（类型化，Scala/Java 用）——DataFrame/Dataset 经 Catalyst 优化

• 协助记忆

  • 口诀：“Core 打底（RDD），SQL/Streaming/MLlib/GraphX 四组件；运行 Driver 调度 + Executor 干活 + Cluster Manager 给资源”。

• 进阶思考

  • Driver 挂了会怎样？
    • Driver 是作业大脑，挂了作业失败（Executor 还在但无人调度/收结果）。生产要 Driver 高可用（YARN 下 AM 重启、K8s 下 Driver Pod 重启），Driver 网络/内存要监控。
  • Executor 数/核怎么定？
    • 影响并行度与资源利用：Executor 数 × 核数 ≈ 集群可并行任务上限；内存给够（别 OOM）但别过大（GC 压力）。权衡：executor 数量、每 executor 核数/内存、并行度（parallelism）——经典调优三元组。

• 扩展信息

  • 生态：Spark + Hive（ThriftServer 支撑 SQL）、Spark on YARN 最常用、Structured Streaming（现代实时）
  • 可选：Spark 3.x 的 AQE（自适应查询执行）、Dynamic Allocation（动态分配）、PySpark（Python 写 DataFrame）

🤔 简述 Spark Job 提交后的执行流程？

• Spark 作业提交后：Driver 构建 DAG → 划分 Stage（按 Shuffle 边界）→ 生成 Task（按分区）→ DAGScheduler 提交给 TaskScheduler → Cluster Manager 分配资源 → 各 Executor 执行 Task → 结果回 Driver。核心：“RDD 算子 → DAG → Stage 切分 → Task 分发执行”。

  • 执行流程（分阶段）

    • ①客户端 submit 作业 → Driver（SparkContext/SparkSession）初始化
    • ②Driver 把 RDD 算子链构建成 DAG（有向无环图，记录转换关系）
    • ③DAGScheduler 把 DAG 按**Shuffle 边界**切成 Stage（ShuffleMapStage：写 Shuffle；ResultStage：产出结果）
    • ④Executor 先经 Cluster Manager（YARN/K8s/Standalone）在应用启动时分配并注册
    • ⑤每 Stage 按分区（Partition）生成 Task（ShuffleMapTask/ResultTask），TaskScheduler 派发给各 Executor 并行执行
    • ⑥ShuffleMapTask 输出 Shuffle 中间数据；ResultStage 的 ResultTask 计算最终结果
    • ⑦Task 结果回 Driver（或直接写外部存储）——整个流程由 action 触发启动（如 count/collect）

  • 关键概念

    • DAG：算子的依赖图（转换关系）——Driver 用它做优化/调度
    • Stage：DAG 按 Shuffle 切分（窄依赖一个 Stage，宽依赖 Shuffle 分 Stage），Stage 内部 Task 并行
    • Task：任务最小执行单元（每分区一个），在 Executor 上跑
    • 懒执行：transformation 只记 DAG，遇 action（count/collect/saveAsTextFile）才触发真正执行

  • 失败处理

    • Task 失败自动重试（spark.task.maxFailures）、Stage 失败重算、检查点（checkpoint）断点

• 协助记忆

  • 口诀：“RDD 算→DAG 图→Shuffle 切 Stage→分区产 Task→Executor 并行跑→action 触发执行”。

• 进阶思考

  • 为什么按 Shuffle 划分 Stage？
    • Shuffle（如 groupByKey/join）需要数据全部到达后按 key 汇总——是天然的执行边界（Stage 边界）。Shuffle 前可流水线（窄依赖合并），Shuffle 后新 Stage。这样 Stage 内并行、Stage 间依赖（Shuffle 落盘），任务划分清晰。
  • DAG 调度和 MapReduce 的作业划分有何不同？
    • MR 是固定 Map→Shuffle→Reduce 两阶段（不管步骤多少都是这两步，多步就多次 MR 落盘）；Spark DAG 把整条算子链按 Shuffle 切 Stage，Stage 内多算子合并执行（不分步落盘）——更灵活高效。

• 扩展信息

  • 易混淆：Job（一个 action 触发的一个 DAG）、Stage（DAG 按 Shuffle 切）、Task（Stage 内分区任务）——层级关系：Job → Stage → Task
  • 运维：Spark UI（看 Job/Stage/Task 耗时/Shuffle 大小）、日志（Driver/Executor）、event log

🤔 Spark 有哪几种运行模式？

• Spark 四种运行模式（按资源管理/部署）：Local（本地单机调试）、Standalone（Spark 自带集群）、YARN（Hadoop 生态，生产主流）、K8s（云原生容器）。核心：“本地调试 Local、自带集群 Standalone、Hadoop 上 YARN、云原生 K8s”。

  • Local 模式

    • 单机多线程（spark-submit --master local[n]），不启动集群——开发/调试用
    • 特点：最快上手，无真实集群/分布式（测试代码用）

  • Standalone 模式

    • Spark 自带的简单集群（Master + Worker），不依赖 Hadoop——小集群/快速部署
    • 特点：部署简单、无 YARN 生态时用；但资源管理/多租户弱于 YARN

  • YARN 模式（生产最常用）

    • 作业提交到 Hadoop YARN（yarn-client/yarn-cluster），由 ResourceManager 调度资源，与 Hive/MR 共用集群——生产主流
    • 特点：资源统一管理、多框架共用、高可用（YARN HA）、队列隔离/配额
    • yarn-cluster（Driver 跑在 YARN，AM 管理）：生产推荐

  • K8s 模式（云原生）

    • Spark 作业跑在 Kubernetes（Pod），K8s 调度资源——云原生/容器化环境
    • 特点：容器隔离、弹性、与云生态集成（S3/HDFS 存储）

  • 选型

    • 调试 Local、小集群/自建 Standalone、Hadoop 生态 YARN、云原生 K8s——生产多 YARN（与 Hive 共用）或 K8s（新架构）

  • 提交方式

    • spark-submit --master yarn --deploy-mode cluster ...；client vs cluster（Driver 在哪跑）

• 协助记忆

  • 口诀：“本地调试 local、自带集群 standalone、Hadoop 上 yarn、云原生 k8s——生产选 yarn/k8s”。

• 进阶思考

  • yarn-client 和 yarn-cluster 区别？
    • client：Driver 跑在提交客户端（本地机器），适合交互式/调试（Driver 在提交机，作业与提交机绑，提交机挂作业挂）；cluster：Driver 跑在 YARN 集群的 AM 容器里（Driver 即 AM 内进程，AM 管理其生命周期），提交后客户端可离开——生产用 cluster（Driver 随 AM 重启、提交机解耦）。
  • Standalone vs YARN 怎么选？
    • 已用 Hadoop（有 YARN/Hive）→ YARN（统一资源、共用集群、队列隔离）；刚起步/不想依赖 Hadoop、资源管理简单 → Standalone（轻量，但多租户/高可用弱）。

• 扩展信息

  • Master URL：local[*]、spark://host:7077（standalone）、yarn、k8s://https://...
  • 配套：--deploy-mode client/cluster、--num-executors/--executor-memory（YARN 下资源）、spark-submit 脚本封装

🤔 Flink 集群有哪些核心组件？

• Flink 集群（Session/Per-job 模式）核心：JobManager（作业管理/调度/Checkpoint 协调）、TaskManager（执行任务/数据流处理）、Job（客户端提交的作业）+ ZK/HA。核心：“JobManager 大脑 + TaskManager 干活 + 可 HA 高可用”。

  • JobManager（JM，作业管理器）

    • 集群主节点——接收作业（JobGraph）、调度 Task 到 TaskManager、协调 Checkpoint/恢复、管理集群状态
    • 高可用：HA 部署（ZooKeeper + 元数据持久化到 HDFS），JobManager 挂可切换
    • 内部：Dispatcher（接收作业）、ResourceManager（分配 TaskManager 资源）、JobMaster（每作业一个管理）

  • TaskManager（TM，任务管理器）

    • Worker 节点——执行 JobManager 分配的 Task（算子/算子链），管理任务线程与内存/网络
    • 一个 TM 跑多个 Task（Slot 资源槽——并发执行的单元，TaskManager.numberOfTaskSlots）

  • Job/客户端

    • 客户端（Flink SQL/DataStream 程序）打包 JobGraph 提交到 Cluster——flink run/Flink SQL CLI
    • 作业提交到 Session Cluster（共享集群）或 Per-job（独立集群实例）

  • HA 与协调

    • ZooKeeper（[JobManager 选主/存储状态]）、HDFS/S3（Checkpoint/Savepoint 存储）
    • Standalone 模式下自建集群；YARN/K8s 模式下由外部调度（Flink on YARN/Flink on K8s）

  • 资源抽象

    • Slot：TaskManager 上的并发单位（一个槽跑一个任务），决定并行度上限

• 协助记忆

  • 口诀：“JobManager 大脑（调度/Checkpoint）+ TaskManager 干活（Slot 跑任务）+ 客户端提交；ZK+HDFS 做 HA/状态存储”。

• 进阶思考

  • JobManager 挂了会怎样（有没有 HA）？
    • 无 HA：作业中断，从头恢复（丢状态）；有 HA：ZK 选新 JobManager，从 Checkpoint 恢复（断点续算），TaskManager 重连。生产必须 HA（JobManager × 多 + ZK）。
  • TM 的 Slot 数和并行度什么关系？
    • Slot 是 TM 上可并行执行的槽位，总 Slot 数 = 集群能支持的最大并行度（容量上限）；作业并行度是独立配置值（env.setParallelism/算子级），需 ≤ 可用 Slot 才能全部同时运行（超出会快速失败 Could not allocate all required slots，非排队），是 Flink 并发与吞吐的关键。

• 扩展信息

  • 部署模式：Standalone/Flink on YARN/Flink on K8s（K8s 下用 Operator 部署）；Session（共享）/Per-Job/Application 模式
  • 运维：Flink Web UI（JobManager 地址）、flink list/savepoint/cancel、Checkpoint 配置（state.backend/CheckpointStorage）

🤔 Flink Checkpoint 是什么？作用？

• Flink Checkpoint（检查点）是周期性自动的全局状态快照：每隔一段时间，JobManager 协调 TaskManager 把算子的状态（KeyedState/OperatorState）+ 数据源偏移量一致地存到持久存储（HDFS/S3），用于故障恢复（作业挂了从最近一次 Checkpoint 重启续算）。核心：“周期自动存一致状态，故障时从检查点恢复，实现 Exactly-once”。

  • 作用（核心价值）

    • 故障恢复：作业/机器挂了，从上次 Checkpoint 恢复（状态 + 数据源 offset 对齐）——不丢数据、少重算
    • Exactly-once 语义基础：配合 state + offset 对齐 + 事务输出（两阶段提交），保证处理恰好一次
    • 是 Flink 流处理可靠性的基石（生产必开）

  • 工作机理

    • CheckpointCoordinator（JobManager）周期触发（checkpoint.interval）屏障（Barrier） 注入数据流
    • Barrier 随数据流流动，算子收到 Barrier 后把状态快照写入 CheckpointStorage（HDFS/S3），所有算子快照完成 → 一个 Checkpoint 成功（n/n 完成）
    • 增量 Checkpoint（RocksDB 增量）、对齐（对齐/非对齐）

  • 配置

    • state.backend（RocksDB/Heap）、checkpoint.interval（频率）、checkpoint.timeout、savepoint（手动）、存储目录（HDFS/S3）
    • Checkpoint 自动、周期；Savepoint 手动、用户触发

  • 与 Savepoint 区别（常问）

    • Checkpoint：自动、周期、触发频率高、用于故障自动恢复、恢复快（默认）
    • Savepoint：手动（flink savepoint）、可指定时间点、用于运维操作（升级/迁移/回滚）、可跨版本恢复

• 协助记忆

  • 口诀：“Checkpoint 周期自动存一致状态（state+offset），故障从它恢复——Exactly-once 基石；Savepoint 手动存、改代码升级用”。

• 进阶思考

  • Checkpoint 怎么做到“一致”（不重不漏）？
    • 用屏障对齐：Barrier 随数据流注入，算子收到本通道 Barrier 后暂停该通道处理、等所有通道 Barrier 到齐再一起快照——对齐属于检查点一致性机制（保证快照时刻状态与 offset 严格对应）；但端到端 Exactly-once 还须配合事务输出（两阶段提交），仅对齐不保证语义。
  • Checkpoint 太频繁会怎样？
    • 频率高：状态快照频繁写存储（IO 压力）、影响吞吐；频率低：恢复时从头重算多。权衡：按状态量/吞吐设间隔（如 30s-5min），配合增量 Checkpoint 减小开销。

• 扩展信息

  • 相关：state.backend（RocksDB/HashMap）、CheckpointStorage（Fs/JobManager）、exactly-once/at-least-once 语义、barrier 对齐/非对齐
  • 运维：flink savepoint/cancel -s、Checkpoint UI（JobManager）、HA 存储（HDFS 目录）

🤔 Flink Savepoint 是什么？作用？与 Checkpoint 区别？

• Flink Savepoint（保存点）是手动触发的全量状态快照，存到持久存储（HDFS/S3）——用于运维操作（升级版本/改并行度/迁移/回滚），可从它 restore 恢复。与 Checkpoint 区别：Checkpoint 自动周期/故障恢复用；Savepoint 手动/运维操作用。核心：“Savepoint 手动存做运维，Checkpoint 自动存做故障”。

  • Savepoint 是什么

    • 用户手动触发（flink savepoint <jobId> <dir>）的作业状态 + 数据源 offset 一致快照（全量）
    • 存到指定路径（savepoint.dir/命令行指定），是作业的“存档点”（可随时恢复）

  • 作用（运维场景）

    • 升级版本：Flink/SQL 升级前打 Savepoint，升级后 restore（跨版本恢复）
    • 改并行度/拓扑：调整并行度后从 Savepoint 恢复（状态重新分配）
    • 迁移/回滚：作业迁移到新集群、改代码后要回滚，Savepoint 恢复到旧状态
    • 人工回溯：想重放到某个时间点（savepoint 记录位置）

  • 与 Checkpoint 区别（重点）

    • 触发：Checkpoint 自动周期（checkpoint.interval）；Savepoint 手动（用户命令）
    • 频率：Checkpoint 频繁（故障恢复）；Savepoint 低频（运维节点）
    • 粒度：Checkpoint 可增量状态（RocksDB）；Savepoint 全量快照
    • 生命周期/用途：Checkpoint 临时（故障自动恢复，可删）；Savepoint 持久（运维存档，长期保留，升级/迁移）
    • 恢复：作业异常自动从最近 Checkpoint 恢复（默认）；人工 flink run -s <savepoint> 从 Savepoint restore

  • 使用

    • 打点（触发存点）：flink savepoint <jobId> [targetDir]（-d/--dispose 是删除 savepoint）；恢复：flink run -s <savepointPath> ...（配合作业同一 JobId/代码兼容）

• 协助记忆

  • 口诀：“Checkpoint 自动周期、故障恢复用；Savepoint 手动、升级/迁移/回滚用——一个保命、一个存档”。

• 进阶思考

  • 为什么升级前一定要 Savepoint 而不是靠 Checkpoint？
    • Checkpoint 是为自动故障恢复设计的（可能被清理/过期、依赖配置、不同版本代理可能不兼容）；Savepoint 是显式存档（全量、指定路径、跨版本设计），改代码/升级后能精确从存档点恢复——运维可预期。
  • Savepoint 恢复条件（容易踩坑）？
    • 恢复到同一个作业/兼容的算子（operator ID 一致）、依赖默认被 state 恢复（uid 设好）、代码拓扑与 Savepoint 匹配（uid/哈希）。改代码要保证算子 uid 稳定，否则恢复失败。

• 扩展信息

  • 对比表：Checkpoint（自动周期/故障恢复/可增量/临时）；Savepoint（手动/运维存档/全量/持久）——Flink 面试高频对比
  • 命令：flink savepoint <jobId> [dir]（打点）、flink stop -s <savepointPath> <jobId>（优雅停止并存点，cancel -s 已废弃）、flink run -s <savepoint>（恢复）、--savepoint 禁用/删除

🤔 Hive 是什么？有哪些核心组件？

• Hive 是把 Hadoop 数据仓库化的 SQL 查询引擎：用户写 HiveQL（SQL），Hive 把它编译成 MapReduce/Tez/Spark 作业跑在 Hadoop 上——让不会写 Java MapReduce 的人用 SQL 分析大数据。核心组件：Metastore（元数据）、Driver（编译器/优化器/执行器）、HQL 解析为 MR 作业。核心：“SQL 查 Hive 表，元数据在 Metastore，作业跑 Hadoop”。

  • Hive 是什么

    • 数据仓库工具（Facebook 起源）：把结构化数据映射成表，SQL 查询转 MapReduce
    • 定位：离线大规模数据分析（ETL/数仓/SQL 报表）——SQL-on-Hadoop

  • 核心组件

    • Metastore（元数据服务）：存表/库/列/分区等元数据（默认内嵌 Derby，生产用 MySQL/PostgreSQL），是 Hive 的“字典”——表和数据的映射关系
    • Driver（驱动/编译器）：①解析（Parser 把 HQL 转 AST）②语义分析（绑定元数据）③逻辑计划 → 物理计划 ④优化（谓词下推/分区裁剪）⑤生成 MapReduce/Tez/Spark 作业 ⑥提交执行
    • 执行引擎：底层由 MapReduce/Tez（更优）/Spark 执行（Execution Engine）
    • 用户界面层：CLI/Beeline/HiveServer2（JDBC 连接）、Thrift API

  • 表类型/HQL 特性

    • 管理表/外部表（External——数据在用户指定路径，Hive 不管理其生命周期，DROP 外部表不删底层数据）、分区表（partition，按字段分区裁剪）、分桶表（bucket）
    • 数据格式：TextFile/Parquet/ORC（列式压缩，快）/Avro；ORC/Parquet 性能优

  • 存储与执行

    • 数据存 HDFS（Hive 只管元数据文件位置，数据在 HDFS）；查询转成后台作业

• 协助记忆

  • 口诀：“Hive = SQL 查数据仓库，Metastore 管元数据、Driver 编译成 MR 作业；分区/列式（ORC）提效”。

• 进阶思考

  • Hive 为什么慢（怎么优化）？
    • 底层是 MapReduce（磁盘、启动开销）；优化：①分区裁剪/谓词下推（少扫数据）②列式存储 ORC/Parquet ③换 Tez/Spark 执行引擎（比 MR 快）④SMB Join/Map Join/Bucketing ⑤调 Reduce 数/内存。瓶颈多为全表扫/数据倾斜/引擎性能。
  • Hive 和 Spark SQL 区别（都是 SQL on Hadoop）？
    • Hive 元数据（Metastore）+ SQL 引擎，底层多 MR（慢但代码兼容）；Spark SQL 基于 Spark（内存快 + Catalyst 优化器），也能读 Hive 元数据（HiveMetastore 共享）。现代更多用 Spark SQL 查询（性能），Hive 表元数据可复用。

• 扩展信息

  • 生态：Beeline/HiveServer2（JDBC 客户端）、ThriftServer、Hive Metastore（共享给 Spark/Presto）、LLAP（Hive 交互式加速）
  • 数仓分层：ODS（原始）→ DWD（明细）→ DWS（汇总）→ ADS（应用），Hive/Spark SQL 做 ETL 各层

🤔 HBase 是什么？有哪些核心组件？

• HBase 是 Hadoop 生态的分布式宽列/列族存储（Key-Value，非传统列存）：海量结构化/半结构化数据的随机实时读写（HDFS 做批处理、HBase 做单点查询）。核心组件：HMaster（管理/分区）、RegionServer（数据服务）、ZooKeeper（协调/选主），底层存 HDFS。核心：“HMaster 管分区、RegionServer 服务读写、数据在 HDFS”。

  • 数据模型

    • 表 → 行键（RowKey）+ 列族（Column Family）+ 列限定符（Qualifier）+ 时间戳（Version）+ 值
    • 稀疏（未定义的列不占存储）、按 RowKey 字典序排序、可多版本——适合海量随机读 + 列动态扩展

  • 核心组件

    • HMaster（主节点）：管理表/Region 分配（RegionServer 负载均衡、故障转移）——不直接收发数据；Region 分裂由 RegionServer 触发并执行（flush→split→生成子 Region），HMaster 只协调分配
    • RegionServer（数据节点）：服务一个或多个 Region（数据分区），处理客户端读写请求（Get/Scan）、MemStore(内存写)+HFile(磁盘落盘)→HDFS、WAL 日志
    • ZooKeeper（协调）：HMaster 选主（HA）、RegionServer 注册/心跳、hbase:meta 表位置（客户端路由）
    • HDFS：底层存储（HFile 数据持久化）

  • 存储流程（写）

    • 客户端 → ZK 找 meta → 定位 RegionServer → RegionServer 写 WAL（日志）+ MemStore（内存缓冲）→ 达到阈值刷写（flush）成 HFile 落 HDFS；Region 大则分裂（split）

  • 适用场景

    • 海量（TB-PB）+ 随机实时读写（时序/日志/用户画像/推荐）——HBase；批处理/离线分析用 Hive/Spark

• 协助记忆

  • 口诀：“HBase = 列式 KV 随机读；HMaster 管分区、RegionServer 服务读写、ZK 协调、数据在 HDFS；写走 WAL+MemStore 再落 HFile”。

• 进阶思考

  • HBase 和 HDFS 什么关系（覆盖还是并列）？
    • HBase 构建在 HDFS 之上：HBase 是把数据组织成 KV 列式、提供随机读写逻辑层，物理数据块存 HDFS。HDFS 只提供文件存储（无随机按 key 查），HBase 在其上加索引/一致性/实时读写。
  • HBase 为什么读快写也快（和 Hive 比）？
    • 写：WAL（顺序写日志）+ MemStore（内存写缓冲）+ 批量刷 HFile（顺序写）——随机写变顺序写；读：MemStore 内存 + BlockCache 缓存 + HFile 索引（按 RowKey 定位，BloomFilter 加速）——按 key 直接寻址。Hive 是全表扫（MR），HBase 是按 RowKey 点查。

• 扩展信息

  • RowKey 设计：RowKey 决定分布（热点考虑，前缀 MD5/加盐避免热点）、长度/顺序（前缀匹配查询优化）——HBase 性能关键
  • 运维：hbase shell（count/scan/get）、Region 分裂/合并、RegionServer 崩溃恢复（WAL 重放）、Hmaster UI(16010)、hbasemeta

🤔 HBase 读写流程是怎样的？

• HBase 读写都先经 ZooKeeper 定位 RegionServer：读走 MemStore+BlockCache+HFile（RowKey 点查/Scan 范围扫）；写走 WAL（日志）+ MemStore（内存缓冲）再异步刷写 HFile 落 HDFS。核心：“写先日志后内存、读按行键定位（内存缓存 + 磁盘 HFile）”。

  • 定位（路由，读写的公共前提）

    • ①客户端访问 ZooKeeper 找 hbase:meta 表的 RegionServer 位置②读 meta 表（缓存），得知要读/写的 RowKey 落在哪个 Region/RegionServer③直连对应 RegionServer 读写（meta 会缓存，减少 ZK 往返）

  • 写入流程

    • ①客户端 Put → 定位到 RegionServer ②RegionServer 写 **WAL（Write-Ahead Log，顺序写日志，先记后写防丢）**③写 **MemStore（内存写缓冲，按 RowKey 排序）**④MemStore 到达阈值 → flush 刷写成 HFile 落 HDFS（StoreFile）⑤Region 过大 → split 分裂为子 Region；HFile 定期合并（compaction）
    • 特点：写是顺序日志 + 内存，快；数据先内存后 HFile

  • 读取流程

    • ①Get（点查）/Scan（范围扫）按 RowKey 定位 RegionServer ②先从 BlockCache（读缓存） 找 ③再从 MemStore（最新未刷写） 找 ④最后查 **HFile（磁盘，RowKey 索引 + BloomFilter 加速）**⑤多文件版本合并（Read 时 MVCC），返回最新数据
    • 特点：缓存优先（冷数据落盘），RowKey 定位快速

  • 一致性/可靠性

    • WAL 保证宕机不丢写（RegionServer 崩，HMaster 拆分其 WAL 并重分配 Region，由新 RegionServer 重放 WAL 恢复——HBase 2.x 走分布式 SplitLog）、MVCC（多版本并发控制）保证读一致性、Region 分裂/合并自动

• 协助记忆

  • 口诀：“定位走 ZK+meta；写：WAL→MemStore→flush 成 HFile；读：BlockCache→MemStore→HFile（按 RowKey）”。

• 进阶思考

  • 为什么写要先写 WAL 再进 MemStore？
    • MemStore 数据在内存（易丢），宕机内存数据全没——WAL 是持久化日志（HDFS 落盘），先记日志再写内存，宕机后从 WAL 重放恢复所有 MemStore 未刷写的数据（不丢）。顺序写日志快，是“写入必持久化”的关键。
  • HBase 读放大/写放大是什么？
    • 写放大：数据频繁 flush/compaction（写多份），MemStore 阈值/compaction 策略影响；读放大：读要查缓存+内存+多个 HFile（版本/MVCC），HFile 多读就慢。compaction 合并文件减读放大、但增写放大——权衡（compaction 策略）。

• 扩展信息

  • RowKey 与读优化：前缀过滤（scan 起止 RowKey）、加盐避开热点、Column Family 别太多（少量大表查询）
  • 运维：Region 分裂/合并（split/merge）、major_compact、hbase hbck（一致性修复）、性能参数（BlockCache/MemStore 大小）

🤔 HBase RegionServer 故障如何排查与恢复？

• RegionServer 故障排查：先看 ZK/HMaster/进程/日志定位，再按“宕机（HMaster 自动接管 Region、WAL 重放）→ 慢（GC/热点/Region 分裂）→ 数据（HFile/WAL 损坏）”处理。核心：“宕机靠 HMaster+WAL 自愈，慢/异常查 GC/热点/磁盘/分裂”。

  • 第一步：定位故障类型

    • HMaster UI/hbase shell 看 RegionServer 状态；ZK 看 RegionServer 是否失联（心跳）
    • 现象分类：宕机（失联/Master 重分配 Region）、慢（Region 在但响应慢）、单 Region 异常、HFile/数据损坏

  • 第二步：宕机排查（数据不丢）

    • RegionServer 挂 → HMaster 检测（ZK 心跳）→ 把其 Region 重新分配到其他 RegionServer → 从 WAL（该机器 HDFS 上的日志）重放恢复未刷写数据
    • 检查：HMaster 日志（RegionServer 失联/Region 重新上线）、Region 是否恢复、网络/磁盘/GC（为何挂）
    • 重点：RegionServer 宕机不丢数据（WAL+副本），但恢复期间 Region 短暂不可用

  • 第三步：慢/异常排查

    • GC 停顿：RegionServer 大 GC（Full GC）卡住——调 JVM GC 参数/MemStore/BlockCache（MSLAB/off-heap 优化）、GC 日志分析
    • 热点：RowKey 设计不当（单一 RowKey 集中某 RegionServer）——加盐/前缀分散
    • Region 分裂/合并过多：频繁 split/compaction 占资源——调分裂/合并策略
    • 磁盘/HDFS：HFile 读写慢（磁盘满/HDFS 节点异常）、StoreFile 过多

  • 第四步：极端数据损坏

    • HFile 损坏/WAL 异常 → HBase 2.x 用 HBCK2（hbck2，一致性检查/修复；1.x 用 hbase hbck）、hbase hfile（查看/校验 HFile）、必要时从副本/快照恢复
    • 数据恢复：Snapshot（表快照）恢复某表

• 协助记忆

  • 口诀：“RegionServer 挂了 HMaster 接管 + WAL 重放（不丢数据）；慢/异常查 GC/热点/分裂/磁盘——先宕机自愈、再性能排查”。

• 进阶思考

  • RegionServer 宕机数据会丢吗（为什么）？
    • 不丢。写数据先落 WAL（HDFS 持久化）+ MemStore；宕机时 MemStore 数据虽在内存，但 WAL 已记录，HMaster 重分配 Region 后从 WAL 重放回放——数据恢复。这是 HBase 可靠性的关键（写必日志）。
  • 一个 RegionServer 挂了会影响多少数据？
    • 影响它管理的那几个 Region（短暂不可用，Master 重分配期间）；其他 RegionServer 不受影响——Region 是数据分布单位，故障影响面=该 RegionServer 的 Region。Region 分布均衡（Master 平衡）让故障影响局部化。

• 扩展信息

  • 相关命令：hbase shell（status/regioninfo）、HMaster UI(16010)、hbase hbck、snapshot（快照）、RegionSplit/MajorCompact
  • 优化：GC 调参（HBASE_REGIONSERVER_OPTS）、MSLAB/off-heap BlockCache、RowKey 加盐、隔离（RegionServer 不同 HDFS）

🤔 ZooKeeper 在大数据体系中的作用是什么？

• ZooKeeper 是大数据体系的分布式协调服务：提供一致性、选主、配置、命名、状态同步——HDFS HA（ZKFC 选主）、HBase（HMaster 选主/meta 路由）、YARN（RM HA）、Kafka（控制器选主）都依赖它。核心：“ZK 做选主/状态存储/命名/协调，是大数据组件高可用的『脑』”。

  • 核心能力

    • 选主（分布式锁/Leader 选举）：HA 组件（NameNode/HMaster/ResourceManager）经 ZK 用临时节点 + 序号选主，主挂自动切换
    • 配置/状态存储：存集群配置/状态（HBase meta 位置、Kafka 分区状态、ZKFC 状态），数据节点（znode）持久化
    • 命名/服务注册：组件注册（Register）、发现（ZK 谁在哪），客户端经 ZK 定位服务
    • 协调/同步：分布式同步、锁、Barrier（协同多节点）

  • 在大数据组件中的具体作用

    • HDFS HA：ZKFC 经 ZK 监控 NameNode 心跳、维护 Active 锁（选主），自动故障切换
    • HBase：HMaster 选主（HA）、RegionServer 注册、hbase:meta 表位置（客户端路由）、分布式 SplitLog 协调
    • YARN：ResourceManager HA（ZK 选主 + 状态存储）
    • Kafka（经典 ZK 版，3.x 起已迁移 KRaft、4.0 完全移除 ZK）：Controller 选主（分区 leader 变更）、元数据（broker/topic）
    • Flume/Storm：配置/状态协调（Flume ZK 做负载/高可用）

  • 数据模型

    • 树状节点（znode）：持久/临时（ephemeral，会话结束自动删）/顺序（sequential）——选主靠临时+顺序节点
    • 监听（watch）：节点变更通知（Watcher）——组件实时感知状态变化

  • 部署建议

    • 奇数节点（3/5/7），过半 Quorum——少数派不能选主/写；部署在独立机器（不与 HDFS/HBase 同机抢资源）

• 协助记忆

  • 口诀：“ZK 做协调：选主（HA）、存状态（meta/配置）、命名注册、watch 通知——HDFS/HBase/YARN/Kafka 的高可用靠它”。

• 进阶思考

  • 为什么大数据 HA 都依赖 ZooKeeper（它这么重要）？
    • 这些组件需要一主多备 + 自动切换：主挂要让备顶上，且不能“脑裂”（双主）。ZK 用临时节点 + 多数派 + watch 提供强一致的选主/锁——组件把“谁是主/状态在哪”交给 ZK 统一仲裁，就能实现可靠 HA。
  • ZK 的 Quorum 为什么必须奇数？
    • 选主/写入需多数派确认（quorum = n/2+1）：奇数节点（3/5/7）能以最少节点获得最大容错——3 挂 1、5 挂 2（偶数 4 挂 1 与 3 相同，浪费一台且不增容错）。所以 ZK 集群用奇数。

• 扩展信息

  • 运维：zkServer.sh status（看 follower/leader）、zkCli.sh（查节点/stat）、4lw（ruok/stat 四字命令）、zoo.cfg（server.x 对称）
  • 高可用依赖：凡是 HA（HDFS/HBase/YARN/Kafka）都离不开 ZK——ZK 本身挂是严重故障（先抓 ZK 再抓上层组件）

🤔 你们的数据是如何进入 Hadoop 的？数据采集方案？

• 进入 Hadoop 的数据采集按来源分：①日志采集（Flume/Kafka 收业务/服务器日志）②数据库同步（Sqoop/DataX/Canal 整库或增量）③消息实时（Kafka 流进 HDFS/HBase）④文件/接口（HDFS 上传、FTP/API）。核心：“日志走 Flume+Kafka、库走 Sqoop/Canal 增量、实时走 Kafka 管道，落地 HDFS/Hive”。

  • 日志采集（最常见）

    • Flume：多级采集（source 收日志 → channel 缓冲 → sink 写 HDFS/Kafka），Agent 分布各服务器
    • Logstash/Filebeat：ELK 生态（日志采集 + 解析），适合日志检索
    • 架构：应用日志 → Flume Agent（采集）→ Kafka（缓冲）→ HDFS（落地）/Spark 实时

  • 数据库同步（结构化数据）

    • Sqoop：Hadoop 与关系库（MySQL/Oracle）批量导入导出（全量/增量 --incremental）——已进入低维护/事实弃用（末版 1.4.7），现多被 Flink CDC/SeaTunnel/DataX 取代，仅作存量/备选
    • Canal：伪装 MySQL slave 读 binlog 增量（实时同步到 Kafka/HDFS）
    • DataX：阿里开源，多源到多目标（MySQL→HDFS/HBase）通用同步

  • 实时/消息流

    • Kafka：日志/binlog/点击流先入 Kafka（缓冲削峰），消费端落 HDFS 或 Spark/Flink 实时计算
    • Kafka Connect/flume-kafka、Spark Structured Streaming/Flink 消费 Kafka 写 HDFS/Hive

  • 文件/接口

    • HDFS CLI（hdfs dfs -put 上传文件）/WebHDFS（HTTP PUT，curl 调 REST）、FTP/API 采集导入、OSS/S3 对象同步

  • 方案设计要点

    • 缓冲削峰（Kafka）、批量/增量（Sqoop 增量、Flume 批量）、容错/重试（采集失败重试、Kafka 重放）、延迟控制（数据新鲜度：离线 T+1、实时秒级）
    • 数据入 Hive/HDFS 分区（按天/小时），便于查询裁剪

• 协助记忆

  • 口诀：“日志 Flume+Kafka、库 Sqoop 增量/Canal 实时、流 Kafka 管道落 HDFS/Hive——缓冲+批量+分区，离线在线分层”。

• 进阶思考

  • Kafka 在数据接入里起了什么作用（为什么都要它）？
    • 缓冲削峰（高并发写入不压垮下游）、持久化可重放（数据丢了能回溯）、解耦（采集与消费独立扩展）、多消费（一份数据给实时/离线多路）。几乎所有实时链路都把它当“中转枢纽”。
  • 离线（T+1）和实时（秒级）怎么一起做？
    • 同一份 Kafka 数据，一路消费写 HDFS/Hive 分区表（离线批处理 T+1），一路 Flink/Spark Streaming 实时计算（秒级）——批流分离，一源多吃。数据先统一进 Kafka，再分发给离线/实时两条链。

• 扩展信息

  • 工具：Flume/Filebeat/Logstash（日志）、Sqoop/DataX/Canal（库）、Kafka（消息）、WebHDFS/HDFS CLI（文件）
  • 数仓接入：ODS 层（原始数据入库）→ 清洗进 DWD；Hive/Spark SQL 做 ETL

🤔 大数据集群如何做存储容量规划？副本、存储增长率考量？

• Hadoop 存储容量规划：可用容量 = 裸容量 ×（1/副本数），并预留 20-30% 缓冲防满，按存储增长率（每日新增 × 保留周期）估算需求。核心：“裸容量除副本数,留 20-30% 缓冲,按日增长×保留期预测,HDFS 别到 full”。

  • 容量估算公式

    • 裸容量：所有 DataNode 磁盘总和（如 30×16T=480T）
    • 副本损失：默认副本 3 → 可用 = 裸容量/3（约 160T）；副本 2 →/2（更省但容错弱）
    • 需考虑元数据/临时文件：HDFS 临时、File 移动、replication 平衡——实际可用再打折
    • 预留缓冲：留 20-30%（防冲到 full 拒写、临时峰值、block 不均衡、数据倾斜——某节点满）

  • 存储增长率考量（关键）

    • 日增量：每日新增数据量（GB/TB）——日志/业务增长、采集频率
    • 保留周期：数据保存天数（HDFS 保留 N 天，过期清理）——T+1 数仓保留、原始/中间/结果层保留不同
    • 年化增长：按 月均增长 × 12 规划 1-2 年扩容节奏
    • 公式：需要容量 = 日增量 × 保留天数 × 副本系数 / 可用率（留 30% 缓冲则 /0.7，留 20% 则 /0.8——二选一写明）

  • 数据分层与冷热

    • 原始层（ODS）量大短期留、中间层（DWD/DWS）保留、结果层（ADS）小长期留——不同层不同副本/保留
    • 冷数据降副本（replication=2）/迁移（到低成本存储）、HDFS 生命周期（Trash/删除策略）

  • 容量监控

    • hdfs dfsadmin -report（容量/DataNode 使用率）、HDFS 使用率告警——80% 是运维告警阈值（非 HDFS 内置限制，真正拒写在 DataNode 磁盘近满触及 dfs.datanode.du.reserved 预留区）
    • 关注单节点倾斜（某 DataNode 满，balancer 均衡）、block 冗余

• 协助记忆

  • 口诀：“可用 = 裸容量/副本数，留 20-30% 缓冲；按‘日增量 × 保留天数 × 副本 / 0.7’估算，数据分层/冷热降副本”。

• 进阶思考

  • 副本 3 是不是浪费（能不能降）？
    • 副本 3 保高可用（容 2 副本挂不丢）；成本敏感可：核心/热数据副本 3、冷/可重建数据副本 2（replication 调低）或 EC（纠删码，用较少冗余换容量）。权衡容错与成本。
  • 存储满了（HDFS 快满）怎么应急？
    • ①清理过期/临时数据（Trash/生命周期）②降冷数据副本 ③扩容（加 DataNode）④balancer 均衡倾斜节点（防单点满）⑤检查数据倾斜/block 冗余。别等 full（拒写阻断业务），提前 80% 告警。

• 扩展信息

  • 相关参数：dfs.replication（副本）、dfs.datanode.du.reserved（预留）、dfs.blocksize（块大小影响元数据量）、trash 配置
  • 监控：hdfs dfsadmin -report、Capacity 指标、Ambari/Prometheus（HDFS 容量/使用率告警）

🤔 Ambari 都监控哪些指标？

• Ambari（Hadoop 集群管理面板）监控分——注：Ambari 已进入维护期、被 CDP/Cloudera Manager 取代（指标底层 HDP 2.x 用 Ganglia/Nagios，2.4+ 用 AMS）：集群健康（HDFS/YARN/HBase/ZK 组件状态、NameNode/ResourceManager 状态）、资源（集群 CPU/内存/磁盘/网络）、服务级（DFS 容量/DataNode 块、YARN 队列、HBase Region）、主机（DataNode/NodeManager 版本、磁盘/负载）。核心：“Ambari 看集群服务健康 + 主节点状态 + 主机资源，告警驱动运维”。

  • 集群/服务健康（重点）

    • 服务状态（HDFS/YARN/HBase/Hive/ZK/MapReduce 是否 STARTED/INSTALLED/异常）
    • 主节点 NameNode/ResourceManager/HMaster 健康（Active/Standby、fsimage/editlog 状态）
    • HDFS 状态：dfsadmin report（Live/Dead DataNode、容量、under replication 副本不足）、NameNode 内存/元数据

  • 资源指标（主机/集群）

    • CPU 使用率/负载、内存（used/swap）、磁盘（使用率/IO）——主机级 DataNode/NodeManager
    • 网络（带宽）、I/O（磁盘吞吐）

  • YARN 指标

    • 集群资源（Vcores/内存总量/已用）、队列（Capacity/Fair 队列使用率、pending/running）、作业（Application 运行/失败/Killed）
    • NodeManager 健康、Container 使用

  • HBase/Hive 指标

    • HBase：RegionServer 状态/Region 数、MemStore/BlockCache/compaction、HMaster 状态
    • Hive：Metastore 状态、HiveServer2 会话/HQL 执行

  • 告警与运维

    • Ambari 内置告警（服务 down、磁盘满、NameNode 切换、ZK 节点失联），可配阈值/通知（邮件/webhook）
    • 配合指标（Grafana/Prometheus）做趋势/容量预警；告警分级（CRITICAL/MAJOR/MINOR）

• 协助记忆

  • 口诀：“Ambari 看服务健康（HDFS/YARN/HBase/ZK）+ 主节点（NN/RM）+ 资源（CPU/内存/磁盘）+ 队列/Region——告警分级驱动运维”。

• 进阶思考

  • Ambari 和 Cloudera Manager/Prometheus 分工？
    • Ambari/CM：集群管理 + 服务健康（部署/配置/服务状态/告警）——运营层面；Prometheus+Grafana：细粒度指标采集展示（YARN/HDFS/Node 性能曲线）——监控层面。常组合：Ambari/CM 管集群、Prometheus 看指标趋势。
  • Ambari 监控到 NameNode 切到 Standby 意味着什么？
    • NameNode 故障切换（HA 触发）——可能主节点故障/失联/ZKFC 判定，要查原 Active 为何挂（内存/磁盘/GC/网络），并确认新 Active 接管正常。这是 HDFS 高可用关键告警。

• 扩展信息

  • 相关：Ambari 指标可在 Grafana 展示（Ambari Metrices）、Cloudera Manager（CDH 版）、Prometheus + node_exporter
  • 运维建议：Ambari 告警（服务/主机状态）+ Prometheus 指标（趋势/容量）+ 日志（HDFS/YARN 日志分析）三层监控

🤔 简述 HDFS 读写完整流程？

• HDFS 读写完整流程（客户端）：读先向 NameNode 查块位置，就近从 DataNode 并行读；写向 NN 申请块，客户端直连 DataNode 管线式写副本（数据不经过 NN）。核心：“读走 NN 查位置 + 直连 DN 并行读；写 NN 分配 + DN 管线写副本”。

  • 读取流程

    • ①客户端 open('/file') → 向 NameNode 请求（getBlockLocations）②NN 返回文件各 Block 的位置（DataNode 列表，含副本）③客户端就近选择 DataNode（网络近者优先）④直连 DataNode 读取 Block 数据（数据流不经 NN）⑤多个 Block 并行/顺序读，DFSInputStream 聚合 ⑥读完关闭；某 DN 故障自动切换到其他副本（read retry）

  • 写入流程

    • ①客户端 create('/file') 向 NN 创建命名空间元数据（校验权限/目录）②写时经 addBlock 向 NN 逐个申请 Block，NN 返回 DataNode 列表（按机架感知选 3 个写目标）③客户端与第一个 DN 建立管线（pipeline），packet 分包写数据 → DN1 → DN2 → DN3（逐副本流水线传输、ack 按包回传）④一个 Block 写完再申请下一 Block ⑤全部写完，客户端调 NN 关闭（close），NN 提交（文件可见）
    • 特点：数据流经管线各 DN（副本），不经过 NN；DN 写失败自动换/调整副本

  • 关键细节

    • NameNode 只做元数据/调度（不传数据），数据路径客户端↔DataNode——NN 轻、吞吐高
    • 副本管线写：DN 间透明传输（DN1 从客户端收再转 DN2…），DFSOutputStream 管理 packet/ack
    • 副本策略（写时选 DN）：机架感知（replica 分布不同机架）、就近、HDFS 写副本的默认放置策略

• 协助记忆

  • 口诀：“读：NN 问位置、就近 DN 并行读（DN 挂换副本）；写：NN 分配 DN、DN 管线写 3 副本——元数据走 NN、数据走 DN”。

• 进阶思考

  • 为什么读要并行读多个块？
    • 大文件切成多个 Block（128M）分布在多个 DataNode，客户端 DFSInputStream 对多个块并行读取——多个 DN 同时供数据，读吞吐成倍提升（带宽叠加）。这就是 HDFS 高吞吐的关键之一。
  • 写文件时某 DataNode 挂了怎么办？
    • 管线中断：客户端检测到写失败，NN 重新分配副本（pipeline 更新），副本不足先降级写（short-circuit），其余副本继续；恢复后补齐副本（replication）。写不丢（副本容错），但性能/进度受影响。

• 扩展信息

  • 命令：hdfs dfs -put（写）、-cat/-get（读）、-ls（列表）、hdfs fsck（块检查）、dfsadmin -safemode（安全模式）
  • 性能：读写缓冲、block 大小、DataNode 数量/网络、副本数影响（多/快但占用大）

🤔 HDFS 文件上传、下载、删除和修改的底层机制？

• HDFS 操作底层机制：上传=管线写块副本；下载=按块并行读；删除=移 Trash（可恢复）+ 延迟删块；修改（写）：HDFS 不支持随机修改（追加 append 有限支持、改内容需重写文件），元数据被 NN 记录、数据分布 DN。核心：“上传写块、下载读块、删除进 Trash、HDFS 只追加不随机改”。

  • 上传（写）底层

    • hdfs dfs -put → 客户端向 NN 申请块 → DN 管线写副本（如前述）——数据切块、副本分布 DN、元数据 NN 记录
    • 写时流式（DFSOutputStream，packet 分包/ack 确认），块满申请新块

  • 下载（读）底层

    • hdfs dfs -get/cat → NN 查块位置 → 客户端就近并行读 DN（多块并行、DFSInputStream 聚合）→ 合并成完整文件

  • 删除底层

    • hdfs dfs -rm → 文件移入 Trash（回收站） 可恢复（-rm 先删到 Trash）——注意 fs.trash.interval 默认 0=禁用 Trash，需显式配置开启（企业发行版常默认启用）
    • Trash 过期后真正删除：NN 更新元数据（删除文件/块映射），块被标记删除，DataNode 后台实际删除块（block 删除由 DN 异步执行）
    • -rm -skipTrash（跳过 Trash 直接删）；回收站防误删

  • 修改底层（关键：HDFS 不支持随机写）

    • HDFS 语义“一次写、多次读”——不支持随机覆盖/修改文件中间内容（hdfs 无 random write）
    • 支持的修改：追加（append，-appendToFile 尾部追加新数据，dfs.support.append 控制、Hadoop 2.x 默认 true）、重命名（mv 元数据变更）、改副本数（setrep 只动元数据、触发副本调度，不碰内容）、改权限（chmod）
    • 所以要改文件内容 → 重写（overwrite 新文件覆盖）或 append；这是 HDFS 与普通文件系统最大差异

• 协助记忆

  • 口诀：“上传管线写块、下载并行读块、删除进 Trash 可恢复；HDFS 只追加不随机改——改内容=重写/append”。

• 进阶思考

  • 为什么 HDFS 不支持随机修改（设计取舍）？
    • 为高吞吐/海量而设计：随机写要定位/维护块内偏移（复杂、冲突）；而“一次写多次读”适合批处理（MapReduce/Hive）场景，避免并发写一致性难题。追加/重写已够离线大数据（数据不可变、追加日志类）。
  • 删除文件为什么进 Trash 而不是马上删？
    • 防误删（运维/批处理脚本删错能恢复）；Trash 过期（可配置天数）后才真正删块，给用户“后悔药”。违反保留期的紧急删除可用 -skipTrash（谨慎）。

• 扩展信息

  • 相关命令：-put/-get/-rm/-appendToFile/-mv/-chmod/-setrep、fs.trash.interval/fs.trash.checkpoint.interval（回收站配置）
  • Trash 配置：core-site.xml 的 fs.trash.interval（分钟，0=禁用）、fs.trash.checkpoint.interval（清理检查周期）

🤔 HDFS DataNode 坏块产生原因有哪些？如何修复？

• DataNode 坏块原因：磁盘物理损坏/坏道、DataNode 异常宕机/进程崩溃、读写中断（网络/校验失败导致 CRC 校验不过）、HDFS 块校验（checksum）不一致。修复：HDFS 自动——检测到坏块 → 从健康副本复制补齐（replication 纠错）；配合 hdfs fsck 检查、DataNode 报 bad 块让 NN 标记、必要时换盘/重新复制。核心：“坏块 HDFS 自动用副本自愈，fsck 检查 + 换盘兜底”。

  • 产生坏块的原因

    • 磁盘故障：物理坏道/扇区损坏/磁盘彻底损坏（bad blocks）
    • DataNode 宕机：进程崩溃/JVM 异常——结果是其块副本缺失/under-replicated（非“坏块 corrupt block”，NN 调度副本补齐）
    • 校验失败：读写时 CRC32 校验不一致（数据损坏/传输错误，checksum 不一致是损坏的表现而非成因）——DataNode 读取验 checksum
    • 网络/写入中断：写 block 时网络故障/写入不完整（部分写），块被视为坏
    • 低版本/配置：DataNode 重启、block 与 NN 记录不一致

  • HDFS 自动修复机制（副本容错）

    • ①DataNode 定期向 NN 报告块（block report），NN 对比副本数（expected replication）——副本不足则调度补充
    • ②某 DataNode 校验失败/坏块 → 上报 NN → NN 标记该 block 副本损坏 → 其他健康block 副本补上（replicate），坏副本被替换
    • ③DataNode 宕机 → NN 判 dead → 其块副本在健康节点复制补齐（under replication 修复）
    • 结果：只要副本 ≥1 健康，HDFS 自动复制补齐，数据不丢（副本 3 容 2 坏）

  • 人工排查/修复

    • hdfs fsck / -files -blocks：检查文件/块完整性（坏块/缺失副本/under replicated）
    • hdfs fsck / -files -blocks -racks（块分布）、-list-corruptfileblocks（列损坏块）
    • hdfs dfsadmin -report：看 DataNode 健康/坏盘、hdfs dfsadmin -safemode（安全模式排查）
    • 坏盘/坏块处理：坏 DataNode 磁盘 → 换盘（datanode 下线、新盘）或 hdfs 移除该数据节点（decommission）
    • DataNode 重启恢复（临时故障）、fsck 修复（-replicate/-delete 可选项）

• 协助记忆

  • 口诀：“坏块多因磁盘坏/宕机/校验失败——HDFS 靠副本自动自愈（fsck 检查、NN 补副本）；人工换盘/下线坏节点”。

• 进阶思考

  • 为什么 HDFS 有副本，坏块数据还能恢复？
    • 副本 3 分布在多个 DataNode，一个副本坏，其他健康副本在——NN 检测倒数（replication 不足 3）后，从健康副本复制补齐到健康节点，坏副本被剔除。只要不超容错上限（1-2 副本坏），数据不丢自动修复。
  • 发现坏块高频了（经常 fsck 有坏块）要警惕什么？
    • 可能是磁盘老化/大面积坏道（硬件级别），或 DataNode 不稳定（内存/JVM/网络）、坏盘未换——需排查磁盘健康（smartctl）、DataNode 日志、NN 元数据一致性，及时换盘/下线。频繁坏块是硬件/稳定性的预警信号。

• 扩展信息

  • 相关命令：hdfs fsck（完整性）、hdfs dfsadmin -report（数据节点）、hdfs dfsadmin -metasave、smartctl（磁盘健康）
  • 预防：磁盘监控（SMART/RAID）、DataNode 巡检、副本数合理、DataNode 日志（datanode.log）检查、备份

🤔 YARN 集群资源充足，但 MapReduce 任务调度很慢，如何排查？

• 资源充足但任务调度慢：先看 YARN 调度器（队列/DAG 依赖/资源隔离）→ 再看作业（Map/Reduce 数量、数据倾斜、Shuffle 量）→ 最后看 NameNode/网络/日志。常见：小文件多（Map 任务数爆炸）、数据倾斜（单 Map 拖尾）、Reduce 数不合理、队列/资源配额（AM 排队）、InputSplit 切片太大/小。核心：“任务多/倾斜/队列受限/切片问题——看 JobHistory/RM UI 定位”。

  • 第一步：确认“慢”在哪一层

    • ResourceManager UI 看作业状态（Submitted/Running）：是排队（资源没给/队列受限）还是运行慢（任务执行慢）
    • YARN 日志/JobHistory（jobhistoryserver）看作业 Map/Reduce 阶段耗时
    • 区分：调度慢（作业迟迟不跑/排队）vs 执行慢（跑了但单任务慢）——排查方向不同

  • 第二步：排查“调度/排队”

    • 队列资源受限：队列 Capacity/Fair 配额不够（yarn queue -status 看 used/pending），作业 AM 排队——调队列配额/优先级
    • AM 启动限制：yarn.scheduler.maximum-am-resource-percent（AM 资源占比上限，AM 启动慢多因它）；yarn.scheduler.maximum-allocation-mb/-vcores 约束所有容器（非 AM 专属）
    • 资源碎片/阻塞：Container 请求但无足够连续资源（YARN 资源粒度/NodeManager 配置）、max-am-resource-percent
    • NodeManager 资源：节点 vcores/内存上限（yarn.nodemanager.resource.memory-mb/cpu-vcores）

  • 第三步：排查“作业执行慢”

    • 小文件多：大量小文件 → Map 任务数爆炸（InputSplit 每文件一个），调度/启动开销大——CombineFileInputFormat/归档（Har）/合并小文件
    • 数据倾斜：某 Key 数据多 → 单个 Map/Reduce 处理慢（拖尾）——combiner/采样/自定义分区/加盐
    • Reduce/Map 数量不当：Reduce 数（mapreduce.job.reduces）过少 Reduce 慢、过多调度开销；块大小影响 Map 数
    • Shuffle 量大：Reduce 拉取 Map 输出多/慢——Shuffle 占网络/磁盘，combiner 减传输、speculative 推测执行
    • NameNode/HDFS 瓶颈：元数据/块读写慢（NN 内存/磁盘）、DataNode 磁盘 IO 慢

  • 第四步：看日志/工具

    • JobHistory（mapreduce 作业耗时）、RM/NM 日志、Map/Reduce task 耗时（Task 进度）、hdfs fsck（块健康）
    • YARN Web UI（8088）看队列/Container/AM、JobTracker（旧）

• 协助记忆

  • 口诀：“先看调度（排队？队列配额/AM 限制）再看执行（小文件/倾斜/Reduce 数/Shuffle）——队列限就调配额、任务多/斜就优化作业”。

• 进阶思考

  • 小文件多为什么让调度变慢（不只任务多）？
    • 每个小文件一个 InputSplit → 一个 Map 任务，任务数成千上万；YARN 调度各 Map 到 Container（启动 JVM、分配资源）开销巨大，且 HDFS 读小文件元数据次数多（NameNode 压力）——调度/启动开销淹没计算。治理：合并小文件/SequenceFile/归档/CombineFileInputFormat。
  • 数据倾斜怎么判定（常见算法）？
    • JobHistory 看各 Map/Reduce 耗时（有个别 task 耗时远超平均→倾斜）；或 Map 输出 Key 分布（Counter/采样看某 Key 占比高）。处理：combiner（Map 端预聚合）、随机加盐（倾斜 Key 分桶）、自定义分区（TotalOrderPartitioner）。

• 扩展信息

  • 参数：mapreduce.job.reduces（Reduce 数）、mapreduce.input.fileinputformat.split.minsize（切片）、yarn.scheduler.capacity.root.queues（队列）、yarn.nodemanager.resource.memory-mb（节点资源）
  • 工具：YARN Web UI、JobHistory、Ganglia/Ambari（资源曲线）、日志（yarn logs -applicationId）

🤔 Spark 作业发生 OOM 内存溢出，如何排查与调优？

• Spark OOM 分两类：Executor 堆内存溢出（Executor OOM）与 Driver OOM。排查：先看是哪个阶段 OOM（Map/Shuffle/Reduce、collect）→ 再归因（数据倾斜、Shuffle 量大、缓存过多、分区小/聚合大、collect 到 Driver 大结果）→ 调优（executor 内存/并行度/Shuffle 分区/数据倾斜避让）。核心：“OOM多因聚合/Shuffle/cache/collect 放大内存——定位阶段、治倾斜、调资源与分区”。

  • 第一步：定位 OOM 在哪

    • Spark UI（executor 日志/Accumulator）看 task/stage 阶段；OOM 常在：groupByKey（无预聚、全量 Shuffle 到内存）、aggregateByKey（仅聚合中间值极大时）、join（大 Shuffle）、collect/take 到 Driver、cache/persist 大 RDD
    • 区分：Executor OOM（executor 堆不够）vs Driver OOM（collect/广播变量/Driver 侧聚合）

  • 第二步：归因

    • 数据倾斜：某 Key 数据巨多 → 单 task 处理超大（聚合/Shuffle 分区不均）——最常见
    • Shuffle 分区数不足：spark.sql.shuffle.partitions（SQL）/defaultParallelism 少 → 单 task 数据多、聚合内存大
    • cache/persist 过度：把大量/大 RDD 缓存，占满内存——缓存策略不当
    • 宽依赖/聚合：groupByKey（全量 Shuffle 到内存）比 reduceByKey（预聚合）耗内存
    • collect 大结果：collect() 全量拉回 Driver（大数据量爆内存）
    • 单条记录大：大字段（String/数组）堆积（Row 内存）

  • 第三步：调优（对症）

    • 资源：调 spark.executor.memory/--executor-memory、spark.executor.cores、spark.driver.memory（Driver OOM）、spark.memory.offHeap.enabled/spark.memory.offHeap.size（堆外内存，需开启才生效）
    • 数据倾斜治理：预聚合（reduceByKey/combineByKey 替代 groupByKey）、加盐（倾斜 Key 加随机前缀分桶）、广播小表（broadcast join 替代大 join）、重分区（repartition/coalesce 均衡）
    • Shuffle 分区：spark.sql.shuffle.partitions 调大（并行度↑、单任务数据↓）、spark.default.parallelism
    • cache 策略：persist 用 MEMORY_AND_DISK（溢出到磁盘）、只缓存复用多次的小/中型 RDD、unpersist 释放
    • 避免 collect：用 show/take/write（输出到存储）替代全量 collect；foreach 分区处理
    • 序列化：kryo 序列化、compress，减少对象内存

  • 第四步：监控/日志

    • Spark UI（stage/task 内存/Shuffle 量）、executor 日志（OutOfMemory/GC）、event log
    • jstat/GC 日志（GC 频繁/Full GC 说明内存紧）

• 协助记忆

  • 口诀：“先定位阶段（聚合/Shuffle/collect/cache），再归因（倾斜/分区少/缓存多），对症：加资源、治倾斜（reduceByKey/加盐/广播）、调分区、慎 collect”。

• 进阶思考

  • groupByKey 为什么比 reduceByKey 更易 OOM？
    • groupByKey 把每个 Key 的所有值原样 Shuffle 到内存（Iterable），无预聚合；reduceByKey 在 Map 端先预聚合（合并部分值）再 Shuffle，传输/内存少。大数据聚合用 reduceByKey/combineByKey（带预聚合），避免 groupByKey。
  • Shuffle 分区不足为什么导致 OOM（而不是慢）？
    • Shuffle 分区数决定每个 Reduce 分区处理的数据量——分区少，单 reduce task 数据量大、聚合进内存爆；分区多则单任务数据小（内存安全）但任务多。spark.sql.shuffle.partitions 设大（如 200-2000）防单分区过大，与数据量匹配。

• 扩展信息

  • 参数：spark.executor.memory/cores/driver.memory、spark.sql.shuffle.partitions、spark.memory.fraction（堆内份额）、spark.serializer=KryoSerializer、spark.broadcast.blockSize
  • 治理手段：reduceByKey/aggregateByKey（预聚合）、broadcast join、加盐、repartition、persist(MEMORY_AND_DISK)、AQE（Spark 3 自适应）

🤔 Hive 查询慢，如何分步排查优化？

• Hive 查询慢排查：先看执行计划（EXPLAIN）和是哪个阶段慢（Map/Reduce/Join/聚合）→ 再归因（全表扫/数据倾斜/Reduce 数不当/Map 任务少/无谓词下推）→ 对症（分区裁剪/列式存储/换 Tez/Spark/Map Join/SMB Join/调 Reduce 数）。核心：“EXPLAIN 定位 + 治全表扫/倾斜/Join，换引擎减 MR 开销”。

  • 第一步：看执行计划/定位慢点

    • EXPLAIN <query> 看执行计划（Map/Reduce/Join 阶段、数据流转）；EXPLAIN EXTENDED 看细节
    • 看各阶段耗时（Tez/Spark UI 或 Hive 日志）：是 Map 慢（扫/过滤）、Shuffle（倾斜）、Reduce（聚合）还是 Join
    • 看 Hive UI/Azkaban（作业耗时、Map/Reduce 数）

  • 第二步：定位常见瓶颈

    • 全表扫：缺分区条件/WHERE 未过滤分区列——主因是表未分区或查询没按分区列过滤（谓词下推默认开启、ORC/Parquet 自动生效，非“没启用”）；用分区裁剪少扫数据
    • 数据倾斜：Join/Group By 某 Key 数据多（单 Reduce 慢）——hive 倾斜优化（hive.optimize.skewjoin/GroupBy map端聚合）
    • Reduce 数不当：mapreduce.job.reduces 太少（Reduce 慢）/太多（启动开销）；hive.exec.reducers.bytes.per.reducer（每 reducer 处理字节）
    • Map 任务少：大文件块大/split size 大 → Map 数少（单 Map 慢；mapred.map.tasks 只是上限提示不真增 Map 数）——调小 mapred.max.split.size/合并小文件
    • Join 大表：大表 Join 大表（Shuffle 慢）——Map Join（小表广播）/bucketing join/SMB
    • 无 Map 端聚合：Group By 没开 hive.map.aggr=true（Map 端预聚合减 Reduce 压力）

  • 第三步：优化（对症）

    • 分区裁剪/谓词下推：表用分区（partition）+ 查询 WHERE 分区列——不扫无关分区；ORC/Parquet 列式（读所需列、谓词下推）
    • 列式+压缩：ORC/Parquet（比 TextFile 快、省空间），ZSTD/Snappy 压缩
    • 换执行引擎：hive.execution.engine=tez（DAG、内存，比 MR 快）或 spark——大幅提速
    • Join 优化：Map Join（hive.auto.convert.join=true，小表广播内存 join）、Bucketing+SMB Join、sort-merge
    • 聚合优化：hive.map.aggr=true（Map 端预聚）、hive.groupby.skewindata（倾斜分摊）、distinct 优化
    • 小文件合并：输入小文件多 → CombineHiveInputFormat/merge（减少 Map 数）；Reduce 数匹配
    • 其他：分桶（bucket，join/抽样快）、CBO（hive.cbo.enable=true 统计驱动优化）、limit/采样（先小批看数据）

  • 第四步：数据侧

    • 看数据是否倾斜（group by 的 Key 分布）、字段类型（int vs string）、NULL 处理（null 也会成为 Key，hive 倾斜优化）

• 协助记忆

  • 口诀：“先 EXPLAIN 定位 → 治全表扫（分区/列式）、倾斜（map 聚合/skewjoin）、Reduce 数、Join（map join/bucket）——换 Tez/Spark 提效大头”。

• 进阶思考

  • 为什么换 Tez/Spark 引擎能大幅提速（核心）？
    • MapReduce 每阶段落磁盘（HDFS），多阶段就多次磁盘 IO + 作业启动开销；Tez 用 DAG（Map-Map-Reduce 链式，中间不强制落盘、AM 调度），Spark 内存计算——减少磁盘往返，大数据量下快数倍。引擎是 Hive 提速最快一招。
  • 数据倾斜在 Hive 里最典型的表现与处理？
    • 表现：Group By/Join 阶段单个 Reduce/Task 卡很久，其他 Reduce 早结束——某 Key 数据量远大于平均。处理：Map 端预聚（map.aggr）、skewindata（两阶段倾斜分摊）、skewjoin（倾斜 Key 单独处理）、加盐/广播小表。

• 扩展信息

  • 参数：hive.execution.engine（mr/tez/spark）、hive.map.aggr、hive.auto.convert.join、hive.optimize.skewjoin、mapreduce.job.reduces、hive.cbo.enable
  • 工具：EXPLAIN、Tez/Spark UI、HiveServer2 日志、Azkaban（调度作业耗时）、Grafana（集群资源）