读懂这100篇论文,你也能成为大数据专家|文章很长,但值得阅读

时间:2019-04-30 13:00:02 来源:新潮流时尚 当前位置:yabo狗亚体育老田鸡 > 亚博登录首页 > 手机阅读

导言

? ? 今天在网上闲逛,无意间发现了这一篇好文,原文作者是PayPal高级工程总监Anil Madan,文章对当前大数据领域用到的一些技术、框架等都做了一遍梳理。本文由CSDN翻译。通过阅读本文,可以对当前大数据领域有一个很好的认识,如果需要深入了解某项技术,可以阅读文章中所给的文章或论文的相关链接,都是不可多得的好资源。

?????? 本文中有标号的地方都可以跳到相应的文章,但微信对链接有限制,因此可以通过下面“阅读原文”转到本文的原文,然后点击里面的链接即可。


开源(Open Source)用之于大数据技术,其作用有二:一方面,在大数据技术变革之路上,开源在众人之力和众人之智推动下,摧枯拉朽,吐故纳新,扮演着非常重要的推动作用。另一方面,开源也给大数据技术构建了一个异常复杂的生态系统。每一天,都有一大堆“新”框架、“新”类库或“新”工具,犹如雨后春笋般涌出,乱花渐欲“迷”人眼。为了掌控住这些“新玩意”,数据分析的达人们不得不“殚精竭虑”地“学而时习之”。

无论你是一个大数据的布道者,还是一个日臻成熟的技术派,亦或你还在大数据这条路上“小河才露尖尖角”,多花点时间,深入理解一下大数据系统的技术体系演进,对你都会有莫大益处。全方位地理解大数据体系结构中的各个组件,并掌握它们之间的微妙差别,可在处理自己身边的大数据案例时,助你张弛有度,“恢恢乎,其于游刃必有余地矣!”

在过去的几年里,我阅读了很多不错的大数据文献,这些文献陪我成长,助我成功,使我成为一个具备良好教育背景的大数据专业人士。在这里,撰写此文的目的,不限于仅仅和大家分享这些很不错的文献,更重要的是,借此机会,想和大家一起,集众人之智慧,破解大数据开源系统之迷宫。

需要提醒的是,下文提及到的 100 篇参考文献(这些文献中大多都是一些开创性的研究论文),将会为你提供结构性的深度剖析,绝非泛泛而谈。我相信,这可从根本上帮助你深度理解大数据体系组件间的细微差别。但如果你打算“走马观花”般地快速过一遍,了解大数据为何物,对不起,这里可能会让你失望。

那么,准备好了吗?让我们走起!

在介绍这 100 篇文献之前,首先让我们看一下大数据处理的关键架构层(如图 1 所示):

01

关键架构层

图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)管理的工具。


操作框架层:这一层提供可扩展的性能监测管理和基准测试框架。


02

架构的演进

减少数据生产者和消费者之间的处理延迟,一直是现代计算构架不断演进的主要动力。由此,诞生了实时和低延迟处理的计算构架,如 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 绕了一大圈,又似回到它当初离开的地方。

03

文件系统层

由于文件系统层关注的焦点,开始向“低延时处理”方向转移,所以传统基于磁盘存储的文件系统,也开始向基于内存计算的文件系统转变 —— 这样做,会大大降低 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操作和存储开销)。

04

数据存储层

宽泛地讲,据对一致性(consistency)要求的强弱不同,分布式数据存储策略,可分为 ACID 和 BASE 两大阵营。ACID 是指数据库事务具有的四个特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。ACID 中的一致性要求比较强,事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。而 BASE 对一致性要求较弱,它的三个特征分别是:基本可用(Basically Available), 软状态/柔性事务(Soft-state,即状态可以有一段时间的不同步), 最终一致性(Eventual consistency)。BASE 还进一步细分基于键值的,基于文档的和基于列和图形的 – 细分的依据取决于底层架构和所支持的数据结构(注:BASE 完全不同于 ACID 模型,它以牺牲强一致性,获得基本可用性和柔性可靠性,并要求达到最终一致性)。

在数据存储层,还有很多类似的系统和某些系统的变种,这里,我仅仅列出较为出名的几个。如漏掉某些重要系统,还请谅解。

BASE

键值存储(Key Value Stores)

Dynamo【29】– 这是由亚马逊工程师们设计的基于键值的高可用的分布式存储系统(注:Dynamo 放弃了数据建模的能力,所有的数据对象采用最简单的 Key-value 模型存储,可简单地将 Dynamo 理解为一个巨大的 Map。Dynamo 是牺牲了部分一致性,来换取整个系统的高可用性)。

Cassandra【30】?– 这是由 Facebook 工程师设计的一个离散的分布式结构化存储系统,受亚马逊的 Dynamo 启发,Cassandra 采用的是面向多维的键值或面向列的数据存储格式(注:Cassandra 可用来管理分布在大量廉价服务器上的巨量结构化数据,并同时提供没有单点故障的高可用服务)。

Voldemort【31】?–这又是一个受亚马逊的 Dynamo 启发的分布式存储作品,由全球最大的职业社交网站 LinkedIn 的工程师们开发而成(注:Voldemort,这个在《哈利·波特》中常被译作“伏地魔”的开源数据库,支撑起了 LinkedIn 的多种数据分析平台)。

面向列的存储(Column Oriented Stores)

BigTable【32】?–这是一篇非常经典的学术论文,阐述了面向列的分布式的数据存储方案,由谷歌荣誉出品。(注:Bigtable 是一个基于 Google 文件系统的分布式数据存储系统,是为谷歌打拼天下的“三驾马车”之一,另外两驾马车分别是分布式锁服务系统 Chubby 和下文将提到的 MapReduce)。

HBase【33】?–目前还没有有关 Hbase 的定义性论文,这里的文献提供了一个有关 HBase 技术的概述性文档(注:Hbase 是一个分布式的、面向列的开源数据库。其设计理念源自谷歌的 BigTable,用 Java 语言编写而成。文献【33】是一个有关 Hbase 的幻灯片文档)。

Hypertable【34】-文献是一个有关“Hypertable”的技术白皮书,对该数据存储结构做了较为详细的介绍(注:Hypertable 也是一个开源、高性能、可伸缩的数据库,它采用与 Google 的 Bigtable 类似的模型)。

面向文档的存储(Document Oriented Stores)

CouchDB【35】– 这是一款面向文档的、开源数据存储管理系统(注:文献【35】是一本 Apache CouchDB 的 400 多页的官方文档)。

MongoDB【36】?–是目前非常流行的一种非关系型(NoSQL)数据库(注:文献【36】是一个有关 MongoDB 的白皮书,对 MongoDB 结构做了很不错的介绍)。

面向图(Graph)的存储

Neo4j【37】?–文献是 Ian Robinson 等撰写的图书《Graph Databases(图数据库)》(注:Neo4j 是一款目前最为流行的高性能 NoSQL 图数据库,它使用图来描述数据模型,把数据保存为图中的节点以及节点之间的关系。这是最流行的图数据库)。

Titan【38】?–文献是有关 Titan 的在线文档(Titan 是一款 Apache 许可证框架下的分布式的开源图数据库,特别为存储和处理大规模图而做了大量优化)。

ACID

我注意到,现在很多开源社区正在悄悄发生变化,它们开始“亦步亦趋”地跟随谷歌的脚步。这也难怪,谷歌太牛,跟牛人混,近牛者牛 —— 下面 4 篇文献,有 3 篇来自于谷歌的“神来之笔”,他们解决了全球分布一致的数据存储问题。

Megastore【39】?–这是一个构建于 BigTable 之上的、高可用的分布式存储系统,文献为有关 Megastore 的技术白皮书(注:Megastore 在被谷歌使用了数年之后,相关技术信息才在 2001 年公布。CSDN 网站亦有文献【39】的中文解读:Google Megastore 分布式存储技术全揭秘)。

Spanner【40】–这是由谷歌研发的、可扩展的、全球分布式的、同步复制数据库,支持 SQL 查询访问。(注:Spanner 的“老爹”是 Big Table,可以说,没有“大表”这个爹,就不可能有这个强有力的“扳手” 儿子。它是第一个把数据分布在全球范围内的系统,并且支持外部一致性的分布式事务)。

MESA【41】–亦是由谷歌研发的、跨地域复制(geo-replicated)、高可用的、可容错的、可扩展的近实时数据仓库系统(注:在 2014 年的 VLDB 大会上,谷歌公布了他们的分析型数据仓库系统 MESA,该系统主要用于存储 Google 互联网广告业务相关的关键衡量数据。文献【41】是 VLDB 的会议论文)。

CockroachDB【42】–该系统是由 Google 前工程师 Spencer Kimball 领导开发的 Spanner 的开源版本(注:这个项目的绰号是“螳螂(Cockroach)”,其寓意是“活得长久”,因为蟑螂是地球上生命力最强的生物之一,即使被砍下头颅,依然还能存活好几天!文献【42】是代码托管网站 GitHub 上对 Cockroach 的说明性文档)。

05

资源管理器层(Resource Managers)

第一代 Hadoop 的生态系统,其资源管理是以整体单一的调度器起家的,其代表作品为 YARN。而当前的调度器则是朝着分层调度的方向演进(Mesos 则是这个方向的代表作),这种分层的调度方式,可以管理不同类型的计算工作负载,从而可获取更高的资源利用率和调度效率。

YARN【43】– 这是新一代的 MapReduce 计算框架,简称 MRv2,它是在第一代 MapReduce 的基础上演变而来的(注:MRv2 的设计初衷是,为了解决第一代 Hadoop 系统扩展性差、不支持多计算框架等问题。对国内用户而言,原文献下载链接可能会产生 404 错误,这里提供一个新文献:由 2011 年剥离自雅虎的 Hadoop 初创公司 Hortonworks 给出的官方文献【43】new,阅读该文献也可对 YARN 有较为深入的理解。CSDN 亦有对 YARN 详细解读的文章:更快、更强——解析 Hadoop 新一代 MapReduce 框架 Yarn)。

Mesos【44】–这是一个开源的计算框架,可对多集群中的资源做弹性管理(注:Mesos 诞生于 UC Berkeley 的一个研究项目,现为 Apache 旗下的一个开源项目,它是一个全局资源调度器。目前 Twitter、 Apple 等国外大公司正在使用 Mesos 管理集群资源,国内用户有豆瓣等。文献【44】是加州大学伯克利分校的研究人员发表于着名会议 NSDI 上的学术论文)。

这些计算框架和调度器之间是松散耦合的,调度器的主要功能就是基于一定的调度策略和调度配置,完成作业调度,以达到工作负载均衡,使有限的资源有较高的利用率。

调度器(Schedulers)

作业调度器,通常以插件的方式加载于计算框架之上,常见的作业调度器有 4 种:

计算能力调度器【45】(Capacity Scheduler)-该文献是一个关于计算能力调度器的指南式文档,介绍了计算能力调度器的不同特性。

公平调度器【46】(FairShare Scheduler)?-该文献是 Hadoop 的公平调度器设计文档,介绍了公平调度的各项特征(注:公平调度是一种赋予作业资源的方法,它提供了一个基于任务数的负载均衡机制,其目的是让所有的作业随着时间的推移,都能平均的获取等同的共享资源)。

延迟调度【47】(Delayed Scheduling)?–该文献是加州大学伯克利分校的一份技术报告,报告介绍了公平调度器的延迟调度策略。

公平与能力调度器【48】(Fair & Capacity schedulers?)–该文献是一篇关于云环境下的 Ha

相关文章:

音效本月排行

音效精选