MIT6.824 L1 Introduction

分布式

为什么要用分布式

  1. 更好地组织管理物理上分离的实体
  2. 通过隔离保证安全
  3. 通过副本进行容错
  4. 通过并发的CPU/内存/磁盘/网络来扩容吞吐量

分布式的缺点

并发的复杂性,应对“部分”失败,难以实现性能潜力

Topic

  • 实现:RPC、线程、并发控制
  • 性能:越多的机器越容易带来的问题->负载不均衡,非并发的代码,共享资源的瓶颈
  • 容错:可用性,持久性,服务器副本
  • 一致性:
    • 副本难以保证相同->客户端/服务器崩溃,脑裂的风险
    • 与高性能的冲突->因为保持一致性需要高强度的沟通

Case Study: MapReduce

用于大规模数据集(>1T)的并行运算

Map:解析原始数据,提取生成多个K-V对

Reduce:消费每一列K-V数据

Topic

MR可以很好的扩展,因为Maps并发执行时,不会互相影响,Reduces也是,因此可以通过买更多的机器来获得更高的吞吐量,而不是以应用为单位进行专用的并发。

MR的性能限制(即优化点):带宽。所有的数据在Map-Reduce间的随机洗牌时,都经由网络,因此对带宽要求较高。但是现在的DataCenter网络快了很多。

Q:如何减少慢网速带来的影响?

A:1. M从本地磁盘的GFS副本而非网络读取输入;2. 中间数据只通过一次网络;3. M写入本地磁盘,而非GFS;4. 中间数据划分为持有多个键的文件 小问题:为什么不通过TCP将M产生的记录流入R

Q:如何实现负载均衡

A:比生产者多得多的任务(?)。1. master将新任务分配给已经完成前一个任务的生产者;2. 没有特别大的任务占据完成时间; 3. 更快的服务器可以在相同时间内完成更多的任务。

Q:容错如何?

A:当服务器在执行一个MR任务时崩了怎么办,更好的解法是隐藏错误,而不是重新开始所有任务。因为MR的任务在调用过程中是无状态的,除了MR的输入输出,也不会进行读写文件,并且不会隐藏任务间的交互,所以重新执行同一个任务会产生同样的结果。这个特点具有一定的限制,但是对MR的简洁性来说很重要。

关于生产者崩溃恢复的一些细节:

  • Map崩溃时:
    • master看到map长时间不响应,崩溃的map无法产生输出的中间数据,但是reduce任务需要它
    • master重启,分发其他GFS副本的输入
    • 一些reduce可能会读取了崩溃的map的中间数据,因此map必须是确定的
    • 如果reduce获取到了所有中间数据,则master不需要重启map,监管如此,reduce崩溃将强制重新执行失败的map
  • Reduce崩溃时:
    • 已经完成的任务就不用再管,master在其他reduce上重启未完成的任务

其他问题:

Q:master给两个map分配了同一个任务怎么办?

A:可能master认为其中一个已经挂了,只要告诉reduce其中一个就行

Q:master给两个reduce分配了同一个任务怎么办?

A:他们都会执行并且输出,但是GFS会保证唯一

Q:某个生产者特别慢怎么办?

A:可能是硬件故障,把剩下的任务丢给其他人去做

Q:master挂了怎么办?

A:断点恢复,或者放弃任务

MR不适用的场景:

  1. 少量数据,因为费用高(比如web后端)
  2. 大量数据的少量更新
  3. 不确定的输入
  4. 多重洗牌
  5. 以上场景需要更灵活的系统和更复杂的模型

Paper

MapReduce: Simplified Data Processing on Large Clusters

Table of Contents