分布式系统论文

作者:严林
链接:https://www.zhihu.com/question/30026369/answer/46476717
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

分布式系统在互联网时代,尤其是大数据时代到来之后,成为了每个程序员的必备技能之一。分布式系统从上个世纪80年代就开始有了不少出色的研究和论文,我在这里只列举最近15年范围以内我觉得有重大影响意义的15篇论文(15 within 15)。
1. The Google File System: 这是分布式文件系统领域划时代意义的论文,文中的多副本机制、控制流与数据流隔离和追加写模式等概念几乎成为了分布式文件系统领域的标准,其影响之深远通过其5000+的引用就可见一斑了,Apache Hadoop鼎鼎大名的HDFS就是GFS的模仿之作;
2. MapReduce: Simplified Data Processing on Large Clusters:这篇也是Google的大作,通过Map和Reduce两个操作,大大简化了分布式计算的复杂度,使得任何需要的程序员都可以编写分布式计算程序,其中使用到的技术值得我们好好学习:简约而不简单!Hadoop也根据这篇论文做了一个开源的MapReduce;
3. Bigtable: A Distributed Storage System for Structured Data:Google在NoSQL领域的分布式表格系统,LSM树的最好使用范例,广泛使用到了网页索引存储、YouTube数据管理等业务,Hadoop对应的开源系统叫HBase(我在前公司任职时也开发过一个相应的系统叫BladeCube,性能较HBase有数倍提升);
4. The Chubby lock service for loosely-coupled distributed systems:Google的分布式锁服务,基于Paxos协议,这篇文章相比于前三篇可能知道的人就少了,但是其对应的开源系统zookeeper几乎是每个后端同学都接触过,其影响力其实不亚于前三篇;
5. Finding a Needle in Haystack: Facebook's Photo Storage:facebook的在线图片存储系统,目前来看是对小文件存储的最好解决方案之一,facebook目前通过该系统存储了超过300PB的数据,一个师兄就在这个团队工作,听过很多有意思的事情(我在前公司的时候开发过一个类似的系统pallas,不仅支持副本,还支持Reed Solomon-LRC,性能也有较多优化);
6. Windows Azure Storage: a highly available cloud storage service with strong consistency:windows azure的总体介绍文章,是一篇很好的描述云存储架构的论文,其中通过分层来同时保证可用性和一致性的思路在现实工作中也给了我很多启发;
7. GraphLab: A New Framework for Parallel Machine Learning:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟;
8. Resilient Distributed Datasets: A Fault-Tolerant Abstraction forIn-Memory Cluster Computing:其实就是 Spark,目前这两年最流行的内存计算模式,通过RDD和lineage大大简化了分布式计算框架,通常几行scala代码就可以搞定原来上千行MapReduce代码才能搞定的问题,大有取代MapReduce的趋势;
9. Scaling Distributed Machine Learning with the Parameter Server:百度少帅李沐大作,目前大规模分布式学习各家公司主要都是使用ps,ps具备良好的可扩展性,使得大数据时代的大规模分布式学习成为可能,包括Google的深度学习模型也是通过ps训练实现,是目前最流行的分布式学习框架,豆瓣的开源系统paracell也是ps的一个实现;
10. Dremel: Interactive Analysis of Web-Scale Datasets:Google的大规模(近)实时数据分析系统,号称可以在3秒相应1PB数据的分析请求,内部使用到了查询树来优化分析速度,其开源实现为Drill,在工业界对实时数据分析也是比价有影响力;
11. Pregel: a system for large-scale graph processing: Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi);
12. Spanner: Google's Globally-Distributed Database:这是第一个全球意义上的分布式数据库,Google的出品。其中介绍了很多一致性方面的设计考虑,简单起见,还采用了GPS和原子钟确保时间最大误差在20ns以内,保证了事务的时间序,同样在分布式系统方面具有很强的借鉴意义;
13. Dynamo: Amazon’s Highly Available Key-value Store:Amazon的分布式NoSQL数据库,意义相当于BigTable对于Google,于BigTable不同的是,Dynamo保证CAP中的AP,C通过vector clock做弱保证,对应的开源系统为Cassandra;
14. S4: Distributed Stream Computing Platform:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台;
15. Storm @Twitter:这个系统不多说,开启了流式计算的新纪元,几乎是所有公司流式计算的首选,绝对值得关注;
最近一两年时间主要精力放到了机器学习上,分布式系统的研究不太多了,现阶段就列这15篇文章吧,覆盖了分布式系统的主要领域。如果想起来有遗漏再来补充。Good luck!

----------------------------------------------分割线-------------------------------------------------------
评论里边 提到的两篇论文也挺不错的,一并补充在这里。
1. Large-scale cluster management at Google with Borg

2. F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business

作者:张帅
链接:https://www.zhihu.com/question/37647788/answer/72960959
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

再补充一些
1.raft
有会议论文,也有博士论文,解决多机一致性的协议,比paxos更贴近实现,更容易理解,已经有多个开源实现,这篇论文的亮点是,提出了一个不停服务的情况下,解决选举组成员变更的方案,值得细读。有意思的是,曾经有幸当面请教过Lamport大神(paxos作者)怎么看待raft,大神说他觉得raft就是paxos的一种实现。

2.multi-paxos
paxos算法需要通过prepare 和accept的四次网络通信才能形成一项决议,而且不限制proposer的数量,非常容易发生冲突,实际工程中,基本上没有按照paxos照搬实现的。简单讲,multi-poxos是一次prepare了一个区间的决议,获得批准后,后面只需要逐个发送accept请求即可,大大减少了网络通信。在实际实现中,通常还要选出一个leader,来消除prepare的冲突。这个论文好像是中国人写的。。。

3.percolator
Google设计的基于BIGTABLE单行事务构建的分布式事务层,对两阶段提交讲的比较清楚。

4.Megastore
Google在bigtable和spanner之间的过度系统,应该是最早的使用paxos保证多机一致性的,但在spanner论文中提到,megastore性能实在不行,现在据一个googol基础架构部门的工程师讲,spanner在谷歌内部要一统江湖了,200多人的团队。

5《Consensus on Transaction Commit》
Jim Gray & Leslie Lamport 两位大神合写的paxos提交算法,比较抽象,核心思想是单个协调者的两阶段提交算法是paxos提交中选举成员组为1的特例。spanner中把协调者状态通过paxos复制到多个副本隐隐有这篇论文的理论影子。对这篇论文的唯一印象就是经典的两阶段提交算法可以看做是Paxos提交算法的一个特例。


说点其他的心得体会吧:
对于大部分人来说,很多分布式的理论和论文只看资料是基本没有收获的, 所谓知行合一,学习需要和实践相结合
在学校期间,看过GFS/BIGTABLE至少三四遍,其实完全没有理解系统精要。
入职阿里oceanbase团队后,会要求再读google三篇论文,串讲并回答一系列问题,比如关于BigTable:

1. GFS可能出现重复记录或者padding,Bigtable如何处理这种情况使得对外提供强一致性模型?

2. 为什么Bigtable设计成Root、Meta、User三级结构,而不是两级或者四级结构?

3. 读取某一行用户数据,最多需要几次请求?分别是什么?

4. 如何保证同一个tablet不会被多台机器同时服务?

5. Tablet在内存中的数据结构如何设计?

6. 如何设计SSTable的存储格式?

7. minor、merging、major这三种compaction有什么区别?

8. Tablet Server的缓存如何实现?

9. 如果tablet出现故障,需要将服务迁移到其它机器,这个过程需要排序操作日志。如何实现?

10. 如何使得tablet迁移过程停服务时间尽量短?

11. tablet分裂的流程是怎样的?

12. tablet合并的流程是怎样的?


回答了这些问题,感觉才真正理解了分布式设计的难度。这之后以为自己理解的差不多了,可是最近再参与设计一个分布式存储项目,在做系统取舍,解决“为什么要这样做”这个层面的问题时,又重新去思考之前看过的系统和论文的方案。


相比于机器学习(完全小白的YY),分布式系统应该是一个理论和实践并重的方向,实践非常非常的重要,觉得自己很幸运,在OceanBase团队向一些大牛学习了两年,并且参与了OB从0.5架构到1.0架构的设计和实现整个过程,负责了数据库ReDo日志使用multi-paxos在多机同步模块设计和实现,在这个实践的过程中,收益良多。

初学者,希望帮到当初和我一样迷茫的小白,各位前辈看到说的不对的地方,欢迎批评指正,非常感谢~


posted @ 2017-12-28 21:15  Mr.zzz  阅读(62)  评论(0编辑  收藏  举报