PayPal高级工程总监：读完这100篇论文 就能成大数据高手
开源(Open Source)用之于大数据技术，其作用有二：一方面，在大数据技术变革之路上，开源在众人之力和众人之智推动下，摧枯拉朽，吐故纳新，扮演着非常重要的推动作用。另一方面，开源也给大数据技术构建了一个异常复杂的生态系统。每一天，都有一大堆“新”框架、“新”类库或“新”工具，犹如雨后春笋般涌出，乱花渐欲“迷”人眼。为了掌控住这些“新玩意”，数据分析的达人们不得不“殚精竭虑”地“学而时习之”。
无论你是一个大数据的布道者，还是一个日臻成熟的技术派，亦或你还在大数据这条路上“小河才露尖尖角”，多花点时间，深入理解一下大数据系统的技术体系演进，对你都会有莫大益处。全方位地理解大数据体系结构中的各个组件，并掌握它们之间的微妙差别，可在处理自己身边的大数据案例时，助你张弛有度，“恢恢乎，其于游刃必有余地矣!”
在过去的几年里，我阅读了很多不错的大数据文献，这些文献陪我成长，助我成功，使我成为一个具备良好教育背景的大数据专业人士。在这里，撰写此文的目的，不限于仅仅和大家分享这些很不错的文献，更重要的是，借此机会，想和大家一起，集众人之智慧，破解大数据开源系统之迷宫。
需要提醒的是，下文提及到的100篇参考文献(这些文献中大多都是一些开创性的研究论文)，将会为你提供结构性的深度剖析，绝非泛泛而谈。我相信，这可从根本上帮助你深度理解大数据体系组件间的细微差别。但如果你打算“走马观花”般地快速过一遍，了解大数据为何物，对不起，这里可能会让你失望。
那么，准备好了吗?让我们走起!
在介绍这100篇文献之前，首先让我们看一下大数据处理的关键架构层(如图1所示)：
关键架构层
图1：大数据处理的关键架构层
文件系统层：在这一层里，分布式文件系统需具备存储管理、容错处理、高可扩展性、高可靠性和高可用性等特性。
数据存储层：由于目前采集到的数据，十之有七八为非结构化和半结构化数据，数据的表现形式各异，有文本的、图像的、音频的、视频的等，因此常见的数据存储也要对应有多种形式，有基于键值(Key-Value)的，有基于文档(Document)，还有基于列(Column)和图表(Graph)的。如果采用单一的数据库引擎，“一刀切式”的满足所有类型的数据存储需求，通常会严重降低数据库管理的性能。因此，我们需要“兵来将挡，水来土掩”式的、多元的(Polyglot)【1】数据库解决方案(这就好比，如果“兵来了”和“水来了”，都要“将”去挡，遇到“兵”时，“将”可以“酣畅淋漓”，而遇到“水”时，还用“将”去挡，那这个“将”估计就要“舍生取义”了。文献【1】是一本有关NoSQL数据处理的图书)
资源管理层：这一层是为了提高资源的高利用率和吞吐量，以到达高效的资源管理与调度目的。
资源协调层： 在本层的系统，需要完成对资源的状态、分布式协调、一致性和资源锁实施管理。
计算框架层：在本层的计算框架非常庞杂，有很多高度专用的框架包含其内，有流式的，交互式的，实时的，批处理和迭代图的(Batch and Iterative Graph，BSP)等。为这些计算框架提供支撑的是运行时引擎，如BDAS【2】(Spark) 和 Flink等(注：这里的BDAS是指“Berkeley Data Analytics Stack”，即伯克利数据分析栈。文献【2】为Spark核心作者Ion Stoica的讲座幻灯片文档)。
数据分析层：在这一层里，主要包括数据分析(消费)工具和一些数据处理函数库。这些工具和函数库，可提供描述性的、预测性的或统计性的数据分析功能及机器学习模块。
数据集成层：在这一层里，不仅包括管理数据分析工作流中用到的各种适用工具，除此之外，还包括对元数据(Metadata)管理的工具。
操作框架层：这一层提供可扩展的性能监测管理和基准测试框架。
架构的演进
减少数据生产者和消费者之间的处理延迟，一直是现代计算构架不断演进的主要动力。由此，诞生了实时和低延迟处理的计算构架，如Lambda和Kappa等，这类混合架构取长补短，架起传统的批处理层和交互式层之间连接的桥梁。
Lambda【3】 -该架构是经典的大数据处理范式，是由南森马兹(Nathan Marz)提出的一个实时大数据处理框架。更多有关Lamda的信息，请读者访问Lambda官方网站。(注：文献【3】是由James Kinley在轻博客网站Tumblr发表的一篇博文：Lambda 架构：构架实时大数据系统的原则)。
Kappa【4】-该计算构架可视为Lambda的一个强有力替代者，Kappa将数据处理的上游移至流式层(注：文献【4】是一篇博客文章，作者是Jay Kreps是Linkedln的一名在线数据架构技术高管。Kreps认为，虽然Lambda构架的理念很有价值，但终究还是一个临时解决方案。他设计了一个替代架构Kappa，是基于他在Linkedin构建Kafka和Samza的经验设计而成)。
SummingBird【5】-这是一个参考模型，用来桥接在线处理模式和传统处理模式。Summingbird是由Twitter(推特)公司用Scala语言开发的、并开源的大规模数据处理框架，支持开发者以批处理模式(基于Hadoop)或流处理模式(基于Storm)，或混合模式(即前两种模式的组合)以统一的方式执行代码。(注：文献【5】是Summingbird的主要设计者Oscar Boykin、Sam Ritchie等人于2014年发表于知名期刊PVLDB中论文，其中论文的二作Sam Ritchie大有来头，他是计算机科学界的传奇人物、C语言和Unix的设计者Dennis Ritchie的侄子)。
在你尚未深入了解下面的各个具体的框架层次之前，建议你认真阅读一下下面的几篇非常有价值的文献，它们帮为你“恶补”一下诸如NoSQL(非结构化)数据存储、数据仓库大规模计算及分布式系统等相关领域的背景知识：
计算中心即计算机【6】(Data center as a computer)-文献【6】是威斯康星大学-麦迪逊分校Mark D. Hill教授主编的一个论文集式的图书，在这本图书中，收集了很多有关数据仓库大规模计算的论文(注：将数据中心视为一台计算机，与传统的高性能计算机有很大不同。计算中心的实例将以虚拟机或者容器的形式存在，计算资源的配置对于用户而言是透明的，这样就大幅降低系统部署的复杂度、并提高资源使用的灵活性)。
非结构化(NOSQL)数据存储【7】- 文献是由Rick Cattell撰写的论文，论文讨论了可扩展的结构化数据的、非结构化的(包括基于键值对的、基于文档的和面向列的)数据存储方案(注：NOSQL是支撑大数据应用的关键所在。事实上，将NOSQL翻译为“非结构化”不甚准确，因为NOSQL更为常见的解释是：Not Only SQL(不仅仅是结构化)，换句话说，NOSQL并不是站在结构化SQL的对立面，而是既可包括结构化数据，也可包括非结构化数据)。
NoSQL学位论文【8】-该文献是德国斯图加特传媒大学Christof Strauch撰写的学位论文，该论文对分布式系统和第一代非结构化系统提供了非常系统的背景知识介绍。
大规模数据管理【9】-文献是加拿大阿尔伯塔大学的研究人员撰写的一篇综述，讨论了大数据应用程序的大规模数据管理系统，传统的数据库供应商与新兴的互联网企业，它们对大数据管理需求是不同的。文章的讨论范围涵盖很广，数据模型、系统结构及一致性模型，皆有涉及。
最终一致性(Eventual Consistency)【10】：论文讨论了分布式系统中的各种不同的一致性模型。(注：原文给出的链接可能有误，因为根据所提供的链接下载而来的论文是关于“MapReduce中日志处理的Join算法”的综述文章，与“最终一致性”的讨论议题无关。这里推荐2篇新的相关论文：(1)综述文章：数据库最终一致性：最新的进展【10】new1;(2)微软研究人员2013年发表于SIGMOD的文章：“最终一致性的反思(Rethinking Eventual Consistency)【10】new2”。)
CAP理论【11】-文献以“CAP 理论十二年回顾："规则"已经变了”为题，探讨了CAP理论及其演化，是篇非常不错的介绍CAP理论的基础性论文(注：论文作者Eric Brewer是加州大学伯克利分校的知名计算机科学学者。该文首发于《Computer》杂志，随后又被InfoQ和IEEE再次发表。CAP理论断言，任何基于网络的数据共享系统，最多只能满足数据一致性(Consistency，C)、可用性(Availability ，A)、分区(Partition，P)容忍性这三要素中的两个要素。但通过显式处理分区，系统设计师可做到优化数据的一致性和可用性，进而取得三者之间的妥协与平衡)。
在过去，在大规模数据处理上，传统的并行数据库管理系统(DBMS)和基于Map Reduce(映射-规约，以下简称MR)的批处理范式之间，曾发生激烈辩论，各持己见。并行数据库管理系统的支持者【12】(注：由耶鲁大学、微软和麻省理工学院的研究人员于2009年发表在SIGMOD的一篇文章)和另外一篇文献【13】(注：2010年发表于《美国计算机学会通讯》上的论文：“MapReduce和并行数据库管理系统，是朋友还是敌人?”)，被MR的拥趸者【14】(注：发表于美国计算机学会通讯的论文：MapReduce:一个弹性的数据处理工具)狠狠地给批驳了一番。
然而，令人讽刺的是，从那时起，Hadoop社区开始引入无共享的(Shared-Nothing)的MPP(大规模并行处理)风格的大数据处理模式，文献“Hadoop上的SQL【15】”，便是例证。要知道，MPP是并行数据库管理系统(DBMS)的灵魂，这样，Map Reduce绕了一大圈，又似回到它当初离开的地方。
文件系统层
由于文件系统层关注的焦点，开始向“低延时处理”方向转移，所以传统基于磁盘存储的文件系统，也开始向基于内存计算的文件系统转变 —— 这样做，会大大降低I / O操作和磁盘序列化带来的访问开销。Tachyon 和 Spark RDD【16】就是朝这个方向演化的范例(注：这里RDD指的是弹性分布式数据集(Resilient Distributed Datasets)，它是一种高度受限的共享内存模型，文献【16】由伯克利大学加州分校的Matei Zaharia等撰写的，他们提出了一种面向内存集群运算的容错抽象模型)。
Google文件系统(GFS)【17】-该文献是分布式文件系统的奠基之作，著名的Hadoop 分布式文件系统(HDFS)，亦脱胎于GFS，基本上可视为GFS的一个简化实现版(注：文献【17】提出了一个可扩展的分布式文件系统GFS，可用于大型分布式数据密集型应用。文献认为，组件故障是常态而不是异常。其所提出的GFS，着眼在几个重要的目标，比如性能、可伸缩性、可靠性和可用性。GFS的新颖之处，并不在于它采用了多么令人惊艳的技术，而在于它能利用所提出的方案，采用廉价的商用机器，来构建高效的分布式文件系统。有用的创新，才是真的创新，GFS做到了!)。
Hadoop 文件系统【18】-该文献由雅虎公司的计算机科学家Konstantin Shvachko等人联合撰写的，论文给出了HDFS的进化历史背景及其架构的设计内涵，是了解Hadoop技术的经典之作。
Ceph文件系统【19】-Ceph是HDFS有力的替代者【20】(注：Ceph 文件系统是加州大学圣克鲁兹分校(USSC)博士生Sage Weil博士期间的一项有关存储系统的研究项目。初出茅庐，略有小成。之后，在开源社区的推动下，Ceph逐渐羽翼渐丰，风云叱咤，功成名就，逐渐发展成为一个 Linux系统下 PB 级分布式文件系统。文献【19】是Weil本人在2006年顶级会议OSDI发表的有关Ceph的开山论文。文献【20】则是Weil率领他的一帮小伙伴们再次发文强调，Ceph是HDFS强有力的替代者)。
Tachyon【21】–是一个高容错的分布式内存文件系统，其设计的核心内涵是，要满足当下“低延迟”的数据处理要求(注：Tachyon 是在内存中处理缓存文件，允许文件以访问内存的速度在集群框架中进行可靠的共享，类似于Spark。Tachyon的吞吐量比HDFS高出100倍。 Spark框架虽然也提供了强大的内存计算能力，但其没有提供内存文件的存储管理能力，而Tachyon则弥补了Spark的不足之处。文献【21】是伯克利大学加州分校和麻省理工学院的研究者联合撰写的，发表在2014年的 SoCC国际会议上，论文一作UC Berkeley AMP实验室博士生李浩源，他亦是Spark核心开发人员之一)。
文件系统的演化历程，其实也见证了文件格式和压缩技术的发展历程。下面的参考文献，可以让你了解到，“面向行”或“面向列”存储格式各自的优缺点，并且还可让你了然文件存储技术发展的新趋势——嵌套式的面向列的存储格式，这种存储格式可极大提高大数据的处理效率。
当前，在文件系统阶段，数据管理的最大挑战之一就是，如何处理大数据中的数据冗余。纠删码(Erasure code)是很有创意的冗余保护机制，它可以减少三倍的冗余副本，还不会影响数据的可恢复性与可用性。
面向列存储 vs. 面向列存储【22】—该文献是是2008年发表于SIGMOD的一篇论文，该文对数据的布局、压缩及物化(materialization)策略都做了很不错的综述。
RCFile【23】-这是由Facebook 数据基础设施小组和俄亥俄州立大学的华人学者共同提出的文件存储格式，他们走了一个“中庸之道”，充分吸取面向列和面向行存储模式的优点，扬长避短，提出了一种混合的数据存储结构PAX(注：目前这种以行/列混合存储技术已成功应用于 Facebook 等国内外大型互联网企业的生产性运行体系)。
Parquet【24】- 这是一种面向行的存储格式，其设计理念源于谷歌 Dremel论文(注：Parquet主要用于 Hadoop 的生态系统中。文献【24】是Julien Dem在Github发表的一篇博客文章)。
ORCFile【25】–这是一种被Hive(一种基于Hadoop的数据仓库工具)采用的、面向列存储的改进版存储格式(注：文献【25】是2014年发表于顶会SIGMOD的一篇学术论文)。
压缩技术【26】-这是是一篇阐述在Hadoop生态系统下的常见压缩算法的综述性文章，文章对常见的压缩算法和其适用场景以及它们的优缺点，做了非常不错的归纳总结。
纠删码技术(Erasure code)【27】-这是一篇是田纳西大学EECS系教授James Plank撰写的、有关存储系统纠删码技术的入门级的文献。有关纠删码改进技术的阐述，读者可参阅来自南加州大学和Facebook的7名作者共同完成的论文《XORing Elephants: 面向大数据的新型纠删码技术【28】》(注：文献【28】的作者开发了纠删码家族的新成员——基于XOR的本地副本存储LRC，该技术是面向Hadoop生态系统的，可显著减少修复数据时的I/O操作和存储开销)。
|
