數據中臺：宜信敏捷數據中臺建設實踐|分享實錄

時間 2019-11-07

原文原文鏈接

內容來源：宜信技術學院第2期技術沙龍-線上直播|宜信敏捷數據中臺建設實踐html

分享嘉賓：宜信數據中臺平臺團隊負責人盧山巍前端

導讀：宜信於2017年推出了一系列大數據開源工具，包括你們熟悉的DBus、Wormhole、Moonbox、Davinci等，在技術社區內獲得了普遍關注和好評。這些工具是如何在宜信內部應用的？它們和宜信數據中臺是怎樣的關係？又是如何驅動各類平常數據業務場景的？
本次分享對這些問題進行了回答，同時重點分享了宜信敏捷數據中臺的設計、架構以及應用場景，提出一種敏捷數據中臺的建設思路，以供參考和探討。如下是本次分享的實錄。git

分享大綱：github

1、導語算法

2、宜信數據中臺頂層設計數據庫

3、從中間件工具到平臺安全

4、典型案例分析架構

5、總結框架

6、Q&A運維

視頻回放地址：https://v.qq.com/x/page/r0874...

PPT下載地址：https://pan.baidu.com/s/1jRum...

1、導語

目前「中臺」的概念很火，包括數據中臺、AI中臺、業務中臺、技術中臺等。宜信技術學院第一期技術沙龍，井玉欣博士分享了宜信的AI中臺，本期技術沙龍，由我來爲你們分享《宜信敏捷數據中臺建設實踐》。

爲何咱們要在數據中臺前加上「敏捷」呢？瞭解咱們的朋友都知道我所在的團隊是宜信敏捷大數據團隊，咱們倡導「敏捷平民化」，把敏捷思想融入到系統建設中，而且研發了四個開源平臺：DBus、Wormhole、Moonbox、Davinci。宜信的數據中臺是由咱們敏捷大數據團隊基於四大開源平臺開發建設的，所以咱們將宜信的數據中臺稱之爲「敏捷數據中臺」。

本次分享分爲三個部分：

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

2、宜信敏捷數據中臺的頂層設計

2.1 特色和需求

關於數據中臺的建設，目前並無一個標準的解決方案，也沒有一個數據中臺能適用於全部的公司，每一個公司都應該結合本身的業務規模及數據需求現狀來研發適合本身公司的數據中臺。

在介紹宜信敏捷數據中臺的頂層設計以前，咱們先來了解其背景：

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

2.2 定位

關於數據中臺的定位，每一個公司都不太同樣。有的公司業務比較專一，只有一條業務線，那它在建設數據中臺的時候，可能須要一個垂直的平臺，直達前線，更好地支持前線的運做。

前文提到宜信業務線不少，且在衆多業務中沒有一個主體業務，這就至關於全部業務線都是主體。基於這樣的背景，咱們須要一個平臺化的數據中臺，來支撐全部業務線的需求和運做。

圖1 定位

如上圖所示，綠色的部分是宜信敏捷數據中臺，咱們稱之爲「ADX數據中臺平臺」，「A」即「Agile（敏捷）」，之因此稱爲「平臺」，是由於咱們但願將其打形成一個服務於全業務線的平臺系統，助力業務發展。

敏捷數據中臺處於中間位置，最底下是各類數據集羣，最上端是各個業務領域數據團隊。數據中臺經過整合處理數據集羣的數據，爲業務領域數據團隊提供自助化、實時化、統一化、服務化、管理化、可溯化的數據服務。

右邊三個藍色的板塊分別是數據管理委員會、數據運維團隊和數據安全團隊。前文提到宜信對數據安全的要求很是高，因此設置了專門的數據安全團隊來規劃公司數據安全的流程和策略；數據管理委員會負責數據的標準化、流程化，補齊技術型驅動的數據中臺的推進效率，保證有效沉澱和呈現數據資產。

咱們對宜信敏捷數據中臺的定位是：從數據技術和計算能力複用，到數據資產和數據服務複用，敏捷數據中臺會以更大價值帶寬，快、準、精讓數據直接賦能業務。

2.3 價值

宜信敏捷數據中臺的價值集中表現爲三個方面：快、準、省。

圖2 價值

存在的問題	敏捷數據中臺之「快」
定製化需求形成重複開發	平臺化，透明封裝複用技術組件
內包實施團隊需排期	自助化，簡單配置，月=>天
T+1延時知足不了實時及精細化運營	實時化，驅動業務增加，天=>分

存在的問題	敏捷數據中臺之「準」
數據存儲各異，取數方式各異，清洗邏輯各異	統一化，統一數據湖歸集和出口
數據孤島未打通整合	管理化，元數據、數據地圖、血緣
需求驅動實施，沒法沉澱數據資產	資產化，模型管理讓數據可信賴，標準化模型加工促使數據資產沉澱

存在的問題	敏捷數據中臺之「省」
時間成本，需求排期和重複開發	自助化，節省時間就是節省成本
人力成本，重複開發和缺乏複用	平臺化，成熟技術組件高複用度
硬件成本，集羣資源濫用形成浪費	精細化，集羣資源可估可查可量化

2.4 模塊架構維度

圖3 模塊架構維度

如圖所示，宜信敏捷數據中臺的建設也是基於「小前臺，大中臺」的共識。整個中間部分都屬於敏捷數據中臺包含的內容，左邊綠色部分是基於數據維度來看整個中臺，右邊藍色部分則是基於平臺維度來看中臺。

數據維度。各類內部數據、外部數據先歸集到數據源層，再以統一化、實時化、標準化、安全化等方式存儲起來造成數據湖層，數據湖對這些原始數據進行處理和體系化歸類，轉化爲數據資產；數據資產層包括數倉體系、指標體系、標籤體系、特徵體系、主數據等；最後將沉澱的這些可複用的數據資產提供給數據應用層，供BI、AI、數據產品應用。
平臺維度。每一個藍色的方框都表明一個技術模塊，整個宜信敏捷數據中臺就是由這些技術模塊組合而成。其中DataHub數據樞紐，能夠幫助用戶完成自助數據申請、發佈、脫敏、清洗和服務等；DataWorks數據工坊，能夠對數據進行自助查詢、做業、可視化等處理；還有DataStar數據模型、DataTag數據標籤、DataMgt 數據管理、ADXMgt 中臺管理等。

值得一提的是，這些模塊都不是從0開發的，而是基於咱們已有的開源工具。首先，基於成熟的中間件工具來進行開發，能夠節約開發的時間和成本；其次，開源工具成爲引擎，能夠共同協力支撐更大的一站式平臺。

2.5 數據能力維度

圖4 數據能力維度

將上述架構模塊從新按照能力維度劃分，能夠分紅若干層，每一層都包含若干能力。如圖所示，能夠清晰地看到建設數據中臺須要具有哪些數據能力，這些能力都對應哪些功能模塊，分別能解決什麼問題。此處再也不展開贅述。

3、從中間件工具到平臺

3.1 ABD總覽

圖5 ABD總覽

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

一開始，基於對業務需求共性的抽象和總結，咱們孵化出若干個通用的中間件，去解決各類各樣的問題。當出現更爲複雜的需求，咱們嘗試將這些通用的中間件進行組合運用。實踐中，咱們發現常常會使用到某些特定的組合，同時，從用戶角度來看，他們更但願能實現自助化，直接拿過來就能用，而不是每次都要本身去選擇和組合。基於這兩點，咱們對這幾個開源工具進行了封裝。

3.1.1 ABD-DBus

DBus（數據總線平臺），是一個DBaaS（Data Bus as a Service）平臺解決方案。

DBus面向大數據項目開發和管理運維人員，致力於提供數據實時採集和分發解決方案。平臺採用高可用流式計算框架，提供海量數據實時傳輸，可靠多路消息訂閱分發，經過簡單靈活的配置，無侵入接入源端數據，對各個IT系統在業務流程中產生的數據進行聚集，並統一處理轉換成經過JSON描述的UMS格式，提供給不一樣下游客戶訂閱和消費。DBus可充當數倉平臺、大數據分析平臺、實時報表和實時營銷等業務的數據源。

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

圖6 DBus功能及定位

如圖所示，DBus能夠無侵入地對接各類數據庫的數據源，實時抽取增量數據，作統一清洗和處理，並以UMS的格式存儲到Kafka中。

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

上圖右下角展現的是DBus的一個截圖，用戶在DBus上能夠經過一個可視化頁面，拉取增量數據，配置日誌和清洗方式，完成實時數據抽取等工做。

圖7 DBus架構

從如上架構圖能夠看到DBus包括若干不一樣的處理模塊，支持不一樣的功能。（GitHub有具體介紹，此處不做展開。）

3.1.2 ABD-Wormhole

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

Wormhole面向大數據項目開發和管理運維人員，致力於提供數據流式化處理解決方案。平臺專一於簡化和統一開發管理流程，提供可視化的操做界面，基於配置和SQL的業務開發方式，屏蔽底層技術實現細節，極大的下降了開發門檻，使得大數據流式處理項目的開發和管理變得更加輕量敏捷、可控可靠。

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

圖8 Wormhole功能及定位

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

Wormhole支持配置流式化的處理邏輯，同時能夠把處理完以後的數據寫到不一樣的數據存儲中。上圖中展現了不少Wormhole的功能特性，咱們還在開發更多新的功能。

上圖右下角是Wormhole的一個工做截圖，Wormhole做爲流式平臺，本身不從新開發流式處理引擎，它主要依賴Spark Streaming 和Flink Streaming 這兩種流式計算引擎。用戶能夠選擇其中一個流式計算引擎，好比Spark，配置流式處理邏輯，肯定Lookup庫的方式，並經過寫SQL來表達這個邏輯。若是涉及CEP，固然就是基於Flink。

由此能夠看出，使用Wormhole的門檻就是配置加上SQL。這也符合咱們一直秉承的理念，即用敏捷化的方式支持用戶自助玩轉大數據。

圖9 Wormhole架構

上圖展現的是Wormhole的架構圖，包含不少功能模塊。介紹其中的幾個功能：

Wormhole支持異構 Sink冪等，能幫助用戶解決數據一致性的問題。
用過 Spark Streaming的人都知道，發起一個 Spark Streaming可能只作一件事情。Wormhole在 Spark Streaming的物理計算管道中抽象出一層「邏輯的Flow」的概念，就是從什麼地方到什麼地方、中間作什麼事，這是一個「邏輯的Flow」。作了這種解耦和抽象以後，Wormhole支持在一個物理的 Spark Streaming管道中同時跑多個不一樣業務邏輯的Flow。因此理論上講，好比有1000個不一樣的 Source表，通過1000個不一樣的流式處理，最後要得出1000個不一樣的結果表，能夠只在Wormhole中發起一個Spark Streaming ，在裏面跑1000個邏輯的Flow來實現。固然這樣作的話可能會致使每一個Flow延遲加大，由於都擠在同一個管道里，但這裏的設置是很靈活的，我可讓某一個Flow獨佔一個VIP的 Stream，若是有些Flow流量很小，或者延遲對其影響不那麼大的話，可讓它們共享一個Stream。靈活性是Wormhole一個很大的特色。
Wormhole有本身的一套指令和反饋體系，用戶不用重啓或中止流，就能夠動態地在線更改邏輯，而且實時拿到做業和反饋結果等。

3.1.3 ABD-Moonbox

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

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

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

圖10 Moonbox功能及定位

數據從DBus過來，通過Wormhole的流式處理，可能落到不一樣的數據存儲中，咱們須要對這些數據進行混算，Moonbox支持多源異構系統無縫混算。上圖展現了Moonbox的功能特性。

平時所說的即席查詢並無真正作到「即席」，由於須要用戶先手工地把數據導到Hive再作計算，這是一個預置的工做。Moonbox不須要事先把數據導到一個地方去，作到了真正的即席查詢。數據能夠散落到不一樣的存儲中，當用戶有需求時，只需寫一個SQL，Moonbox能夠自動拆分這個SQL，從而得知哪些表在哪裏，而後規劃SQL的執行計劃，最終拿到結果。

Moonbox對外提供標準的REST、API、JDBC、ODBC等，所以也能夠將之當作一個虛擬數據庫。

圖11 Moonbox架構

上圖展現的是Moonbox的架構圖。能夠看到Moonbox的計算引擎部分也是基於Spark引擎作的，並無自研。Moonbox對Spark進行擴展和優化，增長了不少企業級的數據庫能力，好比用戶、租戶、權限、類存儲過程等。

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

3.1.4 ABD-Davinci

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

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

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

圖12 Davinci功能及定位

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

圖13 Davinci架構

從設計層面來看，Davinci有本身的完備和一致性的內在邏輯。包括Source、View、Widget，支持各類數據可視化應用。

圖14 Davinci富客戶端應用

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

3.2 ABD架構

圖15 ABD架構

在ABD時代，咱們經過DIY組合四個開源工具來支持各類各樣的數據應用需求。如上圖所示，將整個端到端的流程串起來，這個架構圖展現了咱們「有收有放把整個鏈路打通」的理念。

收。好比採集、架構、流轉、注入、計算服務查詢等功能，須要收斂集合成一個平臺。
放。面對複雜的業務環境，數據源也是各類各樣的沒法統一，很難有一個存儲或數據系統能夠知足全部的需求，使得你們再也不須要選型。所以這一塊的實踐是開放的，你們能夠自主選擇開源工具和組件來適配和兼容。

3.3 ADX總覽

發展到必定階段時，咱們須要一個一站式的平臺，把基礎組件封裝起來，使得用戶能夠在這個平臺上更簡單地完成數據相關的工做，因而進入了ADX數據中臺建設階段。

圖16 ADX 總覽

上圖是ADX 總覽，至關於一個一級功能菜單。用戶登陸到平臺，能夠作如下事情：

項目看板：能夠看到所在項目的看板，包括健康狀況等各方面的統計狀況。
項目管理：能夠作項目相關的管理，包括資產管理、權限管理、審批管理等。
數據管理：能夠作數據方面的管理，好比查看元數據，查看數據血緣等。
數據申請：項目配置好了，數據也瞭解了，能夠作實際工做了。基於安全和權限考慮，並非誰均可以去用放在裏面的數據，所以首先要作數據申請。右邊藍色模塊是本次分享將重點介紹的ADX數據中臺的五大功能模塊。數據申請更可能是由DataHub數據樞紐來實現的，它支持自助申請、發佈、標準化、清洗、脫敏等。
即席查詢、批量做業、流式做業是基於DataWorks數據工坊實現的。
數據模型是基於DataStar這個模型管理平臺來實現的。
應用市場包括數據可視化（數據加工完以後能夠配置最終展示樣式爲圖或儀表板等，這裏可能用到Davinci）；標籤畫像、行爲分析等常見分析方法；智能工具箱（幫助數據科學家更好地作數據集分析、挖掘和算法模型的工做）以及智能服務、智能對話（好比智能聊天機器人）等。

3.3.1 ADX-DataHub數據樞紐

圖17 DataHub工做流程

上圖藍色虛線框顯示的是 DataHub的流程架構，橙色方塊是咱們的開源工具，其中「tria」表明Triangle，是宜信另外一個團隊研發的做業調度工具。
DataHub不是簡單地封裝了鏈路，而是使得用戶能夠在一個更高的level上獲得更好的服務。好比用戶須要某一歷史時刻精確到秒的快照，或者但願拿到一個實時增量數據去作流式處理，DataHub均可以提供。

它是怎麼作到的呢？經過將開源工具引擎化，而後進行整合。舉個例子：不一樣數據源，經過DBus實時抽取出來，通過Wormhole流式處理後落到 HDFS Log數據湖中，咱們把全部實時增量數據都存儲在這裏面，這就意味着咱們能夠從中拿到全部的歷史變動數據，並且這些數據仍是實時同步的。再經過Moonbox在上面定義一些邏輯，當用戶提出想要某一歷史時刻的快照或者增量數據，就能夠即時計算並提供。若是想作實時報表，須要把數據實時快照維護到一個存儲裏，這裏咱們選擇Kudu。

流式處理有不少好處，同時也有短板，好比運維成本較高、穩定性較差等。考慮到這些問題，咱們在DataHub中設置了Sqoop做爲Plan B。若是實時這條線晚上出現問題，能夠自動切換到Plan B，經過傳統的Sqoop去支持次日T+1的報表。等咱們找到並解決問題以後，Plan B就會切換到暫停狀態。

假設用戶本身有數據源，放在Elasticsearch 或者Mongo裏，也但願經過DataHub發佈出去共享給其餘人使用。咱們不該該把Elasticsearch 數據或Mongo數據物理地拷貝到一個地方，由於首先這些數據是NoSQL的，數據量比較大；其次用戶可能但願別人經過模糊查詢的方式去使用Elasticsearch 數據，那可能繼續將數據放在Elasticsearch 裏更好。這時咱們作的是經過Moonbox進行一個邏輯的發佈，但用戶不感知這個過程。

綜上能夠看出，DataHub是在內部把幾個開源平臺經常使用的模式進行有機整合和封裝，對外提供一致性、便捷的數據獲取、發佈等服務。其使用方也能夠是各類不一樣的角色：

數據擁有方能夠在這裏作數據審批；
數據工程師能夠申請數據，申請完後能夠在這裏對數據進行加工；
APP用戶能夠查看Davinci報表；
數據分析師能夠直接用本身的工具去接DataHub出來的數據，而後作數據分析；
數據用戶可能但願本身作一個數據產品，DataHub能夠爲他提供接口。

圖18 DataHub架構

如圖，將DataHub打開，來看其架構設計。從功能模塊角度來看，DataHub基於不一樣開源組件，實現不一樣功能。包括批量採集、流式採集、脫敏、標準化等，還能夠基於不一樣的協議輸出訂閱。

DataHub與其餘幾個組件之間的關係也是很是緊密的。它輸出的數據給DataWorks使用，同時它又依賴中臺管理、數據管理來知足其需求。

3.3.2 ADX-DataLake實時數據湖

廣義的數據湖，就是把全部數據都放在一塊兒，先以存儲和歸集爲主，使用的時候再根據不一樣數據提供不一樣使用方式。

咱們這裏提到的是一個狹義的數據湖，只支持結構化數據源和天然語言文本這兩種類型的數據歸集，而且有統一的方式存儲。

圖19 DataLake

也就是說咱們的實時數據湖加了限制，公司全部結構化數據源和天然語言文本會統一實時彙總爲UbiLog，並由ADX-DataHub統一對外提供訪問。UbiLog的訪問和使用只能經過ADX提供的能力輸出，所以確保了多租戶、安全、權限管控。

3.3.3 ADX-DataWorks數據工坊

主要的數據加工都是在DataWorks自助完成的。

圖20 DataWorks工做流程

如圖來看DataWorks的工做流程。首先DataHub數據出來以後，DataWorks必須去接DataHub的數據。DataWorks支持實時報表，咱們內部使用的是Kudu，因此把這個模式固化下來，用戶就不用本身去選型，直接在上面寫本身的邏輯就能夠了。好比有一個實時DM或批量DM，咱們以爲這是一個很好的數據資產，有複用價值，但願別的業務能複用這個數據，咱們就能夠經過DataHub把它發佈出去，別的業務就能夠申請使用。

因此DataHub和DataWorks等組件封裝而成的數據中臺能夠達到數據共享和數據運營的效果。中臺內部包含Kudu、Kafka、Hive、MySQL等數據庫組件，可是用戶不須要本身去選型，咱們已經作出了最佳選擇，並將其封裝成一個可直接使用的平臺。

上圖左側有一個數據建模師的角色，他在DataStar中作模型管理和開發建設，在DataWorks中主要是負責邏輯和模型的建立；數據工程師不用多說，是最多見的使用DataWorks的角色；終端用戶能夠直接使用Davinci。

圖21 DataWorks架構

如圖，將DataWorks打開來看它的架構，一樣DataWorks也是經過不一樣的模塊來支持各類不一樣的功能。關於這部份內容之後會有更多的文章和分享，此處不詳細介紹。

3.3.4 ADX-DataStar數據模型

圖22 DataStar工做流程

DataStar跟數據指標模型或數據資產相關，每一個公司都有本身內部的數據建模流程和工具。DataStar能夠分爲兩個部分：

模型設計、管理建立。對模型生命週期的管理和工藝流程的沉澱。
從DW（數倉）層到DM（數據集市）層，支持配置化的方式，自動在底下生成對應SQL邏輯，而不須要用戶本身去寫。

DataStar是DW層的事實和維度表組成的星型模型，能夠最後沉澱下來。但咱們認爲，從DW層到DM層或APP層，不須要寫SQL開發了，只須要經過選維度和配置指標的方式，就能夠自動可視化配置出來。

這樣的話對使用人的要求就發生了改變，須要一個建模師或者業務人員來作這個事情，給他一個基礎數據層，他根據本身的需求來配置想要的指標。整個過程，數據實施人員只須要關注ODS層到DW層就能夠了。

3.3.5 ADXMgt/DataMgt中臺管理/數據管理

圖23 ADXMgt/DataMgt

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

3.4 ADX架構

圖24 ADX架構

ADX數據中臺平臺幾個模塊之間的關聯如圖所示。最底下是五個開源工具，每一個模塊都是對這五個開源工具的有機整合和封裝。從圖中能夠看出各組件之間的關聯很是緊密，其中黑色虛線表明的是依賴關係，綠色線條表明的是數據流轉的關係。

4、典型案例分析

如上所述，咱們基於開源工具進行有機整合和封裝，打造了一個更加現代化、自助化、完備的一站式數據中臺平臺。那這個平臺是如何發揮其做用，爲業務提供服務的呢？本節將列舉五個典型案例。

4.1 案例1 — 自助實時報表

【場景】

業務領域組數據團隊須要緊急製做一批報表，不但願排期，但願能夠自助完成，而且部分報表須要T+0時效性。

【挑戰】

業務組數據團隊工程能力有限，只會簡單SQL，以前要麼轉給BI排期，要麼經過工具直連業務備庫製做報表，要麼經過Excel製做。
數據來源可能來自異構數據庫，沒有很好的平臺支持自助導數。
對數據時效性要求很高，須要流上作數據處理邏輯。

【方案】

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

用ADX數據中臺解決自助實時報表的問題。

數據工程師登陸平臺，建立新的項目，申請數據資源。
數據工程師經過元數據查找選出表，選擇DataWorks方式使用，填寫其餘信息，申請這些須要用到的表。好比我須要用到100張表，其中70張是經過T+1的方式使用，30張是經過實時方式使用。
默認中臺會作標準化脫敏加密策略，收到這些申請以後，中臺管理員會按策略依次進行審批。
審批經過後，中臺會自動準備和輸出所申請的數據資源，數據工程師能夠運用拿到的數據資源進行自助查詢、開發、配置、SQL編排、批量或流式處理、配置DV等。
最後將自助報表或儀表板提交給用戶使用。

【總結】

各個角色經過一站式數據中臺交互，統一流程，全部動做都記錄在案，可查詢。
平臺全自助能力，大大提升了業務數字化驅動進程，無需排期等待，通過短暫培訓，人均 3-5日能夠自助完成一張實時報表，實時報表再也不求人。
平臺支持人員也無需過多參與，再也不成爲進度瓶頸。

【能力】

這個場景須要用到不少數據能力，包括：即席查詢能力、批量處理能力、實時處理能力、報表看板能力、數據權限能力、數據安全能力、數據管理能力、租戶管理能力、項目管理能力、做業管理能力、資源管理能力。

4.2 案例2 — 協做模型指標

【場景】

業務線須要打造本身的基礎數據集市，以共享給其餘業務或者前線系統使用。

【挑戰】

如何有效建設數據模型和管理數據模型。
如何既支持本身領域內數據模型建設，同時也支持數據模型的共享。
數據的共享發佈如何從流程上固化、並實現技術安全統一管控。
如何運營數據以確保有效數據資產沉澱和管理。

【方案】

圖26 協做模型指標工做流程

用ADX數據中臺解決協做模型指標的問題。

數據建模師登陸平臺，建立新項目，申請資源。而後查找選出表，設計一個或若干個維度表的DW模型，推送到DataWorks項目。
數據工程師選擇須要的Source表，基於DataStar項目完成從ODS到DW以前的ETL 開發，而後提交做業，發佈到DataHub跑起來。
數據建模師持續可視化配置維護和管理DW/APP層指標集，包括維度的聚合、計算等。

【總結】

這是一個典型的數據資產管理、數據資產運營的案例，經過統一的協做化的模型指標管理，確保了模型可維護、指標可配置、質量可追溯。
DataStar也支持一致性維度共享、數據詞典標準化、業務線梳理等，能夠進一步柔性支持公司統一數據基礎層的建設和沉澱。

【能力】
本案例須要的能力包括：數據服務能力、即席查詢能力、批量處理能力、數據權限能力、數據安全能力、數據管理能力、數據資產能力、租戶管理能力、項目管理能力、做業管理能力、資源管理能力。

4.3 案例3 — 敏捷分析挖掘

【場景】

業務領域組數據分析團隊須要自助的進行快速數據分析挖掘。

【挑戰】

分析團隊使用工具各異，如SAS、R、Python、SQL等。
分析團隊每每須要原始數據進行分析（非脫敏），而且須要全歷史數據。
分析團隊但願能夠快速拿到所需數據（每每並不知道須要什麼數據），並敏捷高效專一於數據分析自己。

【方案】

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

用ADX數據中臺解決敏捷分析挖掘的問題。

數據分析師登陸平臺，建立新項目，申請資源。根據需求查找選出表，選擇習慣的工具使用方法，填寫其餘信息，申請使用。
各方按照策略依次審批。
審批經過後，數據分析師得到資源，利用工具進行自助分析。

【總結】

Moonbox自己是數據虛擬化解決方案，很適合進行各類異構數據源的即席數據讀取和計算，能夠節省數據分析師不少數據工程方面的工做。
Datahub/DataLake提供了實時同步的全增量數據湖，還能夠進行配置化脫敏加密等安全策略，爲數據分析場景提供了安全可靠全面的數據支持。
Moonbox還專門提供了 mbpy（Moonbox Python）庫，以支持Python用戶更容易的在安全管控下進行快速無縫地數據查看、即席計算和經常使用算法運算工做。

圖28 敏捷分析挖掘示例

舉個例子，一個用戶打開Jupyter，import一個mbpy的庫包，並以用戶身份登陸Moonbox，就能夠查看管理員受權給他的表。他能夠運用拿到的數據和表進行分析、計算等，而不須要關注這些數據來自哪裏，這對用戶來講是一個無縫的體驗。

如上圖，有兩張表，一張表是5000多萬條數據，存儲在Kudu裏；另外一張表是600萬多條數據，存儲在Oracle裏。數據存儲在異構的系統中，且kudu自己不支持SQL。咱們經過Moonbox制定邏輯，認爲數據都在一個虛擬數據庫中，只用了1分40秒就計算出結果。

【能力】

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

4.4 案例4 — 情景多屏聯動

【場景】

爲了支持全方位的場景化和數字化驅動，有時會須要大中小智多屏聯動，大屏即爲放映大屏，中屏即爲電腦屏幕，小屏即爲手機屏幕，智屏即爲聊天客戶端屏幕。

【挑戰】

多屏因爲定位不一樣，展現大小不一樣，操做不一樣，能夠要求不一樣程度的可視化和定製化，帶來必定開發量。
多屏也須要在數據權限層面保持高度一致。
其中智屏更須要NLP、聊天機器人和任務機器人等智能能力，還須要有動態生成圖表能力。

【方案】

經過Davinci的Display功能，能夠很好支持配置化知足大小屏定製化需求。
經過Davinci統一數據權限體系，能夠在多屏之間保持一致的數據權限條件。
經過ConvoAI的Chatbot/NLP能力，能夠支持智能微BI能力，即爲智屏。

圖29 Davinci的Display編輯頁面

上圖展現的是Davinci的Display編輯頁面，能夠經過挑選不一樣的組件、調整透明度、任意擺放位置、調前景背景、顏色縮放比例等，自由地定義想要的展現樣式。

圖30 Davinci配置大屏

上圖是Davinci配置大屏的例子，（圖片來源於Davinci開源社區網友的實踐，數據通過處理），能夠看到經過Davinci能夠本身配置大屏，不須要開發。

圖31 Davinci配置小屏

上圖展現的是Davinci配置小屏的示例。圖片來源於宜信的尊享年會。現場工做人員經過手機查看實時數據，瞭解現場狀況。

圖32 智屏

上圖展現的是智屏的示例。咱們公司內部有一個基於ConvoAI的聊天機器人，能夠經過一個聊天窗口，跟用戶互動，針對用戶需求返回結果，包括圖表等。

4.5 案例5 — 數據安全、管理

圖33 數據安全管理工做流程

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

數據安全團隊須要管理安全策略、掃描敏感字段、審批數據資源申請等。宜信敏捷數據中臺提供自動掃描功能，及時將掃描結果返回給安全團隊人員確認。安全團隊也能夠定義幾層不一樣的安全策略、查看審計日誌、調查數據流轉鏈路等。
數據委員會須要作數據調研、數據地圖查看、血緣分析、制定標準化和流程化的清洗規則等。他們一樣能夠登陸數據中臺，完成這些工做。

5、總結

本次分享主要介紹了宜信敏捷數據中臺的頂層設計和定位、內部的模塊架構和功能、以及典型應用場景與案例。咱們立足於宜信業務需求現狀與數據平臺發展背景，基於五大開源工具進行有機組合和封裝，結合敏捷大數據的理念，打造適合宜信本身業務的一站式敏捷數據中臺，並在業務及管理中得以應用與落地，但願能爲你們帶來啓發和借鑑。

Q&A：

Q：企業能純粹依靠開源社區的開源工具來搭建數據中臺嗎？

A：數據中臺是要切合企業實際狀況和目標去建設的，有些好的開源工具自己已經很成熟，不須要重複造輪子，同時也有一些企業根據自身環境和需求，須要定製化開發。因此通常數據中臺都會既有開源工具選型，也會有結合自身狀況的企業內通用組件的開發。

Q：數據中臺建設中，須要避免哪些彎路、哪些坑？

A：數據中臺比純技術平臺要求更多直接賦能業務的能力建設，如數據資產沉澱、數據服務建設、數據加工流程工藝抽象、企業數據標準化安全化管理等，這些可能都沒法依靠純技術驅動自下而上地推進，而是須要公司層面和業務層面達成一致認識和支持，而且由業務實際需求驅動數據中臺迭代建設的。這樣的自上而下和自下而上相結合的迭代方式，能夠有效避免沒必要要的短視和過分設計。

Q：數據中臺建設完畢，其成熟度和效果如何評估？

A：數據中臺的價值由驅動的業務目標來衡量。定性來講，就是是否真正作到了快、準、省的效果；定量來講，能夠經過平臺組件複用度、數據資產複用度、數據服務複用度等指標來評估成熟度。

Q：平臺的元數據是怎樣管理的？

A：元數據是一個獨立的大話題，從元數據類目劃分，到如何採集維護各類元數據，再到如何基於元數據信息打造各類元數據應用等，是能夠單獨拿出一個完整的分享來探討的。具體到宜信ADX的元數據管理，咱們也是按照上述思路進行，先是整理出全景元數據類目劃分，而後很重要的一點是「業務痛點驅動元數據體系建設「，咱們會根據目前公司對元數據最迫切的需求圈定優先級，而後在技術層面能夠經過Moonbox進行各類數據源的基礎技術元數據採集，基於Moonbox的SQL解析能力來生成執行血緣關係等，最後根據業務的實際痛點，好比上游源數據表結構變動會如何影響下游數據應用（血緣影響度分析），下游數據問題如何追溯上游數據流轉鏈路（數據質量診斷分析）等，迭代的開發一個個元數據應用模塊。

Q：數據建模師建模的方法論是什麼？和數倉的維度建模有什麼區別？

A：咱們的建模方法論也是基於著名的《數據倉庫工具箱》來指導建設的，而且根據宜信實際狀況，對Kimball的維度建模進行了必定的簡化、標準化、通用化設計，同時也參考了阿里的OneData體系的經驗，這塊咱們並沒有太多首創性。DataStar更重要的目標，仍是如何易用、有效的吸引和幫到數據建模師，從流程上可以讓模型建設統一化、線上化、管理化，同時力求減小ETL開發人員負擔，將DW到DM/APP層的個性化指標工做經過配置化下放給非數據開發人員自助完成。因此DataStar總體上仍是以管理和提效爲主要目標的。

Q：Triangle任務調度系統是開源的麼？

A：Triangle是另外一個團隊研發維護的，他們有開源計劃，具體什麼時候開源咱們還太肯定。

Q：Davinci 什麼時候發版？

A：這是個永恆的問題，感謝你們對Davinci的持續關注和承認，咱們有計劃將Davinci推到Apache孵化，因此但願你們能夠一如既往地支持Davinci，讓Davinci成爲最好的開源可視化工具選擇。

Q：數據服務是管控了全部的數據讀取寫入嗎？最好的狀況是全部業務方均可經過數據服務訪問數據，這樣的話數據管理、鏈路、地圖就比較容易作。問題是不少狀況下知道鏈接信息的話，業務方是能夠直連的，怎麼避免業務方本身使用API直連？

A：是的，DataHub的目標就是統一收口數據歸集、數據申請、數據發佈、數據服務，這樣像數據安全管理、鏈路管理、標準化管理等都更容易實現了。如何避免業務方繞過DataHub直連源庫，這個恐怕要在管理流程上管控了，對於DataHub自己，因爲DataHub封裝了實時數據湖，使得DataHub擁有了直連業務備庫全部不具有的能力特性，加上持續提高DataHub使用體驗和功能，相信業務方會更加願意從DataHub對接數據的。

Q：DBus支持Postgres數據源嗎?

A：DBus目前支持MySQL、Oracle、DB二、日誌、Mongo數據源，其中Mongo因爲自己日誌的特色使得DBus只能接出非完整增量日誌（只有更新的列會輸出），這樣對強順序消費就提出了很高要求，內部來講沒有太多DBus接Mongo的場景。社區有提出DBus對接PostgreSQL和SQLServer的需求，理論上都是能夠擴展對接的，但目前團隊都投入在數據中臺建設上，更多數據源類型的對接，若是有須要的話，能夠直接聯繫咱們團隊討論。

Q：Moonbox的底層是用Spark SQL實現的這種混合計算，須要消耗不少資源，是怎麼優化的呢？

A：Moonbox的混算引擎是基於Spark的，並對Spark作了一些優化工做，其中最大的一塊優化就是支持了更多計算下推（Pushdown），Spark自己也具有數據聯邦混算能力，但Spark只支持部分算子下推，如Projection和Predict，Moonbox對Spark作了旁路擴展，支持更多如Aggregation、Join、Union等算子下推，而且在解析SQL時會根據數據源計算特色進行有策略的下推執行計劃，儘可能讓數據源作更適合的計算工做，減小在Spark裏混算的計算成本。

Moonbox還支持若是SQL自己沒有混算邏輯，且數據源適合整個SQL計算，Moonbox能夠繞過Spark直接將全SQL作總體下推到數據源。另外，Moonbox支持Batch計算、分佈式Interactive計算和Local Interactive計算模式，每種都作了不一樣的優化和策略。

Q：離線計算和實時計算是怎麼配合的，離線計算能夠作分層存儲，實時計算怎麼實現分層存儲？

A：實時計算分層，有一種作法是經過Kafka來作，固然若是對實時分層數據的時效性要求不過高（如分鐘級）的話，也能夠選擇一些實時NoSQL存儲，如Kudu。「離線計算和實時計算怎麼配合「，有了Moonbox，其實無論批量計算和流式計算的數據存儲在哪裏，均可以經過Moonbox作無縫混算的，能夠說Moonbox簡化並抹平了不少數據流轉架構的複雜性。

Q：中臺的定位是什麼，會不會又是一個buzzword？在宜信內部，數據中臺跟傳統後臺的關係是怎樣的？

A：宜信數據中臺的定位在演講開頭已經談到了，簡單來講就是對下層作統一化管理化透明化，對中層作通用化標準化流程化，對上層作資產化服務化自助化。Buzzword這個也是要一分爲二的看，有些浪潮留下的更可能是教訓，有些浪潮帶來的更可能是進步。「數據中臺跟傳統後臺的關係「，這裏傳統後臺我理解是指業務後臺吧，好的業務後臺能夠更好配合和支持數據中臺，很差的業務後臺會把更多數據層面的挑戰留待數據中臺去面對和解決。

Q：數據異構存儲在如此多的存儲組件中，如何保證個性化查詢的效率？

A：這個問題應該是指Moonbox這種體系架構，如何保證即席查詢效率。純即席查詢（源數據直接計算出結果），查詢效率怎樣都不會拼過內存型MPP查詢引擎的。對於咱們來說，Moonbox主要用於統一批量計算入口、統一即席查詢入口、統一數據服務、統一元數據歸集、統一數據權限、統一血緣關係生成、統一數據工具箱等。若是追求毫秒級/秒級查詢效率，要麼採用預計算引擎如Kylin、Druid等、要麼ES、Clickhouse等，但這些都有個前提，就是基礎數據都已經準備好。所以咱們的數據中臺鏈路，是支持ETL以後將DW/DM數據物理寫入ES、Clickhouse並統一DataHub發佈的，這樣能夠必定程度上保證「個性化「查詢效率。單純從Moonbox角度而言，在異構存儲上進行分鐘級/小時級的預計算並將結果寫入Clickhouse，能夠支持分鐘級/小時級數據延遲，毫秒級/秒級查詢延遲。

Q：若是有新的數據進入系統，整個數據採集到進入存儲的過程是由開發人員控制，仍是專門的數據管理人員經過界面組合各個組件Pattern來控制？

A：若是新數據源來自業務數據庫備庫，DBus已經對接了此備庫前提下，會有專門的數據中臺管理員在數據中臺管理界面上配置發佈新的ODS，以供下游使用方在DataHub上申請並使用；若是新數據源來自業務自有NoSQL庫，業務人員能夠自助地在DataHub上發起發佈數據流程，而後下游使用方能夠在元數據上看到並在DataHub上申請並使用。

所謂「數據採集到存儲「，也是分爲實時採集、批量採集、邏輯採集等的，這些經常使用數據源類型、數據對接方式、用戶使用方式等都被DataHub封裝整合在內，無論是數據擁有方仍是數據使用方面對的都是一站式的DataHub用戶界面，全部的數據鏈路Pattern、自動化流程和最佳技術選型和實踐都被透明化封裝在DataHub裏，這也是工具化到平臺化的價值所在。