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

程小艦發表於2020-11-15

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

在[大資料計算生態之資料計算（一）]中介紹了批處理和流處理中的各個儲存元件的分類及功能。本文將詳細介紹計算層的另外兩種場景的計算引擎--即席查詢和圖查詢。

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

作者 | 小艦

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

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

一

即席查詢（Ad-Hoc)

1.Impala

Impala是用於處理儲存在Hadoop叢集中的大量資料的MPP（大規模並行處理）SQL查詢引擎。與其他Hadoop的SQL引擎相比，它提供了查詢的高效能和低延遲。它提供了訪問儲存在Hadoop分散式檔案系統中的資料的最快方法。與Hive依賴於MapReduce計算不同，Impala採用的是基於記憶體的計算，因此可以更快地完成計算任務。

上圖是Impala的結構圖，Impala主要包括三大核心元件：

Impala Daemon：impalad是Impala的核心程式，執行在所有的資料節點上，可以讀寫資料，並接收客戶端的查詢請求，並行執行來自叢集中其他節點的查詢請求，將中間結果返回給排程節點。呼叫節點將結果返回給客戶端。使用者在impala叢集上的某個節點提交資料處理請求則該節點稱為coordinator node（協調器節點）,其他的叢集節點傳輸其中的處理的部分資料到該coordinator node，coordinator node負責構建最終的結果資料返回給使用者；impala 支援在提交任務的時候(採用JDBC ,ODBC 方式) 採用round-robin演算法來實現負載均衡,將任務提交到不同的節點上；impalad 程式通過持續的和statestore 通訊來確認自己所在的節點是否健康和是否可以接受新的任務請求；
Impala Statestore（主要優化點，執行緒數）：狀態管理程式，定時檢查The Impala Daemon的健康狀況，協調各個執行impalad的例項之間的資訊關係，Impala正是通過這些資訊去定位查詢請求所要的資料，程式名叫做 statestored，在叢集中只需要啟動一個這樣的程式，如果Impala節點由於物理原因、網路原因、軟體原因或者其他原因而下線，Statestore會通知其他節點，避免查詢任務分發到不可用的節點上；
Impala Catalog Service（後設資料管理和元儲存）：後設資料管理服務，程式名叫做catalogd，將資料表變化的資訊分發給各個程式。接收來自statestore的所有請求，每個Impala節點在本地快取所有後設資料。當處理極大量的資料和/或許多分割槽時，獲得表特定的後設資料可能需要大量的時間。因此，本地儲存的後設資料快取有助於立即提供這樣的資訊。當表定義或表資料更新時，其他Impala後臺程式必須通過檢索最新後設資料來更新其後設資料快取，然後對相關表發出新查詢；

Impala的優點是支援JDBC/ODBC遠端訪問，支援SQL查詢，快速查詢大資料，無需轉換為MR，直接讀取HDFS資料，支援列式儲存，多種儲存格式可以選擇，可以與Hive配合使用,相容HiveSQL，基於記憶體進行計算，能夠對PB級資料進行互動式實時查詢、分析；缺點是不支援使用者定義函式UDF，不支援text域的全文搜尋，不支援Transforms，不支援查詢期的容錯，對記憶體要求高，完全依賴於Hive等。

2.Presto

Presto是一個Facebook開源的分散式SQL查詢引擎，適用於互動式分析查詢，資料量支援GB到PB位元組。Presto的架構由關係型資料庫的架構演化而來。Presto之所以能在各個記憶體計算型資料庫中脫穎而出，在於以下幾點：

（1）清晰的架構，是一個能夠獨立執行的系統，不依賴於任何其他外部系統。例如排程，Presto自身提供了對叢集的監控，可以根據監控資訊完成排程。

（2）簡單的資料結構，列式儲存，邏輯行，大部分資料都可以輕易的轉化成presto所需要的這種資料結構。

（3）豐富的外掛介面，完美對接外部儲存系統，或者新增自定義的函式。

上圖為Presto的架構圖，Presto採用典型的master-slave模型：

（1）coordinator(master)負責meta管理,worker管理，query的解析和排程；

（2）worker則負責計算和讀寫；

（3）discovery server，通常內嵌於coordinator節點中，也可以單獨部署，用於節點心跳。在下文中，預設discovery和coordinator共享一臺機器；

聯邦查詢：Presto另外一個非常重要的優點是可以相容不同的資料來源，上圖詳細展示了Presto用於資料來源擴充套件的Connector模組的邏輯架構。邏輯架構中展示了進行自定義資料來源開發的三個主要的API，分別是後設資料提取、資料儲存位置獲得和讀資料，只要實現了對應的介面便可以進行新的資料來源的接入。通過這一特定，可以支援跨資料來源的資料探查、即席查詢，從而減少傳統OLAP分析過程中的資料搬家等步驟。

3.ClickHouse

ClickHouse是一個面向聯機分析處理(OLAP)的開源的面向列式儲存的DBMS，與Hadoop和Spark相比，ClickHouse很輕量級,由俄羅斯第一大搜尋引擎Yandex於2016年6月釋出。

ClickHouse的特點:

（1）開源的列儲存資料庫管理系統，支援線性擴充套件，簡單方便，高可靠性；

（2）容錯跑分快：比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可處理的資料級別已達到10億級別；

（3）功能多：支援資料統計分析各種場景，支援類SQL查詢，異地複製部署；

ClickHouse最近也是比較火，很多公司用它來進行即時查詢任務，如位元組、攜程等。ClickHouse有如下特色；

列式儲存：牛逼的OLAP，列式儲存已經是標配，使得資料壓縮也有了用武之地。直接效果就是減少資料掃描範圍，讓I/O更高效。
MPP架構：多主架構，角色對等，資料分片（Shard）和副本（Replica）的結合，既保證了擴充套件能力，也增強可資料冗餘保護，壞幾塊硬碟，宕幾臺伺服器都能扛得住。
CPU計算：支援CPU向量運算，將單體迴圈變為並行處理，充分利用硬體和演算法，提升計算效率，所以彪悍的快。
儲存引擎：我感覺是過於繁雜了。從ClickHouse的發展歷史看，明顯受到MySQL的影響。在資料庫和表層面都需要規劃儲存引擎。有人說通用，意味著平庸。像ClickHouse這樣，繁雜代表著專業和場景定製。
MergeTree系列表引擎，與ZooKeeper配合支撐Distributed表。另外，ClickHouse的資料型別也是別具一格，對負責設計的架構師有很高的要求。

總之，ClickHoue是個小巧玲瓏，效能極佳的資料庫管理系統。這一點與我們印象中的俄式米格戰鬥機相去甚遠。

二

圖查詢

圖計算主要將客觀世界中事物間關係完整地刻畫、計算和分析的一門技術。它可以用於銀行對於不良貸款的預測，也可以用於網站大資料分析推薦等功能。圖演算法有很多種，每一種演算法都有其實際的應用場景。常見的圖演算法有PageRank、最短路徑、社群發現等演算法。圖計算有兩種模型的計算框架，分別是基於同步的BSP模型（Bulk Synchronous Parallel Computing Model，整體同步平行計算模型）的GraphX和Giraph，這樣的優勢在於可以提升資料處理的吞吐量和規模，但在速度會稍遜一籌。另一種是基於MPI模型的非同步圖計算模型GraphLab。

1.GraphX

與GraphX可以組合使用的有圖資料庫Neo4j、Titan。Titan是一個分散式的圖形資料庫，特別為儲存和處理大資料圖形而優化，它們都可以作為GraphX的持久層，儲存大規模圖資料。

Spark的每一個模組，都有自己的抽象資料結構，GraphX的核心抽象是彈性分散式屬性圖（resilient distribute property graph）,一種點和邊都帶有屬性的有向多重圖。它同時擁有Table和Graph兩種檢視，而只需一種物理儲存，這兩種操作符都有自己獨有的操作符，從而獲得靈活的操作和較高的執行效率。

在工業級的應用中，圖的規模很大，為了提高處理的速度和資料量，我們希望使用分散式的方式來儲存，處理圖資料。圖的分散式儲存大致有兩種方式，邊分割（Edge Cut），點分割（Vertex Cut），在早期的圖計算框架中，使用的是邊分割的儲存方式，後期考慮到真實世界中大規模圖大多是邊多於點的圖，所以採用點分割方式來儲存。點分割能減少網路傳輸和儲存開銷，底層實現是將邊放到各個節點儲存，而進行資料交換的時候將點在各個機器之間廣播進行傳輸。

GraphX的整體架構可以分為三個部分：

儲存層和原語層：Graph類是圖計算的核心類，內部含有VertexRDD、EdgeRDD和RDD[EdgeTriplet]引用。GraphImpl是Graph類的子類，實現了圖操作。
介面層：在底層RDD的基礎之上實現Pragel模型，BSP模式的計算介面。
演算法層：基於Pregel介面實現了常用的圖演算法。包含：PageRank、SVDPlusPlus、TriangleCount、ConnectedComponents、StronglyConnectedConponents等演算法。

2.Giraph

Google 提出了 Pregel 來解決圖演算法在 MapReduce 上執行低效的問題，但沒有開源。Facebook 根據 Pregel 的思路發展了開源系統 Giraph，但 Giraph 有兩個問題：一是 Giraph 的社群不是很活躍；二是現實生活中的圖都是符合冪律分佈的圖，即有一小部分點的邊數非常多，這些點在 Pregel 的計算模式下很容易拖慢整個計算任務。

計算模型：Giraph 的整個計算模型，主要由輸入、一系列 Superstep 迭代計算、輸出構成，其中這些 Superstep 被稱之為 BSP(Bulk Synchronous Parallelism) 模型。

BSP 模型：BSP 模型是一個塊同步並行模型，其由許多個 Superstep 組成。對於 BSP 模型而言，其在 Superstep 內的操作是並行的，但在兩個 Superstep 之間則是由一個同步操作進行隔離的。也就是說 Superstep(N + 1) 會等待 Superstep(N) 執行完成之後才會開始。

上圖顯示了 Superstep 的結構圖，一個 Superstep 由區域性計算、通訊、柵欄同步三個部分構成。可以看到即使有部分的計算比較快，但最終還是會在柵欄同步這裡停下等待其餘的計算完成。在圖計算中應用這種模型的好處是：可以解決圖計算的同步問題，同步模型有利於推斷程式語義（即利於程式設計），並且消除了死鎖和資料競爭的問題。

最後再簡單介紹一下 Giraph 的整個執行流程：

Giraph 向 Hadoop 提交 Job 之後，Zookeeper 將會選出一個 MapTask 作為 Giraph 的 Master，其餘的 MapTask 則作為 Worker。然後這些 Worker 會通過 Zookeeper 命名服務找到 Master，並向 Master 進行註冊。
Master 將會對輸入圖進行分割槽，併傳送分割槽資訊給 Worker，Woker 會對分割槽進行讀取，期間可能會發生 Worker 之間的分割槽交換。
之後 Master 會開始協調 Worker 迭代執行 Superstep，Worker 將會在 Superstep 中完成頂點的計算過程，直到所有的頂點處於不活躍狀態之後結束計算。

在計算結束之後，Giraph 將會根據使用者指定的格式輸出結果。

3.GraphLab

GraphLab是最早由卡耐基梅隆大學SELECT實驗室於Pregel同時期推出的圖計算系統。與Pregel的動機或者說目標不同，GraphLab主要面向機器學習/資料探勘問題：針對很多這類演算法需要在稀疏資料上進行迭代式計算的特點，GraphLab把輸入/輸出資料以圖的形式進行表示，並將演算法抽象為圖上的計算過程。因此，儘管都採用了以頂點為中心的圖計算模型，GraphLab在一些設計決策上與Pregel有較大的不同：GraphLab中的通訊發生在各個頂點不同副本間的狀態同步，而非Pregel中的訊息傳遞；GraphLab主要採用非同步的計算模式，通過多種級別的一致性來保證演算法的收斂效率，而Pregel是典型的同步計算模式。

GraphLab的執行模型：每個頂點每一輪迭代經過gather->apple->scatter三個階段。