如何設計實時數(shù)據(jù)平臺（技術篇）

?

敏捷之歌

我抽數(shù)故我存在 | DBus

人人玩轉流處理 | Wormhole

就當吾是數(shù)據(jù)庫 | Moonbox

顏值最后十公里 | Davinci

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

拓展閱讀：如何設計實時數(shù)據(jù)平臺（設計篇） <https://www.cnblogs.com/yixinjishu/p/11277512.html>

一、技術選型介紹


在設計篇中，我們給出了RTDP的一個整體架構設計（圖1）。在技術篇里，我們則會推薦整體技術組件選型；對每個技術組件做出簡單介紹，尤其對我們抽象并實現(xiàn)的四個技術平臺（統(tǒng)一數(shù)據(jù)采集平臺、統(tǒng)一流式處理平臺、統(tǒng)一計算服務平臺、統(tǒng)一數(shù)據(jù)可視化平臺）著重介紹設計思路；對Pipeline端到端切面話題進行探討，包括功能整合、數(shù)據(jù)管理、數(shù)據(jù)安全等。



圖1 RTDP架構

1.1 整體技術選型



圖2 整體技術選型

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

* 數(shù)據(jù)源、客戶端，列舉了大多數(shù)數(shù)據(jù)應用項目的常用數(shù)據(jù)源類型。
*
數(shù)據(jù)總線平臺DBus，作為統(tǒng)一數(shù)據(jù)采集平臺，負責對接各種數(shù)據(jù)源。DBus將數(shù)據(jù)以增量或全量方式抽取出來，并進行一些常規(guī)數(shù)據(jù)處理，最后將處理后的消息發(fā)布在Kafka上。
* 分布式消息系統(tǒng)Kafka，以分布式、高可用、高吞吐、可發(fā)布-訂閱等能力，連接消息的生產(chǎn)者和消費者。
*
流式處理平臺Wormhole，作為統(tǒng)一流式處理平臺，負責流上處理和對接各種數(shù)據(jù)目標存儲。Wormhole從Kafka消費消息，支持流上配置SQL方式實現(xiàn)流上數(shù)據(jù)處理邏輯，并支持配置化方式將數(shù)據(jù)以最終一致性（冪等）效果落入不同數(shù)據(jù)目標存儲（Sink）中。
*
在數(shù)據(jù)計算存儲層，RTDP架構選擇開放技術組件選型，用戶可以根據(jù)實際數(shù)據(jù)特性、計算模式、訪問模式、數(shù)據(jù)量等信息選擇合適的存儲，解決具體數(shù)據(jù)項目問題。RTDP還支持同時選擇多個不同數(shù)據(jù)存儲，從而更靈活的支持不同項目需求。
*
計算服務平臺Moonbox，作為統(tǒng)一計算服務平臺，對異構數(shù)據(jù)存儲端負責整合、計算下推優(yōu)化、異構數(shù)據(jù)存儲混算等（數(shù)據(jù)虛擬化技術），對數(shù)據(jù)展示和交互端負責收口統(tǒng)一元數(shù)據(jù)查詢、統(tǒng)一數(shù)據(jù)計算和下發(fā)、統(tǒng)一數(shù)據(jù)查詢語言（SQL）、統(tǒng)一數(shù)據(jù)服務接口等。
*
可視應用平臺Davinci，作為統(tǒng)一數(shù)據(jù)可視化平臺，以配置化方式支持各種數(shù)據(jù)可視化和交互需求，并可以整合其他數(shù)據(jù)應用以提供數(shù)據(jù)可視化部分需求解決方案，另外還支持不同數(shù)據(jù)從業(yè)人員在平臺上協(xié)作完成各項日常數(shù)據(jù)應用。其他數(shù)據(jù)終端消費系統(tǒng)如數(shù)據(jù)開發(fā)平臺Zeppelin、數(shù)據(jù)算法平臺Jupyter等在本文不做介紹。
*
切面話題如數(shù)據(jù)管理、數(shù)據(jù)安全、開發(fā)運維、驅動引擎，可以通過對接DBus、Wormhole、Moonbox、Davinci的服務接口進行整合和二次開發(fā)，以支持端到端管控和治理需求。
下面我們會進一步細化上圖涉及到的技術組件和切面話題，介紹技術組件的功能特性，著重講解我們自研技術組件的設計思想，并對切面話題展開討論。

1.2 技術組件介紹

1.2.1 數(shù)據(jù)總線平臺DBus



圖3 RTDP架構之DBus

1.2.1.1 DBus設計思想

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

* 負責對接不同的數(shù)據(jù)源，實時抽取出增量數(shù)據(jù)，對于數(shù)據(jù)庫會采用操作日志抽取方式，對于日志類型支持與多種Agent對接。
* 將所有消息以統(tǒng)一的UMS消息格式發(fā)布在Kafka上，UMS是一種標準化的自帶元數(shù)據(jù)信息的JSON格式，通過統(tǒng)一UMS實現(xiàn)邏輯消息與物理Kafka
Topic解耦，使得同一Topic可以流轉多個UMS消息表。
* 支持數(shù)據(jù)庫的全量數(shù)據(jù)拉取，并且和增量數(shù)據(jù)統(tǒng)一融合成UMS消息，對下游消費透明無感知。
2）從內(nèi)部角度看待設計思想

* 基于Storm計算引擎進行數(shù)據(jù)格式化，確保消息端到端延遲最低。
* 對不同數(shù)據(jù)源數(shù)據(jù)進行標準化格式化，生成UMS信息，其中包括：
? 生成每條消息的唯一單調(diào)遞增id，對應系統(tǒng)字段ums_id_

? 確認每條消息的事件時間戳（event timestamp），對應系統(tǒng)字段ums_ts_

? 確認每條消息的操作模式（增刪改，或insert only），對應系統(tǒng)字段ums_op_

* 對數(shù)據(jù)庫表結構變更實時感知并采用版本號進行管理，確保下游消費時明確上游元數(shù)據(jù)變化。
* 在投放Kafka時確保消息強有序（非絕對有序）和at least once語義。
* 通過心跳表機制確保消息端到端探活感知。
1.2.1.2 DBus功能特性

* 支持配置化全量數(shù)據(jù)拉取
* 支持配置化增量數(shù)據(jù)拉取
* 支持配置化在線格式化日志
* 支持可視化監(jiān)控預警
* 支持配置化多租戶安全管控
* 支持分表數(shù)據(jù)匯集成單邏輯表
1.2.1.3 DBus技術架構



圖4 DBus數(shù)據(jù)流轉架構圖

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

GitHub： https://github.com/BriData

1.2.2 分布式消息系統(tǒng)Kafka


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

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



圖5?


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

圖5顯示，在Kafka背后的Confluent公司解決方案中，引入了一個元數(shù)據(jù)管理組件：Schema
Registry。這個組件主要負責管理在Kafka上流轉消息的
元數(shù)據(jù)信息和Topic信息，并提供一系列元數(shù)據(jù)管理服務。之所以要引入這樣一個組件，是為了Kafka的消費方能夠了解不同Topic上流轉的是哪些數(shù)據(jù)，以及數(shù)據(jù)的元數(shù)據(jù)信息，并進行有效的解析消費。

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

更多關于Schema Registry的介紹，可以參看：

Kafka Tutorial:Kafka, Avro Serialization and the Schema Registry

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

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

1.2.2.1 元數(shù)據(jù)管理（Metadata Management）

* DBus會自動將實時感知的數(shù)據(jù)庫元數(shù)據(jù)變化記錄下來并提供服務
* DBus會自動將在線格式化的日志元數(shù)據(jù)信息記錄下來并提供服務
*
DBus會發(fā)布在Kafka上發(fā)布統(tǒng)一UMS消息，UMS本身自帶消息元數(shù)據(jù)信息，因此下游消費時無需調(diào)用中心化元數(shù)據(jù)服務，可以直接從UMS消息里拿到數(shù)據(jù)的元數(shù)據(jù)信息
1.2.2.2 模式演變（Schema Evolution）

*
UMS消息會自帶Schema的Namespace信息，Namespace是一個7層定位字符串，可以唯一定位任何表的任何生命周期，相當于數(shù)據(jù)表的IP地址，形式如下：
[Datastore].[Datastore Instance].[Database].[Table].[TableVersion].[Database
Partition].[Table Partition]

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

其中[Table Version]代表了這張表的某個Schema的版本號，如果數(shù)據(jù)源是數(shù)據(jù)庫，那么這個版本號是由DBus自動維護的。

*
在RTDP架構中，Kafka的下游是由Wormhole消費的，Wormhole在消費UMS時，會將[TableVersion]作為*處理，意味著當某表上游Schema變更時，Version會自動升號，但Wormhole會無視這個Version變化，將會消費此表所有版本的增量/全量數(shù)據(jù)，那么Wormhole如何做到兼容性模式演變支持呢？在Wormhole里可以配置流上處理SQL和輸出字段，當上游Schema變更是一種“兼容性變更”（指增加字段，或者修改擴大字段類型等）時，是不會影響到Wormhole
SQL正確執(zhí)行的。當上游發(fā)生非兼容性變更時，Wormhole會報錯，這時就需要人工介入對新Schema的邏輯進行修復。
由上文可以看出，Schema Registry和DBus+UMS是兩種不同的解決元數(shù)據(jù)管理和模式演變的設計思路，兩者各有優(yōu)勢和劣勢，可以參考表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消息
* 負責對接不同的數(shù)據(jù)目標存儲 (Sink)，并通過冪等邏輯實現(xiàn)Sink的最終一致性
* 支持配置SQL方式實現(xiàn)流上處理邏輯
* 提供Flow抽象。Flow由一個Source Namespace和一個Sink
Namespace定義，且具備唯一性。Flow上可以定義處理邏輯，是一種流上處理的邏輯抽象，通過與物理Spark Streaming、Flink
Streaming解耦，使得同一個Stream可以處理多個Flow處理流，且Flow可以在不同Stream上任意切換。
* 支持基于回灌（backfill）的Kappa架構；支持基于Wormhole Job的Lambda架構
2)從內(nèi)部角度看待設計思想

* 基于Spark Streaming、Flink計算引擎進行數(shù)據(jù)流上處理。Spark
Streaming可支持高吞吐、批量Lookup、批量寫Sink等場景；Flink可支持低延遲、CEP規(guī)則等場景。
* 通過ums_id_, ums_op_實現(xiàn)不同Sink的冪等入庫邏輯
* 通過計算下推實現(xiàn)Lookup邏輯優(yōu)化
* 抽象幾個統(tǒng)一以支持功能靈活性和設計一致性
? 統(tǒng)一DAG高階分形抽象

? 統(tǒng)一通用流消息UMS協(xié)議抽象

? 統(tǒng)一數(shù)據(jù)邏輯表命名空間Namespace抽象

* 抽象幾個接口以支持可擴展性
? SinkProcessor：擴展更多Sink支持

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

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

* 通過Feedback消息實時歸集流式作業(yè)動態(tài)指標和統(tǒng)計
1.2.3.2 Wormhole功能特性

* 支持可視化，配置化，SQL化開發(fā)實施流式項目
* 支持指令式動態(tài)流式處理的管理、運維、診斷和監(jiān)控
* 支持統(tǒng)一結構化UMS消息和自定義半結構化JSON消息
* 支持處理增刪改三態(tài)事件消息流
* 支持單個物理流同時并行處理多個邏輯業(yè)務流
* 支持流上Lookup Anywhere，Pushdown Anywhere
* 支持基于業(yè)務策略的事件時間戳流式處理
* 支持UDF的注冊管理和動態(tài)加載
* 支持多目標數(shù)據(jù)系統(tǒng)的并發(fā)冪等入庫
* 支持多級基于增量消息的數(shù)據(jù)質量管理
* 支持基于增量消息的流式處理和批量處理
* 支持Lambda架構和Kappa架構
* 支持與三方系統(tǒng)無縫集成，可作為三方系統(tǒng)的流控引擎
* 支持私有云部署，安全權限管控和多租戶資源管理
1.2.3.3 Wormhole技術架構



圖8 Wormhole數(shù)據(jù)流轉架構圖

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

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

1.2.4 常用數(shù)據(jù)計算存儲選型


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

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

*
關系型數(shù)據(jù)庫（Oracle/MySQL等）：適合小數(shù)據(jù)量的復雜關系計算

*
分布式列存儲系統(tǒng)

? Kudu：Scan優(yōu)化，適合OLAP分析計算場景

? HBase：隨機讀寫，適合提供數(shù)據(jù)服務場景

? Cassandra：高性能寫，適合海量數(shù)據(jù)高頻寫入場景

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

* 分布式文件系統(tǒng)
? HDFS/Parquet/Hive：append only，適合海量數(shù)據(jù)批量計算場景

* 分布式文檔系統(tǒng)
? MongoDB：平衡能力，適合大數(shù)據(jù)量中等復雜計算

* 分布式索引系統(tǒng)
? ElasticSearch：索引能力，適合做模糊查詢和OLAP分析場景

* 分布式預計算系統(tǒng)
? Druid/Kylin：預計算能力，適合高性能OLAP分析場景

1.2.5 計算服務平臺Moonbox



圖9 RTDP架構之Moonbox

1.2.5.1 Moonbox設計思想

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

* 負責對接不同的數(shù)據(jù)系統(tǒng)，支持統(tǒng)一方式跨異構數(shù)據(jù)系統(tǒng)即席混算
* 提供三種Client調(diào)用方式：RESTful服務、JDBC連接、ODBC連接
* 統(tǒng)一元數(shù)據(jù)收口；統(tǒng)一查詢語言SQL收口；統(tǒng)一權限控制收口
* 提供兩種查詢結果寫出模式：Merge、Replace
* 提供兩種交互模式：Batch模式、Adhoc模式
* 數(shù)據(jù)虛擬化實現(xiàn)，多租戶實現(xiàn)，可看作是虛擬數(shù)據(jù)庫
2)從內(nèi)部角度看待設計思想

* 對SQL進行解析，經(jīng)過常規(guī)Catalyst處理解析流程，最終生成可下推數(shù)據(jù)系統(tǒng)的邏輯執(zhí)行子樹進行下推計算，然后將結果拉回進行混算并返回
* 支持兩層Namespace：database.table，以提供虛擬數(shù)據(jù)庫體驗
* 提供分布式服務模塊Moonbox Grid提供高可用高并發(fā)能力
* 對可全部下推邏輯（無混算）提供快速執(zhí)行通道
1.2.5.2 Moonbox功能特性

* 支持跨異構系統(tǒng)無縫混算
* 支持統(tǒng)一SQL語法查詢計算和寫入
* 支持三種調(diào)用方式：RESTful服務、JDBC連接、ODBC連接
* 支持兩種交互模式：Batch模式、Adhoc模式
* 支持Cli Command工具和Zeppelin
* 支持多租戶用戶權限體系
* 支持表級權限、列級權限、讀權限、寫權限、UDF權限
* 支持YARN調(diào)度器資源管理
* 支持元數(shù)據(jù)服務
* 支持定時任務
* 支持安全策略
1.2.5.3 Moonbox技術架構



圖10 Moonbox邏輯模塊

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

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

1.2.6 可視應用平臺Davinci



圖11 RTDP架構之Davinci

1.2.6.1 Davinci設計思想

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

* 負責各種數(shù)據(jù)可視化展示功能
* 支持JDBC數(shù)據(jù)源
* 提供平權用戶體系，每個用戶可以建立屬于自己的Org、Team和Project
* 支持SQL編寫數(shù)據(jù)處理邏輯，支持拖拽式編輯可視化展示，提供多用戶社交化分工協(xié)作環(huán)境
* 提供多種不同的圖表交互能力和定制化能力，以應對不同數(shù)據(jù)可視化需求
* 提供嵌入整合進其他數(shù)據(jù)應用的能力
2)從內(nèi)部角度看待設計思想

* 圍繞View和Widget展開。View是數(shù)據(jù)的邏輯視圖；Widget是數(shù)據(jù)可視化視圖
* 通過用戶自定義選擇分類數(shù)據(jù)、有序數(shù)據(jù)和量化數(shù)據(jù)，按照合理的可視化邏輯自動展現(xiàn)視圖
1.2.6.2 Davinci功能特性

1)數(shù)據(jù)源

* 支持JDBC數(shù)據(jù)源
* 支持CSV文件上傳
2)數(shù)據(jù)視圖

* 支持定義SQL模版
* 支持SQL高亮顯示
* 支持SQL測試
* 支持回寫操作
3)可視組件

* 支持預定義圖表
* 支持控制器組件
* 支持自由樣式
4)交互能力

* 支持可視組件全屏顯示
* 支持可視組件本地控制器
* 支持可視組件間過濾聯(lián)動
* 支持群控控制器可視組件
* 支持可視組件本地高級過濾器
* 支持大數(shù)據(jù)量展示分頁和滑塊
5)集成能力

* 支持可視組件CSV下載
* 支持可視組件公共分享
* 支持可視組件授權分享
* 支持儀表板公共分享
* 支持儀表板授權分享
6)安全權限

* 支持數(shù)據(jù)行列權限
* 支持LDAP登錄集成
更多Davinci技術細節(jié)和用戶界面，可以參看：

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

1.3 切面話題討論

1.3.1 數(shù)據(jù)管理

1）元數(shù)據(jù)管理

* DBus可以實時拿到數(shù)據(jù)源的元數(shù)據(jù)并提供服務查詢
* Moonbox可以實時拿到數(shù)據(jù)系統(tǒng)的元數(shù)據(jù)并提供服務查詢
* 對于RTDP架構來說，實時數(shù)據(jù)源和即席數(shù)據(jù)源的元數(shù)據(jù)信息可以通過調(diào)用DBus和Moonbox的RESTful服務歸集，可以基于此建設企業(yè)級元數(shù)據(jù)管理系統(tǒng)
2）數(shù)據(jù)質量

* Wormhole可以配置消息實時落入HDFS（hdfslog）?；趆dfslog的Wormhole
Job支持Lambda架構；基于hdfslog的Backfill支持Kappa架構?？梢酝ㄟ^設置定時任務選擇Lambda架構或者Kappa架構對Sink進行定時刷新，以確保數(shù)據(jù)的最終一致性。Wormhole還支持將流上處理異?；騍ink寫入異常的消息信息實時Feedback到Wormhole系統(tǒng)中，并提供RESTful服務供三方應用調(diào)用處理。
*
Moonbox可以對異構系統(tǒng)進行即席混算，這個能力賦予Moonbox“瑞士軍刀”般的便利性?？梢酝ㄟ^Moonbox編寫定時SQL腳本邏輯，對關注的異構系統(tǒng)數(shù)據(jù)進行比對，或對關注的數(shù)據(jù)表字段進行統(tǒng)計等，可以基于Moonbox的能力二次開發(fā)數(shù)據(jù)質量檢測系統(tǒng)。
3）血緣分析

* Wormhole的流上處理邏輯通常SQL即可滿足，這些SQL可以通過RESTful服務進行歸集。
* Moonbox掌管了數(shù)據(jù)查詢的統(tǒng)一入口，并且所有邏輯均為SQL，這些SQL可以通過Moonbox日志進行歸集。
*
對于RTDP架構來說，實時處理邏輯和即席處理邏輯的SQL可以通過調(diào)用Wormhole的RESTful服務和Moonbox的日志歸集，可以基于此建設企業(yè)級血緣分析系統(tǒng)。
1.3.2 數(shù)據(jù)安全



圖12 RTDP數(shù)據(jù)安全

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


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

1.3.3 開發(fā)運維

1）運維管理

* 實時數(shù)據(jù)處理的運維管理向來是個痛點，DBus和Wormhole通過可視化UI提供了可視化運維管理能力，讓人工運維變得簡單。
* DBus和Wormhole提供了健康檢查、操作管理、Backfill、Flow漂移等RESTful服務，可以基于此研發(fā)自動化運維系統(tǒng)。
2）監(jiān)控預警

* DBus和Wormhole均提供可視化監(jiān)控界面，可以實時看到邏輯表級的吞吐和延遲等信息。
* DBus和Wormhole提供了心跳、Stats、狀態(tài)等RESTful服務，可以基于此研發(fā)自動化預警系統(tǒng)。
二、模式場景探討


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

2.1 同步模式

2.1.1 模式描述

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


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

* 后續(xù)數(shù)據(jù)處理邏輯不再執(zhí)行在業(yè)務備庫上，減少了對業(yè)務備庫的使用壓力
* 提供了將不同物理業(yè)務備庫數(shù)據(jù)實時同步到同一物理數(shù)據(jù)存儲的可能性
2.1.2 技術難點

具體實施比較簡單。

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

2.1.3 運維管理

運維管理比較簡單。


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

2.1.4 適用場景

* 跨部門數(shù)據(jù)實時同步共享
* 交易數(shù)據(jù)庫和分析數(shù)據(jù)庫解耦
* 支持數(shù)倉實時ODS層建設
* 用戶自助實時簡單報表開發(fā)
* 等等
2.2 流算模式

2.2.1 模式描述

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

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

* 流上計算將批量計算集中功耗分散在流上增量計算持續(xù)功耗，極大降低了結果快照的時間延遲
* 流上計算提供了跨異構系統(tǒng)混算的新的計算入口（Lookup）
2.2.2 技術難點

具體實施相對較難。


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

2.2.3 運維管理

運維管理相對較難。


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

2.2.4 適用場景

* 對低延遲要求較高的數(shù)據(jù)應用項目或報表
* 需要低延遲調(diào)用外部服務（如流上調(diào)用外部規(guī)則引擎、在線算法模型使用等）
* 支持數(shù)倉實時事實表+維度表的寬表建設
* 實時多表融合、分拆、清洗、標準化Mapping場景
* 等等
2.3 輪轉模式

2.3.1 模式描述


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


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

2.3.2 技術難點

具體實施難。


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

2.3.3 運維管理

運維管理難。

需要人工運維。和流算模式比，需要更多數(shù)據(jù)系統(tǒng)因素的考慮、更多參數(shù)的配置調(diào)優(yōu)、更難的數(shù)據(jù)質量管理和診斷監(jiān)控。

2.3.4 適用場景

* 低延遲的多步驟的復雜數(shù)據(jù)處理邏輯場景
* 公司級實時數(shù)據(jù)流轉處理網(wǎng)絡建設
2.4 智能模式

2.4.1 模式描述

智能模式，是指利用規(guī)則或算法模型來進行優(yōu)化和增效的使用模式。

可以智能化的點：

* Wormhole Flow的智能漂移（智能化自動化運維）
* Moonbox預計算的智能優(yōu)化（智能化自動化調(diào)優(yōu)）
* 全量計算邏輯智能轉換成流式計算邏輯，然后部署在Wormhole + Moonbox（智能化自動化開發(fā)部署）
* 等等
2.4.2 技術難點

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

用戶只需要完成離線邏輯開發(fā)，剩下交由智能化工具完成開發(fā)、部署、調(diào)優(yōu)、運維。

2.4.3 運維管理

零運維。

2.4.4 適用場景

全場景。?


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

作者：盧山巍

來源：宜信技術學院

• ? 上一篇：iNeuOS 物聯(lián)網(wǎng)云操作系統(tǒng)2.0發(fā)布，集成設備容器、視圖建模、機器學習三大模塊
• ? 下一篇：Appium+python自動化（三十一）- 元芳，你怎么看？ - 日志收集-logging（超詳解）