實時計算的發展歷史只有十幾年，它與基於資料庫的計算模型有本質區別，實時計算是固定的計算任務加上流動的資料，而資料庫大多是固定的資料和流動的計算任務，因此實時計算平臺對資料抽象、延時性、容錯性、資料語義等的要求與資料庫明顯不同，面向實時計算的資料架構也就發展起來。本篇我們介紹面向互動式分析的計算引擎Impala、實時計算引擎Apache Flink和星環實時計算引擎Slipstream。

—  面向互動式分析的計算引擎Impala   —

Apache Impala是由Cloudera開發的SQL on Hadoop計算引擎，架構上仿照Google Dremel，其最終的目標是作為Hive的高效能替代方案。Impala可以分析儲存在HDFS和HBase中的資料，並直接重用Hive的後設資料服務，自研了分散式計算引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成）來解決Hive的資料計算效能慢的問題。與傳統MPP系統不太相同的地方在於，Impala實現了計算引擎與儲存引擎的分離，資料的計算與檔案儲存系統並不是強耦合關係。

Impala支援透過ODBC/JDBC驅動程式和SQL語句與Impala進行互動，使用者可以使用類SQL語句進行資料查詢操作。Impala架構具有四個主要元件，分別是：Impalad（Impala守護程式）、Impala Metastore（後設資料儲存服務）、Impala Statestore（狀態管理服務）和Impala Catalog。

Impalad是在每個節點的Impala守護程式，用於接收並處理從客戶端傳送來的請求。Impalad包括三種元件：Query Planner、Query Coordinator和Query Executor。接收到SQL查詢的節點會成為Coordinator節點，Coordinator節點透過Query Planner將查詢轉為執行計劃並轉給Query Coordinator，由其將任務分配給其他Impala節點的Query Executor進行並行化處理。每個工作節點的Query Executor在處理完自己負責的查詢部分後，會各自將結果上報給協調節點的Query Coordinator，由Coordinator節點進行彙總並返回給使用者。

Metastore用於儲存表結構、位置等以及與查詢相關的後設資料資訊，通常採用MySQL和PostgreSQL作為資料庫例項。每個Impala節點都會在本地快取後設資料，當訪問大資料量時先在本地查詢後設資料資訊，如果沒有命中再去Metastore中查詢，以節省開銷。Statestore負責收集每個Impalad的健康狀況。如果節點故障，Statestore會將故障資訊通知叢集所有的Impalad，Coordinator不會再向受影響的節點分配任何作業。Catalog負責從Metastore中同步後設資料，並將後設資料資訊透過Statestore分發到各個Impalad中，使得叢集中所有Impalad都有後設資料的快取資訊。

Impalad一般部署在DataNode上，使用HDFS提供的Short-Circuit Local Reads機制，使得資料的訪問過程能夠直接訪問DataNode。Impala支援SQL、Java等進行查詢，在Client提交查詢後，查詢會分配到Impala叢集中的某一個節點上，該節點便作為本次查詢的協調節點。協調節點的Impalad會與叢集中NameNode進行通訊，確定本次查詢資料所在的DataNode。在對SQL語句進行解析後，將查詢的解析樹變成若干分支，傳送到本節點Query Coordinator，由Coordinator把查詢任務分配給所有儲存這個查詢相關資料的Impala節點的Query Executor。各Query Executor根據自己分配到的任務，直接訪問檔案系統的DataNode進行資料查詢，在處理完成後Query Executor將結果上報給協調節點的Query Coordinator進行彙總，由協調節點把彙總後的結果返回給客戶端。

Hive計算過程中，所有資料處理的中間過程的結果都會透過磁碟儲存下來，這樣的設計能夠實現更好的可伸縮性和容錯能力。而Impala設計之初旨在透過記憶體進行並行處理和任務計算，只負責處理過程中間結果的傳輸，減少了把中間結果寫入磁碟的步驟，由DataNode的Impalad程式直接讀取HDFS及HBase資料,從而大大降低了延遲。不過這個最終帶來的問題是Impala對一些特殊場景的容錯性（如資料傾斜場景下）不如Hive，在生產中的表現就是穩定性不足，因此其並沒有像Hive一樣取得廣泛的落地。從國內專案的落地效果看，Impala屬於較為失敗的專案，落地案例非常稀少，另外社群核心的開發人員也陸續轉其他專案，短期上不太會有很好的起色。2017年開始Cloudera推動基於其自研的分散式儲存Kudu配合Impala的互動式分析方案，以解決HDFS不能支援快速資料寫入和不能利用索引等問題，不過這個方案沒有很好的深度最佳化，而Kudu的主要作者Todd Lipcon轉投Google研發Spanner資料庫，也事實上宣告了這個技術嘗試以失敗而終結。

—  實時計算引擎Apache Flink   —

Apache Flink在2014年8月正式釋出了第一個版本，並於14年底成為Apache優質 專案，是一個同時面向資料流處理和批次資料處理的開源框架和分散式處理引擎，具有高吞吐、低延遲、高擴充套件、支援容錯等特性。Flink以資料並行和流水線方式進行高吞吐量、低延遲的資料流計算程式，流水線執行時系統可以執行批處理或實時流處理。此外，Flink runtime也支援迭代演算法的執行，因此可以在流上執行機器學習演算法。Flink可以被應用與實時ETL、流批一體資料分析以及事件驅動的應用中（如實時風控、反欺詐、異常檢查、實時規則引擎等）。

Flink是一個支援在有界和無界資料流上做有狀態計算的大資料引擎。它以事件為單位，並且支援SQL、State、WaterMark等特性。它支援"exactly once"，即事件投遞保證只有一次，不多也不少，這樣資料的準確效能得到提升。比起Storm，它的吞吐量更高，延遲更低，準確效能得到保障；比起Spark Streaming，它以事件為單位，達到真正意義上的實時計算，且所需計算資源相對更少。Flink runtime是Flink的核心計算結構，這是一個分散式系統，它接受流資料流程式，並在一臺或多臺機器上以容錯的方式執行這些資料流程式。

• Flink邏輯架構

Flink的技術架構如下圖所示，分為Kernel層、API層、儲存層與資源管理層，其主要組成部分和功能如下：

• Runtime是Flink中核心計算框架，採用了標準 master-slave 的結構，master負責管理整個叢集中的資源和作業；Slave負責提供具體的資源並實際執行作業。runtime用於將框架中的job進行拆分並構建DAG圖，透過單執行緒或多執行緒的方式對拆分後的job進行分散式作業，提高執行速度。
• DataSet API 和DataStream API表示Flink中的分散式資料集，分別用於Flink批處理和流處理。DataStream為流處理提供了支援，包括逐條記錄的轉換操作和在處理事件時進行外部資料庫查詢等；DataSet API支援批資料處理，將輸入資料轉換成DataSet資料集，並行分佈在叢集的每個節點上；然後將DataSet資料集進行各種轉換操作(map、filter等)，最後透過DataSink操作將結果資料集輸出到外部系統。
• Flink ML是Flink的機器學習庫，提供了可擴充套件的ML演算法，直觀的API和工具，支援監督學習、無監督學習、資料預處理等，幫助使用者在flink框架中便捷的使用機器學習模型。
• Table API 是一種類SQL的關係型API，使用者可以像操作表一樣地運算元據，非常的直觀和方便。透過類SQL語句，系統會自動化決定如何高效計算。Table & SQL API 實現了流處理和批處理統一的API層，批資料的查詢會隨著輸入資料的結束生成有限結果集，流資料的查詢會一直執行並生成結果流。Table & SQL API 支援資料批與流查詢的同樣語法，使用程式碼編寫規則就能同時在批和流上跑。
• Flink CEP是在flink上實現複雜事件處理(CEP)的庫，允許在事件流中對事件進行檢測，方便使用者掌握資料中重要的事項。
• Gelly是Flink的圖API庫，它包含了一組旨在簡化Flink中圖形分析應用程式開發的方法。在Gelly中，可以使用類似於批處理API提供的 函式來轉換和修改圖。Gelly提供了建立、轉換和修改圖的方法，以及圖演算法庫，可以方便使用者進行大型圖分析。

• Fink系統架構

在系統模組構成上，如下圖所示，Flink主要由Client、JobManager、TaskManager和Dispatcher組成，各個模組的主要功能包括：

• Client：Flink作業在哪臺機器上面提交，那麼當前機器稱之為Client。由使用者Program所構建出DataFlow Graph會以Job形式透過Client提交給JobManager。
• JobManager：主節點，相當於YARN裡面的REsourceManager，生成環境中一般可以做HA 高可用。JobManager會將任務進行拆分，排程到TaskManager上面執行。
• TaskManager：是從節點，TaskManager才是真正實現task的部分。
• Dispatcher ：提供了一個REST 介面，用於提交application執行。

在提交job時，Flink會啟動一個 Client程式負責對job進行編譯，將使用者編寫的程式碼編譯為StreamGraph圖並進行檢查和最佳化等工作，以Job Graph形式提交給Dispatcher。當job到 Dispatcher 後，Dispatcher 會首先啟動一個 Job Manager 元件，然後 Job Manager 會向 Resource Manager 申請資源，根據job graph來啟動job中具體的task。在flink中資源以slot形式存在，在Resource Manager 選到空閒的 Slot 後，會通知Task節點的Manager，由Task Manager 進行相應的記錄後向 Job Manager 進行註冊。Job Manager 收到 Task Manager 註冊上來的 Slot 後提交 Task ，由Task Manager啟動一個新執行緒來執行該 Task，進行預先指定的計算，計算中所有的metadata從叢集的儲存中獲得，並透過資料 Shuffle 模組互相交換資料。

—  星環實時計算引擎Slipstream —

Transwarp Slipstream是一款通用的實時計算引擎，使用事件驅動和批處理統一的模型，在保證毫秒級別延遲的同時，幫助使用者更高效、準確的進行資料整合，同時提供更復雜的分析功能，以幫助企業挖掘實時資料的價值。作為商業版的企業級流處理產品，Slipstream在安全和可用性方面也下了很大功夫，主要包括：

• Exactly Once語義保證：透過分散式的Checkpoint機制，對應用操作的狀態進行Checkpoint，可以在不影響應用整體執行效能的同時，保證Exactly Once語義。
• 自動故障恢復：實時應用通常需要7*24小時不間斷執行，Slipstream提供了自動故障恢復機制，當Worker或者Server發生故障時，實現秒級別的任務自動恢復。
• 使用者登陸安全認證：提供基於LDAP和Kerberos的認證方式，確保授權使用者可以訪問。
• 操作審計：對於登陸使用者的操作都會記錄日誌，方便監控告警，以及事後日誌審計。
• 細粒度的許可權訪問控制：提供對應用的檢視、修改、啟動、停止、刪除等多種操作許可權進行細粒度的控制，保證應用的安全性。
• 智慧資源隔離排程：透過應用的抽象，和資源佇列，可以實現不同應用之間的資源隔離和管理，透過應用優先順序，可以保證在資源緊張時，保證高優先順序的應用不受影響。

—  小結 —

本篇我們介紹了面向互動式分析的計算引擎Impala、實時計算引擎Apache Flink和星環實時計算引擎Slipstream。那麼隨著任務增多，資源有限，分散式系統需要對資源和任務做有效的排程管理，因此有了分散式資源管理技術，下一篇我們將介紹集中式排程器YARN和容器管理技術Kubernetes。