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

敏捷之歌

我抽數故我存在 | DBus

人人玩轉流處理 | Wormhole

就當吾是數據庫 | Moonbox

顏值最后十公里 | Davinci

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

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

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

一、技術選型介紹

在設計篇中，我們給出了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 技術組件介紹

圖3 RTDP架構之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語義。

通過心跳表機制確保消息端到端探活感知。

支持配置化全量數據拉取

支持配置化增量數據拉取

支持配置化在線格式化日志

支持可視化監控預警

支持配置化多租戶安全管控

支持分表數據匯集成單邏輯表

圖4 DBus數據流轉架構圖

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

GitHub： https://github.com/BriData

Kafka已經成為事實標準的大數據流式處理分布式消息系統，當然Kafka在不斷的擴展和完善，現在也具備了一定的存儲能力和流式處理能力。關于Kafka本身的功能和技術已經有很多文章信息可以查閱，本文不再詳述Kafka的自身能力。

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

圖5

圖片來源：http://cloudurable.com/images/kafka-ecosystem-rest-proxy-schema-registry.png

圖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

http://cloudurable.com/blog/kafka-avro-schema-registry/index.html

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

DBus會自動將實時感知的數據庫元數據變化記錄下來并提供服務

DBus會自動將在線格式化的日志元數據信息記錄下來并提供服務

DBus會發布在Kafka上發布統一UMS消息，UMS本身自帶消息元數據信息，因此下游消費時無需調用中心化元數據服務，可以直接從UMS消息里拿到數據的元數據信息

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消息舉例

圖7 RTDP架構之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消息實時歸集流式作業動態指標和統計

支持可視化，配置化，SQL化開發實施流式項目

支持指令式動態流式處理的管理、運維、診斷和監控

支持統一結構化UMS消息和自定義半結構化JSON消息

支持處理增刪改三態事件消息流

支持單個物理流同時并行處理多個邏輯業務流

支持流上Lookup Anywhere，Pushdown Anywhere

支持基于業務策略的事件時間戳流式處理

支持UDF的注冊管理和動態加載

支持多目標數據系統的并發冪等入庫

支持多級基于增量消息的數據質量管理

支持基于增量消息的流式處理和批量處理

支持Lambda架構和Kappa架構

支持與三方系統無縫集成，可作為三方系統的流控引擎

支持私有云部署，安全權限管控和多租戶資源管理

圖8 Wormhole數據流轉架構圖

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

GitHub：https://github.com/edp963/wormhole

RTDP架構對待數據計算存儲選型的選擇采取開放整合的態度。不同數據系統有各自的優勢和適合的場景，但并沒有一個數據系統可以適合各種各樣的存儲計算場景。因此當有合適的、成熟的、主流的數據系統出現，Wormhole和Moonbox會按照需要相應的擴展整合支持。

這里大致列舉一些比較通用的選型：

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

分布式列存儲系統

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

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

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

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

分布式文件系統

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

分布式文檔系統

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

分布式索引系統

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

分布式預計算系統

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

圖9 RTDP架構之Moonbox

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

負責對接不同的數據系統，支持統一方式跨異構數據系統即席混算

提供三種Client調用方式：RESTful服務、JDBC連接、ODBC連接

統一元數據收口；統一查詢語言SQL收口；統一權限控制收口

提供兩種查詢結果寫出模式：Merge、Replace

提供兩種交互模式：Batch模式、Adhoc模式

數據虛擬化實現，多租戶實現，可看作是虛擬數據庫

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

對SQL進行解析，經過常規Catalyst處理解析流程，最終生成可下推數據系統的邏輯執行子樹進行下推計算，然后將結果拉回進行混算并返回

支持兩層Namespace：database.table，以提供虛擬數據庫體驗

提供分布式服務模塊Moonbox Grid提供高可用高并發能力

對可全部下推邏輯（無混算）提供快速執行通道

支持跨異構系統無縫混算

支持統一SQL語法查詢計算和寫入

支持三種調用方式：RESTful服務、JDBC連接、ODBC連接

支持兩種交互模式：Batch模式、Adhoc模式

支持Cli Command工具和Zeppelin

支持多租戶用戶權限體系

支持表級權限、列級權限、讀權限、寫權限、UDF權限

支持YARN調度器資源管理

支持元數據服務

支持定時任務

支持安全策略

圖10 Moonbox邏輯模塊

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

GitHub： https://github.com/edp963/moonbox

圖11 RTDP架構之Davinci

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

負責各種數據可視化展示功能

支持JDBC數據源

提供平權用戶體系，每個用戶可以建立屬于自己的Org、Team和Project

支持SQL編寫數據處理邏輯，支持拖拽式編輯可視化展示，提供多用戶社交化分工協作環境

提供多種不同的圖表交互能力和定制化能力，以應對不同數據可視化需求

提供嵌入整合進其他數據應用的能力

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

圍繞View和Widget展開。View是數據的邏輯視圖；Widget是數據可視化視圖

通過用戶自定義選擇分類數據、有序數據和量化數據，按照合理的可視化邏輯自動展現視圖

1)數據源

支持JDBC數據源

支持CSV文件上傳

2)數據視圖

支持定義SQL模版

支持SQL高亮顯示

支持SQL測試

支持回寫操作

3)可視組件

支持預定義圖表

支持控制器組件

支持自由樣式

4)交互能力

支持可視組件全屏顯示

支持可視組件本地控制器

支持可視組件間過濾聯動

支持群控控制器可視組件

支持可視組件本地高級過濾器

支持大數據量展示分頁和滑塊

5)集成能力

支持可視組件CSV下載

支持可視組件公共分享

支持可視組件授權分享

支持儀表板公共分享

支持儀表板授權分享

6)安全權限

支持數據行列權限

支持LDAP登錄集成

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

GitHub：https://github.com/edp963/davinci

1.3 切面話題討論

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的日志歸集，可以基于此建設企業級血緣分析系統。

圖12 RTDP數據安全

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

另外，由于Moonbox成為了面向應用層數據訪問的統一入口，因此基于Moonbox的操作審計日志可以獲得很多安全層面的信息，可以圍繞操作審計日志建立數據安全預警機制，進而建設企業級數據安全系統。

1）運維管理

實時數據處理的運維管理向來是個痛點，DBus和Wormhole通過可視化UI提供了可視化運維管理能力，讓人工運維變得簡單。

DBus和Wormhole提供了健康檢查、操作管理、Backfill、Flow漂移等RESTful服務，可以基于此研發自動化運維系統。

2）監控預警

DBus和Wormhole均提供可視化監控界面，可以實時看到邏輯表級的吞吐和延遲等信息。

DBus和Wormhole提供了心跳、Stats、狀態等RESTful服務，可以基于此研發自動化預警系統。

二、模式場景探討

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

2.1 同步模式

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

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

后續數據處理邏輯不再執行在業務備庫上，減少了對業務備庫的使用壓力

提供了將不同物理業務備庫數據實時同步到同一物理數據存儲的可能性

具體實施比較簡單。

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

運維管理比較簡單。

需要人工運維。但由于流上沒有處理邏輯，因此容易把控流速，無需考慮流上處理邏輯本身的功耗，可以給出一個相對穩定的同步管道配置。并且也很容易做到定時端到端數據比對來確保數據質量，因為源端和目標端的數據是完全一致的。

跨部門數據實時同步共享

交易數據庫和分析數據庫解耦

支持數倉實時ODS層建設

用戶自助實時簡單報表開發

等等

2.2 流算模式

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

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

流上計算將批量計算集中功耗分散在流上增量計算持續功耗，極大降低了結果快照的時間延遲

流上計算提供了跨異構系統混算的新的計算入口（Lookup）

具體實施相對較難。

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

運維管理相對較難。

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

對低延遲要求較高的數據應用項目或報表

需要低延遲調用外部服務（如流上調用外部規則引擎、在線算法模型使用等）

支持數倉實時事實表+維度表的寬表建設

實時多表融合、分拆、清洗、標準化Mapping場景

等等

2.3 輪轉模式

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

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

具體實施難。

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

運維管理難。

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

低延遲的多步驟的復雜數據處理邏輯場景

公司級實時數據流轉處理網絡建設

2.4 智能模式

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

可以智能化的點：

Wormhole Flow的智能漂移（智能化自動化運維）

Moonbox預計算的智能優化（智能化自動化調優）

全量計算邏輯智能轉換成流式計算邏輯，然后部署在Wormhole + Moonbox（智能化自動化開發部署）

等等

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

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

零運維。

全場景。

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

來源：宜信技術學院

本文轉載自異步社區。

Kafka 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。