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

本文僅為筆者平日學(xué)習(xí)記錄之用隐圾,侵刪
原文:https://mp.weixin.qq.com/s/iyDxv_sLcNEJ1KBG7gGH3w

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

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

在設(shè)計篇中革砸,我們給出了RTDP的一個整體架構(gòu)設(shè)計(圖1)除秀。在技術(shù)篇里,我們則會推薦整體技術(shù)組件選型算利;對每個技術(shù)組件做出簡單介紹册踩,尤其對我們抽象并實現(xiàn)的四個技術(shù)平臺(統(tǒng)一數(shù)據(jù)采集平臺、統(tǒng)一流式處理平臺效拭、統(tǒng)一計算服務(wù)平臺暂吉、統(tǒng)一數(shù)據(jù)可視化平臺)著重介紹設(shè)計思路胖秒;對Pipeline端到端切面話題進行探討,包括功能整合慕的、數(shù)據(jù)管理阎肝、數(shù)據(jù)安全等。

圖1 RTDP架構(gòu)

1.1 整體技術(shù)選型

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

首先肮街,我們簡要解讀一下圖2:

  • 數(shù)據(jù)源风题、客戶端,列舉了大多數(shù)數(shù)據(jù)應(yīng)用項目的常用數(shù)據(jù)源類型嫉父。

  • 數(shù)據(jù)總線平臺DBus俯邓,作為統(tǒng)一數(shù)據(jù)采集平臺,負責(zé)對接各種數(shù)據(jù)源熔号。DBus將數(shù)據(jù)以增量或全量方式抽取出來稽鞭,并進行一些常規(guī)數(shù)據(jù)處理,最后將處理后的消息發(fā)布在Kafka上引镊。

  • 分布式消息系統(tǒng)Kafka朦蕴,以分布式、高可用弟头、高吞吐吩抓、可發(fā)布-訂閱等能力,連接消息的生產(chǎn)者和消費者赴恨。

  • 流式處理平臺Wormhole疹娶,作為統(tǒng)一流式處理平臺,負責(zé)流上處理和對接各種數(shù)據(jù)目標(biāo)存儲伦连。Wormhole從Kafka消費消息雨饺,支持流上配置SQL方式實現(xiàn)流上數(shù)據(jù)處理邏輯,并支持配置化方式將數(shù)據(jù)以最終一致性(冪等)效果落入不同數(shù)據(jù)目標(biāo)存儲(Sink)中惑淳。

  • 在數(shù)據(jù)計算存儲層额港,RTDP架構(gòu)選擇開放技術(shù)組件選型,用戶可以根據(jù)實際數(shù)據(jù)特性歧焦、計算模式移斩、訪問模式、數(shù)據(jù)量等信息選擇合適的存儲绢馍,解決具體數(shù)據(jù)項目問題向瓷。RTDP還支持同時選擇多個不同數(shù)據(jù)存儲,從而更靈活的支持不同項目需求舰涌。

  • 計算服務(wù)平臺Moonbox猖任,作為統(tǒng)一計算服務(wù)平臺,對異構(gòu)數(shù)據(jù)存儲端負責(zé)整合舵稠、計算下推優(yōu)化超升、異構(gòu)數(shù)據(jù)存儲混算等(數(shù)據(jù)虛擬化技術(shù))入宦,對數(shù)據(jù)展示和交互端負責(zé)收口統(tǒng)一元數(shù)據(jù)查詢、統(tǒng)一數(shù)據(jù)計算和下發(fā)室琢、統(tǒng)一數(shù)據(jù)查詢語言(SQL)乾闰、統(tǒng)一數(shù)據(jù)服務(wù)接口等。

  • 可視應(yīng)用平臺Davinci盈滴,作為統(tǒng)一數(shù)據(jù)可視化平臺涯肩,以配置化方式支持各種數(shù)據(jù)可視化和交互需求,并可以整合其他數(shù)據(jù)應(yīng)用以提供數(shù)據(jù)可視化部分需求解決方案巢钓,另外還支持不同數(shù)據(jù)從業(yè)人員在平臺上協(xié)作完成各項日常數(shù)據(jù)應(yīng)用病苗。其他數(shù)據(jù)終端消費系統(tǒng)如數(shù)據(jù)開發(fā)平臺Zeppelin、數(shù)據(jù)算法平臺Jupyter等在本文不做介紹症汹。

  • 切面話題如數(shù)據(jù)管理硫朦、數(shù)據(jù)安全、開發(fā)運維背镇、驅(qū)動引擎咬展,可以通過對接DBus、Wormhole瞒斩、Moonbox破婆、Davinci的服務(wù)接口進行整合和二次開發(fā),以支持端到端管控和治理需求胸囱。

下面我們會進一步細化上圖涉及到的技術(shù)組件和切面話題祷舀,介紹技術(shù)組件的功能特性,著重講解我們自研技術(shù)組件的設(shè)計思想烹笔,并對切面話題展開討論裳扯。

1.2 技術(shù)組件介紹

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

圖3 RTDP架構(gòu)之DBus
1.2.1.1 DBus設(shè)計思想

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

  • 負責(zé)對接不同的數(shù)據(jù)源,實時抽取出增量數(shù)據(jù)箕宙,對于數(shù)據(jù)庫會采用操作日志抽取方式嚎朽,對于日志類型支持與多種Agent對接铺纽。

  • 將所有消息以統(tǒng)一的UMS消息格式發(fā)布在Kafka上柬帕,UMS是一種標(biāo)準化的自帶元數(shù)據(jù)信息的JSON格式,通過統(tǒng)一UMS實現(xiàn)邏輯消息與物理Kafka Topic解耦狡门,使得同一Topic可以流轉(zhuǎn)多個UMS消息表陷寝。

  • 支持數(shù)據(jù)庫的全量數(shù)據(jù)拉取,并且和增量數(shù)據(jù)統(tǒng)一融合成UMS消息其馏,對下游消費透明無感知凤跑。

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

  • 基于Storm計算引擎進行數(shù)據(jù)格式化,確保消息端到端延遲最低叛复。

  • 對不同數(shù)據(jù)源數(shù)據(jù)進行標(biāo)準化格式化仔引,生成UMS信息扔仓,其中包括:

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

? 確認每條消息的事件時間戳(event timestamp)咖耘,對應(yīng)系統(tǒng)字段ums_ts_

? 確認每條消息的操作模式(增刪改翘簇,或insert only),對應(yīng)系統(tǒng)字段ums_op_

  • 對數(shù)據(jù)庫表結(jié)構(gòu)變更實時感知并采用版本號進行管理儿倒,確保下游消費時明確上游元數(shù)據(jù)變化版保。

  • 在投放Kafka時確保消息強有序(非絕對有序)和at least once語義。

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

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ù)細節(jié)和用戶界面彻犁,可以參看:GitHub:https://github.com/BriData

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

Kafka已經(jīng)成為事實標(biāo)準的大數(shù)據(jù)流式處理分布式消息系統(tǒng),當(dāng)然Kafka在不斷的擴展和完善凰慈,現(xiàn)在也具備了一定的存儲能力和流式處理能力汞幢。關(guān)于Kafka本身的功能和技術(shù)已經(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疾宏。這個組件主要負責(zé)管理在Kafka上流轉(zhuǎn)消息的 元數(shù)據(jù)信息和Topic信息,并提供一系列元數(shù)據(jù)管理服務(wù)触创。之所以要引入這樣一個組件坎藐,是為了Kafka的消費方能夠了解不同Topic上流轉(zhuǎn)的是哪些數(shù)據(jù),以及數(shù)據(jù)的元數(shù)據(jù)信息哼绑,并進行有效的解析消費岩馍。

任何數(shù)據(jù)流轉(zhuǎn)鏈路,不管是在什么系統(tǒng)上流轉(zhuǎn)抖韩,都會存在這段數(shù)據(jù)鏈路的元數(shù)據(jù)管理問題蛀恩,Kafka也不例外。Schema Registry是一種中心化的Kafka數(shù)據(jù)鏈路元數(shù)據(jù)管理解決方案茂浮,并且基于Schema Registry双谆,Confluent提供了相應(yīng)的Kafka數(shù)據(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ù)管理和模式演變問題呢?

1.2.2.1 元數(shù)據(jù)管理(Metadata Management)
  • DBus會自動將實時感知的數(shù)據(jù)庫元數(shù)據(jù)變化記錄下來并提供服務(wù)

  • DBus會自動將在線格式化的日志元數(shù)據(jù)信息記錄下來并提供服務(wù)

  • DBus會發(fā)布在Kafka上發(fā)布統(tǒng)一UMS消息幌羞,UMS本身自帶消息元數(shù)據(jù)信息寸谜,因此下游消費時無需調(diào)用中心化元數(shù)據(jù)服務(wù),可以直接從UMS消息里拿到數(shù)據(jù)的元數(shù)據(jù)信息

1.2.2.2 模式演變(Schema Evolution)
  • UMS消息會自帶Schema的Namespace信息属桦,Namespace是一個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]代表了這張表的某個Schema的版本號果善,如果數(shù)據(jù)源是數(shù)據(jù)庫讲逛,那么這個版本號是由DBus自動維護的。

  • 在RTDP架構(gòu)中岭埠,Kafka的下游是由Wormhole消費的盏混,Wormhole在消費UMS時,會將[TableVersion]作為*處理惜论,意味著當(dāng)某表上游Schema變更時许赃,Version會自動升號,但Wormhole會無視這個Version變化馆类,將會消費此表所有版本的增量/全量數(shù)據(jù)混聊,那么Wormhole如何做到兼容性模式演變支持呢?在Wormhole里可以配置流上處理SQL和輸出字段乾巧,當(dāng)上游Schema變更是一種“兼容性變更”(指增加字段句喜,或者修改擴大字段類型等)時,是不會影響到Wormhole SQL正確執(zhí)行的沟于。當(dāng)上游發(fā)生非兼容性變更時咳胃,Wormhole會報錯,這時就需要人工介入對新Schema的邏輯進行修復(fù)旷太。

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

表1 Schema Registry 與 DBus+UMS 對比

這里給出一個UMS的例子:

圖6 UMS消息舉例

1.2.3 流式處理平臺Wormhole

圖7 RTDP架構(gòu)之Wormhole
1.2.3.1 Wormhole設(shè)計思想

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

  • 消費來自Kafka 的UMS消息和自定義JSON消息

  • 負責(zé)對接不同的數(shù)據(jù)目標(biāo)存儲 (Sink),并通過冪等邏輯實現(xiàn)Sink的最終一致性

  • 支持配置SQL方式實現(xiàn)流上處理邏輯

  • 提供Flow抽象睡毒。Flow由一個Source Namespace和一個Sink Namespace定義来惧,且具備唯一性。Flow上可以定義處理邏輯演顾,是一種流上處理的邏輯抽象供搀,通過與物理Spark Streaming、Flink Streaming解耦偶房,使得同一個Stream可以處理多個Flow處理流趁曼,且Flow可以在不同Stream上任意切換。

  • 支持基于回灌(backfill)的Kappa架構(gòu)棕洋;支持基于Wormhole Job的Lambda架構(gòu)

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

  • 基于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)一以支持功能靈活性和設(shè)計一致性

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

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

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

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

? SinkProcessor:擴展更多Sink支持

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

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

  • 通過Feedback消息實時歸集流式作業(yè)動態(tài)指標(biāo)和統(tǒng)計
1.2.3.2 Wormhole功能特性
  • 支持可視化,配置化次绘,SQL化開發(fā)實施流式項目

  • 支持指令式動態(tài)流式處理的管理瘪阁、運維、診斷和監(jiān)控

  • 支持統(tǒng)一結(jié)構(gòu)化UMS消息和自定義半結(jié)構(gòu)化JSON消息

  • 支持處理增刪改三態(tài)事件消息流

  • 支持單個物理流同時并行處理多個邏輯業(yè)務(wù)流

  • 支持流上Lookup Anywhere邮偎,Pushdown Anywhere

  • 支持基于業(yè)務(wù)策略的事件時間戳流式處理

  • 支持UDF的注冊管理和動態(tài)加載

  • 支持多目標(biāo)數(shù)據(jù)系統(tǒng)的并發(fā)冪等入庫

  • 支持多級基于增量消息的數(shù)據(jù)質(zhì)量管理

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

  • 支持Lambda架構(gòu)和Kappa架構(gòu)

  • 支持與三方系統(tǒng)無縫集成管跺,可作為三方系統(tǒng)的流控引擎

  • 支持私有云部署,安全權(quán)限管控和多租戶資源管理

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

更多Wormhole技術(shù)細節(jié)和用戶界面禾进,可以參看:GitHub:https://github.com/edp963/wormhole

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

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

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

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

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

? Kudu:Scan優(yōu)化哑了,適合OLAP分析計算場景

? HBase:隨機讀寫换怖,適合提供數(shù)據(jù)服務(wù)場景

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

? ClickHouse:高性能計算侧纯,適合只有insert寫入場景(后期將支持更新刪除操作)

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

? HDFS/Parquet/Hive:append only勃救,適合海量數(shù)據(jù)批量計算場景

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

? MongoDB:平衡能力碍讨,適合大數(shù)據(jù)量中等復(fù)雜計算

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

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

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

? Druid/Kylin:預(yù)計算能力蒙秒,適合高性能OLAP分析場景

1.2.5 計算服務(wù)平臺Moonbox

圖9 RTDP架構(gòu)之Moonbox
1.2.5.1 Moonbox設(shè)計思想

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

  • 負責(zé)對接不同的數(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)一查詢語言SQL收口;統(tǒng)一權(quán)限控制收口

  • 提供兩種查詢結(jié)果寫出模式:Merge瓢省、Replace

  • 提供兩種交互模式:Batch模式弄息、Adhoc模式

  • 數(shù)據(jù)虛擬化實現(xiàn),多租戶實現(xiàn)勤婚,可看作是虛擬數(shù)據(jù)庫

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

  • 對SQL進行解析摹量,經(jīng)過常規(guī)Catalyst處理解析流程,最終生成可下推數(shù)據(jù)系統(tǒng)的邏輯執(zhí)行子樹進行下推計算,然后將結(jié)果拉回進行混算并返回

  • 支持兩層Namespace:database.table缨称,以提供虛擬數(shù)據(jù)庫體驗

  • 提供分布式服務(wù)模塊Moonbox Grid提供高可用高并發(fā)能力

  • 對可全部下推邏輯(無混算)提供快速執(zhí)行通道

1.2.5.2 Moonbox功能特性
  • 支持跨異構(gòu)系統(tǒng)無縫混算

  • 支持統(tǒng)一SQL語法查詢計算和寫入

  • 支持三種調(diào)用方式:RESTful服務(wù)凝果、JDBC連接、ODBC連接

  • 支持兩種交互模式:Batch模式睦尽、Adhoc模式

  • 支持Cli Command工具和Zeppelin

  • 支持多租戶用戶權(quán)限體系

  • 支持表級權(quán)限器净、列級權(quán)限、讀權(quán)限当凡、寫權(quán)限山害、UDF權(quán)限

  • 支持YARN調(diào)度器資源管理

  • 支持元數(shù)據(jù)服務(wù)

  • 支持定時任務(wù)

  • 支持安全策略

1.2.5.3 Moonbox技術(shù)架構(gòu)
圖10 Moonbox邏輯模塊

更多Moonbox技術(shù)細節(jié)和用戶界面,可以參看:GitHub:https://github.com/edp963/moonbox

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

圖11 RTDP架構(gòu)之Davinci
1.2.6.1 Davinci設(shè)計思想

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

  • 負責(zé)各種數(shù)據(jù)可視化展示功能

  • 支持JDBC數(shù)據(jù)源

  • 提供平權(quán)用戶體系沿量,每個用戶可以建立屬于自己的Org浪慌、Team和Project

  • 支持SQL編寫數(shù)據(jù)處理邏輯,支持拖拽式編輯可視化展示欧瘪,提供多用戶社交化分工協(xié)作環(huán)境

  • 提供多種不同的圖表交互能力和定制化能力眷射,以應(yīng)對不同數(shù)據(jù)可視化需求

  • 提供嵌入整合進其他數(shù)據(jù)應(yīng)用的能力

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

  • 圍繞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)可視組件

  • 支持預(yù)定義圖表

  • 支持控制器組件

  • 支持自由樣式

4)交互能力

  • 支持可視組件全屏顯示

  • 支持可視組件本地控制器

  • 支持可視組件間過濾聯(lián)動

  • 支持群控控制器可視組件

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

  • 支持大數(shù)據(jù)量展示分頁和滑塊

5)集成能力

  • 支持可視組件CSV下載

  • 支持可視組件公共分享

  • 支持可視組件授權(quán)分享

  • 支持儀表板公共分享

  • 支持儀表板授權(quán)分享

6)安全權(quán)限

  • 支持數(shù)據(jù)行列權(quán)限

  • 支持LDAP登錄集成

更多Davinci技術(shù)細節(jié)和用戶界面芥被,可以參看:GitHub:https://github.com/edp963/davinci

1.3 切面話題討論

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

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

  • DBus可以實時拿到數(shù)據(jù)源的元數(shù)據(jù)并提供服務(wù)查詢

  • Moonbox可以實時拿到數(shù)據(jù)系統(tǒng)的元數(shù)據(jù)并提供服務(wù)查詢

  • 對于RTDP架構(gòu)來說欧宜,實時數(shù)據(jù)源和即席數(shù)據(jù)源的元數(shù)據(jù)信息可以通過調(diào)用DBus和Moonbox的RESTful服務(wù)歸集,可以基于此建設(shè)企業(yè)級元數(shù)據(jù)管理系統(tǒng)

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

  • Wormhole可以配置消息實時落入HDFS(hdfslog)拴魄∪呷祝基于hdfslog的Wormhole Job支持Lambda架構(gòu);基于hdfslog的Backfill支持Kappa架構(gòu)匹中∠氖可以通過設(shè)置定時任務(wù)選擇Lambda架構(gòu)或者Kappa架構(gòu)對Sink進行定時刷新,以確保數(shù)據(jù)的最終一致性顶捷。Wormhole還支持將流上處理異彻掖拢或Sink寫入異常的消息信息實時Feedback到Wormhole系統(tǒng)中,并提供RESTful服務(wù)供三方應(yīng)用調(diào)用處理服赎。

  • Moonbox可以對異構(gòu)系統(tǒng)進行即席混算葵蒂,這個能力賦予Moonbox“瑞士軍刀”般的便利性≈芈牵可以通過Moonbox編寫定時SQL腳本邏輯践付,對關(guān)注的異構(gòu)系統(tǒng)數(shù)據(jù)進行比對,或?qū)﹃P(guān)注的數(shù)據(jù)表字段進行統(tǒng)計等缺厉,可以基于Moonbox的能力二次開發(fā)數(shù)據(jù)質(zhì)量檢測系統(tǒng)永高。

3)血緣分析

  • Wormhole的流上處理邏輯通常SQL即可滿足隧土,這些SQL可以通過RESTful服務(wù)進行歸集。

  • Moonbox掌管了數(shù)據(jù)查詢的統(tǒng)一入口乏梁,并且所有邏輯均為SQL次洼,這些SQL可以通過Moonbox日志進行歸集关贵。

  • 對于RTDP架構(gòu)來說遇骑,實時處理邏輯和即席處理邏輯的SQL可以通過調(diào)用Wormhole的RESTful服務(wù)和Moonbox的日志歸集,可以基于此建設(shè)企業(yè)級血緣分析系統(tǒng)揖曾。

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

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

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

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

1.3.3 開發(fā)運維

1)運維管理

  • 實時數(shù)據(jù)處理的運維管理向來是個痛點绿鸣,DBus和Wormhole通過可視化UI提供了可視化運維管理能力,讓人工運維變得簡單暂氯。

  • DBus和Wormhole提供了健康檢查潮模、操作管理、Backfill痴施、Flow漂移等RESTful服務(wù)擎厢,可以基于此研發(fā)自動化運維系統(tǒng)。

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

  • DBus和Wormhole均提供可視化監(jiān)控界面辣吃,可以實時看到邏輯表級的吞吐和延遲等信息动遭。

  • DBus和Wormhole提供了心跳、Stats神得、狀態(tài)等RESTful服務(wù)厘惦,可以基于此研發(fā)自動化預(yù)警系統(tǒng)。

二循头、模式場景探討

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

2.1 同步模式

2.1.1 模式描述

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

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

  • 后續(xù)數(shù)據(jù)處理邏輯不再執(zhí)行在業(yè)務(wù)備庫上,減少了對業(yè)務(wù)備庫的使用壓力

  • 提供了將不同物理業(yè)務(wù)備庫數(shù)據(jù)實時同步到同一物理數(shù)據(jù)存儲的可能性

2.1.2 技術(shù)難點

具體實施比較簡單是越。

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

2.1.3 運維管理

運維管理比較簡單浦徊。

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

2.1.4 適用場景

  • 跨部門數(shù)據(jù)實時同步共享

  • 交易數(shù)據(jù)庫和分析數(shù)據(jù)庫解耦

  • 支持數(shù)倉實時ODS層建設(shè)

  • 用戶自助實時簡單報表開發(fā)

  • 等等

2.2 流算模式

2.2.1 模式描述

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

在RTDP架構(gòu)中硬贯,流上處理邏輯的配置和支持主要在Wormhole平臺上進行焕襟。在同步模式的能力之上,流算模式主要提供了兩個能力:

  • 流上計算將批量計算集中功耗分散在流上增量計算持續(xù)功耗饭豹,極大降低了結(jié)果快照的時間延遲

  • 流上計算提供了跨異構(gòu)系統(tǒng)混算的新的計算入口(Lookup)

2.2.2 技術(shù)難點

具體實施相對較難鸵赖。

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

2.2.3 運維管理

運維管理相對較難翘悉。

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

2.2.4 適用場景

  • 對低延遲要求較高的數(shù)據(jù)應(yīng)用項目或報表

  • 需要低延遲調(diào)用外部服務(wù)(如流上調(diào)用外部規(guī)則引擎抬旺、在線算法模型使用等)

  • 支持數(shù)倉實時事實表+維度表的寬表建設(shè)

  • 實時多表融合、分拆祥楣、清洗开财、標(biāo)準化Mapping場景

  • 等等

2.3 輪轉(zhuǎn)模式

2.3.1 模式描述

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

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

2.3.2 技術(shù)難點

具體實施難宏娄。

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

2.3.3 運維管理

運維管理難卖宠。

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

2.3.4 適用場景

  • 低延遲的多步驟的復(fù)雜數(shù)據(jù)處理邏輯場景

  • 公司級實時數(shù)據(jù)流轉(zhuǎn)處理網(wǎng)絡(luò)建設(shè)

2.4 智能模式

2.4.1 模式描述

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

可以智能化的點:

  • Wormhole Flow的智能漂移(智能化自動化運維)

  • Moonbox預(yù)計算的智能優(yōu)化(智能化自動化調(diào)優(yōu))

  • 全量計算邏輯智能轉(zhuǎn)換成流式計算邏輯吼砂,然后部署在Wormhole + Moonbox(智能化自動化開發(fā)部署)

  • 等等

2.4.2 技術(shù)難點

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

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

2.4.3 運維管理

零運維。

2.4.4 適用場景

全場景蓉坎。

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

作者:盧山巍

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末禀横,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子粥血,更是在濱河造成了極大的恐慌柏锄,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,104評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件复亏,死亡現(xiàn)場離奇詭異趾娃,居然都是意外死亡,警方通過查閱死者的電腦和手機缔御,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,816評論 3 399
  • 文/潘曉璐 我一進店門抬闷,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人耕突,你說我怎么就攤上這事笤成。” “怎么了有勾?”我有些...
    開封第一講書人閱讀 168,697評論 0 360
  • 文/不壞的土叔 我叫張陵疹启,是天一觀的道長。 經(jīng)常有香客問我蔼卡,道長喊崖,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 59,836評論 1 298
  • 正文 為了忘掉前任雇逞,我火速辦了婚禮荤懂,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘塘砸。我一直安慰自己节仿,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 68,851評論 6 397
  • 文/花漫 我一把揭開白布掉蔬。 她就那樣靜靜地躺著廊宪,像睡著了一般矾瘾。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上箭启,一...
    開封第一講書人閱讀 52,441評論 1 310
  • 那天壕翩,我揣著相機與錄音,去河邊找鬼傅寡。 笑死放妈,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的荐操。 我是一名探鬼主播芜抒,決...
    沈念sama閱讀 40,992評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼托启!你這毒婦竟也來了宅倒?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,899評論 0 276
  • 序言:老撾萬榮一對情侶失蹤驾中,失蹤者是張志新(化名)和其女友劉穎唉堪,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體肩民,經(jīng)...
    沈念sama閱讀 46,457評論 1 318
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,529評論 3 341
  • 正文 我和宋清朗相戀三年链方,在試婚紗的時候發(fā)現(xiàn)自己被綠了持痰。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,664評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡祟蚀,死狀恐怖工窍,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情前酿,我是刑警寧澤患雏,帶...
    沈念sama閱讀 36,346評論 5 350
  • 正文 年R本政府宣布,位于F島的核電站罢维,受9級特大地震影響淹仑,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜肺孵,卻給世界環(huán)境...
    茶點故事閱讀 42,025評論 3 334
  • 文/蒙蒙 一匀借、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧平窘,春花似錦吓肋、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,511評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽肤舞。三九已至,卻和暖如春均蜜,著一層夾襖步出監(jiān)牢的瞬間萨赁,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,611評論 1 272
  • 我被黑心中介騙來泰國打工兆龙, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留杖爽,地道東北人。 一個月前我還...
    沈念sama閱讀 49,081評論 3 377
  • 正文 我出身青樓紫皇,卻偏偏與公主長得像慰安,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子聪铺,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,675評論 2 359