3.2 大數(shù)據(jù)處理技術(shù)

1993—2013：大數(shù)據(jù)處理技術(shù)發(fā)展的風(fēng)雨二十年

在新型大數(shù)據(jù)處理技術(shù)與平臺(tái)出現(xiàn)之前，人們處理大規(guī)模數(shù)據(jù)或計(jì)算密集型科學(xué)計(jì)算任務(wù)的方式通常是借助MPI（Message Passing Interface）編程模型和方法。在大數(shù)據(jù)處理技術(shù)與平臺(tái)出現(xiàn)之前，業(yè)界也使用MPI進(jìn)行大數(shù)據(jù)的并行化編程與計(jì)算。MPI起源于1993年，由來自大學(xué)、美國(guó)國(guó)家實(shí)驗(yàn)室、高性能計(jì)算廠商共同發(fā)起組織與研究。MPI由于能夠充分利用并行計(jì)算系統(tǒng)的硬件資源，發(fā)揮其計(jì)算性能，從而被廣泛應(yīng)用于高性能科學(xué)計(jì)算的多個(gè)領(lǐng)域。然而，MPI缺少統(tǒng)一的計(jì)算框架支持，缺少良好的架構(gòu)支撐，程序員需要考慮包括數(shù)據(jù)存儲(chǔ)、劃分、容錯(cuò)處理等諸多細(xì)節(jié)，因此其并行化編程計(jì)算的自動(dòng)化程度較低、程序設(shè)計(jì)較為復(fù)雜、程序員負(fù)擔(dān)較重。

隨著Web2.0時(shí)代的發(fā)展，互聯(lián)網(wǎng)上的數(shù)據(jù)量呈現(xiàn)爆炸式增長(zhǎng)，為了滿足信息搜索的需要，人們對(duì)大規(guī)模數(shù)據(jù)的存儲(chǔ)提出了非常強(qiáng)勁的需要。基于成本的考慮，通過提升硬件來解決大批量數(shù)據(jù)的搜索越來越不切實(shí)際，于是谷歌提出了一種基于軟件的可靠文件存儲(chǔ)體系“谷歌文件系統(tǒng)”（GFS），使用普通的電腦來并行支撐大規(guī)模數(shù)據(jù)的存儲(chǔ)。

存進(jìn)去的數(shù)據(jù)是低價(jià)值的，只有對(duì)數(shù)據(jù)進(jìn)行加工才能滿足實(shí)際的應(yīng)用需要，于是谷歌又創(chuàng)造了MapReduce這一計(jì)算模型，該模型能夠利用集群的力量將復(fù)雜的運(yùn)算拆分到多個(gè)普通電腦上進(jìn)行計(jì)算，計(jì)算完成后通過匯總得到最終的計(jì)算結(jié)果。

有了GFS和MapReduce之后，文件的存儲(chǔ)和運(yùn)算得到了解決，這時(shí)候又出現(xiàn)了新的問題。GFS的隨機(jī)讀寫能力很差，同時(shí)谷歌又需要一種存放格式化數(shù)據(jù)的數(shù)據(jù)庫(kù)，原本通過單機(jī)的數(shù)據(jù)庫(kù)就能解決的問題，在新的架構(gòu)下又“悲劇”了。于是谷歌開發(fā)了一套列式數(shù)據(jù)庫(kù)系統(tǒng)——BigTable。

谷歌完成了上述系統(tǒng)后，就把其中的思想作為論文發(fā)布出來了，美國(guó)科學(xué)家Doug Cutting 參考了Google這3項(xiàng)技術(shù)的原理之后，開始利用Java程序語(yǔ)言開發(fā)自家的DFS文件系統(tǒng)和MapReduce程序。Doug Cutting在2006年1月成立了獨(dú)立的開源項(xiàng)目，并且以兒子的玩具大象名字將之命名為Hadoop。

后來，Yahoo看到了Hadoop可以運(yùn)用于大量數(shù)據(jù)運(yùn)算的價(jià)值，便開始支持Hadoop項(xiàng)目，并投入不少人力和財(cái)力參與其開發(fā)工作，并開始在內(nèi)部運(yùn)用Hadoop。Yahoo甚至在2008年建置了一個(gè)當(dāng)時(shí)全球最大規(guī)模的Hadoop體系，利用4千多臺(tái)服務(wù)器，使用超過3萬(wàn)個(gè)處理器核心來索引超過16 PB的網(wǎng)頁(yè)數(shù)據(jù)。一段時(shí)間后，Google公司也參與了Hadoop項(xiàng)目的開發(fā)，并利用此項(xiàng)目作為教材，在世界各地培訓(xùn)云端運(yùn)算的開發(fā)人才，Hadoop逐漸被視為云端運(yùn)算的關(guān)鍵技術(shù)。因?yàn)橹匾匀赵觯琀adoop也在2008年成為Apache的頂級(jí)項(xiàng)目。

伴隨數(shù)據(jù)時(shí)代的發(fā)展，新興社交網(wǎng)站如臉書（Facebook）、推特（Twitter）等發(fā)展起來，由于用戶數(shù)據(jù)量劇增且數(shù)據(jù)類型大多為非結(jié)構(gòu)化數(shù)據(jù)，諸如圖片、網(wǎng)絡(luò)視頻、網(wǎng)站或聊天記錄等，于是也開始采用Hadoop來處理數(shù)據(jù)。例如Facebook就利用Hadoop打造了一個(gè)數(shù)據(jù)倉(cāng)儲(chǔ)平臺(tái)來整理和縮減龐大的用戶數(shù)據(jù)，數(shù)據(jù)量減少后再放入原有數(shù)據(jù)庫(kù)中進(jìn)行處理分析。

由于眾多行業(yè)對(duì)大規(guī)模數(shù)據(jù)處理的熱切需求，開源的Hadoop在推出之后很快得到了全球?qū)W術(shù)界和工業(yè)界的普遍關(guān)注和使用。在此過程中，大家還想要各種各樣的特性，Hadoop也得到了不斷的完善和發(fā)展。和谷歌類似，Hadoop除了最核心的存儲(chǔ)層HDFS（Hadoop分布式文件存儲(chǔ)系統(tǒng)）以及開源版本的MapReduce，類似的參照BigTable就有了Hbase。Facebook的工程師覺得MapReduce程序太難寫，于是就開發(fā)了Hive。Hive是一套能把SQL語(yǔ)句轉(zhuǎn)成MapReduce的工具，有了這套工具，只要你會(huì)SQL就可以來Hadoop上寫MapReduce程序分析數(shù)據(jù)了。對(duì)了，參考chubby，后面又有了開源的ZooKeeper來作為分布式鎖服務(wù)的提供者。

Hadoop從2006年項(xiàng)目成立開始，已經(jīng)風(fēng)風(fēng)雨雨走過了12年，從最開始的HDFS和MapReduce兩個(gè)組件開始，到現(xiàn)在已經(jīng)形成了一個(gè)完整的框架（圖3-2）。

圖3-2 Hadoop框架

最新發(fā)布的Hadoop3.0框架，除了其最核心的存儲(chǔ)層HDFS （分布式文件系統(tǒng)）和計(jì)算模型MapReduce（分布式計(jì)算），它還包括了HBase（列式數(shù)據(jù)庫(kù)）、Hive（數(shù)據(jù)倉(cāng)庫(kù)）、Sqoop（ETL工具）、Flume（日志收集）、Impala、Zookeeper（協(xié)作）、Mahout （數(shù)據(jù)挖掘）、Pig（數(shù)據(jù)流）以及Ambari（安裝、部署、配置、管理）等。

由于Hadoop最開始是用來跑文件的，對(duì)于數(shù)據(jù)的批處理來說沒什么問題，但是，如果有一天突然大家想要一個(gè)實(shí)時(shí)的查詢服務(wù)，數(shù)據(jù)這么大，要滿足實(shí)時(shí)查詢首先要拋開的是Mapreduce，因?yàn)樗俣群苈榇耍瑢W(xué)術(shù)界和業(yè)界又在不斷的研究中推出了多種大數(shù)據(jù)計(jì)算模式。2008年，一家叫Cloudera的公司出現(xiàn)了，其目標(biāo)是要做Hadoop界的redhat，把各種外圍系統(tǒng)打包進(jìn)去組成一個(gè)完整的生態(tài)系統(tǒng)，后來它開發(fā)了impala。impala的速度與MapReduce相比，實(shí)時(shí)分析的效率有了幾十倍的提升，后來Hadoop的創(chuàng)始人Doug Cutting也加入了Cloudera。這時(shí)候?qū)W院派也開始發(fā)力了，加州大學(xué)伯克利分校于2013年開發(fā)了Spark。Spark是支撐常見的大數(shù)據(jù)處理計(jì)算模式的集大成者。Spark提出了一種高效的、基于分布式內(nèi)存的抽象數(shù)據(jù)對(duì)象：彈性分布式數(shù)據(jù)集RDD。Spark在全面兼容Hadoop HDFS分布式存儲(chǔ)訪問接口的基礎(chǔ)上，通過更多的利用內(nèi)存處理大幅提高了并行化計(jì)算系統(tǒng)的性能。剛開始，Spark的語(yǔ)法比較難掌握，后來慢慢出現(xiàn)了Shark項(xiàng)目，漸漸使Spark向SQL語(yǔ)法靠近。

在一套完整的大數(shù)據(jù)處理流程中，用戶往往需要綜合多種計(jì)算模式。在支持多計(jì)算模式的大數(shù)據(jù)處理系統(tǒng)中，除了Apache Spark，還出現(xiàn)了起源于歐洲的大數(shù)據(jù)內(nèi)存計(jì)算框Apache Flink。Flink的核心是一個(gè)流式數(shù)據(jù)流引擎，它為數(shù)據(jù)的分布式計(jì)算提供了數(shù)據(jù)分布、通信、容錯(cuò)等功能，同時(shí)支持流式（Streaming）計(jì)算和批處理（Batch）計(jì)算（批處理計(jì)算當(dāng)作流式計(jì)算的一種特殊情況），并為這兩種類型的計(jì)算提供了相應(yīng)的分布式數(shù)據(jù)計(jì)算模型DataStream和Dataset及豐富的數(shù)據(jù)轉(zhuǎn)換接口。

大數(shù)據(jù)時(shí)代的計(jì)算模型：MapReduce

MapReduce是用于大數(shù)據(jù)并行計(jì)算的核心算法模型，其實(shí)，在生活中也不缺乏類似的模型。舉個(gè)簡(jiǎn)單的例子，比如我們要統(tǒng)計(jì)一個(gè)檔案館里到底保存了多少份檔案。一種方法是，找一個(gè)數(shù)數(shù)很厲害又能夠長(zhǎng)時(shí)間工作的人，由他一個(gè)人來完成這個(gè)任務(wù)。第二種方法是，找一大批數(shù)數(shù)資質(zhì)不那么好的人和一個(gè)負(fù)責(zé)分配任務(wù)的人，由分配任務(wù)的人負(fù)責(zé)劃分區(qū)域，確保每個(gè)人都分到一部分要統(tǒng)計(jì)的區(qū)域，不重復(fù)也不疏漏。隨后對(duì)所有人下發(fā)統(tǒng)計(jì)的指令，統(tǒng)計(jì)檔案的人將自己負(fù)責(zé)的區(qū)域統(tǒng)計(jì)完成后記錄下來，所有參與統(tǒng)計(jì)的人上交統(tǒng)計(jì)結(jié)果以后，負(fù)責(zé)分配任務(wù)的人將所有的統(tǒng)計(jì)結(jié)果相加，得到最后的結(jié)果。如果中途有人因?yàn)橐恍┮馔鈱?dǎo)致技術(shù)終止，那么就再派一個(gè)人去重新完成。在數(shù)據(jù)量很大的時(shí)候，第二種方案的優(yōu)越性就顯示出來了，因?yàn)閿?shù)數(shù)資質(zhì)不好的人總是容易找到的，而且個(gè)體成本較低，只要調(diào)度和統(tǒng)計(jì)的方法沒問題，第二種方案能夠確保更加快速地完成我們的任務(wù)，甚至可以通過增加數(shù)數(shù)的人來提升速度。MapReduce就是這樣一種計(jì)算模型。

大數(shù)據(jù)時(shí)代的存儲(chǔ)系統(tǒng)：HDFS

過春節(jié)的時(shí)候，家家戶戶都免不了吃一頓團(tuán)年飯。李明家親戚比較多，來了30多個(gè)人，一桌坐不下，就分為8人一桌，坐了4桌。這好比我們有一塊500 GB的硬盤，但有1000 GB的內(nèi)容需要存儲(chǔ)，一臺(tái)電腦放不下，我們可以考慮多增加幾臺(tái)，這多臺(tái)電腦形成了一個(gè)系統(tǒng)，這就是我們今天所說的分布式文件系統(tǒng)。隨之而來的問題是，假如增加的電腦每一臺(tái)都只有500 GB的存儲(chǔ)容量，如何存儲(chǔ)1000GB的內(nèi)容呢？ 事實(shí)上，如圖3-3所示，在分布式文件系統(tǒng)中，一個(gè)大的文件被切成了小塊，分別存儲(chǔ)到不同機(jī)器上。

圖3-3 文件分布式存儲(chǔ)

聰明的你也許會(huì)問，大文件被切割后，如果要查找一個(gè)文件，如何快速地知道這個(gè)文件在哪個(gè)機(jī)器上呢？我們當(dāng)然可以從頭到尾地搜索，找到需要的文件，但這樣效率太低。想想吃飯的場(chǎng)景，如圖3-4所示，李明為了照顧不同親戚的口味，為每桌都點(diǎn)了一些不同的菜品，服務(wù)員上菜時(shí)，李明會(huì)告訴他們菜上到哪桌。

圖3-4 吃飯場(chǎng)景架構(gòu)圖

我們?cè)賮砜纯捶植际轿募到y(tǒng)的架構(gòu)，如圖3-5所示，在分布式文件系統(tǒng)的架構(gòu)中，DataNode是真正存儲(chǔ)數(shù)據(jù)的地方，類似于上面場(chǎng)景的飯桌；每道菜就是一個(gè)文件切塊，NameNode的作用類似于李明，是一個(gè)管理者（Master），它知道每一個(gè)DataNode的存儲(chǔ)情況；客戶端（client）是統(tǒng)一的操作接口，類似于上面的服務(wù)員，發(fā)出查詢指令。在這樣一個(gè)體系架構(gòu)中，client要查詢或者寫入文件時(shí)，會(huì)先去詢問NameNode，看看自己應(yīng)該選擇在哪個(gè)DateNode中讀或者寫，這樣就避免了全局搜索，大大提高了文件操作的效率。

圖3-5 HDFS架構(gòu)圖

在分布式文件系統(tǒng)中，大文件被分別存儲(chǔ)在不同機(jī)器（DataNode）上，如果某個(gè)DataNode壞掉，那這個(gè)文件是否就不能訪問了呢？假如由成千上萬(wàn)的機(jī)器組成的分布式系統(tǒng)用于存儲(chǔ)PB或者EB級(jí)別的數(shù)據(jù)，即便是每臺(tái)機(jī)器出現(xiàn)故障的概率在0.01%，匯總在一起也成了大概率事件，不滿足可靠性的要求。想想吃飯的場(chǎng)景，如果某一桌的湯飛進(jìn)了蒼蠅，所幸其他桌還有同樣的湯，可以從其他桌分過來喝。這種思想在分布式文件系統(tǒng)中就是將數(shù)據(jù)進(jìn)行復(fù)制并保存多份，在寫入一個(gè)數(shù)據(jù)文件時(shí)，不會(huì)僅僅寫入一個(gè)DataNode，而會(huì)寫入多個(gè)DataNode（圖3-6）。這樣，如果其中一個(gè)DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，雖然耗費(fèi)的存儲(chǔ)空間大一些，但保證了數(shù)據(jù)的可靠性，相對(duì)于數(shù)據(jù)的價(jià)值來說，硬盤要便宜得多。

圖3-6 數(shù)據(jù)寫入

NameNode對(duì)于分布式文件系統(tǒng)是非常重要的，在Hadoop2.x之前，整個(gè)系統(tǒng)只有一個(gè)NameNode，如果這個(gè)丟失了，那整個(gè)系統(tǒng)也就丟失了。因此，在Hadoop2.x之后，可以在系統(tǒng)中配置多個(gè)NameNode，但這又增加了系統(tǒng)的復(fù)雜程度，需要考慮的問題變得更多。

總的來說，分布式文件系統(tǒng)可以存儲(chǔ)海量數(shù)據(jù)，并且保證了數(shù)據(jù)的可靠性，不會(huì)造成數(shù)據(jù)的丟失。但缺點(diǎn)也同樣明顯，比如不適合存儲(chǔ)大批量的小文件，文件寫入后無法隨機(jī)修改，只能追加，不支持并發(fā)寫入，查詢效率不高。因此，分布式文件系統(tǒng)設(shè)計(jì)的初衷在于做離線計(jì)算，在整個(gè)大數(shù)據(jù)的體系架構(gòu)中，分布式文件系統(tǒng)作為核心的數(shù)據(jù)存儲(chǔ)層位于最底層，在其上層還有接下來將介紹的分布式數(shù)據(jù)庫(kù)Hbase。

大數(shù)據(jù)時(shí)代的分布式數(shù)據(jù)庫(kù)：Hbase

Hbase是一個(gè)構(gòu)建在分布式文件系統(tǒng)（HDFS）上的分布式數(shù)據(jù)庫(kù)，支持百萬(wàn)級(jí)的高并發(fā)寫入和實(shí)時(shí)查詢。Hbase有著和傳統(tǒng)數(shù)據(jù)庫(kù)mysql完全不一樣的存儲(chǔ)方式，mysql是行式存儲(chǔ)，而Hbase是列式存儲(chǔ)。在大數(shù)據(jù)領(lǐng)域，Hbase相對(duì)于傳統(tǒng)數(shù)據(jù)庫(kù)有著巨大的數(shù)據(jù)讀寫優(yōu)勢(shì)。那什么是行式存儲(chǔ)，什么又是列式存儲(chǔ)呢？假如我們有以下的數(shù)據(jù)表（圖3-7）：

圖3-7 原始數(shù)據(jù)表

行式存儲(chǔ)就是建立一個(gè)二維的數(shù)據(jù)表（圖3-8），存儲(chǔ)在傳統(tǒng)的數(shù)據(jù)庫(kù)如mysql中：

圖3-8 行式存儲(chǔ)

行式存儲(chǔ)中，如果有較多的空數(shù)據(jù)，就會(huì)造成存儲(chǔ)空間的浪費(fèi)，因此，人們?cè)O(shè)計(jì)了列式存儲(chǔ)來解決稀疏數(shù)據(jù)的問題。同樣的數(shù)據(jù)，在Hbase中的存儲(chǔ)結(jié)構(gòu)是這樣的，也就是所謂的列式存儲(chǔ)。相當(dāng)于把每一行的每一列拆開，通過rowkey關(guān)聯(lián)起來，rowkey相同的數(shù)據(jù)其實(shí)就是原來的一行（圖3-9）。這樣既可以避免空數(shù)據(jù)的存儲(chǔ)，也使得在存儲(chǔ)量上可以達(dá)到上百萬(wàn)列。此外，由于Hbase是基于HDFS來存儲(chǔ)的，因此Hbase可以存儲(chǔ)上億行，是一個(gè)真正的海量數(shù)據(jù)庫(kù)。當(dāng)Hbase中的表達(dá)到數(shù)十億行時(shí)，每個(gè)表的大小可能達(dá)到TB級(jí)別，有時(shí)甚至PB級(jí)，這些表就會(huì)切分成小一點(diǎn)的數(shù)據(jù)單位，然后分配到多臺(tái)服務(wù)器上。這些小一點(diǎn)的數(shù)據(jù)單位叫region，管理region的服務(wù)器叫region server。一張表由多個(gè)region組成（圖3-10）。

圖3-9 列式存儲(chǔ)

圖 3-10 全表拆分為region