MIT6.824
  • 简介
  • Lecture 01 - Introduction
    • 1.1 分布式系统的驱动力和挑战（Drivens and Challenges）
    • 1.2 课程结构（Course Structure）
    • 1.3 分布式系统的抽象和实现工具（Abstraction and Implementation）
    • 1.4 可扩展性（Scalability）
    • 1.5 可用性（Availability）
    • 1.6 一致性（Consistency）
    • 1.7 MapReduce基本工作方式
    • 1.8 Map函数和Reduce函数
  • Lecture 03 - GFS
    • 3.1分布式存储系统的难点（Why Hard）
    • 3.2 错误的设计（Bad Design）
    • 3.3 GFS的设计目标
    • 3.4 GFS Master 节点
    • 3.5 GFS读文件（Read File)
    • 3.6 GFS写文件（Write File）（1）
    • 3.7 GFS写文件（Write File）（2）
    • 3.8 GFS的一致性
  • Lecture 04 - VMware FT
    • 4.1 复制（Replication）
    • 4.2 状态转移和复制状态机（State Transfer and Replicated State Machine）
    • 4.3 VMware FT 工作原理
    • 4.4 非确定性事件（Non-Deterministic Events）
    • 4.5 输出控制（Output Rule）
    • 4.6 重复输出（Duplicated Output）
    • 4.7 Test-and-Set 服务
  • Lecture 06 - Raft1
    • 6.1 脑裂（Split Brain）
    • 6.2 过半票决（Majority Vote）
    • 6.3 Raft 初探
    • 6.4 Log 同步时序
    • 6.5 日志（Raft Log）
    • 6.6 应用层接口
    • 6.7 Leader选举（Leader Election）
    • 6.8 选举定时器（Election Timer）
    • 6.9 可能的异常情况
  • Lecture 07 - Raft2
    • 7.1 日志恢复（Log Backup）
    • 7.2 选举约束（Election Restriction）
    • 7.3 快速恢复（Fast Backup）
    • 7.4 持久化（Persistence）
    • 7.5 日志快照（Log Snapshot）
    • 7.6 线性一致（Linearizability）
  • Lecture 08 - Zookeeper
    • 8.1 线性一致（Linearizability）（1）
    • 8.2 线性一致（Linearizability）（2）
    • 8.3 线性一致（Linearizability）（3）
    • 8.4 Zookeeper
    • 8.5 一致保证（Consistency Guarantees）
    • 8.6 同步操作（sync）
    • 8.7 就绪文件（Ready file/znode）
  • Lecture 09 - More Replication, CRAQ
    • 9.1 Zookeeper API
    • 9.2 使用Zookeeper实现计数器
    • 9.3 使用Zookeeper实现非扩展锁
    • 9.4 使用Zookeeper实现可扩展锁
    • 9.5 链复制（Chain Replication）
    • 9.6 链复制的故障恢复（Fail Recover）
    • 9.7 链复制的配置管理器（Configuration Manager）
  • Lecture 10 - Cloud Replicated DB, Aurora
    • 10.1 Aurora 背景历史
    • 10.2 故障可恢复事务（Crash Recoverable Transaction）
    • 10.3 关系型数据库（Amazon RDS）
    • 10.4 Aurora 初探
    • 10.5 Aurora存储服务器的容错目标（Fault-Tolerant Goals）
    • 10.6 Quorum 复制机制（Quorum Replication）
    • 10.7 Aurora读写存储服务器
    • 10.8 数据分片（Protection Group）
    • 10.9 只读数据库（Read-only Database）
  • Lecture 11 - Cache Consistency: Frangipani
    • 11.1 Frangipani 初探
    • 11.2 Frangipani的挑战（Challenges）
    • 11.3 Frangipani的锁服务（Lock Server）
    • 11.4 缓存一致性（Cache Coherence）
    • 11.5 原子性（Atomicity）
    • 11.6 Frangipani Log
    • 11.7 故障恢复（Crash Recovery）
    • 11.8 Frangipani总结
  • Lecture 12 - Distributed Transaction
    • 12.1 分布式事务初探（Distributed Transaction）
    • 12.2 并发控制（Concurrency Control）
    • 12.3 两阶段提交（Two-Phase Commit）
    • 12.4 故障恢复（Crash Recovery）
    • 12.5 总结
由 GitBook 提供支持
在本页

这有帮助吗？

  1. Lecture 01 - Introduction

1.7 MapReduce基本工作方式

上一页1.6 一致性（Consistency）下一页1.8 Map函数和Reduce函数

最后更新于4年前

这有帮助吗？

接下来介绍MapReduce。这是一个详细的案例研究，它会展示之前讲过的大部分的思想。

MapReduce是由Google设计，开发和使用的一个系统，相关的论文在2004年发表。Google当时面临的问题是，他们需要在TB级别的数据上进行大量的计算。比如说，为所有的网页创建索引，分析整个互联网的链接路径并得出最重要或者最权威的网页。如你所知，在当时，整个互联网的数据也有数十TB。构建索引基本上等同于对整个数据做排序，而排序比较费时。如果用一台计算机对整个互联网数据进行排序，要花费多长时间呢？可能要几周，几个月，甚至几年。所以，当时Google非常希望能将对大量数据的大量运算并行跑在几千台计算机上，这样才能快速完成计算。对Google来说，购买大量的计算机是没问题的，这样Google的工程师就不用花大量时间来看报纸来等他们的大型计算任务完成。所以，有段时间，Google买了大量的计算机，并让它的聪明的工程师在这些计算机上编写分布式软件，这样工程师们可以将手头的问题分包到大量计算机上去完成，管理这些运算，并将数据取回。

如果你只雇佣熟练的分布式系统专家作为工程师，尽管可能会有些浪费，也是可以的。但是Google想雇用的是各方面有特长的人，不一定是想把所有时间都花在编写分布式软件上的工程师。所以Google需要一种框架，可以让它的工程师能够进行任意的数据分析，例如排序，网络索引器，链接分析器以及任何的运算。工程师只需要实现应用程序的核心，就能将应用程序运行在数千台计算机上，而不用考虑如何将运算工作分发到数千台计算机，如何组织这些计算机，如何移动数据，如何处理故障等等这些细节。所以，当时Google需要一种框架，使得普通工程师也可以很容易的完成并运行大规模的分布式运算。这就是MapReduce出现的背景。

MapReduce的思想是，应用程序设计人员和分布式运算的使用者，只需要写简单的Map函数和Reduce函数，而不需要知道任何有关分布式的事情，MapReduce框架会处理剩下的事情。

抽象来看，MapReduce假设有一些输入，这些输入被分割成大量的不同的文件或者数据块。所以，我们假设现在有输入文件1，输入文件2和输入文件3，这些输入可能是从网上抓取的网页，更可能是包含了大量网页的文件。

MapReduce启动时，会查找Map函数。之后，MapReduce框架会为每个输入文件运行Map函数。这里很明显有一些可以并行运算的地方，比如说可以并行运行多个只关注输入和输出的Map函数。

Map函数以文件作为输入，文件又是整个输入数据的一部分。Map函数的输出是一个key-value对的列表。假设我们在实现一个最简单的MapReduce Job：单词计数器。它会统计每个单词出现的次数。在这个例子中，Map函数会输出key-value对，其中key是单词，而value是1。Map函数会将输入中的每个单词拆分，并输出一个key-value对，key是该单词，value是1。最后需要对所有的key-value进行计数，以获得最终的输出。所以，假设输入文件1包含了单词a和单词b，Map函数的输出将会是key=a，value=1和key=b，value=1。第二个Map函数只从输入文件2看到了b，那么输出将会是key=b，value=1。第三个输入文件有一个a和一个c。

我们对所有的输入文件都运行了Map函数，并得到了论文中称之为中间输出（intermediate output），也就是每个Map函数输出的key-value对。

运算的第二阶段是运行Reduce函数。MapReduce框架会收集所有Map函数输出的每一个单词的统计。比如说，MapReduce框架会先收集每一个Map函数输出的key为a的key-value对。收集了之后，会将它们提交给Reduce函数。

之后会收集所有的b。这里的收集是真正意义上的收集，因为b是由不同计算机上的不同Map函数生成，所以不仅仅是数据从一台计算机移动到另一台（如果Map只在一台计算机的一个实例里，可以直接通过一个RPC将数据从Map移到Reduce）。我们收集所有的b，并将它们提交给另一个Reduce函数。这个Reduce函数的入参是所有的key为b的key-value对。对c也是一样。所以，MapReduce框架会为所有Map函数输出的每一个key，调用一次Reduce函数。

在我们这个简单的单词计数器的例子中，Reduce函数只需要统计传入参数的长度，甚至都不用查看传入参数的具体内容，因为每一个传入参数代表对单词加1，而我们只需要统计个数。最后，每个Reduce都输出与其关联的单词和这个单词的数量。所以第一个Reduce输出a=2，第二个Reduce输出b=2，第三个Reduce输出c=1。

这就是一个典型的MapReduce Job。从整体来看，为了保证完整性，有一些术语要介绍一下：

  • Job。整个MapReduce计算称为Job。

  • Task。每一次MapReduce调用称为Task。

所以，对于一个完整的MapReduce Job，它由一些Map Task和一些Reduce Task组成。所以这是一个单词计数器的例子，它解释了MapReduce的基本工作方式。