Daily Study

更新: 2/9/2026 字数: 0 字时长: 0 分钟

Daily Plan

#todo

涉及到的内容：clickhouse flink elasticsearch hadoop hdfs

设计目标是为了处理PB级海量数据：

内存存不下：如果用 HashMap，你需要把所有 Key 存入内存，数据量太大直接 OOM。
归并的需求：通过排序，相同的 Key 会自动靠在一起（比如 Apple, Apple, Apple, Banana, Banana...）。这样 Reducer 只需要顺序读取，读到一个新 Key 就可以处理上一组数据，完全不需要把所有数据加载到内存。

基于磁盘执行任务：Map 跑完 -> 写磁盘 -> Shuffle -> Reduce 跑完 -> 写磁盘

Input Split (切片)
- 系统将 HDFS 上的大文件切割成物理上的 Block（默认 128MB）。
- 每一个 Block 启动一个 Map Task（进程/线程）。
Map Phase (映射阶段)
- 任务：解析输入数据，处理成 <Key, Value> 对。
- 例子：读一行文本 "Hello World Hello"，输出：
  - <Hello, 1>
  - <World, 1>
  - <Hello, 1>
- 特点：Map 任务之间完全并行，互不干扰（Shared Nothing），速度极快。
Shuffle Phase
- 目标：把 Map 输出的无序数据，整理成 Reduce 需要的有序数据。
- 过程：
  1. Partition (分区)：决定这条数据发给哪个 Reduce 节点（通常是 Hash(Key) % ReduceNum）。
  2. Sort (排序)：在 Map 端内存中对 Key 进行排序。
  3. Spill (溢写)：内存满了写到磁盘（Disk I/O）。
  4. Merge (合并)：Reduce 端从多个 Map 节点拉取数据（Network I/O），并进行归并排序。
- 代价：涉及大量的网络传输和磁盘读写。
Reduce Phase (归约阶段)
- 任务：接收 Shuffle 过来的数据，通常是一组 <Key, List<Value>>。
- 例子：
  - 输入：<Hello, [1, 1, 1, ...]>
  - 逻辑：sum(list)
  - 输出：<Hello, 10086>
Output Phase ：将结果写入 HDFS 文件系统（为了可靠性，会有 3 副本复制）。

该阶段会进行针对<Key, Value> 中的 Key的排序，默认情况下按照 Key的字典序进行排序。分成了 3 次排序操作，贯穿了 Map 和 Reduce 两端。

第一阶段：Map 端内存中的排序 (QuickSort)

场景：Map 任务输出数据时，并不是直接写磁盘，而是先写进一个内存缓冲区（Ring Buffer / 环形缓冲区，默认 100MB）。
动作：当缓冲区快满时，需要把数据溢写到磁盘成临时文件。
排序对象：在溢写之前，MapReduce 会在内存中对这 80MB 数据进行一次快速排序。
排序规则：双重排序：
- 先按 Partition ID 排序（决定这行数据发给哪个 Reducer）。
- 再按 Key 排序（保证同一个 Partition 内的数据是有序的）。
结果：生成的临时小文件内部是有序的。

第二阶段：Map 端磁盘文件的合并

第三阶段：Reduce 端的归并排序

总结 MapReduce 的 Shuffle 排序：

其中多路归并排序实现：使用最小堆。