1.1 大數據處理架構演進歷程

谷歌發表的三篇劃時代論文（分別介紹MapReduce、GFS和BigTable），特別是介紹MapReduce的那篇論文，開啟了大規模數據處理波瀾壯闊的發展歷程。一篇篇論文和那些大數據從業者耳熟能詳的大數據處理架構，是這個歷程中的重要里程碑，圖1-1所示為主流大數據處理架構的發展歷程。

2003年，谷歌的工程師便開始構建各種定制化數據處理系統，以解決大規模數據處理的幾大難題：大規模數據處理特別困難（Data Processing is hard），這里的難有多個方面，僅僅是在大規模數據上構建一個處理程序也不是一件容易的事情；保證可伸縮性很難（Scalability is hard），讓處理程序在不同規模的集群上運行，或者更進一步，讓程序根據計算資源狀況自動調度執行，也不是一件容易的事情；容錯很難（Fault-tolerance is hard），讓處理程序在由廉價機器組成的集群上可靠地運行，更不是一件容易的事情。這些困難促使 MapReduce（不是 Hadoop中的MapReduce）誕生。MapReduce將處理抽象成Map+Shuffle+Reduce的過程，這種抽象對大數據處理理論變革有著深遠的影響。

以計算詞頻為例，MapReduce將輸入（Input）文本以行為單位分片（Split），每個Map任務將分片中的每個詞映射為鍵值對的形式（Dear，1），Shuffle將相同鍵的記錄組合在一起，最后由Reduce任務計算詞頻并輸出（Output）結果，圖1-2描述了一個有3個Map和3個Reduce的詞頻計算過程。

筆者有一段相似的架構經歷，能夠幫助讀者更好地理解是什么驅動谷歌的工程師開發MapReduce這個通用框架。驅動筆者開發一個定制化數據處理程序的想法主要來自業務需求，也有 MapReduce 思想的啟發。當時，筆者就職的公司有TB級的短文本數據，筆者需要將這些文本的一些相鄰行合并成一條記錄，再對這些記錄進行聚合操作，并在這之上構建一個用于語義分析的應用。出于保密要求，這些數據被分批歸集到公司內網的一臺 x86服務器上，語義分析程序也運行在這臺內網機器上。筆者有兩套方案，其中一套方案使用Hadoop，但是由于只有兩臺物理機器，而且用Hadoop有點“大炮打蚊子”的感覺，加之因著迷于Linux內核之美而“繼承”下的“一言不合便動手造輪子”的理念，筆者決定采用另一套方案：使用Java語言自己動手構建一個簡易的、定制化的多線程數據處理框架（類MapReduce數據處理框架），如圖1-3所示。

其中，Reader用于并行讀取數據；Dealer用于實現可級聯的數據處理邏輯，如先計算記錄總數，再過濾非目標記錄，最后分詞并計算語義標簽；Writer將Dealer處理的最終結果以配置的格式寫入輸出文件。

多線程并行處理將程序運行速度提高了好幾個量級。盡管如此，這段經歷也令筆者回味深長：

（1）語義分析應用程序和底層組件間耦合得太緊，以至于這套軟件只能由筆者維護。因為承擔這個任務的部門的其他同事都是做數據分析的，沒有軟件開發工作經驗。

（2）語義分析訓練通常是相當耗時的，沒有功能更強大的框架支持，手工操作的時間成本比較高。

這段經歷讓筆者深刻領悟到MapReduce框架的深思熟慮。

2004年，Doug Cutting和Mike Cafarella在構建Nutch時受到谷歌公司發表的MapReduce論文的啟發，實現了開源版本的MapReduce，即Hadoop。此后，Pig、Hive、HBase等工具不斷涌現，Hadoop批處理生態系統蓬勃發展，也讓人們再次領教了開源的力量，圖1-4展示了Hadoop生態系統。

批處理（batch）的概念由來已久。在操作系統理論中，批處理是指用戶將一批作業提交給操作系統后就不再干預，由操作系統控制它們自動運行。這種操作系統被稱為批處理操作系統，它是為了提高CPU的利用率而提出的一種操作系統。例如，在DOS和Windows系統中，我們可以在擴展名為.bat 的腳本文件中順序定義一系列操作命令，讓操作系統自動運行這些命令。

在數據處理理論中有對應的批處理系統。批處理系統的核心功能是在大容量靜態數據集上運行預定義功能的、可預期完成時間的計算任務。這里的靜態是指數據集是有界的，是數據集的時間屬性。

流處理（streaming）系統則是構建在無界數據集之上的、可提供實時計算的另一類數據處理系統。

經過一段時間的應用實踐，MapReduce的缺陷也逐漸暴露，最讓人詬病的是Map+Shuffle+Reduce編程模型導致計算作業效率低下。為此，2007年，谷歌發起了Flume項目。起初，Flume只有Java版本，因此也被稱為Flume Java（這里所說的Flume和Apache的Flume不同）。Flume將數據處理過程抽象成計算圖（有向無環圖），數據處理邏輯被編譯成 Map+Shuffle+Reduce 的組合，并加入物理執行計劃優化，而不是簡單地將Map+Shuffle+Reduce串聯。

Flume引入的管道（Pipeline）、動態負載均衡（谷歌內部稱為液態分片）和流語義思想成為大數據處理技術變革的寶貴理論財富。

產生于處理推特信息流的流式數據處理框架 Storm 以犧牲強一致性換取實時性，并在一些場景下取得了成功。為了讓數據處理程序兼備強一致性和實時性，工程師們將強實時性的 Storm 和強一致性的 Hadoop 批處理系統融合在一起，即Lambda架構。其中，Storm負責實時生成近似結果，Hadoop負責計算最終精準結果。Lambda架構需要部署兩套隊列集群，數據要持久化存放兩份，這會導致數據冗余，增加系統維護成本。Lambda架構示意圖，如圖1-5所示。

MapReduce模型嚴重依賴分布式文件系統，如Map將計算結果臨時寫入文件系統，而Shuffle從文件系統中讀入該結果，這往往會產生較大的計算性能損耗，因此基于內存的計算是另一個選擇，這就是Spark成功的秘訣。此外，Spark還支持流式數據處理，即Spark Streaming，其原理是將多個微批處理任務串接起來構建流式數據處理任務。但是這種采用微批重復運行的機制犧牲了低延遲和高吞吐的優勢，引發了 Spark Streaming 是不是真正流式數據處理引擎的爭議。Spark Streaming流式數據處理任務的架構方案，如圖1-6所示。

這期間，流式數據處理繼續發展，出現了 MillWheel、Kafka 和 DataFlow。exactly-once語義、數據源端的持久化和可重放、動態表理論，以及時間、窗口、水印、觸發器等流式數據處理核心理論的提出，加快了流式數據處理框架的發展步伐。

作為流式數據處理中容錯的解決方案之一的輕量級快照機制，借助上述流式數據處理相關理論，以及開源的旺盛生命力，Flink 于 2015 年迅速登上實時數據處理的舞臺，并將推動大數據發展新的浪潮。正是在這種背景下，筆者決定深入Flink實現底層，為讀者呈現其中的智慧之光。Flink架構，如圖1-7所示。