简介这份演示文稿《云计算之分布式计算》面向云计算、大数据方向的初学者、高校师生及技术分享者用于系统讲解分布式计算的基本原理与应用体系。课件从移动互联网、物联网带动的数据爆炸切入引用IDC、加州大学及《纽约时报》等资料说明数据量每两年翻一番、信息消费总量达数ZB的大数据时代挑战强调决策正从经验转向数据驱动。随后深入梳理分布式计算的两大类别批量计算与实时计算并围绕Google与Apache生态介绍MapReduce海量数据离线处理、Pregel大规模图迭代计算、Percolator增量更新、Dremel大数据分析、Tenzing与HiveSQL查询等计算框架以及GFS/HDFS文件系统、BigTable/HBase数据库如何支撑海量数据存储与高效访问课件还以天气预报中的词频统计为例演示MapReduce的Map、Reduce工作流程便于直观理解分布式任务的切分与汇总过程。资源为单个pptx演示文稿约840KB方便下载后直接用于课堂讲解或二次编辑。目前已有106人学习适合用于云计算课程教学、技术分享、自学梳理也可作为教学PPT的版式与内容结构参考。1. 云计算里最容易被绕过去的那个词分布式计算做云计算运维这两年我有个很深的感受很多人对分布式计算的了解停留在“把任务分给多台机器跑”这一句话上可真到了集群上用起来任务卡死、数据倾斜、节点忙闲不均一个个问题全冒出来了。这份《云计算之分布式计算》课件把 MapReduce 工作流程、Google 技术栈和 Apache 生态的对照关系、Amdahl 定律的边界全都串了起来特别适合两类人一是刚接触离线数仓、想知道批量计算到底怎么运转的新手二是已经用着 Hadoop 生态、但一直没搞清楚 Pregel、Tenzing、Hama 这些名字背后对应关系的云计算运维工程师。它能解决的核心问题是让你从“会用命令”进到“知道为什么这么设计”。2. 批量计算的骨架MapReduce 工作流程与任务划分2.1 Map 阶段数据切分、分片与本地计算MapReduce 的起点是把输入数据切成若干分片split。课件里用“统计天气预报中每个字出现次数”这个例子把昨天、今日、明天三天的天气文本分别交给三个 Slave 节点处理每个节点拿到的是完整的一条记录而不是跨行的半截数据。这种按行切分的策略在 Hadoop 里叫 InputSplit默认情况下每个分片对应一个 HDFS 块默认 128MB但注意分片边界和块边界不一定对齐分片会记录“文件路径 起始偏移 长度”这样才能保证一条记录不被切到两个分片里。Map 任务读到自己负责的分片后逐行解析输出键值对。以“小雨转多云”为例Map 输出的是小,1、雨,1、转,1、多,1、云,1这样的中间结果。这里有一个容易被新手忽略的细节Map 输出不是直接写磁盘而是先写进环形缓冲区默认 100MB当缓冲区写到 80% 阈值时后台线程开始 spill 到本地磁盘并且在 spill 过程中做分区和排序。分区数量由 Reduce 任务数决定排序则是按 key 进行。课件里 Master 只负责调度不参与实际计算这个角色划分非常关键——Master 挂了整个作业就废了所以生产环境里通常会为 Master 配 HA。2.2 Reduce 阶段键值路由、数据再分布与归并Reduce 阶段要做的事是从所有 Map 输出里把相同 key 的值归到同一个 Reducer 里。课件里展示了“统计‘小’”“统计‘雨’”“统计‘转’”等多个 Reduce 任务并行工作的画面。数据传播过程很直观Map 端输出的键值对按 key 哈希后分不到同区Reduce 端从各个 Map 节点拉取属于自己分区的中间结果然后做一次归并排序再调用用户写的 reduce 函数。这个环节有一个很容易踩的坑如果某个 key 特别多比如“雨”出现了 2 次而其他字只有 1 次所有“雨”的键值对都会被分到同一个 Reducer这就叫数据倾斜。课件里虽然没明说但从示例数据能看出来前三个 Slave 的输出里“雨”出现了 4 次如果按 key 哈希这个 Reducer 的负担会明显高于其他 Reducer。解决思路通常是加一层随机前缀做二次散列或者改用 Combine 在 Map 端先做一次局部归并来减少传输量。2.3 用课件里的例子完整推演一遍把课件里的天气文本作为输入推演过程可以梳理成一张表阶段输入输出示例说明原始数据昨天小雨转多云今日多云转阵雨明天小雨转中雨三条文本记录按行切分三个 Map 各处理一条Map 输出每条记录拆成单字小,1 雨,1 转,1 多,1 云,1逐字拆分按空格分词在此场景简化为单字分区路由所有 Map 的中间结果按 key 哈希到三个 Reduce 分区“雨”“云”“转”等高频字可能集中到同一分区Reduce 归并各分区内按键排序统计出小:1, 雨:2, 多:1, 云:1相同 key 合并输出最终计数这里可以看出 MapReduce 的一个核心设计哲学计算向数据移动而不是数据向计算移动。每个 Map 只处理本地分片Reduce 再拉取中间结果整个过程的并行度由分片数量和 Reduce 任务数共同决定。单纯增加 Reduce 数量并不能线性提升性能因为数据 shuffle 的网络开销会同步上升单纯增加分片数量则会让 Master 的调度压力变大。课件里那一屏“Master 与三个 Slave”的调度关系其实就是一套微缩版的 YARN 资源调度。3. Google 技术栈与 Apache 生态一张对照表理清血缘关系3.1 存储层GFS 与 HDFS 的对应关系课件里有一页专门做 Google 与 Apache 的对应GFS 对应 HDFSBigTable 对应 HBaseMapReduce 对应 MapReducePregel 对应 HamaTenzing 对应 Hive。这个对照表对从业者的价值在于理解了 Google 的原始设计动机就理解了 Hadoop 生态的演进逻辑。GFS 的原始论文解决了三个问题单机磁盘容量不够、单机磁盘损坏概率高、多机文件访问需要统一命名空间。HDFS 把这套思想原样搬了过来采用 128MB 大块、三副本冗余、NameNode 统一元数据管理的方案。生产环境里副本数不是拍脑袋定的3 是可靠性与成本的平衡点2 副本在机房断电场景下可能双盘同时失联4 副本的存储成本直接多出三分之一。课件里讲“分布式环境”时强调企业要构建大规模数据中心这正是存储层的现实背景——没有可靠的分布式文件系统计算框架就是空中楼阁。3.2 数据管理层BigTable 与 HBase 的适用边界BigTable 是一张稀疏的、分布式的、持久化的多维映射表行键、列族、时间戳三个维度决定一个单元格。HBase 完整继承了这套模型。实际使用中我经常看到有人拿 HBase 当传统关系型数据库用这是误解HBase 没有跨行事务索引只有 RowKey 一种二级索引要靠自己维护。课件把 BigTable/HBase 归到“数据管理”而不是“数据库”这个分类很准确。HBase 的 RowKey 设计直接决定读写热点如果用时间戳当 RowKey 前缀最新数据会全部写到最后一个 Region形成写热点。常见做法是倒序时间戳或者加盐前缀比如用户 ID 哈希值取模。课件里没有展开这些细节但从“提供快速读写能力”这句话可以推导出RowKey 散列均匀是前提条件。3.3 计算框架与查询层Pregel、Hama、Tenzing、Hive 的角色Pregel 是 Google 的图计算框架采用“以顶点为中心的 BSP 模型”每个超步superstep里所有顶点并行执行用户自定义函数顶点之间通过消息传递通信。Hama 在 Apache 生态里对应实现了这套模型。注意 Pregel 不是万能的图计算方案BSP 模型对幂律分布的网络图比如社交关系图会产生严重的消息倾斜——少数热门顶点每个超步会收到海量消息。课件里把它和 MapReduce 并列说明 Google 自己也意识到 MapReduce 不适合迭代计算每一轮迭代都要落盘一次性能开销太大。Tenzing 对应 Hive但两者的定位有微妙差别。Tenzing 是 Google 内部用来在 MapReduce 之上跑 SQL 的引擎核心思路是“把查询翻译成 MR 作业”Hive 最开始也是这个思路把 HiveQL 编译成 MapReduce 执行计划。注意 Hive 在一条查询里会生成多个 MR Job每两个 Job 之间都有落盘所以写 Hive SQL 要特别小心 join 顺序和子查询嵌套层级。课件把这层称为“SQL 查询引擎”本质上是给不写 Java 的分析人员一个 SQL 入口。3.4 一份可落地的选型对照表层次Google 方案Apache 对应方案典型适用场景文件系统GFSHDFS海量文件存储、批处理输入输出分布式数据库BigTableHBase稀疏结构化数据、实时读写批量计算框架MapReduceHadoop MapReduce离线清洗、ETL、全量统计迭代图计算PregelHama网页排名、社交图谱、最短路径SQL 查询引擎TenzingHive数仓分析、即席查询、报表任务这张表的价值在于选型时可以按层次逐个对照。比如一个实时写入、秒级查询的需求选 HBase 是合理的如果查询模式复杂、涉及多表关联就应该把数据同步到 Hive 做离线分析而不是强行在 HBase 上跑全表扫描。我在实际项目里见过不少翻车案例根因都是把这张表里的层次搞混了比如用 Hive 承接实时写入或者用 HBase 跑复杂的聚合分析。4. Amdahl 定律并行加速比的边界到底在哪4.1 定律的推导与工业化直觉课件用“泡茶”这个例子引入 Amdahl 定律洗开水壶1分钟、洗茶壶3分钟、拿茶叶2分钟、泡茶2分钟、烧开水15分钟、洗茶杯2分钟。如果一个人完成总耗时是 25 分钟但烧开水 15 分钟可以和洗茶壶、拿茶叶、洗茶杯并行最理想的并行路径是先洗开水壶 1 分钟再烧开水 15 分钟同时在烧水期间并行洗茶壶、拿茶叶、洗茶杯需要 3227 分钟 15 分钟最后泡茶 2 分钟。总耗时变成 115218 分钟而不是 25/无限大。这就是 Amdahl 定律的直观体现串行部分决定了加速比上限。公式上如果问题规模固定为 1其中不可并行部分占 f那么无论如何增加处理器数量最大加速比不会超过 1/f。在这个例子里洗开水壶和泡茶是必须串行的f 3/25加速比上限约 8.3 倍——但实际上受限于“烧开水 15 分钟”这个瓶颈实际加速比只有 25/18 ≈ 1.39 倍。生产环境里这个定律经常被忽略。我见过一个案例某团队把跑批时间从 2 小时优化到 30 分钟然后想继续加节点压到 10 分钟结果节点翻倍后时间只降到 22 分钟。原因就是数据导入和结果写回这两个串行环节占据了固定开销加机器对它们毫无帮助。课件里那句“并行加速比不超出 1/f”不是理论摆设是做容量规划时必须先算的一笔账。4.2 核心参数串行比例 f 的估算方法做并行度规划时我一般会把作业拆成四段话数据读取、计算处理、Shuffle 传输、结果写回。前两段和后两段的可并行程度完全不同。阶段是否可并行占比经验值优化手段数据读取可并行15%增加 InputSplit但受限于文件格式计算处理可并行60%加 Map/Reduce 并行度注意数据倾斜Shuffle 传输部分可并行20%压缩中间结果调整分区策略结果写回几乎不可并行5%减少输出文件数使用压缩输出格式从这个表能推算出即使把计算处理全部并行化加速比上限也受读取和写回限制。把 f 定为 0.2读 写 部分 shuffle 的串行损耗则加速比上限为 5 倍。这也解释了为什么 MapReduce 作业从 10 个节点扩到 50 个节点提速往往不到 3 倍——数据读取和结果合并的开销跟着涨上去了。4.3 集群规模设计一个 1TB 数据的估算流程假设一个离线作业要处理 1TB 文本数据单机处理能力约 20MB/s串行处理需要 50000 秒约 14 小时。如果引入 10 个节点并行理论上加速比接近 10 倍但算上启动开销、调度延迟和 shuffle 网络传输实际可用系数通常在 0.60.8 之间。我一般按这个流程估算先规定目标时间 T比如 60 分钟内再估算单节点吞吐量 V比如 20MB/s算出理论节点数 N 数据量 /V × T × 并行效率。代入 1TB 数据目标 1 小时V20MB/s并行效率 0.7N ≈ 1024×1024 /20×3600×0.7≈ 20.8取整 21 个节点。这里要再回代 Amdahl 定律验证如果串行部分 f 占 20%21 节点的最大加速比是 1 / (0.2 0.8/21) ≈ 3.9远小于 21——说明这个作业想靠加节点提速是做不到的真正的瓶颈是串行部分而不是并行度不够。5. 离线批量计算的常见翻车点从任务卡死到数据倾斜5.1 现象某个 Reduce 长期卡在 99%其他早已跑完原因数据倾斜某个 key 的数据量远超其他 key分配到单个 Reducer 后成为长尾。课件里的天气预报例子虽然数据量小但“雨”字出现次数明显偏多已经能看出这种趋势。解决先在 Map 端做 Combine减少 shuffle 数据量如果倾斜依旧给 key 加随机前缀做二次散列把大 key 拆到多个 Reducer 再合并结果。另一个思路是把倾斜 key 单独提取出来用两个 Job 分别处理最后 union 结果。注意加前缀后会导致原本有序的输出变成近似有序下游如果有排序依赖要额外处理。5.2 现象集群资源充足但作业一直处于 ACCEPTED 状态原因ResourceManager 等待调度但不是因为 CPU 或内存不足而是 NAME 里队列配置的 AM 资源上限被占满。很多团队把多个作业提同到同一个队列ApplicationMaster 本身也要占用容器资源AM 数量达到上限后作业只能排队。解决检查 YARN 队列配置把yarn.scheduler.capacity.maximum-am-resource-percent从默认的 0.1 调高到 0.20.3或者为不同作业划分独立队列。同时检查作业的 AM 请求内存是否超出单个节点可用资源。这类问题最隐蔽的地方在于集群总资源看起来是够的但 AM 资源这个特定维度被卡死了。5.3 现象Map 阶段已经结束但 Shuffle 阶段网络传输特别慢原因中间结果数据量过大且没有开启压缩。默认情况下 MapReduce 的中间结果是不压缩的1TB 输入数据的中间结果可能膨胀到 23TB全走网络传输。解决开启中间结果压缩mapreduce.map.output.compresstrue压缩格式选 Snappy 或 LZ4这类压缩编解码器对 CPU 开销小、压缩率高。我之前在一个 300GB 的作业上开启 Snappy 压缩后shuffle 时间从 40 分钟降到 12 分钟。注意最终输出如果要被下游直接读取不要用 Snappy 而是考虑 Gzip或者用 Parquet 列式存储自带压缩。5.4 现象作业在 Map 阶段反复重试同一批任务原因某些 Map 任务因为读取特定数据块失败而反复重试比如 HDFS 上某个块损坏或节点磁盘故障。另一个常见原因是推测执行Speculative Execution被打开当某个任务执行明显慢于其他任务时集群会启动一个备份任务竞争。如果慢任务只是网络抖动而不是真正的性能问题备份任务会造成重复计算和资源浪费。解决先救援 HDFS用hdfs fsck检查损坏块并恢复对推测执行通常建议按作业类型单独设置mapreduce.map.speculativefalse。如果作业本身有数据倾斜推测执行反而会把长尾拖得更长因为每个备份任务都在处理同样的倾斜 key。5.5 现象作业跑完但输出文件数量爆炸下游加载极慢原因每个 Reduce 输出一个文件如果设置了 1000 个 Reducer就会生成 1000 个小文件。下游同步任务把大部分时间耗在打开文件上。解决调整 Reducer 数量与输出文件数匹配mapreduce.job.reduces按数据量和目标文件大小反推或者在作业末尾加一步合并把结果合并成少量大文件。更彻底的做法是改用 Hive 或 Spark SQL输出直接写动态分区目录控制每个分区的大小。课件里虽然没有讲输出设计但生产环境中文件数量对后续任务的影响往往比计算本身更大。6. 准实时计算的三个进阶方向增量更新、交互查询与图迭代课件里把技术趋势分成批量计算、准实时计算和实时计算三条线。MapReduce 解决了批量Percolator 和 Dremel 解决准实时而这正是从“离线跑批”往“实时数仓”迁移的中间站。Percolator 的思路很容易理解不再全量重算而是只处理变更的数据。课件把它叫“数据增量更新系统”实现上依赖 BigTable 的列级时间戳和分布式锁用两阶段提交保证跨行事务。我在实际项目中做过类似的设计核心是把变更记录放到消息队列里下游拿增量数据去更新宽表而不是每天凌晨全量刷一遍。这样能显著缩短数据可见性延迟但要注意增量更新是“最终一致”一旦某条记录处理失败需要人工补偿或者重放一次全量快照。Dremel 解决的是“我不能等 10 分钟才看到统计结果”的场景。课件把它定位成“数据分析系统”它在 Google 内部支撑了万亿行日志的秒级扫描原理是列式存储加多级聚合树。开源生态里对应的是 Presto/Trino 和 ClickHouse。如果你在做云计算运维遇到的需求是“用户要看过去 7 天每分钟的请求量”Dremel 这类 MPP 引擎比 MapReduce 合适得多。我的习惯做法是把明细数据同时导一份到列式存储查询走 MPP 引擎批处理仍然走 Hive 离线链路两条链路各管各的。Tenzing 之后是 Hive 生态的演进方向。课件里 Tenzing 和 Hive 被放在同一格但今天的 Hive 已经支持 Tez 或 Spark 作为执行引擎落盘次数明显减少。我的经验是运维同学评估一套离线数仓方案时先看三点数据多快可见、查询多快返回、扩节点是不是线性提速对应的正好是批量、准实时、实时三条线的取舍。从那以后我每次接到新的数据处理需求都强制先问一句这是不是一定要全量重算如果有 20% 数据每天都变就应该优先考虑增量方案而不是加节点硬扛全量。项目上线前也必拿 Amdahl 定律估算一遍串行比例避免交付一个加机器也提不了速的集群。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/2 15:36:49 · 阅读 1.2k 分布式计算核心：MapReduce流程、Amdahl定律与云端排障实战
简介这份演示文稿《云计算之分布式计算》面向云计算、大数据方向的初学者、高校师生及技术分享者用于系统讲解分布式计算的基本原理与应用体系。课件从移动互联网、物联网带动的数据爆炸切入引用IDC、加州大学及《纽约时报》等资料说明数据量每两年翻一番、信息消费总量达数ZB的大数据时代挑战强调决策正从经验转向数据驱动。随后深入梳理分布式计算的两大类别批量计算与实时计算并围绕Google与Apache生态介绍MapReduce海量数据离线处理、Pregel大规模图迭代计算、Percolator增量更新、Dremel大数据分析、Tenzing与HiveSQL查询等计算框架以及GFS/HDFS文件系统、BigTable/HBase数据库如何支撑海量数据存储与高效访问课件还以天气预报中的词频统计为例演示MapReduce的Map、Reduce工作流程便于直观理解分布式任务的切分与汇总过程。资源为单个pptx演示文稿约840KB方便下载后直接用于课堂讲解或二次编辑。目前已有106人学习适合用于云计算课程教学、技术分享、自学梳理也可作为教学PPT的版式与内容结构参考。1. 云计算里最容易被绕过去的那个词分布式计算做云计算运维这两年我有个很深的感受很多人对分布式计算的了解停留在“把任务分给多台机器跑”这一句话上可真到了集群上用起来任务卡死、数据倾斜、节点忙闲不均一个个问题全冒出来了。这份《云计算之分布式计算》课件把 MapReduce 工作流程、Google 技术栈和 Apache 生态的对照关系、Amdahl 定律的边界全都串了起来特别适合两类人一是刚接触离线数仓、想知道批量计算到底怎么运转的新手二是已经用着 Hadoop 生态、但一直没搞清楚 Pregel、Tenzing、Hama 这些名字背后对应关系的云计算运维工程师。它能解决的核心问题是让你从“会用命令”进到“知道为什么这么设计”。2. 批量计算的骨架MapReduce 工作流程与任务划分2.1 Map 阶段数据切分、分片与本地计算MapReduce 的起点是把输入数据切成若干分片split。课件里用“统计天气预报中每个字出现次数”这个例子把昨天、今日、明天三天的天气文本分别交给三个 Slave 节点处理每个节点拿到的是完整的一条记录而不是跨行的半截数据。这种按行切分的策略在 Hadoop 里叫 InputSplit默认情况下每个分片对应一个 HDFS 块默认 128MB但注意分片边界和块边界不一定对齐分片会记录“文件路径 起始偏移 长度”这样才能保证一条记录不被切到两个分片里。Map 任务读到自己负责的分片后逐行解析输出键值对。以“小雨转多云”为例Map 输出的是小,1、雨,1、转,1、多,1、云,1这样的中间结果。这里有一个容易被新手忽略的细节Map 输出不是直接写磁盘而是先写进环形缓冲区默认 100MB当缓冲区写到 80% 阈值时后台线程开始 spill 到本地磁盘并且在 spill 过程中做分区和排序。分区数量由 Reduce 任务数决定排序则是按 key 进行。课件里 Master 只负责调度不参与实际计算这个角色划分非常关键——Master 挂了整个作业就废了所以生产环境里通常会为 Master 配 HA。2.2 Reduce 阶段键值路由、数据再分布与归并Reduce 阶段要做的事是从所有 Map 输出里把相同 key 的值归到同一个 Reducer 里。课件里展示了“统计‘小’”“统计‘雨’”“统计‘转’”等多个 Reduce 任务并行工作的画面。数据传播过程很直观Map 端输出的键值对按 key 哈希后分不到同区Reduce 端从各个 Map 节点拉取属于自己分区的中间结果然后做一次归并排序再调用用户写的 reduce 函数。这个环节有一个很容易踩的坑如果某个 key 特别多比如“雨”出现了 2 次而其他字只有 1 次所有“雨”的键值对都会被分到同一个 Reducer这就叫数据倾斜。课件里虽然没明说但从示例数据能看出来前三个 Slave 的输出里“雨”出现了 4 次如果按 key 哈希这个 Reducer 的负担会明显高于其他 Reducer。解决思路通常是加一层随机前缀做二次散列或者改用 Combine 在 Map 端先做一次局部归并来减少传输量。2.3 用课件里的例子完整推演一遍把课件里的天气文本作为输入推演过程可以梳理成一张表阶段输入输出示例说明原始数据昨天小雨转多云今日多云转阵雨明天小雨转中雨三条文本记录按行切分三个 Map 各处理一条Map 输出每条记录拆成单字小,1 雨,1 转,1 多,1 云,1逐字拆分按空格分词在此场景简化为单字分区路由所有 Map 的中间结果按 key 哈希到三个 Reduce 分区“雨”“云”“转”等高频字可能集中到同一分区Reduce 归并各分区内按键排序统计出小:1, 雨:2, 多:1, 云:1相同 key 合并输出最终计数这里可以看出 MapReduce 的一个核心设计哲学计算向数据移动而不是数据向计算移动。每个 Map 只处理本地分片Reduce 再拉取中间结果整个过程的并行度由分片数量和 Reduce 任务数共同决定。单纯增加 Reduce 数量并不能线性提升性能因为数据 shuffle 的网络开销会同步上升单纯增加分片数量则会让 Master 的调度压力变大。课件里那一屏“Master 与三个 Slave”的调度关系其实就是一套微缩版的 YARN 资源调度。3. Google 技术栈与 Apache 生态一张对照表理清血缘关系3.1 存储层GFS 与 HDFS 的对应关系课件里有一页专门做 Google 与 Apache 的对应GFS 对应 HDFSBigTable 对应 HBaseMapReduce 对应 MapReducePregel 对应 HamaTenzing 对应 Hive。这个对照表对从业者的价值在于理解了 Google 的原始设计动机就理解了 Hadoop 生态的演进逻辑。GFS 的原始论文解决了三个问题单机磁盘容量不够、单机磁盘损坏概率高、多机文件访问需要统一命名空间。HDFS 把这套思想原样搬了过来采用 128MB 大块、三副本冗余、NameNode 统一元数据管理的方案。生产环境里副本数不是拍脑袋定的3 是可靠性与成本的平衡点2 副本在机房断电场景下可能双盘同时失联4 副本的存储成本直接多出三分之一。课件里讲“分布式环境”时强调企业要构建大规模数据中心这正是存储层的现实背景——没有可靠的分布式文件系统计算框架就是空中楼阁。3.2 数据管理层BigTable 与 HBase 的适用边界BigTable 是一张稀疏的、分布式的、持久化的多维映射表行键、列族、时间戳三个维度决定一个单元格。HBase 完整继承了这套模型。实际使用中我经常看到有人拿 HBase 当传统关系型数据库用这是误解HBase 没有跨行事务索引只有 RowKey 一种二级索引要靠自己维护。课件把 BigTable/HBase 归到“数据管理”而不是“数据库”这个分类很准确。HBase 的 RowKey 设计直接决定读写热点如果用时间戳当 RowKey 前缀最新数据会全部写到最后一个 Region形成写热点。常见做法是倒序时间戳或者加盐前缀比如用户 ID 哈希值取模。课件里没有展开这些细节但从“提供快速读写能力”这句话可以推导出RowKey 散列均匀是前提条件。3.3 计算框架与查询层Pregel、Hama、Tenzing、Hive 的角色Pregel 是 Google 的图计算框架采用“以顶点为中心的 BSP 模型”每个超步superstep里所有顶点并行执行用户自定义函数顶点之间通过消息传递通信。Hama 在 Apache 生态里对应实现了这套模型。注意 Pregel 不是万能的图计算方案BSP 模型对幂律分布的网络图比如社交关系图会产生严重的消息倾斜——少数热门顶点每个超步会收到海量消息。课件里把它和 MapReduce 并列说明 Google 自己也意识到 MapReduce 不适合迭代计算每一轮迭代都要落盘一次性能开销太大。Tenzing 对应 Hive但两者的定位有微妙差别。Tenzing 是 Google 内部用来在 MapReduce 之上跑 SQL 的引擎核心思路是“把查询翻译成 MR 作业”Hive 最开始也是这个思路把 HiveQL 编译成 MapReduce 执行计划。注意 Hive 在一条查询里会生成多个 MR Job每两个 Job 之间都有落盘所以写 Hive SQL 要特别小心 join 顺序和子查询嵌套层级。课件把这层称为“SQL 查询引擎”本质上是给不写 Java 的分析人员一个 SQL 入口。3.4 一份可落地的选型对照表层次Google 方案Apache 对应方案典型适用场景文件系统GFSHDFS海量文件存储、批处理输入输出分布式数据库BigTableHBase稀疏结构化数据、实时读写批量计算框架MapReduceHadoop MapReduce离线清洗、ETL、全量统计迭代图计算PregelHama网页排名、社交图谱、最短路径SQL 查询引擎TenzingHive数仓分析、即席查询、报表任务这张表的价值在于选型时可以按层次逐个对照。比如一个实时写入、秒级查询的需求选 HBase 是合理的如果查询模式复杂、涉及多表关联就应该把数据同步到 Hive 做离线分析而不是强行在 HBase 上跑全表扫描。我在实际项目里见过不少翻车案例根因都是把这张表里的层次搞混了比如用 Hive 承接实时写入或者用 HBase 跑复杂的聚合分析。4. Amdahl 定律并行加速比的边界到底在哪4.1 定律的推导与工业化直觉课件用“泡茶”这个例子引入 Amdahl 定律洗开水壶1分钟、洗茶壶3分钟、拿茶叶2分钟、泡茶2分钟、烧开水15分钟、洗茶杯2分钟。如果一个人完成总耗时是 25 分钟但烧开水 15 分钟可以和洗茶壶、拿茶叶、洗茶杯并行最理想的并行路径是先洗开水壶 1 分钟再烧开水 15 分钟同时在烧水期间并行洗茶壶、拿茶叶、洗茶杯需要 3227 分钟 15 分钟最后泡茶 2 分钟。总耗时变成 115218 分钟而不是 25/无限大。这就是 Amdahl 定律的直观体现串行部分决定了加速比上限。公式上如果问题规模固定为 1其中不可并行部分占 f那么无论如何增加处理器数量最大加速比不会超过 1/f。在这个例子里洗开水壶和泡茶是必须串行的f 3/25加速比上限约 8.3 倍——但实际上受限于“烧开水 15 分钟”这个瓶颈实际加速比只有 25/18 ≈ 1.39 倍。生产环境里这个定律经常被忽略。我见过一个案例某团队把跑批时间从 2 小时优化到 30 分钟然后想继续加节点压到 10 分钟结果节点翻倍后时间只降到 22 分钟。原因就是数据导入和结果写回这两个串行环节占据了固定开销加机器对它们毫无帮助。课件里那句“并行加速比不超出 1/f”不是理论摆设是做容量规划时必须先算的一笔账。4.2 核心参数串行比例 f 的估算方法做并行度规划时我一般会把作业拆成四段话数据读取、计算处理、Shuffle 传输、结果写回。前两段和后两段的可并行程度完全不同。阶段是否可并行占比经验值优化手段数据读取可并行15%增加 InputSplit但受限于文件格式计算处理可并行60%加 Map/Reduce 并行度注意数据倾斜Shuffle 传输部分可并行20%压缩中间结果调整分区策略结果写回几乎不可并行5%减少输出文件数使用压缩输出格式从这个表能推算出即使把计算处理全部并行化加速比上限也受读取和写回限制。把 f 定为 0.2读 写 部分 shuffle 的串行损耗则加速比上限为 5 倍。这也解释了为什么 MapReduce 作业从 10 个节点扩到 50 个节点提速往往不到 3 倍——数据读取和结果合并的开销跟着涨上去了。4.3 集群规模设计一个 1TB 数据的估算流程假设一个离线作业要处理 1TB 文本数据单机处理能力约 20MB/s串行处理需要 50000 秒约 14 小时。如果引入 10 个节点并行理论上加速比接近 10 倍但算上启动开销、调度延迟和 shuffle 网络传输实际可用系数通常在 0.60.8 之间。我一般按这个流程估算先规定目标时间 T比如 60 分钟内再估算单节点吞吐量 V比如 20MB/s算出理论节点数 N 数据量 /V × T × 并行效率。代入 1TB 数据目标 1 小时V20MB/s并行效率 0.7N ≈ 1024×1024 /20×3600×0.7≈ 20.8取整 21 个节点。这里要再回代 Amdahl 定律验证如果串行部分 f 占 20%21 节点的最大加速比是 1 / (0.2 0.8/21) ≈ 3.9远小于 21——说明这个作业想靠加节点提速是做不到的真正的瓶颈是串行部分而不是并行度不够。5. 离线批量计算的常见翻车点从任务卡死到数据倾斜5.1 现象某个 Reduce 长期卡在 99%其他早已跑完原因数据倾斜某个 key 的数据量远超其他 key分配到单个 Reducer 后成为长尾。课件里的天气预报例子虽然数据量小但“雨”字出现次数明显偏多已经能看出这种趋势。解决先在 Map 端做 Combine减少 shuffle 数据量如果倾斜依旧给 key 加随机前缀做二次散列把大 key 拆到多个 Reducer 再合并结果。另一个思路是把倾斜 key 单独提取出来用两个 Job 分别处理最后 union 结果。注意加前缀后会导致原本有序的输出变成近似有序下游如果有排序依赖要额外处理。5.2 现象集群资源充足但作业一直处于 ACCEPTED 状态原因ResourceManager 等待调度但不是因为 CPU 或内存不足而是 NAME 里队列配置的 AM 资源上限被占满。很多团队把多个作业提同到同一个队列ApplicationMaster 本身也要占用容器资源AM 数量达到上限后作业只能排队。解决检查 YARN 队列配置把yarn.scheduler.capacity.maximum-am-resource-percent从默认的 0.1 调高到 0.20.3或者为不同作业划分独立队列。同时检查作业的 AM 请求内存是否超出单个节点可用资源。这类问题最隐蔽的地方在于集群总资源看起来是够的但 AM 资源这个特定维度被卡死了。5.3 现象Map 阶段已经结束但 Shuffle 阶段网络传输特别慢原因中间结果数据量过大且没有开启压缩。默认情况下 MapReduce 的中间结果是不压缩的1TB 输入数据的中间结果可能膨胀到 23TB全走网络传输。解决开启中间结果压缩mapreduce.map.output.compresstrue压缩格式选 Snappy 或 LZ4这类压缩编解码器对 CPU 开销小、压缩率高。我之前在一个 300GB 的作业上开启 Snappy 压缩后shuffle 时间从 40 分钟降到 12 分钟。注意最终输出如果要被下游直接读取不要用 Snappy 而是考虑 Gzip或者用 Parquet 列式存储自带压缩。5.4 现象作业在 Map 阶段反复重试同一批任务原因某些 Map 任务因为读取特定数据块失败而反复重试比如 HDFS 上某个块损坏或节点磁盘故障。另一个常见原因是推测执行Speculative Execution被打开当某个任务执行明显慢于其他任务时集群会启动一个备份任务竞争。如果慢任务只是网络抖动而不是真正的性能问题备份任务会造成重复计算和资源浪费。解决先救援 HDFS用hdfs fsck检查损坏块并恢复对推测执行通常建议按作业类型单独设置mapreduce.map.speculativefalse。如果作业本身有数据倾斜推测执行反而会把长尾拖得更长因为每个备份任务都在处理同样的倾斜 key。5.5 现象作业跑完但输出文件数量爆炸下游加载极慢原因每个 Reduce 输出一个文件如果设置了 1000 个 Reducer就会生成 1000 个小文件。下游同步任务把大部分时间耗在打开文件上。解决调整 Reducer 数量与输出文件数匹配mapreduce.job.reduces按数据量和目标文件大小反推或者在作业末尾加一步合并把结果合并成少量大文件。更彻底的做法是改用 Hive 或 Spark SQL输出直接写动态分区目录控制每个分区的大小。课件里虽然没有讲输出设计但生产环境中文件数量对后续任务的影响往往比计算本身更大。6. 准实时计算的三个进阶方向增量更新、交互查询与图迭代课件里把技术趋势分成批量计算、准实时计算和实时计算三条线。MapReduce 解决了批量Percolator 和 Dremel 解决准实时而这正是从“离线跑批”往“实时数仓”迁移的中间站。Percolator 的思路很容易理解不再全量重算而是只处理变更的数据。课件把它叫“数据增量更新系统”实现上依赖 BigTable 的列级时间戳和分布式锁用两阶段提交保证跨行事务。我在实际项目中做过类似的设计核心是把变更记录放到消息队列里下游拿增量数据去更新宽表而不是每天凌晨全量刷一遍。这样能显著缩短数据可见性延迟但要注意增量更新是“最终一致”一旦某条记录处理失败需要人工补偿或者重放一次全量快照。Dremel 解决的是“我不能等 10 分钟才看到统计结果”的场景。课件把它定位成“数据分析系统”它在 Google 内部支撑了万亿行日志的秒级扫描原理是列式存储加多级聚合树。开源生态里对应的是 Presto/Trino 和 ClickHouse。如果你在做云计算运维遇到的需求是“用户要看过去 7 天每分钟的请求量”Dremel 这类 MPP 引擎比 MapReduce 合适得多。我的习惯做法是把明细数据同时导一份到列式存储查询走 MPP 引擎批处理仍然走 Hive 离线链路两条链路各管各的。Tenzing 之后是 Hive 生态的演进方向。课件里 Tenzing 和 Hive 被放在同一格但今天的 Hive 已经支持 Tez 或 Spark 作为执行引擎落盘次数明显减少。我的经验是运维同学评估一套离线数仓方案时先看三点数据多快可见、查询多快返回、扩节点是不是线性提速对应的正好是批量、准实时、实时三条线的取舍。从那以后我每次接到新的数据处理需求都强制先问一句这是不是一定要全量重算如果有 20% 数据每天都变就应该优先考虑增量方案而不是加节点硬扛全量。项目上线前也必拿 Amdahl 定律估算一遍串行比例避免交付一个加机器也提不了速的集群。希望帮到你。本文还有配套的精品资源点击获取