2.2 数据本地性
文档摘要
2.2 数据本地性 本节摘要：数据本地性指调度器尽量把 Map 任务分配到其输入分片所在的节点上执行，从而避免搬运数据。本地性分节点本地、机架本地、跨机架三级，级别每降一级，代价从内存读取跌落到跨机架网络传输。本节量化这三级差异，解释调度器"等多久才放弃本地性"的权衡，并给出保住本地性的工程做法。 一笔传输账 设一个 128MB 的分片，三种放置方式下 Map 任务读入数据的路径： 节点本地：数据就在执行节点磁盘/页缓存。走本地磁盘读，热数据直接命中内存，典型吞吐数百 MB/s 以上； 机架本地：数据在同机架另一节点。走一次机架内交换机，千兆网卡理论 125MB/s，实际打八折约 100MB/s，读 128MB 约 1.3 秒； 跨机架：数据在别的机架。
2.2 数据本地性
本节摘要：数据本地性指调度器尽量把 Map 任务分配到其输入分片所在的节点上执行，从而避免搬运数据。本地性分节点本地、机架本地、跨机架三级，级别每降一级，代价从内存读取跌落到跨机架网络传输。本节量化这三级差异，解释调度器"等多久才放弃本地性"的权衡，并给出保住本地性的工程做法。
一笔传输账
设一个 128MB 的分片，三种放置方式下 Map 任务读入数据的路径：
- 节点本地：数据就在执行节点磁盘/页缓存。走本地磁盘读，热数据直接命中内存，典型吞吐数百 MB/s 以上；
- 机架本地：数据在同机架另一节点。走一次机架内交换机，千兆网卡理论 125MB/s，实际打八折约 100MB/s，读 128MB 约 1.3 秒；
- 跨机架：数据在别的机架。路径多经过一台核心交换机，还可能与集群其他流量争带宽，读 128MB 数秒起。
看似秒级差距不大，但乘上规模就吓人：一个 10TB 的作业有一万多个分片，若全部跨机架读，仅输入传输就要消耗十TB 的网络流量，核心交换机直接打满，作业时长被网络钉死。而全部节点本地的作业，网络几乎只为 Shuffle 服务。这就是"移动计算比移动数据便宜"的量化含义：把几十 MB 的程序与任务描述发过去，比把 128MB 的数据拉过来划算，数据再大点差距更悬殊。
HDFS 的副本策略天然配合本地性：默认三副本，两份在同机架不同节点、一份在别的机架。调度器因此通常有三次机会把任务放到数据附近。
三级本地性与调度权衡
调度器为每个待运行任务维护本地性等级，理想顺序：
图 2.2-1 三级本地性的读取路径
问题来了：若数据所在节点全部繁忙，调度器是死等，还是把任务发到空闲节点上去拉数据？
Hadoop 的答案是延迟调度：任务先在本地队列里等一小段（可配，默认秒级），若窗口内目标节点释放了槽位就本地执行；等超时了就降级——先试机架本地，再不行跨机架。这个看似简单的策略在论文层面被证明能用很小的等待代价换回绝大部分本地性收益，因为 Map 任务数量众多、单个任务时长有限，槽位很快会轮转出来。
工程上判断本地性是否健康，看作业计数器里的这几个指标：节点本地命中的容器数、机架本地命中数、跨机架数。一个健康的大作业，绝大多数 Map 任务应落在前两档。
本地性为什么主要属于 Map
注意本地性讨论几乎只围绕 Map 任务。原因在结构上：
- Map 的输入是 HDFS 文件，位置固定、副本已知，调度器有明确的目标节点可选；
- Reduce 的输入是所有 Map 的输出，散布在曾运行过 Map 任务的所有节点上，天生就是"数据从四面八方流向 Reduce"，无单一"数据所在地"可言（能优化的只是把 Reduce 尽量安排在拥有较多 Map 输出副本的节点，收益有限）。
这也是第 4 章 Shuffle 被称为"不可避免的恶"的根源之一：Map 端本地性做得再好，第三幕的网络传输量依然由中间数据总量决定。Reduce 端本地性能做的是次要优化。
保住与丢掉本地性的常见场景
丢掉本地性的情形：
- 等待超时被降级调度——偶发无害，频繁发生说明集群负载不均；
- 开启重用 JVM 的策略配置不当，或队列资源划分与数据分布错位（数据集中在 A 机房、计算槽位集中在 B 机房）；
- 磁盘坏道导致副本流失，数据只剩远端副本；
- 推测执行的备份任务：备份任务启动在任意空闲节点，本来就不指望本地性，用它换时间。
保住本地性的做法：
- 让 HDFS 副本分布与计算槽位分布大体均衡，避免"数据在这头、槽位在那头"；
- 小文件用 CombineFileInputFormat 时保持节点级打包，而不是随机把不同节点的小文件塞进一个分片；
- 重跑历史作业时，如果输入数据被近期作业的重写打散了副本分布，本地性会变差，这不是错觉，是副本换了位置。
一个容易忽略的事实：本地性以"分片对齐块"为前提
回看上一节：分片默认等于块大小，一个分片的数据恰好集中在一个块上，本地性目标明确。若你把分片调成 300MB 而块仍是 128MB，一个分片横跨三个块（可能分属三个节点），任务无论放在哪个节点都得跨网拉另外两块——调分片大小的同时，实际上也在稀释本地性。这是 splitSize 公式里那个 min blockSize 约束的深层理由，也是"想加大分片就同时加大块"这条经验法则的出处。
本节要点回顾
- 核心命题：移动计算远比移动数据便宜，调度器让任务流向数据所在节点。
- 三级本地性：节点本地、机架本地、跨机架，读取代价逐级跳升，HDFS 三副本给了调度器三次机会。
- 延迟调度：短暂死等换本地性，超时降级，兼顾吞吐与网络成本。
- Map 专属：Reduce 输入天然分散，本地性优化主要作用于第一幕。
- 前提：分片对齐块是本地性的隐形地基，乱调分片大小会同时伤害本地性。
- 诊断：看作业计数器的三级命中分布，即可判断本地性健康度。
数据就位、任务开机，下一节补上第一幕的最后一个决策：压不压缩、怎么压。