柚子快報(bào)邀請碼778899分享：淺談大數(shù)據(jù)生態(tài)

http://yzkb.51969.com/

大數(shù)據(jù)生態(tài)

零、引入一、初識-大數(shù)據(jù)生態(tài)二、再相識-大數(shù)據(jù)生態(tài)三、小結(jié)-大數(shù)據(jù)生態(tài)四、大數(shù)據(jù)生態(tài)圈4.1 數(shù)據(jù)采集技術(shù)框架4.2 數(shù)據(jù)存儲技術(shù)框架4.3 分布式資源管理框架4.4 數(shù)據(jù)計(jì)算技術(shù)框架4.5 數(shù)據(jù)分析技術(shù)框架4.6 任務(wù)調(diào)度技術(shù)框架4.7 大數(shù)據(jù)底層基礎(chǔ)技術(shù)框架4.8 數(shù)據(jù)檢索技術(shù)框架4.9 大數(shù)據(jù)集群安裝管理框架

零、引入

一提到大數(shù)據(jù)生態(tài)，我們都會想到 “Hadoop”。 是的，不僅僅是 “Hadoop”，還有那頭飛起來的豬，哦不，是大象。

那么，這頭飛起來的大象/Hadoop，究竟是一個(gè)什么樣的東西呢。

一、初識-大數(shù)據(jù)生態(tài)

Hadoop只是一套工具的總稱，它包含三部分：HDFS，Yarn，MapReduce 這三部分的功能分別：分布式文件存儲、資源調(diào)度和計(jì)算。

這一套相當(dāng)于用Yarn調(diào)度資源，讀取HDFS文件內(nèi)容進(jìn)行MR計(jì)算。

按理來說，這就足夠了呀，就可以完成大數(shù)據(jù)分析了。

但是，問題來了，第一個(gè)就是麻煩、太麻煩了！要寫Java代碼，需要定義Mapper和Reducer類、還需要定義主類，并在其中配置和運(yùn)行MapReduce作業(yè)等等等…

/*

1.首先，我們需要定義Mapper和Reducer類。

2.Mapper類的作用是將輸入的文本數(shù)據(jù)分割成單詞，并為每個(gè)單詞生成一個(gè)鍵值對，其中鍵是單詞，值是數(shù)字1。

3.Reducer類的作用是將具有相同鍵（即相同單詞）的所有值（即數(shù)字1）相加，得到該單詞的總出現(xiàn)次數(shù)。

*/

但做數(shù)據(jù)的最好的工具是什么？SQL！所以Hive相當(dāng)于這一套標(biāo)準(zhǔn)流程的SQL化。

Hive可以簡單理解為，Hadoop之上添加了自己的SQL解析和優(yōu)化器，寫一段SQL，解析為Java代碼，然后去執(zhí)行MR，底層數(shù)據(jù)還是在HDFS上。

這看起來挺完美，但問題是程序員發(fā)現(xiàn)好慢啊。原因是MR，它需要頻繁寫讀文件。這時(shí)基于內(nèi)存的Spark出現(xiàn)了，Spark是替代MR的，它會為SQL生成有向無環(huán)圖，加上各種算子和寬窄依賴的優(yōu)化，使得計(jì)算速度達(dá)到了新的高度。

按理說這就完美解決了呀。

但是，我們是不是到目前為止都是在處理靜態(tài)的數(shù)據(jù)呢？像比如線上支付校驗(yàn)這種需要實(shí)時(shí)返回結(jié)果的總不能等著Spark批量算吧。

解決問題之前，我們再想想，數(shù)據(jù)怎么來的。一般數(shù)據(jù)包含兩種：業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)。

業(yè)務(wù)數(shù)據(jù)就是數(shù)據(jù)庫中的結(jié)構(gòu)性的數(shù)據(jù)，規(guī)規(guī)整整。業(yè)務(wù)數(shù)據(jù)怎么到Hive呢？開源上一般通過Sqoop進(jìn)行導(dǎo)入，比如一張表，數(shù)據(jù)少每天我把表全部導(dǎo)入一遍，這叫全量同步；數(shù)據(jù)特別大，就只同步每天變化和新增的，這是增量同步。

但這種同步比較滯后，都是在夜深人靜集群的計(jì)算資源比較空閑的時(shí)候做的，對應(yīng)的也是離線分析。

實(shí)時(shí)的數(shù)據(jù)產(chǎn)生了該怎么拿到呢？

實(shí)時(shí)怎么理解？來一批處理一批，再細(xì)一點(diǎn)兒，來一條，處理一條。

比如，你買一件東西，平臺數(shù)據(jù)庫中會多一條訂單數(shù)據(jù)，app會產(chǎn)生行為日志數(shù)據(jù)。訂單數(shù)據(jù)插入數(shù)據(jù)庫時(shí)一般會有binlog，即記錄插入、更新或刪除的數(shù)據(jù)，我們只要能實(shí)時(shí)拿到這一條binlog，就相當(dāng)于拿到了實(shí)時(shí)數(shù)據(jù)。

binlog怎么拿呢？這就要說道數(shù)據(jù)庫的主從備份機(jī)制，一般本身就是拿主庫的binlog同步到備份庫，剛好有一個(gè)叫 Canal 的工具可以把自己偽裝成備份庫，來拉取主庫的binlog，再解析、包裝最后拋出，就相當(dāng)于實(shí)時(shí)拿到數(shù)據(jù)了！

Canal 拿到了binlog就能直接處理了嗎？可以，但有件事兒大家想一想。馬上十一長假了，加入一下子超級多人下單消費(fèi)，Canal 拋出的消息我們下游一下子消費(fèi)不完咋辦呢？比如快遞員每天都只給你派送一件快遞，你拿到之后錢貨兩清。然后突然一天快遞員給你送一千件到你樓下，你下樓一件一件搬，快遞員還得等你搬完才能回去，這得等到啥時(shí)候。聰明的你馬上想到了，放快遞柜呀，你有時(shí)間慢慢搬不就行了，也不占用快遞員的時(shí)間了。

這就是消息隊(duì)列/MessageQueue，Kafka 就是起這樣的作用：異步、解耦、消峰。Canal 的數(shù)據(jù)一般會拋到 Kafka或RocketMQ，可以保存一段時(shí)間。然后下游程序再去實(shí)時(shí)拉取消息來計(jì)算。

說了這么多下游，下游到底由誰來消費(fèi)計(jì)算這些實(shí)時(shí)數(shù)據(jù)呢？還記得Spark嗎，沒錯(cuò)它又來了，Spark streaming 就是處理實(shí)時(shí)流數(shù)據(jù)的好手。

Spark 是一整套組件的統(tǒng)稱，比如你可以用 Java 寫 Spark 任務(wù)，用 Spark SQL 去寫 SQL，可以用 Spark MLib 完成機(jī)器學(xué)習(xí)的模型訓(xùn)練等等，Spark Streaming 就是用來微批地處理流式數(shù)據(jù)的。

具體而言，離線數(shù)據(jù)我們是等半夜數(shù)據(jù)都抽到 Hive 中再計(jì)算，而 Spark Streaming 則是實(shí)時(shí)數(shù)據(jù)來一小批，它就處理一小批。所以本質(zhì)上講，Spark Streaming 還是批處理，只不過是每一批數(shù)據(jù)很少，并且處理很及時(shí)，從而達(dá)到實(shí)時(shí)計(jì)算的目的。

Spark 本身的流行使得 Spark Streaming 也一直大范圍使用。

那么，這一套有什么邏輯缺陷嗎？

我們可以想一想，實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)最大的差異，是時(shí)效性。離線數(shù)據(jù)像湖水，該多少就多少，就在那里；實(shí)時(shí)數(shù)據(jù)像水流，綿綿不絕。時(shí)間，便是非常重要的一個(gè)特質(zhì)。當(dāng)一條數(shù)據(jù)來的時(shí)候，我們需要知道這條數(shù)據(jù)是什么時(shí)候產(chǎn)生的，這便是業(yè)務(wù)時(shí)間。但我們拿到這條數(shù)據(jù)時(shí)往往是業(yè)務(wù)時(shí)間之后的一小會，這邊是處理時(shí)間。真正世界里的實(shí)時(shí)數(shù)據(jù)肯定不是像 Spark Streaming 那樣一批一批來的，而是一個(gè)一個(gè)的事件。對此，F(xiàn)link 幫助我們解決了這些問題。

二、再相識-大數(shù)據(jù)生態(tài)

大數(shù)據(jù)本身是個(gè)很寬泛的概念，Hadoop生態(tài)圈（或者泛生態(tài)圈）基本上都是為了處理超過單機(jī)尺度的數(shù)據(jù)處理而誕生的。

可以把它比作一個(gè)廚房所以需要的各種工具。鍋碗瓢盆，各有各的用處，互相之間又有重合。你可以用湯鍋直接當(dāng)碗吃飯喝湯，你可以用小刀或者刨子去皮。但是每個(gè)工具有自己的特性，雖然奇怪的組合也能工作，但是未必是最佳選擇。

大數(shù)據(jù)，首先你要能存的下大數(shù)據(jù)。

傳統(tǒng)的文件系統(tǒng)是單機(jī)的，不能橫跨不同的機(jī)器。HDFS（Hadoop Distributed FileSystem）的設(shè)計(jì)本質(zhì)上是為了大量的數(shù)據(jù)能橫跨成百上千臺機(jī)器，但是你看到的是一個(gè)文件系統(tǒng)而不是很多文件系統(tǒng)。

比如你說我要獲取/hdfs/tmp/file1的數(shù)據(jù)，你引用的是一個(gè)文件路徑，但是實(shí)際的數(shù)據(jù)存放在很多不同的機(jī)器上。你作為用戶，不需要知道這些，就好比在單機(jī)上你不關(guān)心文件分散在什么磁道什么扇區(qū)一樣。

HDFS為你管理這些數(shù)據(jù)。

存的下數(shù)據(jù)之后，我們就開始考慮怎么處理數(shù)據(jù)。

雖然HDFS可以為你整體管理不同機(jī)器上的數(shù)據(jù)，但是這些數(shù)據(jù)太大了。一臺機(jī)器讀取成T上P的數(shù)據(jù)（很大的數(shù)據(jù)哦，比如整個(gè)東京熱有史以來所有高清電影的大小甚至更大），一臺機(jī)器慢慢跑也許需要好幾天甚至好幾周。

對于很多公司來說，單機(jī)處理是不可忍受的，比如微博要更新24小時(shí)熱博，它必須在24小時(shí)之內(nèi)跑完這些處理。那么我如果要用很多臺機(jī)器處理，我就面臨了如何分配工作，如果一臺機(jī)器掛了如何重新啟動(dòng)相應(yīng)的任務(wù)，機(jī)器之間如何互相通信交換數(shù)據(jù)以完成復(fù)雜的計(jì)算等等。

這就是MapReduce / Tez / Spark的功能。MapReduce是第一代計(jì)算引擎，Tez和Spark是第二代。MapReduce的設(shè)計(jì)，采用了很簡化的計(jì)算模型，只有Map和Reduce兩個(gè)計(jì)算過程（中間用Shuffle串聯(lián)），用這個(gè)模型，已經(jīng)可以處理大數(shù)據(jù)領(lǐng)域很大一部分問題了。

那什么是Map什么是Reduce？

考慮：如果你要統(tǒng)計(jì)一個(gè)巨大的文本文件存儲在類似HDFS上，你想要知道這個(gè)文本里各個(gè)詞的出現(xiàn)頻率。

你啟動(dòng)了一個(gè)MapReduce程序。Map階段，幾百臺機(jī)器同時(shí)讀取這個(gè)文件的各個(gè)部分，分別把各自讀到的部分分別統(tǒng)計(jì)出詞頻，產(chǎn)生類似（hello, 12100次），（world，15214次）等等這樣的Pair（我這里把Map和Combine放在一起說以便簡化）。

這幾百臺機(jī)器各自都產(chǎn)生了如上的集合，然后又有幾百臺機(jī)器啟動(dòng)Reduce處理。Reducer機(jī)器A將從Mapper機(jī)器收到所有以A開頭的統(tǒng)計(jì)結(jié)果，機(jī)器B將收到B開頭的詞匯統(tǒng)計(jì)結(jié)果（當(dāng)然實(shí)際上不會真的以字母開頭做依據(jù)，而是用函數(shù)產(chǎn)生Hash值以避免數(shù)據(jù)串化。因?yàn)轭愃芚開頭的詞肯定比其他要少得多，而你不希望數(shù)據(jù)處理各個(gè)機(jī)器的工作量相差懸殊）。然后這些Reducer將再次匯總，（hello，12100）＋（hello，12311）＋（hello，345881）= （hello，370292）。每個(gè)Reducer都如上處理，你就得到了整個(gè)文件的詞頻結(jié)果。

這看似是個(gè)很簡單的模型，但很多算法都可以用這個(gè)模型描述了。

Map＋Reduce的簡單模型很暴力，雖然好用，但是很笨重。

第二代的Tez和Spark除了內(nèi)存Cache之類的新功能/特性，本質(zhì)上來說，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊，數(shù)據(jù)交換更靈活，更少的磁盤讀寫，以便更方便地描述復(fù)雜算法，取得更高的吞吐量。

有了MapReduce，Tez和Spark之后，程序員發(fā)現(xiàn)，MapReduce的程序?qū)懫饋碚媛闊?。他們希望簡化這個(gè)過程。

這就好比你有了匯編語言，雖然你幾乎什么都能干了，但是你還是覺得繁瑣。你希望有個(gè)更高層更抽象的語言層來描述算法和數(shù)據(jù)處理流程。于是就有了Pig和Hive。

Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計(jì)算引擎去計(jì)算，而你就從繁瑣的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了。

有了Hive之后，人們發(fā)現(xiàn)SQL對比Java有巨大的優(yōu)勢。一個(gè)是它太容易寫了。剛才詞頻的東西，用SQL描述就只有一兩行，MapReduce寫起來大約要幾十上百行。

而更重要的是，非計(jì)算機(jī)背景的用戶終于感受到了愛：我也會寫SQL！于是數(shù)據(jù)分析人員終于從乞求工程師幫忙的窘境解脫出來，工程師也從寫奇怪的一次性的處理程序中解脫出來。大家都開心了。Hive逐漸成長成了大數(shù)據(jù)倉庫的核心組件。甚至很多公司的流水線作業(yè)集完全是用SQL描述，因?yàn)橐讓懸赘?，一看就懂，容易維護(hù)。

自從數(shù)據(jù)分析人員開始用Hive分析數(shù)據(jù)之后，它們發(fā)現(xiàn)，Hive在MapReduce上跑，真慢啊啊?。。×魉€作業(yè)集也許沒啥關(guān)系，比如24小時(shí)更新的推薦，反正24小時(shí)內(nèi)跑完就算了。

但是數(shù)據(jù)分析，人們總是希望能跑更快一些。比如我希望看過去一個(gè)小時(shí)內(nèi)多少人在充氣娃娃頁面駐足，分別停留了多久，對于一個(gè)巨型網(wǎng)站海量數(shù)據(jù)下，這個(gè)處理過程也許要花幾十分鐘甚至很多小時(shí)。而這個(gè)分析也許只是你萬里長征的第一步，你還要看多少人瀏覽了跳蛋多少人看了拉赫曼尼諾夫的CD，以便跟老板匯報(bào)，我們的用戶是猥瑣男悶騷女更多還是文藝青年／少女更多。你無法忍受等待的折磨，只能跟帥帥的工程師蟈蟈說，快，快，再快一點(diǎn)！

于是，Impala，Presto，Drill 誕生了（當(dāng)然還有無數(shù)非著名的交互SQL引擎，就不一一列舉了）。三個(gè)系統(tǒng)的核心理念是，MapReduce引擎太慢，因?yàn)樗ㄓ茫珡?qiáng)壯，太保守，我們SQL需要更輕量，更激進(jìn)地獲取資源，更專門地對SQL做優(yōu)化，而且不需要那么多容錯(cuò)性保證（因?yàn)橄到y(tǒng)出錯(cuò)了大不了重新啟動(dòng)任務(wù)，如果整個(gè)處理時(shí)間更短的話，比如幾分鐘之內(nèi)）。這些系統(tǒng)讓用戶更快速地處理SQL任務(wù)，犧牲了通用性穩(wěn)定性等特性。

如果說MapReduce是大砍刀，砍啥都不怕，那上面三個(gè)（Impala，Presto，Drill）就是剔骨刀，靈巧鋒利，但是不能搞太大太硬的東西。

這些系統(tǒng)，說實(shí)話，一直沒有達(dá)到人們期望的流行度。

因?yàn)檫@時(shí)候又兩個(gè)異類被造出來了。他們是Hive on Tez / Spark和SparkSQL。它們的設(shè)計(jì)理念是，MapReduce慢，但是如果我用新一代通用計(jì)算引擎Tez或者Spark來跑SQL，那我就能跑的更快。而且用戶不需要維護(hù)兩套系統(tǒng)。

這就好比如果你廚房小，人又懶，對吃的精細(xì)程度要求有限，那你可以買個(gè)電飯煲，能蒸能煲能燒，省了好多廚具。

截至目前，基本就是一個(gè)數(shù)據(jù)倉庫的構(gòu)架了。底層HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig?；蛘逪DFS上直接跑Impala，Drill，Presto。這解決了中低速數(shù)據(jù)處理的要求。

那如果我要更高速的處理呢？

如果我是一個(gè)類似微博的公司，我希望顯示不是24小時(shí)熱博，我想看一個(gè)不斷變化的熱播榜，更新延遲在一分鐘之內(nèi)，上面的手段都將無法勝任。

于是又一種計(jì)算模型被開發(fā)出來，這就是Streaming（流）計(jì)算。Storm是最流行的流計(jì)算平臺。流計(jì)算的思路是，如果要達(dá)到更實(shí)時(shí)的更新，我何不在數(shù)據(jù)流進(jìn)來的時(shí)候就處理了？比如還是詞頻統(tǒng)計(jì)的例子，我的數(shù)據(jù)流是一個(gè)一個(gè)的詞，我就讓他們一邊流過我就一邊開始統(tǒng)計(jì)了。

流計(jì)算很牛逼，基本無延遲，但是它的短處是，不靈活，你想要統(tǒng)計(jì)的東西必須預(yù)先知道，畢竟數(shù)據(jù)流過就沒了，你沒算的東西就無法補(bǔ)算了。因此它是個(gè)很好的東西，但是無法替代上面數(shù)據(jù)倉庫和批處理系統(tǒng)。

還有一個(gè)有些獨(dú)立的模塊是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的（多到無法想象）。所以KV Store就是說，我有一堆鍵值，我能很快速滴獲取與這個(gè)Key綁定的數(shù)據(jù)。

比如我用身份證號，能取到你的身份數(shù)據(jù)。這個(gè)動(dòng)作用MapReduce也能完成，但是很可能要掃描整個(gè)數(shù)據(jù)集。而KV Store專用來處理這個(gè)操作，所有存和取都專門為此優(yōu)化了。從幾個(gè)P的數(shù)據(jù)中查找一個(gè)身份證號，也許只要零點(diǎn)幾秒。

這讓大數(shù)據(jù)公司的一些專門操作被大大優(yōu)化了。比如我網(wǎng)頁上有個(gè)根據(jù)訂單號查找訂單內(nèi)容的頁面，而整個(gè)網(wǎng)站的訂單數(shù)量無法單機(jī)數(shù)據(jù)庫存儲，我就會考慮用KV Store來存。KV Store的理念是，基本無法處理復(fù)雜的計(jì)算，大多沒法JOIN，也許沒法聚合，沒有強(qiáng)一致性保證（不同數(shù)據(jù)分布在不同機(jī)器上，你每次讀取也許會讀到不同的結(jié)果，也無法處理類似銀行轉(zhuǎn)賬那樣的強(qiáng)一致性要求的操作）。

但是就是快。極快。除此之外，還有一些更特制的系統(tǒng)／組件，比如Mahout是分布式機(jī)器學(xué)習(xí)庫，Protobuf是數(shù)據(jù)交換的編碼和庫，ZooKeeper是高一致性的分布存取協(xié)同系統(tǒng)，等等。

有了這么多亂七八糟的工具，都在同一個(gè)集群上運(yùn)轉(zhuǎn)，大家需要互相尊重有序工作。所以另外一個(gè)重要組件是，調(diào)度系統(tǒng)?，F(xiàn)在最流行的是Yarn。你可以把他看作中央管理，好比你媽在廚房監(jiān)工，哎，你妹妹切菜切完了，你可以把刀拿去殺雞了。只要大家都服從你媽分配，那大家都能愉快滴燒菜。

你可以認(rèn)為，大數(shù)據(jù)生態(tài)圈就是一個(gè)廚房工具生態(tài)圈。為了做不同的菜，中國菜，日本菜，法國菜，你需要各種不同的工具。而且客人的需求正在復(fù)雜化，你的廚具不斷被發(fā)明，也沒有一個(gè)萬用的廚具可以處理所有情況，因此它會變的越來越復(fù)雜。

三、小結(jié)-大數(shù)據(jù)生態(tài)

大數(shù)據(jù)技術(shù)體系，雖然各種技術(shù)百花齊放，層出不窮。 但大數(shù)據(jù)技術(shù)本質(zhì)上無非解決4個(gè)核心問題。

【存儲】海量的數(shù)據(jù)怎樣有效的存儲？

主要包括hdfs、Kafka。

【計(jì)算】海量的數(shù)據(jù)怎樣快速計(jì)算？

主要包括MapReduce、Spark、Flink等。

【查詢】海量數(shù)據(jù)怎樣快速查詢？

主要為Nosql和Olap：Nosql主要包括Hbase、Cassandra 等，其中Olap包括Kylin、Impala等；其中Nosql主要解決隨機(jī)查詢，Olap技術(shù)主要解決關(guān)聯(lián)查詢。

【挖掘】海量數(shù)據(jù)怎樣挖掘出隱藏的知識？

也就是當(dāng)前火熱的機(jī)器學(xué)習(xí)和深度學(xué)習(xí)等技術(shù)，包括TensorFlow、Caffe、Mahout等。

1，傳統(tǒng)數(shù)據(jù)倉庫派說 MapReduce 修煉太復(fù)雜，老子不會編程，老子以前用SQL吃遍天下，為了將這撥人收入門下，并降低大數(shù)據(jù)修煉難度，遂出了Hive，Pig、Impala 等SQL ON Hadoop的簡易修煉秘籍；

2，伯克利派說 MapReduce 只重招數(shù)，內(nèi)力無法施展，且不同的場景需要修煉不同的技術(shù)，太過復(fù)雜，于是推出基于內(nèi)力（內(nèi)存）的《Spark》，意圖解決所有大數(shù)據(jù)計(jì)算問題。

3，流式計(jì)算相關(guān)門派說 Hadoop 只能憋大招（批量計(jì)算），太麻煩，于是出了SparkStreaming、Storm，S4 等流式計(jì)算技術(shù)，能夠?qū)崿F(xiàn)數(shù)據(jù)一來就即時(shí)計(jì)算。

4，Apache看各大門派紛爭四起，推出 Flink，想一統(tǒng)流計(jì)算和批量計(jì)算的修煉。

四、大數(shù)據(jù)生態(tài)圈

大數(shù)據(jù)生態(tài)圈中的核心技術(shù)總結(jié)下來如圖①所示，分為以下9類：

4.1 數(shù)據(jù)采集技術(shù)框架

數(shù)據(jù)采集也被稱為數(shù)據(jù)同步。

隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等技術(shù)的興起，產(chǎn)生了海量數(shù)據(jù)。這些數(shù)據(jù)散落在各個(gè)地方，我們需要將這些數(shù)據(jù)融合到一起，然后從這些海量數(shù)據(jù)中計(jì)算出一些有價(jià)值的內(nèi)容。此時(shí)第一步需要做的是把數(shù)據(jù)采集過來。

數(shù)據(jù)采集是大數(shù)據(jù)的基礎(chǔ)，沒有數(shù)據(jù)采集，何談大數(shù)據(jù)！

Sqoop 和 Datax 常用于關(guān)系型數(shù)據(jù)庫，離線數(shù)據(jù)采集。

Cannal 和 Maxwell 常用于關(guān)系型數(shù)據(jù)庫，實(shí)時(shí)數(shù)據(jù)采集。

4.2 數(shù)據(jù)存儲技術(shù)框架

數(shù)據(jù)的快速增長推動(dòng)了技術(shù)的發(fā)展，涌現(xiàn)出了一批優(yōu)秀的、支持分布式的存儲系統(tǒng)。

數(shù)據(jù)存儲技術(shù)框架包括HDFS、HBase、Kudu、Kafka等。

HDFS它可以解決海量數(shù)據(jù)存儲的問題，但是其最大的缺點(diǎn)是不支持單條數(shù)據(jù)的修改操作，因?yàn)樗吘共皇菙?shù)據(jù)庫。HBase是一個(gè)基于HDFS的分布式NoSQL數(shù)據(jù)庫。這意味著，HBase可以利用HDFS的海量數(shù)據(jù)存儲能力，并支持修改操作。但HBase并不是關(guān)系型數(shù)據(jù)庫，所以它無法支持傳統(tǒng)的SQL語法。Kudu是介于HDFS和HBase之間的技術(shù)組件，既支持?jǐn)?shù)據(jù)修改，也支持基于SQL的數(shù)據(jù)分析功能；目前Kudu的定位比較尷尬，屬于一個(gè)折中的方案，在實(shí)際工作中應(yīng)用有限。Kafka常用于海量數(shù)據(jù)的臨時(shí)緩沖存儲，對外提供高吞吐量的讀寫能力。

4.3 分布式資源管理框架

在傳統(tǒng)的IT領(lǐng)域中，企業(yè)的服務(wù)器資源（內(nèi)存、CPU等）是有限的，也是固定的。但是，服務(wù)器的應(yīng)用場景卻是靈活多變的。例如，今天臨時(shí)上線了一個(gè)系統(tǒng)，需要占用幾臺服務(wù)器；過了幾天，需要把這個(gè)系統(tǒng)下線，把這幾臺服務(wù)器清理出來。

在大數(shù)據(jù)時(shí)代到來之前，服務(wù)器資源的變更對應(yīng)的是系統(tǒng)的上線和下線，這些變動(dòng)是有限的。

隨著大數(shù)據(jù)時(shí)代的到來，臨時(shí)任務(wù)的需求量大增，這些任務(wù)往往需要大量的服務(wù)器資源。如果此時(shí)還依賴運(yùn)維人員人工對接服務(wù)器資源的變更，顯然是不現(xiàn)實(shí)的。

因此，分布式資源管理系統(tǒng)應(yīng)運(yùn)而生，常見的包括YARN、Kubernetes和Mesos，它們的典型應(yīng)用領(lǐng)域如圖所示。

4.4 數(shù)據(jù)計(jì)算技術(shù)框架

數(shù)據(jù)計(jì)算分為離線數(shù)據(jù)計(jì)算和實(shí)時(shí)數(shù)據(jù)計(jì)算。

（1）離線數(shù)據(jù)計(jì)算

大數(shù)據(jù)中的離線數(shù)據(jù)計(jì)算引擎經(jīng)過十幾年的發(fā)展，到目前為止主要發(fā)生了3次大的變更。

MapReduce可以稱得上是大數(shù)據(jù)行業(yè)的第一代離線數(shù)據(jù)計(jì)算引擎，主要用于解決大規(guī)模數(shù)據(jù)集的分布式并行計(jì)算。MapReduce計(jì)算引擎的核心思想是，將計(jì)算邏輯抽象成Map和Reduce兩個(gè)階段進(jìn)行處理。Tez計(jì)算引擎在大數(shù)據(jù)技術(shù)生態(tài)圈中的存在感較弱，實(shí)際工作中很少會單獨(dú)使用Tez去開發(fā)計(jì)算程序。Spark最大的特點(diǎn)就是內(nèi)存計(jì)算：任務(wù)執(zhí)行階段的中間結(jié)果全部被放在內(nèi)存中，不需要讀寫磁盤，極大地提高了數(shù)據(jù)的計(jì)算性能。Spark提供了大量高階函數(shù)（也可以稱之為算子），可以實(shí)現(xiàn)各種復(fù)雜邏輯的迭代計(jì)算，非常適合應(yīng)用在海量數(shù)據(jù)的快速且復(fù)雜計(jì)算需求中。

（2）實(shí)時(shí)數(shù)據(jù)計(jì)算

業(yè)內(nèi)最典型的實(shí)時(shí)數(shù)據(jù)計(jì)算場景是天貓“雙十一”的數(shù)據(jù)大屏。

數(shù)據(jù)大屏中展現(xiàn)的成交總金額、訂單總量等數(shù)據(jù)指標(biāo)，都是實(shí)時(shí)計(jì)算出來的。

用戶購買商品后，商品的金額就會被實(shí)時(shí)增加到數(shù)據(jù)大屏中的成交總金額中。

用于實(shí)時(shí)數(shù)據(jù)計(jì)算的工具主要有以下3種。

Storm主要用于實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)分布式計(jì)算。Flink屬于新一代實(shí)時(shí)數(shù)據(jù)分布式計(jì)算引擎，其計(jì)算性能和生態(tài)圈都優(yōu)于Storm。Spark中的SparkStreaming組件也可以提供基于秒級別的實(shí)時(shí)數(shù)據(jù)分布式計(jì)算功能。

Spark Streaming和Storm、Flink之間的區(qū)別見表。

目前企業(yè)中離線計(jì)算主要使用Spark，實(shí)時(shí)計(jì)算主要使用Flink。

4.5 數(shù)據(jù)分析技術(shù)框架

數(shù)據(jù)分析技術(shù)框架包括Hive、Impala、Kylin、Clickhouse、Druid、Doris等，它們的典型應(yīng)用場景如圖所示。

Hive、Impala和Kylin屬于典型的離線OLAP（Online AnalyticalProcessing）數(shù)據(jù)分析引擎，主要應(yīng)用在離線數(shù)據(jù)分析領(lǐng)域。

Hive的執(zhí)行效率一般，但是穩(wěn)定性極高；Impala基于內(nèi)存可以提供優(yōu)秀的執(zhí)行效率，但是穩(wěn)定性一般；Kylin通過預(yù)計(jì)算可以提供PB級別數(shù)據(jù)毫秒級響應(yīng)。

Clickhouse、Druid和Doris屬于典型的實(shí)時(shí)OLAP數(shù)據(jù)分析引擎，主要應(yīng)用在實(shí)時(shí)數(shù)據(jù)分析領(lǐng)域。

Druid和Doris是可以支持高并發(fā)的，ClickHouse的并發(fā)能力有限；Druid中的SQL支持是有限的，ClickHouse支持非標(biāo)準(zhǔn)SQL，Doris支持標(biāo)準(zhǔn)SQL，對SQL支持比較好。Druid和ClickHouse的成熟程度目前相對比較高，Doris處于快速發(fā)展階段。

4.6 任務(wù)調(diào)度技術(shù)框架

任務(wù)調(diào)度技術(shù)框架包括Azkaban、Ooize、DolphinScheduler等。

它們適用于普通定時(shí)執(zhí)行的例行化任務(wù)，以及包含復(fù)雜依賴關(guān)系的多級任務(wù)進(jìn)行調(diào)度，支持分布式，保證調(diào)度系統(tǒng)的性能和穩(wěn)定性，它們之間的區(qū)別見表。

4.7 大數(shù)據(jù)底層基礎(chǔ)技術(shù)框架

大數(shù)據(jù)底層基礎(chǔ)技術(shù)框架主要是指Zookeeper。Zookeepe主要提供常用的基礎(chǔ)功能（例如：命名空間、配置服務(wù)等），大數(shù)據(jù)生態(tài)圈中的Hadoop（HA）、HBase、Kafka等技術(shù)組件的運(yùn)行都會用到Zookeeper。

4.8 數(shù)據(jù)檢索技術(shù)框架

隨著企業(yè)中數(shù)據(jù)的逐步積累，針對海量數(shù)據(jù)的統(tǒng)計(jì)分析需求會變得越來越多樣化：不僅要進(jìn)行分析，還要實(shí)現(xiàn)多條件快速復(fù)雜查詢。例如，電商網(wǎng)站中的商品搜索功能，以及各種搜索引擎中的信息檢索功能，這些功能都屬于多條件快速復(fù)雜查詢的范疇。

在選擇全文檢索引擎工具時(shí)，可以從易用性、擴(kuò)展性、穩(wěn)定性、集群運(yùn)維難度、項(xiàng)目集成程度、社區(qū)活躍度這幾個(gè)方面進(jìn)行對比。Lucene、Solr和Elasticsearch的對比見表。

4.9 大數(shù)據(jù)集群安裝管理框架

企業(yè)如果想從傳統(tǒng)的數(shù)據(jù)處理轉(zhuǎn)型到大數(shù)據(jù)處理，首先要做就是搭建一個(gè)穩(wěn)定可靠的大數(shù)據(jù)平臺。

一個(gè)完整的大數(shù)據(jù)平臺需要包含數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)計(jì)算、數(shù)據(jù)分析、集群監(jiān)控等功能，這就意味著其中需要包含F(xiàn)lume、Kafka、HaDoop、Hive、HBase、Spark、Flink等組件，這些組件需要部署到上百臺甚至上千臺機(jī)器中。

如果依靠運(yùn)維人員單獨(dú)安裝每一個(gè)組件，則工作量比較大，而且需要考慮版本之間的匹配問題及各種沖突問題，并且后期集群維護(hù)工作也會給運(yùn)維人員造成很大的壓力。

于是，國外一些廠商就對大數(shù)據(jù)中的組件進(jìn)行了封裝，提供了一體化的大數(shù)據(jù)平臺，利用它可以快速安裝大數(shù)據(jù)組件。目前業(yè)內(nèi)最常見的是包括CDH、HDP、CDP等。

HDP：全稱是 Hortonworks Data Platform。它由 Hortonworks 公司基于 Apache Hadoop 進(jìn)行了封裝，借助于 Ambari 工具提供界面化安裝和管理，并且集成了大數(shù)據(jù)中的常見組件， 可以提供一站式集群管理。HDP 屬于開源版免費(fèi)大數(shù)據(jù)平臺，沒有提供商業(yè)化服務(wù)；CDH：全稱是 Cloudera Distribution Including Apache Hadoop。它由 Cloudera 公司基于 Apache Hadoop 進(jìn)行了商業(yè)化，借助于 Cloudera Manager 工具提供界面化安裝和管理，并且集成了大數(shù)據(jù)中的常見組件，可以提供一站式集群管理。CDH 屬于商業(yè)化收費(fèi)大數(shù)據(jù)平臺，默認(rèn)可以試用 30 天。之后，如果想繼續(xù)使用高級功能及商業(yè)化服務(wù)，則需要付費(fèi)購買授權(quán)，如果只使用基礎(chǔ)功能，則可以繼續(xù)免費(fèi)使用；CDP：Cloudera 公司在 2018 年 10 月份收購了 Hortonworks，之后推出了新一代的大數(shù)據(jù)平臺產(chǎn)品 CDP（Cloudera Data Center）。CDP 的版本號延續(xù)了之前 CDH 的版本號。從 7.0 版本開始， CDP 支持 Private Cloud（私有云）和 Hybrid Cloud（混合云）。CDP 將 HDP 和 CDH 中比較優(yōu)秀的組件進(jìn)行了整合，并且增加了一些新的組件。

淺談了一下關(guān)于大數(shù)據(jù)生態(tài)，以上，分享結(jié)束。

柚子快報(bào)邀請碼778899分享：淺談大數(shù)據(jù)生態(tài)

http://yzkb.51969.com/

文章來源