成为一名大数据平台SRE需要具备哪些基础技能-附录

HDFS HA 工作原理

1. 双NameNode架构

   • Active NN：处理客户端请求，管理命名空间。
   • Standby NN：实时同步元数据，准备接管故障的Active NN。

2. 元数据同步

   • QJM（Quorum Journal Manager）：Active NN将EditLog写入奇数个JournalNode（JN），Standby NN从JN读取更新。
   • ZKFC：监控NameNode状态，通过ZooKeeper协调主备切换。

3. 故障转移流程

   1. ZKFC检测到Active NN异常（心跳超时）。
   2. ZooKeeper触发选举，Standby NN转换为Active状态。
   3. 新Active NN从QJM获取最新EditLog，恢复服务。

4. 脑裂防护

   • 切换前隔离旧Active NN（通过SSH强制kill进程）。
   • QJM确保同一时间只有一个NN可写入EditLog。

5. 客户端访问

   • 通过Logical NameService（如hdfs://mycluster）透明访问，无需关心实际NN地址。

通过上述机制，HDFS HA实现了NameNode级别的高可用。

HDFS 数据冗余策略

1. 多副本存储

   • 默认3副本，可通过dfs.replication调整。
   • 流水线写入：客户端→DataNode1→DataNode2→DataNode3。

2. 机架感知放置

   • 2副本：1个本地节点，1个跨机架节点。
   • 3副本：1个本地，1个跨机架，1个同机架不同节点。

3. 副本维护

   • NameNode通过心跳检测Under/Over-Replicated块，自动复制/删除副本。
   • 故障时（如DataNode宕机），触发副本重建。

4. 动态调整

   • 命令行：hdfs dfs -setrep 5 /path
   • 存储策略：HOT（磁盘）、WARM（混合）、COLD（归档）。

5. 空间优化

   • 纠删码（如RS-3-2）用5块存储3块数据，节省40%空间（HDFS 3.0+）。

YARN 核心调度原理

1. 三层架构

   • ResourceManager（RM）：全局资源调度，维护集群可用资源和应用队列。
   • NodeManager（NM）：节点上的资源监控与容器管理。
   • ApplicationMaster（AM）：每个应用的“代理”，向RM请求资源，与NM通信启动任务。

2. 资源抽象

   • Resource：用CPU和内存（如16核+64GB）量化资源。
   • Container：资源分配的基本单位（如2核+8GB），任务在Container中运行。

3. 调度器类型

   • FIFO Scheduler：单队列，按提交顺序调度，大作业会阻塞后续任务。
   • Capacity Scheduler：多队列（如prod、dev），每个队列有容量限制，支持优先级。
   • Fair Scheduler：多队列，动态平衡资源，短作业可快速获取资源（如Spark SQL查询）。

4. 调度流程

   1. 用户提交应用，RM为其分配AM容器。
   2. AM向RM注册，持续请求资源（如“需要10个2核+8GB的Container”）。
   3. RM根据调度策略（如容量、公平性）分配Container。
   4. AM与NM通信，启动任务。

5. 关键机制

   • 资源抢占：当队列资源不足时，低优先级应用的Container可被强制回收。
   • 资源隔离：通过cgroups（Linux）限制Container的CPU/内存使用，防止相互干扰。
   • 节点标签：将节点分组（如“SSD节点”“GPU节点”），AM可指定资源类型。

6. 优化建议

   • 小作业用Fair Scheduler，长批处理用Capacity Scheduler。
   • 设置合理的Container大小（避免“大容器浪费”或“小容器碎片”）。
   • 通过yarn.scheduler.maximum-allocation-mb限制单任务最大资源。

YARN通过集中式资源管理和灵活调度器，实现了多租户、多 workload 的资源隔离与高效利用。

YARN 队列

1. 队列层级
   多队列按业务/部门划分（如root.prod、root.dev），支持树形结构，父队列资源可分配给子队列。

2. 资源隔离
   每个队列有容量上限（如prod占60%、dev占40%），避免单队列独占资源，空闲资源可临时共享。

3. 调度策略适配

   • 容量调度器：队列容量固定，超量使用需归还。
   • 公平调度器：动态平衡队列资源，保证“最终公平”。

4. 优先级控制
   队列内任务可设优先级，高优先级任务优先获取资源。

5. 核心作用
   实现多业务资源隔离、按需分配，防止任务间相互干扰。

MapReduce shuffle过程优化

1. Map端优化

   • 压缩数据：启用mapreduce.map.output.compress（如Snappy/LZ4）减少网络传输。
   • 增大环形缓冲区：调大io.sort.mb（默认100MB）和io.sort.spill.percent（默认0.8），减少Spill溢写次数。
   • Combiner提前聚合：在Map端本地执行Combiner（如求和、计数），降低输出数据量。

2. Reduce端优化

   • 并行Fetch：增加mapreduce.reduce.shuffle.parallelcopies（默认5）提升拉取速度。
   • 内存预分配：调大mapreduce.reduce.shuffle.input.buffer.percent（默认0.7），让数据直接进入内存排序。
   • 归并阈值调整：通过mapreduce.reduce.merge.inmem.threshold控制内存中合并的文件数。

3. 数据倾斜处理

   • 加盐哈希：对高频Key添加随机前缀，分散到多个Reduce。
   • 两阶段聚合：先局部聚合（Map端Combiner），再全局聚合。

4. 集群资源分配

   • 调整Map/Reduce任务数：通过mapreduce.job.maps和mapreduce.job.reduces控制并行度。
   • 增加资源配额：提高单个任务内存（mapreduce.map.memory.mb/mapreduce.reduce.memory.mb）。

5. 硬件优化

   • 使用SSD存储中间数据，降低Spill/Read延迟。
   • 升级网络带宽（如万兆网卡）减少传输瓶颈。

通过以上措施，可显著提升Shuffle阶段效率，尤其在TB级数据处理中效果明显。

Hive元数据管理

1. 元数据存储

   • Metastore服务：独立进程，对外提供Thrift接口，支持多客户端并发访问。
   • 底层数据库：默认Derby（单用户），生产环境用MySQL/PostgreSQL存储元数据（表名、列类型、分区信息等）。

2. 元数据内容

   • 表结构：存储表名、字段名、数据类型、SerDe（序列化/反序列化）信息。
   • 分区与分桶：记录分区键、分桶规则及对应HDFS路径。
   • 数据位置：指向HDFS文件或外部存储（如S3、HBase）的路径。

3. 与HDFS交互

   • Hive表数据实际存储在HDFS，元数据仅记录逻辑结构和位置。
   • 创建表时，Metastore注册路径；查询时，根据元数据定位数据块。

4. 性能优化

   • 缓存机制：通过hive.metastore.cache.size配置元数据缓存，减少DB访问。
   • 分区剪枝：查询时直接过滤无关分区（如WHERE dt='2023-01-01'）。

5. 高可用方案

   • 部署多个Metastore服务，客户端通过负载均衡器访问。
   • 底层数据库采用主备复制（如MySQL主从）保障可用性。

6. 元数据迁移

   • 使用metatool工具导出/导入元数据，支持跨集群迁移。
   • 外部表迁移只需更新路径，无需移动实际数据。

通过集中化管理元数据，Hive实现了SQL语义与底层存储的解耦，支持多种数据源和计算引擎（如MapReduce、Spark）。

Hive SQL执行引擎

1. 多引擎支持

   • MapReduce（默认）：稳定但延迟高，适合批处理。
   • Tez：基于DAG优化，减少Shuffle，性能提升30%-50%。
   • Spark：内存计算，适合迭代任务，需配置hive.execution.engine=spark。

2. 执行流程

   • 解析器：将SQL转为抽象语法树（AST）。
   • 编译器：AST→逻辑计划→物理计划（如MapReduce任务）。
   • 优化器：应用谓词下推、列裁剪、分区剪枝等规则。
   • 执行器：调度任务到YARN或Spark集群。

3. 关键优化

   • 向量化执行：批量处理数据（默认启用），提升10倍以上速度。
   • CBO（成本优化器）：基于统计信息选择最优计划（需收集表和列统计）。
   • 并行执行：通过hive.vectorized.execution.enabled=true并行处理互不依赖的任务。

4. 引擎选择建议

   • 实时查询：优先Spark或Tez。
   • 复杂ETL：MapReduce（稳定性高）。
   • 迭代算法：Spark（内存复用）。

Hive通过统一SQL接口支持多引擎，用户可按需切换，无需修改代码。

Hbase分布式存储架构

1. 整体架构分层

• Client层：通过HBase API或Thrift/REST接口访问数据，缓存元数据（Region位置）减少查询开销。
• Master节点：管理RegionServer，负责Region分配、负载均衡、DDL操作（建表/删表）。
• RegionServer层：实际存储数据，由多个Region组成，每个Region负责存储表的一个连续分区。
• 底层存储层：数据最终存储在HDFS，依赖HDFS的高可靠与扩展性。

2. 核心存储单元：Region

• 数据分片：表按RowKey范围切分为多个Region，每个Region存储数据的一个子集，随数据增长自动分裂。
• 存储结构：每个Region包含多个Store（对应列族），每个Store由MemStore（内存缓存）和StoreFile（磁盘文件，HFile格式）组成。

3. 关键组件功能

• ZooKeeper：
  • 监控Master和RegionServer状态，选举主Master。
  • 存储RootRegion位置（元数据入口）。
• HRegionServer：
  • 处理数据读写请求，MemStore刷写（flush）到磁盘生成StoreFile。
  • 合并小StoreFile为大文件（Compaction），分裂过大Region。
• HMaster：
  • 管理RegionServer生命周期，分配Region到节点。
  • 处理表结构变更（DDL），不参与数据读写。

4. 数据读写流程

• 读流程：
  1. 客户端从ZooKeeper获取RootRegion位置，查询Meta表（.META.）获取目标Region所在RegionServer。
  2. 直接访问RegionServer，先查MemStore，再查StoreFile（按时间倒序）。
• 写流程：
  1. 数据先写入Region的MemStore（内存），同时记录WAL（预写日志，保证数据不丢失）。
  2. 当MemStore超过阈值（默认128MB），刷写到磁盘生成StoreFile。

5. 分布式特性

• 自动分片与负载均衡：Region分裂后，Master重新分配到不同RegionServer，避免单点压力。
• 高可用性：Master和RegionServer均支持多节点部署，ZooKeeper保障故障自动切换。
• 线性扩展：添加RegionServer即可增加存储与计算能力，数据自动迁移。

6. 与HDFS的关系

• HBase数据文件（HFile）存储在HDFS，利用HDFS的多副本机制（默认3副本）保证数据可靠性。
• RegionServer故障时，HDFS数据可被其他节点读取，确保服务不中断。

HBase通过分层架构、自动分片和分布式协同，实现了海量非结构化数据的低延迟读写与水平扩展，适用于高并发、高吞吐的场景（如日志分析、实时数据存储）。

Hbase RowKey设计原则

1. 长度控制

• 短而精：建议10-100字节（过长增加存储开销与网络传输成本）。
• 避免字符串冗余：如用Int/Long替代字符串时间（例：202306→202306010000）。

2. 散列分布

• 前缀加盐：对高频Key添加随机前缀（如user_001→r01_user_001），避免数据倾斜。
• 反转热点字段：如手机号[phone]反转成000831000831，打散连续前缀。
• 哈希分区：对Key取Hash（如hash(user_id)+原ID），均衡分布到不同Region。

3. 查询模式适配

• 前缀查询优化：将查询条件前置（如user_001_log→log_user_001），利用HBase的RowKey有序性。
• 范围查询设计：按时间倒序存储（如20230601_12345→20230602_12345），方便最新数据扫描。

4. 数据类型与编码

• 二进制存储：用字节数组（Bytes）存储，避免字符串编解码开销（如Long转为BigEndian字节）。
• 字典编码：对重复值（如枚举类型）预映射为短字节（例：status=1→01）。

5. 冷热数据分离

• 时间戳前缀：用时间戳作为RowKey前缀（如20230601_data），配合TTL自动淘汰旧数据。
• 多表隔离：热数据与冷数据分表存储，避免冷数据拖慢热数据查询。

6. 业务场景结合

• 唯一标识：确保RowKey全局唯一（如表名_主键_时间戳）。
• 组合查询：将多条件合并为单一Key（如user_001_order_123），减少跨Region查询。

示例：

• 反模式：user_1001_log_202306（前缀集中，易导致Region热点）。
• 优化后：202306_log_user_1001（时间倒序+条件前置，利于范围查询）。

合理的RowKey设计可避免集群热点、提升查询性能，是HBase调优的核心环节之一。

Spark RDD设计原则

1. 不可变性与惰性计算

• 不可变：RDD创建后不可修改，只能通过转换操作生成新RDD。
• 惰性执行：转换操作（如map、filter）只记录逻辑，行动操作（如collect、count）触发实际计算。

2. 分区与并行度

• 合理分区：根据集群资源和数据量设置分区数（默认等于HDFS块数），避免分区过少导致并行度不足，或过多导致调度开销。
• 控制并行度：通过spark.default.parallelism或转换函数（如repartition）调整。

3. 依赖关系与容错

• 窄依赖（如map、filter）：父RDD的分区只被一个子RDD分区使用，支持流水线计算。
• 宽依赖（如groupByKey、join）：需Shuffle，通过Checkpoint或RDD持久化（cache/persist）避免重复计算。

4. 持久化策略

• 缓存高频使用的RDD：如rdd.cache()（等价于persist(StorageLevel.MEMORY_ONLY)）。
• 选择存储级别：
  • 内存不足时用MEMORY_AND_DISK。
  • 计算成本高的RDD用DISK_ONLY。
  • 需快速恢复时启用MEMORY_ONLY_SER+序列化。

5. 避免Shuffle操作

• 优先使用聚合操作：如reduceByKey替代groupByKey，减少Shuffle数据量。
• 广播小表：通过sparkContext.broadcast()广播Join中的小表，避免Shuffle。

6. 函数式编程范式

• 纯函数：转换函数避免副作用（如修改外部变量），确保结果确定性。
• 避免闭包陷阱：RDD操作中传递的函数需确保依赖变量可序列化（如避免引用非序列化对象）。

7. 数据本地性优化

• 数据本地性级别：优先计算数据所在节点（PROCESS_LOCAL），其次同一机架（NODE_LOCAL），避免跨网络传输。
• 控制数据倾斜：对Key加盐或两阶段聚合处理热点数据。

8. 高级优化

• 使用Kryo序列化：通过spark.serializer配置，比Java序列化更高效。
• 自定义分区器：对Key分布不均的数据（如日期），自定义Partitioner实现均匀分布。

示例对比：

• 低效：rdd.groupByKey().mapValues(_.sum)
• 高效：rdd.reduceByKey(_ + _) （减少Shuffle数据量）

合理的RDD设计可显著提升Spark作业性能，核心在于减少Shuffle、优化分区与充分利用内存。

Spark DAG调度

1. DAG生成逻辑

• 触发条件：action算子（如collect、save）触发DAG构建，基于RDD依赖关系形成计算图。
• 阶段划分：根据宽依赖（Shuffle）将DAG切分为多个Stage（阶段），窄依赖合并为同一Stage。

2. Stage类型与执行模式

• Shuffle Map Stage：处理宽依赖前的阶段，输出数据写入磁盘（如groupByKey前的Map）。
• Result Stage：最后一个阶段，直接计算结果或输出（如collect）。
• 执行模式：
  • 流水线执行：窄依赖Stage内任务并行处理（如map+filter合并）。
  • 分阶段执行：宽依赖Stage间需等待前一Stage完成（Shuffle过程）。

3. 任务调度策略

• 调度器类型：
  • FIFO调度：按作业提交顺序执行（默认）。
  • 公平调度：为每个作业分配资源，适合多用户场景（通过spark.scheduler.mode配置）。
• 任务分配：
  • 每个Stage拆分为多个Task（数量等于RDD分区数），分发到Executor执行。
  • 优先选择数据本地性高的节点（PROCESS_LOCAL > NODE_LOCAL）。

4. 容错与重试机制

• 失败恢复：Task失败时，重试同一Stage的任务（默认重试4次）。
• Stage失败：若Stage中Task失败比例过高（如超过16次），重新提交整个Stage。
• Checkpoint机制：对长周期作业，通过checkpoint截断依赖链，避免全链路重算。

5. 性能优化要点

• 减少Stage数量，就是减少shuffle：用coalesce合并小分区，或通过广播变量避免Shuffle。
• 数据本地化优化：调整spark.locality.wait参数（默认3秒），等待数据本地节点资源。
• 推测执行：启用spark.speculation，对慢任务启动备份实例（适用于数据倾斜场景）。

6. 核心组件协作

• DAGScheduler：负责Stage切分、依赖管理，生成TaskSet。
• TaskScheduler：将TaskSet提交给集群管理器（如YARN），调度Task执行。
• Executor：接收Task，执行RDD计算并返回结果。

示例流程：

行动操作（如collect） → DAGScheduler解析RDD依赖 → 按宽依赖切分Stage → 
TaskScheduler调度Task到Executor → 各Stage按顺序或流水线执行 → 返回结果

DAG调度通过依赖分析与阶段切分，实现分布式计算的高效协调，是Spark性能优化的关键切入点。

Spark 内存管理

1. 内存区域划分（Spark 2.0+ Unified Memory）

• 执行内存（Execution）：Shuffle、Join、排序等计算操作的内存。
• 存储内存（Storage）：RDD缓存、广播变量的内存。
• 统一管理：两者可动态占用对方空间（默认各占40%，剩余20%为预留空间）。

2. 关键配置参数

参数	含义
spark.executor.memory	每个Executor总内存（如10g）。
spark.memory.fraction	执行+存储内存占总内存的比例（默认0.6，即60%）。
spark.memory.storageFraction	存储内存占执行+存储内存的初始比例（默认0.5，即30%总内存）。
spark.shuffle.memoryFraction	单个Shuffle操作的内存上限（旧版参数，新版由动态分配替代）。

3. 内存优化策略

• RDD缓存：
  • 使用persist(StorageLevel.MEMORY_AND_DISK)避免OOM。
  • 大RDD优先用MEMORY_ONLY_SER（序列化存储，节省空间）。
• Shuffle优化：
  • 通过spark.shuffle.spill允许中间数据溢出到磁盘，避免内存压力。
  • 调整spark.shuffle.file.buffer（默认32KB）增大Shuffle写缓冲区。
• 广播变量：
  • 用sparkContext.broadcast()缓存大变量到Executor，减少网络传输。

4. 堆外内存（Off-Heap）

• 启用条件：
  • 设置spark.memory.offHeap.enabled=true并配置spark.memory.offHeap.size。
• 优势：
  • 减少GC压力，适合处理TB级数据。
  • 避免JVM对象头开销，提升内存利用率。

5. GC调优

• 选择垃圾回收器：
  • 大内存（>8GB）用G1GC（-XX:+UseG1GC）。
  • 配置spark.executor.extraJavaOptions调整GC参数。
• 减少临时对象：
  • 避免在map/filter中创建大量对象，复用对象池。

6. 内存监控工具

• Web UI：查看Executor内存使用、RDD存储占比。
• Spark Metrics：集成Prometheus+Grafana监控内存使用率、GC频率。

总结
合理分配执行与存储内存，优先序列化缓存RDD，谨慎使用堆外内存，结合GC调优，可显著提升Spark作业性能。

Flink Watermark原理

1. 核心作用

• 标记事件时间（Event Time）进度，告诉系统“小于该时间的事件已基本到达”，触发窗口计算。
• 平衡计算延迟与结果准确性（允许一定乱序，超过阈值则视为迟到数据）。

2. 生成方式

• 周期生成：每隔固定时间（如200ms），从数据源按规则生成Watermark（默认方式）。
• 断点生成：基于特定事件触发（如遇到标记数据）。

生成规则示例：
Watermark = 窗口内最大事件时间 - 允许乱序的延迟时间
（如最大事件时间10:00，延迟2秒，则Watermark为09:59:58）。

3. 窗口触发逻辑

• 当Watermark时间 ≥ 窗口结束时间时，触发窗口计算（如[10:00, 10:05)窗口，Watermark≥10:05时触发）。
• 未在Watermark前到达的事件，视为迟到数据（可通过allowedLateness设置额外等待时间）。

4. 传递与合并

• 多并行流场景下，Watermark在算子间传递时，取所有输入流中最小的Watermark（保证全局进度一致）。

总结
Watermark通过定义事件时间进度，解决乱序流的窗口触发问题，核心是“用可容忍的延迟换取结果完整性”。

Flink Checkpoint原理

1. 核心作用

• 周期性记录算子状态快照，故障时可从最近Checkpoint恢复，保证Exactly-Once语义。

2. 触发与执行流程

• 触发：JobManager定期（默认1000ms）向Source算子发送Checkpoint屏障（Barrier）。
• 屏障传播：Barrier随数据流在算子间传递，标记快照点前后的数据。
• 状态快照：
  • 算子接收到所有输入流的Barrier后，将状态写入持久化存储（如HDFS）。
  • 采用异步快照（Async Snapshot）避免阻塞数据流处理。

3. 存储与恢复

• 存储介质：默认保存在分布式文件系统（如HDFS），也支持RocksDB（本地+持久化）。
• 恢复机制：故障时，JobManager从最新Checkpoint重新部署作业，算子从快照加载状态。

4. 语义保障

• 通过两阶段提交（2PC） 协调Source/Sink，结合Barrier对齐，确保跨算子状态一致性，实现Exactly-Once。

总结
Checkpoint通过周期性快照+屏障协调，在故障时快速恢复状态，是Flink流处理可靠性的核心保障。

Flink状态管理

1. 状态类型

• 托管状态（Managed State）：
  • 由Flink自动管理，支持内存优化和Checkpoint。
  • 细分为：
    • Keyed State：按Key分区的状态（如ValueState、ListState），仅KeyedStream可用。
    • Operator State：算子级状态（如Source的偏移量），全体并行实例共享。
• 原始状态（Raw State）：用户自行管理，Flink仅保存字节数组，需手动序列化。

2. 状态存储

• 内存存储：基于JVM堆内存（MemoryStateBackend），适合测试，不支持大状态。
• RocksDB存储：基于本地磁盘的嵌入式数据库（RocksDBStateBackend），支持大状态，适合生产。
• 存储优化：自动分区、序列化压缩，减少内存占用。

3. 状态一致性

• 依赖Checkpoint机制，通过快照+恢复保证故障后状态一致。
• 结合两阶段提交（2PC），支持Exactly-Once语义。

4. 状态过期与清理

• 配置StateTtlConfig设置状态生存时间（TTL），自动清理过期数据。

Kafka分区机制

1. 核心作用

• 分区（Partition）是Topic的物理分片，将数据分散存储，支持并行读写，提升吞吐量。

2. 分区策略

• 生产者分区规则：
  • 指定partition参数：直接写入目标分区。
  • 未指定但有key：按key.hashCode() % 分区数路由（同key数据入同分区，保证顺序）。
  • 无key无指定：轮询（Round-Robin）分配。

3. 分区特性

• 顺序性：单个分区内数据按写入顺序存储（全局无序，分区内有序）。
• 扩展性：可动态增加分区（不支持减少），通过重新分配均衡负载。
• 副本机制：每个分区有多个副本（含1个Leader，其余Follower），Leader负责读写，Follower同步数据，保证高可用。

Kafka高可用原理

1. 副本机制

• 每个分区包含多个副本（replication-factor指定数量），分为：
  • Leader副本：唯一处理读写请求，数据变更同步给Follower。
  • Follower副本：仅同步Leader数据，Leader故障时参与竞选。
    2. 故障检测与转移
• Broker故障：ZooKeeper监控Broker心跳，超时（默认6s）标记为下线。
• Leader选举：
  • 分区所在Broker故障后，由Controller（集群总控节点） 从存活Follower中选举新Leader（优先选同步完成的副本）。
  • Controller故障时，ZooKeeper通过选举产生新Controller。

3. 数据可靠性保障

• 生产者可配置acks参数：
  • acks=1：Leader写入成功即返回（默认，平衡性能与可靠性）。
  • acks=-1：需所有ISR（同步副本集）确认，保证数据不丢失。

Kafka ISR

Kafka中的ISR（In-Sync Replicas，同步副本集）是保障数据可靠性的核心机制：

• 定义：指与Leader副本保持同步的Follower副本集合（包含Leader自身）。
• 同步标准：Follower需在replica.lag.time.max.ms（默认30s）内成功从Leader同步数据，否则被踢出ISR。
• 作用：
  • 生产者配置acks=-1时，仅需ISR中所有副本确认，即可保证数据不丢失。
  • Leader故障时，新Leader仅从ISR中选举，确保数据一致性。

简言之，ISR是“可信的副本子集”，平衡了数据可靠性与性能。