這篇文章是我近期準(zhǔn)備在公司做大數(shù)據(jù)分享的內(nèi)容。因?yàn)榱?xí)慣了全英文的 keynote，所以本來標(biāo)題叫《Introduction to bigdata》，但微信的英文標(biāo)題字體總覺得有些別扭，所以還是取了這么個中文名。

這篇文章的目的是帶那些對大數(shù)據(jù)不了解又有興趣的人入門。如果你是老手可以忽略，或者想看看有沒有不一樣的東西也行。

我們學(xué)習(xí)一個新知識，***步應(yīng)該是給它個明確的定義。這樣才能知道你學(xué)的是什么，哪些該學(xué)，哪些又可以先不用管。

然而，大數(shù)據(jù)雖然很火，但其實(shí)是個概念沒那么清晰的東西，不同的人可能有不同的理解。

這次我們不去糾結(jié)具體的定義，也忽略那些 4 個 V、6 個 C 之類傳統(tǒng)說教的東西，甚至不想聊架構(gòu)演進(jìn)以及各種調(diào)優(yōu)的方法，這些東西講了大家也不一定懂，懂了也記不住，記住了也用不起來。

我們也不去關(guān)注 AI、Machine Learning 那些炫酷的應(yīng)用層面的東西，而是去看看大數(shù)據(jù)這棟房子的地基是什么模樣。限于篇幅，很多技術(shù)細(xì)節(jié)點(diǎn)到即止，有興趣的同學(xué)可以再按需了解，這也正是入門的含義所在。

一

首先***個問題，大數(shù)據(jù)，大數(shù)據(jù)，多大叫大?或者換一個角度，什么時候需要用到大數(shù)據(jù)相關(guān)的技術(shù)?

這依然是個沒有標(biāo)準(zhǔn)答案的問題，有些人可能覺得幾十 G 就夠大了，也有人覺得幾十 T 也還好。當(dāng)你不知道多大叫大，或者當(dāng)你不知道該不該用大數(shù)據(jù)技術(shù)的時候，通常你就還不需要它。

而當(dāng)你的數(shù)據(jù)多到單機(jī)或者幾臺機(jī)器存不下，即使存得下也不好管理和使用的時候;當(dāng)你發(fā)現(xiàn)用傳統(tǒng)的編程方式，哪怕多進(jìn)程多線程協(xié)程全用上，數(shù)據(jù)處理速度依然很不理想的時候;當(dāng)你碰到其他由于數(shù)據(jù)量太大導(dǎo)致的實(shí)際問題的時候，可能你需要考慮下是不是該嘗試下大數(shù)據(jù)相關(guān)的技術(shù)。

二

從剛才的例子很容易能抽象出大數(shù)據(jù)的兩類典型應(yīng)用場景：

• 大量數(shù)據(jù)的存儲，解決裝不下的問題。
• 大量數(shù)據(jù)的計算，解決算得慢的問題。

因此，大數(shù)據(jù)的地基也就由存儲和計算兩部分組成。

三

我們在單機(jī)，或者說數(shù)據(jù)量沒那么大的時候，對于存儲有兩種需求：

• 文件形式的存儲
• 數(shù)據(jù)庫形式的存儲

文件形式的存儲是最基本的需求，比如各個服務(wù)產(chǎn)生的日志、爬蟲爬來的數(shù)據(jù)、圖片音頻等多媒體文件等等。對應(yīng)的是最原始的數(shù)據(jù)。

數(shù)據(jù)庫形式的存儲則通常是處理之后可以直接供業(yè)務(wù)程序化使用的數(shù)據(jù)，比如從訪問日志文件里處理得到訪問者 ip、ua 等信息保存到關(guān)系數(shù)據(jù)庫，這樣就能直接由一個 web 程序展示在頁面上。對應(yīng)的是處理后方便使用的數(shù)據(jù)。

大數(shù)據(jù)也只是數(shù)據(jù)量大而已，這兩種需求也一樣。雖然不一定嚴(yán)謹(jǐn)，但前者我們可以叫做離線(offline)存儲，后者可以叫做在線(online)存儲。

四

離線存儲這塊 HDFS(Hadoop Distributed File System) 基本上是事實(shí)上的標(biāo)準(zhǔn)。從名字可以看出，這是個分布式的文件系統(tǒng)。實(shí)際上，「分布式」也是解決大數(shù)據(jù)問題的通用方法，只有支持***橫向擴(kuò)展的分布式系統(tǒng)才能在理論上有解決***增長的數(shù)據(jù)量帶來的問題的可能性。當(dāng)然這里的***要打個引號。 

這是 HDFS 的簡易架構(gòu)圖，看起來仍然不太直觀，其實(shí)要點(diǎn)只有幾句話：

• 文件被以 block 為單位拆分后存放在不同的服務(wù)器上，每個 block 都在不同機(jī)器上做了多份冗余。
• 有 NameNode 和 DataNode 兩種角色，前者存放元數(shù)據(jù)也就是每個 block 保存在哪里，后者負(fù)責(zé)存放實(shí)際數(shù)據(jù)。
• 讀和寫數(shù)據(jù)都要先向 NameNode 拿到對應(yīng)文件的元數(shù)據(jù)，然后再找對應(yīng)的 DataNode 拿實(shí)際的數(shù)據(jù)。

可以看到，HDFS 通過集中記錄元數(shù)據(jù)的方式實(shí)現(xiàn)了分布式的效果，數(shù)據(jù)量增長只需要添加一些新的 DataNode 就可以了，單機(jī)容量不再是限制。

而為了保證數(shù)據(jù)的高可用，比如某臺服務(wù)器突然壞了再也起不來了，HDFS 通過冗余的方式(通常是 3 副本)來解決這個問題。這也是分布式系統(tǒng)里最常用的高可用方式，雖然成本可能很高。

系統(tǒng)級別的高可用才有意義，所以除了數(shù)據(jù)的高可用，元數(shù)據(jù)的高可用也至關(guān)重要。思路一樣 -- 備份。HDFS 提供了 Secondary NameNode 來提供元數(shù)據(jù)的冗余。當(dāng)然更好的方式是使用 NameNode HA 的方式，通過 active/standby 一組 NameNode 來保證不間斷的元數(shù)據(jù)讀寫服務(wù)。

同樣，擴(kuò)展性剛才也只考慮到數(shù)據(jù)的橫向擴(kuò)展，元數(shù)據(jù)呢?當(dāng)數(shù)據(jù)量大到一定程度，元數(shù)據(jù)也會非常大，類似我們在傳統(tǒng)關(guān)系數(shù)據(jù)庫里碰到的索引膨脹的問題。解決的思路是 NameNode Federation。簡單講就是把原來的一組 active/standy NameNode 拆分成多組，每組只管理一部分元數(shù)據(jù)。拆分后以類似我們在 Linux 系統(tǒng)里掛載(mount)硬盤的方法對外作為整體提供服務(wù)。這些 NameNode 組之間相互獨(dú)立，2.x 版本的 HDFS 通過 ViewFS 這個抽象在客戶端通過配置的方式實(shí)現(xiàn)對多組 NameNode 的透明訪問，3.x 版本的 HDFS 則實(shí)現(xiàn)了全新的 Router Federation 來在服務(wù)端保證對多組 NameNode 的透明訪問。

可以看到，元數(shù)據(jù)的橫向擴(kuò)展和實(shí)際數(shù)據(jù)的橫向擴(kuò)展思路完全一樣，都是拆分然后做成分布式。

五

和離線存儲對應(yīng)的是在線存儲，可以參照傳統(tǒng)的 MySQL、Oracle 等數(shù)據(jù)庫來理解。在大數(shù)據(jù)領(lǐng)域最常用的是 HBase。

數(shù)據(jù)分類的標(biāo)準(zhǔn)很多，HBase 可能被歸類為 NoSQL 數(shù)據(jù)庫、列式數(shù)據(jù)庫、分布式數(shù)據(jù)庫等等。

說它是 NoSQL 數(shù)據(jù)庫，是因?yàn)?HBase 沒有提供傳統(tǒng)關(guān)系型數(shù)據(jù)庫的很多特性。比如不支持通過 SQL 的形式讀寫數(shù)據(jù)，雖然可以集成 Apache Phoenix 等第三方方案，但畢竟原生不支持;不支持二級索引(Secondary Index)，只有順序排列的 rowkey 作為主鍵，雖然通過內(nèi)置的 Coprocessor 能實(shí)現(xiàn)，第三方的 Apache Phoenix 也提供了 SQL 語句創(chuàng)建二級索引的功能，但畢竟原生不支持;Schema 不那么結(jié)構(gòu)化和確定，只提供了列族來對列分類管理，每個列族內(nèi)的列的數(shù)量、類型都沒有限制，完全在數(shù)據(jù)寫入時確定，甚至只能通過全表掃描確定一共有哪些列。從這些角度看，HBase 甚至都不像是個 DataBase，而更像是個 DataStore。

說它是列式數(shù)據(jù)庫，是因?yàn)榈讓哟鎯σ粤凶鍨閱挝唤M織。不同行的相同列族放在一起，同一行的不同列族反而不在一起。這也就使得基于列(族)的過濾等變得更加容易。

說它是分布式數(shù)據(jù)庫，是因?yàn)樗峁┝藦?qiáng)大的橫向擴(kuò)展的能力。這也是 HBase 能成為大數(shù)據(jù)在線存儲領(lǐng)域主流方案的主要原因。

HBase 能提供超大數(shù)據(jù)量存儲和訪問的根本在于，它是基于 HDFS 的，所有的數(shù)據(jù)都以文件的形式保存在 HDFS 上。這樣就天然擁有了橫向擴(kuò)展的能力，以及高可用等特性。

解決了數(shù)據(jù)存儲的問題，剩下就需要在這個基礎(chǔ)上提供一套類似數(shù)據(jù)庫的 API 服務(wù)，并保證這套 API 服務(wù)也是可以很容易橫向擴(kuò)展的。 

上線這個架構(gòu)圖已經(jīng)足夠簡單，我們羅列幾個關(guān)鍵點(diǎn)：

• 每個節(jié)點(diǎn)上都有一個叫 RegionServer 的程序來提供對數(shù)據(jù)的讀寫服務(wù)
• 每個表被拆分成很多個 Region，然后均衡地分散在各個 RegionServer 上

另外有個 HMaster 的服務(wù)，負(fù)責(zé)對表的創(chuàng)建、修改、刪除已經(jīng) Region 相關(guān)的各種管理操作。

很容易看出，HBase 的分布式和 HDFS 非常像，RegionServer 類似于 DataNode，HMaster 類似于 NameNode，Region 類似于 Block。

只要在 HDFS 層擴(kuò)容 DataNode，在 HBase 層擴(kuò)容 RegionServer，就很容易實(shí)現(xiàn) HBase 的橫向擴(kuò)展，來滿足更多數(shù)據(jù)的讀寫需求。

細(xì)心的人應(yīng)該發(fā)現(xiàn)了，圖里沒有體現(xiàn)元數(shù)據(jù)。在 HDFS 里元數(shù)據(jù)是由 NameNode 掌控的，類似的，HBase 里的元數(shù)據(jù)由 HMaster 來掌控。HBase 里的元數(shù)據(jù)保存的是一張表有哪些 Region，又各由哪個 RegionServer 提供服務(wù)。

這些元數(shù)據(jù)，HBase 采用了很巧妙的方法保存 -- 像應(yīng)用數(shù)據(jù)那些以 HBase table 的形式保存，這樣就能像操作一張普通表一樣操作元數(shù)據(jù)了，實(shí)現(xiàn)上無疑簡單了很多。

而由于 HBase 的元數(shù)據(jù)以 Region 為粒度，遠(yuǎn)遠(yuǎn)比 HDFS 里的 block 粒度大多了，因此元數(shù)據(jù)的數(shù)據(jù)量一般也就不會成為性能瓶頸，也就不太需要再考慮元數(shù)據(jù)的橫向擴(kuò)展了。

至于高可用，存儲層面已經(jīng)有 HDFS 保障，服務(wù)層面只要提供多個 HMaster 做主備就行了。

六

存儲的話題聊到這里。下面來看看計算這塊。

和存儲類似，無論數(shù)據(jù)大小，我們可以把計算分為兩種類型：

• 離線(offline)計算，或者叫批量(batch)計算/處理
• 在線(online)計算，或者叫實(shí)時(realtime)計算、流(stream)計算/處理

區(qū)分批處理和流處理的另一個角度是處理數(shù)據(jù)的邊界。批處理對應(yīng) bounded 數(shù)據(jù)，數(shù)據(jù)量的大小有限且確定，而流處理的數(shù)據(jù)是 unbounded 的，數(shù)據(jù)量沒有邊界，程序永遠(yuǎn)執(zhí)行下去不會停止。

在大數(shù)據(jù)領(lǐng)域，批量計算一般用于用于對響應(yīng)時間和延遲不敏感的場景。有些是業(yè)務(wù)邏輯本身就不敏感，比如天級別的報表，有些則是由于數(shù)據(jù)量特別大等原因而被迫犧牲了響應(yīng)時間和延遲。而相反，流計算則用于對響應(yīng)時間和延遲敏感的場景，如實(shí)時的 PV 計算等。

批量計算的延遲一般較大，在分鐘、小時甚至天級。流處理則一般要求在毫秒或秒級完成數(shù)據(jù)處理。值得一提的是，介于兩者之間，還有準(zhǔn)實(shí)時計算的說法，延遲通常在數(shù)秒到數(shù)十秒。準(zhǔn)實(shí)時計算很自然能想到是為了在延遲和處理數(shù)據(jù)量之間達(dá)到一個可以接受的平衡。

七

批量計算在大數(shù)據(jù)領(lǐng)域最老資歷的就是 MapReduce。MapReduce 和前面提到的 HDFS 合在一起就組成了 Hadoop。而 Hadoop 多年來一直是大數(shù)據(jù)領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)基礎(chǔ)設(shè)施。從這一點(diǎn)也可以看出，我們按存儲和計算來對大數(shù)據(jù)技術(shù)做分類也是最基本的一種辦法。

MapReduce 作為一個分布式的計算框架(回想下前面說的分布式是解決大數(shù)據(jù)問題的默認(rèn)思路)，編程模型起源于函數(shù)式編程語言里的 map 和 reduce 函數(shù)。

得益于 HDFS 已經(jīng)將數(shù)據(jù)以 block 為單位切割，MapReduce 框架也就可以很輕松地將數(shù)據(jù)的初步處理以多個 map 函數(shù)的形式分發(fā)到不同的服務(wù)器上并行執(zhí)行。map 階段處理的結(jié)果又以同樣的思路分布到不同的服務(wù)器上并行做第二階段的 reduce 操作，以得到想要的結(jié)果。

以大數(shù)據(jù)領(lǐng)域的「Hello World」-- 「Word Count」為例，要計算 100 個文件共 10 T 數(shù)據(jù)里每個單詞出現(xiàn)的次數(shù)，在 map 階段可能就會有 100 個 mapper 并行去對自己分配到的數(shù)據(jù)做分詞，然后把同樣的單詞「shuffle」到同樣的 reducer 做聚合求和的操作，這些 reducer 同樣也是并行執(zhí)行，***獨(dú)立輸出各自的執(zhí)行結(jié)果，合在一起就是最終完整的結(jié)果。 

從上圖可以看到，shuffle 操作處理 map 階段的輸出以作為 reduce 階段的輸入，是個承上啟下的關(guān)鍵過程。這個過程雖然是 MapReduce 框架自動完成的，但由于涉及非常多的 IO 操作，而 IO 往往是數(shù)據(jù)處理流程中最消耗性能的部分，因此 shuffle 也就成了性能調(diào)優(yōu)的重點(diǎn)。

可以看到，正是采用了分布式計算的思想，利用了多臺服務(wù)器多核并行處理的方法，才使得我們能以足夠快的速度完成對海量數(shù)據(jù)的處理。

八

MapReduce 框架作為一個分布式計算框架，提供了基礎(chǔ)的大數(shù)據(jù)計算能力。但隨著使用場景越來越豐富，也慢慢暴露出一些問題。

資源協(xié)調(diào)

前面我們講分布式存儲的時候提到了 NameNode 這么一個統(tǒng)一管理的角色，類似的，分布式計算也需要有這么一個統(tǒng)一管理和協(xié)調(diào)的角色。更具體的說，這個角色需要承擔(dān)計算資源的協(xié)調(diào)、計算任務(wù)的分配、任務(wù)進(jìn)度和狀態(tài)的監(jiān)控、失敗任務(wù)的重跑等職責(zé)。

早期 MapReduce -- 即 MR1 -- 完整地實(shí)現(xiàn)了這些功能，居中統(tǒng)一協(xié)調(diào)的角色叫做 JobTracker，另外每個節(jié)點(diǎn)上會有一個 TaskTracker 負(fù)責(zé)收集本機(jī)資源使用情況并匯報給 JobTracker 作為分配資源的依據(jù)。

這個架構(gòu)的主要問題是 JobTracker 的職責(zé)太多了，在集群達(dá)到一定規(guī)模，任務(wù)多到一定地步后，很容易成為整個系統(tǒng)的瓶頸。

于是有了重構(gòu)之后的第二代 MapReduce -- MR2，并給它取了個新名字 YARN(Yet-Another-Resource-Negotiator)。 

JobTracker 的兩個核心功能 -- 資源管理和任務(wù)的調(diào)度/監(jiān)控被拆分開，分別由 ResourceManager 和 ApplicationMaster 來承擔(dān)。ResouerceManager 主要負(fù)責(zé)分配計算資源(其實(shí)還包括初始化和監(jiān)控 ApplicationMaster)，工作變的很簡單，不再容易成為瓶頸，部署多個實(shí)例后也很容易實(shí)現(xiàn)高可用。而 ApplicationMaster 則是每個 App 各分配一個，所有 Job 的資源申請、調(diào)度執(zhí)行、狀態(tài)監(jiān)控、重跑等都由它來組織。這樣，負(fù)擔(dān)最重的工作分散到了各個 AM 中去了，瓶頸也就不存在了。

開發(fā)成本

為了使用 MapReduce 框架，你需要寫一個 Mapper 類，這個類要繼承一些父類，然后再寫一個 map 方法來做具體的數(shù)據(jù)處理。reduce 也類似?？梢钥吹竭@個開發(fā)和調(diào)試成本還是不低的，尤其對于數(shù)據(jù)分析師等編程能力不那么突出的職位來說。

很自然的思路就是 SQL 化，要實(shí)現(xiàn)基本的數(shù)據(jù)處理，恐怕沒有比 SQL 更通用的語言了。

早期對 MapReduce 的 SQL 化主要有兩個框架實(shí)現(xiàn)。一個是 Apache Pig，一個是 Apache Hive。前者相對小眾，后者是絕大部分公司的選擇。

Hive 實(shí)現(xiàn)的基本功能就是把你的 SQL 語句解釋成一個個 MapReduce 任務(wù)去執(zhí)行。

比如我們現(xiàn)在創(chuàng)建這么一張測試表：

create table test2018(id int, name string, province string); 

然后通過 explain 命令來查看下面這條 select 語句的執(zhí)行計劃：

explain select province, count(*) from test2018 group by province; 

可以看到，Hive 把剛才的 SQL 語句解析成了 MapReduce 任務(wù)。這條 SQL 很簡單，如果是復(fù)雜的 SQL，可能會被解析成很多個連續(xù)依賴執(zhí)行的 MapReduce 任務(wù)。

另外，既然是 SQL，很自然的，Hive 還提供了庫、表這類抽象，讓你來更好的組織你的數(shù)據(jù)。甚至傳統(tǒng)的數(shù)據(jù)倉庫技術(shù)也能很好地以 Hive 為基礎(chǔ)開展。這又是另一個很大的話題，這里不再展開。

計算速度

MapReduce 每個階段的結(jié)果都需要落磁盤，然后再讀出來給下一階段處理。由于是分布式系統(tǒng)，所以也有很多需要網(wǎng)絡(luò)傳輸數(shù)據(jù)的情況。而磁盤 IO 和網(wǎng)絡(luò) IO 都是非常消耗時間的操作。后者可以通過數(shù)據(jù)本地性(locality)解決 -- 把任務(wù)分配到數(shù)據(jù)所在的機(jī)器上執(zhí)行，前者就很大程度地拖慢了程序執(zhí)行的速度。

在這個問題上解決的比較好的是 Apache Spark。 Spark 號稱基于內(nèi)存的分布式計算框架，所有計算都在內(nèi)存中進(jìn)行，只要當(dāng)內(nèi)存不夠時才會 spill 到磁盤。因此能盡可能地減少磁盤操作。

同時，Spark 基于 DAG(Directed Acyclic Graph)來組織執(zhí)行過程，知道了整個執(zhí)行步驟的先后依賴關(guān)系，也就有了優(yōu)化物理執(zhí)行計劃的可能，很多無謂和重復(fù)的 IO 操作也就被省略了。

另外一個不得不提的點(diǎn)是，MapReduce 編程模型太過簡單，導(dǎo)致很多情況下一些并不復(fù)雜的運(yùn)算卻需要好幾個 MapReduce 任務(wù)才能完成，這也嚴(yán)重拖累了性能。而 Spark 提供了類型非常豐富的操作，也很大程度上提升了性能。

編程模型

上一段提到 Spark 類型豐富的操作提升了性能，另一個好處就是開發(fā)復(fù)雜度也變低了很多。相比較之下，MapReduce 編程模型的表達(dá)能力就顯得非常羸弱了，畢竟很多操作硬要去套用先 map 再 reduce 會非常麻煩。

以分組求平均值為例，在 MapReduce 框架下，需要像前面說的那樣寫兩個類，甚至有人會寫成兩個 MapReduce 任務(wù)。

而在 Spark 里面，只要一句 ds.groupby(key).avg() 就搞定了。 真的是沒有對比就沒有傷害。

九

毫無疑問，每個人都希望數(shù)據(jù)越早算出來越好，所以實(shí)時計算或者叫流計算一直是研究和使用的熱點(diǎn)。

前面提到，Hadoop 是大數(shù)據(jù)領(lǐng)域的標(biāo)準(zhǔn)基礎(chǔ)設(shè)施，提供了 HDFS 作為存儲系統(tǒng)，以及 MapReduce 作為計算引擎，但卻并沒有提供對流處理的支持。因此，流處理這個領(lǐng)域也就出現(xiàn)了很多競爭者，沒有形成早些年 MapReduce 那樣一統(tǒng)江湖的局面。

這里我們簡單看下目前流行度***的三個流處理框架：Spark Streaming、Storm 和 Flink。

既然能各自鼎立天下，這些框架肯定也都各有優(yōu)缺點(diǎn)。篇幅有限，這里我們挑選幾個典型的維度來做對比。

編程范式

常規(guī)來說，可以把編程范式或者通俗點(diǎn)說程序的寫法分為兩類：命令式(Imperative)和聲明式(Declarative)。前者需要一步步寫清楚「怎么做」，更接近機(jī)器，后者只用寫需要「做什么」，更接近人。前文提到 WordCount 的例子，MapReduce 的版本就屬于命令式，Spark 的版本就屬于聲明式。

不難看出，命令式更繁瑣但也賦予了程序員更強(qiáng)的控制力，聲明式更簡潔但也可能會失去一定的控制力。

延遲(latency)

延遲的概念很簡單，就是一條數(shù)據(jù)從產(chǎn)生到被處理完經(jīng)歷的時間。注意這里的時間是實(shí)際經(jīng)歷的時間，而不一定是真正處理的時間。

吞吐量(throughput)

吞吐量就是單位時間內(nèi)處理數(shù)據(jù)的數(shù)量。和上面的延遲一起通常被認(rèn)為是流處理系統(tǒng)在性能上最為重要的兩個指標(biāo)。

下面我們就從這幾個維度來看看這三個流處理框架。

Spark Streaming

Spark Streaming 和我們前面提到的用于離線批處理的 Spark 基于同樣的計算引擎，本質(zhì)上是所謂的 mirco-batch，只是這個 batch 可以設(shè)置的很小，也就有了近似實(shí)時的效果。

編程范式

和離線批處理的 Spark 一樣，屬于聲明式，提供了非常豐富的操作，代碼非常簡潔。

延遲

由于是 micro-batch，延遲相對來一條處理一條的實(shí)時處理引擎會差一些，通常在秒級。當(dāng)然可以把 batch 設(shè)的更小以減小延遲，但代價是吞吐量會降低。

由于是基于批處理做的流處理，所以就決定了 Spark Streaming 延遲再怎么調(diào)優(yōu)也達(dá)不到有些場景的要求。為了解決這個問題，目前尚未正式發(fā)布的 Spark 2.3 將會支持 continuous processing，提供不遜于 native streaming 的延遲。continuous processing 顧名思義摒棄了 mirco-batch 的偽流處理，使用和 native streaming 一樣的 long-running task 來處理數(shù)據(jù)。到時候?qū)⒁耘渲玫姆绞阶層脩糇约哼x擇 micro-batch 還是 continuous processing 來做流式處理。

吞吐量

由于是 micro-batch，吞吐量比嚴(yán)格意義上的實(shí)時處理引擎高不少。從這里也可以看到，micro-batch 是個有利有弊的選擇。

Storm

Storm 的編程模型某種程度上說和 MapReduce 很像，定義了 Spout 用來處理輸入，Bolt 用來做處理邏輯。多個 Spout 和 Bolt 互相連接、依賴組成 Topology。Spout 和 Bolt 都需要像 MR 那樣定義一些類再實(shí)現(xiàn)一些具體的方法。

編程范式

很顯然屬于命令式。

延遲

Storm 是嚴(yán)格意義上的實(shí)時處理系統(tǒng)(native streaming)，來一條數(shù)據(jù)處理一條，所以延遲很低，一般在毫秒級別。

吞吐量

同樣，由于來一條數(shù)據(jù)處理一條，為了保證容錯(falt tolerance) 采用了逐條消息 ACK 的方式，吞吐量相對 Spark Streaming 這樣的 mirco-batch 引擎就差了不少。

需要補(bǔ)充說明的是，Storm 的升級版 Trident 做了非常大的改動，采用了類似 Spark Streaming 的 mirco-batch 模式，因此延遲比 Storm 高(變差了)，吞吐量比 Storm 高(變好了)，而編程范式也變成了開發(fā)成本更低的聲明式。

Flink

Flink 其實(shí)和 Spark 一樣都想做通用的計算引擎，這點(diǎn)上比 Storm 的野心要大。但 Flink 采用了和 Spark 完全相反的方式來支持自己本來不擅長的領(lǐng)域。Flink 作為 native streaming 框架，把批處理看做流處理的特殊情況來達(dá)到邏輯抽象上的統(tǒng)一。

• 編程范式

典型的聲明式。

• 延遲

和 Storm 一樣，F(xiàn)link 也是來一條處理一條，保證了很低的延遲。

• 吞吐量

實(shí)時處理系統(tǒng)中，往往低延遲帶來的就是低吞吐量(Storm)，高吞吐量又會導(dǎo)致高延遲(Spark Streaming)。這兩個性能指標(biāo)也是常見的 trade-off 了，通常都需要做取舍。

但 Flink 卻做到了低延遲和高吞吐兼得。關(guān)鍵就在于相比 Storm 每條消息都 ACK 的方式，F(xiàn)link 采取了 checkpoint 的方式來容錯，這樣也就盡可能地減小了對吞吐量的影響。

十

到此為止，批處理和流處理我們都有了大致的了解。不同的應(yīng)用場景總能二選一找到適合的方案。

然而，卻也有些情況使得我們不得不在同一個業(yè)務(wù)中同時實(shí)現(xiàn)批處理和流處理兩套方案：

• 流處理程序故障，恢復(fù)時間超過了流數(shù)據(jù)的保存時間，導(dǎo)致數(shù)據(jù)丟失。
• 類似多維度月活計算，精確計算需要保存所有用戶 id 來做去重，由此帶來的存儲開銷太大，因此只能使用 hyperloglog 等近似算法。
• ...

這些場景下，往往會采用流處理保證實(shí)時性，再加批處理校正來保證數(shù)據(jù)正確性。由此還專門產(chǎn)生了一個叫 Lambda Architecture 的架構(gòu)。 

流處理層和批處理層各自獨(dú)立運(yùn)行輸出結(jié)果，查詢層根據(jù)時間選擇用哪份結(jié)果展示給用戶。比如最近一天用流處理的實(shí)時但不一定精確的結(jié)果，超過一天就用批處理不實(shí)時但精確的結(jié)果。

Lambda Architecture 確實(shí)能解決問題，但流處理和批處理兩套程序，再加上頂在前面的查詢服務(wù)，帶來的開發(fā)和維護(hù)成本也不小。

因此，近年來也有人提出了 Kappa Architecture，帶來了另一種統(tǒng)一的思路，但也有明顯的缺點(diǎn)。限于篇幅這里不再贅述。

十一

計算框架是大數(shù)據(jù)領(lǐng)域競爭最激烈的方向之一，除了前面提到的方案，還有 Impla、Tez、 Presto、Samza 等等。很多公司都喜歡造輪子，并且都聲稱自己的輪子比別人的好。而從各個框架的發(fā)展歷程來看，又有很明顯的互相借鑒的意思。

在眾多選擇中，Spark 作為通用型分布式計算框架的野心和能力已經(jīng)得到充分的展示和證實(shí)，并且仍然在快速地進(jìn)化： Spark SQL 支持了類 Hive 的純 SQL 數(shù)據(jù)處理，Spark Streaming 支持了實(shí)時計算，Spark MLlib 支持了機(jī)器學(xué)習(xí)，Spark GraphX 支持了圖計算。而流處理和批處理底層執(zhí)行引擎的統(tǒng)一，也讓 Spark 在 Lambda Architecture 下的開發(fā)和維護(hù)成本低到可以接受。

所以，出于技術(shù)風(fēng)險、使用和維護(hù)成本的考慮，Spark 是我們做大數(shù)據(jù)計算的***。當(dāng)然，如果有些實(shí)際應(yīng)用場景 Spark 不能很好的滿足，也可以選擇其他計算框架作為補(bǔ)充。比如如果對延遲(latency) 非常敏感，那 Storm 和 Flink 就值得考慮了。

十二

如開篇所說，大數(shù)據(jù)是個非常廣的領(lǐng)域，初學(xué)者很容易迷失。希望通過這篇文章，能讓大家對大數(shù)據(jù)的基礎(chǔ)有個大概的了解。限于篇幅，很多概念和技術(shù)都點(diǎn)到即止，有興趣的同學(xué)可以再擴(kuò)展去學(xué)習(xí)。相信，打好了這個基礎(chǔ)，再去學(xué)大數(shù)據(jù)領(lǐng)域的其他技術(shù)也會輕松一些。