MIT6824 Lab1要求

介绍

在这个实验室中，您将构建一个MapReduce系统。您将实现一个调用应用程序Map和Reduce函数并处理文件读写的工作进程，以及一个协调进程，它将任务分发给工作进程并处理失败的工作进程。您将构建与MapReduce论文类似的内容。(注意:本实验室使用的是“协调员”而不是论文的“主人”。)

开始

你得准备好go语言运行环境去做实验。

使用git(一个版本控制系统)获取初始的实验室软件。要了解更多关于git的知识，请查看Pro git书籍或git用户手册。

$ git clone git://g.csail.mit.edu/6.824-golabs-2022 6.824
$ cd 6.824
$ ls
Makefile src
$

我们在src/main/ mrsequence .go中为您提供了一个简单的顺序mapreduce实现。它在单个进程中同一时间只会运行一个map和reduce。我们还为您提供了两个MapReduce应用程序:word-count in mrapps/wc。和mrapps/index . 文本索引器。你可以按如下顺序运行单词计数:

$ cd ~/6.824
$ cd src/main
$ go build -race -buildmode=plugin ../mrapps/wc.go
$ rm mr-out*
$ go run -race mrsequential.go wc.so pg*.txt
$ more mr-out-0
A 509
ABOUT 2
ACT 8
...

(注意:-race使能go启用race检测器。我们建议您使用race检测器开发和测试6.824实验室代码。然而，如果你的代码有比赛，当我们测试它时，即使没有比赛检测器，它也很有可能失败。)

mrsequential。Go将其输出保留在文件mr-out-0中。输入来自名为pg-xxx.txt的文本文件。

请随意从mrsequence .go中借用代码。你也应该看看mrapps/wc。去看看MapReduce应用程序代码是什么样的。

你的工作(中等/困难)

你的工作是实现一个分布式MapReduce，它由两个程序组成，协调器和工作器。将只有一个协调进程和一个或多个并行执行的工作进程。在真实的系统中，工作人员会在一堆不同的机器上运行，但在这个实验室中，你将在一台机器上运行所有的工作人员。工作人员将通过RPC与协调器交谈。每个工作进程将向协调器请求一个任务，从一个或多个文件读取任务的输入，执行任务，并将任务的输出写入一个或多个文件。协调器应该注意一个工作人员是否没有在合理的时间内完成它的任务(对于这个实验室，使用10秒)，并将相同的任务交给不同的工作人员。

我们给了你一个小代码来开始。协调器和工作器的“主”例程在main/mrcoordinator中。不要更改mian/ mrworker.go文件。你的代码应该放在mr/coordinator.go, mr/worker.go, and mr/rpc.go.中

下面是如何在单词计数MapReduce应用程序上运行代码。首先，确保word-count插件是新构建的:

go build -race -buildmode=plugin ../mrapps/wc.go

在main目录下，运行coordinator.。

$ rm mr-out*
$ go run -race mrcoordinator.go pg-*.txt

pg-*.txt是输入文件为mrcoordinator提供参数。每个文件对应一个“split”，是一个Map任务的输入。race flags运行与它的race检测器一起运行。在一个或多个其他窗口中，运行一些wrokers

$ go run -race mrworker.go wc.so

当works和coordinator完成时，查看mr-out-*中的输出。当你完成了实验，输出文件的排序并集应该匹配顺序输出，像这样:

$ cat mr-out-* | sort | more
A 509
ABOUT 2
ACT 8
...

我们为您提供了main/test-mr.sh中的测试脚本。测试检查wc和indexer MapReduce应用程序在给定pg-xxx.txt文件作为输入时是否产生正确的输出。这些测试还检查您的实现是否并行运行Map和Reduce任务，以及您的实现是否从运行任务时崩溃的worker中恢复。
如果你现在运行测试脚本，它将挂起，因为协调器从未完成:

$ cd ~/6.824/src/main
$ bash test-mr.sh
*** Starting wc test.

您可以在mr/coordinator的Done函数中将ret:= false更改为true。执行，以便协调器立即退出。然后:

$ bash test-mr.sh
*** Starting wc test.
sort: No such file or directory
cmp: EOF on mr-wc-all
--- wc output is not the same as mr-correct-wc.txt
--- wc test: FAIL
$

测试脚本期望在名为mr-out-X的文件中看到输出，每个reduce任务对应一个文件。mr/coordinator.go 和 mr/worker.go的空实现，不生成这些文件(或做很多其他事情)，因此测试失败。当你完成后，测试脚本输出应该如下所示:

$ bash test-mr.sh
*** Starting wc test.
--- wc test: PASS
*** Starting indexer test.
--- indexer test: PASS
*** Starting map parallelism test.
--- map parallelism test: PASS
*** Starting reduce parallelism test.
--- reduce parallelism test: PASS
*** Starting crash test.
--- crash test: PASS
*** PASSED ALL TESTS
$

您还将看到来自Go RPC包的一些错误，它们看起来如下：

2019/12/16 13:27:09 rpc.Register: method "Done" has 1 input parameters; needs exactly three

registering the coordinator as an RPC server checks if all its methods are suitable for RPCs (have 3 inputs); we know that Done is not called via RPC.
忽略这些消息;将coordinator注册为RPC服务器进行检查，如果它的所有方法都适合rpc(有3个输入),我们知道Done不是通过RPC调用的。

一些规则:

map阶段应该将中间的键值对划分不同的块为n个Reduce reduce任务，其中nReduce是reduce任务的参数main/mrcoordinator.go传递给MakeCoordinator()。因此，每个映射器都需要创建nReduce中间文件供reduce任务使用。
worker实现应该将第X个reduce任务的输出放在文件mr-out-X中。一个mr-out-X文件中的每一行是一个个Reduce函数输出的一行。这一行应该用“%v %v”格式生成，用键和值调用。看一下main/mrsequential。查找注释为“这是正确的格式”的行。如果您的实现与这种格式偏离太多，测试脚本就会失败。
您可以修改mr/worker.go, mr/coordinator.go, and mr/rpc.go. 您可以临时修改其他文件进行测试，但要确保您的代码与原始版本兼容;我们将使用原始版本进行测试。wokrers应该将中间Map输出放在当前目录中的文件中，以便workers稍后可以将它们作为Reduce任务的输入读取。
mian/ mrcoordinator。希望mr/coordinator.go 去实现一个Done()方法，当MapReduce作业完全完成时返回true;在这一点上，mrcoordinator.go将退出去。当作业完全完成时，工作进程应该退出。实现这一点的一个简单方法是使用call()的返回值:如果wokers无法联系到coordinator，它可以假定coordinator已经退出，因为任务已经完成，因此wokers程序也可以终止。
根据您的设计，您可能还会发现有一个“请退出”的伪任务是很有用的，coordinator可以将它交给wokers。

提示

指南页面提供了一些关于开发和调试的提示。

一种开始的方法是修改mr/worker.go.Worker()发送一个RPC到协调器请求一个任务。然后修改协调器，以响应尚未启动的映射任务的文件名。然后修改worker以读取该文件并调用应用程序Map函数，如mrsequence .go中所示。

应用程序Map和Reduce函数在运行时使用Go插件包从文件名以.so结尾的文件加载。

如果你修改了mr/目录中的任何内容，你可能需要重新构建你所使用的MapReduce插件，例如go build -race -buildmode=plugin …/mrapps/wc.go

这个实验依赖于工作人员共享一个文件系统。当所有工作程序运行在同一台机器上时，这很简单，但如果工作程序运行在不同的机器上，则需要像GFS这样的全局文件系统。

中间文件的合理命名约定是mr-X-Y，其中X是Map任务号，Y是reduce任务号。

worker的map任务代码将需要一种方法将中间键/值对存储在文件中，以一种能够在reduce任务中正确读取的方式。一种可能是使用Go的encoding/json包。将JSON格式的键/值对写入打开的文件:如下

 enc := json.NewEncoder(file)
  for _, kv := ... {
    err := enc.Encode(&kv)

并读回这样的文件:

dec := json.NewDecoder(file)
  for {
    var kv KeyValue
    if err := dec.Decode(&kv); err != nil {
      break
    }
    kva = append(kva, kv)
  }

worker的map部分可以使用(在worker.go中)ihash(key)函数为给定的键选择reduce任务。

你可以从mrsequential中窃取一些代码。go用于读取Map输入文件，对Map和Reduce之间的中间键/值对进行排序，以及在文件中存储Reduce输出。
coordinator作为RPC服务器，将是并发的;不要忘记锁定共享数据。
Use Go’s race detector, with go build -race and go run -race. test-mr.sh by default runs the tests with the race detector.
worker有时需要等待，例如，直到最后一个map完成，reduce才能开始。一种可能是工作人员定期向协调器请求工作，在每个请求之间与时间睡一觉。sleep()。另一种可能是协调器中的相关RPC处理程序有一个等待的循环，可以使用time.Sleep()或sync.Cond。Go在它自己的线程中为每个RPC运行处理程序，因此一个处理程序正在等待的事实不会阻止协调器处理其他RPC。最好的方法是让协调器等待一段时间，然后放弃并将任务重新分发给另一个wroker。对于这个实验室，让协调员等待10秒钟;在此之后，协调器应该假设工作者已经死亡(当然，它可能没有)。
如果您选择实现Backup Tasks(第3.6节)，请注意，我们测试您的代码在worker执行任务时不会调度无关的任务，而不会崩溃。备份任务应该只在一段相对较长的时间(例如10秒)后安排。

要测试崩溃恢复，可以使用mrapps/crash。应用程序的插件。它在Map和Reduce函数中随机退出。

为了确保没有人在崩溃的情况下观察到部分写入的文件，MapReduce论文提到了使用临时文件的技巧，并在它完全写入后原子地重命名它。你可以用ioutil。TempFile创建临时文件。Rename以原子的方式重命名它。

Test-mr.sh在子目录mr-tmp中运行它的所有进程，因此，如果出现错误，您想查看中间文件或输出文件，请查看那里。您可以临时修改test-mr.sh，以便在测试失败后退出，这样脚本就不会继续测试(并覆盖输出文件)。

test-mr-many.sh 提供了一个基本脚本(这就是我们测试代码的方式)。它将运行测试的次数作为参数。您不应该同时运行几个test-mr.sh实例，因为协调器将重用同一个套接字，从而导致冲突。

Go RPC只发送名称以大写字母开头的结构字段。子结构也必须有大写的字段名。

当向RPC系统传递应答结构的指针时，*reply所指向的对象应该为零分配。RPC调用的代码应该总是像这样

  reply := SomeType{}
  call(..., &reply)

在呼叫前不设置任何应答字段。如果您不遵循这个要求，那么当您将应答字段预初始化为该数据类型的非默认值，并且RPC所执行的服务器将该应答字段设置为默认值时，就会出现问题;您将观察到写操作似乎没有生效，而在调用方，非默认值仍然存在

挑战练习

实现你自己的MapReduce应用程序(见mrapps/*中的例子)，例如分布式Grep (MapReduce论文2.3节)。

让MapReduce协调器和工作程序在不同的机器上运行，就像在实践中那样。您需要将rpc设置为通过TCP/IP而不是Unix套接字进行通信(请参阅Coordinator.server()中的注释输出行)，并使用共享文件系统读取/写入文件。例如，您可以ssh到MIT的多个Athena集群机器，它们使用AFS共享文件;或者您可以租用几个AWS实例并使用S3进行存储。