学习分布式系统须要怎样的知识

来源：

https://www.zhihu.com/question/23645117/answer/124708083

 

个人 PhD 研究方向是分布式系统，我老板也是分布式系统出身，咱们实验室在这方面的积累还算不错，因此借此问题谈谈本身的见解。首先须要说明的是，分布式系统是一个复杂且宽泛的研究领域，学习一两门在线课程，看一两本书可能都是不能彻底覆盖其全部内容的。介于这篇文章是引导初学者入门，因此我我的以为为初学者介绍一下当前分布式系统领域的全貌，也许比直接推荐论文和课程更有帮助。当初学者对这个领域创建起一个大的 Picture 以后，能够根据本身的兴趣，有选择性地深刻不一样领域进行进一步的学习。

 

本文主要试图回答如下两个问题：

 

1.  近些年分布式系统领域都在作些什么。
2.  为何如今投入分布式系统的学习和研究是值得的。

 

我会尽量多地去介绍更 “实用” 的分布式系统知识。

 

什么是实用？例如：

 

• Paxos 是分布式系统里一个重要并且实用的技术。

• Consistent Hash 也是分布式系统里一个重要并且实用的技术。

• MapReduce、Spark 等等都是很实用的系统。

 

什么不实用？ 例如：

 

• Paxos 算法的数学证实。（注意此处“不实用” 和 “不重要”的区别）

 

固然，分布式系统实在是一个太宽泛的话题，本人才疏学浅，回答也仅仅可能侧重于我所关心的领域和方向，不少地方都不能面面俱到。因此在此只能抛砖引玉， 走马观花，欢迎你们提出宝贵意见，我也会及时对文章进行修改和补充。

 

分布式系统近些年都在作些什么？

 

分布式系统是一个古老而宽泛的话题，而近几年由于 “大数据” 概念的兴起，又焕发出了新的青春与活力。除此以外，分布式系统也是一门理论模型与工程技法并重的学科内容。相较于机器学习这样的研究方向，学习分布式系统的同窗每每会感受：“入门容易，深刻难”。

 

的确，学习分布式系统几乎不须要太多数学知识（相比于机器学习），这也是为何会形成 “入门容易” 的错觉。然而一旦深刻下去，每每须要咱们去体会 System 研究的 “简洁” 与 “美”，正如李沐的回答中说的那样，系统工做是 “艺术” 而不是 “科学” ，这一点我以为是系统研究工做最难，同时也是最精华的地方。总之把握一点原则：好的系统研究工做，尤为是分布式系统研究，必定是尽量地用最简单、最直观的方法去解决实际的问题（看看 MapReduce 就知道了），由于简单就意味着实用。

 

整体来讲，分布式系统要作的任务就是把多台机器有机地组合、链接起来，让其协同完成一件任务，能够是计算任务，也能够是存储任务。若是必定要给近些年的分布式系统研究作一个分类的话，我我的认为大概能够包括三大部分：

 

1.  分布式存储系统 
2.  分布式计算系统 
3.  分布式管理系统

 

近十年来在这三个方向上，毫无疑问， Google 都是开创者，甚至不少业内人士都说，这十年是外界追随谷歌技术的十年。咱们以前说到，分布式系统的研究是一门由实际问题驱动的研究，而 Google 则是最早须要面对这些实际问题的公司。下面咱们分别看看这三个方面工业界以及学术界这几年都在作些什么。

 

分布式存储系统：

 

分布式存储系统是一个很是古老的话题，同时也是分布式系统里最难，最复杂，涉及面最广的问题。 往细了分，分布式存储系统大概能够分为四个子方向：

 

1.  结构化存储 
2.  非结构化存储 
3.  半结构化存储 
4.  In-memory 存储

 

除了这四个子方向以外，分布式存储系统还有一系列的理论、算法、技术做为支撑：例如 Paxos、CAP、ConsistentHash、Timing（时钟）、2PC、3PC 等等，这些内容咱们会在后面提到。如今，咱们先来看看上述四个子方向大体都在干些什么。

 

结构化存储（Structured Storage Systems）的历史很是古老，典型的场景就是事务处理系统或者关系型数据库（RDBMS）。传统的结构化存储都是从单机作起的，好比你们耳熟能详的  MySQL。有句话说：MySQL 的成长史就是互联网的成长史。这一点也不为过。除了 MySQL 以外，PostgreSQL 也是近几年来势头很是强劲的一个 RDBMS。咱们发现，传统的结构化存储系统强调的是：（1）结构化的数据（例如关系表）；（2）强一致性 （例如，银行系统、电商系统等场景）；（3）随机访问（索引、增删查改、SQL 语言）。然而，正是因为这些性质和限制，结构化存储系统的可扩展性一般都不是很好，这在必定程度上限制告终构化存储在大数据环境下的表现。随着摩尔定律面临的瓶颈，传统的单机关系型数据库系统面临着巨大的挑战。不过真的没办法了吗？在此咱们先埋下一个伏笔：）

 

非结构化存储 （No-structed Storage Systems）：和结构化存储不一样的是，非结构化存储强调的是高可扩展性，典型的系统就是分布式文件系统。分布式文件系统也是一个古老的研究话题，好比 70 年代的 Xerox Alto、80 年代的 NFS、AFS、90 年代 xFS 等等。然而，这些早期的分布式文件系统只是起到了网络磁盘的做用，其最大的问题就是不支持容错 （Fault Tolerance）和错误恢复 （Fault Recovery）。而 Google 在 2003 年 SOSP 上推出的 GFS（Google File System）则是作出了里程碑的一步，其开源实现对应为  HDFS。GFS 的主要思想包括：

 

（1）用 Master 来管理 Metadata。
（2）文件使用 64MB 的 Chunks 来存储，而且在不一样的 Server 上保存多个副本。
（3）自动容错，自动错误恢复。

 

Google 设计 GFS 最初的目的是为了存储海量的日志文件以及网页等文本信息，而且对其进行批量处理（例如配合 MapReduce 为文档创建倒排索引，计算网页 PageRank 等）。和结构化存储系统相比，虽然分布式文件系统的可扩展性、吞吐率都很是好，可是几乎没法支持随机访问（Random Access）操做，一般只能进行文件进行追加（Append）操做。而这样的限制使得非结构化存储系统很难面对那些低延时，实时性较强的应用。

 

半结构化存储 （Semi-structure Storage Systems）的提出即是为了解决非结构化存储系统随机访问性能差的问题。咱们一般会听到一些流行的名词，好比 NoSQL、Key-Value Store,  甚至包括对象存储，例如 Protobuf、Thrift 等等。这些都属于半结构化存储研究的领域，其中以 NoSQL 近几年的发展势头尤其强劲。NoSQL 系统既有分布式文件系统所具备的可扩展性，又有结构化存储系统的随机访问能力（例如随机 Update、Read 操做），系统在设计时一般选择简单键值（K-V）进行存储，抛弃了传统 RDBMS 里复杂 SQL 查询以及 ACID 事务。这样作能够换取系统最大限度的可扩展性和灵活性。在 NoSQL 里比较有名系统包括：Google 的 Bigtable、Amazon 的 Dynamo，以及开源界大名鼎鼎的 HBase、Cassandra 等。一般这些 NoSQL 系统底层都是基于比较成熟的存储引擎，好比 Bigtable 就是基于 LevelDB（Jeff dean 写的，很是好的 C++ 源码教程），底层数据结构采用 LSM-Tree，除了 LSM-Tree 以外 B-Tree （B+Tree）也是很成熟的存储引擎数据结构。

 

In-memory 存储：随着业务的并发愈来愈高，存储系统对低延迟的要求也愈来愈高。 同时因为摩尔定律以及内存的价格不断降低，基于内存的存储系统也开始普及。In-memory 存储顾名思义就是将数据存储在内存中, 从而得到读写的高性能。比较有名的系统包括 Memcahed ，以及 Redis。 这些基于 K-V 键值系统的主要目的是为基于磁盘的存储系统作 Cache。还有一些偏向于内存计算的系统，好比能够追溯到普林斯顿 Kai Lee 教授早期的研究工做 Distributed Shared Memory ( DSM )，斯坦福的 RamCloud，以及最近比较火的基于 Lineage 技术的 Tachyon（Alluxio）项目（Spark 生态系统子项目）等等。

 

NewSQL：咱们在介绍结构化存储时说到，单机 RDBMS 系统在可扩展性上面临着巨大的挑战，然而 NoSQL 不能很好地支持关系模型。那是否是有一种系统能兼备 RDBMS 的特性（例如：完整的 SQL 支持，ACID 事务支持），又能像 NoSQL 系统那样具备强大的可扩展能力呢？ 2012 年 Google 在 OSDI 上发表的 Spanner，以及 2013 年在 SIGMOD 发表的 F1，让业界第一次看到了关系模型和 NoSQL 在超大规模数据中心上融合的可能性。不过因为这些系统都太过于黑科技了，没有大公司支持应该是作不出来的。好比 Spanner 里用了原子钟这样的黑科技来解决时钟同步问题，打破光速传输的限制。在这里只能对 Google 表示膜拜。

 

咱们在以前提到，分布式存储系统有一系列的理论、算法、技术做为支撑：例如 Paxos、CAP、Consistent Hash、Timing（时钟）、2PC、3PC 等等。那么如何掌握好这些技术呢？以我我的的经验，掌握这些内容必定要理解其对应的上下文。什么意思呢？就是必定要去思考为何在当下环境须要某项技术，若是没有这个技术用其它技术替代是否可行，而不是一味地陷入大量的细节之中。例如：如何掌握好 Paxos?  Paxos 本质上来讲是一个三阶段提交，更 high level 讲是一个分布式锁。理解 Paxos 必须一步一步从最简单的场景出发，好比从最简单的 Master-backup 出发，发现不行；衍生出多数派读写，发现仍是不行，再到 Paxos。以后再了解其变种，好比 Fast Paxos、Multi-Paxos。同理为何须要 Consistent Hash，咱们能够先思考若是用简单 Range Partition 划分数据有什么问题。再好比学习 2PC、3PC 这样的技术时，能够想一想他们和 Paxos 有什么关系，可否替代 Paxos。

以上是我关于分布式存储系统内容的一些总结，推荐一些相关的论文 ，有兴趣的读者能够看看：

 

• http://www.eecg.toronto.edu/~ashvin/courses/ece1746/2003/reading/ghemawat-sosp03.pdf

• http://lintool.github.io/UMD-courses/bigdata-2015-Spring/content/ChangFay_etal_OSDI2006.pdf

• https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

• http://lintool.github.io/UMD-courses/bigdata-2015-Spring/content/Khurana_etal_2012.pdf

• http://lintool.github.io/UMD-courses/bigdata-2015-Spring/content/Abadi_2012.pdf

• https://www.usenix.org/conference/osdi12/technical-sessions/presentation/corbett

• https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf

• https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html

• http://lintool.github.io/UMD-courses/bigdata-2015-Spring/content/Stonebraker_etal_CACM2010.pdf

• http://www.cs.cmu.edu/~pavlo/courses/fall2013/static/slides/mapreduce.pdf

 

分布式计算系统

 

聊完了分布式存储系统，让咱们来聊聊分布式计算系统 ：） 首先解决一个不少初学分布式计算的同窗的疑惑：分布式计算和并行计算是一回事吗？最初我也有这样的疑惑，而如今个人理解是这样的：

 

• 传统的并行计算要的是：投入更多机器，数据大小不变，计算速度更快。

• 分布式计算要求：投入更多的机器，能处理更大的数据。

 

换句话说两者的出发点从一开始就不一样，一个强调 High Performance, 一个强调 Scalability。举例来讲，MapReduce 给业界带来的真正思考是什么？实际上是给咱们普及了 Google 这样级别的公司对真正意义上的「大数据」的理解。由于在 04 年论文出来以前，搞并行计算的人压根连 「容错」的概念都没有。换句话说，分布式计算最为核心的部分就是「容错」，没有容错，分布式计算根本无从谈起。MapReduce 统要作成这个样子（Map ＋ Reduce），其实就是为了容错。

 

然而不少初学分布式计算的同窗对容错的概念多多少少是有误解的。包括我在初学 MapReduce 的时候也会思考：好好的计算怎么就会出错了呢？一方面，因为硬件的老化，有可能会致使某台存储设备没有启动起来，某台机器的网卡坏了，甚至于计算运行过程当中断电了，这些都是有可能的。然而最频繁发生的错误是计算进程被杀掉。由于 Google 的运行环境是共有集群，任何一个权限更高的进程均可能 Kill 掉你的计算进程。设想在一个拥有几千台机器的集群中运行，一个进程都不被 Kill 掉的几率几乎为零。具体的容错机制咱们会在后面介绍具体的系统时提到。

 

另外一个有意思的话题是，随着机器学习技术的兴起，愈来愈多的分布式计算系统是为了机器学习这样的应用设计的，这也是我比较关注的研究领域，也会在后面重点谈到。

 

如同分布式存储系统同样，我对分布式计算系统也作了一个分类，以下：

 

1.  传统基于 MSG 的系统 
2.  MapReduce-like 系统 
3.  图计算系统
4.  基于状态（State）的系统 
5.  Streaming 系统

 

固然不一样的人可能会有不一样的分类方法，不过大同小异。咱们接下来聊聊这些系统都在干些什么。

 

传统基于MSG的系统：这类系统里比较有表明性的就是 MPI （Message Passing Interface）。目前比较流行的两个 MPI 实现是 MPICH2 和 OpenMPI。MPI 这个框架很是灵活，对程序的结构几乎没有太多约束，以致于你们有时把 MPI 称为一组接口 API, 而不是系统框架。在这些 API 里最经常使用的两个就是 send 和 recv 接口（还有一系列非阻塞扩展接口，例如：Isend、Irecv 等）。MPI 除了提供消息传递接口以外，其框架还实现了资源管理和分配，以及调度的功能。除此以外，MPI 在高性能计算里也被普遍使用，一般能够和 Infiniband 这样的高速网络无缝结合。

 

除了 send 和 recv 接口以外，MPI 中另外一个接口也值得注意，那就是 AllReduce。这个接口在不少机器学习系统开发里都很用。由于不少并行机器学习系统都是各个进程分别训练模型，而后在合适的时候（例如一轮迭代结束）你们同步一下答案，达成共识，而后继续迭代。这个 “达成共识” 的操做每每能够很方便地经过 AllReduce 来完成。 AllReduce 接口具备两个优势：高效和使用简单。 先说说为何使用简单：使用 AllReduce 一般只须要在单机核心源码里加入  AllReduce 一行代码，就能完成并行化的功能。说 AllReduce 高效的缘由是由于其底层消息传递使用了 Tree Aggregation，尽量地将计算分摊到每个节点。

 

但是，既然 AllReduce 这么好，为何在实际大规模计算中不多看到呢？缘由很简单，就是由于  MPI 不支持容错，因此很难扩展到大规模集群之上。不过最近陈天奇写了一个支持容错的 AllReduce 接口，叫 Rabit，有兴趣的同窗能够关注一下。 大名鼎鼎的 XGBoost 底层的分布式接口就是 Rabit。

 

MapReduce-like 系统：这一类系统又叫做 Dataflow 系统，其中以 MapReduce（Hadoop）和 Spark 为表明。其实在学术界有不少相似的系统例如 Dryad、FlumeJava、Twister 等等。这一类系统的特色是将计算抽象成为 High-Level Operator，例如像 Map、Reduce、Filter 这样的函数式算子，而后将算子组合成 DAG ，而后由后端的调度引擎进行并行化调度。其中，MapReduce 系统属于比较简单的 DAG，只有 Map 和 Reduce 两层节点。MapReduce 这样的系统之因此能够扩展到超大规模的集群上运行，就是由于其完备的容错机制。在 Hadoop 社区还有不少基于 MapReduce 框架的衍生产品，好比 Hive（并行数据库 OLAP）、Pig（交互式数据操做）等等。

 

MapReduce-like 的编程风格和 MPI 截然相反。MapReduce对程序的结构有严格的约束——计算过程必须能在两个函数中描述：Map 和 Reduce；输入和输出数据都必须是一个一个的 Records；任务之间不能通讯，整个计算过程当中惟一的通讯机会是 Map Phase 和 Reduce Phase 之间的 Shuffuling Phase，这是在框架控制下的，而不是应用代码控制的。由于有了严格的控制，系统框架在任什么时候候出错均可以从上一个状态恢复。Spark 的 RDD 则是利用 Lineage，可让数据在内存中完成转换。

 

因为良好的扩展性，许多人都将机器学习算法的并行化任务放在了这些平台之上。比较有名的库包括 Mahout（基于 Hadoop），以及 MLI （基于 Spark) 。然而这些系统最大缺点有两点：

 

1. 这些系统所能支持的机器学习模型一般都不是很大。致使这个问题的主要缘由是这系统在 push back 机器学习模型时都是粗粒度地把整个模型进行回传，致使了网络通讯的瓶颈。有些机器学习的模型能够大到没法想象，好比咱们用 Field-aware Factorization Machine （FFM）作  Criteo 的 CTR Prediction 时模型大小能够达到 100 GB.

 

2. 严格的 BSP 同步计算使得集群的效率变得很低。也就是说系统很容易受到 straggle 的影响。

 

图计算系统：图计算系统是分布式计算里另外一个分支，这些系统都是把计算过程抽象成图，而后在不一样节点分布式执行，例如 PageRank 这样的任务，很适合用图计算系统来表示。最先成名的图计算系统当属 Google  的 Pregel，该系统采用 BSP 模型，计算以 Vectex 为中心。随后又有一系列图计算框架推出，例如：GPS （对 Pregel 作了优化，除了 Vectex-centric Computation，还有 Global Computation，动态调整分区等等。）Giraph / Hama 都是基于 Hadoop 的 Apache 的开源 BSP 图计算项目。

 

除了同步（BSP）图计算系统以外，异步图计算系统里的佼佼者当属 GraphLab，该系统提出了 GAS 的编程模型。目前这个项目已经更名为 Dato，专门推广基于图的大规模机器学习系统。

 

基于状态（State）的系统：这一类系统主要包括 2010 年 OSDI 上推出的 Piccolo，以及后来 2012 年 NIPS 上 Google 推出的 DistBelief，再到后来被机器系学习领域普遍应用的 Parameter Server 架构。这里咱们重点介绍一下 Parameter Server 这个架构。

 

咱们以前说，MPI 因为不支持容错因此很难扩展至大规模集群之中；MapReduce 系统没法支持大模型机器学习应用，而且节点同步效率较低。用图抽象来作机器学习任务，不少问题都不能很好地求解，好比深度学习中的多层结构。而 Parameter Server 这种 State-Centric 模型则把机器学习的模型存储参数上升为主要组件，而且采用异步机制提高处理能力。参数服务器的概念最先来自于 Alex Smola 于 2010 年提出的并行  LDA 架构。它经过采用分布式的 Memcached 做为存放参数的存储，这样就提供了有效的机制做用于不一样Worker节点同步模型参数。Google 的 Jeff Dean 在 2012 年进一步提出了第一代 Google Brain 大规模神经网络的解决方案 Distbelief。后来  CMU  的 Eric xing 以及百度少帅李沐都提出了更通用的 Parameter server 架构。

 

若是要深刻 Parameter Server 系统的设计，须要一些机器学习的背景，好比什么是 SSP  协议， 在此咱们就不详细讨论了。

 

Streaming 系统：Streaming 系统听名字就能看出来是为流式数据提供服务的。其中比较有名的系统包括 Storm、Spark Streaming、Flink 等等。因为本人对这个领域并非很熟，就不详细介绍了。

 

以上是我对分布式计算系统的一些介绍，其实每个方向深刻下去都是一个研究领域，在此推荐一些论文：

 

• MapReduce: Simplified Data Processing on Large Clusters

• Resilient Distributed Datasets

• Scaling Distributed Machine Learning with the Parameter Server

• Distributed GraphLab: A Framework for Machine Learning

• Piccolo: Building Fast, Distributed Programs with Partitioned ..

• Petuum: A New Platform for Distributed Machine Learning on Big Data

• Spark Streaming

• Dryad: Distributed Data-parallel Programs from Sequential Building ...

• Large Scale Distributed Deep Networks - NIPS Proceedings

 

-End-