宜信盧山巍：數據中臺的「自動化數據治理」時代已來

中臺，我理解是能力的下沉，數據處理能力下沉爲加工平臺，數據處理結果下沉爲數據資產。那麼數據治理可否下沉？能夠下沉出什麼東西？

——宜信數據中臺負責人 盧山巍

本文來源：宜信數據中臺負責人盧山巍在億歐產業互聯網頻道「數字中臺創新」沙龍的分享實錄

原文首發：億歐

億歐產業互聯網頻道10月24日在上海InnoSpace落地「數字中臺創新」沙龍，活動匯聚了良品鋪子電商技術中心總監羅軼羣、愛馳汽車科技信息總監杭瑜峯、宜信數據中臺負責人盧山巍、ThoughtWorks首席諮詢師及極客時間《說透中臺》專欄做者王健、億歐華東負責人繆國成、億歐產業互聯網頻道副主編黃志磊、億歐產業互聯網頻道做者龔晨霞參與分享，就數字中臺話題展開深度討論。

宜信是一家成立於2006年從事普惠金融和財富管理業務的金融科技企業，2018年基於四大開源平臺和中間件等技術，開始研發數據中臺，並在宜信內部推廣使用。目前，宜信的中臺部門一共分爲兩大板塊：數據中臺和AI中臺。

如下是盧山巍演講觀點梳理：

一、宜信數據中臺指導思惟：統一建設、敏捷開發

二、從開源到中臺，關鍵詞是自助化

三、數據治理，更依賴人治仍是自治？

如下是演講速記實錄，經億歐產業互聯網頻道整理，供行業人士參考。

你們下午好，我叫盧山巍，來自宜信。剛纔聽羅總高屋建瓴地介紹了中臺的概念和應用，受益不淺。個人分享會不太同樣：第一，我有一個限定詞是「數據」。羅總的分享對業務中臺、組織中臺、技術中臺都有探討，而我自己是作數據的，因此我只介紹數據中臺。第二，我我的是從純粹技術路線走上來的，分享的內容會比較具體而微 。

我今天分享的話題是《宜信數據中臺建設三部曲》，內容將按照時間發展故事線來展開。分別是：「敏捷使者」— ABD時代（2015年-2018年） ；「自助奇兵」— ADX時代（2018年-2019年）； 「自治歸來」— ADG時代（2019年-）。

2015年加入宜信以前，我在上海張江的eBay研發中心工做，當時的主要方向是大數據架構和研發，在付費廣告組作大數據相關的事情。因爲我我的的關注點比較下沉，對平臺技術更感興趣，所以總想在技術領域中作出一些框架和平臺類的東西。

一、宜信數據中臺指導思惟：統一建設、敏捷開發

2015年宜信找到我，說公司內部沒有數據平臺，但願我可以去帶領建設數據平臺，因而我加入了宜信。

其實說「公司沒有數據平臺」是不許確的，更準確地說應該是「公司沒有統一的數據平臺」，由於公司不少業務線都有本身所謂的數據平臺，有的作得好一點，有的是純粹的定製化，談不上平臺化，由於公司規模很大，不少是自下而上地建設，不像銀行是自上而下去推進作這個事情。當時也沒有數據中臺這個概念，只是說要作一個好的數據平臺，感受有點無從下手，頗有挑戰，所以着手作了不少公司內部的調研和訪談，用幾張圖來展示當時的現狀。

左上角的圖表達的是業務的豎井，從前臺到業務開發端，到數據端，甚至有的數據庫都沒打通。一般好的數據中臺，要有好的業務中臺配合，在業務豎井嚴重的現狀下，想在數據層融合打通是挺難的事。

左下角表達的是在2015年的時候，不少企業都面臨的兩個慢的問題，即：時效慢、實施慢。

一方面，那時比較主流的仍是T+1批處理，不少企業沒有完善的流式處理平臺，不像如今有不少成熟的選擇。通常來說都是隻能知足T+1時效的數據需求。

另外一方面，由於沒有很好的自助平臺給你們使用，就變成了需求提給特定的BI團隊，BI團隊接了這個需求，需求多了忙不過來，就開始排期，可能要1-2個月甚至以上的時間才能響應和處理這個需求。

有的業務部門比較有實力，擁有很多大數據工程師，使用了不少技術選型，好比MongoDB、ES、HBase、Cassandra、Phoenix、Presto、Spark、Hive、Impala等等各類技術選型都有，沒有統一的技術選型標準。而公司需求又是多樣化的，像上圖右邊的自助查詢、360全景分析、實時處理、多維分析、數據湖等等，使得大數據架構變得愈來愈複雜和臃腫，愈來愈難以建設和維護，再加上圖下方的數據治理、數據質量、數據安全等切面課題，當時面臨的就是這樣一個比較複雜的現狀。

在這樣的現狀之下思考整個問題，找尋解決方案。自己我我的是比較倡導敏捷開發思想的，敏捷開發更可能是在業務開發方面的實踐經驗，大數據比較笨重，怎麼才能讓大象奔跑起來？我認爲要用敏捷化思想去建設數據平臺。通過調研和思考，造成了一系列大數據敏捷思想框架、實踐和方法論，更重要的是咱們要落地一些中間件去驅動敏捷化實踐。

接下來咱們前後自研了四個中間件平臺：DBus、Wormhole、Moonbox、Davinci。既然用了這麼多的技術選型，又很難快速將它們統一到一套技術選型，還要可以去統一收口管控關鍵節點，最好的辦法就是利用中間件思想去適配已有的選型，而後再去簡化整個架構。

下面這個圖就比較技術視角了，展現了整個數據處理的鏈路，從左到右，分爲數據源層、數據集成層、數據總線層、數據處理層、數據存儲層、數據服務層和數據應用層 。其中數據源層，自然有各類各樣的選型，這是業務須要；數據存儲層，出於不一樣目的有了衆多技術選型，這個也無法很快統一，並且自己也很難找到一個大數據存儲選型，可以解決全部的存儲問題和計算問題，因此不得不面對多個存儲和計算的整合問題。

在應用端，需求場景驅動也是很難整合統一的。可以整合收口的是數據集成層、數據總線層、數據處理層和數據服務層 。整個數據鏈路梳理完以後，是一種「開放+統一」的架構，有些層面是開放包容的，而有些層面是要統一收口管控的。

固然，上圖灰色的切面課題也是應該關注和支持的，由於咱們當時的策略是作四個中間件工具DBus、Wormhole、Moonbox、Davinci，所以沒有太關注這些切面課題 。

下面分別介紹這些中間件工具：

• DBus，可以實時將數據抽取出來，能夠對接多個數據庫和日誌，既能夠實時抽取增量數據，也支持抽取全量數據，並與增量數據保持一致性id體系，以支持後續冪等入庫。
• Wormhole，負責流式做業開發和管理，能夠不用編寫代碼，只經過配置和SQL方式便可支持實時同步和流上處理邏輯。這也體現出敏捷性：一是中間件統一了通用技術實現，不用重複開發；二是不斷地下降數據項目實施成本，實施人員儘可能關注業務邏輯自己，簡單培訓便可自助完成項目，這些都是敏捷思想的體現。舉個例子，從使用體驗上看，好比增量數據從Oracle實時出來，但願實時寫到MySQL裏去，只要簡單配置一下就能夠了，若是還須要有一些實時處理邏輯，好比流上增量數據去Lookup外面的Redis，只要寫一個SQL便可 。另外，由於咱們作中間件而不重造引擎，因此Wormhole是基於主流流式計算引擎Spark和Flink開發的，用戶能夠自行選擇但願的計算引擎。Flink還支持CEP操做，因此Wormhole也支持CEP規則配置。
• Moonbox，異構系統混算服務，假設數據由於各類緣由存放在各個不一樣的地方，但又但願可以混算這些數據，你能夠當Moonbox是一個「虛擬數據庫」來使用。好比A表在Oracle裏，B表在MongoDB裏，C表在ES裏，一個完整的SQL發給Moonbox，會自動將結果混算出來並返回結果數據；同時，Moonbox還能有效利用各個存儲的計算優點，將更多算子下推計算，以總體提升運算性能。
• Davinci，可視化平臺，通常可視化平臺具有的功能Davinci基本都具有，而且支持豐富的可視化應用和系統整合能力，力圖解決「大數據最後十千米問題」。

這些中間件作出來後帶來了什麼效果？好比某條業務線2-3個數據相關人員，對業務很是瞭解，但沒有大數據技術開發背景，通過一兩週的培訓，就能夠自助地、快速地完成各類實時數倉、實時報表、實時應用的端到端項目。這在之前是不可想象的，之前要作一個實時項目，須要有大數據技術開發背景的團隊來支持，而如今哪怕不是IT背景的人，培訓一下就能夠作這個事情了，這就是敏捷中間件工具帶來的效率提高和成本減低。

接下來更深刻地介紹一下Wormhole。

除了上面說到的配置化和SQL化開發流式應用這些好處，從內部技術實現角度來看，不少流式開發要注意的典型問題也都被中間件屏蔽了，這些對用戶來講是透明支持的。

• 冪等Sink，流上的增量數據不保證強有序，可是落Sink的時候要作到最終一致性。Wormhole已經內置了這個處理邏輯，用戶只管寫好流上邏輯SQL就能夠 。
• HDFS小文件，作大數據你們都知道這個問題，Wormhole也內置瞭解決方案。
• 多Flow支持，這是咱們首創的功能，若是作過Spark開發，會知道寫一個Spark程序，它起來後會一直佔固定內存跑一個做業，而咱們認爲Spark streaming應該是物理資源管道，裏面的流上邏輯應該和物理資源解藕，因此咱們設計開發了Flow的概念。Flow的定義就是從哪兒來，到哪兒去，在流上作什麼處理邏輯。解耦帶來的效果是一個Spark streaming物理管道能夠跑多個邏輯Flow，好比說公司有1萬張表，須要同步到2萬個目標端，可能在之前開發須要起兩萬個Spark streaming做業，如今只須要起一個Spark streaming做業就能夠了，好比設置50G內存，在裏面跑2萬個同步Flow工做，至關於作了邏輯層管道支持，這個仍是比較首創的，目前只有咱們在這麼作。
• 動態指令，這個是和運維相關的，我不但願每次改流式處理邏輯的時候都要去重啓這個流，而是可以在線更改、實時生效。
• 業務時間策略，之前Spark streaming是默認基於Process time去作計算的，如今流式引擎很成熟了，引擎內部支持基於Event time計算，但當時Spark streaming尚未支持，因此這塊咱們也作了相應的支持。
• Flow漂移，這個也是運維相關，好比說，咱們起了5個物理的Spark streaming管道，每一個裏面跑10個Flow，某天某個業務線增量數據量激增，某個Stream資源不夠用了，Flow漂移能力就能夠將這個邏輯Flow漂到其餘空閒的Spark streaming物理管道里。這就是在不斷地下降流式處理運維開發的門檻，儘可能作到敏捷化，也就是說我能夠寫一個自動化小程序，定時檢測哪個Spark streaming資源不夠，哪個閒置，而後自動漂一個Flow，這樣能夠作到流式處理的自動化運維。這個課題你們也在探索，批量做業相對很好運維，出了問題自動重啓就能夠了，但流式處理的話就比較難運維了，包括資源大小、重啓Offset等等，咱們在上面都作了不少的工做。因此咱們不是簡單地包裝Spark，而是作了不少深刻的東西的。

關於開源，我之前就任於eBay，eBay出了幾個Apache頂級開源項目，對咱們也是頗有影響的，因此我在宜信設計作這四個工具的時候，一開始就是朝着通用化開源工具的方向進行的。不知道在座你們有沒有據說過這幾個工具，其中Davinci在社區是很火的，不少公司都有在用。

至此，第一階段工做趨於穩定，解決了公司內部不少的問題，開源的幾個工具不光是在公司內部獲得很好的應用，在技術社區也賦能了不少其餘企業。

第二階段是從去年下半年開始的。2017年我參加了杭州雲棲大會，聽過阿里分享的數據中臺，那時「中臺」這個詞尚未流行起來。到了2018年初，我就在思考，認爲數據中臺是當下公司須要作的東西，因而跟CTO建議，他也很支持咱們，以後沒幾個月，數據中臺開始流行起來，因此咱們也至關於遇上風口了。

二、從開源到中臺，關鍵詞是自助化

ABD時代已經作得不錯了，爲何還要再往上作數據中臺？除了前面提到的業務線多、技術選型多、需求多等這些你們都知道的問題以外，從數據管理層面來看，如數據治理、數據資產等都尚未涉及，還有不少切面上的課題也沒有過多考慮。以前由於開源也和一些社區、公司作過線下交流，都表示「大家的開源工具作得很好，可是離咱們業務需求想要的中間感受還差一塊」，其實差的就是一個相似數據中臺的東西。

無論數據中臺如何定義，企業須要一個可以更加直接賦能業務的平臺，所以咱們能夠在業務需求和中間件工具之間再提高一個層次，構建一個一體化、標準化、一站式的自助平臺。

進入第二個時代，敏捷數據中臺ADX。下圖大三角中的藍色三角，數據平臺引擎，從技術層面來說，咱們首先要基於以前的開源工具建設一個好用的自助平臺。可是單單一個好的自助數據平臺，不等同於數據中臺。參考了不少數據中臺文章和定義後，咱們總結出數據中臺還應該包括其餘三塊。

• 一塊是數據資產體系，數據資產是好的數據信息的沉澱和複用，數據中臺必定要將數據資產建設歸入其中，具體方式好比將數據模型方法論固化並下沉系統化，這樣可以更加規範化、標準化地支持沉澱數據資產。
• 有了數據資產，有了好的平臺，但若是壺很大、口很小，數據價值賦能業務帶寬不足，業務部門可能直觀感覺會以爲好像只能看報表，會形成數據賦能能力不夠。因此對接前臺業務不光要能提供報表，還須要可以提供數據產品、數據API、自助分析等，這些均可以更好地賦能業務。
• 有了這些，數據中臺能不能真正運轉起來，還要看公司的流程制度和運營機制。好比我有好的數據資產，卻沒有數據運營機制保障，其餘業務團隊也不會敢用，若是要複用的話我要對其負責，這些都是數據運營的考慮範疇。這些方面都作好以後，纔有可能把數據中臺作好並運做好。

數據中臺的價值體現，在上圖右側也有展現，簡單來講就是「更省更快更準」，或者換個說法是「降本增效提質」，這就是數據中臺的價值本質。

下面這張圖是ADX上一個大體的使用體驗，在自助化數據中臺上，整個數據中臺研發團隊就成爲在其背後的IT團隊了。用戶沒必要和咱們直接打交道，在平臺上能夠自助地申請資源、申請庫表，自助開發、自助運維、查看監控 、設置報警、診斷問題、上線下線等，咱們只要作好平臺設計、研發和運維，這是咱們想達到的效果，更加全面完全的自助化、平民化。

數據中臺是基於模塊化思想建設的，拆分爲衆多子模塊，之間關係是分層和聯合的。好比統一的數據歸集、數據加工、數據模型、監控預警等，這些和其餘公司思路都差很少；右側的數據管理、中臺管理，都是在解決切面的課題；上面部分是貼近業務使用的模塊。模塊不少這裏不一一展開介紹。

值得一提的是，主要核心模塊都不是從零開發，而是基於ABD開源工具整合打通構建的，因此ADX不是推翻了之前的ABD，而是基於ABD更加抽象、更模式化、更面向業務去作上層建築。

如今處於ADX時代，下圖就有所變化了。DataHub整合了數據集成和數據總線層，之前DBus只支持流式歸集和分發，而DataHub無論是流式仍是批量均可以支持。DataWorks之於Wormhole也是如此，至關於ABD功能的擴展外延。

下層的切面課題，也都有相應的模塊對應解決。因此說ADX更加平臺化，不像之前咱們作了幾個比較好的開源工具，而後你們本身DIY組合去解決各類場景項目，如今是基於一站式自助平臺，用戶能夠在其上完成各類各樣的平常數據處理工做。

再提一下DataHub，這個模塊當時作的時候沒以爲怎樣，作出來之後你們都以爲真的很方便，很強大。

下圖從DataHub這個模塊外面站在黑盒的角度去看，能夠想要什麼數據就能獲得什麼數據：好比我想要某張表的天天T+1快照，它會返給我；我想要這張表的任何一個歷史時刻的精確快照，它也能返給我；我想要這張表的實時流數據，它還能返給我。之因此能作到這點，由於咱們把全部表的全量+增量數據都實時落入數據湖，並基於ABD開源工具的整合模式提供各類各樣的所需數據形態，所以從數據層面來看，理論上你想要什麼，DataHub均可以提供。咱們也瞭解了社區一些相似的數據整合方案，大部分都是提供單純工具層面的功能，而沒有內置實時數據湖。DataHub包含了一個數據湖，全公司全部的數據均可以實時地統一地歸集和維護進來，全部的數據使用方，想要什麼就能夠返回什麼，這是很是方便和完全的使用體驗。

第二個時代ADX時代，從開發到上線到如今大規模應用，有一年多的時間，基本能力都已具有。到了第三個時代，咱們更關注數據資產能力和數據治理能力建設，沒有數據資產就談不上數據中臺，而數據治理是確保數據資產有效沉澱和賦能業務的重要保障。

數據治理這個課題，在數據鏈路每一層都有對應可能存在的問題，這些問題有些能夠在系統層面解決，但更多的是依賴於人去治、依賴於組織去治，且依然不容易獲得完美的解決。在這個課題上咱們也在思考和摸索中，如下僅限於探討。

三、數據治理，更依賴人治仍是自治？

下面是咱們的一些思考。「自治」包含兩層含義：自動化治理和自助化治理。

中臺，我理解是能力的下沉，數據處理能力下沉爲加工平臺，數據處理結果下沉爲數據資產。那麼數據治理可否下沉？能夠下沉出什麼東西？

一類是下沉出一些平臺工具，好比元數據管理、數據質量管理，這些能夠作得很通用化、工具化；一類是下沉出一些方法論的系統化，好比阿里的OneData，是一套內部打磨出來的本地化的方法論，落地爲一套系統體系，這套體系和方法論不必定適合於每家公司，但我以爲這個思路每家公司均可以借鑑，打磨適合本企業業務體系的方法論，而後將之系統化，更好地約束和規範化企業內的數據治理管理和數據資產建設。

對於「自動化」數據治理，以上兩類依然不能覆蓋全部問題，好比企業有不少遺留系統、遺留流程，沒法在短期內進行大規模的、統一的改造和遷移，那麼怎樣去管控它、治理它？這依然是一個難題。RPA是一個比較新興的思路，能夠很好地處理遺留系統的問題，這一點和數據治理也許能夠找到很好的交叉點，好比能夠利用流程編排、自動執行的思想，應對一些遺留系統、遺留環境的數據治理問題。

關於「自助化」數據治理，數據治理和數據處理不太同樣，好比流式處理，這是一個業務可以直觀感覺到的剛需，無論什麼業務都會有很強的需求。而數據治理不一樣，從業務角度來看，數據治理雖然就長期而言能夠爲整個企業和業務發展帶來堅實的正面影響，但短時間內可能會限制業務快速發展的速度，因此業務方可能不會有特別大的動力去主動支持和配合數據治理。

有些企業會自上而下強制推行數據治理的管理和實踐，這是須要管理層有這個意識和決心的。咱們公司不太同樣，數據治理須要向業務快速迭代和需求快速變動妥協，沒法作到自上而下強推，但又不能不治，所以咱們考慮能不能自助化地作數據治理。好比業務線能夠創建本身的私有數據資產，若是但願升級成公有數據資產，能夠進行申請審覈，固然這要能夠爲業務線帶來好處，要和KPI綁定，這樣一來，數據資產的運營能力能夠下放，讓你們主動共同參與到數據治理中來，這種柔性數據治理推廣方式可能會更有效，這也是咱們在嘗試的工做。

上圖只是一個粗略的概念架構圖，還不是特別成熟，這也是咱們如今在思考的一些思路。若是能夠把公司全部的元數據歸集起來，造成一個企業級元數據全景圖譜的話，咱們就具有了數據知識；由於咱們有Moonbox，咱們就具有了各類數據操做能力；基於數據知識能力和數據操做能力，就能夠根據數據治理的經驗、規則和現狀的流程梳理，進行數據治理動做的可視化編排，最終造成一個自動化數據治理的體系和框架。

數據治理純靠人的話，不肯定性因素太大，相對來講我更相信工具，相信經過不斷的抽象、下沉和驗證，能夠找到一套更系統化的流程方式和配套工具去作得更好。

以上就是咱們四年來數據中臺建設的三個時代走過的歷程，前路依然任重道遠，還需繼續摸索沉澱，但願能夠和你們多多交流探討，感謝你們的聆聽！