如何設計實時數據平臺（技術篇）

敏捷之歌

我抽數故我存在 | DBus

人人玩轉流處理 | Wormhole

就當吾是數據庫 | Moonbox

顏值最後十千米 | Davinci

導讀：實時數據平臺（RTDP，Real-time Data Platform）是一個重要且常見的大數據基礎設施平臺。在上篇（設計篇）中，咱們從現代數倉架構角度和典型數據處理角度介紹了RTDP，並探討了RTDP的總體設計架構。本文做爲下篇（技術篇），則是從技術角度入手，介紹RTDP的技術選型和相關組件，探討適用不一樣應用場景的相關模式。RTDP的敏捷之路就此展開~

拓展閱讀：以企業級實時數據平臺爲例，瞭解何爲敏捷大數據

如何設計實時數據平臺（設計篇）

1、技術選型介紹

在設計篇中，咱們給出了RTDP的一個總體架構設計（圖1）。在技術篇裏，咱們則會推薦總體技術組件選型；對每一個技術組件作出簡單介紹，尤爲對咱們抽象並實現的四個技術平臺（統一數據採集平臺、統一流式處理平臺、統一計算服務平臺、統一數據可視化平臺）着重介紹設計思路；對Pipeline端到端切面話題進行探討，包括功能整合、數據管理、數據安全等。

圖1 RTDP架構

1.1 總體技術選型

圖2 總體技術選型

首先，咱們簡要解讀一下圖2：

• 數據源、客戶端，列舉了大多數數據應用項目的經常使用數據源類型。
• 數據總線平臺DBus，做爲統一數據採集平臺，負責對接各類數據源。DBus將數據以增量或全量方式抽取出來，並進行一些常規數據處理，最後將處理後的消息發佈在Kafka上。
• 分佈式消息系統Kafka，以分佈式、高可用、高吞吐、可發佈-訂閱等能力，鏈接消息的生產者和消費者。
• 流式處理平臺Wormhole，做爲統一流式處理平臺，負責流上處理和對接各類數據目標存儲。Wormhole從Kafka消費消息，支持流上配置SQL方式實現流上數據處理邏輯，並支持配置化方式將數據以最終一致性（冪等）效果落入不一樣數據目標存儲（Sink）中。
• 在數據計算存儲層，RTDP架構選擇開放技術組件選型，用戶能夠根據實際數據特性、計算模式、訪問模式、數據量等信息選擇合適的存儲，解決具體數據項目問題。RTDP還支持同時選擇多個不一樣數據存儲，從而更靈活的支持不一樣項目需求。
• 計算服務平臺Moonbox，做爲統一計算服務平臺，對異構數據存儲端負責整合、計算下推優化、異構數據存儲混算等（數據虛擬化技術），對數據展現和交互端負責收口統一元數據查詢、統一數據計算和下發、統一數據查詢語言（SQL）、統一數據服務接口等。
• 可視應用平臺Davinci，做爲統一數據可視化平臺，以配置化方式支持各類數據可視化和交互需求，並能夠整合其餘數據應用以提供數據可視化部分需求解決方案，另外還支持不一樣數據從業人員在平臺上協做完成各項平常數據應用。其餘數據終端消費系統如數據開發平臺Zeppelin、數據算法平臺Jupyter等在本文不作介紹。
• 切面話題如數據管理、數據安全、開發運維、驅動引擎，能夠經過對接DBus、Wormhole、Moonbox、Davinci的服務接口進行整合和二次開發，以支持端到端管控和治理需求。

下面咱們會進一步細化上圖涉及到的技術組件和切面話題，介紹技術組件的功能特性，着重講解咱們自研技術組件的設計思想，並對切面話題展開討論。

1.2 技術組件介紹

1.2.1 數據總線平臺DBus

圖3 RTDP架構之DBus

1.2.1.1 DBus設計思想

1）從外部角度看待設計思想

• 負責對接不一樣的數據源，實時抽取出增量數據，對於數據庫會採用操做日誌抽取方式，對於日誌類型支持與多種Agent對接。
• 將全部消息以統一的UMS消息格式發佈在Kafka上，UMS是一種標準化的自帶元數據信息的JSON格式，經過統一UMS實現邏輯消息與物理Kafka Topic解耦，使得同一Topic能夠流轉多個UMS消息表。
• 支持數據庫的全量數據拉取，而且和增量數據統一融合成UMS消息，對下游消費透明無感知。

2）從內部角度看待設計思想

• 基於Storm計算引擎進行數據格式化，確保消息端到端延遲最低。
• 對不一樣數據源數據進行標準化格式化，生成UMS信息，其中包括：

✔ 生成每條消息的惟一單調遞增id，對應系統字段ums_id_

✔ 確認每條消息的事件時間戳（event timestamp），對應系統字段ums_ts_

✔ 確認每條消息的操做模式（增刪改，或insert only），對應系統字段ums_op_

• 對數據庫表結構變動實時感知並採用版本號進行管理，確保下游消費時明確上游元數據變化。
• 在投放Kafka時確保消息強有序（非絕對有序）和at least once語義。
• 經過心跳錶機制確保消息端到端探活感知。

1.2.1.2 DBus功能特性

• 支持配置化全量數據拉取
• 支持配置化增量數據拉取
• 支持配置化在線格式化日誌
• 支持可視化監控預警
• 支持配置化多租戶安全管控
• 支持分表數據聚集成單邏輯表

1.2.1.3 DBus技術架構

圖4 DBus數據流轉架構圖

更多DBus技術細節和用戶界面，能夠參看：

GitHub： github.com/BriData

1.2.2 分佈式消息系統Kafka

Kafka已經成爲事實標準的大數據流式處理分佈式消息系統，固然Kafka在不斷的擴展和完善，如今也具有了必定的存儲能力和流式處理能力。關於Kafka自己的功能和技術已經有不少文章信息能夠查閱，本文再也不詳述Kafka的自身能力。

這裏咱們具體探討Kafka上消息元數據管理（Metadata Management）和模式演變（Schema Evolution）的話題。

圖5

圖片來源：cloudurable.com/images/kafk…

圖5顯示，在Kafka背後的Confluent公司解決方案中，引入了一個元數據管理組件：Schema Registry。這個組件主要負責管理在Kafka上流轉消息的 元數據信息和Topic信息，並提供一系列元數據管理服務。之因此要引入這樣一個組件，是爲了Kafka的消費方可以瞭解不一樣Topic上流轉的是哪些數據，以及數據的元數據信息，並進行有效的解析消費。

任何數據流轉鏈路，不論是在什麼系統上流轉，都會存在這段數據鏈路的元數據管理問題，Kafka也不例外。Schema Registry是一種中心化的Kafka數據鏈路元數據管理解決方案，而且基於Schema Registry，Confluent提供了相應的Kafka數據安全機制和模式演變機制。

更多關於Schema Registry的介紹，能夠參看：

Kafka Tutorial:Kafka, Avro Serialization and the Schema Registry

cloudurable.com/blog/kafka-…

那麼在RTDP架構中，如何解決Kafka消息元數據管理和模式演變問題呢？

1.2.2.1 元數據管理（Metadata Management）

• DBus會自動將實時感知的數據庫元數據變化記錄下來並提供服務
• DBus會自動將在線格式化的日誌元數據信息記錄下來並提供服務
• DBus會發布在Kafka上發佈統一UMS消息，UMS自己自帶消息元數據信息，所以下游消費時無需調用中心化元數據服務，能夠直接從UMS消息裏拿到數據的元數據信息

1.2.2.2 模式演變（Schema Evolution）

• UMS消息會自帶Schema的Namespace信息，Namespace是一個7層定位字符串，能夠惟必定位任何表的任何生命週期，至關於數據表的IP地址，形式以下：

[Datastore].[Datastore Instance].[Database].[Table].[TableVersion].[Database Partition].[Table Partition]

例：oracle.oracle01.db1.table1.v2.dbpar01.tablepar01

其中[Table Version]表明了這張表的某個Schema的版本號，若是數據源是數據庫，那麼這個版本號是由DBus自動維護的。

• 在RTDP架構中，Kafka的下游是由Wormhole消費的，Wormhole在消費UMS時，會將[TableVersion]做爲*處理，意味着當某表上游Schema變動時，Version會自動升號，但Wormhole會無視這個Version變化，將會消費此表全部版本的增量/全量數據，那麼Wormhole如何作到兼容性模式演變支持呢？在Wormhole裏能夠配置流上處理SQL和輸出字段，當上遊Schema變動是一種「兼容性變動」（指增長字段，或者修改擴大字段類型等）時，是不會影響到Wormhole SQL正確執行的。當上遊發生非兼容性變動時，Wormhole會報錯，這時就須要人工介入對新Schema的邏輯進行修復。

由上文能夠看出，Schema Registry和DBus+UMS是兩種不一樣的解決元數據管理和模式演變的設計思路，二者各有優點和劣勢，能夠參考表1的簡單比較。

表1 Schema Registry 與 DBus+UMS 對比

這裏給出一個UMS的例子：

圖6 UMS消息舉例

1.2.3 流式處理平臺Wormhole

圖7 RTDP架構之Wormhole

1.2.3.1 Wormhole設計思想

1)從外部角度看待設計思想

• 消費來自Kafka 的UMS消息和自定義JSON消息
• 負責對接不一樣的數據目標存儲 (Sink)，並經過冪等邏輯實現Sink的最終一致性
• 支持配置SQL方式實現流上處理邏輯
• 提供Flow抽象。Flow由一個Source Namespace和一個Sink Namespace定義，且具有惟一性。Flow上能夠定義處理邏輯，是一種流上處理的邏輯抽象，經過與物理Spark Streaming、Flink Streaming解耦，使得同一個Stream能夠處理多個Flow處理流，且Flow能夠在不一樣Stream上任意切換。
• 支持基於回灌（backfill）的Kappa架構；支持基於Wormhole Job的Lambda架構

2)從內部角度看待設計思想

• 基於Spark Streaming、Flink計算引擎進行數據流上處理。Spark Streaming可支持高吞吐、批量Lookup、批量寫Sink等場景；Flink可支持低延遲、CEP規則等場景。
• 經過ums_id_, ums_op_實現不一樣Sink的冪等入庫邏輯
• 經過計算下推實現Lookup邏輯優化
• 抽象幾個統一以支持功能靈活性和設計一致性

✔ 統一DAG高階分形抽象

✔ 統一通用流消息UMS協議抽象

✔ 統一數據邏輯表命名空間Namespace抽象

• 抽象幾個接口以支持可擴展性

✔ SinkProcessor：擴展更多Sink支持

✔ SwiftsInterface：自定義流上處理邏輯支持

✔ UDF：更多流上處理UDF支持

• 經過Feedback消息實時歸集流式做業動態指標和統計

1.2.3.2 Wormhole功能特性

• 支持可視化，配置化，SQL化開發實施流式項目
• 支持指令式動態流式處理的管理、運維、診斷和監控
• 支持統一結構化UMS消息和自定義半結構化JSON消息
• 支持處理增刪改三態事件消息流
• 支持單個物理流同時並行處理多個邏輯業務流
• 支持流上Lookup Anywhere，Pushdown Anywhere
• 支持基於業務策略的事件時間戳流式處理
• 支持UDF的註冊管理和動態加載
• 支持多目標數據系統的併發冪等入庫
• 支持多級基於增量消息的數據質量管理
• 支持基於增量消息的流式處理和批量處理
• 支持Lambda架構和Kappa架構
• 支持與三方系統無縫集成，可做爲三方系統的流控引擎
• 支持私有云部署，安全權限管控和多租戶資源管理

1.2.3.3 Wormhole技術架構

圖8 Wormhole數據流轉架構圖

更多Wormhole技術細節和用戶界面，能夠參看：

GitHub：github.com/edp963/worm…

1.2.4 經常使用數據計算存儲選型

RTDP架構對待數據計算存儲選型的選擇採起開放整合的態度。不一樣數據系統有各自的優點和適合的場景，但並無一個數據系統能夠適合各類各樣的存儲計算場景。所以當有合適的、成熟的、主流的數據系統出現，Wormhole和Moonbox會按照須要相應的擴展整合支持。

這裏大體列舉一些比較通用的選型：

• 關係型數據庫（Oracle/MySQL等）：適合小數據量的複雜關係計算

• 分佈式列存儲系統

✔ Kudu：Scan優化，適合OLAP分析計算場景

✔ HBase：隨機讀寫，適合提供數據服務場景

✔ Cassandra：高性能寫，適合海量數據高頻寫入場景

✔ ClickHouse：高性能計算，適合只有insert寫入場景（後期將支持更新刪除操做）

• 分佈式文件系統

✔ HDFS/Parquet/Hive：append only，適合海量數據批量計算場景

• 分佈式文檔系統

✔ MongoDB：平衡能力，適合大數據量中等複雜計算

• 分佈式索引系統

✔ ElasticSearch：索引能力，適合作模糊查詢和OLAP分析場景

• 分佈式預計算系統

✔ Druid/Kylin：預計算能力，適合高性能OLAP分析場景

1.2.5 計算服務平臺Moonbox

圖9 RTDP架構之Moonbox

1.2.5.1 Moonbox設計思想

1)從外部角度看待設計思想

• 負責對接不一樣的數據系統，支持統一方式跨異構數據系統即席混算
• 提供三種Client調用方式：RESTful服務、JDBC鏈接、ODBC鏈接
• 統一元數據收口；統一查詢語言SQL收口；統一權限控制收口
• 提供兩種查詢結果寫出模式：Merge、Replace
• 提供兩種交互模式：Batch模式、Adhoc模式
• 數據虛擬化實現，多租戶實現，可看做是虛擬數據庫

2)從內部角度看待設計思想

• 對SQL進行解析，通過常規Catalyst處理解析流程，最終生成可下推數據系統的邏輯執行子樹進行下推計算，而後將結果拉回進行混算並返回
• 支持兩層Namespace：database.table，以提供虛擬數據庫體驗
• 提供分佈式服務模塊Moonbox Grid提供高可用高併發能力
• 對可所有下推邏輯（無混算）提供快速執行通道

1.2.5.2 Moonbox功能特性

• 支持跨異構系統無縫混算
• 支持統一SQL語法查詢計算和寫入
• 支持三種調用方式：RESTful服務、JDBC鏈接、ODBC鏈接
• 支持兩種交互模式：Batch模式、Adhoc模式
• 支持Cli Command工具和Zeppelin
• 支持多租戶用戶權限體系
• 支持表級權限、列級權限、讀權限、寫權限、UDF權限
• 支持YARN調度器資源管理
• 支持元數據服務
• 支持定時任務
• 支持安全策略

1.2.5.3 Moonbox技術架構

圖10 Moonbox邏輯模塊

更多Moonbox技術細節和用戶界面，能夠參看：

GitHub： github.com/edp963/moon…

1.2.6 可視應用平臺Davinci

圖11 RTDP架構之Davinci

1.2.6.1 Davinci設計思想

1)從外部角度看待設計思想

• 負責各類數據可視化展現功能
• 支持JDBC數據源
• 提供平權用戶體系，每一個用戶能夠創建屬於本身的Org、Team和Project
• 支持SQL編寫數據處理邏輯，支持拖拽式編輯可視化展現，提供多用戶社交化分工協做環境
• 提供多種不一樣的圖表交互能力和定製化能力，以應對不一樣數據可視化需求
• 提供嵌入整合進其餘數據應用的能力

2)從內部角度看待設計思想

• 圍繞View和Widget展開。View是數據的邏輯視圖；Widget是數據可視化視圖
• 經過用戶自定義選擇分類數據、有序數據和量化數據，按照合理的可視化邏輯自動展示視圖

1.2.6.2 Davinci功能特性

1)數據源

• 支持JDBC數據源
• 支持CSV文件上傳

2)數據視圖

• 支持定義SQL模版
• 支持SQL高亮顯示
• 支持SQL測試
• 支持回寫操做

3)可視組件

• 支持預約義圖表
• 支持控制器組件
• 支持自由樣式

4)交互能力

• 支持可視組件全屏顯示
• 支持可視組件本地控制器
• 支持可視組件間過濾聯動
• 支持羣控控制器可視組件
• 支持可視組件本地高級過濾器
• 支持大數據量展現分頁和滑塊

5)集成能力

• 支持可視組件CSV下載
• 支持可視組件公共分享
• 支持可視組件受權分享
• 支持儀表板公共分享
• 支持儀表板受權分享

6)安全權限

• 支持數據行列權限
• 支持LDAP登陸集成

更多Davinci技術細節和用戶界面，能夠參看：

GitHub：github.com/edp963/davi…

1.3 切面話題討論

1.3.1 數據管理

1）元數據管理

• DBus能夠實時拿到數據源的元數據並提供服務查詢
• Moonbox能夠實時拿到數據系統的元數據並提供服務查詢
• 對於RTDP架構來講，實時數據源和即席數據源的元數據信息能夠經過調用DBus和Moonbox的RESTful服務歸集，能夠基於此建設企業級元數據管理系統

2）數據質量

• Wormhole能夠配置消息實時落入HDFS（hdfslog）。基於hdfslog的Wormhole Job支持Lambda架構；基於hdfslog的Backfill支持Kappa架構。能夠經過設置定時任務選擇Lambda架構或者Kappa架構對Sink進行定時刷新，以確保數據的最終一致性。Wormhole還支持將流上處理異常或Sink寫入異常的消息信息實時Feedback到Wormhole系統中，並提供RESTful服務供三方應用調用處理。
• Moonbox能夠對異構系統進行即席混算，這個能力賦予Moonbox「瑞士軍刀」般的便利性。能夠經過Moonbox編寫定時SQL腳本邏輯，對關注的異構系統數據進行比對，或對關注的數據表字段進行統計等，能夠基於Moonbox的能力二次開發數據質量檢測系統。

3）血緣分析

• Wormhole的流上處理邏輯一般SQL便可知足，這些SQL能夠經過RESTful服務進行歸集。
• Moonbox掌管了數據查詢的統一入口，而且全部邏輯均爲SQL，這些SQL能夠經過Moonbox日誌進行歸集。
• 對於RTDP架構來講，實時處理邏輯和即席處理邏輯的SQL能夠經過調用Wormhole的RESTful服務和Moonbox的日誌歸集，能夠基於此建設企業級血緣分析系統。

1.3.2 數據安全

圖12 RTDP數據安全

上圖給出了RTDP架構中，四個開源平臺覆蓋了端到端數據流轉鏈路，而且在每一個節點上都有對數據安全各個方面的考量和支持，確保了實時數據管道端到端的數據安全性。

另外，因爲Moonbox成爲了面向應用層數據訪問的統一入口，所以基於Moonbox的操做審計日誌能夠得到不少安全層面的信息，能夠圍繞操做審計日誌創建數據安全預警機制，進而建設企業級數據安全系統。

1.3.3 開發運維

1）運維管理

• 實時數據處理的運維管理向來是個痛點，DBus和Wormhole經過可視化UI提供了可視化運維管理能力，讓人工運維變得簡單。
• DBus和Wormhole提供了健康檢查、操做管理、Backfill、Flow漂移等RESTful服務，能夠基於此研發自動化運維繫統。

2）監控預警

• DBus和Wormhole均提供可視化監控界面，能夠實時看到邏輯表級的吞吐和延遲等信息。
• DBus和Wormhole提供了心跳、Stats、狀態等RESTful服務，能夠基於此研發自動化預警系統。

2、模式場景探討

上一章咱們介紹了RTDP架構各個技術組件的設計架構和功能特性，至此讀者已經對RTDP架構如何落地有了具體的認識和了解。那麼RTDP架構能夠解決哪些常見數據應用場景呢？下面咱們會探討幾種使用模式，以及不一樣模式適應何種需求場景。

2.1 同步模式

2.1.1 模式描述

同步模式，是指只配置異構數據系統之間的數據實時同步，在流上不作任何處理邏輯的使用模式。

具體而言，經過配置DBus將數據從數據源實時抽取出來投放在Kafka上，而後經過配置Wormhole將Kafka上數據實時寫入到Sink存儲中。同步模式主要提供了兩個能力：

• 後續數據處理邏輯再也不執行在業務備庫上，減小了對業務備庫的使用壓力
• 提供了將不一樣物理業務備庫數據實時同步到同一物理數據存儲的可能性

2.1.2 技術難點

具體實施比較簡單。

IT實施人員無需瞭解太多流式處理的常見問題，不須要考慮流上處理邏輯實現的設計和實施，只須要了解基本的流控參數配置便可。

2.1.3 運維管理

運維管理比較簡單。

須要人工運維。但因爲流上沒有處理邏輯，所以容易把控流速，無需考慮流上處理邏輯自己的功耗，能夠給出一個相對穩定的同步管道配置。而且也很容易作到定時端到端數據比對來確保數據質量，由於源端和目標端的數據是徹底一致的。

2.1.4 適用場景

• 跨部門數據實時同步共享
• 交易數據庫和分析數據庫解耦
• 支持數倉實時ODS層建設
• 用戶自助實時簡單報表開發
• 等等

2.2 流算模式

2.2.1 模式描述

流算模式，是指在同步模式的基礎上，在流上配置處理邏輯的使用模式。

在RTDP架構中，流上處理邏輯的配置和支持主要在Wormhole平臺上進行。在同步模式的能力之上，流算模式主要提供了兩個能力：

• 流上計算將批量計算集中功耗分散在流上增量計算持續功耗，極大下降告終果快照的時間延遲
• 流上計算提供了跨異構系統混算的新的計算入口（Lookup）

2.2.2 技術難點

具體實施相對較難。

用戶須要瞭解流上處理能作哪些事，適合作哪些事，如何轉化全量計算邏輯成爲增量計算邏輯等。還要考慮流上處理邏輯自己功耗和依賴的外部數據系統等因素來調節配置更多參數。

2.2.3 運維管理

運維管理相對較難。

須要人工運維。但比同步模式運維管理更難，主要體如今流控參數配置考慮因素較多、沒法支持端到端數據比對、要選擇結果快照最終一致性實現策略、要考慮流上Lookup時間對齊策略等方面問題。

2.2.4 適用場景

• 對低延遲要求較高的數據應用項目或報表
• 須要低延遲調用外部服務（如流上調用外部規則引擎、在線算法模型使用等）
• 支持數倉實時事實表+維度表的寬表建設
• 實時多表融合、分拆、清洗、標準化Mapping場景
• 等等

2.3 輪轉模式

2.3.1 模式描述

輪轉模式，是指在流算模式的基礎上，在數據實時落庫中，同時跑短時定時任務在庫上進一步計算後，將結果再次投放在Kafka上跑下一輪流上計算，這樣流算轉批算、批算轉流算的使用模式。

在RTDP架構中，能夠利用Kafka->Wormhole->Sink->Moonbox->Kafka的整合方式實現任何輪次任何頻次的輪轉計算。在流算模式的能力之上，輪轉模式提供的主要能力是：理論上支持低延遲的任何複雜流轉計算邏輯。

2.3.2 技術難點

具體實施難。

Moonbox轉Wormhole能力的引入，比流算模式進一步增長了考慮的變量因素，如多Sink的選擇、Moonbox計算的頻率設定、如何拆分Wormhole和Moonbox的計算分工等方面問題。

2.3.3 運維管理

運維管理難。

須要人工運維。和流算模式比，須要更多數據系統因素的考慮、更多參數的配置調優、更難的數據質量管理和診斷監控。

2.3.4 適用場景

• 低延遲的多步驟的複雜數據處理邏輯場景
• 公司級實時數據流轉處理網絡建設

2.4 智能模式

2.4.1 模式描述

智能模式，是指利用規則或算法模型來進行優化和增效的使用模式。

能夠智能化的點：

• Wormhole Flow的智能漂移（智能化自動化運維）
• Moonbox預計算的智能優化（智能化自動化調優）
• 全量計算邏輯智能轉換成流式計算邏輯，而後部署在Wormhole + Moonbox（智能化自動化開發部署）
• 等等

2.4.2 技術難點

具體實施在理論上最簡單，但有效的技術實現最難。

用戶只須要完成離線邏輯開發，剩下交由智能化工具完成開發、部署、調優、運維。

2.4.3 運維管理

零運維。

2.4.4 適用場景

全場景。

自此，咱們對「如何設計實時數據平臺」這個話題的討論暫時告一段落。咱們從概念背景，討論到架構設計，接着介紹了技術組件，最後探討了模式場景。因爲這裏涉及到的每一個話題點都很大，本文只是作了淺層的介紹和探討。後續咱們會不按期針對某個具體話題點展開詳細討論，將咱們的實踐和心得呈現出來，拋磚引玉，集思廣益。若是對RTDP架構中的四個開源平臺感興趣，歡迎在GitHub上找到咱們，瞭解使用，交流建議。

做者：盧山巍

來源：宜信技術學院