摘要：本文基于PayPal進階工程總監Anil Madan寫的大資料文章，其中涵蓋100篇大資料的論文，涵蓋大資料技術棧（資料存儲層、鍵值存儲、面向列的存儲、流式、互動式、實時系統、工具、庫等），全部讀懂你将會是大資料的頂級高手。作者通過引用Anil Madan原文和CSDN的譯文為基礎。進行中英對照整理所得。旨在技術傳播，分享更多技術愛好者。為尊重原文，本人将原文放置最醒目之處：英文：100 open source Big Data architecture papers for data professionals.中文：PayPal進階工程總監：讀完這100篇論文 就能成大資料高手.（本文引用整編所得，轉載說明出處：讀完這100篇論文 就能成大資料高手.）
100 open source Big Data architecture papers for data professionals.
讀完這100篇論文 就能成大資料高手
作者 白甯超
2016年4月16日13:38:49
摘要：本文基于PayPal進階工程總監Anil Madan寫的大資料文章，其中涵蓋100篇大資料的論文，涵蓋大資料技術棧（資料存儲層、鍵值存儲、面向列的存儲、流式、互動式、實時系統、工具、庫等），全部讀懂你将會是大資料的頂級高手。作者通過引用Anil Madan原文和CSDN的譯文為基礎。進行中英對照整理所得。旨在技術傳播，分享更多技術愛好者。為尊重原文，本人将原文放置最醒目之處：英文：100 open source Big Data architecture papers for data professionals.中文：PayPal進階工程總監：讀完這100篇論文 就能成大資料高手.（本文引用整編所得，轉載說明出處：讀完這100篇論文 就能成大資料高手.）
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.
- Ceph File System– An alternative to 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）
在分布式資料系統中，協調器主要用于協調服務和進行狀态管理。
Paxos【49】 –文獻【49】是經典論文“The Part-Time Parliament（兼職的議會）【50】” 的簡化版。
注：兩篇文獻的作者均是萊斯利·蘭伯特（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）”進行快速恢複）。
Shark【70】–這是另外一篇很棒的于2013年發表在SIGMOD的學術論文，其深度解讀在Apache Hive之上SQL通路機制（注：這篇文獻描述了如何建構在Spark上建構SQL引擎——Shark。更重要的是，文章還讨論了之前在 Hadoop/MapReduce上實施SQL查詢如此之慢的原因）。
Dryad【71】– 文獻讨論了使用有向無環圖(Directed Acycline Graph，DAG)來配置和執行并行資料流水線的方法（注：Dryad是一個通用的粗顆粒度的分布式計算和資源排程引擎，其核心特性之一，就是允許使用者自己建構DAG排程拓撲圖。文獻【71】是微軟于2007年在EuroSys國際會議上釋出的學術論文）。
Tez【72】 –其核心思想來源于Dryad，可視為利用Yarn(即MRv2)對Dryad的開源實作（注：Apache Tez是基于Hadoop Yarn之上的DAG計算架構。由Hadoop的二東家Hortonworks開發并提供主要技術支援。文獻【72】是一個關于Tez的簡要介紹文檔）。
BlinkDB【73】–可在抽樣資料上實作互動式查詢，其呈現出的查詢結果，附帶有誤差辨別。
（注：BlinkDB 是一個用于在海量資料上運作互動式 SQL 查詢的大規模并行查詢引擎。BlinkDB允許使用者通過适當降低資料精度，對資料進行先采樣後計算，其通過其獨特的優化技術，實作了比Hive快百倍的互動式查詢速度，而查詢進度誤差僅降低2~10%。
BlinkDB采用的政策，與大資料布道師，維克托·邁爾-舍恩伯格在其著作《大資料時代》中提到的觀點，“要全體，不要抽樣”，恰恰相反。
基于常識，我們知道：多了，你就快不了。好了，你就省不了。對大資料處理而言，也是這樣。英特爾中國研究院院長吳甘沙認為，大體量、精确性和速度快，三者不可兼得，頂多取其二。如果要實作在大體量資料上的 “快”，就得想辦法減少資料，而減少資料，勢必要适度地降低分析精确性。
事實上，大資料并不見得越“大”越好，有時候一味的追求“大”是沒有必要的。例如，在醫療健康領域，如果來監控某個病人的體溫，可穿戴裝置可以一秒鐘采集一次資料，也可以一分鐘采集一次資料，前者采集的資料總量比後者“大”60倍，但就監控病人身體狀況而言，意義并不是太大。雖然後者的資料忽略了人體在一分鐘内的變化，監控的精度有所下降，但對于完成監控病人健康狀态這一目的而言，是可以接受的。）
RealTime
Druid – a real time OLAP data store. Operationalized time series analytics databases
Pinot – LinkedIn OLAP data store very similar to Druid.
實時系統（RealTime）
Druid【74】 –這是一個開源的分布式實時資料分析和存儲系統，旨在快速處理大規模的資料，并能做到快速查詢和分析（注：文獻【74】是2014年Druid創始人Eric Tschetter和中國工程師楊仿今等人在SIGMOD上發表的一篇論文）。
Pinot【75】 –這是由LinkedIn公司出品的一個開源的、實時分布式的 OLAP資料分析存儲系統，非常類似于前面提到的Druid，LinkedIn 使用它實作低延遲可伸縮的實時分析。（注：文獻【75】是在GitHub上的有關Pinot的說明性文檔）。
資料分析層（Data Analysis）
The analysis tools range from declarative languages like SQL to procedural languages like Pig. Libraries on the other hand are supporting out of the box implementations of the most common data mining and machine learning libraries.
資料分析層（Data Analysis）
資料分析層中的工具，涵蓋範圍很廣，從諸如SQL的聲明式程式設計語言，到諸如Pig的過程化程式設計語言，均有涉及。另一方面，資料分析層中的庫也很豐富，可支援常見的資料挖掘和機器學習算法，這些類庫可拿來即用，甚是友善。
Tools
Pig – Provides a good overview of Pig Latin.
Pig – provide an introduction of how to build data pipelines using Pig.
Hive – provides an introduction of Hive.
Hive – another good paper to understand the motivations behind Hive at Facebook.
Phoenix – SQL on Hbase.
Join Algorithms for Map Reduce – provides a great introduction to different join algorithms on Hadoop.
Join Algorithms for Map Reduce – another great paper on the different join techniques.
工具（Tools）
Pig【76】 –這是一篇有關Pig Latin非常不錯的綜述文章（注：Pig Latin原是一種兒童黑話，屬于是一種英語語言遊戲，形式是在英語上加上一點規則使發音改變，讓大人們聽不懂，進而完成孩子們獨懂的交流。文獻【76】是雅虎的工程師們于2008年發表在SIGMOD的一篇論文，論文的題目是“Pig Latin：并不是太老外的一種資料語言”，言外之意，他們發明了一種資料處理的“黑話”——Pig Latin，一開始你可能不懂，等你熟悉了，就會發現這種資料查詢語言的樂趣所在）。
Pig【77】 – 這是另外一篇由雅虎工程師們撰寫的有關使用Pig經驗的論文，文章介紹了如果利用Pig在Map-Reduce上建構一個高水準的資料流分析系統。
Hive【78】 –該文獻是Facebook資料基礎設施研究小組撰寫的一篇學術論文，介紹了Hive的來龍去脈（注：Hive是一個建立于 Hadoop 上的資料倉庫基礎構架。它用來進行資料的提取、轉化和加載（即Extract-Transform-Load ，ETL），它是一種可以存儲、查詢和分析存儲在 Hadoop 中的大規模資料的機制）。
Hive【79】–該文獻是另外一篇有關Hive的值得一讀的好論文。論文作者來自Facebook資料基礎設施研究小組，在這篇論文裡，可以幫助讀者了解Hive的設計理念。
Phoenix【80】 –它是 HBase 的 SQL 驅動（注：Phoenix可将 SQL 查詢轉成 HBase 的掃描及相應的動作。文獻【80】是關于在Hbase上部署SQL的幻燈片文檔）。
Map Reduce上的連接配接（join）算法【81】–該文獻介紹了在Hadoop環境下的各種并行連接配接算法，并對它們的性能作出系統性評測。
Map Reduce上的連接配接算法【82】 –這是威斯康星大學和IBM研究團隊撰寫的綜述性文章，文章對在Map Reduce模型下的各種連接配接算法進行了綜合比較。
Libraires
MLlib – Machine language library on Spark.
SparkR – Distributed R on Spark framework.
Mahout – Machine learning framework on traditional Map Reduce.
庫（Libraires）
MLlib【83】–這是在Spark計算架構中對常用的機器學習算法的實作庫，該庫還包括相關的測試和資料生成器（注：文獻【83】是MLlib的一個幻燈片說明文檔）。
SparkR【84】–這是AMPLab釋出的一個R開發包，為Apache Spark提供輕量級的前端（注：R是一種廣泛應用于統計分析、繪圖的語言及操作環境。文獻【84】是有關SparkR的幻燈片文檔）。
Mahout【85】 –這是一個功能強大的資料挖掘工具，是一個基于傳統Map Reduce的分布式機器學習架構（注：Mahout的中文含義就是“馭象之人”，而Hadoop的Logo正是一頭小黃象。很明顯，這個庫是幫助使用者用好Hadoop這頭難用的大象。文獻【85】是有關Mahout的圖書）。
資料內建層（Data Integration）
Data integration frameworks provide good mechanisms to ingest and outgest data between Big Data systems. It ranges from orchestration pipelines to metadata framework with support for lifecycle management and governance.
資料內建層（Data Integration）
資料內建架構提供了良好的機制，以協助高效地攝取和輸出大資料系統之間的資料。從業務流程線到中繼資料架構，資料內建層皆有涵蓋，進而提供全方位的資料在整個生命周期的管理和治理。
Ingest/Messaging
Flume – a framework for collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store.
Sqoop– a tool to move data between Hadoop and Relational data stores.
Kafka – distributed messaging system for data processing
攝入/消息傳遞（Ingest/Messaging）
Flume【86】 –這是Apache旗下的一個分布式的、高可靠的、高可用的服務架構，可協助從分散式或集中式資料源采集、聚合和傳輸海量日志（注：文獻【86】是Apache網站上有關Flume的一篇部落格文章）。
Sqoop【87】–該系統主要用來在Hadoop和關系資料庫中傳遞資料（注：Sqoop目前已成為Apache的頂級項目之一。通過Sqoop，可以友善地将資料從關系資料庫導入到HDFS，或反之亦可。文獻【87】是有關Sqoop的幻燈片說明文檔）。
Kafka【88】 –這是由LinkedIn開發的一個分布式消息系統（注：由Scala編寫而成的Kafka，由于可水準擴充、吞吐率高等特性，得到廣泛應用。文獻【88】是LindedIn的工程師們在2011年發表于NetDB的會議論文）。
ETL/Workflow
Crunch – library for writing, testing, and running MapReduce pipelines.
Falcon – data management framework that helps automate movement and processing of Big Data.
Cascading – data manipulation through scripting.
Oozie – a workflow scheduler system to manage Hadoop jobs.
ETL/工作流
ETL是資料抽取（Extract）、清洗（Cleaning）、轉換（Transform）、裝載（Load）的過程，是建構資料倉庫的重要一環。
Crunch【89】–這是Apache旗下的一套Java API函數庫，它能夠大大簡化編寫、測試、運作MapReduce 處理工作流的程式（注：文獻【89】是有關Crunch的幻燈片解釋文檔）。
Falcon【90】– 這是Apache旗下的Falcon大資料管理架構，可以幫助使用者自動遷移和處理大資料集合（注：文獻【90】是一份關于Falcon技術預覽報告）。
Cascading【91】 –這是一個架構在Hadoop上的API函數庫，用來建立複雜的可容錯的資料處理工作流（注：文獻【91】是關于Hadoop上的Cascading的概論和技術随筆）。
Oozie【92】–是一個工作流引擎，用來協助Hadoop作業管理（注：Oozie字面含義是馴象之人，其寓意和Mahout一樣，幫助使用者更好地搞定Hadoop這頭大象。文獻【92】是Apache網站上有關Oozie的官方文檔）。
Metadata
HCatalog - a table and storage management layer for Hadoop.
中繼資料（Metadata）
HCatalog【93】– 它提供了面向Apache Hadoop的資料表和存儲管理服務（注：Apache HCatalog提供一個共享的模式和資料類型的機制，它抽象出表，使使用者不必關心資料怎麼存儲，并提供了可操作的跨資料處理工具。文獻【93】是Apache網站有關Hcatalog的官方說明文檔）。
Serialization
ProtocolBuffers – language neutral serialization format popularized by Google. Avro – modeled around Protocol Buffers for the Hadoop ecosystem.
序列化（Serialization）
Protocol Buffers【94】 –由Google推廣的一種與語言無關的、對結構化資料進行序列化和反序列化的機制（注：Protocol Buffers可用于通訊協定、資料存儲等領域的語言及平台無關、可擴充的序列化結構資料格式。文獻【94】是有關Protocol Buffers幻燈片文檔）。
Avro【95】 –這是一個模組化于Protocol Buffers之上的、Hadoop生态系統中的子項目（注：Avro本身既是一個序列化架構，同時也實作了RPC的功能）。
操作架構層（Operational Frameworks）
Finally the operational frameworks provide capabilities for metrics, benchmarking and performance optimization to manage workloads.
操作架構（Operational Frameworks）
最後，我們還需要一個操作性架構，來建構一套衡量标準和測試基準，進而來評價各種計算架構的性能優劣。在這個操作性架構中，還需要包括性能優化工具，借助它來平衡工作負載。
Monitoring Frameworks
OpenTSDB – a time series metrics systems built on top of HBase.
Ambari - system for collecting, aggregating and serving Hadoop and system metrics
監測管理架構（Monitoring Frameworks）
OpenTSDB【96】 –這是建構于HBase之上的實時性能評測系統（注：文獻【96】提供了OpenTSDB的簡要概述，介紹了OpenTSDB的工作機理）。
Ambari【97】– 這是一款基于Web的系統，支援Apache Hadoop叢集的供應、管理和監控（注：文獻【97】闡述了Ambari架構的設計準則）。
Benchmarking
YCSB – performance evaluation of NoSQL systems.
GridMix – provides benchmark for Hadoop workloads by running a mix of synthetic jobs
Background on big data benchmarking with the key challenges associated.
基準測試（Benchmarking）
YCSB【98】 –該文獻是一篇使用YCSB對NoSQL系統進行性能評估的期刊論文（注：YCSB是雅虎雲服務基準測試（Yahoo! Cloud Serving Benchmark）的簡寫。見名知意，它是由雅虎出品的一款通用雲服務性能測試工具）。
GridMix【99】 –該系統通過運作大量合成的作業，對Hadoop系統進行基準測試，進而獲得性能評價名額（注：文獻是Apache網站有關GridMix的官方說明文檔）。
最後一篇文獻是有關大資料基準測試的綜述文章【100】，文章讨論了基準測試的最新技術進展以及所面臨的幾個主要挑戰。
總結（Summary）
I hope that the papers are useful as you embark or strengthen your journey. I am sure there are few hundred more papers that I might have inadvertently missed and a whole bunch of systems that I might be unfamiliar with - apologies in advance as don\'t mean to offend anyone though happy to be educated....
譯者寄語：
在你邁步于大資料的旅途中，真心希望這些文獻能助你一臂之力。但要知道，有關大資料的文獻，何止千萬，由于個人精力、能力有限，有些領域也不甚熟稔，故難免會挂一漏萬。如有疏忽，漏掉你的大作，還請你海涵。最後，希望這些文獻能給你帶來“學而時習之，不亦樂乎”的快感！