建設實時數倉以前的思考與方案

 

 

導讀：本文由做者LittleMagic總結分享受權發佈，主要闡述建設實時數倉以前的思考與方案記錄。詳細分爲如下幾個方面：

1. 動機背景

2. 指導思想

3. 技術選型

4. 架構分層

5. 元數據管理

6. SQL做業管理

7. 數據質量

 

。

做者：LittleMagic

 

 

正文

前言

隨着此次新冠疫情帶來的機遇，業務數據規模飛速增加，實時數倉的建設已經提上了日程。雖然尚未正式開始實施，可是汲取前人的經驗，作好萬全的準備老是必要的。

本文簡單地記錄一下建設實時數倉以前的一些思考和方案想法，不涉及維度建模方法論的事情。若是有興趣請移步：系列 | 漫談數倉第二篇NO.2 數據模型（維度建模）

1、動機背景

 

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

 

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

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

 

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

 

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

 

2、指導思想：Kappa架構

一圖流，可品

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

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

 

3、計算/存儲技術選型

 

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版本的改動較多，須要仔細研究。

 

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——時序數據

 

4、實時數倉分層架構

 

參照離線數倉分層，儘可能扁平，減小數據中途的lag。

 

image1

image2

5、元數據管理

 

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序列化/反序列化來利用元數據。

 

6、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、數據質量

 

7.1 性能監控  

 

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

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

• Kafka鏈路延遲（records-lag-max）→ 若是搞全鏈路延遲，須要作數據血緣分析

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

 

7.2 數據質量  

 

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

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

 

 

歷史好文推薦

1. 從0到1搭建大數據平臺之計算存儲系統

2. 從0到1搭建大數據平臺之調度系統

3. 從0到1搭建大數據平臺之數據採集系統

4. 如何從0到1搭建大數據平臺

5. 從0到1搭建自助分析平臺

 

 

福利時刻

01. 後臺回覆「數據」,便可領取大數據經典資料。

02. 後臺回覆「轉型」,便可傳統數據倉庫轉型大數據必學資料。

03. 後臺回覆「加羣」,或添加一哥微信ID：dataclub_bigdata  拉您入羣（大數據|數倉|分析）或領取資料。

Q: 關於大數據，你還想了解什麼？

 

歡迎你們掃描下方二維碼訂閱「數據社」內容並推薦給更多數據方向的朋友，但願有更多機會和你們交流。