作者：Anil Madan** 譯者：張玉宏 文源：LinkeDin 轉(zhuǎn)自：CSDN**
PayPal高級工程總監(jiān)Anil Madan寫了篇大數(shù)據(jù)的文章，近日CSDN對此進行了翻譯茫陆。一共有100篇大數(shù)據(jù)的論文缔恳，涵蓋大數(shù)據(jù)技術(shù)棧具练，全部讀懂你將會是大數(shù)據(jù)的頂級高手狼荞。
開源（Open Source）用之于大數(shù)據(jù)技術(shù)派哲，其作用有二：一方面偎血，在大數(shù)據(jù)技術(shù)變革之路上，開源在眾人之力和眾人之智推動下雕沉，摧枯拉朽集乔，吐故納新，扮演著非常重要的推動作用坡椒。另一方面扰路，開源也給大數(shù)據(jù)技術(shù)構(gòu)建了一個異常復(fù)雜的生態(tài)系統(tǒng)。每一天肠牲，都有一大堆“新”框架幼衰、“新”類庫或“新”工具靴跛，猶如雨后春筍般涌出缀雳，亂花漸欲“迷”人眼。為了掌控住這些“新玩意”梢睛，數(shù)據(jù)分析的達人們不得不“殫精竭慮”地“學而時習之”肥印。
無論你是一個大數(shù)據(jù)的布道者，還是一個日臻成熟的技術(shù)派绝葡，亦或你還在大數(shù)據(jù)這條路上“小荷才露尖尖角”深碱，多花點時間，深入理解一下大數(shù)據(jù)系統(tǒng)的技術(shù)體系演進藏畅，對你都會有莫大益處敷硅。全方位地理解大數(shù)據(jù)體系結(jié)構(gòu)中的各個組件，并掌握它們之間的微妙差別愉阎，可在處理自己身邊的大數(shù)據(jù)案例時绞蹦，助你張弛有度，“恢恢乎榜旦，其于游刃必有余地矣!”
在過去的幾年里幽七，我閱讀了很多不錯的大數(shù)據(jù)文獻，這些文獻陪我成長溅呢，助我成功澡屡，使我成為一個具備良好教育背景的大數(shù)據(jù)專業(yè)人士。在這里咐旧，撰寫此文的目的驶鹉，不限于僅僅和大家分享這些很不錯的文獻，更重要的是铣墨，借此機會室埋，想和大家一起，集眾人之智慧，破解大數(shù)據(jù)開源系統(tǒng)之迷宮词顾。
需要提醒的是八秃，下文提及到的100篇參考文獻（這些文獻中大多都是一些開創(chuàng)性的研究論文），將會為你提供結(jié)構(gòu)性的深度剖析肉盹，絕非泛泛而談昔驱。我相信，這可從根本上幫助你深度理解大數(shù)據(jù)體系組件間的細微差別上忍。但如果你打算“走馬觀花”般地快速過一遍骤肛，了解大數(shù)據(jù)為何物，對不起窍蓝，這里可能會讓你失望腋颠。
那么，準備好了嗎吓笙？讓我們走起淑玫！
在介紹這100篇文獻之前，首先讓我們看一下大數(shù)據(jù)處理的關(guān)鍵架構(gòu)層（如圖1所示）：
關(guān)鍵架構(gòu)層
** 圖1：大數(shù)據(jù)處理的關(guān)鍵架構(gòu)層**
文件系統(tǒng)層：在這一層里面睛，分布式文件系統(tǒng)需具備存儲管理絮蒿、容錯處理、高可擴展性叁鉴、高可靠性和高可用性等特性土涝。
數(shù)據(jù)存儲層：由于目前采集到的數(shù)據(jù)，十之有七八為非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)幌墓，數(shù)據(jù)的表現(xiàn)形式各異但壮，有文本的、圖像的常侣、音頻的蜡饵、視頻的等，因此常見的數(shù)據(jù)存儲也要對應(yīng)有多種形式袭祟，有基于鍵值（Key-Value）的验残，有基于文檔（Document），還有基于列（Column）和圖表（Graph）的巾乳。如果采用單一的數(shù)據(jù)庫引擎您没，“一刀切式”的滿足所有類型的數(shù)據(jù)存儲需求，通常會嚴重降低數(shù)據(jù)庫管理的性能胆绊。因此氨鹏，我們需要“兵來將擋，水來土掩”式的压状、多元的（Polyglot）【1】數(shù)據(jù)庫解決方案（這就好比仆抵，如果“兵來了”和“水來了”跟继，都要“將”去擋，遇到“兵”時镣丑，“將”可以“酣暢淋漓”舔糖，而遇到“水”時，還用“將”去擋莺匠，那這個“將”估計就要“舍生取義”了金吗。文獻【1】是一本有關(guān)NoSQL數(shù)據(jù)處理的圖書）
資源管理層：這一層是為了提高資源的高利用率和吞吐量，以到達高效的資源管理與調(diào)度目的趣竣。
資源協(xié)調(diào)層： 在本層的系統(tǒng)摇庙，需要完成對資源的狀態(tài)、分布式協(xié)調(diào)遥缕、一致性和資源鎖實施管理卫袒。
計算框架層：在本層的計算框架非常龐雜，有很多高度專用的框架包含其內(nèi)单匣，有流式的夕凝，交互式的，實時的封孙，批處理和迭代圖的（Batch and Iterative Graph迹冤，BSP）等讽营。為這些計算框架提供支撐的是運行時引擎虎忌，如BDAS【2】(Spark) 和Flink等（注：這里的BDAS是指“Berkeley Data Analytics Stack”，即伯克利數(shù)據(jù)分析棧橱鹏。文獻【2】為Spark核心作者Ion Stoica的講座幻燈片文檔）膜蠢。
數(shù)據(jù)分析層：在這一層里，主要包括數(shù)據(jù)分析(消費)工具和一些數(shù)據(jù)處理函數(shù)庫莉兰。這些工具和函數(shù)庫挑围，可提供描述性的、預(yù)測性的或統(tǒng)計性的數(shù)據(jù)分析功能及機器學習模塊糖荒。
數(shù)據(jù)集成層：在這一層里杉辙，不僅包括管理數(shù)據(jù)分析工作流中用到的各種適用工具，除此之外捶朵，還包括對元數(shù)據(jù)（Metadata）管理的工具蜘矢。
操作框架層：這一層提供可擴展的性能監(jiān)測管理和基準測試框架。
架構(gòu)的演進
減少數(shù)據(jù)生產(chǎn)者和消費者之間的處理延遲综看，一直是現(xiàn)代計算構(gòu)架不斷演進的主要動力品腹。由此，誕生了實時和低延遲處理的計算構(gòu)架红碑，如Lambda和Kappa等舞吭，這類混合架構(gòu)取長補短，架起傳統(tǒng)的批處理層和交互式層之間連接的橋梁。
Lambda【3】-該架構(gòu)是經(jīng)典的大數(shù)據(jù)處理范式羡鸥，是由南森?馬茲（Nathan Marz）提出的一個實時大數(shù)據(jù)處理框架蔑穴。更多有關(guān)Lamda的信息，請讀者訪問Lambda官方網(wǎng)站惧浴。（注：文獻【3】是由James Kinley在輕博客網(wǎng)站Tumblr發(fā)表的一篇博文：Lambda 架構(gòu)：構(gòu)架實時大數(shù)據(jù)系統(tǒng)的原則）澎剥。
Kappa【4】-該計算構(gòu)架可視為Lambda的一個強有力替代者，Kappa將數(shù)據(jù)處理的上游移至流式層（注：文獻【4】是一篇博客文章赶舆，作者是Jay Kreps是Linkedln的一名在線數(shù)據(jù)架構(gòu)技術(shù)高管哑姚。Kreps認為，雖然Lambda構(gòu)架的理念很有價值芜茵，但終究還是一個臨時解決方案叙量。他設(shè)計了一個替代架構(gòu)Kappa，是基于他在Linkedin構(gòu)建Kafka和Samza的經(jīng)驗設(shè)計而成）九串。
SummingBird【5】-這是一個參考模型绞佩，用來橋接在線處理模式和傳統(tǒng)處理模式。Summingbird是由Twitter（推特）公司用Scala語言開發(fā)的猪钮、并開源的大規(guī)模數(shù)據(jù)處理框架品山，支持開發(fā)者以批處理模式（基于Hadoop）或流處理模式（基于Storm），或混合模式（即前兩種模式的組合）以統(tǒng)一的方式執(zhí)行代碼烤低。（注：文獻【5】是Summingbird的主要設(shè)計者Oscar Boykin肘交、Sam Ritchie等人于2014年發(fā)表于知名期刊PVLDB中論文，其中論文的二作Sam Ritchie大有來頭扑馁，他是計算機科學界的傳奇人物涯呻、C語言和Unix的設(shè)計者Dennis Ritchie的侄子）。
在你尚未深入了解上面的各個具體的框架層次之前腻要，建議你認真閱讀一下下面的幾篇非常有價值的文獻复罐，它們幫為你“惡補”一下諸如NoSQL（非結(jié)構(gòu)化）數(shù)據(jù)存儲、數(shù)據(jù)倉庫大規(guī)模計算及分布式系統(tǒng)等相關(guān)領(lǐng)域的背景知識：
計算中心即計算機【6】（Data center as a computer）-文獻【6】是威斯康星大學-麥迪遜分校Mark D.Hill教授主編的一個論文集式的圖書雄家，在這本圖書中效诅，收集了很多有關(guān)數(shù)據(jù)倉庫大規(guī)模計算的論文（注：將數(shù)據(jù)中心視為一臺計算機，與傳統(tǒng)的高性能計算機有很大不同趟济。計算中心的實例將以虛擬機或者容器的形式存在乱投，計算資源的配置對于用戶而言是透明的，這樣就大幅降低系統(tǒng)部署的復(fù)雜度咙好、并提高資源使用的靈活性）篡腌。
非結(jié)構(gòu)化（NOSQL）數(shù)據(jù)存儲【7】- 文獻是由Rick Cattell撰寫的論文，論文討論了可擴展的結(jié)構(gòu)化數(shù)據(jù)的勾效、非結(jié)構(gòu)化的（包括基于鍵值對的嘹悼、基于文檔的和面向列的）數(shù)據(jù)存儲方（注：NOSQL是支撐大數(shù)據(jù)應(yīng)用的關(guān)鍵所在叛甫。事實上，將NOSQL翻譯為“非結(jié)構(gòu)化”不甚準確杨伙，因為NOSQL更為常見的解釋是：Not Only SQL（不僅僅是結(jié)構(gòu)化）其监，換句話說，NOSQL并不是站在結(jié)構(gòu)化SQL的對立面限匣，而是既可包括結(jié)構(gòu)化數(shù)據(jù)抖苦，也可包括非結(jié)構(gòu)化數(shù)據(jù)）。
NoSQL學位論文【8】-該文獻是德國斯圖加特傳媒大學Christof Strauch撰寫的學位論文米死，該論文對分布式系統(tǒng)和第一代非結(jié)構(gòu)化系統(tǒng)提供了非常系統(tǒng)的背景知識介紹锌历。
大規(guī)模數(shù)據(jù)管理【9】-文獻是加拿大阿爾伯塔大學的研究人員撰寫的一篇綜述，討論了大數(shù)據(jù)應(yīng)用程序的大規(guī)模數(shù)據(jù)管理系統(tǒng)峦筒，傳統(tǒng)的數(shù)據(jù)庫供應(yīng)商與新興的互聯(lián)網(wǎng)企業(yè)究西，它們對大數(shù)據(jù)管理需求是不同的。文章的討論范圍涵蓋很廣物喷，數(shù)據(jù)模型卤材、系統(tǒng)結(jié)構(gòu)及一致性模型，皆有涉及峦失。
最終一致性（Eventual Consistency）【10】：論文討論了分布式系統(tǒng)中的各種不同的一致性模型扇丛。（注：原文給出的鏈接可能有誤，因為根據(jù)所提供的鏈接下載而來的論文是關(guān)于“MapReduce中日志處理的Join算法”的綜述文章尉辑，與“最終一致性”的討論議題無關(guān)帆精。這里推薦2篇新的相關(guān)論文：（1）綜述文章：數(shù)據(jù)庫最終一致性：最新的進展【10】new1；（2）微軟研究人員2013年發(fā)表于SIGMOD的文章：“最終一致性的反思（Rethinking Eventual Consistency）【10】new2”材蹬。）
CAP理論【11】-文獻以“CAP理論十二年回顧："規(guī)則"已經(jīng)變了”為題实幕，探討了CAP理論及其演化，是篇非常不錯的介紹CAP理論的基礎(chǔ)性論文（注：論文作者Eric Brewer是加州大學伯克利分校的知名計算機科學學者堤器。該文首發(fā)于《Computer》雜志，隨后又被InfoQ和IEEE再次發(fā)表末贾。CAP理論斷言闸溃，任何基于網(wǎng)絡(luò)的數(shù)據(jù)共享系統(tǒng)，最多只能滿足數(shù)據(jù)一致性（Consistency拱撵，C）辉川、可用性（Availability，A）拴测、分區(qū)（Partition乓旗，P）容忍性這三要素中的兩個要素。但通過顯式處理分區(qū)集索，系統(tǒng)設(shè)計師可做到優(yōu)化數(shù)據(jù)的一致性和可用性屿愚，進而取得三者之間的妥協(xié)與平衡）汇跨。
在過去，在大規(guī)模數(shù)據(jù)處理上妆距，傳統(tǒng)的并行數(shù)據(jù)庫管理系統(tǒng)（DBMS）和基于Map Reduce（映射-規(guī)約穷遂，以下簡稱MR）的批處理范式之間，曾發(fā)生激烈辯論娱据，各持己見蚪黑。并行數(shù)據(jù)庫管理系統(tǒng)的支持者【12】（注：由耶魯大學、微軟和麻省理工學院的研究人員于2009年發(fā)表在SIGMOD的一篇文章）和另外一篇文獻【13】（注：2010年發(fā)表于《美國計算機學會通訊》上的論文：“MapReduce和并行數(shù)據(jù)庫管理系統(tǒng)中剩，是朋友還是敵人忌穿？”），被MR的擁躉者【14】（注：發(fā)表于美國計算機學會通訊的論文：MapReduce:一個彈性的數(shù)據(jù)處理工具）狠狠地給批駁了一番结啼。
然而伴网，令人諷刺的是，從那時起妆棒，Hadoop社區(qū)開始引入無共享的（Shared-Nothing）的MPP（大規(guī)模并行處理）風格的大數(shù)據(jù)處理模式澡腾，文獻“Hadoop上的SQL【15】”，便是例證糕珊。要知道动分，MPP是并行數(shù)據(jù)庫管理系統(tǒng)（DBMS）的靈魂，這樣红选，Map Reduce繞了一大圈澜公，又似回到它當初離開的地方。
文件系統(tǒng)層
由于文件系統(tǒng)層關(guān)注的焦點喇肋，開始向“低延時處理”方向轉(zhuǎn)移姜盈，所以傳統(tǒng)基于磁盤存儲的文件系統(tǒng)，也開始向基于內(nèi)存計算的文件系統(tǒng)轉(zhuǎn)變—— 這樣做堪嫂，會大大降低I / O操作和磁盤序列化帶來的訪問開銷藻肄。Tachyon和 SparkRDD【16】就是朝這個方向演化的范例（注：這里RDD指的是彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets），它是一種高度受限的共享內(nèi)存模型间学，文獻【16】由伯克利大學加州分校的Matei Zaharia等撰寫的殷费，他們提出了一種面向內(nèi)存集群運算的容錯抽象模型）。
Google文件系統(tǒng)（GFS）【17】-該文獻是分布式文件系統(tǒng)的奠基之作低葫，著名的Hadoop分布式文件系統(tǒng)（HDFS）详羡，亦脫胎于GFS，基本上可視為GFS的一個簡化實現(xiàn)版（注：文獻【17】提出了一個可擴展的分布式文件系統(tǒng)GFS嘿悬，可用于大型分布式數(shù)據(jù)密集型應(yīng)用实柠。文獻認為，組件故障是常態(tài)而不是異常善涨。其所提出的GFS窒盐，著眼在幾個重要的目標草则，比如性能、可伸縮性登钥、可靠性和可用性畔师。GFS的新穎之處，并不在于它采用了多么令人驚艷的技術(shù)牧牢，而在于它能利用所提出的方案看锉，采用廉價的商用機器，來構(gòu)建高效的分布式文件系統(tǒng)塔鳍。有用的創(chuàng)新伯铣，才是真的創(chuàng)新，GFS做到了Ｂ秩摇）腔寡。
Hadoop 文件系統(tǒng)【18】-該文獻由雅虎公司的計算機科學家Konstantin Shvachko等人聯(lián)合撰寫的，論文給出了HDFS的進化歷史背景及其架構(gòu)的設(shè)計內(nèi)涵掌唾，是了解Hadoop技術(shù)的經(jīng)典之作放前。
Ceph文件系統(tǒng)【19】-Ceph是HDFS有力的替代者【20】（注：Ceph文件系統(tǒng)是加州大學圣克魯茲分校（USSC）博士生Sage Weil博士期間的一項有關(guān)存儲系統(tǒng)的研究項目。初出茅廬糯彬，略有小成凭语。之后，在開源社區(qū)的推動下撩扒，Ceph逐漸羽翼漸豐似扔，風云叱咤，功成名就搓谆，逐漸發(fā)展成為一個 Linux系統(tǒng)下 PB級分布式文件系統(tǒng)炒辉。文獻【19】是Weil本人在2006年頂級會議OSDI發(fā)表的有關(guān)Ceph的開山論文。文獻【20】則是Weil率領(lǐng)他的一幫小伙伴們再次發(fā)文強調(diào)泉手，Ceph是HDFS強有力的替代者）黔寇。
Tachyon【21】–是一個高容錯的分布式內(nèi)存文件系統(tǒng)，其設(shè)計的核心內(nèi)涵是螃诅，要滿足當下“低延遲”的數(shù)據(jù)處理要求（注：Tachyon是在內(nèi)存中處理緩存文件啡氢，允許文件以訪問內(nèi)存的速度在集群框架中進行可靠的共享，類似于Spark术裸。Tachyon的吞吐量比HDFS高出100倍。Spark框架雖然也提供了強大的內(nèi)存計算能力亭枷，但其沒有提供內(nèi)存文件的存儲管理能力袭艺，而Tachyon則彌補了Spark的不足之處。文獻【21】是伯克利大學加州分校和麻省理工學院的研究者聯(lián)合撰寫的叨粘，發(fā)表在2014年的SoCC國際會議上猾编，論文一作UC Berkeley AMP實驗室博士生李浩源瘤睹，他亦是Spark核心開發(fā)人員之一）。
文件系統(tǒng)的演化歷程答倡，其實也見證了文件格式和壓縮技術(shù)的發(fā)展歷程轰传。下面的參考文獻，可以讓你了解到瘪撇，“面向行”或“面向列”存儲格式各自的優(yōu)缺點获茬，并且還可讓你了然文件存儲技術(shù)發(fā)展的新趨勢——嵌套式的面向列的存儲格式，這種存儲格式可極大提高大數(shù)據(jù)的處理效率倔既。
當前恕曲，在文件系統(tǒng)階段，數(shù)據(jù)管理的最大挑戰(zhàn)之一就是渤涌，如何處理大數(shù)據(jù)中的數(shù)據(jù)冗余佩谣。糾刪碼（Erasure code）是很有創(chuàng)意的冗余保護機制，它可以減少三倍的冗余副本实蓬，還不會影響數(shù)據(jù)的可恢復(fù)性與可用性茸俭。
面向列存儲 vs. 面向列存儲【22】—該文獻是是2008年發(fā)表于SIGMOD的一篇論文，該文對數(shù)據(jù)的布局安皱、壓縮及物化（materialization）策略都做了很不錯的綜述调鬓。
RCFile【23】-這是由Facebook數(shù)據(jù)基礎(chǔ)設(shè)施小組和俄亥俄州立大學的華人學者共同提出的文件存儲格式，他們走了一個“中庸之道”练俐，充分吸取面向列和面向行存儲模式的優(yōu)點袖迎，揚長避短，提出了一種混合的數(shù)據(jù)存儲結(jié)構(gòu)PAX（注：目前這種以行/列混合存儲技術(shù)已成功應(yīng)用于 Facebook 等國內(nèi)外大型互聯(lián)網(wǎng)企業(yè)的生產(chǎn)性運行體系）腺晾。
Parquet【24】- 這是一種面向行的存儲格式燕锥，其設(shè)計理念源于谷歌Dremel論文（注：Parquet主要用于Hadoop 的生態(tài)系統(tǒng)中。文獻【24】是JulienDem在Github發(fā)表的一篇博客文章）悯蝉。
ORCFile【25】–這是一種被Hive（一種基于Hadoop的數(shù)據(jù)倉庫工具）采用的归形、面向列存儲的改進版存儲格式（注：文獻【25】是2014年發(fā)表于頂會SIGMOD的一篇學術(shù)論文）。
壓縮技術(shù)【26】-這是是一篇闡述在Hadoop生態(tài)系統(tǒng)下的常見壓縮算法的綜述性文章鼻由，文章對常見的壓縮算法和其適用場景以及它們的優(yōu)缺點暇榴，做了非常不錯的歸納總結(jié)。
糾刪碼技術(shù)（Erasure code）【27】-這是一篇是田納西大學EECS系教授James Plank撰寫的蕉世、有關(guān)存儲系統(tǒng)糾刪碼技術(shù)的入門級的文獻蔼紧。有關(guān)糾刪碼改進技術(shù)的闡述，讀者可參閱來自南加州大學和Facebook的7名作者共同完成的論文《XORing Elephants: 面向大數(shù)據(jù)的新型糾刪碼技術(shù)【28】》（注：文獻【28】的作者開發(fā)了糾刪碼家族的新成員——基于XOR的本地副本存儲LRC狠轻，該技術(shù)是面向Hadoop生態(tài)系統(tǒng)的奸例，可顯著減少修復(fù)數(shù)據(jù)時的I/O操作和存儲開銷）。
數(shù)據(jù)存儲層
寬泛地講向楼，據(jù)對一致性（consistency）要求的強弱不同查吊，分布式數(shù)據(jù)存儲策略谐区，可分為ACID和BASE兩大陣營。ACID是指數(shù)據(jù)庫事務(wù)具有的四個特性：原子性（Atomicity）逻卖、一致性（Consistency）宋列、隔離性（Isolation）、持久性（Durability）评也。ACID中的一致性要求比較強炼杖，事務(wù)執(zhí)行的結(jié)果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。而BASE對一致性要求較弱仇参，它的三個特征分別是：基本可用（Basically Available）嘹叫、軟狀態(tài)/柔性事務(wù)（Soft-state，即狀態(tài)可以有一段時間的不同步）诈乒、最終一致性（Eventual consistency）罩扇。BASE還進一步細分基于鍵值的，基于文檔的和基于列和圖形的怕磨。細分的依據(jù)取決于底層架構(gòu)和所支持的數(shù)據(jù)結(jié)構(gòu)（注：BASE完全不同于ACID模型喂饥，它以犧牲強一致性，獲得基本可用性和柔性可靠性肠鲫，并要求達到最終一致性）员帮。
在數(shù)據(jù)存儲層，還有很多類似的系統(tǒng)和某些系統(tǒng)的變種导饲，這里捞高，我僅僅列出較為出名的幾個。如漏掉某些重要系統(tǒng)渣锦，還請諒解硝岗。
BASE
鍵值存儲（Key Value Stores）
Dynamo【29】– 這是由亞馬遜工程師們設(shè)計的基于鍵值的高可用的分布式存儲系統(tǒng)（注：Dynamo放棄了數(shù)據(jù)建模的能力，所有的數(shù)據(jù)對象采用最簡單的Key-value模型存儲袋毙，可簡單地將Dynamo理解為一個巨大的Map型檀。Dynamo是犧牲了部分一致性，來換取整個系統(tǒng)的高可用性）听盖。
Cassandra【30】– 這是由Facebook工程師設(shè)計的一個離散的分布式結(jié)構(gòu)化存儲系統(tǒng)胀溺，受亞馬遜的Dynamo啟發(fā)，Cassandra采用的是面向多維的鍵值或面向列的數(shù)據(jù)存儲格式（注：Cassandra可用來管理分布在大量廉價服務(wù)器上的巨量結(jié)構(gòu)化數(shù)據(jù)皆看，并同時提供沒有單點故障的高可用服務(wù)）仓坞。
Voldemort【31】–這又是一個受亞馬遜的Dynamo啟發(fā)的分布式存儲作品，由全球最大的職業(yè)社交網(wǎng)站LinkedIn的工程師們開發(fā)而成（注：Voldemort腰吟，這個在《哈利·波特》中常被譯作“伏地魔”的開源數(shù)據(jù)庫扯躺，支撐起了LinkedIn的多種數(shù)據(jù)分析平臺）。
面向列的存儲（Column Oriented Stores）
BigTable【32】–這是一篇非常經(jīng)典的學術(shù)論文蝎困，闡述了面向列的分布式的數(shù)據(jù)存儲方案录语，由谷歌榮譽出品。（注：Bigtable是一個基于Google文件系統(tǒng)的分布式數(shù)據(jù)存儲系統(tǒng)禾乘，是為谷歌打拼天下的“三駕馬車”之一澎埠，另外兩駕馬車分別是分布式鎖服務(wù)系統(tǒng)Chubby和下文將提到MapReduce）。
HBase【33】–目前還沒有有關(guān)Hbase的定義性論文始藕，這里的文獻提供了一個有關(guān)HBase技術(shù)的概述性文檔（注：Hbase是一個分布式的蒲稳、面向列的開源數(shù)據(jù)庫。其設(shè)計理念源自谷歌的BigTable伍派，用Java語言編寫而成江耀。文獻【33】是一個有關(guān)Hbase的幻燈片文檔）。
Hypertable【34】-文獻是一個有關(guān)“Hypertable”的技術(shù)白皮書诉植，對該數(shù)據(jù)存儲結(jié)構(gòu)做了較為詳細的介紹（注：Hypertable也是一個開源祥国、高性能、可伸縮的數(shù)據(jù)庫晾腔，它采用與Google的Bigtable類似的模型）舌稀。
面向文檔的存儲（Document Oriented Stores）
CouchDB【35】– 這是一款面向文檔的、開源數(shù)據(jù)存儲管理系統(tǒng)（注：文獻【35】是一本Apache CouchDB的400多頁的官方文檔）灼擂。
MongoDB【36】–是目前非常流行的一種非關(guān)系型(NoSQL)數(shù)據(jù)庫（注：文獻【36】是一個有關(guān)MongoDB的白皮書壁查，對MongoDB結(jié)構(gòu)做了很不錯的介紹）。
面向圖（Graph）的存儲
Neo4j【37】–文獻是Ian Robinson等撰寫的圖書《Graph Databases（圖數(shù)據(jù)庫）》（注：Neo4j是一款目前最為流行的高性能NoSQL 圖數(shù)據(jù)庫剔应，它使用圖來描述數(shù)據(jù)模型睡腿，把數(shù)據(jù)保存為圖中的節(jié)點以及節(jié)點之間的關(guān)系。這是最流行的圖數(shù)據(jù)庫）峻贮。
Titan【38】–文獻是有關(guān)Titan的在線文檔（Titan是一款A(yù)pache許可證框架下的分布式的開源圖數(shù)據(jù)庫席怪，特別為存儲和處理大規(guī)模圖而做了大量優(yōu)化）。
ACID
我注意到月洛，現(xiàn)在很多開源社區(qū)正在悄悄發(fā)生變化何恶，它們開始“亦步亦趨”地跟隨谷歌的腳步。這也難怪嚼黔，谷歌太牛细层，跟牛人混，近牛者牛 ——
下面4篇文獻唬涧，有3篇來自于谷歌的“神來之筆”疫赎，他們解決了全球分布一致的數(shù)據(jù)存儲問題。
Megastore【39】–這是一個構(gòu)建于BigTable之上的碎节、高可用的分布式存儲系統(tǒng)捧搞，文獻為有關(guān)Megastore的技術(shù)白皮書（注：Megastore在被谷歌使用了數(shù)年之后，相關(guān)技術(shù)信息才在2001年公布。CSDN網(wǎng)站亦有文獻【39】的中文解讀：Google Megastore分布式存儲技術(shù)全揭秘）胎撇。
Spanner【40】–這是由谷歌研發(fā)的介粘、可擴展的、全球分布式的晚树、同步復(fù)制數(shù)據(jù)庫姻采，支持SQL查詢訪問。（注：Spanner的“老爹”是Big Table爵憎，可以說慨亲，沒有“大表”這個爹，就不可能有這個強有力的“扳手” 兒子宝鼓。它是第一個把數(shù)據(jù)分布在全球范圍內(nèi)的系統(tǒng)刑棵，并且支持外部一致性的分布式事務(wù)）。
MESA【41】–亦是由谷歌研發(fā)的愚铡、跨地域復(fù)制(geo-replicated)蛉签、高可用的、可容錯的茂附、可擴展的近實時數(shù)據(jù)倉庫系統(tǒng)（注：在2014年的VLDB大會上正蛙，谷歌公布了他們的分析型數(shù)據(jù)倉庫系統(tǒng)MESA，該系統(tǒng)主要用于存儲Google互聯(lián)網(wǎng)廣告業(yè)務(wù)相關(guān)的關(guān)鍵衡量數(shù)據(jù)营曼。文獻【41】是VLDB的會議論文）乒验。
CockroachDB【42】–該系統(tǒng)是由Google前工程師Spencer Kimball領(lǐng)導開發(fā)的Spanner的開源版本（注：這個項目的綽號是“螳螂（Cockroach）”，其寓意是“活得長久”蒂阱，因為蟑螂是地球上生命力最強的生物之一锻全，即使被砍下頭顱，依然還能存活好幾天录煤！文獻【42】是代碼托管網(wǎng)站GitHub上對Cockroach的說明性文檔）鳄厌。
資源管理器層（Resource Managers）
第一代Hadoop的生態(tài)系統(tǒng)，其資源管理是以整體單一的調(diào)度器起家的妈踊，其代表作品為YARN了嚎。而當前的調(diào)度器則是朝著分層調(diào)度的方向演進（Mesos則是這個方向的代表作），這種分層的調(diào)度方式廊营，可以管理不同類型的計算工作負載歪泳，從而可獲取更高的資源利用率和調(diào)度效率。
YARN【43】– 這是新一代的MapReduce計算框架露筒，簡稱MRv2呐伞，它是在第一代MapReduce的基礎(chǔ)上演變而來的（注：MRv2的設(shè)計初衷是，為了解決第一代Hadoop系統(tǒng)擴展性差慎式、不支持多計算框架等問題伶氢。對國內(nèi)用戶而言趟径，原文獻下載鏈接可能會產(chǎn)生404錯誤，這里提供一個新文獻：由2011年剝離自雅虎的Hadoop初創(chuàng)公司Hortonworks給出的官方文獻【43】new癣防，閱讀該文獻也可對YARN有較為深入的理解蜗巧。CSDN亦有對YARN詳細解讀的文章：[更快、更強——解析Hadoop新一代MapReduce框架Yarn](file:///D:/iwork/CSDN-%E6%96%87%E7%AB%A0/04-big%20data/%E6%9B%B4%E5%BF%AB%E3%80%81%E6%9B%B4%E5%BC%BA%E2%80%94%E2%80%94%E8%A7%A3%E6%9E%90Hadoop%E6%96%B0%E4%B8%80%E4%BB%A3MapReduce%E6%A1%86%E6%9E%B6Yarn)）劣砍。
Mesos【44】–這是一個開源的計算框架惧蛹，可對多集群中的資源做彈性管理（注：Mesos誕生于UC Berkeley的一個研究項目，現(xiàn)為Apache旗下的一個開源項目刑枝，它是一個全局資源調(diào)度器。目前Twitter迅腔、Apple等國外大公司正在使用Mesos管理集群資源装畅，國內(nèi)用戶有豆瓣等。文獻【44】是加州大學伯克利分校的研究人員發(fā)表于著名會議NSDI上的學術(shù)論文）沧烈。
這些計算框架和調(diào)度器之間是松散耦合的掠兄，調(diào)度器的主要功能就是基于一定的調(diào)度策略和調(diào)度配置，完成作業(yè)調(diào)度锌雀，以達到工作負載均衡蚂夕，使有限的資源有較高的利用率。
調(diào)度器（Schedulers）
作業(yè)調(diào)度器腋逆，通常以插件的方式加載于計算框架之上婿牍，常見的作業(yè)調(diào)度器有4種：
計算能力調(diào)度器【45】（Capacity Scheduler）-該文獻是一個關(guān)于計算能力調(diào)度器的指南式文檔，介紹了計算能力調(diào)度器的不同特性惩歉。
公平調(diào)度器【46】（FairShare Scheduler） -該文獻是Hadoop的公平調(diào)度器設(shè)計文檔等脂，介紹了公平調(diào)度的各項特征（注：公平調(diào)度是一種賦予作業(yè)資源的方法，它提供了一個基于任務(wù)數(shù)的負載均衡機制撑蚌，其目的是讓所有的作業(yè)隨著時間的推移上遥，都能平均的獲取等同的共享資源）。
延遲調(diào)度【47】（Delayed Scheduling） –該文獻是加州大學伯克利分校的一份技術(shù)報告争涌，報告介紹了公平調(diào)度器的延遲調(diào)度策略粉楚。
公平與能力調(diào)度器【48】（Fair & Capacity schedulers ）–該文獻是一篇關(guān)于云環(huán)境下的Hadoop調(diào)度器的綜述性論文。
協(xié)調(diào)器（Coordination）
在分布式數(shù)據(jù)系統(tǒng)中亮垫，協(xié)調(diào)器主要用于協(xié)調(diào)服務(wù)和進行狀態(tài)管理模软。
Paxos【49】–文獻【49】是經(jīng)典論文“The Part-TimeParliament（兼職的議會）【50】” 的簡化版。
注：兩篇文獻的作者均是萊斯利·蘭伯特（LeslieLamport）包警，此君是個傳奇人物撵摆，科技論文寫作常用編輯器LaTex，其中“La”就是來自其姓“Lamport”的前兩個字母害晦。Lamport目前是微軟研究院首席研究員特铝，2013年暑中，因其在分布式計算理論領(lǐng)域做出的杰出貢獻，榮獲計算機領(lǐng)域最高獎——圖靈獎鲫剿。牛人的故事特別多鳄逾，Lamport亦是這樣。就這兩篇文獻而言灵莲，Lamport的奇聞軼事都值得說道說道雕凹。光看其經(jīng)典論文題目“The Part-TimeParliament（兼職的議會）【50】”，或許就讓讀者“一頭霧水”政冻，這是一篇計算機科學領(lǐng)域的論文嗎枚抵？和讀者一樣感覺的可能還有期刊編輯。其實明场，早在1990年時汽摹，Lamport就提出Paxos算法，他虛構(gòu)了一個希臘城邦Paxos及其議會苦锨，以此來形象比喻說明該算法的流程逼泣。論文投出后，期刊編輯建議Lamport舟舒，將論文用更加嚴謹?shù)臄?shù)學語言重新進行描述一下拉庶。可Lamport則認為秃励，我的幽默氏仗，你不懂！拒絕修改莺治。時隔八年之后的 1998年廓鞠，Paxos算法才被伯樂期刊《ACM Transactions on Computer Systems》發(fā)表。由于Paxos算法本身過于復(fù)雜谣旁，且同行不理解自己的“幽默”床佳，于是，2001年Lamport就用簡易語言撰寫這篇文章榄审，重新發(fā)表了該論文的簡化版【49】砌们，即“Paxosmade simple（Paxos變得簡單）”。簡化版的摘要更簡單搁进，就一句話：“Paxos算法浪感，用簡易英語說明之，很簡單”饼问，如果去掉中間的那個無故緊要的定語從句影兽，就是“Paxos算法，很簡單”莱革。弄得你都來不及做深思狀峻堰，摘要就完了讹开。這…，這…捐名，完全顛覆了我們常用的“三段論式（提問題旦万、解問題、給結(jié)論）”的論文摘要寫法啊镶蹋。
后來成艘，隨著分布式系統(tǒng)的不斷發(fā)展壯大，Paxos算法開始大顯神威贺归。Google的Chubby和Apache的Zookeeper淆两，都是用Paxos作為其理論基礎(chǔ)實現(xiàn)的。就這樣牧氮，Paxos終于登上大雅之堂琼腔，它也為Lamport在2013年獲得圖靈獎，立下汗馬功勞踱葛。從Lamport發(fā)表Paxos算法的小案例，我們可以看出：彪悍的人生光坝，不需要解釋尸诽。牛逼的論文，就可以任性盯另！
Chubby【51】– 該文獻的作者是谷歌工程師Mike Burrows性含。Chubby系統(tǒng)本質(zhì)上就是前文提到的Paxos的一個實現(xiàn)版本，主要用于谷歌分布式鎖服務(wù)鸳惯。（注：原文鏈接會出現(xiàn)404錯誤商蕴，CSDN網(wǎng)站有Chubby論文的下載鏈接）。
Zookeeper【52】–這是Apache Hadoop框架下的Chubby開源版本芝发。它不僅僅提供簡單地上鎖服務(wù)绪商，而事實上，它還是一個通用的分布式協(xié)調(diào)器辅鲸，其設(shè)計靈感來自谷歌的Chubby（注：眾所周知格郁，分布式協(xié)調(diào)服務(wù)開發(fā)困難很大，分布式系統(tǒng)中的多進程間很容易發(fā)生條件競爭和死鎖独悴。ZooKeeper的開發(fā)動力就是減輕分布式應(yīng)用開發(fā)的困難例书，使用戶不必從零開始構(gòu)建協(xié)調(diào)服務(wù)）。
計算框架（Computational
Frameworks）運行時計算框架刻炒，可為不同種類的計算决采，提供運行時（runtime）環(huán)境。最常用的是運行時計算框架是Spark和Flink坟奥。
Spark【53】–因Spark日益普及树瞭，加之其具備良好的多計算環(huán)境的適用性拇厢，它已對傳統(tǒng)的Hadoop生態(tài)環(huán)境，形成了嚴峻的挑戰(zhàn)（注：Spark是一個基于內(nèi)存計算的開源的集群計算系統(tǒng)移迫，其目的在于旺嬉，讓數(shù)據(jù)分析更加快速。Spark是由加州大學伯克利分校的AMP實驗室采用Scala語言開發(fā)而成厨埋。Spark的內(nèi)存計算框架邪媳，適合各種迭代算法和交互式數(shù)據(jù)分析，能夠提升大數(shù)據(jù)處理的實時性和準確性荡陷，現(xiàn)已逐漸獲得很多企業(yè)的支持副女，如阿里巴巴、百度蝎宇、網(wǎng)易贤旷、英特爾等公司均是其用戶）。
Flink【54】–這是一個非常類似于Spark的計算框架唉地，但在迭代式數(shù)據(jù)處理上据悔，比Spark更給力（注：目前大數(shù)據(jù)分析引擎Flink，已升級成為Apache頂級項目）耘沼。
Spark和Flink都屬于基礎(chǔ)性的大數(shù)據(jù)處理引擎极颓。具體的計算框架，大體上群嗤，可根據(jù)采用的模型及延遲的處理不同菠隆，來進行分門別類。
批處理（Batch）
MapReduce【55】– 這是谷歌有關(guān)MapReduce的最早的學術(shù)論文（注：對于國內(nèi)用戶狂秘，點擊原文獻鏈接可能會產(chǎn)生404錯誤骇径，CSDN網(wǎng)站有MapReduce論文的下載鏈接）。
MapReduce綜述【56】–這是一篇過時者春、但依然值得一讀的破衔、有關(guān)MapReduce計算框架的綜述性文章。
迭代式（BSP）
Pregel【57】–這又是一篇谷歌出品的大手筆論文碧查，主要描述了大規(guī)模圖處理方法（注：Pregel是一種面向圖算法的分布式編程框架运敢，其采用的是迭代式的計算模型。它被稱之為Google后Hadoop時代的新“三駕馬車”之一忠售。另外兩駕馬車分別是：“交互式”大數(shù)據(jù)分析系統(tǒng)Dremel和網(wǎng)絡(luò)搜索引擎Caffeine）传惠。
Giraph【58】– 該系統(tǒng)建模于谷歌的Pregel，可視為Pregel的開源版本稻扬，它是一個基于 Hadoop架構(gòu)的卦方、可擴展的分布式迭代圖處理系統(tǒng)。
GraphX【59】–這是一個同時采用圖并行計算和數(shù)據(jù)并行的計算框架（注：GraphX最先是加州大學伯克利分校AMPLab實驗室的一個分布式圖計算框架項目泰佳，后來整合到Spark中盼砍，成為其中的一個核心組件尘吗。GraphX最大的貢獻在于，在Spark之上提供一棧式數(shù)據(jù)解決方案浇坐，可方便高效地完成圖計算的一整套流水作業(yè)）睬捶。
Hama【60】– 是一個構(gòu)建Hadoop之上的基于BSP模型的分布式計算引擎（注：Hama的運行環(huán)境需要關(guān)聯(lián)Zookeeper、HBase近刘、HDFS 組件擒贸。Hama中最關(guān)鍵的技術(shù)，就是采用了BSP模型(Bulk SynchronousParallel觉渴，即整體同步并行計算模型介劫，又名大同步模型)。BSP模型是哈佛大學的計算機科學家Viliant和牛津大學的BillMcColl在1990年聯(lián)合提出的案淋，他們希望能像馮·諾伊曼體系結(jié)構(gòu)那樣座韵，架起計算機程序語言和體系結(jié)構(gòu)間的橋梁，故又稱作橋模型(Bridge Model)踢京。
開源圖處理系統(tǒng)【61】（Open source graphprocessing ）-這是滑鐵盧大學的研究人員撰寫的綜述性文獻誉碴，文獻【61】對類Pregel（Pregel-like）的、基于BSP模型的圖處理系統(tǒng)進行了實驗性的比較瓣距。
流式（Streaming）
流式處理【62】（Stream Processing）- 這是一篇非常棒的翔烁、有關(guān)面向大數(shù)據(jù)實時處理系統(tǒng)的綜述性文章。
Storm【63】– 這是一個大數(shù)據(jù)實時處理系統(tǒng)（注：Storm有時也被人們稱為實時處理領(lǐng)域的Hadoop旨涝，它大大簡化了面向龐大規(guī)模數(shù)據(jù)流的處理機制，從而在實時處理領(lǐng)域扮演著重要角色侣背。文獻【63】是Twitter工程師們在2014年發(fā)表于SIGMOD上的學術(shù)論文）白华。
Samza【64】-這是一款由Linkedin公司開發(fā)的分布式的流式數(shù)據(jù)處理框架（注：所謂流式數(shù)據(jù)，是指要在處理單位內(nèi)得到的數(shù)據(jù)贩耐，這種方式更注重于實時性弧腥，流式數(shù)據(jù)有時也稱為快數(shù)據(jù)）。
Spark流【65】（Spark Streaming） -該文獻是加州大學伯克利分校的研究人員于2013年在著名操作系統(tǒng)會議SOSP上發(fā)表的學術(shù)論文潮太，論文題目是《離散流：容錯大規(guī)模流式計算》（注：這里的離散流是指一種微批處理構(gòu)架管搪，其橋接了傳統(tǒng)的批處理和交互式處理。Spark Streaming是Spark核心API的一個擴展铡买，它并不會像Storm那樣逐個處理數(shù)據(jù)流更鲁，而是在處理前，按時間間隔預(yù)先將其切分為很多小段的批處理作業(yè)）奇钞。
交互式（Interactive）
Dremel【66】–這又是一篇由谷歌出品的經(jīng)典論文澡为，論文描述了如何處理“交互式”大數(shù)據(jù)的工作負載。該論文是多個基于Hadoop的開源SQL系統(tǒng)的理論基礎(chǔ)（注：文獻【66】寫于2006年景埃，“捂”藏4年之后媒至，于2010年公布于眾顶别。文章針對MR交互式查詢能力不足，提出了Dremel拒啰，闡述了Dremel的設(shè)計原理驯绎，并提供了部分測試報告）。
Impala【67】–這是一個大規(guī)模并行處理（MPP）式 SQL 大數(shù)據(jù)分析引擎（注：Impala像Dremel一樣谋旦，其借鑒了MPP（Massively Parallel Processing剩失，大規(guī)模并行處理）并行數(shù)據(jù)庫的思想，拋棄了MapReduce這個不太適合做SQL查詢的范式蛤织，從而讓Hadoop支持處理交互式的工作負載赴叹。本文作者阿尼爾?馬丹在LinkedIn上的博客原文，在此處的“MPI”系“MPP”筆誤指蚜，讀者可參閱文獻【67】發(fā)現(xiàn)此問題）乞巧。
Drill【68】–這是谷歌Dremel的開源版本（注：Drill是一個低延遲的、能對海量數(shù)據(jù)（包括結(jié)構(gòu)化摊鸡、半結(jié)構(gòu)化及嵌套數(shù)據(jù)）實施交互式查詢的分布式數(shù)據(jù)引擎）绽媒。
Shark【69】–該文獻是2012年發(fā)表于SIGMOD的一篇學術(shù)論文，論文對Spark生態(tài)系統(tǒng)上的數(shù)據(jù)分析能力免猾，給出了很深入的介紹（注：Shark是由加州伯克利大學AMPLab開發(fā)的大數(shù)據(jù)分析系統(tǒng)是辕。Shark即“Hive onSpark”的含義，本質(zhì)上是通過Hive的HQL解析猎提，把HQL翻譯成Spark上的RDD操作获三。然后通過Hive的元數(shù)據(jù)獲，取數(shù)據(jù)庫里的表信息锨苏。HDFS上的數(shù)據(jù)和文件疙教，最后會由Shark獲取，并放到Spark上運算伞租。Shark基于Scala語言的算子推導贞谓，可實現(xiàn)良好的容錯機制，對執(zhí)行失敗的長/短任務(wù)葵诈，均能從上一個“快照點（Snapshot）”進行快速恢復(fù)）裸弦。
Shark【70】–這是另外一篇很棒的于2013年發(fā)表在SIGMOD的學術(shù)論文，其深度解讀在Apache
Hive之上SQL訪問機制（注：這篇文獻描述了如何構(gòu)建在Spark上構(gòu)建SQL引擎——Shark作喘。更重要的是理疙，文章還討論了之前在Hadoop/MapReduce上實施SQL查詢?nèi)绱酥脑颍?br> Dryad【71】– 文獻討論了使用有向無環(huán)圖(DirectedAcyclineGraph，DAG)來配置和執(zhí)行并行數(shù)據(jù)流水線的方法（注：Dryad是一個通用的粗顆粒度的分布式計算和資源調(diào)度引擎徊都，其核心特性之一沪斟，就是允許用戶自己構(gòu)建DAG調(diào)度拓撲圖。文獻【71】是微軟于2007年在EuroSys國際會議上發(fā)布的學術(shù)論文）。
Tez【72】–其核心思想來源于Dryad主之，可視為利用Yarn(即MRv2)對Dryad的開源實（注：Apache Tez是基于Hadoop Yarn之上的DAG計算框架择吊。由Hadoop的二東家Hortonworks開發(fā)并提供主要技術(shù)支持。文獻【72】是一個關(guān)于Tez的簡要介紹文檔）槽奕。
BlinkDB【73】–可在抽樣數(shù)據(jù)上實現(xiàn)交互式查詢几睛，其呈現(xiàn)出的查詢結(jié)果，附帶有誤差標識粤攒。（注：BlinkDB 是一個用于在海量數(shù)據(jù)上運行交互式 SQL 查詢的大規(guī)模并行查詢引擎所森。BlinkDB允許用戶通過適當降低數(shù)據(jù)精度，對數(shù)據(jù)進行先采樣后計算夯接，其通過其獨特的優(yōu)化技術(shù)焕济，實現(xiàn)了比Hive快百倍的交互式查詢速度，而查詢進度誤差僅降低2~10%盔几。
BlinkDB采用的策略晴弃，與大數(shù)據(jù)布道師，維克托·邁爾-舍恩伯格在其著作《大數(shù)據(jù)時代》中提到的觀點逊拍，“要全體上鞠，不要抽樣”，恰恰相反芯丧∩盅郑基于常識，我們知道：多了缨恒，你就快不了谴咸。好了，你就省不了骗露。對大數(shù)據(jù)處理而言寿冕，也是這樣。英特爾中國研究院院長吳甘沙認為椒袍，大體量、精確性和速度快藻茂，三者不可兼得驹暑，頂多取其二。如果要實現(xiàn)在大體量數(shù)據(jù)上的“快”辨赐，就得想辦法減少數(shù)據(jù)优俘，而減少數(shù)據(jù)，勢必要適度地降低分析精確性掀序。
事實上帆焕，大數(shù)據(jù)并不見得越“大”越好，有時候一味的追求“大”是沒有必要的。例如叶雹，在醫(yī)療健康領(lǐng)域财饥，如果來監(jiān)控某個病人的體溫，可穿戴設(shè)備可以一秒鐘采集一次數(shù)據(jù)折晦，也可以一分鐘采集一次數(shù)據(jù)钥星，前者采集的數(shù)據(jù)總量比后者“大”60倍，但就監(jiān)控病人身體狀況而言满着，意義并不是太大谦炒。雖然后者的數(shù)據(jù)忽略了人體在一分鐘內(nèi)的變化，監(jiān)控的精度有所下降风喇，但對于完成監(jiān)控病人健康狀態(tài)這一目的而言宁改，是可以接受的。）
實時系統(tǒng)（RealTime）
Druid【74】–這是一個開源的分布式實時數(shù)據(jù)分析和存儲系統(tǒng)魂莫，旨在快速處理大規(guī)模的數(shù)據(jù)还蹲，并能做到快速查詢和分析（注：文獻【74】是2014年Druid創(chuàng)始人Eric Tschetter和中國工程師楊仿今等人在SIGMOD上發(fā)表的一篇論文）。
Pinot【75】–這是由LinkedIn公司出品的一個開源的豁鲤、實時分布式的 OLAP數(shù)據(jù)分析存儲系統(tǒng)秽誊，非常類似于前面提到的Druid，LinkedIn 使用它實現(xiàn)低延遲可伸縮的實時分析琳骡。（注：文獻【75】是在GitHub上的有關(guān)Pinot的說明性文檔）锅论。
數(shù)據(jù)分析層（Data Analysis）
數(shù)據(jù)分析層中的工具，涵蓋范圍很廣楣号，從諸如SQL的聲明式編程語言最易，到諸如Pig的過程化編程語言，均有涉及炫狱。另一方面藻懒，數(shù)據(jù)分析層中的庫也很豐富，可支持常見的數(shù)據(jù)挖掘和機器學習算法视译，這些類庫可拿來即用嬉荆，甚是方便。
工具（Tools）
Pig【76】–這是一篇有關(guān)Pig Latin非常不錯的綜述文章（注：Pig Latin原是一種兒童黑話酷含，屬于是一種英語語言游戲鄙早，形式是在英語上加上一點規(guī)則使發(fā)音改變，讓大人們聽不懂椅亚，從而完成孩子們獨懂的交流限番。文獻【76】是雅虎的工程師們于2008年發(fā)表在SIGMOD的一篇論文，論文的題目是“Pig Latin：并不是太老外的一種數(shù)據(jù)語言”呀舔，言外之意弥虐，他們發(fā)明了一種數(shù)據(jù)處理的“黑話”——Pig
Latin，一開始你可能不懂，等你熟悉了霜瘪，就會發(fā)現(xiàn)這種數(shù)據(jù)查詢語言的樂趣所在）珠插。
Pig【77】– 這是另外一篇由雅虎工程師們撰寫的有關(guān)使用Pig經(jīng)驗的論文，文章介紹了如果利用Pig在Map-Reduce上構(gòu)建一個高水準的數(shù)據(jù)流分析系統(tǒng)粥庄。
Hive【78】–該文獻是Facebook數(shù)據(jù)基礎(chǔ)設(shè)施研究小組撰寫的一篇學術(shù)論文丧失，介紹了Hive的來龍去脈（注：Hive是一個建立于 Hadoop上的數(shù)據(jù)倉庫基礎(chǔ)構(gòu)架。它用來進行數(shù)據(jù)的提取惜互、轉(zhuǎn)化和加載（即Extract-Transform-Load布讹，ETL），它是一種可以存儲训堆、查詢和分析存儲在 Hadoop 中的大規(guī)模數(shù)據(jù)的機制）描验。
Hive【79】–該文獻是另外一篇有關(guān)Hive的值得一讀的好論文。論文作者來自Facebook數(shù)據(jù)基礎(chǔ)設(shè)施研究小組坑鱼，在這篇論文里膘流，可以幫助讀者理解Hive的設(shè)計理念。
Phoenix【80】–它是HBase 的 SQL 驅(qū)動（注：Phoenix可將 SQL 查詢轉(zhuǎn)成 HBase 的掃描及相應(yīng)的動作鲁沥。文獻【80】是關(guān)于在Hbase上部署SQL的幻燈片文檔）呼股。
MapReduce上的連接（join）算法【81】–該文獻介紹了在Hadoop環(huán)境下的各種并行連接算法，并對它們的性能作出系統(tǒng)性評測画恰。
MapReduce上的連接算法【82】–這是威斯康星大學和IBM研究團隊撰寫的綜述性文章彭谁，文章對在Map Reduce模型下的各種連接算法進行了綜合比較。
庫（Libraires）
MLlib【83】–這是在Spark計算框架中對常用的機器學習算法的實現(xiàn)庫允扇，該庫還包括相關(guān)的測試和數(shù)據(jù)生成器（注：文獻【83】是MLlib的一個幻燈片說明文檔）缠局。
SparkR【84】–這是AMPLab發(fā)布的一個R開發(fā)包，為Apache
Spark提供輕量級的前端（注：R是一種廣泛應(yīng)用于統(tǒng)計分析考润、繪圖的語言及操作環(huán)境狭园。文獻【84】是有關(guān)SparkR的幻燈片文檔）。
Mahout【85】–這是一個功能強大的數(shù)據(jù)挖掘工具糊治，是一個基于傳統(tǒng)Map Reduce的分布式機器學習框架（注：Mahout的中文含義就是“馭象之人”唱矛，而Hadoop的Logo正是一頭小黃象。很明顯井辜，這個庫是幫助用戶用好Hadoop這頭難用的大象揖赴。文獻【85】是有關(guān)Mahout的圖書）。
數(shù)據(jù)集成層（Data Integration）
數(shù)據(jù)集成框架提供了良好的機制抑胎，以協(xié)助高效地攝取和輸出大數(shù)據(jù)系統(tǒng)之間的數(shù)據(jù)。從業(yè)務(wù)流程線到元數(shù)據(jù)框架渐北，數(shù)據(jù)集成層皆有涵蓋阿逃，從而提供全方位的數(shù)據(jù)在整個生命周期的管理和治理。
攝入/消息傳遞（Ingest/Messaging）
Flume【86】–這是Apache旗下的一個分布式的、高可靠的恃锉、高可用的服務(wù)框架搀菩，可協(xié)助從分散式或集中式數(shù)據(jù)源采集、聚合和傳輸海量日志（注：文獻【86】是Apache網(wǎng)站上有關(guān)Flume的一篇博客文章）破托。
Sqoop【87】–該系統(tǒng)主要用來在Hadoop和關(guān)系數(shù)據(jù)庫中傳遞數(shù)據(jù)（注：Sqoop目前已成為Apache的頂級項目之一肪跋。通過Sqoop，可以方便地將數(shù)據(jù)從關(guān)系數(shù)據(jù)庫導入到HDFS土砂，或反之亦可州既。文獻【87】是有關(guān)Sqoop的幻燈片說明文檔）。
Kafka【88】–這是由LinkedIn開發(fā)的一個分布式消息系統(tǒng)（注：由Scala編寫而成的Kafka萝映，由于可水平擴展吴叶、吞吐率高等特性，得到廣泛應(yīng)用序臂。文獻【88】是LindedIn的工程師們在2011年發(fā)表于NetDB的會議論文）蚌卤。
ETL/工作流
ETL是數(shù)據(jù)抽取（Extract）奥秆、清洗（Cleaning）逊彭、轉(zhuǎn)換（Transform）、裝載（Load）的過程构订，是構(gòu)建數(shù)據(jù)倉庫的重要一環(huán)侮叮。
Crunch【89】–這是Apache旗下的一套Java API函數(shù)庫，它能夠大大簡化編寫鲫咽、測試签赃、運行MapReduce 處理工作流的程序（注：文獻【89】是有關(guān)Crunch的幻燈片解釋文檔）。
Falcon【90】– 這是Apache旗下的Falcon大數(shù)據(jù)管理框架分尸，可以幫助用戶自動遷移和處理大數(shù)據(jù)集合（注：文獻【90】是一份關(guān)于Falcon技術(shù)預(yù)覽報告）锦聊。
Cascading【91】–這是一個架構(gòu)在Hadoop上的API函數(shù)庫，用來創(chuàng)建復(fù)雜的可容錯的數(shù)據(jù)處理工作流（注：文獻【91】是關(guān)于Hadoop上的Cascading的概論和技術(shù)隨筆）箩绍。
Oozie【92】–是一個工作流引擎孔庭，用來協(xié)助Hadoop作業(yè)管理（注：Oozie字面含義是馴象之人，其寓意和Mahout一樣材蛛，幫助用戶更好地搞定Hadoop這頭大象圆到。文獻【92】是Apache網(wǎng)站上有關(guān)Oozie的官方文檔）。
元數(shù)據(jù)（Metadata）
HCatalog【93】– 它提供了面向Apache Hadoop的數(shù)據(jù)表和存儲管理服務(wù)（注：Apache
HCatalog提供一個共享的模式和數(shù)據(jù)類型的機制卑吭，它抽象出表芽淡，使用戶不必關(guān)心數(shù)據(jù)怎么存儲，并提供了可操作的跨數(shù)據(jù)處理工具豆赏。文獻【93】是Apache網(wǎng)站有關(guān)Hcatalog的官方說明文檔）挣菲。
序列化（Serialization）
Protocol Buffers【94】–由Google推廣的一種與語言無關(guān)的、對結(jié)構(gòu)化數(shù)據(jù)進行序列化和反序列化的機制（注：Protocol Buffers可用于通訊協(xié)議白胀、數(shù)據(jù)存儲等領(lǐng)域的語言及平臺無關(guān)椭赋、可擴展的序列化結(jié)構(gòu)數(shù)據(jù)格式。文獻【94】是有關(guān)Protocol Buffers幻燈片文檔）或杠。
Avro【95】–這是一個建模于Protocol Buffers之上的哪怔、Hadoop生態(tài)系統(tǒng)中的子項目（注：Avro本身既是一個序列化框架，同時也實現(xiàn)了RPC的功能）向抢。
操作框架（Operational Frameworks）
最后认境，我們還需要一個操作性框架，來構(gòu)建一套衡量標準和測試基準笋额，從而來評價各種計算框架的性能優(yōu)劣元暴。在這個操作性框架中，還需要包括性能優(yōu)化工具兄猩，借助它來平衡工作負載茉盏。
監(jiān)測管理框架（Monitoring Frameworks）
OpenTSDB【96】–這是構(gòu)建于HBase之上的實時性能評測系統(tǒng)（注：文獻【96】提供了OpenTSDB的簡要概述，介紹了OpenTSDB的工作機理）枢冤。
Ambari【97】– 這是一款基于Web的系統(tǒng)鸠姨，支持Apache Hadoop集群的供應(yīng)、管理和監(jiān)控（注：文獻【97】闡述了Ambari架構(gòu)的設(shè)計準則）淹真。
基準測試（Benchmarking）
YCSB【98】–該文獻是一篇使用YCSB對NoSQL系統(tǒng)進行性能評估的期刊論文（注：YCSB是雅虎云服務(wù)基準測試（Yahoo! Cloud Serving Benchmark）的簡寫讶迁。見名知意，它是由雅虎出品的一款通用云服務(wù)性能測試工具）核蘸。
GridMix【99】–該系統(tǒng)通過運行大量合成的作業(yè)巍糯，對Hadoop系統(tǒng)進行基準測試，從而獲得性能評價指標（注：文獻是Apache網(wǎng)站有關(guān)GridMix的官方說明文檔）客扎。
最后一篇文獻是有關(guān)大數(shù)據(jù)基準測試的綜述文章【100】祟峦，文章討論了基準測試的最新技術(shù)進展以及所面臨的幾個主要挑戰(zhàn)。
譯者寄語：
在你邁步于大數(shù)據(jù)的旅途中徙鱼，真心希望這些文獻能助你一臂之力宅楞。但要知道，有關(guān)大數(shù)據(jù)的文獻袱吆，何止千萬厌衙，由于個人精力、能力有限绞绒，有些領(lǐng)域也不甚熟稔婶希，故難免會掛一漏萬。如有疏忽蓬衡，漏掉你的大作喻杈，還請你海涵拐揭。最后，希望這些文獻能給你帶來“學而時習之奕塑，不亦樂乎”的快感！
譯者介紹：張玉宏家肯，博士龄砰。2012年畢業(yè)于電子科技大學，現(xiàn)執(zhí)教于河南工業(yè)大學讨衣。中國計算機協(xié)會（CCF）會員换棚，ACM/IEEE會員。主要研究方向為高性能計算反镇、生物信息學固蚤，主編有《Java從入門到精通》一書。
