如何設(shè)計(jì)實(shí)時(shí)數(shù)據(jù)平臺(tái)（技術(shù)篇）

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

拓展閱讀：如何設(shè)計(jì)實(shí)時(shí)數(shù)據(jù)平臺(tái)（設(shè)計(jì)篇）

一、技術(shù)選型介紹

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

圖1 RTDP架構(gòu)

1.1 整體技術(shù)選型

圖2 整體技術(shù)選型

首先，我們簡(jiǎn)要解讀一下圖2：

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

下面我們會(huì)進(jìn)一步細(xì)化上圖涉及到的技術(shù)組件和切面話題，介紹技術(shù)組件的功能特性，著重講解我們自研技術(shù)組件的設(shè)計(jì)思想，并對(duì)切面話題展開討論。

1.2 技術(shù)組件介紹

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

圖3 RTDP架構(gòu)之DBus

1.2.1.1 DBus設(shè)計(jì)思想

1）從外部角度看待設(shè)計(jì)思想

• 負(fù)責(zé)對(duì)接不同的數(shù)據(jù)源，實(shí)時(shí)抽取出增量數(shù)據(jù)，對(duì)于數(shù)據(jù)庫(kù)會(huì)采用操作日志抽取方式，對(duì)于日志類型支持與多種Agent對(duì)接。
• 將所有消息以統(tǒng)一的UMS消息格式發(fā)布在Kafka上，UMS是一種標(biāo)準(zhǔn)化的自帶元數(shù)據(jù)信息的JSON格式，通過(guò)統(tǒng)一UMS實(shí)現(xiàn)邏輯消息與物理Kafka Topic解耦，使得同一Topic可以流轉(zhuǎn)多個(gè)UMS消息表。
• 支持?jǐn)?shù)據(jù)庫(kù)的全量數(shù)據(jù)拉取，并且和增量數(shù)據(jù)統(tǒng)一融合成UMS消息，對(duì)下游消費(fèi)透明無(wú)感知。

2）從內(nèi)部角度看待設(shè)計(jì)思想

• 基于Storm計(jì)算引擎進(jìn)行數(shù)據(jù)格式化，確保消息端到端延遲最低。
• 對(duì)不同數(shù)據(jù)源數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化格式化，生成UMS信息，其中包括：

? 生成每條消息的唯一單調(diào)遞增id，對(duì)應(yīng)系統(tǒng)字段ums_id_

? 確認(rèn)每條消息的事件時(shí)間戳（event timestamp），對(duì)應(yīng)系統(tǒng)字段ums_ts_

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

• 對(duì)數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更實(shí)時(shí)感知并采用版本號(hào)進(jìn)行管理，確保下游消費(fèi)時(shí)明確上游元數(shù)據(jù)變化。
• 在投放Kafka時(shí)確保消息強(qiáng)有序（非絕對(duì)有序）和at least once語(yǔ)義。
• 通過(guò)心跳表機(jī)制確保消息端到端探活感知。

1.2.1.2 DBus功能特性

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

1.2.1.3 DBus技術(shù)架構(gòu)

圖4 DBus數(shù)據(jù)流轉(zhuǎn)架構(gòu)圖

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

GitHub： https://github.com/BriData

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

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

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

圖5

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

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

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

更多關(guān)于Schema Registry的介紹，可以參看：

Kafka Tutorial:Kafka, Avro Serialization and the Schema Registry

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

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

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

• DBus會(huì)自動(dòng)將實(shí)時(shí)感知的數(shù)據(jù)庫(kù)元數(shù)據(jù)變化記錄下來(lái)并提供服務(wù)
• DBus會(huì)自動(dòng)將在線格式化的日志元數(shù)據(jù)信息記錄下來(lái)并提供服務(wù)
• DBus會(huì)發(fā)布在Kafka上發(fā)布統(tǒng)一UMS消息，UMS本身自帶消息元數(shù)據(jù)信息，因此下游消費(fèi)時(shí)無(wú)需調(diào)用中心化元數(shù)據(jù)服務(wù)，可以直接從UMS消息里拿到數(shù)據(jù)的元數(shù)據(jù)信息

1.2.2.2 模式演變（Schema Evolution）

• UMS消息會(huì)自帶Schema的Namespace信息，Namespace是一個(gè)7層定位字符串，可以唯一定位任何表的任何生命周期，相當(dāng)于數(shù)據(jù)表的IP地址，形式如下：

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

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

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

• 在RTDP架構(gòu)中，Kafka的下游是由Wormhole消費(fèi)的，Wormhole在消費(fèi)UMS時(shí)，會(huì)將[TableVersion]作為*處理，意味著當(dāng)某表上游Schema變更時(shí)，Version會(huì)自動(dòng)升號(hào)，但Wormhole會(huì)無(wú)視這個(gè)Version變化，將會(huì)消費(fèi)此表所有版本的增量/全量數(shù)據(jù)，那么Wormhole如何做到兼容性模式演變支持呢？在Wormhole里可以配置流上處理SQL和輸出字段，當(dāng)上游Schema變更是一種“兼容性變更”（指增加字段，或者修改擴(kuò)大字段類型等）時(shí)，是不會(huì)影響到Wormhole SQL正確執(zhí)行的。當(dāng)上游發(fā)生非兼容性變更時(shí)，Wormhole會(huì)報(bào)錯(cuò)，這時(shí)就需要人工介入對(duì)新Schema的邏輯進(jìn)行修復(fù)。

由上文可以看出，Schema Registry和DBus+UMS是兩種不同的解決元數(shù)據(jù)管理和模式演變的設(shè)計(jì)思路，兩者各有優(yōu)勢(shì)和劣勢(shì)，可以參考表1的簡(jiǎn)單比較。

表1 Schema Registry 與 DBus+UMS 對(duì)比

這里給出一個(gè)UMS的例子：

圖6 UMS消息舉例

1.2.3 流式處理平臺(tái)Wormhole

圖7 RTDP架構(gòu)之Wormhole

1.2.3.1 Wormhole設(shè)計(jì)思想

1)從外部角度看待設(shè)計(jì)思想

• 消費(fèi)來(lái)自Kafka 的UMS消息和自定義JSON消息
• 負(fù)責(zé)對(duì)接不同的數(shù)據(jù)目標(biāo)存儲(chǔ) (Sink)，并通過(guò)冪等邏輯實(shí)現(xiàn)Sink的最終一致性
• 支持配置SQL方式實(shí)現(xiàn)流上處理邏輯
• 提供Flow抽象。Flow由一個(gè)Source Namespace和一個(gè)Sink Namespace定義，且具備唯一性。Flow上可以定義處理邏輯，是一種流上處理的邏輯抽象，通過(guò)與物理Spark Streaming、Flink Streaming解耦，使得同一個(gè)Stream可以處理多個(gè)Flow處理流，且Flow可以在不同Stream上任意切換。
• 支持基于回灌（backfill）的Kappa架構(gòu)；支持基于Wormhole Job的Lambda架構(gòu)

2)從內(nèi)部角度看待設(shè)計(jì)思想

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

? 統(tǒng)一DAG高階分形抽象

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

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

• 抽象幾個(gè)接口以支持可擴(kuò)展性

? SinkProcessor：擴(kuò)展更多Sink支持

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

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

• 通過(guò)Feedback消息實(shí)時(shí)歸集流式作業(yè)動(dòng)態(tài)指標(biāo)和統(tǒng)計(jì)

1.2.3.2 Wormhole功能特性

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

1.2.3.3 Wormhole技術(shù)架構(gòu)

圖8 Wormhole數(shù)據(jù)流轉(zhuǎn)架構(gòu)圖

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

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

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

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

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

• 關(guān)系型數(shù)據(jù)庫(kù)（Oracle/MySQL等）：適合小數(shù)據(jù)量的復(fù)雜關(guān)系計(jì)算

• 分布式列存儲(chǔ)系統(tǒng)

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

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

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

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

• 分布式文件系統(tǒng)

? HDFS/Parquet/Hive：append only，適合海量數(shù)據(jù)批量計(jì)算場(chǎng)景

• 分布式文檔系統(tǒng)

? MongoDB：平衡能力，適合大數(shù)據(jù)量中等復(fù)雜計(jì)算

• 分布式索引系統(tǒng)

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

• 分布式預(yù)計(jì)算系統(tǒng)

? Druid/Kylin：預(yù)計(jì)算能力，適合高性能OLAP分析場(chǎng)景

1.2.5 計(jì)算服務(wù)平臺(tái)Moonbox

圖9 RTDP架構(gòu)之Moonbox

1.2.5.1 Moonbox設(shè)計(jì)思想

1)從外部角度看待設(shè)計(jì)思想

• 負(fù)責(zé)對(duì)接不同的數(shù)據(jù)系統(tǒng)，支持統(tǒng)一方式跨異構(gòu)數(shù)據(jù)系統(tǒng)即席混算
• 提供三種Client調(diào)用方式：RESTful服務(wù)、JDBC連接、ODBC連接
• 統(tǒng)一元數(shù)據(jù)收口；統(tǒng)一查詢語(yǔ)言SQL收口；統(tǒng)一權(quán)限控制收口
• 提供兩種查詢結(jié)果寫出模式：Merge、Replace
• 提供兩種交互模式：Batch模式、Adhoc模式
• 數(shù)據(jù)虛擬化實(shí)現(xiàn)，多租戶實(shí)現(xiàn)，可看作是虛擬數(shù)據(jù)庫(kù)

2)從內(nèi)部角度看待設(shè)計(jì)思想

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

1.2.5.2 Moonbox功能特性

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

1.2.5.3 Moonbox技術(shù)架構(gòu)

圖10 Moonbox邏輯模塊

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

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

1.2.6 可視應(yīng)用平臺(tái)Davinci

圖11 RTDP架構(gòu)之Davinci

1.2.6.1 Davinci設(shè)計(jì)思想

1)從外部角度看待設(shè)計(jì)思想

• 負(fù)責(zé)各種數(shù)據(jù)可視化展示功能
• 支持JDBC數(shù)據(jù)源
• 提供平權(quán)用戶體系，每個(gè)用戶可以建立屬于自己的Org、Team和Project
• 支持SQL編寫數(shù)據(jù)處理邏輯，支持拖拽式編輯可視化展示，提供多用戶社交化分工協(xié)作環(huán)境
• 提供多種不同的圖表交互能力和定制化能力，以應(yīng)對(duì)不同數(shù)據(jù)可視化需求
• 提供嵌入整合進(jìn)其他數(shù)據(jù)應(yīng)用的能力

2)從內(nèi)部角度看待設(shè)計(jì)思想

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

1.2.6.2 Davinci功能特性

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

• 支持JDBC數(shù)據(jù)源
• 支持CSV文件上傳

2)數(shù)據(jù)視圖

• 支持定義SQL模版
• 支持SQL高亮顯示
• 支持SQL測(cè)試
• 支持回寫操作

3)可視組件

• 支持預(yù)定義圖表
• 支持控制器組件
• 支持自由樣式

4)交互能力

• 支持可視組件全屏顯示
• 支持可視組件本地控制器
• 支持可視組件間過(guò)濾聯(lián)動(dòng)
• 支持群控控制器可視組件
• 支持可視組件本地高級(jí)過(guò)濾器
• 支持大數(shù)據(jù)量展示分頁(yè)和滑塊

5)集成能力

• 支持可視組件CSV下載
• 支持可視組件公共分享
• 支持可視組件授權(quán)分享
• 支持儀表板公共分享
• 支持儀表板授權(quán)分享

6)安全權(quán)限

• 支持?jǐn)?shù)據(jù)行列權(quán)限
• 支持LDAP登錄集成

更多Davinci技術(shù)細(xì)節(jié)和用戶界面，可以參看：

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

1.3 切面話題討論

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

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

• DBus可以實(shí)時(shí)拿到數(shù)據(jù)源的元數(shù)據(jù)并提供服務(wù)查詢
• Moonbox可以實(shí)時(shí)拿到數(shù)據(jù)系統(tǒng)的元數(shù)據(jù)并提供服務(wù)查詢
• 對(duì)于RTDP架構(gòu)來(lái)說(shuō)，實(shí)時(shí)數(shù)據(jù)源和即席數(shù)據(jù)源的元數(shù)據(jù)信息可以通過(guò)調(diào)用DBus和Moonbox的RESTful服務(wù)歸集，可以基于此建設(shè)企業(yè)級(jí)元數(shù)據(jù)管理系統(tǒng)

2）數(shù)據(jù)質(zhì)量

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

3）血緣分析

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

1.3.2 數(shù)據(jù)安全

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

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

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

1.3.3 開發(fā)運(yùn)維

1）運(yùn)維管理

• 實(shí)時(shí)數(shù)據(jù)處理的運(yùn)維管理向來(lái)是個(gè)痛點(diǎn)，DBus和Wormhole通過(guò)可視化UI提供了可視化運(yùn)維管理能力，讓人工運(yùn)維變得簡(jiǎn)單。
• DBus和Wormhole提供了健康檢查、操作管理、Backfill、Flow漂移等RESTful服務(wù)，可以基于此研發(fā)自動(dòng)化運(yùn)維系統(tǒng)。

2）監(jiān)控預(yù)警

• DBus和Wormhole均提供可視化監(jiān)控界面，可以實(shí)時(shí)看到邏輯表級(jí)的吞吐和延遲等信息。
• DBus和Wormhole提供了心跳、Stats、狀態(tài)等RESTful服務(wù)，可以基于此研發(fā)自動(dòng)化預(yù)警系統(tǒng)。

二、模式場(chǎng)景探討

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

2.1 同步模式

2.1.1 模式描述

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

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

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

2.1.2 技術(shù)難點(diǎn)

具體實(shí)施比較簡(jiǎn)單。

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

2.1.3 運(yùn)維管理

運(yùn)維管理比較簡(jiǎn)單。

需要人工運(yùn)維。但由于流上沒(méi)有處理邏輯，因此容易把控流速，無(wú)需考慮流上處理邏輯本身的功耗，可以給出一個(gè)相對(duì)穩(wěn)定的同步管道配置。并且也很容易做到定時(shí)端到端數(shù)據(jù)比對(duì)來(lái)確保數(shù)據(jù)質(zhì)量，因?yàn)樵炊撕湍繕?biāo)端的數(shù)據(jù)是完全一致的。

2.1.4 適用場(chǎng)景

• 跨部門數(shù)據(jù)實(shí)時(shí)同步共享
• 交易數(shù)據(jù)庫(kù)和分析數(shù)據(jù)庫(kù)解耦
• 支持?jǐn)?shù)倉(cāng)實(shí)時(shí)ODS層建設(shè)
• 用戶自助實(shí)時(shí)簡(jiǎn)單報(bào)表開發(fā)
• 等等

2.2 流算模式

2.2.1 模式描述

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

在RTDP架構(gòu)中，流上處理邏輯的配置和支持主要在Wormhole平臺(tái)上進(jìn)行。在同步模式的能力之上，流算模式主要提供了兩個(gè)能力：

• 流上計(jì)算將批量計(jì)算集中功耗分散在流上增量計(jì)算持續(xù)功耗，極大降低了結(jié)果快照的時(shí)間延遲
• 流上計(jì)算提供了跨異構(gòu)系統(tǒng)混算的新的計(jì)算入口（Lookup）

2.2.2 技術(shù)難點(diǎn)

具體實(shí)施相對(duì)較難。

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

2.2.3 運(yùn)維管理

運(yùn)維管理相對(duì)較難。

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

2.2.4 適用場(chǎng)景

• 對(duì)低延遲要求較高的數(shù)據(jù)應(yīng)用項(xiàng)目或報(bào)表
• 需要低延遲調(diào)用外部服務(wù)（如流上調(diào)用外部規(guī)則引擎、在線算法模型使用等）
• 支持?jǐn)?shù)倉(cāng)實(shí)時(shí)事實(shí)表+維度表的寬表建設(shè)
• 實(shí)時(shí)多表融合、分拆、清洗、標(biāo)準(zhǔn)化Mapping場(chǎng)景
• 等等

2.3 輪轉(zhuǎn)模式

2.3.1 模式描述

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

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

2.3.2 技術(shù)難點(diǎn)

具體實(shí)施難。

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

2.3.3 運(yùn)維管理

運(yùn)維管理難。

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

2.3.4 適用場(chǎng)景

• 低延遲的多步驟的復(fù)雜數(shù)據(jù)處理邏輯場(chǎng)景
• 公司級(jí)實(shí)時(shí)數(shù)據(jù)流轉(zhuǎn)處理網(wǎng)絡(luò)建設(shè)

2.4 智能模式

2.4.1 模式描述

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

可以智能化的點(diǎn)：

• Wormhole Flow的智能漂移（智能化自動(dòng)化運(yùn)維）
• Moonbox預(yù)計(jì)算的智能優(yōu)化（智能化自動(dòng)化調(diào)優(yōu)）
• 全量計(jì)算邏輯智能轉(zhuǎn)換成流式計(jì)算邏輯，然后部署在Wormhole + Moonbox（智能化自動(dòng)化開發(fā)部署）
• 等等

2.4.2 技術(shù)難點(diǎn)

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

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

2.4.3 運(yùn)維管理

零運(yùn)維。

2.4.4 適用場(chǎng)景

全場(chǎng)景。

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

作者：盧山巍

來(lái)源：宜信技術(shù)學(xué)院