Big Data technology has been extremely disruptive with open source playing a dominant role in shaping its evolution. While on one hand it has been disruptive, on the other it has led to a complex ecosystem where new frameworks, libraries and tools are being released pretty much every day, creating confusion as technologists struggle and grapple with the deluge.

開源（Open Source）用之於大資料技術，其作用有二：一方面，在大資料技術變革之路上，開源在眾人之力和眾人之智推動下，摧枯拉朽，吐故納新，扮演著非常重要的推動作用。另一方面，開源也給大資料技術構建了一個異常複雜的生態系統。每一天，都有一大堆“新”框架、“新”類庫或“新”工具，猶如雨後春筍般湧出，亂花漸欲“迷”人眼。為了掌控住這些“新玩意”，資料分析的達人們不得不“殫精竭慮”地“學而時習之”。

If you are a Big Data enthusiast or a technologist ramping up (or scratching your head), it is important to spend some serious time deeply understanding the architecture of key systems to appreciate its evolution. Understanding the architectural components and subtleties would also help you choose and apply the appropriate technology for your use case. In my journey over the last few years, some literature has helped me become a better educated data professional. My goal here is to not only share the literature but consequently also use the opportunity to put some sanity into the labyrinth of open source systems.  

無論你是一個大資料的佈道者，還是一個日臻成熟的技術派，亦或你還在大資料這條路上“小荷才露尖尖角”，多花點時間，深入理解一下大資料系統的技術體系演進，對你都會有莫大益處。全方位地理解大資料體系結構中的各個元件，並掌握它們之間的微妙差別，可在處理自己身邊的大資料案例時，助你張弛有度，“恢恢乎，其於遊刃必有餘地矣!”。在過去的幾年裡，我閱讀了很多不錯的大資料文獻，這些文獻陪我成長，助我成功，使我成為一個具備良好教育背景的大資料專業人士。在這裡，撰寫此文的目的，不限於僅僅和大家分享這些很不錯的文獻，更重要的是，藉此機會，想和大家一起，集眾人之智慧，破解大資料開源系統之迷宮。

One caution, most of the reference literature included is hugely skewed towards deep architecture overview (in most cases original research papers) than simply provide you with basic overview. I firmly believe that deep dive will fundamentally help you understand the nuances, though would not provide you with any shortcuts, if you want to get a quick basic overview.

Jumping right in…

關鍵架構層（Key architecture layers）

• File Systems- Distributed file systems which provide storage, fault tolerance, scalability, reliability, and availability.
• Data Stores– Evolution of application databases into Polyglot storage with application specific databases instead of one size fits all. Common ones are Key-Value, Document, Column and Graph.
• Resource Managers– provide resource management capabilities and support schedulers for high utilization and throughput.
• Coordination– systems that manage state, distributed coordination, consensus and lock management.
• Computational Frameworks– a lot of work is happening at this layer with highly specialized compute frameworks for Streaming, Interactive, Real Time, Batch and Iterative Graph (BSP) processing. Powering these are complete computation runtimes like BDAS (Spark) & Flink.
• DataAnalytics –Analytical (consumption) tools and libraries, which support exploratory, descriptive, predictive, statistical analysis and machine learning.
• Data Integration– these include not only the orchestration tools for managing pipelines but also metadata management.
• Operational Frameworks – these provide scalable frameworks for monitoring & benchmarking.

需要提醒的是，下文提及到的100篇參考文獻（這些文獻中大多都是一些開創性的研究論文），將會為你提供結構性的深度剖析，絕非泛泛而談。我相信，這可從根本上幫助你深度理解大資料體系元件間的細微差別。但如果你打算“走馬觀花”般地快速過一遍，瞭解大資料為何物，對不起，這裡可能會讓你失望。那麼，準備好了嗎？讓我們走起！

在介紹這100篇文獻之前，首先讓我們看一下大資料處理的關鍵架構層（如圖所示）：

圖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）管理的工具。
• 操作框架層：這一層提供可擴充套件的效能監測管理和基準測試框架。

架構的演進（Architecture Evolution）

The modern data architecture is evolving with a goal of reduced latency between data producers and consumers. This consequently is leading to real time and low latency processing, bridging the traditional batch and interactive layers into hybrid architectures like Lambda and Kappa.

• Lambda - Established architecture for a typical data pipeline. More details.
• Kappa– An alternative architecture which moves the processing upstream to the Stream layer.
• SummingBird– a reference model on bridging the online and traditional processing models. 

Before you deep dive into the actual layers, here are some general documents which can provide you a great background on NoSQL, Data Warehouse Scale Computing and Distributed Systems.

• Data center as a computer– provides a great background on warehouse scale computing.
• NOSQL Data Stores– background on a diverse set of key-value, document and column oriented stores.
• NoSQL Thesis– great background on distributed systems, first generation NoSQL systems.
• Large Scale Data Management- covers the data model, the system architecture and the consistency model, ranging from traditional database vendors to new emerging internet-based enterprises. 
• Eventual Consistency– background on the different consistency models for distributed systems.
• CAP Theorem– a nice background on CAP and its evolution.

There also has been in the past a fierce debate between traditional Parallel DBMS with Map Reduce paradigm of processing. Pro parallel DBMS (another) paper(s) was rebutted by the pro MapReduce one. Ironically the  Hadoop community from then has come full circle with the introduction of MPI style shared nothing based processing on Hadoop - SQL on Hadoop. 

架構的演進

減少資料生產者和消費者之間的處理延遲，一直是現代計算構架不斷演進的主要動力。由此，誕生了實時和低延遲處理的計算構架，如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繞了一大圈，又似回到它當初離開的地方。

檔案系統層（FIle Systems） 

As the focus shifts to low latency processing, there is a shift from traditional disk based storage file systems to an  emergence of in memory file systems - which drastically reduces the I/O & disk serialization cost. Tachyon and Spark RDD are examples of that evolution.

• Google File System- The seminal work on Distributed File Systems which shaped the Hadoop File System.
• Hadoop File System– Historical context/architecture on evolution of HDFS.
• Tachyon– An in memory storage system to handle the modern day low latency data processing.

File Systems have also seen an evolution on the file formats and compression techniques. The following references gives you a great background on the merits of row and column formats and the shift towards newer nested column oriented formats which are highly efficient for Big Data processing. Erasure codes are using some innovative techniques to reduce the triplication (3 replicas) schemes without compromising data recoverability and availability.  

• Column Oriented vs Row-Stores– good overview of data layout, compression and materialization.
• RCFile– Hybrid PAX structure which takes the best of both the column and row oriented stores.
• Parquet– column oriented format first covered in Google’s Dremel’s paper.
• ORCFile– an improved column oriented format used by Hive.
• Compression– compression techniques and their comparison on the Hadoop ecosystem.
• Erasure Codes– background on erasure codes and techniques; improvement on the default triplication on Hadoop to reduce storage cost.

檔案系統層

由於檔案系統層關注的焦點，開始向“低延時處理”方向轉移，所以傳統基於磁碟儲存的檔案系統，也開始向基於記憶體計算的檔案系統轉變 —— 這樣做，會大大降低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操作和儲存開銷）。

資料儲存（Data Stores）

Broadly, the distributed data stores are classified on ACID & BASE stores depending on the continuum of strong to weak consistency respectively. BASE further is classified into KeyValue, Document, Column and Graph - depending on the underlying schema & supported data structure. While there are multitude of systems and offerings in this space, I have covered few of the more prominent ones. I apologize if I have missed a significant one...

寬泛地講，據對一致性（consistency）要求的強弱不同，分散式資料儲存策略，可分為ACID和BASE兩大陣營。ACID是指資料庫事務具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、永續性（Durability）。ACID中的一致性要求比較強，事務執行的結果必須是使資料庫從一個一致性狀態變到另一個一致性狀態。而BASE對一致性要求較弱，它的三個特徵分別是：基本可用（Basically Available）, 軟狀態/柔性事務（Soft-state，即狀態可以有一段時間的不同步）, 最終一致性（Eventual consistency）。BASE還進一步細分基於鍵值的，基於文件的和基於列和圖形的 – 細分的依據取決於底層架構和所支援的資料結構（注：BASE完全不同於ACID模型，它以犧牲強一致性，獲得基本可用性和柔性可靠性，並要求達到最終一致性）。

在資料儲存層，還有很多類似的系統和某些系統的變種，這裡，我僅僅列出較為出名的幾個。如漏掉某些重要系統，還請諒解。

BASE

鍵值儲存（Key Value Stores）

Dynamo – key-value distributed storage system
Cassandra – Inspired by Dynamo; a multi-dimensional key-value/column oriented data store.
Voldemort – another one inspired by Dynamo, developed at LinkedIn.

鍵值儲存（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 – seminal paper from Google on distributed column oriented data stores.
HBase – while there is no definitive paper , this provides a good overview of the technology.
Hypertable – provides a good overview of the architecture.

面向列的儲存（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 – a popular document oriented data store.
MongoDB – a good introduction to MongoDB architecture.

面向文件的儲存（Document Oriented Stores）

CouchDB^【35】– 這是一款面向文件的、開源資料儲存管理系統（注：文獻【35】是一本Apache CouchDB的400多頁的官方文件）。

MongoDB^【36】 –是目前非常流行的一種非關係型(NoSQL)資料庫（注：文獻【36】是一個有關MongoDB的白皮書，對MongoDB結構做了很不錯的介紹）。

Graph

Neo4j – most popular Graph database.
Titan – open source Graph database under the Apache license.

面向圖（Graph）的儲存

Neo4j^【37】 –文獻是Ian Robinson等撰寫的圖書《Graph Databases（圖資料庫）》（注：Neo4j是一款目前最為流行的高效能NoSQL 圖資料庫，它使用圖來描述資料模型，把資料儲存為圖中的節點以及節點之間的關係。這是最流行的圖資料庫）。

Titan^【38】 –文獻是有關Titan的線上文件（Titan是一款Apache許可證框架下的分散式的開源圖資料庫，特別為儲存和處理大規模圖而做了大量優化）。

ACID

I see a lot of evolution happening in the open source community which will try and catch up with what Google has done – 3 out of the prominent papers below are from Google , they have solved the globally distributed consistent data store problem.

Megastore – a highly available distributed consistent database. Uses Bigtable as its storage subsystem.
Spanner – Globally distributed synchronously replicated linearizable database which supports SQL access.
MESA – provides consistency, high availability, reliability, fault tolerance and scalability for large data and query volumes.
CockroachDB – An open source version of Spanner (led by former engineers) in active development.

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的說明性文件）。

資源管理層（Resource Managers）

While the first generation of Hadoop ecosystem started with monolithic schedulers like YARN, the evolution now is towards hierarchical schedulers (Mesos), that can manage distinct workloads, across different kind of compute workloads, to achieve higher utilization and efficiency.

YARN – The next generation Hadoop compute framework.
Mesos – scheduling between multiple diverse cluster computing frameworks.

These are loosely coupled with schedulers whose primary function is schedule jobs based on scheduling policies/configuration.

資源管理器層（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

Capacity Scheduler - introduction to different features of capacity scheduler. 
FairShare Scheduler - introduction to different features of fair scheduler.
Delayed Scheduling - introduction to Delayed Scheduling for FairShare scheduler.
Fair & Capacity schedulers – a survey of Hadoop schedulers.

排程器（Schedulers）

作業排程器，通常以外掛的方式加載於計算框架之上，常見的作業排程器有4種：

計算能力排程器^【45】（Capacity Scheduler）-該文獻是一個關於計算能力排程器的指南式文件，介紹了計算能力排程器的不同特性。

公平排程器^【46】（FairShare Scheduler） -該文獻是Hadoop的公平排程器設計文件，介紹了公平排程的各項特徵（注：公平排程是一種賦予作業資源的方法，它提供了一個基於任務數的負載均衡機制，其目的是讓所有的作業隨著時間的推移，都能平均的獲取等同的共享資源）。

延遲排程^【47】（Delayed Scheduling） –該文獻是加州大學伯克利分校的一份技術報告，報告介紹了公平排程器的延遲排程策略。

公平與能力排程器^【48】（Fair & Capacity schedulers ）–該文獻是一篇關於雲環境下的Hadoop排程器的綜述性論文。

資源協調層（Coordination）

These are systems that are used for coordination and state management across distributed data systems.
Paxos – a simple version of the classical paper; used for distributed systems consensus and coordination. 
Chubby – Google’s distributed locking service that implements Paxos.
Zookeeper – open source version inspired from Chubby though is general coordination service than simply a locking service 

協調器（Coordination）

在分散式資料系統中，協調器主要用於協調服務和進行狀態管理。

注：兩篇文獻的作者均是萊斯利·蘭伯特（Leslie Lamport），此君是個傳奇人物，科技論文寫作常用編輯器LaTex，其中“La”就是來自其姓“Lamport”的前兩個字母。Lamport目前是微軟研究院首席研究員，2013年，因其在分散式計算理論領域做出的傑出貢獻，榮獲計算機領域最高獎——圖靈獎。

牛人的故事特別多，Lamport亦是這樣。就這兩篇文獻而言，Lamport的奇聞軼事都值得說道說道。光看其經典論文題目“The Part-Time Parliament（兼職的議會）^【50】”，或許就讓讀者“一頭霧水”，這是一篇電腦科學領域的論文嗎？和讀者一樣感覺的可能還有期刊編輯。其實，早在1990年時，Lamport就提出Paxos演算法，他虛構了一個希臘城邦Paxos及其議會，以此來形象比喻說明該演算法的流程。論文投出後，期刊編輯建議Lamport，將論文用更加嚴謹的數學語言重新進行描述一下。可Lamport則認為，我的幽默，你不懂！拒絕修改。時隔八年之後的 1998年，Paxos演算法才被伯樂期刊《ACM Transactions on Computer Systems》發表。由於Paxos演算法本身過於複雜，且同行不理解自己的“幽默”， 於是，2001年Lamport就用簡易語言撰寫這篇文章，重新發表了該論文的簡化版^【49】，即“Paxos made simple（Paxos變得簡單）”。簡化版的摘要更簡單，就一句話：“Paxos演算法，用簡易英語說明之，很簡單”，如果去掉中間的那個無故緊要的定語從句，就是“Paxos演算法，很簡單”。弄得你都來不及做深思狀，摘要就完了。這…，這…，完全顛覆了我們常用的“三段論式（提問題、解問題、給結論）”的論文摘要寫法啊。

後來，隨著分散式系統的不斷髮展壯大，Paxos演算法開始大顯神威。Google的Chubby和Apache的Zookeeper，都是用Paxos作為其理論基礎實現的。就這樣， Paxos終於登上大雅之堂，它也為Lamport在2013年獲得圖靈獎，立下汗馬功勞。從Lamport發表Paxos演算法的小案例，我們可以看出：彪悍的人生，不需要解釋。牛逼的論文，就可以任性！

Chubby^【51】– 該文獻的作者是谷歌工程師Mike Burrows。Chubby系統本質上就是前文提到的Paxos的一個實現版本，主要用於谷歌分散式鎖服務。（注：原文連結會出現404錯誤，CSDN網站有Chubby論文的下載連結）。

Zookeeper^【52】 –這是Apache Hadoop框架下的Chubby開源版本。它不僅僅提供簡單地上鎖服務，而事實上，它還是一個通用的分散式協調器，其設計靈感來自谷歌的Chubby（注：眾所周知，分散式協調服務開發困難很大，分散式系統中的多程序間很容易發生條件競爭和死鎖。ZooKeeper的開發動力就是減輕分散式應用開發的困難，使使用者不必從零開始構建協調服務）。

計算框架（Computational Frameworks）

The execution runtimes provide an environment for running distinct kinds of compute. The most common runtimes are

Spark – its popularity and adoption is challenging the traditional Hadoop ecosystem.Flink – very similar to Spark ecosystem; strength over Spark is in iterative processing.

The frameworks broadly can be classified based on the model and latency of processing

計算框架（Computational Frameworks）

執行時計算框架，可為不同種類的計算，提供執行時（runtime）環境。最常用的是執行時計算框架是Spark和Flink。

Spark^【53】 –因Spark日益普及，加之其具備良好的多計算環境的適用性，它已對傳統的Hadoop生態環境，形成了嚴峻的挑戰（注：Spark是一個基於記憶體計算的開源的叢集計算系統，其目的在於，讓資料分析更加快速。Spark是由加州大學伯克利分校的AMP實驗室採用Scala語言開發而成。Spark的記憶體計算框架，適合各種迭代演算法和互動式資料分析，能夠提升大資料處理的實時性和準確性，現已逐漸獲得很多企業的支援，如阿里巴巴、百度、網易、英特爾等公司均是其使用者）。

Flink^【54】 –這是一個非常類似於Spark的計算框架，但在迭代式資料處理上，比Spark更給力（注：目前大資料分析引擎Flink，已升級成為Apache頂級專案）。

Spark和Flink都屬於基礎性的大資料處理引擎。具體的計算框架，大體上，可根據採用的模型及延遲的處理不同，來進行分門別類。

Batch

MapReduce – The seminal paper from Google on MapReduce.

MapReduce Survey – A dated, yet a good paper; survey of Map Reduce frameworks.

批處理（Batch）

MapReduce^【55】– 這是谷歌有關MapReduce的最早的學術論文（注：對於國內使用者，點選原文獻連結可能會產生404錯誤，CSDN網站有MapReduce論文的下載連結）。

MapReduce綜述^【56】 –這是一篇過時、但依然值得一讀的、有關MapReduce計算框架的綜述性文章。

Iterative (BSP)

Pregel – Google’s paper on large scale graph processing
Giraph - large-scale distributed Graph processing system modelled around Pregel
GraphX - graph computation framework that unifies graph-parallel and data parallel computation.
Hama - general BSP computing engine on top of Hadoop
Open source graph processing  survey of open source systems modelled around Pregel BSP.

迭代式（BSP）

Pregel^【57】–這又是一篇谷歌出品的大手筆論文，主要描述了大規模圖處理方法（注：Pregel是一種面向圖演算法的分散式程式設計框架，其採用的是迭代式的計算模型。它被稱之為Google後Hadoop時代的新“三駕馬車”之一。另外兩駕馬車分別是：“互動式”大資料分析系統Dremel和網路搜尋引擎Caffeine）。

Giraph^【58】 – 該系統建模於谷歌的Pregel，可視為Pregel的開源版本，它是一個基於 Hadoop架構的、可擴充套件的分散式迭代圖處理系統。

GraphX^【59】 –這是一個同時採用圖平行計算和資料並行的計算框架（注：GraphX最先是加州大學伯克利分校AMPLab實驗室的一個分散式圖計算框架專案，後來整合到Spark中，成為其中的一個核心元件。GraphX最大的貢獻在於，在Spark之上提供一棧式資料解決方案，可方便高效地完成圖計算的一整套流水作業）。

Hama^【60】– 是一個構建Hadoop之上的基於BSP模型的分散式計算引擎（注：

Hama的執行環境需要關聯 Zookeeper、HBase、HDFS 元件。Hama中最關鍵的技術，就是採用了BSP模型(Bulk Synchronous Parallel，即整體同步平行計算模型，又名大同步模型)。BSP模型是哈佛大學的電腦科學家Viliant和牛津大學的BillMcColl在1990年聯合提出的，他們希望能像馮·諾伊曼體系結構那樣，架起計算機程式語言和體系結構間的橋樑，故又稱作橋模型(Bridge Model)。

開源圖處理系統^【61】（Open source graph processing ）-這是滑鐵盧大學的研究人員撰寫的綜述性文獻，文獻【61】對類Pregel（Pregel-like）的、基於BSP模型的圖處理系統進行了實驗性的比較。

Streaming

Stream Processing – A great overview of the distinct real time processing systems 
Storm – Real time big data processing system
Samza  - stream processing framework from LinkedIn
Spark Streaming – introduced the micro batch architecture bridging the traditional batch and interactive processing.

流式（Streaming）

流式處理^【62】（Stream Processing）- 這是一篇非常棒的、有關面向大資料實時處理系統的綜述性文章。

Storm^【63】 – 這是一個大資料實時處理系統（注：Storm有時也被人們稱為實時處理領域的Hadoop，它大大簡化了面向龐大規模資料流的處理機制，從而在實時處理領域扮演著重要角色。文獻【63】是Twitter工程師們在2014年發表於SIGMOD上的學術論文）。

Samza^【64】 -這是一款由Linkedin公司開發的分散式的流式資料處理框架（注：所謂流式資料，是指要在處理單位內得到的資料，這種方式更注重於實時性，流式資料有時也稱為快資料）。

Spark流^【65】（Spark Streaming） -該文獻是加州大學伯克利分校的研究人員於2013年在著名作業系統會議SOSP上發表的學術論文，論文題目是《離散流：容錯大規模流式計算》（注：這裡的離散流是指一種微批處理構架，其橋接了傳統的批處理和互動式處理。Spark Streaming是Spark 核心API的一個擴充套件，它並不會像Storm那樣逐個處理資料流，而是在處理前，按時間間隔預先將其切分為很多小段的批處理作業）。

Interactive

Dremel – Google’s paper on how it processes interactive big data workloads, which laid the groundwork for multiple open source SQL systems on Hadoop.
Impala – MPI style processing on make Hadoop performant for interactive workloads.
Drill – A open source implementation of Dremel.
Shark – provides a good introduction to the data analysis capabilities on the Spark ecosystem.
Shark – another great paper which goes deeper into SQL access.
Dryad – Configuring & executing parallel data pipelines using DAG.
Tez – open source implementation of Dryad using YARN.
BlinkDB - enabling interactive queries over data samples and presenting results annotated with meaningful error bars

互動式（Interactive）

Dremel^【66】–這又是一篇由谷歌出品的經典論文，論文描述瞭如何處理“互動式”大資料的工作負載。該論文是多個基於Hadoop的開源SQL系統的理論基礎（注：文獻【66】寫於2006年，“捂”藏4年之後，於2010年公佈於眾。文章針對MR互動式查詢能力不足，提出了Dremel，闡述了Dremel的設計原理，並提供了部分測試報告）。

Impala^【67】 –這是一個大規模並行處理（MPP）式 SQL 大資料分析引擎（注：

Impala像Dremel一樣，其借鑑了MPP（Massively Parallel Processing，大規模並行處理）並行資料庫的思想，拋棄了MapReduce這個不太適合做SQL查詢的正規化，從而讓Hadoop支援處理互動式的工作負載。本文作者阿尼爾•馬丹在LinkedIn上的部落格原文，在此處的“MPI”系“MPP”筆誤，讀者可參閱文獻【67】發現此問題）。

Drill^【68】–這是谷歌 Dremel的開源版本（注：Drill是一個低延遲的、能對海量資料（包括結構化、半結構化及巢狀資料）實施互動式查詢的分散式資料引擎）。

Shark^【69】 –該文獻是2012年發表於SIGMOD的一篇學術論文，論文對Spark生態系統上的資料分析能力，給出了很深入的介紹（注：Shark是由加州伯克利大學AMPLab開發的大資料分析系統。Shark即“Hive on Spark”的含義，本質上是通過Hive的HQL解析，把HQL翻譯成Spark上的RDD操作。然後通過Hive的元資料獲，取資料庫裡的表資訊。HDFS上的資料和檔案，最後會由Shark獲取，並放到Spark上運算。Shark基於 Scala語言的運算元推導，可實現良好的容錯機制，對執行失敗的長/短任務，均能從上一個“快照點（Snapshot）”進行快速恢復）。