宜信敏捷資料中臺建設實踐|分享實錄
內容來源：宜信技術學院第2期技術沙龍-線上直播|宜信敏捷資料中臺建設實踐
分享嘉賓：宜信資料中臺平臺團隊負責人 盧山巍
導讀：宜信於2017年推出了一系列大資料開源工具，包括大家熟悉的DBus、Wormhole、Moonbox、Davinci等，在技術社群內得到了廣泛關注和好評。這些工具是如何在宜信內部應用的？它們和宜信資料中臺是怎樣的關係？又是如何驅動各種日常資料業務場景的？
本次分享對這些問題進行了回答，同時重點分享了宜信敏捷資料中臺的設計、架構以及應用場景，提出一種敏捷資料中臺的建設思路，以供參考和探討。以下是本次分享的實錄。
分享大綱：
一、導語
二、宜信資料中臺頂層設計
三、從中介軟體工具到平臺
四、典型案例分析
五、總結
六、Q&A
視訊回放地址：https://v.qq.com/x/page/r0874wlaomx.html
PPT下載地址：https://pan.baidu.com/s/1jRumFMj_vQG1rxUvepEMlg
一、導語
目前“中臺”的概念很火，包括資料中臺、AI中臺、業務中臺、技術中臺等。宜信技術學院第一期技術沙龍，井玉欣博士分享了宜信的AI中臺，本期技術沙龍，由我來為大家分享《宜信敏捷資料中臺建設實踐》。
為什麼我們要在資料中臺前加上“敏捷”呢？瞭解我們的朋友都知道我所在的團隊是宜信敏捷大資料團隊，我們倡導“敏捷平民化”，把敏捷思想融入到系統建設中，並且研發了四個開源平臺：DBus、Wormhole、Moonbox、Davinci。宜信的資料中臺是由我們敏捷大資料團隊基於四大開源平臺開發建設的，因此我們將宜信的資料中臺稱之為“敏捷資料中臺”。
本次分享分為三個部分：
-
宜信敏捷資料中臺的頂層設計。資料中臺是一個公司級的平臺系統，所以不能只從技術層面去設計，還要考慮包括流程、標準化等在內的頂層設計。
-
從中介軟體工具到平臺介紹宜信是如何設計建設敏捷資料中臺的。
-
結合典型案例介紹宜信敏捷資料中臺支援哪些資料方面的應用和實踐。
二、宜信敏捷資料中臺的頂層設計
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.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/wormhole
圖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/moonbox
圖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/davinci
圖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.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 資料安全管理工作流程
這個案例比較簡單，一個完備的資料中臺，不僅有應用客戶場景，還有管理客戶場景，管理客戶典型的比如資料安全團隊和資料委員會。
-
資料安全團隊需要管理安全策略、掃描敏感欄位、審批資料資源申請等。宜信敏捷資料中臺提供自動掃描功能，及時將掃描結果返回給安全團隊人員確認。安全團隊也可以定義幾層不同的安全策略、檢視審計日誌、調查資料流轉鏈路等。
-
資料委員會需要做資料調研、資料地圖檢視、血緣分析、制定標準化和流程化的清洗規則等。他們同樣可以登入資料中臺，完成這些工作。
五、總結
本次分享主要介紹了宜信敏捷資料中臺的頂層設計和定位、內部的模組架構和功能、以及典型應用場景與案例。我們立足於宜信業務需求現狀與資料平臺發展背景，基於五大開源工具進行有機組合和封裝，結合敏捷大資料的理念，打造適合宜信自己業務的一站式敏捷資料中臺，並在業務及管理中得以應用與落地，希望能為大家帶來啟發和借鑑。
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、DB2、日誌、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裡，這也是工具化到平臺化的價值所在。
來源：宜信技術學院
拓展閱讀：【宜信技術沙龍01期】AI中臺：一種敏捷的智慧業務支援方案