大資料計算生態之資料計算（一）

程小艦發表於2020-11-15

導讀：大資料計算髮展至今，已經形成了一個百花齊放的大資料生態，通用計算、定製開發，批量處理、實時計算，關係查詢、圖遍歷以及機器學習等等，我們都可以找到各種對應的計算引擎來協助我們處理這些任務。本系列文章擬以大資料平臺從低到高的層次為主線，梳理整個大資料計算生態元件及其功能。

在[大資料計算生態之資料儲存]中介紹了儲存層中的各個儲存元件的分類及功能。有了資料之後，各個應用就可以利用這些資料進行不同維度或角度的分析，從而形成不同的資料價值產品。支撐這一過程最重要的就是計算引擎。計算層是整個大資料計算生態的核心，計算引擎為各個資料任務提供算力支援。本文將詳細介紹計算層的各個計算引擎。

本文經授權轉自公眾號DLab資料實驗室

作者 | 小艦

出品 | DLab資料實驗室（ID：rucdlab）

大資料計算引擎大致可分為批處理、流處理和即席（Ad-Hoc）查詢和圖查詢四類。批處理指的是大規模複雜的資料處理過程，通常的時間跨度在幾分鐘到數小時甚至數日；流處理指的是實時的資料處理和查詢，通常的時間跨度在數百毫秒到數秒之間；即席（Ad-Hoc）查詢指的是介於實時和批處理之間的一種查詢處理，如一些互動式的資料探查任務，需要秒級或分鐘級的較快的響應時間。圖查詢是基於圖模型進行的資料查詢，圖查詢涉及到更多的是迭代類的操作，常見的圖演算法如路徑搜尋演算法、中心性演算法以及社群發現演算法等，這些演算法在公安系統和銀行金融領域中的打擊犯罪團伙、金融欺詐、信用卡盜刷等領域有著重要的應用。

01

批處理計算

目前，在批處理領域，使用最多的計算引擎當屬HadoopMR和Spark兩者。HadoopMR是最早的批處理引擎，是根據Google的”三駕馬車“實現的開源計算框架，主要是解決海量資料的計算問題。由於HadoopMR在處理效率上的一系列問題，Spark應運而生，Spark 針對Hadoop MR2.0存在的問題，對MapReduce做了大量優化。

1.MapReduce（Hadoop）

MapReduce就是指我們常說的Hadoop MapReduce，它是一個批處理計算引擎。每個MapReduce任務都包含兩個過程：Map過程和Reduce過程。

MapReduce的計算模型：Map和Reduce兩個計算過程(中間用Shuffle串聯),MapReduce程式。

- - Map階段：多臺機器同時讀取一個檔案的各個部分，分別統計詞頻，產生多個Map集合；

- - Reduce階段：接收所對應的Map集合結果，將相同鍵的集合彙總，進而得到整個檔案的詞頻結果；

MapReduce的缺點是每個map階段結束時，都需要將中間結果寫到磁碟，reduce階段繼續從磁碟讀取資料進行下一步的處理。這個過程會產生大量的資料I/O，導致處理效率比較低。

2. Spark

與Hadoop MapReduce不同的是，Spark是基於記憶體的批處理計算引擎。SparkSpark及其元件已經形成了一個大資料生態，Spark基於這個引擎，提供了很多的高階應用模組解決不同場景中的業務需求。Spark分為Spark Core、SparkSQL、SparkStreaming、GraphX以及MLLib等，SparkCore為Spark的核心和基礎，提供基本的批處理功能，其他的每個元件專注於不同的處理任務。

Spark Core：Spark Core包含Spark的基本功能，如記憶體計算、任務排程、部署模式、故障恢復、儲存管理等。Spark建立在統一的抽象RDD之上，使其可以以基本一致的方式應對不同的大資料處理場景；通常所說的Apache Spark，就是指Spark Core；

Spark SQL：Spark SQL允許開發人員直接處理RDD，同時也可查詢Hive、HBase等外部資料來源。Spark SQL的一個重要特點是其能夠統一處理關係表和RDD，使得開發人員可以輕鬆地使用SQL命令進行查詢，並進行更復雜的資料分析；

Spark Streaming：Spark Streaming支援高吞吐量、可容錯處理的實時流資料處理，其核心思路是將流式計算分解成一系列短小的批處理作業。Spark Streaming支援多種資料輸入源，如Kafka、Flume和TCP套接字等；

MLlib（機器學習）：MLlib提供了常用機器學習演算法的實現，包括聚類、分類、迴歸、協同過濾等，降低了機器學習的門檻，開發人員只要具備一定的理論知識就能進行機器學習的工作；

GraphX（圖計算）：GraphX是Spark中用於圖計算的API，可認為是Pregel在Spark上的重寫及優化，Graphx效能良好，擁有豐富的功能和運算子，能在海量資料上自如地執行復雜的圖演算法。

Spark與Hadoop相比主要有且不限於以下幾個優勢：

（1）減少磁碟I/O

Hadoop的的map和reduce過程每此處理都要涉及讀寫磁碟，map端的中間結果也要排序並寫入磁碟，reduce從磁碟中進行讀取；這樣整個處理過程中磁碟I/O就成了處理瓶頸；Spark允許將map端的中間結果放入記憶體，reduce直接從記憶體中拉取資料，避免了大量的磁碟I/O。

（2）提高並行度

MapReduce的並行度是程式級別，Spark是執行緒級別；MapReduce需要進行磁碟的map寫入，reduce讀取，屬於序列執行；spark把不同環節抽象為stage，允許多個stage序列執行或並行執行。

（3）避免重複計算

Spark中通過DAG（有向無環圖）來串起資料處理的各個Stage階段，如果某個階段發生故障或者資料丟失，可以利用血緣機制來回溯某個RDD，從而減少資料的重新計算，提高效率。

從以上我們看到Spark對Hadoop MR存在的問題都進行了優化，從而提升了資料處理的效率。根據Spark官方提供的效能對比資料，Spark效能比Hadoop高出120倍。

通過上圖簡單的一個wordCount統計的例子，可以大致瞭解Spark進行資料處理的流程，體會Spark的pipeline管道計算模式的優勢。

02

流處理計算

Spark的Spark Streaming和Storm是比較早的流計算框架，隨著流計算技術的發展，Storm逐漸被遺棄，Flink作為一匹流計算的黑馬得到了業界的廣泛應用。Spark Streaming也依靠Spark生態生存了下來。但是面對Spark Streaming對於Flink表現出的不足，從Spark 2.3開始，Structured Streaming引入了低延遲的持續流處理模式，這時候已經不再採用批處理引擎，而是一種類似Flink機制的持續處理引擎，可以達到端到端最低1ms的延遲。

1.Storm

Storm是Twitter開源的分散式實時大資料處理框架，被業界稱為實時版Hadoop。Apache Storm從一端讀取實時資料的原始流，並將其傳遞通過一系列小處理單元，並在另一端輸出處理/有用的資訊。

在Storm中，需要先設計一個實時計算結構，也就是拓撲（topology）。這個拓撲結構會被提交給叢集，其中主節點（master node）負責給工作節點（worker node）分配程式碼，工作節點負責執行程式碼。在一個拓撲結構中，包含spout和bolt兩種角色。資料在spouts之間傳遞，這些spouts將資料流以tuple元組的形式傳送；而bolt則負責轉換資料流。

下圖描述了Apache Storm的核心概念。

2.Spark Streaming

Spark Streaming屬於Spark的一個元件，是基於批的流式計算框架，支援Kafka、Flume及簡單的TCP套接字等多種資料輸入源，輸入流接收器（Reciever）負責接入資料。DStream是SparkStreaming中的資料流抽象，它也可以被組織為DStreamGraph。Dstream本質上由一系列連續的RDD組成。

Spark Streaming，即核心Spark API的擴充套件，不像Storm那樣一次處理一個資料流。相反，它在處理資料流之前，會按照時間間隔對資料流進行分段切分。Spark針對連續資料流的抽象，我們稱為DStream（Discretized Stream）。

DStream是小批處理的RDD（彈性分散式資料集）， RDD則是分散式資料集，可以通過任意函式和滑動資料視窗（視窗計算）進行轉換，實現並行操作。

3.Flink

Flink是一個面向資料流處理和批量資料處理的可分散式的開源計算框架，它基於同一個Flink流式執行模型（streaming execution model），能夠支援流處理和批處理兩種應用型別。

Flink最核心的資料結構是Stream，它代表一個執行在多分割槽上的並行流。

在 Stream 上同樣可以進行各種轉換操作（Transformation）。與 Spark 的 RDD 不同的是，Stream 代表一個資料流而不是靜態資料的集合。所以，它包含的資料是隨著時間增長而變化的。而且 Stream 上的轉換操作都是逐條進行的，即每當有新的資料進來，整個流程都會被執行並更新結果。這樣的基本處理模式決定了 Flink 會比 Spark Streaming 有更低的流處理延遲性。當一個 Flink 程式被執行的時候，它會被對映為 Streaming Dataflow，上圖就是一個Streaming Dataflow。

4.Structured Streaming

Spark 2.0 引入了Structured Streaming，將微批次處理從高階 API 中解耦出去。它簡化了 API 的使用，API 不再負責進行微批次處理；開發者可以將流看成是一個沒有邊界的表，並基於這些“表”執行查詢。Structured Streaming的預設引擎基於微批處理引擎，並且可以達到最低100ms的延遲和資料處理的exactly-once保證。採用何種處理模式只需要進行簡單的模式配置即可。

Structured Streaming定義了無界表的概念，即每個流的資料來源從邏輯上來說看做一個不斷增長的動態表（無界表），從資料來源不斷流入的每個資料項可以看作為新的一行資料追加到動態表中。使用者可以通過靜態結構化資料的批處理查詢方式（SQL查詢），對資料進行實時查詢。

Structured Streaming通過不同的觸發模式來實現不同的延遲級別和一致性語義。主要提供了以下四種觸發模式：

單次觸發：顧名思義就是隻觸發一次執行，類似於Flink的批處理；
週期性觸發：查詢以微批處理模式執行，微批執行將以使用者指定的時間間隔來進行；
預設觸發：一個批次執行結束立即執行下個批次；
連續處理：是Structured Streaming從2.3開始提出的新的模式，對標的就是Flink的流處理模式，該模式支援傳入一個引數，傳入引數為checkpoint間隔，也就是連續處理引擎每隔多久記錄查詢的進度；

總結

批處理和流處理涵蓋了大部分的應用場景，由於篇幅有限，本期就講到這裡，下期將會繼續介紹大資料計算的另外兩種場景：即席（Ad-Hoc)查詢和圖查詢。