PayPal高級(jí)工程總監(jiān)：讀完這100篇論文 就能成大數(shù)據(jù)高手-CSDN.NET http://www.csdn.net/article/2015-07-07/2825148

更多請(qǐng)關(guān)注原文：https://www.linkedin.com/pulse/100-open-source-big-data-architecture-papers-anil-madan

在介紹這100篇文獻(xiàn)之前藕届，首先讓我們看一下大數(shù)據(jù)處理的關(guān)鍵架構(gòu)層（如圖1所示）：
關(guān)鍵架構(gòu)層

Paste_Image.png

轉(zhuǎn)自：csdn；譯者：張玉宏亭饵；文來(lái)自：LinkeDin休偶；作者： 作者：Anil Madan；
開(kāi)源（Open Source）用之于大數(shù)據(jù)技術(shù)辜羊，其作用有二：一方面踏兜，在大數(shù)據(jù)技術(shù)變革之路上，開(kāi)源在眾人之力和眾人之智推動(dòng)下八秃，摧枯拉朽碱妆，吐故納新，扮演著非常重要的推動(dòng)作用昔驱。另一方面疹尾，開(kāi)源也給大數(shù)據(jù)技術(shù)構(gòu)建了一個(gè)異常復(fù)雜的生態(tài)系統(tǒng)。每一天骤肛，都有一大堆“新”框架纳本、“新”類(lèi)庫(kù)或“新”工具，猶如雨后春筍般涌出腋颠，亂花漸欲“迷”人眼繁成。為了掌控住這些“新玩意”，數(shù)據(jù)分析的達(dá)人們不得不“殫精竭慮”地“學(xué)而時(shí)習(xí)之”秕豫。

無(wú)論你是一個(gè)大數(shù)據(jù)的布道者朴艰，還是一個(gè)日臻成熟的技術(shù)派观蓄，亦或你還在大數(shù)據(jù)這條路上“小河才露尖尖角”，多花點(diǎn)時(shí)間祠墅，深入理解一下大數(shù)據(jù)系統(tǒng)的技術(shù)體系演進(jìn)侮穿，對(duì)你都會(huì)有莫大益處。全方位地理解大數(shù)據(jù)體系結(jié)構(gòu)中的各個(gè)組件毁嗦，并掌握它們之間的微妙差別亲茅，可在處理自己身邊的大數(shù)據(jù)案例時(shí)，助你張弛有度狗准，“恢恢乎克锣，其于游刃必有余地矣!”

在過(guò)去的幾年里，我閱讀了很多不錯(cuò)的大數(shù)據(jù)文獻(xiàn)腔长，這些文獻(xiàn)陪我成長(zhǎng)袭祟，助我成功，使我成為一個(gè)具備良好教育背景的大數(shù)據(jù)專(zhuān)業(yè)人士捞附。在這里巾乳，撰寫(xiě)此文的目的，不限于僅僅和大家分享這些很不錯(cuò)的文獻(xiàn)鸟召，更重要的是胆绊，借此機(jī)會(huì)，想和大家一起欧募，集眾人之智慧压状，破解大數(shù)據(jù)開(kāi)源系統(tǒng)之迷宮。

需要提醒的是跟继，下文提及到的100篇參考文獻(xiàn)（這些文獻(xiàn)中大多都是一些開(kāi)創(chuàng)性的研究論文）种冬，將會(huì)為你提供結(jié)構(gòu)性的深度剖析，絕非泛泛而談还栓。我相信碌廓，這可從根本上幫助你深度理解大數(shù)據(jù)體系組件間的細(xì)微差別传轰。但如果你打算“走馬觀花”般地快速過(guò)一遍剩盒，了解大數(shù)據(jù)為何物，對(duì)不起慨蛙，這里可能會(huì)讓你失望辽聊。
那么，準(zhǔn)備好了嗎期贫？讓我們走起跟匆！

在介紹這100篇文獻(xiàn)之前，首先讓我們看一下大數(shù)據(jù)處理的關(guān)鍵架構(gòu)層（如圖1所示）：
關(guān)鍵架構(gòu)層

數(shù)據(jù)存儲(chǔ)層：由于目前采集到的數(shù)據(jù)讽营，十之有七八為非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)的表現(xiàn)形式各異泡徙，有文本的橱鹏、圖像的、音頻的堪藐、視頻的等莉兰，因此常見(jiàn)的數(shù)據(jù)存儲(chǔ)也要對(duì)應(yīng)有多種形式，有基于鍵值（Key-Value）的礁竞，有基于文檔（Document）糖荒，還有基于列（Column）和圖表（Graph）的。如果采用單一的數(shù)據(jù)庫(kù)引擎模捂，“一刀切式”的滿足所有類(lèi)型的數(shù)據(jù)存儲(chǔ)需求寂嘉，通常會(huì)嚴(yán)重降低數(shù)據(jù)庫(kù)管理的性能。因此枫绅，我們需要“兵來(lái)將擋泉孩，水來(lái)土掩”式的、多元的（Polyglot）【1】數(shù)據(jù)庫(kù)解決方案（這就好比并淋，如果“兵來(lái)了”和“水來(lái)了”寓搬，都要“將”去擋，遇到“兵”時(shí)县耽，“將”可以“酣暢淋漓”句喷，而遇到“水”時(shí)，還用“將”去擋兔毙，那這個(gè)“將”估計(jì)就要“舍生取義”了唾琼。文獻(xiàn)【1】是一本有關(guān)NoSQL數(shù)據(jù)處理的圖書(shū)）

資源管理層：這一層是為了提高資源的高利用率和吞吐量，以到達(dá)高效的資源管理與調(diào)度目的澎剥。

**資源協(xié)調(diào)層： **在本層的系統(tǒng)锡溯，需要完成對(duì)資源的狀態(tài)、分布式協(xié)調(diào)哑姚、一致性和資源鎖實(shí)施管理祭饭。

計(jì)算框架層：在本層的計(jì)算框架非常龐雜，有很多高度專(zhuān)用的框架包含其內(nèi)叙量，有流式的倡蝙，交互式的，實(shí)時(shí)的绞佩，批處理和迭代圖的（Batch and Iterative Graph寺鸥，BSP）等猪钮。為這些計(jì)算框架提供支撐的是運(yùn)行時(shí)引擎，如BDAS【2】(Spark) 和 Flink等（注：這里的BDAS是指“Berkeley Data Analytics Stack”胆建，即伯克利數(shù)據(jù)分析棧躬贡。文獻(xiàn)【2】為Spark核心作者Ion Stoica的講座幻燈片文檔）。

數(shù)據(jù)分析層：在這一層里眼坏，主要包括數(shù)據(jù)分析(消費(fèi))工具和一些數(shù)據(jù)處理函數(shù)庫(kù)拂玻。這些工具和函數(shù)庫(kù)，可提供描述性的宰译、預(yù)測(cè)性的或統(tǒng)計(jì)性的數(shù)據(jù)分析功能及機(jī)器學(xué)習(xí)模塊檐蚜。

數(shù)據(jù)集成層：在這一層里，不僅包括管理數(shù)據(jù)分析工作流中用到的各種適用工具沿侈，除此之外闯第，還包括對(duì)元數(shù)據(jù)（Metadata）管理的工具。

操作框架層：這一層提供可擴(kuò)展的性能監(jiān)測(cè)管理和基準(zhǔn)測(cè)試框架缀拭。

架構(gòu)的演進(jìn)
減少數(shù)據(jù)生產(chǎn)者和消費(fèi)者之間的處理延遲咳短，一直是現(xiàn)代計(jì)算構(gòu)架不斷演進(jìn)的主要?jiǎng)恿ΑＳ纱酥肓埽Q生了實(shí)時(shí)和低延遲處理的計(jì)算構(gòu)架咙好，如Lambda和Kappa等，這類(lèi)混合架構(gòu)取長(zhǎng)補(bǔ)短褐荷，架起傳統(tǒng)的批處理層和交互式層之間連接的橋梁勾效。
Lambda【3】 -該架構(gòu)是經(jīng)典的大數(shù)據(jù)處理范式，是由南森?馬茲（Nathan Marz）提出的一個(gè)實(shí)時(shí)大數(shù)據(jù)處理框架叛甫。更多有關(guān)Lamda的信息层宫，請(qǐng)讀者訪問(wèn)Lambda官方網(wǎng)站。（注：文獻(xiàn)【3】是由James Kinley在輕博客網(wǎng)站Tumblr發(fā)表的一篇博文：Lambda 架構(gòu)：構(gòu)架實(shí)時(shí)大數(shù)據(jù)系統(tǒng)的原則）其监。

Kappa【4】-該計(jì)算構(gòu)架可視為L(zhǎng)ambda的一個(gè)強(qiáng)有力替代者萌腿，Kappa將數(shù)據(jù)處理的上游移至流式層（注：文獻(xiàn)【4】是一篇博客文章，作者是Jay Kreps是Linkedln的一名在線數(shù)據(jù)架構(gòu)技術(shù)高管抖苦。Kreps認(rèn)為毁菱，雖然Lambda構(gòu)架的理念很有價(jià)值，但終究還是一個(gè)臨時(shí)解決方案睛约。他設(shè)計(jì)了一個(gè)替代架構(gòu)Kappa鼎俘，是基于他在Linkedin構(gòu)建Kafka和Samza的經(jīng)驗(yàn)設(shè)計(jì)而成）哲身。

SummingBird【5】-這是一個(gè)參考模型辩涝，用來(lái)橋接在線處理模式和傳統(tǒng)處理模式。Summingbird是由Twitter（推特）公司用Scala語(yǔ)言開(kāi)發(fā)的勘天、并開(kāi)源的大規(guī)模數(shù)據(jù)處理框架怔揩，支持開(kāi)發(fā)者以批處理模式（基于Hadoop）或流處理模式（基于Storm）捉邢，或混合模式（即前兩種模式的組合）以統(tǒng)一的方式執(zhí)行代碼。（注：文獻(xiàn)【5】是Summingbird的主要設(shè)計(jì)者Oscar Boykin商膊、Sam Ritchie等人于2014年發(fā)表于知名期刊PVLDB中論文伏伐，其中論文的二作Sam Ritchie大有來(lái)頭，他是計(jì)算機(jī)科學(xué)界的傳奇人物晕拆、C語(yǔ)言和Unix的設(shè)計(jì)者Dennis Ritchie的侄子）藐翎。

在你尚未深入了解下面的各個(gè)具體的框架層次之前，建議你認(rèn)真閱讀一下下面的幾篇非常有價(jià)值的文獻(xiàn)实幕，它們幫為你“惡補(bǔ)”一下諸如NoSQL（非結(jié)構(gòu)化）數(shù)據(jù)存儲(chǔ)吝镣、數(shù)據(jù)倉(cāng)庫(kù)大規(guī)模計(jì)算及分布式系統(tǒng)等相關(guān)領(lǐng)域的背景知識(shí)：
計(jì)算中心即計(jì)算機(jī)【6】（Data center as a computer）-文獻(xiàn)【6】是威斯康星大學(xué)-麥迪遜分校Mark D. Hill教授主編的一個(gè)論文集式的圖書(shū)，在這本圖書(shū)中昆庇，收集了很多有關(guān)數(shù)據(jù)倉(cāng)庫(kù)大規(guī)模計(jì)算的論文（注：將數(shù)據(jù)中心視為一臺(tái)計(jì)算機(jī)末贾，與傳統(tǒng)的高性能計(jì)算機(jī)有很大不同。計(jì)算中心的實(shí)例將以虛擬機(jī)或者容器的形式存在整吆，計(jì)算資源的配置對(duì)于用戶(hù)而言是透明的拱撵，這樣就大幅降低系統(tǒng)部署的復(fù)雜度、并提高資源使用的靈活性）表蝙。

非結(jié)構(gòu)化（NOSQL）數(shù)據(jù)存儲(chǔ)【7】– 文獻(xiàn)是由Rick Cattell撰寫(xiě)的論文拴测，論文討論了可擴(kuò)展的結(jié)構(gòu)化數(shù)據(jù)的、非結(jié)構(gòu)化的（包括基于鍵值對(duì)的、基于文檔的和面向列的）數(shù)據(jù)存儲(chǔ)方案（注：NOSQL是支撐大數(shù)據(jù)應(yīng)用的關(guān)鍵所在舟铜。事實(shí)上瞭恰，將NOSQL翻譯為“非結(jié)構(gòu)化”不甚準(zhǔn)確，因?yàn)镹OSQL更為常見(jiàn)的解釋是：Not Only SQL（不僅僅是結(jié)構(gòu)化）抄谐，換句話說(shuō)，NOSQL并不是站在結(jié)構(gòu)化SQL的對(duì)立面扰法，而是既可包括結(jié)構(gòu)化數(shù)據(jù)蛹含，也可包括非結(jié)構(gòu)化數(shù)據(jù)）。

NoSQL學(xué)位論文【8】-該文獻(xiàn)是德國(guó)斯圖加特傳媒大學(xué)Christof Strauch撰寫(xiě)的學(xué)位論文塞颁，該論文對(duì)分布式系統(tǒng)和第一代非結(jié)構(gòu)化系統(tǒng)提供了非常系統(tǒng)的背景知識(shí)介紹浦箱。

大規(guī)模數(shù)據(jù)管理【9】-文獻(xiàn)是加拿大阿爾伯塔大學(xué)的研究人員撰寫(xiě)的一篇綜述，討論了大數(shù)據(jù)應(yīng)用程序的大規(guī)模數(shù)據(jù)管理系統(tǒng)祠锣，傳統(tǒng)的數(shù)據(jù)庫(kù)供應(yīng)商與新興的互聯(lián)網(wǎng)企業(yè)酷窥，它們對(duì)大數(shù)據(jù)管理需求是不同的。文章的討論范圍涵蓋很廣伴网，數(shù)據(jù)模型蓬推、系統(tǒng)結(jié)構(gòu)及一致性模型，皆有涉及澡腾。

最終一致性（Eventual Consistency）【10】：論文討論了分布式系統(tǒng)中的各種不同的一致性模型沸伏。（注：原文給出的鏈接可能有誤糕珊，因?yàn)楦鶕?jù)所提供的鏈接下載而來(lái)的論文是關(guān)于“MapReduce中日志處理的Join算法”的綜述文章，與“最終一致性”的討論議題無(wú)關(guān)毅糟。這里推薦2篇新的相關(guān)論文：（1）綜述文章：數(shù)據(jù)庫(kù)最終一致性：最新的進(jìn)展【10】new1红选；（2）微軟研究人員2013年發(fā)表于SIGMOD的文章：“最終一致性的反思（Rethinking Eventual Consistency）【10】new2”。）

CAP理論【11】-文獻(xiàn)以“CAP理論十二年回顧：”規(guī)則”已經(jīng)變了”為題姆另，探討了CAP理論及其演化喇肋，是篇非常不錯(cuò)的介紹CAP理論的基礎(chǔ)性論文（注：論文作者Eric Brewer是加州大學(xué)伯克利分校的知名計(jì)算機(jī)科學(xué)學(xué)者。該文首發(fā)于《Computer》雜志迹辐，隨后又被InfoQ和IEEE再次發(fā)表苟蹈。CAP理論斷言，任何基于網(wǎng)絡(luò)的數(shù)據(jù)共享系統(tǒng)右核，最多只能滿足數(shù)據(jù)一致性（Consistency慧脱，C）、可用性（Availability 贺喝，A）菱鸥、分區(qū)（Partition，P）容忍性這三要素中的兩個(gè)要素躏鱼。但通過(guò)顯式處理分區(qū)氮采，系統(tǒng)設(shè)計(jì)師可做到優(yōu)化數(shù)據(jù)的一致性和可用性，進(jìn)而取得三者之間的妥協(xié)與平衡）染苛。

在過(guò)去鹊漠，在大規(guī)模數(shù)據(jù)處理上，傳統(tǒng)的并行數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）和基于Map Reduce（映射-規(guī)約茶行，以下簡(jiǎn)稱(chēng)MR）的批處理范式之間躯概，曾發(fā)生激烈辯論，各持己見(jiàn)畔师。并行數(shù)據(jù)庫(kù)管理系統(tǒng)的支持者【12】（注：由耶魯大學(xué)娶靡、微軟和麻省理工學(xué)院的研究人員于2009年發(fā)表在SIGMOD的一篇文章）和另外一篇文獻(xiàn)【13】（注：2010年發(fā)表于《美國(guó)計(jì)算機(jī)學(xué)會(huì)通訊》上的論文：“MapReduce和并行數(shù)據(jù)庫(kù)管理系統(tǒng)，是朋友還是敵人看锉？”）姿锭，被MR的擁躉者【14】（注：發(fā)表于美國(guó)計(jì)算機(jī)學(xué)會(huì)通訊的論文：MapReduce:一個(gè)彈性的數(shù)據(jù)處理工具）狠狠地給批駁了一番。

然而伯铣，令人諷刺的是呻此，從那時(shí)起，Hadoop社區(qū)開(kāi)始引入無(wú)共享的（Shared-Nothing）的MPP（大規(guī)模并行處理）風(fēng)格的大數(shù)據(jù)處理模式腔寡，文獻(xiàn)“Hadoop上的SQL【15】”焚鲜，便是例證。要知道，MPP是并行數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）的靈魂恃泪，這樣郑兴，Map Reduce繞了一大圈犀斋，又似回到它當(dāng)初離開(kāi)的地方贝乎。

文件系統(tǒng)層
由于文件系統(tǒng)層關(guān)注的焦點(diǎn)，開(kāi)始向“低延時(shí)處理”方向轉(zhuǎn)移叽粹，所以傳統(tǒng)基于磁盤(pán)存儲(chǔ)的文件系統(tǒng)览效，也開(kāi)始向基于內(nèi)存計(jì)算的文件系統(tǒng)轉(zhuǎn)變 —— 這樣做，會(huì)大大降低I / O操作和磁盤(pán)序列化帶來(lái)的訪問(wèn)開(kāi)銷(xiāo)虫几。Tachyon 和 Spark RDD【16】就是朝這個(gè)方向演化的范例（注：這里RDD指的是彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets）锤灿，它是一種高度受限的共享內(nèi)存模型，文獻(xiàn)【16】由伯克利大學(xué)加州分校的Matei Zaharia等撰寫(xiě)的辆脸，他們提出了一種面向內(nèi)存集群運(yùn)算的容錯(cuò)抽象模型）但校。

Google文件系統(tǒng)（GFS）【17】-該文獻(xiàn)是分布式文件系統(tǒng)的奠基之作，著名的Hadoop 分布式文件系統(tǒng)（HDFS）啡氢，亦脫胎于GFS状囱，基本上可視為GFS的一個(gè)簡(jiǎn)化實(shí)現(xiàn)版（注：文獻(xiàn)【17】提出了一個(gè)可擴(kuò)展的分布式文件系統(tǒng)GFS，可用于大型分布式數(shù)據(jù)密集型應(yīng)用倘是。文獻(xiàn)認(rèn)為亭枷，組件故障是常態(tài)而不是異常。其所提出的GFS搀崭，著眼在幾個(gè)重要的目標(biāo)叨粘，比如性能、可伸縮性瘤睹、可靠性和可用性升敲。GFS的新穎之處，并不在于它采用了多么令人驚艷的技術(shù)轰传，而在于它能利用所提出的方案冻晤，采用廉價(jià)的商用機(jī)器，來(lái)構(gòu)建高效的分布式文件系統(tǒng)绸吸。有用的創(chuàng)新鼻弧，才是真的創(chuàng)新，GFS做到了＝踝隆）攘轩。

Hadoop 文件系統(tǒng)【18】-該文獻(xiàn)由雅虎公司的計(jì)算機(jī)科學(xué)家Konstantin Shvachko等人聯(lián)合撰寫(xiě)的，論文給出了HDFS的進(jìn)化歷史背景及其架構(gòu)的設(shè)計(jì)內(nèi)涵码俩，是了解Hadoop技術(shù)的經(jīng)典之作度帮。

Ceph文件系統(tǒng)【19】-Ceph是HDFS有力的替代者【20】（注：Ceph文件系統(tǒng)是加州大學(xué)圣克魯茲分校（USSC）博士生Sage Weil博士期間的一項(xiàng)有關(guān)存儲(chǔ)系統(tǒng)的研究項(xiàng)目。初出茅廬，略有小成笨篷。之后瞳秽，在開(kāi)源社區(qū)的推動(dòng)下率翅，Ceph逐漸羽翼漸豐冕臭，風(fēng)云叱咤，功成名就鼻由，逐漸發(fā)展成為一個(gè) Linux系統(tǒng)下 PB 級(jí)分布式文件系統(tǒng)窟感。文獻(xiàn)【19】是Weil本人在2006年頂級(jí)會(huì)議OSDI發(fā)表的有關(guān)Ceph的開(kāi)山論文哈误。文獻(xiàn)【20】則是Weil率領(lǐng)他的一幫小伙伴們?cè)俅伟l(fā)文強(qiáng)調(diào)，Ceph是HDFS強(qiáng)有力的替代者）。

Tachyon【21】–是一個(gè)高容錯(cuò)的分布式內(nèi)存文件系統(tǒng)，其設(shè)計(jì)的核心內(nèi)涵是，要滿足當(dāng)下“低延遲”的數(shù)據(jù)處理要求（注：Tachyon是在內(nèi)存中處理緩存文件婆芦，允許文件以訪問(wèn)內(nèi)存的速度在集群框架中進(jìn)行可靠的共享，類(lèi)似于Spark。Tachyon的吞吐量比HDFS高出100倍棠枉。Spark框架雖然也提供了強(qiáng)大的內(nèi)存計(jì)算能力，但其沒(méi)有提供內(nèi)存文件的存儲(chǔ)管理能力生闲，而Tachyon則彌補(bǔ)了Spark的不足之處扯躺。文獻(xiàn)【21】是伯克利大學(xué)加州分校和麻省理工學(xué)院的研究者聯(lián)合撰寫(xiě)的倍啥，發(fā)表在2014年的 SoCC國(guó)際會(huì)議上，論文一作UC Berkeley AMP實(shí)驗(yàn)室博士生李浩源，他亦是Spark核心開(kāi)發(fā)人員之一）。

文件系統(tǒng)的演化歷程，其實(shí)也見(jiàn)證了文件格式和壓縮技術(shù)的發(fā)展歷程建车。下面的參考文獻(xiàn)，可以讓你了解到沃暗，“面向行”或“面向列”存儲(chǔ)格式各自的優(yōu)缺點(diǎn)嚼黔，并且還可讓你了然文件存儲(chǔ)技術(shù)發(fā)展的新趨勢(shì)——嵌套式的面向列的存儲(chǔ)格式碎节，這種存儲(chǔ)格式可極大提高大數(shù)據(jù)的處理效率陌僵。

當(dāng)前，在文件系統(tǒng)階段，數(shù)據(jù)管理的最大挑戰(zhàn)之一就是，如何處理大數(shù)據(jù)中的數(shù)據(jù)冗余茂附。糾刪碼（Erasure code）是很有創(chuàng)意的冗余保護(hù)機(jī)制蒂阱，它可以減少三倍的冗余副本荞胡，還不會(huì)影響數(shù)據(jù)的可恢復(fù)性與可用性窖梁。

面向列存儲(chǔ) vs. 面向列存儲(chǔ)【22】—該文獻(xiàn)是是2008年發(fā)表于SIGMOD的一篇論文假哎，該文對(duì)數(shù)據(jù)的布局劣砍、壓縮及物化（materialization）策略都做了很不錯(cuò)的綜述靠娱。

RCFile【23】-這是由Facebook數(shù)據(jù)基礎(chǔ)設(shè)施小組和俄亥俄州立大學(xué)的華人學(xué)者共同提出的文件存儲(chǔ)格式迅诬，他們走了一個(gè)“中庸之道”铐维，充分吸取面向列和面向行存儲(chǔ)模式的優(yōu)點(diǎn)第煮，揚(yáng)長(zhǎng)避短，提出了一種混合的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)PAX（注：目前這種以行/列混合存儲(chǔ)技術(shù)已成功應(yīng)用于 Facebook 等國(guó)內(nèi)外大型互聯(lián)網(wǎng)企業(yè)的生產(chǎn)性運(yùn)行體系）鳄逾。

Parquet【24】– 這是一種面向行的存儲(chǔ)格式，其設(shè)計(jì)理念源于谷歌 Dremel論文（注：Parquet主要用于 Hadoop 的生態(tài)系統(tǒng)中竖慧。文獻(xiàn)【24】是Julien Dem在Github發(fā)表的一篇博客文章）。

ORCFile【25】–這是一種被Hive（一種基于Hadoop的數(shù)據(jù)倉(cāng)庫(kù)工具）采用的谣旁、面向列存儲(chǔ)的改進(jìn)版存儲(chǔ)格式（注：文獻(xiàn)【25】是2014年發(fā)表于頂會(huì)SIGMOD的一篇學(xué)術(shù)論文）。

壓縮技術(shù)【26】-這是是一篇闡述在Hadoop生態(tài)系統(tǒng)下的常見(jiàn)壓縮算法的綜述性文章滋早，文章對(duì)常見(jiàn)的壓縮算法和其適用場(chǎng)景以及它們的優(yōu)缺點(diǎn)榄审，做了非常不錯(cuò)的歸納總結(jié)。

糾刪碼技術(shù)（Erasure code）【27】-這是一篇是田納西大學(xué)EECS系教授James Plank撰寫(xiě)的杆麸、有關(guān)存儲(chǔ)系統(tǒng)糾刪碼技術(shù)的入門(mén)級(jí)的文獻(xiàn)搁进。有關(guān)糾刪碼改進(jìn)技術(shù)的闡述，讀者可參閱來(lái)自南加州大學(xué)和Facebook的7名作者共同完成的論文《XORing Elephants: 面向大數(shù)據(jù)的新型糾刪碼技術(shù)【28】》（注：文獻(xiàn)【28】的作者開(kāi)發(fā)了糾刪碼家族的新成員——基于XOR的本地副本存儲(chǔ)LRC昔头，該技術(shù)是面向Hadoop生態(tài)系統(tǒng)的饼问，可顯著減少修復(fù)數(shù)據(jù)時(shí)的I/O操作和存儲(chǔ)開(kāi)銷(xiāo)）。

數(shù)據(jù)存儲(chǔ)層
寬泛地講减细，據(jù)對(duì)一致性（consistency）要求的強(qiáng)弱不同匆瓜，分布式數(shù)據(jù)存儲(chǔ)策略，可分為ACID和BASE兩大陣營(yíng)未蝌。ACID是指數(shù)據(jù)庫(kù)事務(wù)具有的四個(gè)特性：原子性（Atomicity）、一致性（Consistency）茧妒、隔離性（Isolation）萧吠、持久性（Durability）。ACID中的一致性要求比較強(qiáng)桐筏，事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫(kù)從一個(gè)一致性狀態(tài)變到另一個(gè)一致性狀態(tài)纸型。而B(niǎo)ASE對(duì)一致性要求較弱，它的三個(gè)特征分別是：基本可用（Basically Available）, 軟狀態(tài)/柔性事務(wù)（Soft-state梅忌，即狀態(tài)可以有一段時(shí)間的不同步）, 最終一致性（Eventual consistency）狰腌。BASE還進(jìn)一步細(xì)分基于鍵值的，基于文檔的和基于列和圖形的 – 細(xì)分的依據(jù)取決于底層架構(gòu)和所支持的數(shù)據(jù)結(jié)構(gòu)（注：BASE完全不同于ACID模型牧氮，它以犧牲強(qiáng)一致性琼腔，獲得基本可用性和柔性可靠性，并要求達(dá)到最終一致性）踱葛。

在數(shù)據(jù)存儲(chǔ)層丹莲，還有很多類(lèi)似的系統(tǒng)和某些系統(tǒng)的變種光坝，這里，我僅僅列出較為出名的幾個(gè)甥材。如漏掉某些重要系統(tǒng)盯另，還請(qǐng)諒解。

BASE
鍵值存儲(chǔ)（Key Value Stores）
Dynamo【29】– 這是由亞馬遜工程師們?cè)O(shè)計(jì)的基于鍵值的高可用的分布式存儲(chǔ)系統(tǒng)（注：Dynamo放棄了數(shù)據(jù)建模的能力洲赵，所有的數(shù)據(jù)對(duì)象采用最簡(jiǎn)單的Key-value模型存儲(chǔ)鸳惯，可簡(jiǎn)單地將Dynamo理解為一個(gè)巨大的Map。Dynamo是犧牲了部分一致性叠萍，來(lái)?yè)Q取整個(gè)系統(tǒng)的高可用性）悲敷。

Cassandra【30】 – 這是由Facebook工程師設(shè)計(jì)的一個(gè)離散的分布式結(jié)構(gòu)化存儲(chǔ)系統(tǒng)，受亞馬遜的Dynamo啟發(fā)俭令，Cassandra采用的是面向多維的鍵值或面向列的數(shù)據(jù)存儲(chǔ)格式（注：Cassandra可用來(lái)管理分布在大量廉價(jià)服務(wù)器上的巨量結(jié)構(gòu)化數(shù)據(jù)后德，并同時(shí)提供沒(méi)有單點(diǎn)故障的高可用服務(wù)）。

Voldemort【31】 –這又是一個(gè)受亞馬遜的Dynamo啟發(fā)的分布式存儲(chǔ)作品抄腔，由全球最大的職業(yè)社交網(wǎng)站LinkedIn的工程師們開(kāi)發(fā)而成（注：Voldemort瓢湃，這個(gè)在《哈利·波特》中常被譯作“伏地魔”的開(kāi)源數(shù)據(jù)庫(kù)，支撐起了LinkedIn的多種數(shù)據(jù)分析平臺(tái)）赫蛇。

面向列的存儲(chǔ)（Column Oriented Stores）
BigTable【32】 –這是一篇非常經(jīng)典的學(xué)術(shù)論文绵患，闡述了面向列的分布式的數(shù)據(jù)存儲(chǔ)方案，由谷歌榮譽(yù)出品悟耘。（注：Bigtable是一個(gè)基于Google文件系統(tǒng)的分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)落蝙，是為谷歌打拼天下的“三駕馬車(chē)”之一，另外兩駕馬車(chē)分別是分布式鎖服務(wù)系統(tǒng)Chubby和下文將提到的MapReduce）暂幼。

HBase【33】 –目前還沒(méi)有有關(guān)Hbase的定義性論文筏勒，這里的文獻(xiàn)提供了一個(gè)有關(guān)HBase技術(shù)的概述性文檔（注：Hbase是一個(gè)分布式的、面向列的開(kāi)源數(shù)據(jù)庫(kù)旺嬉。其設(shè)計(jì)理念源自谷歌的 BigTable管行，用Java語(yǔ)言編寫(xiě)而成。文獻(xiàn)【33】是一個(gè)有關(guān)Hbase的幻燈片文檔）邪媳。

Hypertable【34】–文獻(xiàn)是一個(gè)有關(guān)“Hypertable”的技術(shù)白皮書(shū)捐顷，對(duì)該數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)做了較為詳細(xì)的介紹（注：Hypertable也是一個(gè)開(kāi)源、高性能雨效、可伸縮的數(shù)據(jù)庫(kù)迅涮，它采用與Google的Bigtable類(lèi)似的模型）。

面向文檔的存儲(chǔ)（Document Oriented Stores）
CouchDB【35】– 這是一款面向文檔的徽龟、開(kāi)源數(shù)據(jù)存儲(chǔ)管理系統(tǒng)（注：文獻(xiàn)【35】是一本Apache CouchDB的400多頁(yè)的官方文檔）叮姑。

MongoDB【36】 –是目前非常流行的一種非關(guān)系型(NoSQL)數(shù)據(jù)庫(kù)（注：文獻(xiàn)【36】是一個(gè)有關(guān)MongoDB的白皮書(shū)，對(duì)MongoDB結(jié)構(gòu)做了很不錯(cuò)的介紹）顿肺。

面向圖（Graph）的存儲(chǔ)
Neo4j【37】 –文獻(xiàn)是Ian Robinson等撰寫(xiě)的圖書(shū)《Graph Databases（圖數(shù)據(jù)庫(kù)）》（注：Neo4j是一款目前最為流行的高性能NoSQL 圖數(shù)據(jù)庫(kù)戏溺，它使用圖來(lái)描述數(shù)據(jù)模型渣蜗，把數(shù)據(jù)保存為圖中的節(jié)點(diǎn)以及節(jié)點(diǎn)之間的關(guān)系。這是最流行的圖數(shù)據(jù)庫(kù)）旷祸。

Titan【38】 –文獻(xiàn)是有關(guān)Titan的在線文檔（Titan是一款A(yù)pache許可證框架下的分布式的開(kāi)源圖數(shù)據(jù)庫(kù)耕拷，特別為存儲(chǔ)和處理大規(guī)模圖而做了大量?jī)?yōu)化）。

ACID
我注意到托享，現(xiàn)在很多開(kāi)源社區(qū)正在悄悄發(fā)生變化骚烧，它們開(kāi)始“亦步亦趨”地跟隨谷歌的腳步。這也難怪闰围，谷歌太牛赃绊，跟牛人混，近牛者牛 —— 下面4篇文獻(xiàn)羡榴，有3篇來(lái)自于谷歌的“神來(lái)之筆”碧查，他們解決了全球分布一致的數(shù)據(jù)存儲(chǔ)問(wèn)題。

Megastore【39】 –這是一個(gè)構(gòu)建于BigTable之上的校仑、高可用的分布式存儲(chǔ)系統(tǒng)忠售，文獻(xiàn)為有關(guān)Megastore的技術(shù)白皮書(shū)（注：Megastore在被谷歌使用了數(shù)年之后，相關(guān)技術(shù)信息才在2001年公布迄沫。中文解讀：Google Megastore分布式存儲(chǔ)技術(shù)全揭秘）稻扬。

Spanner【40】–這是由谷歌研發(fā)的、可擴(kuò)展的羊瘩、全球分布式的泰佳、同步復(fù)制數(shù)據(jù)庫(kù)，支持SQL查詢(xún)?cè)L問(wèn)尘吗。（注：Spanner的“老爹”是Big Table逝她，可以說(shuō)，沒(méi)有“大表”這個(gè)爹摇予，就不可能有這個(gè)強(qiáng)有力的“扳手” 兒子汽绢。它是第一個(gè)把數(shù)據(jù)分布在全球范圍內(nèi)的系統(tǒng)，并且支持外部一致性的分布式事務(wù)）侧戴。

MESA【41】–亦是由谷歌研發(fā)的、跨地域復(fù)制(geo-replicated)跌宛、高可用的酗宋、可容錯(cuò)的、可擴(kuò)展的近實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)（注：在2014年的VLDB 大會(huì)上疆拘，谷歌公布了他們的分析型數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)MESA蜕猫，該系統(tǒng)主要用于存儲(chǔ)Google互聯(lián)網(wǎng)廣告業(yè)務(wù)相關(guān)的關(guān)鍵衡量數(shù)據(jù)。文獻(xiàn)【41】是VLDB的會(huì)議論文）哎迄。

CockroachDB【42】–該系統(tǒng)是由Google前工程師Spencer Kimball領(lǐng)導(dǎo)開(kāi)發(fā)的Spanner 的開(kāi)源版本（注：這個(gè)項(xiàng)目的綽號(hào)是“螳螂（Cockroach）”回右，其寓意是“活得長(zhǎng)久”隆圆，因?yàn)轶胧堑厍蛏仙ψ顝?qiáng)的生物之一，即使被砍下頭顱翔烁，依然還能存活好幾天渺氧！文獻(xiàn)【42】是代碼托管網(wǎng)站GitHub上對(duì)Cockroach的說(shuō)明性文檔）。

資源管理器層（Resource Managers）
第一代Hadoop的生態(tài)系統(tǒng)蹬屹，其資源管理是以整體單一的調(diào)度器起家的侣背，其代表作品為YARN。而當(dāng)前的調(diào)度器則是朝著分層調(diào)度的方向演進(jìn)（Mesos則是這個(gè)方向的代表作）慨默，這種分層的調(diào)度方式贩耐，可以管理不同類(lèi)型的計(jì)算工作負(fù)載，從而可獲取更高的資源利用率和調(diào)度效率厦取。

YARN【43】– 這是新一代的MapReduce計(jì)算框架潮太，簡(jiǎn)稱(chēng)MRv2，它是在第一代MapReduce的基礎(chǔ)上演變而來(lái)的（注：MRv2的設(shè)計(jì)初衷是虾攻，為了解決第一代Hadoop系統(tǒng)擴(kuò)展性差铡买、不支持多計(jì)算框架等問(wèn)題。這里提供一個(gè)新文獻(xiàn)：由2011年剝離自雅虎的Hadoop初創(chuàng)公司Hortonworks給出的官方文獻(xiàn)【43】new台谢，閱讀該文獻(xiàn)也可對(duì)YARN有較為深入的理解寻狂。

Mesos【44】–這是一個(gè)開(kāi)源的計(jì)算框架，可對(duì)多集群中的資源做彈性管理（注：Mesos誕生于UC Berkeley的一個(gè)研究項(xiàng)目朋沮，現(xiàn)為Apache旗下的一個(gè)開(kāi)源項(xiàng)目蛇券，它是一個(gè)全局資源調(diào)度器。目前Twitter樊拓、 Apple等國(guó)外大公司正在使用Mesos管理集群資源纠亚，國(guó)內(nèi)用戶(hù)有豆瓣等。文獻(xiàn)【44】是加州大學(xué)伯克利分校的研究人員發(fā)表于著名會(huì)議NSDI上的學(xué)術(shù)論文）筋夏。

這些計(jì)算框架和調(diào)度器之間是松散耦合的蒂胞，調(diào)度器的主要功能就是基于一定的調(diào)度策略和調(diào)度配置，完成作業(yè)調(diào)度条篷，以達(dá)到工作負(fù)載均衡骗随，使有限的資源有較高的利用率。

調(diào)度器（Schedulers）
作業(yè)調(diào)度器赴叹，通常以插件的方式加載于計(jì)算框架之上鸿染，常見(jiàn)的作業(yè)調(diào)度器有4種：

計(jì)算能力調(diào)度器【45】（Capacity Scheduler）-該文獻(xiàn)是一個(gè)關(guān)于計(jì)算能力調(diào)度器的指南式文檔，介紹了計(jì)算能力調(diào)度器的不同特性乞巧。

公平調(diào)度器【46】（FairShare Scheduler） -該文獻(xiàn)是Hadoop的公平調(diào)度器設(shè)計(jì)文檔涨椒，介紹了公平調(diào)度的各項(xiàng)特征（注：公平調(diào)度是一種賦予作業(yè)資源的方法，它提供了一個(gè)基于任務(wù)數(shù)的負(fù)載均衡機(jī)制，其目的是讓所有的作業(yè)隨著時(shí)間的推移蚕冬，都能平均的獲取等同的共享資源）免猾。

延遲調(diào)度【47】（Delayed Scheduling） –該文獻(xiàn)是加州大學(xué)伯克利分校的一份技術(shù)報(bào)告，報(bào)告介紹了公平調(diào)度器的延遲調(diào)度策略囤热。

公平與能力調(diào)度器【48】（Fair & Capacity schedulers ）–該文獻(xiàn)是一篇關(guān)于云環(huán)境下的Hadoop調(diào)度器的綜述性論文猎提。

協(xié)調(diào)器（Coordination）
在分布式數(shù)據(jù)系統(tǒng)中，協(xié)調(diào)器主要用于協(xié)調(diào)服務(wù)和進(jìn)行狀態(tài)管理赢乓。
Paxos【49】 –文獻(xiàn)【49】是經(jīng)典論文“The Part-Time Parliament（兼職的議會(huì)）【50】” 的簡(jiǎn)化版忧侧。

注：兩篇文獻(xiàn)的作者均是萊斯利·蘭伯特（Leslie Lamport），此君是個(gè)傳奇人物牌芋，科技論文寫(xiě)作常用編輯器LaTex蚓炬，其中“La”就是來(lái)自其姓“Lamport”的前兩個(gè)字母。Lamport目前是微軟研究院首席研究員躺屁，2013年肯夏，因其在分布式計(jì)算理論領(lǐng)域做出的杰出貢獻(xiàn)，榮獲計(jì)算機(jī)領(lǐng)域最高獎(jiǎng)——圖靈獎(jiǎng)犀暑。

牛人的故事特別多驯击，Lamport亦是這樣。就這兩篇文獻(xiàn)而言耐亏，Lamport的奇聞?shì)W事都值得說(shuō)道說(shuō)道徊都。光看其經(jīng)典論文題目“The Part-Time Parliament（兼職的議會(huì)）【50】”，或許就讓讀者“一頭霧水”广辰，這是一篇計(jì)算機(jī)科學(xué)領(lǐng)域的論文嗎暇矫？和讀者一樣感覺(jué)的可能還有期刊編輯。其實(shí)择吊，早在1990年時(shí)李根，Lamport就提出Paxos算法，他虛構(gòu)了一個(gè)希臘城邦Paxos及其議會(huì)几睛，以此來(lái)形象比喻說(shuō)明該算法的流程房轿。論文投出后，期刊編輯建議Lamport所森，將論文用更加嚴(yán)謹(jǐn)?shù)臄?shù)學(xué)語(yǔ)言重新進(jìn)行描述一下囱持。可Lamport則認(rèn)為焕济，我的幽默洪唐，你不懂！拒絕修改吼蚁。時(shí)隔八年之后的 1998年，Paxos算法才被伯樂(lè)期刊《ACM Transactions on Computer Systems》發(fā)表。由于Paxos算法本身過(guò)于復(fù)雜肝匆，且同行不理解自己的“幽默”粒蜈， 于是，2001年Lamport就用簡(jiǎn)易語(yǔ)言撰寫(xiě)這篇文章旗国，重新發(fā)表了該論文的簡(jiǎn)化版【49】枯怖，即“Paxos made simple（Paxos變得簡(jiǎn)單）”。簡(jiǎn)化版的摘要更簡(jiǎn)單能曾，就一句話：“Paxos算法度硝，用簡(jiǎn)易英語(yǔ)說(shuō)明之，很簡(jiǎn)單”寿冕，如果去掉中間的那個(gè)無(wú)故緊要的定語(yǔ)從句蕊程，就是“Paxos算法，很簡(jiǎn)單”驼唱。弄得你都來(lái)不及做深思狀藻茂，摘要就完了。這…玫恳，這…辨赐，完全顛覆了我們常用的“三段論式（提問(wèn)題、解問(wèn)題京办、給結(jié)論）”的論文摘要寫(xiě)法啊掀序。

后來(lái)，隨著分布式系統(tǒng)的不斷發(fā)展壯大惭婿，Paxos算法開(kāi)始大顯神威不恭。Google的Chubby和Apache的Zookeeper，都是用Paxos作為其理論基礎(chǔ)實(shí)現(xiàn)的审孽。就這樣县袱， Paxos終于登上大雅之堂，它也為L(zhǎng)amport在2013年獲得圖靈獎(jiǎng)佑力，立下汗馬功勞式散。從Lamport發(fā)表Paxos算法的小案例，我們可以看出：彪悍的人生打颤，不需要解釋暴拄。牛逼的論文，就可以任性编饺！

Chubby【51】– 該文獻(xiàn)的作者是谷歌工程師Mike Burrows乖篷。Chubby系統(tǒng)本質(zhì)上就是前文提到的Paxos的一個(gè)實(shí)現(xiàn)版本，主要用于谷歌分布式鎖服務(wù)透且。

Zookeeper【52】 –這是Apache Hadoop框架下的Chubby開(kāi)源版本撕蔼。它不僅僅提供簡(jiǎn)單地上鎖服務(wù)豁鲤，而事實(shí)上，它還是一個(gè)通用的分布式協(xié)調(diào)器鲸沮，其設(shè)計(jì)靈感來(lái)自谷歌的Chubby（注：眾所周知琳骡，分布式協(xié)調(diào)服務(wù)開(kāi)發(fā)困難很大，分布式系統(tǒng)中的多進(jìn)程間很容易發(fā)生條件競(jìng)爭(zhēng)和死鎖讼溺。ZooKeeper的開(kāi)發(fā)動(dòng)力就是減輕分布式應(yīng)用開(kāi)發(fā)的困難楣号，使用戶(hù)不必從零開(kāi)始構(gòu)建協(xié)調(diào)服務(wù)）。

計(jì)算框架（Computational Frameworks）
運(yùn)行時(shí)計(jì)算框架怒坯，可為不同種類(lèi)的計(jì)算炫狱，提供運(yùn)行時(shí)（runtime）環(huán)境。最常用的是運(yùn)行時(shí)計(jì)算框架是Spark和Flink剔猿。

Spark【53】 –因Spark日益普及视译，加之其具備良好的多計(jì)算環(huán)境的適用性，它已對(duì)傳統(tǒng)的Hadoop生態(tài)環(huán)境艳馒，形成了嚴(yán)峻的挑戰(zhàn)（注：Spark是一個(gè)基于內(nèi)存計(jì)算的開(kāi)源的集群計(jì)算系統(tǒng)憎亚，其目的在于，讓數(shù)據(jù)分析更加快速弄慰。Spark是由加州大學(xué)伯克利分校的AMP實(shí)驗(yàn)室采用Scala語(yǔ)言開(kāi)發(fā)而成第美。Spark的內(nèi)存計(jì)算框架，適合各種迭代算法和交互式數(shù)據(jù)分析陆爽，能夠提升大數(shù)據(jù)處理的實(shí)時(shí)性和準(zhǔn)確性什往，現(xiàn)已逐漸獲得很多企業(yè)的支持，如阿里巴巴慌闭、百度别威、網(wǎng)易、英特爾等公司均是其用戶(hù)）驴剔。

Flink【54】 –這是一個(gè)非常類(lèi)似于Spark的計(jì)算框架省古，但在迭代式數(shù)據(jù)處理上，比Spark更給力（注：目前大數(shù)據(jù)分析引擎Flink丧失，已升級(jí)成為Apache頂級(jí)項(xiàng)目）豺妓。
Spark和Flink都屬于基礎(chǔ)性的大數(shù)據(jù)處理引擎。具體的計(jì)算框架布讹，大體上琳拭，可根據(jù)采用的模型及延遲的處理不同，來(lái)進(jìn)行分門(mén)別類(lèi)描验。

批處理（Batch）
MapReduce【55】– 這是谷歌有關(guān)MapReduce的最早的學(xué)術(shù)論文白嘁。

MapReduce綜述【56】 –這是一篇過(guò)時(shí)、但依然值得一讀的膘流、有關(guān)MapReduce計(jì)算框架的綜述性文章絮缅。

迭代式（BSP）
Pregel【57】–這又是一篇谷歌出品的大手筆論文鲁沥，主要描述了大規(guī)模圖處理方法（注：Pregel是一種面向圖算法的分布式編程框架，其采用的是迭代式的計(jì)算模型盟蚣。它被稱(chēng)之為Google后Hadoop時(shí)代的新“三駕馬車(chē)”之一黍析。另外兩駕馬車(chē)分別是：“交互式”大數(shù)據(jù)分析系統(tǒng)Dremel和網(wǎng)絡(luò)搜索引擎Caffeine）。

Giraph【58】 – 該系統(tǒng)建模于谷歌的Pregel屎开，可視為Pregel的開(kāi)源版本，它是一個(gè)基于 Hadoop架構(gòu)的马靠、可擴(kuò)展的分布式迭代圖處理系統(tǒng)奄抽。

GraphX【59】 –這是一個(gè)同時(shí)采用圖并行計(jì)算和數(shù)據(jù)并行的計(jì)算框架（注：GraphX最先是加州大學(xué)伯克利分校AMPLab實(shí)驗(yàn)室的一個(gè)分布式圖計(jì)算框架項(xiàng)目，后來(lái)整合到Spark中甩鳄，成為其中的一個(gè)核心組件逞度。GraphX最大的貢獻(xiàn)在于，在Spark之上提供一棧式數(shù)據(jù)解決方案妙啃，可方便高效地完成圖計(jì)算的一整套流水作業(yè)）档泽。

Hama【60】– 是一個(gè)構(gòu)建Hadoop之上的基于BSP模型的分布式計(jì)算引擎（注：Hama的運(yùn)行環(huán)境需要關(guān)聯(lián) Zookeeper、HBase揖赴、HDFS 組件馆匿。Hama中最關(guān)鍵的技術(shù)，就是采用了BSP模型(Bulk Synchronous Parallel燥滑，即整體同步并行計(jì)算模型渐北，又名大同步模型)。BSP模型是哈佛大學(xué)的計(jì)算機(jī)科學(xué)家Viliant和牛津大學(xué)的BillMcColl在1990年聯(lián)合提出的铭拧，他們希望能像馮·諾伊曼體系結(jié)構(gòu)那樣赃蛛，架起計(jì)算機(jī)程序語(yǔ)言和體系結(jié)構(gòu)間的橋梁，故又稱(chēng)作橋模型(Bridge Model)搀菩。

開(kāi)源圖處理系統(tǒng)【61】（Open source graph processing ）-這是滑鐵盧大學(xué)的研究人員撰寫(xiě)的綜述性文獻(xiàn)呕臂，文獻(xiàn)【61】對(duì)類(lèi)Pregel（Pregel-like）的、基于BSP模型的圖處理系統(tǒng)進(jìn)行了實(shí)驗(yàn)性的比較肪跋。

流式（Streaming）
流式處理【62】（Stream Processing）- 這是一篇非常棒的歧蒋、有關(guān)面向大數(shù)據(jù)實(shí)時(shí)處理系統(tǒng)的綜述性文章。

Storm【63】 – 這是一個(gè)大數(shù)據(jù)實(shí)時(shí)處理系統(tǒng)（注：Storm有時(shí)也被人們稱(chēng)為實(shí)時(shí)處理領(lǐng)域的Hadoop澎嚣，它大大簡(jiǎn)化了面向龐大規(guī)模數(shù)據(jù)流的處理機(jī)制疏尿，從而在實(shí)時(shí)處理領(lǐng)域扮演著重要角色。文獻(xiàn)【63】是Twitter工程師們?cè)?014年發(fā)表于SIGMOD上的學(xué)術(shù)論文）易桃。

Samza【64】 -這是一款由Linkedin公司開(kāi)發(fā)的分布式的流式數(shù)據(jù)處理框架（注：所謂流式數(shù)據(jù)褥琐，是指要在處理單位內(nèi)得到的數(shù)據(jù)，這種方式更注重于實(shí)時(shí)性晤郑，流式數(shù)據(jù)有時(shí)也稱(chēng)為快數(shù)據(jù)）敌呈。

Spark流【65】（Spark Streaming） -該文獻(xiàn)是加州大學(xué)伯克利分校的研究人員于2013年在著名操作系統(tǒng)會(huì)議SOSP上發(fā)表的學(xué)術(shù)論文贸宏，論文題目是《離散流：容錯(cuò)大規(guī)模流式計(jì)算》（注：這里的離散流是指一種微批處理構(gòu)架，其橋接了傳統(tǒng)的批處理和交互式處理磕洪。Spark Streaming是Spark 核心API的一個(gè)擴(kuò)展吭练，它并不會(huì)像Storm那樣逐個(gè)處理數(shù)據(jù)流，而是在處理前析显，按時(shí)間間隔預(yù)先將其切分為很多小段的批處理作業(yè)）鲫咽。

交互式（Interactive）
Dremel【66】–這又是一篇由谷歌出品的經(jīng)典論文，論文描述了如何處理“交互式”大數(shù)據(jù)的工作負(fù)載谷异。該論文是多個(gè)基于Hadoop的開(kāi)源SQL系統(tǒng)的理論基礎(chǔ)（注：文獻(xiàn)【66】寫(xiě)于2006年分尸，“捂”藏4年之后，于2010年公布于眾歹嘹。文章針對(duì)MR交互式查詢(xún)能力不足箩绍，提出了Dremel，闡述了Dremel的設(shè)計(jì)原理尺上，并提供了部分測(cè)試報(bào)告）材蛛。

Impala【67】 –這是一個(gè)大規(guī)模并行處理（MPP）式 SQL 大數(shù)據(jù)分析引擎（注：Impala像Dremel一樣，其借鑒了MPP（Massively Parallel Processing怎抛，大規(guī)模并行處理）并行數(shù)據(jù)庫(kù)的思想卑吭，拋棄了MapReduce這個(gè)不太適合做SQL查詢(xún)的范式，從而讓Hadoop支持處理交互式的工作負(fù)載抽诉。本文作者阿尼爾?馬丹在LinkedIn上的博客原文陨簇，在此處的“MPI”系“MPP”筆誤，讀者可參閱文獻(xiàn)【67】發(fā)現(xiàn)此問(wèn)題）迹淌。

Drill【68】–這是谷歌 Dremel的開(kāi)源版本（注：Drill是一個(gè)低延遲的河绽、能對(duì)海量數(shù)據(jù)（包括結(jié)構(gòu)化、半結(jié)構(gòu)化及嵌套數(shù)據(jù)）實(shí)施交互式查詢(xún)的分布式數(shù)據(jù)引擎）唉窃。

Shark【69】 –該文獻(xiàn)是2012年發(fā)表于SIGMOD的一篇學(xué)術(shù)論文耙饰，論文對(duì)Spark生態(tài)系統(tǒng)上的數(shù)據(jù)分析能力，給出了很深入的介紹（注：Shark是由加州伯克利大學(xué)AMPLab開(kāi)發(fā)的大數(shù)據(jù)分析系統(tǒng)纹份。Shark即“Hive on Spark”的含義儿普，本質(zhì)上是通過(guò)Hive的HQL解析背镇，把HQL翻譯成Spark上的RDD操作尘应。然后通過(guò)Hive的元數(shù)據(jù)獲上渴，取數(shù)據(jù)庫(kù)里的表信息。HDFS上的數(shù)據(jù)和文件元暴，最后會(huì)由Shark獲取篷扩，并放到Spark上運(yùn)算。Shark基于 Scala語(yǔ)言的算子推導(dǎo)茉盏，可實(shí)現(xiàn)良好的容錯(cuò)機(jī)制鉴未，對(duì)執(zhí)行失敗的長(zhǎng)/短任務(wù)枢冤，均能從上一個(gè)“快照點(diǎn)（Snapshot）”進(jìn)行快速恢復(fù)）。

Shark【70】–這是另外一篇很棒的于2013年發(fā)表在SIGMOD的學(xué)術(shù)論文铜秆，其深度解讀在Apache Hive之上SQL訪問(wèn)機(jī)制（注：這篇文獻(xiàn)描述了如何構(gòu)建在Spark上構(gòu)建SQL引擎——Shark淹真。更重要的是，文章還討論了之前在 Hadoop/MapReduce上實(shí)施SQL查詢(xún)?nèi)绱酥脑颍?/p>

Dryad【71】– 文獻(xiàn)討論了使用有向無(wú)環(huán)圖(Directed Acycline Graph连茧，DAG)來(lái)配置和執(zhí)行并行數(shù)據(jù)流水線的方法（注：Dryad是一個(gè)通用的粗顆粒度的分布式計(jì)算和資源調(diào)度引擎核蘸，其核心特性之一，就是允許用戶(hù)自己構(gòu)建DAG調(diào)度拓?fù)鋱D梅屉。文獻(xiàn)【71】是微軟于2007年在EuroSys國(guó)際會(huì)議上發(fā)布的學(xué)術(shù)論文）值纱。

Tez【72】 –其核心思想來(lái)源于Dryad，可視為利用Yarn(即MRv2)對(duì)Dryad的開(kāi)源實(shí)現(xiàn)（注：Apache Tez是基于Hadoop Yarn之上的DAG計(jì)算框架坯汤。由Hadoop的二東家Hortonworks開(kāi)發(fā)并提供主要技術(shù)支持。文獻(xiàn)【72】是一個(gè)關(guān)于Tez的簡(jiǎn)要介紹文檔）搀愧。

BlinkDB【73】–可在抽樣數(shù)據(jù)上實(shí)現(xiàn)交互式查詢(xún)惰聂，其呈現(xiàn)出的查詢(xún)結(jié)果，附帶有誤差標(biāo)識(shí)咱筛。（注：BlinkDB 是一個(gè)用于在海量數(shù)據(jù)上運(yùn)行交互式 SQL 查詢(xún)的大規(guī)模并行查詢(xún)引擎搓幌。BlinkDB允許用戶(hù)通過(guò)適當(dāng)降低數(shù)據(jù)精度，對(duì)數(shù)據(jù)進(jìn)行先采樣后計(jì)算迅箩，其通過(guò)其獨(dú)特的優(yōu)化技術(shù)溉愁，實(shí)現(xiàn)了比Hive快百倍的交互式查詢(xún)速度，而查詢(xún)進(jìn)度誤差僅降低2~10%饲趋。
BlinkDB采用的策略拐揭，與大數(shù)據(jù)布道師，維克托·邁爾-舍恩伯格在其著作《大數(shù)據(jù)時(shí)代》中提到的觀點(diǎn)奕塑，“要全體堂污，不要抽樣”，恰恰相反龄砰。

基于常識(shí)盟猖，我們知道：多了，你就快不了换棚。好了式镐，你就省不了。對(duì)大數(shù)據(jù)處理而言固蚤，也是這樣娘汞。英特爾中國(guó)研究院院長(zhǎng)吳甘沙認(rèn)為，大體量颇蜡、精確性和速度快价说，三者不可兼得辆亏，頂多取其二。如果要實(shí)現(xiàn)在大體量數(shù)據(jù)上的 “快”鳖目，就得想辦法減少數(shù)據(jù)扮叨，而減少數(shù)據(jù)，勢(shì)必要適度地降低分析精確性领迈。

事實(shí)上彻磁，大數(shù)據(jù)并不見(jiàn)得越“大”越好，有時(shí)候一味的追求“大”是沒(méi)有必要的狸捅。例如衷蜓，在醫(yī)療健康領(lǐng)域，如果來(lái)監(jiān)控某個(gè)病人的體溫尘喝，可穿戴設(shè)備可以一秒鐘采集一次數(shù)據(jù)磁浇，也可以一分鐘采集一次數(shù)據(jù)，前者采集的數(shù)據(jù)總量比后者“大”60倍朽褪，但就監(jiān)控病人身體狀況而言置吓，意義并不是太大。雖然后者的數(shù)據(jù)忽略了人體在一分鐘內(nèi)的變化缔赠，監(jiān)控的精度有所下降衍锚，但對(duì)于完成監(jiān)控病人健康狀態(tài)這一目的而言，是可以接受的嗤堰。）

實(shí)時(shí)系統(tǒng)（RealTime）
Druid【74】 –這是一個(gè)開(kāi)源的分布式實(shí)時(shí)數(shù)據(jù)分析和存儲(chǔ)系統(tǒng)戴质，旨在快速處理大規(guī)模的數(shù)據(jù)，并能做到快速查詢(xún)和分析（注：文獻(xiàn)【74】是2014年Druid創(chuàng)始人Eric Tschetter和中國(guó)工程師楊仿今等人在SIGMOD上發(fā)表的一篇論文）踢匣。

Pinot【75】 –這是由LinkedIn公司出品的一個(gè)開(kāi)源的告匠、實(shí)時(shí)分布式的 OLAP數(shù)據(jù)分析存儲(chǔ)系統(tǒng)，非常類(lèi)似于前面提到的Druid符糊，LinkedIn 使用它實(shí)現(xiàn)低延遲可伸縮的實(shí)時(shí)分析凫海。（注：文獻(xiàn)【75】是在GitHub上的有關(guān)Pinot的說(shuō)明性文檔）。

數(shù)據(jù)分析層（Data Analysis）
數(shù)據(jù)分析層中的工具男娄，涵蓋范圍很廣行贪，從諸如SQL的聲明式編程語(yǔ)言，到諸如Pig的過(guò)程化編程語(yǔ)言模闲，均有涉及建瘫。另一方面，數(shù)據(jù)分析層中的庫(kù)也很豐富尸折，可支持常見(jiàn)的數(shù)據(jù)挖掘和機(jī)器學(xué)習(xí)算法啰脚，這些類(lèi)庫(kù)可拿來(lái)即用，甚是方便。

工具（Tools）
Pig【76】 –這是一篇有關(guān)Pig Latin非常不錯(cuò)的綜述文章（注：Pig Latin原是一種兒童黑話橄浓，屬于是一種英語(yǔ)語(yǔ)言游戲粒梦，形式是在英語(yǔ)上加上一點(diǎn)規(guī)則使發(fā)音改變，讓大人們聽(tīng)不懂荸实，從而完成孩子們獨(dú)懂的交流匀们。文獻(xiàn)【76】是雅虎的工程師們于2008年發(fā)表在SIGMOD的一篇論文，論文的題目是“Pig Latin：并不是太老外的一種數(shù)據(jù)語(yǔ)言”准给，言外之意泄朴，他們發(fā)明了一種數(shù)據(jù)處理的“黑話”——Pig Latin，一開(kāi)始你可能不懂露氮，等你熟悉了祖灰，就會(huì)發(fā)現(xiàn)這種數(shù)據(jù)查詢(xún)語(yǔ)言的樂(lè)趣所在）。

Pig【77】 – 這是另外一篇由雅虎工程師們撰寫(xiě)的有關(guān)使用Pig經(jīng)驗(yàn)的論文畔规，文章介紹了如果利用Pig在Map-Reduce上構(gòu)建一個(gè)高水準(zhǔn)的數(shù)據(jù)流分析系統(tǒng)局扶。

Hive【78】 –該文獻(xiàn)是Facebook數(shù)據(jù)基礎(chǔ)設(shè)施研究小組撰寫(xiě)的一篇學(xué)術(shù)論文，介紹了Hive的來(lái)龍去脈（注：Hive是一個(gè)建立于 Hadoop 上的數(shù)據(jù)倉(cāng)庫(kù)基礎(chǔ)構(gòu)架叁扫。它用來(lái)進(jìn)行數(shù)據(jù)的提取详民、轉(zhuǎn)化和加載（即Extract-Transform-Load ，ETL）陌兑，它是一種可以存儲(chǔ)、查詢(xún)和分析存儲(chǔ)在 Hadoop 中的大規(guī)模數(shù)據(jù)的機(jī)制）由捎。

Hive【79】–該文獻(xiàn)是另外一篇有關(guān)Hive的值得一讀的好論文兔综。論文作者來(lái)自Facebook數(shù)據(jù)基礎(chǔ)設(shè)施研究小組，在這篇論文里狞玛，可以幫助讀者理解Hive的設(shè)計(jì)理念软驰。

Phoenix【80】 –它是 HBase 的 SQL 驅(qū)動(dòng)（注：Phoenix可將 SQL 查詢(xún)轉(zhuǎn)成 HBase 的掃描及相應(yīng)的動(dòng)作。文獻(xiàn)【80】是關(guān)于在Hbase上部署SQL的幻燈片文檔）心肪。

Map Reduce上的連接（join）算法【81】–該文獻(xiàn)介紹了在Hadoop環(huán)境下的各種并行連接算法锭亏，并對(duì)它們的性能作出系統(tǒng)性評(píng)測(cè)。

Map Reduce上的連接算法【82】 –這是威斯康星大學(xué)和IBM研究團(tuán)隊(duì)撰寫(xiě)的綜述性文章硬鞍，文章對(duì)在Map Reduce模型下的各種連接算法進(jìn)行了綜合比較慧瘤。

庫(kù)（Libraires）
MLlib【83】–這是在Spark計(jì)算框架中對(duì)常用的機(jī)器學(xué)習(xí)算法的實(shí)現(xiàn)庫(kù)，該庫(kù)還包括相關(guān)的測(cè)試和數(shù)據(jù)生成器（注：文獻(xiàn)【83】是MLlib的一個(gè)幻燈片說(shuō)明文檔）固该。

SparkR【84】–這是AMPLab發(fā)布的一個(gè)R開(kāi)發(fā)包锅减，為Apache Spark提供輕量級(jí)的前端（注：R是一種廣泛應(yīng)用于統(tǒng)計(jì)分析、繪圖的語(yǔ)言及操作環(huán)境伐坏。文獻(xiàn)【84】是有關(guān)SparkR的幻燈片文檔）怔匣。

Mahout【85】 –這是一個(gè)功能強(qiáng)大的數(shù)據(jù)挖掘工具，是一個(gè)基于傳統(tǒng)Map Reduce的分布式機(jī)器學(xué)習(xí)框架（注：Mahout的中文含義就是“馭象之人”桦沉，而Hadoop的Logo正是一頭小黃象每瞒。很明顯金闽，這個(gè)庫(kù)是幫助用戶(hù)用好Hadoop這頭難用的大象。文獻(xiàn)【85】是有關(guān)Mahout的圖書(shū)）剿骨。

數(shù)據(jù)集成層（Data Integration）
數(shù)據(jù)集成框架提供了良好的機(jī)制代芜，以協(xié)助高效地?cái)z取和輸出大數(shù)據(jù)系統(tǒng)之間的數(shù)據(jù)。從業(yè)務(wù)流程線到元數(shù)據(jù)框架懦砂，數(shù)據(jù)集成層皆有涵蓋蜒犯，從而提供全方位的數(shù)據(jù)在整個(gè)生命周期的管理和治理。

攝入/消息傳遞（Ingest/Messaging）
Flume【86】 –這是Apache旗下的一個(gè)分布式的荞膘、高可靠的罚随、高可用的服務(wù)框架，可協(xié)助從分散式或集中式數(shù)據(jù)源采集羽资、聚合和傳輸海量日志（注：文獻(xiàn)【86】是Apache網(wǎng)站上有關(guān)Flume的一篇博客文章）淘菩。

Sqoop【87】–該系統(tǒng)主要用來(lái)在Hadoop和關(guān)系數(shù)據(jù)庫(kù)中傳遞數(shù)據(jù)（注：Sqoop目前已成為Apache的頂級(jí)項(xiàng)目之一。通過(guò)Sqoop屠升，可以方便地將數(shù)據(jù)從關(guān)系數(shù)據(jù)庫(kù)導(dǎo)入到HDFS潮改，或反之亦可。文獻(xiàn)【87】是有關(guān)Sqoop的幻燈片說(shuō)明文檔）腹暖。

Kafka【88】 –這是由LinkedIn開(kāi)發(fā)的一個(gè)分布式消息系統(tǒng)（注：由Scala編寫(xiě)而成的Kafka汇在，由于可水平擴(kuò)展、吞吐率高等特性脏答，得到廣泛應(yīng)用糕殉。文獻(xiàn)【88】是LindedIn的工程師們?cè)?011年發(fā)表于NetDB的會(huì)議論文）。

ETL/工作流
ETL是數(shù)據(jù)抽戎掣妗（Extract）阿蝶、清洗（Cleaning）、轉(zhuǎn)換（Transform）黄绩、裝載（Load）的過(guò)程羡洁，是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)的重要一環(huán)。

Crunch【89】–這是Apache旗下的一套Java API函數(shù)庫(kù)爽丹，它能夠大大簡(jiǎn)化編寫(xiě)筑煮、測(cè)試、運(yùn)行MapReduce 處理工作流的程序（注：文獻(xiàn)【89】是有關(guān)Crunch的幻燈片解釋文檔）习劫。

Falcon【90】– 這是Apache旗下的Falcon大數(shù)據(jù)管理框架咆瘟，可以幫助用戶(hù)自動(dòng)遷移和處理大數(shù)據(jù)集合（注：文獻(xiàn)【90】是一份關(guān)于Falcon技術(shù)預(yù)覽報(bào)告）。

Cascading【91】 –這是一個(gè)架構(gòu)在Hadoop上的API函數(shù)庫(kù)诽里，用來(lái)創(chuàng)建復(fù)雜的可容錯(cuò)的數(shù)據(jù)處理工作流（注：文獻(xiàn)【91】是關(guān)于Hadoop上的Cascading的概論和技術(shù)隨筆）袒餐。

Oozie【92】–是一個(gè)工作流引擎，用來(lái)協(xié)助Hadoop作業(yè)管理（注：Oozie字面含義是馴象之人，其寓意和Mahout一樣灸眼，幫助用戶(hù)更好地搞定Hadoop這頭大象卧檐。文獻(xiàn)【92】是Apache網(wǎng)站上有關(guān)Oozie的官方文檔）。

元數(shù)據(jù)（Metadata）
HCatalog【93】– 它提供了面向Apache Hadoop的數(shù)據(jù)表和存儲(chǔ)管理服務(wù)（注：Apache HCatalog提供一個(gè)共享的模式和數(shù)據(jù)類(lèi)型的機(jī)制焰宣，它抽象出表霉囚，使用戶(hù)不必關(guān)心數(shù)據(jù)怎么存儲(chǔ)，并提供了可操作的跨數(shù)據(jù)處理工具匕积。文獻(xiàn)【93】是Apache網(wǎng)站有關(guān)Hcatalog的官方說(shuō)明文檔）盈罐。

序列化（Serialization）
Protocol Buffers【94】 –由Google推廣的一種與語(yǔ)言無(wú)關(guān)的、對(duì)結(jié)構(gòu)化數(shù)據(jù)進(jìn)行序列化和反序列化的機(jī)制（注：Protocol Buffers可用于通訊協(xié)議闪唆、數(shù)據(jù)存儲(chǔ)等領(lǐng)域的語(yǔ)言及平臺(tái)無(wú)關(guān)盅粪、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)格式。文獻(xiàn)【94】是有關(guān)Protocol Buffers幻燈片文檔）悄蕾。

Avro【95】 –這是一個(gè)建模于Protocol Buffers之上的票顾、Hadoop生態(tài)系統(tǒng)中的子項(xiàng)目（注：Avro本身既是一個(gè)序列化框架，同時(shí)也實(shí)現(xiàn)了RPC的功能）帆调。
操作框架（Operational Frameworks）
最后奠骄，我們還需要一個(gè)操作性框架，來(lái)構(gòu)建一套衡量標(biāo)準(zhǔn)和測(cè)試基準(zhǔn)番刊，從而來(lái)評(píng)價(jià)各種計(jì)算框架的性能優(yōu)劣含鳞。在這個(gè)操作性框架中，還需要包括性能優(yōu)化工具芹务，借助它來(lái)平衡工作負(fù)載民晒。

監(jiān)測(cè)管理框架（Monitoring Frameworks）
OpenTSDB【96】 –這是構(gòu)建于HBase之上的實(shí)時(shí)性能評(píng)測(cè)系統(tǒng)（注：文獻(xiàn)【96】提供了OpenTSDB的簡(jiǎn)要概述，介紹了OpenTSDB的工作機(jī)理）锄禽。

Ambari【97】– 這是一款基于Web的系統(tǒng)，支持Apache Hadoop集群的供應(yīng)靴姿、管理和監(jiān)控（注：文獻(xiàn)【97】闡述了Ambari架構(gòu)的設(shè)計(jì)準(zhǔn)則）沃但。

基準(zhǔn)測(cè)試（Benchmarking）
YCSB【98】 –該文獻(xiàn)是一篇使用YCSB對(duì)NoSQL系統(tǒng)進(jìn)行性能評(píng)估的期刊論文（注：YCSB是雅虎云服務(wù)基準(zhǔn)測(cè)試（Yahoo! Cloud Serving Benchmark）的簡(jiǎn)寫(xiě)。見(jiàn)名知意佛吓，它是由雅虎出品的一款通用云服務(wù)性能測(cè)試工具）宵晚。

GridMix【99】 –該系統(tǒng)通過(guò)運(yùn)行大量合成的作業(yè)，對(duì)Hadoop系統(tǒng)進(jìn)行基準(zhǔn)測(cè)試维雇，從而獲得性能評(píng)價(jià)指標(biāo)（注：文獻(xiàn)是Apache網(wǎng)站有關(guān)GridMix的官方說(shuō)明文檔）淤刃。

最后一篇文獻(xiàn)是有關(guān)大數(shù)據(jù)基準(zhǔn)測(cè)試的綜述文章【100】，文章討論了基準(zhǔn)測(cè)試的最新技術(shù)進(jìn)展以及所面臨的幾個(gè)主要挑戰(zhàn)吱型。
更多請(qǐng)關(guān)注原文：https://www.linkedin.com/pulse/100-open-source-big-data-architecture-papers-anil-madan
寄語(yǔ)：
在你邁步于大數(shù)據(jù)的旅途中逸贾，真心希望這些文獻(xiàn)能助你一臂之力。但要知道，有關(guān)大數(shù)據(jù)的文獻(xiàn)铝侵，何止千萬(wàn)灼伤，由于個(gè)人精力、能力有限咪鲜，有些領(lǐng)域也不甚熟稔狐赡，故難免會(huì)掛一漏萬(wàn)。如有疏忽疟丙，漏掉你的大作颖侄，還請(qǐng)你海涵。最后享郊，希望這些文獻(xiàn)能給你帶來(lái)“學(xué)而時(shí)習(xí)之览祖，不亦樂(lè)乎”的快感！