架構選型
首先在架構上，Flink 采用了經典的主從模式，DataFlow Graph 與 Storm 形成的拓撲 Topology 結構類似，Flink 程序啟動后，會根據用戶的代碼處理成 Stream Graph，然后優化成為 JobGraph，JobManager 會根據 JobGraph 生成 ExecutionGraph。ExecutionGraph 才是 Flink 真正能執行的數據結構，當很多個 ExecutionGraph 分布在集群中，就會形成一張網狀的拓撲結構。
其次在容錯方面，針對以前的 Spark Streaming 任務，我們可以配置對應的 checkpoint，也就是保存點（檢查點）。當任務出現 failover 的時候，會從 checkpoint 重新加載，使得數據不丟失。但是這個過程會導致原來的數據重復處理，不能做到“只處理一次”的語義。Flink 基於兩階段提交實現了端到端的一次處理語義。
在任務的反壓上，Flink 沒有使用任何復雜的機制來解決反壓問題，Flink 在數據傳輸過程中使用了分布式阻塞隊列。我們知道在一個阻塞隊列中，當隊列滿了以后發送者會被天然阻塞住，這種阻塞功能相當於給這個阻塞隊列提供了反壓的能力。
這些優勢和特性，使得 Flink 在實時計算平台的搭建上占有一席之地。
實時計算平台整體架構
一般的實時計算平台的構成大都是以下幾部分構成。
- 實時數據收集層
在實際業務中，大量的實時計算都是基於消息系統進行的數據收集和投遞，這都離不開強大的消息中間件。目前業界使用最廣的是 Kafka，另外一些重要的業務數據還會用到其他消息系統比如 RocketMQ 等。Kafka 因為高吞吐、低延遲的特性，特別適合大數量量、高 QPS 下的業務場景，而 RocketMQ 則在事務消息、一致性上有獨特的優勢。
- 實時計算層
Flink 在計算層同時支持流式及批量分析應用，這就是我們所說的批流一體。Flink 承擔了數據的實時采集、實時計算和下游發送的角色。隨着 Blink 的開源和一些其他實時產品的開源，支持可視化、SQL 化的開發模式已經越來越普及。
- 數據存儲層
這里是我們的實時數據存儲層，存儲層除了傳統 MySQL 等存儲引擎以外，還會根據場景數據的不同存儲在 Redis、HBase、OLAP 中。而這一層我個人認為最重要的技術選型則是 OLAP。OLAP 的技術選型直接制約着數據存儲層和數據服務層的能力。關於 OLAP 的技術選型，可以參考這里。
- 數據服務層
數據服務層會提供統一的對外查詢、多維度的實時匯總，加上完善的租戶和權限設計，能夠支持多部門、多業務的數據需求。另外，基於數據服務層還會有數據的展示、大屏、指標可視化等。
實時計算平台實際應用
美團在公開發表的文章中提到，目前美團實時計算平台的架構組成：最底層是實時數據收集層，使用 Kafka 進行數據收集，支撐了大量的實時計算和離線數據拉取任務。
基於實時數據收集層之上，是基於 Flink 的實時計算層，美團選擇了 Flink on Yarn 模式，並且選擇了 Redis、HBase 和 ElasticSearch 作為數據存儲。同時，美團還面向數據開發者進行作業托管、作業調優和診斷報警功能。
整體來看，美團的實時計算平台主要包含作業管理和資源管理兩個方面的能力。基於作業管理上可以做到任務的發布、回滾、狀態監控等，在資源管理上基於多租戶的設計進行業務隔離，並且 Flink Job 采用 on Yarn 的模式，任務之間進行資源隔離。
根據公開的技術分享文檔來看，目前美團點評的實時計算平台節點已經達到幾千台，在資源的優化上需要做到自動擴容、縮容，另外實時計算任務和離線任務的混合部署也需要考慮到如何進行更細粒度資源的釋放。
美團的實時計算平台圖
微博的實時計算平台是隨着業務線的快速擴張，為了滿足業務需求逐漸演變。在初期架構中，僅僅存在計算和存儲兩層，每次接入一個新的實時計算業務就要重新開發一遍，代碼的利用率低下，接入成本很高。
基於上面的需求，微博開發了基於 Flink 的通用組件，用來快速支持實時數據的快速接入。從下到上共分為五層，分別是接入層、計算層、存儲層、服務層和應用層。整體的架構圖如下圖所示：
微博的實時計算平台圖
基於微博的實時計算架構，數據從產生進入消息系統，通過 Flink 進行 ETL 進入存儲層。根據業務不同的指標和數據需求，寫入不同的存儲中。統一查詢服務則根據目前業務的需要，將查詢服務微服務化，從數倉如 Redis、ElasticSearch、MySQL 等不同的存儲中直接抽取。
微博的實時計算平台初期架構僅僅包含計算和存儲兩層，每個新的實時計算需求都要重新開發一遍，代碼利用率低、重復開發。不同業務的不同需求對同一個指標的計算沒有進行統一。隨着數據量和業務的增長，前期架構的弊端開始顯現，逐步發展成現在通用的計算架構。
在全新的計算架構下，微博基於 ClickHouse 進行多維度的計算來滿足大數據量下的快速查詢需求。數據分層上也借鑒了離線數倉的經驗，構建了一套多層級的實時數倉服務，並且開發了多種形式的微服務對指標提取、數據聚合、數據質量、報警監控等進行支持。
基於 Flink 的實時數據倉庫
我們在之前的課程中提過，Flink 的實際應用場景之一就是實時數據倉庫。
實時數倉背景
傳統的離線數據倉庫將業務數據集中進行存儲后，以固定的計算邏輯定時進行 ETL 和其他建模后產出報表等應用。離線數據倉庫主要是構建 T+1 的離線數據，通過定時任務每天拉取增量數據，然后創建各個業務相關的主題維度數據，對外提供 T+1 的數據查詢接口。
離線數據倉庫 ETL 和實時數據倉庫的差異圖
上圖展示了離線數據倉庫 ETL 和實時數據倉庫的差異，可以看到離線數據倉庫的計算和數據的實時性均較差。數據本身的價值隨着時間的流逝會逐步減弱，因此數據發生后必須盡快地達到用戶的手中，實時數倉的構建需求也應運而生。
實時數據倉庫的建設是“數據智能 BI”必不可少的一環，也是大規模數據應用中必然面臨的挑戰。
Flink 在實時數倉的優勢
Flink 在實時數倉和實時 ETL 中有天然的優勢：
狀態管理，實時數倉里面會進行很多的聚合計算，這些都需要對狀態進行訪問和管理，Flink 支持強大的狀態管理；
豐富的 API，Flink 提供極為豐富的多層次 API，包括 Stream API、Table API 及 Flink SQL；
生態完善，實時數倉的用途廣泛，Flink 支持多種存儲（HDFS、ES 等）；
批流一體，Flink 已經在將流計算和批計算的 API 進行統一。
實時數倉的實際應用
離線數據倉庫的設計中，我們會把倉庫結構分為不同的層次來存儲不同的數據，大概可以分為：ODS 源數據、DWD 明細層、DWS 匯總層、ADM 應用層。在實時數據倉庫的設計中也可以參考這個設計。
但是需要注意的是，在實時數據模型的處理方式上和離線有所區別。例如，明細層的匯總一般是基於 Flink 等接入 Kafka 消息進行關聯的，維度表的數據一般會放在 HDFS、HBase 中作為明細層的補充。另外，在實時數據倉庫中要選擇不同的 OLAP 庫來滿足即席查詢。
我們來看一下網易嚴選和美團的實時數據倉庫的設計分別是怎樣的。
網易嚴選
網易嚴選的實時數據倉庫設計圖
如上圖所示，網易嚴選的實時數據倉庫 ODS 層主要是基於 Kafka 的事實數據，經過 Flink 處理后形成 DWD 明細層，在 DWD 層中會關聯一些維度和歷史數據，並且存入 Redis 中。在 DWS 層中會根據不同的業務場景有不同的存儲，高並發查詢和寫入會基於 HBase 進行。如果你需要基於明細做不同維度的匯總那么就要在 GreenPulm 這個 OLAP 引擎中進行查詢分析，另外一些維度較多的查詢、排序等直接存儲在 Redis 中供查詢使用。
我們可以看出網易嚴選在建設實時數倉的主要考量是計算和存儲。在計算上，網易嚴選選擇了 Flink，主要是因為 Flink 的端到端的精確一次語義支持和容錯特性。另外在存儲方面，網易嚴選選擇把 Flink 處理完的數據備份到 Kafka，並且根據業務場景和數據應用特點選擇了不同的存儲介質，例如一些高並發查詢會基於 HBase 進行，常見的匯總指標會放入 MySQL 中直接使用。
在我們的實際業務場景下，明細和匯總數據會根據查詢 QPS、維度的復雜程度等選擇不同的介質，其中 HBase、OLAP、Redis 等都是常見存儲介質，需要用戶根據實際業務進行選擇。
美團
下圖是美團的實時數倉分層的架構模型圖：
ODS 層，基於 MySQL Binlog 和 Kafka 的日志消息；
明細層，基於事實數據關聯成明細數據；
匯總層，使用明細數據進行多維度的查詢匯總；
應用層，對外提供 HTTP、RPC 等查詢服務。
美團的實時數倉分層架構模型圖
美團的 ODS 存放的主要是業務數據，其中大多是基於 MySQL 的 Binlog 和消息數據，這也是我們在實際業務中常用的方法。我們在建設實時數據倉庫的過程中一個要求就是要和實際業務系統進行解耦，所以消息系統是我們的必然選擇。
明細層是根據業務進行的划分，這一層的計算主要是基於 Flink 進行的，這一層承擔着業務數據的解析、關聯維表、明細存儲的功能。
匯總層會基於明細數據進行再次關聯和匯總，根據業務需要產出中間層和指標結果層。
最上層是同一對外服務的應用層，這層在我們的實際應用中非常重要。主要是根據外部系統的查詢需要提供不同的查詢服務，基於 HTTP、RPC 等的查詢服務是常見選擇，我們需要仔細評估訪問的 QPS、查詢負載等對接口進行限流、冪等、容錯設計。並且需要進行嚴格的權限設計，防止數據泄露和非法訪問。
總結
本課時我們講解了基於 Flink 的實時計算平台的設計和架構，並且講解了美團和微博的實時計算平台設計；與此同時還講解了 Flink 在實時數倉的優勢和應用。總體來看，實時數據平台和實時數倉在業界已經有了較為成熟的方案，我們可以根據已有的方案和公司業務設計自己的實時計算平台和實時數據倉庫。