第1章 序幕：分而治之的范式

第 1 章 · 序幕：分而治之的范式

章节摘要：本章是三幕剧开演前的序幕。先弄清 MapReduce 的定义与出身——它是 Google 2004 年提出、Hadoop 落地实现的分布式计算模型；再拆解"分而治之"如何被改造成 map 与 reduce 两个函数接口；最后把三幕剧范式的优势与代价摆在桌面上，让你在深入学习机制之前，先对这台机器的适用范围有清醒预期。

学习目标

阅读完本章，你应当能够：

1. 用三句话向同事解释 MapReduce 是什么、解决什么问题；
2. 说清 map 与 reduce 各自的输入输出契约，以及框架在契约之外替你做了哪些事；
3. 复述 2004 年前后催生 MapReduce 的工程背景（大规模网页索引构建）；
4. 判断一个计算任务是否适合 MapReduce 范式，并说出理由；
5. 列出范式的三条主要代价，并各举一个对应场景。

核心概念速览

图 1-1 从一个计算问题到三幕剧的映射

序幕只立一件事：业务逻辑只有两个函数，其余全是框架的戏份。

子章节导航

1.1 什么是 MapReduce

从 Google 爬虫与索引构建的真实痛点讲起，给出 MapReduce 的严格定义、函数式编程的血统（map 与 reduce 沿用自 Lisp 与函数式语言），并对比单机程序与 MapReduce 程序在"谁负责并行"上的根本差异。

1.2 三幕剧范式与优劣取舍

把完整计算流程折叠成"切分—映射—汇流"三幕，解释为什么这样切分阶段是理解一切后续机制的最优视角；随后正面盘点范式的长处（自动并行、容错、可扩展）与短处（不适合迭代、流式、复杂交互式查询），并给出取舍判断表。

子章节之间的逻辑关系

一句话论点：1.1 回答"它是什么、从哪来"，1.2 回答"它凭什么、值不值"——先立本体，再划边界。

  真实痛点 2004 网页索引
        │
        ▼
  1.1 定义与血统 ──► 1.2 三幕剧视角 + 优劣取舍
                          │
                          ▼
              带着范式地图进入第 2 章 第一幕 切分
​

前置知识与后续延伸

• 前置：Java 基础语法；对"进程、文件、网络传输"有常识级理解即可。
• 为后续铺垫：本章确立的"三幕"词汇表将在第 2、3、4 章逐一展开；优劣取舍表中提到的 Shuffle 开销与迭代低效，分别在第 4 章与第 7 章回收。