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是由推ter（推特）公司用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】 -這是由 非死book 數據基礎設施小組和俄亥俄州立大學的華人學者共同提出的文件存儲格式，他們走了一個“中庸之道”，充分吸取面向列和面向行存儲模式的優點，揚長避短，提出了一種混合的數據存儲結構PAX（注：目前這種以行/列混合存儲技術已成功應用于 非死book 等國內外大型互聯網企業的生產性運行體系）。
• Parquet ^【24】 - 這是一種面向行的存儲格式，其設計理念源于谷歌 Dremel論文（注：Parquet主要用于 Hadoop 的生態系統中。文獻【24】是Julien Dem在Github發表的一篇博客文章）。
• ORCFile ^【25】 –這是一種被 Hive（一種基于Hadoop的數據倉庫工具）采用的、面向列存儲的改進版存儲格式（注：文獻【25】是2014年發表于頂會SIGMOD的一篇學術論文）。
• 壓縮技術 ^【26】 -這是是一篇闡述在 Hadoop生態系統下的常見壓縮算法的綜述性文章，文章對常見的壓縮算法和其適用場景以及它們的優缺點，做了非常不錯的歸納總結。
• 糾刪碼技術（Erasure code） ^【27】 -這是一篇是田納西大學 EECS系教授James Plank撰寫的、有關存儲系統糾刪碼技術的入門級的文獻。有關糾刪碼改進技術的闡述，讀者可參閱來自南加州大學和非死book的7名作者共同完成的論文《 XORing Elephants: 面向大數據的新型糾刪碼技術 ^【28】 》（注：文獻【 28】的作者開發了糾刪碼家族的新成員——基于XOR的本地副本存儲LRC，該技術是面向Hadoop生態系統的，可顯著減少修復數據時的I/O操作和存儲開銷）。