導讀：宜信于2017年推出了一系列大數(shù)據(jù)開源工具，包括大家熟悉的DBus、Wormhole、Moonbox、Davinci等，在技術社區(qū)內(nèi)得到了廣泛關注和好評。這些工具是如何在宜信內(nèi)部應用的?它們和宜信數(shù)據(jù)中臺是怎樣的關系?又是如何驅(qū)動各種日常數(shù)據(jù)業(yè)務場景的?

本次分享對這些問題進行了回答，同時重點分享了宜信敏捷數(shù)據(jù)中臺的設計、架構以及應用場景，提出一種敏捷數(shù)據(jù)中臺的建設思路，以供參考和探討。以下是本次分享的實錄。

一、導語

目前“中臺”的概念很火，包括數(shù)據(jù)中臺、AI中臺、業(yè)務中臺、技術中臺等。宜信技術學院第一期技術沙龍，井玉欣博士分享了宜信的AI中臺，本期技術沙龍，由我來為大家分享《宜信敏捷數(shù)據(jù)中臺建設實踐》。

為什么我們要在數(shù)據(jù)中臺前加上“敏捷”呢?了解我們的朋友都知道我所在的團隊是宜信敏捷大數(shù)據(jù)團隊，我們倡導“敏捷平民化”，把敏捷思想融入到系統(tǒng)建設中，并且研發(fā)了四個開源平臺：DBus、Wormhole、Moonbox、Davinci。宜信的數(shù)據(jù)中臺是由我們敏捷大數(shù)據(jù)團隊基于四大開源平臺開發(fā)建設的，因此我們將宜信的數(shù)據(jù)中臺稱之為“敏捷數(shù)據(jù)中臺”。

本次分享分為三個部分：

• 宜信敏捷數(shù)據(jù)中臺的頂層設計。數(shù)據(jù)中臺是一個公司級的平臺系統(tǒng)，所以不能只從技術層面去設計，還要考慮包括流程、標準化等在內(nèi)的頂層設計。
• 從中間件工具到平臺介紹宜信是如何設計建設敏捷數(shù)據(jù)中臺的。
• 結合典型案例介紹宜信敏捷數(shù)據(jù)中臺支持哪些數(shù)據(jù)方面的應用和實踐。

二、宜信數(shù)據(jù)中臺頂層設計

1. 特點和需求

關于數(shù)據(jù)中臺的建設，目前并沒有一個標準的解決方案，也沒有一個數(shù)據(jù)中臺能適用于所有的公司，每個公司都應該結合自己的業(yè)務規(guī)模及數(shù)據(jù)需求現(xiàn)狀來研發(fā)適合自己公司的數(shù)據(jù)中臺。

在介紹宜信敏捷數(shù)據(jù)中臺的頂層設計之前，我們先來了解其背景：

• 業(yè)務板塊和業(yè)務條線眾多。宜信的業(yè)務大體可分為四大板塊：普惠金融板塊、財富管理板塊、資產(chǎn)管理板塊、金融科技板塊，擁有近百條業(yè)務線和產(chǎn)品線。
• 技術選型眾多。不同業(yè)務方有不同的數(shù)據(jù)需求，技術選型時依據(jù)這些客觀需求及主觀偏好，會選擇不同的數(shù)據(jù)組件，包括 ：MySQL、Oracle、HBase、KUDU、Cassandra、Elasticsearch、MongoDB、Hive、Spark、Presto、Impala、Clickhouse等。
• 數(shù)據(jù)需求多樣。業(yè)務線多樣，導致數(shù)據(jù)需求多樣，包括：報表、可視化、服務、推送、遷移、同步、數(shù)據(jù)應用等。
• 數(shù)據(jù)需求多變。為順應互聯(lián)網(wǎng)的快速變化，業(yè)務方的數(shù)據(jù)需求也是多變的，經(jīng)常有周級產(chǎn)出數(shù)據(jù)需求和數(shù)據(jù)應用。
• 數(shù)據(jù)管理考慮。要求數(shù)據(jù)元信息可查，數(shù)據(jù)定義和流程標準化，數(shù)據(jù)管理可控等。
• 數(shù)據(jù)安全考慮。宜信作為一家同時擁有互聯(lián)網(wǎng)屬性和金融屬性的公司，對數(shù)據(jù)安全和權限的要求很高，我們在數(shù)據(jù)安全方面做了很多工作，包括：多級數(shù)據(jù)安全策略、數(shù)據(jù)鏈路可追溯、敏感數(shù)據(jù)不可泄露等。
• 數(shù)據(jù)權限考慮。在數(shù)據(jù)權限方面的工作包括：表級、列級、行級數(shù)據(jù)權限，組織架構、角色、權限策略自動化。
• 數(shù)據(jù)成本考慮。包括集群成本、運維成本、人力成本、時間成本、風險成本等。

2. 定位

關于數(shù)據(jù)中臺的定位，每個公司都不太一樣。有的公司業(yè)務比較專注，只有一條業(yè)務線，那它在建設數(shù)據(jù)中臺的時候，可能需要一個垂直的平臺，直達前線，更好地支持前線的運作。

前文提到宜信業(yè)務線很多，且在眾多業(yè)務中沒有一個主體業(yè)務，這就相當于所有業(yè)務線都是主體?；谶@樣的背景，我們需要一個平臺化的數(shù)據(jù)中臺，來支撐所有業(yè)務線的需求和運作。

圖1 定位

如上圖所示，綠色的部分是宜信敏捷數(shù)據(jù)中臺，我們稱之為“ADX數(shù)據(jù)中臺平臺”，“A”即“Agile(敏捷)”，之所以稱為“平臺”，是因為我們希望將其打造成一個服務于全業(yè)務線的平臺系統(tǒng)，助力業(yè)務發(fā)展。

敏捷數(shù)據(jù)中臺處于中間位置，最底下是各種數(shù)據(jù)集群，最上端是各個業(yè)務領域數(shù)據(jù)團隊。數(shù)據(jù)中臺通過整合處理數(shù)據(jù)集群的數(shù)據(jù)，為業(yè)務領域數(shù)據(jù)團隊提供自助化、實時化、統(tǒng)一化、服務化、管理化、可溯化的數(shù)據(jù)服務。

右邊三個藍色的板塊分別是數(shù)據(jù)管理委員會、數(shù)據(jù)運維團隊和數(shù)據(jù)安全團隊。前文提到宜信對數(shù)據(jù)安全的要求非常高，所以設置了專門的數(shù)據(jù)安全團隊來規(guī)劃公司數(shù)據(jù)安全的流程和策略;數(shù)據(jù)管理委員會負責數(shù)據(jù)的標準化、流程化，補齊技術型驅(qū)動的數(shù)據(jù)中臺的推動效率，保證有效沉淀和呈現(xiàn)數(shù)據(jù)資產(chǎn)。

我們對宜信敏捷數(shù)據(jù)中臺的定位是：從數(shù)據(jù)技術和計算能力復用，到數(shù)據(jù)資產(chǎn)和數(shù)據(jù)服務復用，敏捷數(shù)據(jù)中臺會以更大價值帶寬，快、準、精讓數(shù)據(jù)直接賦能業(yè)務。

3.  價值

宜信敏捷數(shù)據(jù)中臺的價值集中表現(xiàn)為三個方面：快、準、省。

圖2 價值

4.  模塊架構維度

圖3 模塊架構維度

如圖所示，宜信敏捷數(shù)據(jù)中臺的建設也是基于“小前臺，大中臺”的共識。整個中間部分都屬于敏捷數(shù)據(jù)中臺包含的內(nèi)容，左邊綠色部分是基于數(shù)據(jù)維度來看整個中臺，右邊藍色部分則是基于平臺維度來看中臺。

• 數(shù)據(jù)維度。各種內(nèi)部數(shù)據(jù)、外部數(shù)據(jù)先歸集到數(shù)據(jù)源層，再以統(tǒng)一化、實時化、標準化、安全化等方式存儲起來形成數(shù)據(jù)湖層，數(shù)據(jù)湖對這些原始數(shù)據(jù)進行處理和體系化歸類，轉(zhuǎn)化為數(shù)據(jù)資產(chǎn);數(shù)據(jù)資產(chǎn)層包括數(shù)倉體系、指標體系、標簽體系、特征體系、主數(shù)據(jù)等;最后將沉淀的這些可復用的數(shù)據(jù)資產(chǎn)提供給數(shù)據(jù)應用層，供BI、AI、數(shù)據(jù)產(chǎn)品應用。
• 平臺維度。每個藍色的方框都代表一個技術模塊，整個宜信敏捷數(shù)據(jù)中臺就是由這些技術模塊組合而成。其中DataHub數(shù)據(jù)樞紐，可以幫助用戶完成自助數(shù)據(jù)申請、發(fā)布、脫敏、清洗和服務等;DataWorks數(shù)據(jù)工坊，可以對數(shù)據(jù)進行自助查詢、作業(yè)、可視化等處理;還有DataStar數(shù)據(jù)模型、DataTag數(shù)據(jù)標簽、DataMgt 數(shù)據(jù)管理、ADXMgt 中臺管理等。

值得一提的是，這些模塊都不是從0開發(fā)的，而是基于我們已有的開源工具。首先，基于成熟的中間件工具來進行開發(fā)，可以節(jié)約開發(fā)的時間和成本;其次，開源工具成為引擎，可以共同合力支撐更大的一站式平臺。

5.  數(shù)據(jù)能力維度

圖4 數(shù)據(jù)能力維度

將上述架構模塊重新按照能力維度劃分，可以分成若干層，每一層都包含若干能力。如圖所示，可以清晰地看到建設數(shù)據(jù)中臺需要具備哪些數(shù)據(jù)能力，這些能力都對應哪些功能模塊，分別能解決什么問題。此處不再展開贅述。

三、從中間件工具到平臺

1.  ABD總覽

圖5 ABD總覽

中間件工具指DBus、Wormhole、Moonbox、Davinci四大開源平臺，它們從敏捷大數(shù)據(jù)(ABD，Agile BigData)理念中抽象而出，組成ABD平臺棧，敏捷數(shù)據(jù)中臺則被我們稱為ADX(Agile Data X Platform)。也就是說我們經(jīng)歷了從ABD到ADX的過程。

一開始，基于對業(yè)務需求共性的抽象和總結，我們孵化出若干個通用的中間件，去解決各種各樣的問題。當出現(xiàn)更為復雜的需求，我們嘗試將這些通用的中間件進行組合運用。實踐中，我們發(fā)現(xiàn)經(jīng)常會使用到某些特定的組合，同時，從用戶角度來看，他們更希望能實現(xiàn)自助化，直接拿過來就能用，而不是每次都要自己去選擇和組合?；谶@兩點，我們對這幾個開源工具進行了封裝。

(1) ABD-DBus

DBus(數(shù)據(jù)總線平臺)，是一個DBaaS(Data Bus as a Service)平臺解決方案。

DBus面向大數(shù)據(jù)項目開發(fā)和管理運維人員，致力于提供數(shù)據(jù)實時采集和分發(fā)解決方案。平臺采用高可用流式計算框架，提供海量數(shù)據(jù)實時傳輸，可靠多路消息訂閱分發(fā)，通過簡單靈活的配置，無侵入接入源端數(shù)據(jù)，對各個IT系統(tǒng)在業(yè)務流程中產(chǎn)生的數(shù)據(jù)進行匯集，并統(tǒng)一處理轉(zhuǎn)換成通過JSON描述的UMS格式，提供給不同下游客戶訂閱和消費。DBus可充當數(shù)倉平臺、大數(shù)據(jù)分析平臺、實時報表和實時營銷等業(yè)務的數(shù)據(jù)源。

開源地址：https://github.com/BriData

圖6 DBus功能及定位

如圖所示，DBus可以無侵入地對接各種數(shù)據(jù)庫的數(shù)據(jù)源，實時抽取增量數(shù)據(jù)，做統(tǒng)一清洗和處理，并以UMS的格式存儲到Kafka中。

DBus的功能還包括批量抽取、監(jiān)控、分發(fā)、多租戶，以及配置清晰規(guī)則等，具體功能特性如圖所示。

上圖右下角展示的是DBus的一個截圖，用戶在DBus上可以通過一個可視化頁面，拉取增量數(shù)據(jù)，配置日志和清洗方式，完成實時數(shù)據(jù)抽取等工作。

圖7 DBus架構

從如上架構圖可以看到DBus包括若干不同的處理模塊，支持不同的功能。(GitHub有具體介紹，此處不作展開。)

(2) ABD-Wormhole

Wormhole(流式處理平臺)，是一個SPaaS(Stream Processing as a Service)平臺解決方案。

Wormhole面向大數(shù)據(jù)項目開發(fā)和管理運維人員，致力于提供數(shù)據(jù)流式化處理解決方案。平臺專注于簡化和統(tǒng)一開發(fā)管理流程，提供可視化的操作界面，基于配置和SQL的業(yè)務開發(fā)方式，屏蔽底層技術實現(xiàn)細節(jié)，極大的降低了開發(fā)門檻，使得大數(shù)據(jù)流式處理項目的開發(fā)和管理變得更加輕量敏捷、可控可靠。

開源地址： https://github.com/edp963/wormhole

圖8 Wormhole功能及定位

DBus將實時數(shù)據(jù)以UMS的格式存儲到Kafka中，我們要使用這些實時的流式數(shù)據(jù)，就要用到Wormhole這個工具。

Wormhole支持配置流式化的處理邏輯，同時可以把處理完之后的數(shù)據(jù)寫到不同的數(shù)據(jù)存儲中。上圖中展示了很多Wormhole的功能特性，我們還在開發(fā)更多新的功能。

上圖右下角是Wormhole的一個工作截圖，Wormhole作為流式平臺，自己不重新開發(fā)流式處理引擎，它主要依賴Spark Streaming 和Flink Streaming 這兩種流式計算引擎。用戶可以選擇其中一個流式計算引擎，比如Spark，配置流式處理邏輯，確定Lookup庫的方式，并通過寫SQL來表達這個邏輯。如果涉及CEP，當然就是基于Flink。

由此可以看出，使用Wormhole的門檻就是配置加上SQL。這也符合我們一直秉承的理念，即用敏捷化的方式支持用戶自助玩轉(zhuǎn)大數(shù)據(jù)。

圖9 Wormhole架構

上圖展示的是Wormhole的架構圖，包含很多功能模塊。介紹其中的幾個功能：

• Wormhole支持異構 Sink冪等，能幫助用戶解決數(shù)據(jù)一致性的問題。
• 用過 Spark Streaming的人都知道，發(fā)起一個 Spark Streaming可能只做一件事情。Wormhole在 Spark Streaming的物理計算管道中抽象出一層“邏輯的Flow”的概念，就是從什么地方到什么地方、中間做什么事，這是一個“邏輯的Flow”。做了這種解耦和抽象之后，Wormhole支持在一個物理的 Spark Streaming管道中同時跑多個不同業(yè)務邏輯的Flow。所以理論上講，比如有1000個不同的 Source表，經(jīng)過1000個不同的流式處理，最后要得出1000個不同的結果表，可以只在Wormhole中發(fā)起一個Spark Streaming ，在里面跑1000個邏輯的Flow來實現(xiàn)。當然這樣做的話可能會導致每個Flow延遲加大，因為都擠在同一個管道里，但這里的設置是很靈活的，我可以讓某一個Flow獨占一個VIP的 Stream，如果有些Flow流量很小，或者延遲對其影響不那么大的話，可以讓它們共享一個Stream。靈活性是Wormhole一個很大的特點。
• Wormhole有自己的一套指令和反饋體系，用戶不用重啟或停止流，就可以動態(tài)地在線更改邏輯，并且實時拿到作業(yè)和反饋結果等。

(3) ABD-Moonbox

Moonbox(計算服務平臺)，是一個DVtaaS(Data Virtualization as a Service)平臺解決方案。

Moonbox面向數(shù)據(jù)倉庫工程師/數(shù)據(jù)分析師/數(shù)據(jù)科學家等， 基于數(shù)據(jù)虛擬化設計思想，致力于提供批量計算服務解決方案。Moonbox負責屏蔽底層數(shù)據(jù)源的物理和使用細節(jié)，為用戶帶來虛擬數(shù)據(jù)庫般使用體驗，用戶只需通過統(tǒng)一SQL語言，即可透明實現(xiàn)跨異構數(shù)據(jù)系統(tǒng)混算和寫出。此外Moonbox還提供數(shù)據(jù)服務、數(shù)據(jù)管理、數(shù)據(jù)工具、數(shù)據(jù)開發(fā)等基礎支持，可支撐更加敏捷和靈活的數(shù)據(jù)應用架構和邏輯數(shù)倉實踐。

開源地址： https://github.com/edp963/moonbox

圖10 Moonbox功能及定位

數(shù)據(jù)從DBus過來，經(jīng)過Wormhole的流式處理，可能落到不同的數(shù)據(jù)存儲中，我們需要對這些數(shù)據(jù)進行混算，Moonbox支持多源異構系統(tǒng)無縫混算。上圖展示了Moonbox的功能特性。

平時所說的即席查詢并沒有真正做到“即席”，因為需要用戶先手工地把數(shù)據(jù)導到Hive再做計算，這是一個預置的工作。Moonbox不需要事先把數(shù)據(jù)導到一個地方去，做到了真正的即席查詢。數(shù)據(jù)可以散落到不同的存儲中，當用戶有需求時， 只需寫一個SQL，Moonbox可以自動拆分這個SQL，從而得知哪些表在哪里，然后規(guī)劃SQL的執(zhí)行計劃，最終拿到結果。

Moonbox對外提供標準的REST、API、JDBC、ODBC等，因此也可以將之看成一個虛擬數(shù)據(jù)庫。

圖11 Moonbox架構

上圖展示的是Moonbox的架構圖?？梢钥吹組oonbox的計算引擎部分也是基于Spark引擎做的，并沒有自研。Moonbox對Spark進行擴展和優(yōu)化，增加了很多企業(yè)級的數(shù)據(jù)庫能力，比如用戶、租戶、權限、 類存儲過程等。

從上圖看，Moonbox整個服務端是一個分布式的架構，所以它也是高可用的。

(4) ABD-Davinci

Davinci(可視應用平臺)，是一個DVaaS(Data Visualization as a Service)平臺解決方案。

Davinci面向業(yè)務人員/數(shù)據(jù)工程師/數(shù)據(jù)分析師/數(shù)據(jù)科學家，致力于提供一站式數(shù)據(jù)可視化解決方案。既可作為公有云/私有云獨立部署使用，也可作為可視化插件集成到三方系統(tǒng)。用戶只需在可視化UI上簡單配置即可服務多種數(shù)據(jù)可視化應用，并支持高級交互/行業(yè)分析/模式探索/社交智能等可視化功能。

開源地址：https://github.com/edp963/davinci

圖12 Davinci功能及定位

Davinci是一個可視化工具，所具備的功能特性如圖所示。

圖13 Davinci架構

從設計層面來看，Davinci有自己的完備和一致性的內(nèi)在邏輯。包括Source、View、Widget，支持各種數(shù)據(jù)可視化應用。

圖14 Davinci富客戶端應用

Davinci是一個富客戶端的應用，所以主要還是看它前端的使用體驗、豐富性和易用性等。Davinci支持圖表驅(qū)動和透視驅(qū)動兩種模式編輯Widget。上圖是一個透視驅(qū)動的效果樣例，可以看到橫縱坐標都是透視的，它們會將整個圖切成不同的單元格，每個單元格里可以選擇不同的圖。

2.  ABD架構

圖15 ABD架構

在ABD時代，我們通過DIY組合四個開源工具來支持各種各樣的數(shù)據(jù)應用需求。如上圖所示，將整個端到端的流程串起來，這個架構圖展示了我們“有收有放把整個鏈路打通”的理念。

收。比如采集、架構、流轉(zhuǎn)、注入、計算服務查詢等功能，需要收斂集合成一個平臺。

放。面對復雜的業(yè)務環(huán)境，數(shù)據(jù)源也是各種各樣的無法統(tǒng)一，很難有一個存儲或數(shù)據(jù)系統(tǒng)可以滿足所有的需求，使得大家不再需要選型。因此這一塊的實踐是開放的，大家可以自主選擇開源工具和組件來適配和兼容。

3. ADX總覽

發(fā)展到一定階段時，我們需要一個一站式的平臺，把基礎組件封裝起來，使得用戶可以在這個平臺上更簡單地完成數(shù)據(jù)相關的工作，于是進入了ADX數(shù)據(jù)中臺建設階段。

圖16 ADX 總覽

上圖是ADX 總覽，相當于一個一級功能菜單。用戶登錄到平臺，可以做以下事情：

• 項目看板：可以看到所在項目的看板，包括健康情況等各方面的統(tǒng)計情況。
• 項目管理：可以做項目相關的管理，包括資產(chǎn)管理、權限管理、審批管理等。
• 數(shù)據(jù)管理：可以做數(shù)據(jù)方面的管理，比如查看元數(shù)據(jù)，查看數(shù)據(jù)血緣等。
• 數(shù)據(jù)申請：項目配置好了，數(shù)據(jù)也了解了，可以做實際工作了?；诎踩蜋嘞蘅紤]，并不是誰都可以去用放在里面的數(shù)據(jù)，因此首先要做數(shù)據(jù)申請。右邊藍色模塊是本次分享將重點介紹的ADX數(shù)據(jù)中臺的五大功能模塊。數(shù)據(jù)申請更多是由DataHub數(shù)據(jù)樞紐來實現(xiàn)的，它支持自助申請、發(fā)布、標準化、清洗、脫敏等。
• 即席查詢、批量作業(yè)、流式作業(yè)是基于DataWorks數(shù)據(jù)工坊實現(xiàn)的。
• 數(shù)據(jù)模型是基于DataStar這個模型管理平臺來實現(xiàn)的。
• 應用市場，包括數(shù)據(jù)可視化(數(shù)據(jù)加工完之后可以配置最終展現(xiàn)樣式為圖或儀表板等，這里可能用到Davinci);標簽畫像、行為分析等常見分析方法;智能工具箱(幫助數(shù)據(jù)科學家更好地做數(shù)據(jù)集分析、挖掘和算法模型的工作)以及智能服務、智能對話(比如智能聊天機器人)等。

(1) ADX-DataHub數(shù)據(jù)樞紐

圖17 DataHub工作流程

上圖藍色虛線框顯示的是 DataHub的流程架構，橙色方塊是我們的開源工具，其中“tria”代表Triangle，是宜信另一個團隊研發(fā)的作業(yè)調(diào)度工具。 DataHub不是簡單地封裝了鏈路，而是使得用戶可以在一個更高的level上得到更好的服務。比如用戶需要某一歷史時刻精確到秒的快照，或者希望拿到一個實時增量數(shù)據(jù)去做流式處理，DataHub都可以提供。

它是怎么做到的呢?通過將開源工具引擎化，然后進行整合。舉個例子：不同數(shù)據(jù)源，通過DBus實時抽取出來，經(jīng)過Wormhole流式處理后落到 HDFS Log數(shù)據(jù)湖中，我們把所有實時增量數(shù)據(jù)都存儲在這里面，這就意味著我們可以從中拿到所有的歷史變更數(shù)據(jù)，而且這些數(shù)據(jù)還是實時同步的。再通過Moonbox在上面定義一些邏輯，當用戶提出想要某一歷史時刻的快照或者增量數(shù)據(jù)，就可以即時計算并提供。如果想做實時報表，需要把數(shù)據(jù)實時快照維護到一個存儲里，這里我們選擇Kudu。

流式處理有很多好處，同時也有短板，比如運維成本較高、穩(wěn)定性較差等。考慮到這些問題，我們在DataHub中設置了Sqoop作為Plan B。如果實時這條線晚上出現(xiàn)問題，可以自動切換到Plan B，通過傳統(tǒng)的Sqoop去支持第二天T+1的報表。等我們找到并解決問題之后，Plan B就會切換到暫停狀態(tài)。

假設用戶自己有數(shù)據(jù)源，放在Elasticsearch 或者Mongo里，也希望通過DataHub發(fā)布出去共享給其他人使用。我們不應該把Elasticsearch 數(shù)據(jù)或Mongo數(shù)據(jù)物理地拷貝到一個地方，因為首先這些數(shù)據(jù)是NoSQL的，數(shù)據(jù)量比較大;其次用戶可能希望別人通過模糊查詢的方式去使用Elasticsearch 數(shù)據(jù)，那可能繼續(xù)將數(shù)據(jù)放在Elasticsearch 里更好。這時我們做的是通過Moonbox進行一個邏輯的發(fā)布，但用戶不感知這個過程。

綜上可以看出，DataHub是在內(nèi)部把幾個開源平臺常用的模式進行有機整合和封裝，對外提供一致性、便捷的數(shù)據(jù)獲取、發(fā)布等服務。其使用方也可以是各種不同的角色：

• 數(shù)據(jù)擁有方可以在這里做數(shù)據(jù)審批;
• 數(shù)據(jù)工程師可以申請數(shù)據(jù)，申請完后可以在這里對數(shù)據(jù)進行加工;
• APP用戶可以查看Davinci報表;
• 數(shù)據(jù)分析師可以直接用自己的工具去接DataHub出來的數(shù)據(jù)，然后做數(shù)據(jù)分析;
• 數(shù)據(jù)用戶可能希望自己做一個數(shù)據(jù)產(chǎn)品，DataHub可以為他提供接口。

圖18 DataHub架構

如圖，將DataHub打開，來看其架構設計。從功能模塊角度來看，DataHub基于不同開源組件，實現(xiàn)不同功能。包括批量采集、流式采集、脫敏、標準化等，還可以基于不同的協(xié)議輸出訂閱。

DataHub與其他幾個組件之間的關系也是非常緊密的。它輸出的數(shù)據(jù)給DataWorks使用，同時它又依賴中臺管理、數(shù)據(jù)管理來滿足其需求。

(2) ADX-DataLake實時數(shù)據(jù)湖

廣義的數(shù)據(jù)湖，就是把所有數(shù)據(jù)都放在一起，先以存儲和歸集為主，使用的時候再根據(jù)不同數(shù)據(jù)提供不同使用方式。

我們這里提到的是一個狹義的數(shù)據(jù)湖，只支持結構化數(shù)據(jù)源和自然語言文本這兩種類型的數(shù)據(jù)歸集，并且有統(tǒng)一的方式存儲。

圖19 DataLake

也就是說我們的實時數(shù)據(jù)湖加了限制，公司所有結構化數(shù)據(jù)源和自然語言文本會統(tǒng)一實時匯總為UbiLog，并由ADX-DataHub統(tǒng)一對外提供訪問。UbiLog的訪問和使用只能通過ADX提供的能力輸出，因此確保了多租戶、安全、權限管控。

(3) ADX-DataWorks數(shù)據(jù)工坊

主要的數(shù)據(jù)加工都是在DataWorks自助完成的。

圖20 DataWorks工作流程

如圖來看DataWorks的工作流程。首先DataHub數(shù)據(jù)出來之后，DataWorks必須去接DataHub的數(shù)據(jù)。DataWorks支持實時報表，我們內(nèi)部使用的是Kudu，所以把這個模式固化下來，用戶就不用自己去選型，直接在上面寫自己的邏輯就可以了。比如有一個實時DM或批量DM，我們覺得這是一個很好的數(shù)據(jù)資產(chǎn)，有復用價值，希望別的業(yè)務能復用這個數(shù)據(jù)，我們就可以通過DataHub把它發(fā)布出去，別的業(yè)務就可以申請使用。

所以DataHub和DataWorks等組件封裝而成的數(shù)據(jù)中臺可以達到數(shù)據(jù)共享和數(shù)據(jù)運營的效果。中臺內(nèi)部包含Kudu、Kafka、Hive、MySQL等數(shù)據(jù)庫組件，但是用戶不需要自己去選型，我們已經(jīng)做出了最佳選擇，并將其封裝成一個可直接使用的平臺。

上圖左側有一個數(shù)據(jù)建模師的角色，他在DataStar中做模型管理和開發(fā)建設，在DataWorks中主要是負責邏輯和模型的創(chuàng)建;數(shù)據(jù)工程師不用多說，是最常見的使用DataWorks的角色；終端用戶可以直接使用Davinci。

圖21 DataWorks架構

如圖，將DataWorks打開來看它的架構，同樣DataWorks也是通過不同的模塊來支持各種不同的功能。關于這部分內(nèi)容以后會有更多的文章和分享，此處不詳細介紹。

(4) ADX-DataStar數(shù)據(jù)模型

圖22 DataStar工作流程

DataStar跟數(shù)據(jù)指標模型或數(shù)據(jù)資產(chǎn)相關，每個公司都有自己內(nèi)部的數(shù)據(jù)建模流程和工具。DataStar可以分為兩個部分：

• 模型設計、管理創(chuàng)建。對模型生命周期的管理和工藝流程的沉淀。
• 從DW(數(shù)倉)層到DM(數(shù)據(jù)集市)層，支持配置化的方式，自動在底下生成對應SQL邏輯，而不需要用戶自己去寫。

DataStar是DW層的事實和維度表組成的星型模型，可以最后沉淀下來。但我們認為，從DW層到DM層或APP層，不需要寫SQL開發(fā)了，只需要通過選維度和配置指標的方式，就可以自動可視化配置出來。

這樣的話對使用人的要求就發(fā)生了改變，需要一個建模師或者業(yè)務人員來做這個事情，給他一個基礎數(shù)據(jù)層，他根據(jù)自己的需求來配置想要的指標。整個過程，數(shù)據(jù)實施人員只需要關注ODS層到DW層就可以了。

(5) ADXMgt/DataMgt中臺管理/數(shù)據(jù)管理

圖23 ADXMgt/DataMgt

中臺管理模塊主要關注租戶管理、項目管理、資源管理、權限管理、審批管理等。數(shù)據(jù)管理模塊主要關注數(shù)據(jù)管理層或數(shù)據(jù)治理層的話題。這兩個模塊從不同的維度對中間的三個主要組件提供支持和產(chǎn)生規(guī)則制約。

4.  ADX架構

圖24 ADX架構

ADX數(shù)據(jù)中臺平臺幾個模塊之間的關聯(lián)如圖所示。最底下是五個開源工具，每個模塊都是對這五個開源工具的有機整合和封裝。從圖中可以看出各組件之間的關聯(lián)非常緊密，其中黑色虛線代表的是依賴關系，綠色線條代表的是數(shù)據(jù)流轉(zhuǎn)的關系。

四、典型案例分析

如上所述，我們基于幾個開源工具進行有機整合和封裝，打造了一個更加現(xiàn)代化、自助化、完備的一站式數(shù)據(jù)中臺平臺。那這個平臺是如何發(fā)揮其作用，為業(yè)務提供服務的呢?本節(jié)將列舉五個典型案例。

1. 案例1 — 自助實時報表

【場景】

業(yè)務領域組數(shù)據(jù)團隊需要緊急制作一批報表，不希望排期，希望可以自助完成，并且部分報表需要T+0時效性。

【挑戰(zhàn)】

• 業(yè)務組數(shù)據(jù)團隊工程能力有限，只會簡單SQL，之前要么轉(zhuǎn)給BI排期，要么通過工具直連業(yè)務備庫制作報表，要么通過Excel制作。
• 數(shù)據(jù)來源可能來自異構數(shù)據(jù)庫，沒有很好的平臺支持自助導數(shù)。
• 對數(shù)據(jù)時效性要求很高，需要流上做數(shù)據(jù)處理邏輯。

【方案】

圖25 自助實時報表工作流程

用ADX數(shù)據(jù)中臺解決自助實時報表的問題。

• 數(shù)據(jù)工程師登錄平臺，創(chuàng)建新的項目，申請數(shù)據(jù)資源。
• 數(shù)據(jù)工程師通過元數(shù)據(jù)查找選出表，選擇DataWorks方式使用，填寫其他信息，申請這些需要用到的表。比如我需要用到100張表，其中70張是通過T+1的方式使用，30張是通過實時方式使用。
• 默認中臺會做標準化脫敏加密策略，收到這些申請之后，中臺管理員會按策略依次進行審批。
• 審批通過后，中臺會自動準備和輸出所申請的數(shù)據(jù)資源，數(shù)據(jù)工程師可以運用拿到的數(shù)據(jù)資源進行自助查詢、開發(fā)、配置、SQL編排、批量或流式處理、配置DV等。
• 最后將自助報表或儀表板提交給用戶使用。

【總結】

• 各個角色通過一站式數(shù)據(jù)中臺交互，統(tǒng)一流程，所有動作都記錄在案，可查詢。
• 平臺全自助能力，大大提高了業(yè)務數(shù)字化驅(qū)動進程，無需排期等待，經(jīng)過短暫培訓，人均 3-5日可以自助完成一張實時報表，實時報表不再求人。
• 平臺支持人員也無需過多參與，不再成為進度瓶頸。
• 【能力】

這個場景需要用到很多數(shù)據(jù)能力，包括：即席查詢能力、批量處理能力、實時處理能力、報表看板能力、數(shù)據(jù)權限能力、數(shù)據(jù)安全能力、數(shù)據(jù)管理能力、租戶管理能力、項目管理能力、作業(yè)管理能力、資源管理能力。

2.  案例2 — 協(xié)作模型指標

【場景】

業(yè)務線需要打造自己的基礎數(shù)據(jù)集市，以共享給其他業(yè)務或者前線系統(tǒng)使用。

【挑戰(zhàn)】

• 如何有效建設數(shù)據(jù)模型和管理數(shù)據(jù)模型。
• 如何既支持自己領域內(nèi)數(shù)據(jù)模型建設，同時也支持數(shù)據(jù)模型的共享。
• 數(shù)據(jù)的共享發(fā)布如何從流程上固化、并實現(xiàn)技術安全統(tǒng)一管控。
• 如何運營數(shù)據(jù)以確保有效數(shù)據(jù)資產(chǎn)沉淀和管理。

【方案】

圖26 協(xié)作模型指標工作流程

用ADX數(shù)據(jù)中臺解決協(xié)作模型指標的問題。

• 數(shù)據(jù)建模師登錄平臺，創(chuàng)建新項目，申請資源。然后查找選出表，設計一個或若干個維度表的DW模型，推送到DataWorks項目。
• 數(shù)據(jù)工程師選擇需要的Source表，基于DataStar項目完成從ODS到DW之前的ETL 開發(fā)，然后提交作業(yè)，發(fā)布到DataHub跑起來。
• 數(shù)據(jù)建模師持續(xù)可視化配置維護和管理DW/APP層指標集，包括維度的聚合、計算等。

【總結】

• 這是一個典型的數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)資產(chǎn)運營的案例，通過統(tǒng)一的協(xié)作化的模型指標管理，確保了模型可維護、指標可配置、質(zhì)量可追溯。
• DataStar也支持一致性維度共享、數(shù)據(jù)詞典標準化、業(yè)務線梳理等，可以進一步柔性支持公司統(tǒng)一數(shù)據(jù)基礎層的建設和沉淀。

【能力】 本案例需要的能力包括：數(shù)據(jù)服務能力、即席查詢能力、批量處理能力、數(shù)據(jù)權限能力、數(shù)據(jù)安全能力、數(shù)據(jù)管理能力、數(shù)據(jù)資產(chǎn)能力、租戶管理能力、項目管理能力、作業(yè)管理能力、資源管理能力。

3.  案例3 — 敏捷分析挖掘

【場景】

業(yè)務領域組數(shù)據(jù)分析團隊需要自助的進行快速數(shù)據(jù)分析挖掘。

【挑戰(zhàn)】

• 分析團隊使用工具各異，如SAS、R、Python、SQL等。
• 分析團隊往往需要原始數(shù)據(jù)進行分析(非脫敏)，并且需要全歷史數(shù)據(jù)。
• 分析團隊希望可以快速拿到所需數(shù)據(jù)(往往并不知道需要什么數(shù)據(jù))，并敏捷高效專注于數(shù)據(jù)分析本身。

【方案】

圖27 敏捷分析挖掘工作流程

用ADX數(shù)據(jù)中臺解決敏捷分析挖掘的問題。

• 數(shù)據(jù)分析師登錄平臺，創(chuàng)建新項目，申請資源。根據(jù)需求查找選出表，選擇習慣的工具使用方法，填寫其他信息，申請使用。
• 各方按照策略依次審批。
• 審批通過后，數(shù)據(jù)分析師獲得資源，利用工具進行自助分析。

【總結】

• Moonbox本身是數(shù)據(jù)虛擬化解決方案，很適合進行各種異構數(shù)據(jù)源的即席數(shù)據(jù)讀取和計算，可以節(jié)省數(shù)據(jù)分析師很多數(shù)據(jù)工程方面的工作。
• Datahub/DataLake提供了實時同步的全增量數(shù)據(jù)湖，還可以進行配置化脫敏加密等安全策略，為數(shù)據(jù)分析場景提供了安全可靠全面的數(shù)據(jù)支持。
• Moonbox還專門提供了 mbpy(Moonbox Python)庫，以支持Python用戶更容易的在安全管控下進行快速無縫地數(shù)據(jù)查看、即席計算和常用算法運算工作。

圖28 敏捷分析挖掘示例

舉個例子，一個用戶打開Jupyter，import一個mbpy的庫包，并以用戶身份登錄Moonbox，就可以查看管理員授權給他的表。他可以運用拿到的數(shù)據(jù)和表進行分析、計算等，而不需要關注這些數(shù)據(jù)來自哪里，這對用戶來說是一個無縫的體驗。

如上圖，有兩張表，一張表是5000多萬條數(shù)據(jù)，存儲在Kudu里;另一張表是600萬多條數(shù)據(jù)，存儲在Oracle里。數(shù)據(jù)存儲在異構的系統(tǒng)中，且kudu本身不支持SQL。我們通過Moonbox制定邏輯，認為數(shù)據(jù)都在一個虛擬數(shù)據(jù)庫中， 只用了1分40秒就計算出結果。

【能力】

本案例需要的能力包括：分析鉆取能力、數(shù)據(jù)服務能力、算法模型能力、即席查詢能力、多維分析能力、數(shù)據(jù)權限能力、數(shù)據(jù)安全能力、數(shù)據(jù)管理能力、租戶管理能力、項目管理能力、資源管理能力。

4. 案例4 — 情景多屏聯(lián)動

【場景】

為了支持全方位的場景化和數(shù)字化驅(qū)動，有時會需要大中小智多屏聯(lián)動，大屏即為放映大屏，中屏即為電腦屏幕，小屏即為手機屏幕，智屏即為聊天客戶端屏幕。

【挑戰(zhàn)】

• 多屏由于定位不同，展示大小不同，操作不同，可以要求不同程度的可視化和定制化，帶來一定開發(fā)量。
• 多屏也需要在數(shù)據(jù)權限層面保持高度一致。
• 其中智屏更需要NLP、聊天機器人和任務機器人等智能能力，還需要有動態(tài)生成圖表能力。

【方案】

• 通過Davinci的Display功能，可以很好支持配置化滿足大小屏定制化需求。
• 通過Davinci統(tǒng)一數(shù)據(jù)權限體系，可以在多屏之間保持一致的數(shù)據(jù)權限條件。
• 通過ConvoAI的Chatbot/NLP能力，可以支持智能微BI能力，即為智屏。

圖29 Davinci的Display編輯頁面

上圖展示的是Davinci的Display編輯頁面，可以通過挑選不同的組件、調(diào)整透明度、任意擺放位置、調(diào)前景背景、顏色縮放比例等，自由地定義想要的展示樣式。

圖30 Davinci配置大屏

上圖是Davinci配置大屏的例子，(圖片來源于Davinci開源社區(qū)網(wǎng)友的實踐，數(shù)據(jù)經(jīng)過處理)，可以看到通過Davinci可以自己配置大屏，不需要開發(fā)。

圖31 Davinci配置小屏

上圖展示的是Davinci配置小屏的示例。圖片來源于宜信的尊享年會。現(xiàn)場工作人員通過手機查看實時數(shù)據(jù)，了解現(xiàn)場情況。

圖32 智屏

上圖展示的是智屏的示例。我們公司內(nèi)部有一個基于ConvoAI的聊天機器人，可以通過一個聊天窗口，跟用戶互動，針對用戶需求返回結果，包括圖表等。

5.  案例5 — 數(shù)據(jù)安全、管理

圖33 數(shù)據(jù)安全管理工作流程

這個案例比較簡單，一個完備的數(shù)據(jù)中臺，不僅有應用客戶場景，還有管理客戶場景，管理客戶典型的比如數(shù)據(jù)安全團隊和數(shù)據(jù)委員會。

數(shù)據(jù)安全團隊需要管理安全策略、掃描敏感字段、審批數(shù)據(jù)資源申請等。宜信敏捷數(shù)據(jù)中臺提供自動掃描功能，及時將掃描結果返回給安全團隊人員確認。安全團隊也可以定義幾層不同的安全策略、查看審計日志、調(diào)查數(shù)據(jù)流轉(zhuǎn)鏈路等。

數(shù)據(jù)委員會需要做數(shù)據(jù)調(diào)研、數(shù)據(jù)地圖查看、血緣分析、制定標準化和流程化的清洗規(guī)則等。他們同樣可以登錄數(shù)據(jù)中臺，完成這些工作。

五、總結

本次分享主要介紹了宜信敏捷數(shù)據(jù)中臺的頂層設計和定位、內(nèi)部的模塊架構和功能、以及典型應用場景與案例。我們立足于宜信業(yè)務需求現(xiàn)狀與數(shù)據(jù)平臺發(fā)展背景，基于五大開源工具進行有機組合和封裝，結合敏捷大數(shù)據(jù)的理念，打造適合宜信自己業(yè)務的一站式敏捷數(shù)據(jù)中臺，并在業(yè)務及管理中得以應用與落地，希望能為大家?guī)韱l(fā)和借鑒。

【本文是51CTO專欄機構宜信技術學院的原創(chuàng)文章，微信公眾號“宜信技術學院( id: CE_TECH)”】

戳這里，看該作者更多好文