一、動機背景

隨着業務快速增長，時效性越顯重要，傳統離線數倉的不足暴露出來：

• 運維層面——所有調度任務只能在業務閒時（凌晨）集中啓動，集羣壓力大，耗時越來越長；

• 業務層面——數據按T+1更新，延遲高，數據時效價值打折扣，無法精細化運營與及時感知異常。

實時數倉即離線數倉的時效性改進方案，從原本的小時/天級別做到秒/分鐘級別。底層設計變動的同時，需要盡力保證平滑遷移，不影響用戶（分析人員）之前的使用習慣。

實時數倉的建設應早日提上日程，未來企業對數據時效性的要求會越來越高（ 如實時大屏、實時監控、實時風控等 ），實時數倉會很好的解決該問題。

二、指導思想：Kappa架構

一圖流，可品

參考大數據數據倉庫架構演進：

關於數倉架構，可回顧我們之前分享的文章，更多請移步： 系列 | 漫談數倉第一篇NO.1『基礎架構』

三、計算/存儲技術選型

3.1 計算引擎

硬性要求：

1. 批流一體化——能同時進行實時和離線的操作；

2. 提供統一易用的SQL interface——方便開發人員和分析人員。

可選項： Spark、Flink

較優解： Flink

• 優點：

1. 嚴格按照Google Dataflow模型實現；

2. 在事件時間、窗口、狀態、exactly-once等方面更有優勢；

3. 非微批次處理，真正的實時流處理；

4. 多層API，對table/SQL支持良好，支持UDF、流式join等高級用法。

• 缺點：

1. 生態系統沒有Spark強大（不太重要）；

2. 1.10版本相比1.9版本的改動較多，需要仔細研究。

低至4折！Flink/Kylin/數據分析(湖)...100減50！更多滿減低至4折！

3.2 底層（事實數據）| 存儲引擎

• 硬性要求：

1. 數據in-flight——不能中途落地，處理完之後直接給到下游，最小化延遲；

2. 可靠存儲——有一定持久化能力，高可用，支持數據重放。

• 可選項： 各種消息隊列組件（Kafka、RabbitMQ、RocketMQ、Pulsar、...）

• 較優解： Kafka

  1. 吞吐量很大；

  2. 與Flink、Canal等外部系統的對接方案非常成熟，容易操作；

  3. 團隊使用經驗豐富。

3.3 中間層（維度數據）| 存儲引擎

• 硬性要求：

1. 支持較大規模的查詢（主要是與事實數據join的查詢）；

2. 能夠快速實時更新。

• 可選項： RDBMS（MySQL等）、NoSQL（HBase、Redis、Cassandra等）

• 較優解 ：HBase

• 優點：

1. 實時寫入性能高，且支持基於時間戳的多版本機制；

2. 接入業務庫MySQL binlog簡單；

3. 可以通過集成Phoenix獲得SQL能力。

3.4 高層（明細/彙總數據）| 存儲/查詢引擎

根 據不同的需求，按照業務特點選擇不同的方案。

當前已大規模應用，可隨時利用的組件：

• Greenplum——業務歷史明細、BI支持、大寬表MOLAP

• Redis——大列表業務結果（PV/UV、標籤、推薦結果、Top-N等）

• HBase——高併發彙總指標（用戶畫像）

• MySQL——普通匯總指標、彙總模型等

當前未有或未大規模應用的組件：

• ElasticSearch（ELK）——日誌明細，也可以用作OLAP

• Druid——OLAP

• InfluxDB/OpenTSDB——時序數據

四、實時數倉分層架構

參照離線數倉分層，儘量扁平，減少數據中途的lag。

image1

image2

五、元數據管理

5.1 必要性

Kafka本身沒有Hive/GP等傳統數倉組件的metastore，必須自己維護數據schema。
（Flink 1.10開始正式在Table API中支持Catalog，用於外部元數據對接。）

5.2 可行方案

1. 外部存儲（e.g. MySQL） + Flink ExternalCatalog

2. Hive metastore + Flink HiveCatalog（與上一種方案本質相同，但是借用Hive的表描述與元數據體系）

3. Confluent Schema Registry (CSR) + Kafka Avro Serializer/Deserializer

CSR是開源的元數據註冊中心，能與Kafka無縫集成，支持RESTful風格管理。producer和consumer通過Avro序列化/反序列化來利用元數據。

六、SQL作業管理

6.1 必要性

實時數倉平臺展現給分析人員的開發界面應該是類似Hue的交互式查詢UI，即用戶寫標準SQL，在平臺上提交作業並返回結果，底層是透明的。
但僅靠Flink SQL無法實現，需要我們自行填補這個gap。

6.2 可行方案

AthenaX（由Uber開源）

該項目比較老舊，是基於Flink 1.5構建的，預計需要花比較多的時間精力來搞二次開發。

6.3 流程

用戶提交SQL → 通過Catalog獲取元數據 → 解釋、校驗、優化SQL → 編譯爲Flink Table/SQL job → 部署到YARN集羣並運行 → 輸出結果

重點仍然是元數據問題：如何將AthenaX的Catalog與Flink的Catalog打通？

需要將外部元數據的對應到Flink的TableDescriptor（包含connector、format、schema三類參數），進而映射到相應的TableFactory並註冊表。

另 外還需要控制SQL作業對YARN資源的佔用，考慮用YARN隊列實現，視情況調整調度策略。

七、數據質量

7.1 性能監控

使用Flink Metrics，主要考慮兩點：

• 算子數據吞吐量（numRecordsInPerSecond/numRecordsOutPerSecond）

• Kafka鏈路延遲（records-lag-max）→ 如果搞全鏈路延遲，需要做數據血緣分析

其他方面待定（術業有專攻，可專業搞監控系統的同學支持）

7.2 數據質量

• 手動對數——旁路寫明細表，定期與數據源交叉驗證

• 自動監控——數據指標波動告警，基線告警，表級告警 etc.

往期推薦

！ 關注不迷路~ 各種乾貨、資源定期分享 ！