宜信盧山?。簲?shù)據(jù)中臺的“自動化數(shù)據(jù)治理”時代已來

中臺，我理解是能力的下沉，數(shù)據(jù)處理能力下沉為加工平臺，數(shù)據(jù)處理結(jié)果下沉為數(shù)據(jù)資產(chǎn)。那么數(shù)據(jù)治理能否下沉？可以下沉出什么東西？

——宜信數(shù)據(jù)中臺負(fù)責(zé)人 盧山巍

本文來源：宜信數(shù)據(jù)中臺負(fù)責(zé)人盧山巍在億歐產(chǎn)業(yè)互聯(lián)網(wǎng)頻道“數(shù)字中臺創(chuàng)新”沙龍的分享實(shí)錄

原文首發(fā)：億歐

億歐產(chǎn)業(yè)互聯(lián)網(wǎng)頻道10月24日在上海InnoSpace落地“數(shù)字中臺創(chuàng)新”沙龍，活動匯聚了良品鋪?zhàn)与娚碳夹g(shù)中心總監(jiān)羅軼群、愛馳汽車科技信息總監(jiān)杭瑜峰、宜信數(shù)據(jù)中臺負(fù)責(zé)人盧山巍、ThoughtWorks首席咨詢師及極客時間《說透中臺》專欄作者王健、億歐華東負(fù)責(zé)人繆國成、億歐產(chǎn)業(yè)互聯(lián)網(wǎng)頻道副主編黃志磊、億歐產(chǎn)業(yè)互聯(lián)網(wǎng)頻道作者龔晨霞參與分享，就數(shù)字中臺話題展開深度討論。

宜信是一家成立于2006年從事普惠金融和財富管理業(yè)務(wù)的金融科技企業(yè)，2018年基于四大開源平臺和中間件等技術(shù)，開始研發(fā)數(shù)據(jù)中臺，并在宜信內(nèi)部推廣使用。目前，宜信的中臺部門一共分為兩大板塊：數(shù)據(jù)中臺和AI中臺。  

以下是盧山巍演講觀點(diǎn)梳理：

1、宜信數(shù)據(jù)中臺指導(dǎo)思維：統(tǒng)一建設(shè)、敏捷開發(fā)

2、從開源到中臺，關(guān)鍵詞是自助化

3、數(shù)據(jù)治理，更依賴人治還是自治？  

以下是演講速記實(shí)錄，經(jīng)億歐產(chǎn)業(yè)互聯(lián)網(wǎng)頻道整理，供行業(yè)人士參考。

大家下午好，我叫盧山巍，來自宜信。剛才聽羅總高屋建瓴地介紹了中臺的概念和應(yīng)用，受益匪淺。我的分享會不太一樣：第一，我有一個限定詞是“數(shù)據(jù)”。羅總的分享對業(yè)務(wù)中臺、組織中臺、技術(shù)中臺都有探討，而我本身是做數(shù)據(jù)的，所以我只介紹數(shù)據(jù)中臺。第二，我個人是從純粹技術(shù)路線走上來的，分享的內(nèi)容會比較具體而微 。

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

2015年加入宜信之前，我在上海張江的eBay研發(fā)中心工作，當(dāng)時的主要方向是大數(shù)據(jù)架構(gòu)和研發(fā)，在付費(fèi)廣告組做大數(shù)據(jù)相關(guān)的事情。由于我個人的關(guān)注點(diǎn)比較下沉，對平臺技術(shù)更感興趣，因此總想在技術(shù)領(lǐng)域中做出一些框架和平臺類的東西。  

1、宜信數(shù)據(jù)中臺指導(dǎo)思維：統(tǒng)一建設(shè)、敏捷開發(fā)

2015年宜信找到我，說公司內(nèi)部沒有數(shù)據(jù)平臺，希望我能夠去帶領(lǐng)建設(shè)數(shù)據(jù)平臺，于是我加入了宜信。

其實(shí)說“公司沒有數(shù)據(jù)平臺”是不準(zhǔn)確的，更準(zhǔn)確地說應(yīng)該是“公司沒有統(tǒng)一的數(shù)據(jù)平臺”，因?yàn)楣竞芏鄻I(yè)務(wù)線都有自己所謂的數(shù)據(jù)平臺，有的做得好一點(diǎn)，有的是純粹的定制化，談不上平臺化，因?yàn)楣疽?guī)模很大，很多是自下而上地建設(shè)，不像銀行是自上而下去推動做這個事情。當(dāng)時也沒有數(shù)據(jù)中臺這個概念，只是說要做一個好的數(shù)據(jù)平臺，感覺有點(diǎn)無從下手，很有挑戰(zhàn)，因此著手做了很多公司內(nèi)部的調(diào)研和訪談，用幾張圖來展現(xiàn)當(dāng)時的現(xiàn)狀。

左上角的圖表達(dá)的是業(yè)務(wù)的豎井，從前臺到業(yè)務(wù)開發(fā)端，到數(shù)據(jù)端，甚至有的數(shù)據(jù)庫都沒打通。通常好的數(shù)據(jù)中臺，要有好的業(yè)務(wù)中臺配合，在業(yè)務(wù)豎井嚴(yán)重的現(xiàn)狀下，想在數(shù)據(jù)層融合打通是挺難的事。

左下角表達(dá)的是在2015年的時候，很多企業(yè)都面臨的兩個慢的問題，即：時效慢、實(shí)施慢。

一方面，那時比較主流的還是T+1批處理，很多企業(yè)沒有完善的流式處理平臺，不像現(xiàn)在有很多成熟的選擇。一般來講都是只能滿足T+1時效的數(shù)據(jù)需求。

另一方面，因?yàn)闆]有很好的自助平臺給大家使用，就變成了需求提給特定的BI團(tuán)隊，BI團(tuán)隊接了這個需求，需求多了忙不過來，就開始排期，可能要1-2個月甚至以上的時間才能響應(yīng)和處理這個需求。

有的業(yè)務(wù)部門比較有實(shí)力，擁有不少大數(shù)據(jù)工程師，使用了很多技術(shù)選型，比如MongoDB、ES、HBase、Cassandra、Phoenix、Presto、Spark、Hive、Impala等等各種技術(shù)選型都有，沒有統(tǒng)一的技術(shù)選型標(biāo)準(zhǔn)。而公司需求又是多樣化的，像上圖右邊的自助查詢、360全景分析、實(shí)時處理、多維分析、數(shù)據(jù)湖等等，使得大數(shù)據(jù)架構(gòu)變得越來越復(fù)雜和臃腫，越來越難以建設(shè)和維護(hù)，再加上圖下方的數(shù)據(jù)治理、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全等切面課題，當(dāng)時面臨的就是這樣一個比較復(fù)雜的現(xiàn)狀。

在這樣的現(xiàn)狀之下思考整個問題，找尋解決方案。本身我個人是比較倡導(dǎo)敏捷開發(fā)思想的，敏捷開發(fā)更多是在業(yè)務(wù)開發(fā)方面的實(shí)踐經(jīng)驗(yàn)，大數(shù)據(jù)比較笨重，怎么才能讓大象奔跑起來？我認(rèn)為要用敏捷化思想去建設(shè)數(shù)據(jù)平臺。經(jīng)過調(diào)研和思考，形成了一系列大數(shù)據(jù)敏捷思想框架、實(shí)踐和方法論，更重要的是我們要落地一些中間件去驅(qū)動敏捷化實(shí)踐。

接下來我們先后自研了四個中間件平臺：DBus、Wormhole、Moonbox、Davinci。既然用了這么多的技術(shù)選型，又很難快速將它們統(tǒng)一到一套技術(shù)選型，還要能夠去統(tǒng)一收口管控關(guān)鍵節(jié)點(diǎn)，最好的辦法就是利用中間件思想去適配已有的選型，然后再去簡化整個架構(gòu)。

下面這個圖就比較技術(shù)視角了，展示了整個數(shù)據(jù)處理的鏈路，從左到右，分為數(shù)據(jù)源層、數(shù)據(jù)集成層、數(shù)據(jù)總線層、數(shù)據(jù)處理層、數(shù)據(jù)存儲層、數(shù)據(jù)服務(wù)層和數(shù)據(jù)應(yīng)用層 。其中數(shù)據(jù)源層，天然有各種各樣的選型，這是業(yè)務(wù)需要；數(shù)據(jù)存儲層，出于不同目的有了眾多技術(shù)選型，這個也沒法很快統(tǒng)一，而且本身也很難找到一個大數(shù)據(jù)存儲選型，能夠解決所有的存儲問題和計算問題，所以不得不面對多個存儲和計算的整合問題。

在應(yīng)用端，需求場景驅(qū)動也是很難整合統(tǒng)一的。能夠整合收口的是數(shù)據(jù)集成層、數(shù)據(jù)總線層、數(shù)據(jù)處理層和數(shù)據(jù)服務(wù)層 。整個數(shù)據(jù)鏈路梳理完之后，是一種“開放+統(tǒng)一”的架構(gòu)，有些層面是開放包容的，而有些層面是要統(tǒng)一收口管控的。

當(dāng)然，上圖灰色的切面課題也是應(yīng)該關(guān)注和支持的，因?yàn)槲覀儺?dāng)時的策略是做四個中間件工具DBus、Wormhole、Moonbox、Davinci，因此沒有太關(guān)注這些切面課題 。

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

• DBus，能夠?qū)崟r將數(shù)據(jù)抽取出來，可以對接多個數(shù)據(jù)庫和日志，既可以實(shí)時抽取增量數(shù)據(jù)，也支持抽取全量數(shù)據(jù)，并與增量數(shù)據(jù)保持一致性id體系，以支持后續(xù)冪等入庫。
• Wormhole，負(fù)責(zé)流式作業(yè)開發(fā)和管理，可以不用編寫代碼，只通過配置和SQL方式即可支持實(shí)時同步和流上處理邏輯。這也體現(xiàn)出敏捷性：一是中間件統(tǒng)一了通用技術(shù)實(shí)現(xiàn)，不用重復(fù)開發(fā)；二是不斷地降低數(shù)據(jù)項(xiàng)目實(shí)施成本，實(shí)施人員盡量關(guān)注業(yè)務(wù)邏輯本身，簡單培訓(xùn)即可自助完成項(xiàng)目，這些都是敏捷思想的體現(xiàn)。舉個例子，從使用體驗(yàn)上看，比如增量數(shù)據(jù)從Oracle實(shí)時出來，希望實(shí)時寫到MySQL里去，只要簡單配置一下就可以了，如果還需要有一些實(shí)時處理邏輯，比如流上增量數(shù)據(jù)去Lookup外面的Redis，只要寫一個SQL即可 。另外，因?yàn)槲覀冏鲋虚g件而不重造引擎，所以Wormhole是基于主流流式計算引擎Spark和Flink開發(fā)的，用戶可以自行選擇希望的計算引擎。Flink還支持CEP操作，所以Wormhole也支持CEP規(guī)則配置。
• Moonbox，異構(gòu)系統(tǒng)混算服務(wù)，假設(shè)數(shù)據(jù)因?yàn)楦鞣N原因存放在各個不同的地方，但又希望能夠混算這些數(shù)據(jù)，你可以當(dāng)Moonbox是一個“虛擬數(shù)據(jù)庫”來使用。比如A表在Oracle里，B表在MongoDB里，C表在ES里，一個完整的SQL發(fā)給Moonbox，會自動將結(jié)果混算出來并返回結(jié)果數(shù)據(jù)；同時，Moonbox還能有效利用各個存儲的計算優(yōu)勢，將更多算子下推計算，以整體提高運(yùn)算性能。
• Davinci，可視化平臺，一般可視化平臺具備的功能Davinci基本都具備，并且支持豐富的可視化應(yīng)用和系統(tǒng)整合能力，力圖解決“大數(shù)據(jù)最后十公里問題”。

這些中間件做出來后帶來了什么效果？比如某條業(yè)務(wù)線2-3個數(shù)據(jù)相關(guān)人員，對業(yè)務(wù)非常了解，但沒有大數(shù)據(jù)技術(shù)開發(fā)背景，經(jīng)過一兩周的培訓(xùn)，就可以自助地、快速地完成各種實(shí)時數(shù)倉、實(shí)時報表、實(shí)時應(yīng)用的端到端項(xiàng)目。這在以前是不可想象的，以前要做一個實(shí)時項(xiàng)目，需要有大數(shù)據(jù)技術(shù)開發(fā)背景的團(tuán)隊來支持，而現(xiàn)在哪怕不是IT背景的人，培訓(xùn)一下就可以做這個事情了，這就是敏捷中間件工具帶來的效率提升和成本減低。  

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

除了上面說到的配置化和SQL化開發(fā)流式應(yīng)用這些好處，從內(nèi)部技術(shù)實(shí)現(xiàn)角度來看，很多流式開發(fā)要注意的典型問題也都被中間件屏蔽了，這些對用戶來說是透明支持的。  

• 冪等Sink，流上的增量數(shù)據(jù)不保證強(qiáng)有序，但是落Sink的時候要做到最終一致性。Wormhole已經(jīng)內(nèi)置了這個處理邏輯，用戶只管寫好流上邏輯SQL就可以 。
• HDFS小文件，做大數(shù)據(jù)大家都知道這個問題，Wormhole也內(nèi)置了解決方案。
• 多Flow支持，這是我們獨(dú)創(chuàng)的功能，如果做過Spark開發(fā)，會知道寫一個Spark程序，它起來后會一直占固定內(nèi)存跑一個作業(yè)，而我們認(rèn)為Spark streaming應(yīng)該是物理資源管道，里面的流上邏輯應(yīng)該和物理資源解藕，所以我們設(shè)計開發(fā)了Flow的概念。Flow的定義就是從哪兒來，到哪兒去，在流上做什么處理邏輯。解耦帶來的效果是一個Spark streaming物理管道可以跑多個邏輯Flow，比如說公司有1萬張表，需要同步到2萬個目標(biāo)端，可能在以前開發(fā)需要起兩萬個Spark streaming作業(yè)，現(xiàn)在只需要起一個Spark streaming作業(yè)就可以了，比如設(shè)置50G內(nèi)存，在里面跑2萬個同步Flow工作，相當(dāng)于做了邏輯層管道支持，這個還是比較獨(dú)創(chuàng)的，目前只有我們在這么做。
• 動態(tài)指令，這個是和運(yùn)維相關(guān)的，我不希望每次改流式處理邏輯的時候都要去重啟這個流，而是能夠在線更改、實(shí)時生效。
• 業(yè)務(wù)時間策略，以前Spark streaming是默認(rèn)基于Process time去做計算的，現(xiàn)在流式引擎很成熟了，引擎內(nèi)部支持基于Event time計算，但當(dāng)時Spark streaming還沒有支持，所以這塊我們也做了相應(yīng)的支持。
• Flow漂移，這個也是運(yùn)維相關(guān)，比如說，我們起了5個物理的Spark streaming管道，每個里面跑10個Flow，某天某個業(yè)務(wù)線增量數(shù)據(jù)量激增，某個Stream資源不夠用了，F(xiàn)low漂移能力就可以將這個邏輯Flow漂到其他空閑的Spark streaming物理管道里。這就是在不斷地降低流式處理運(yùn)維開發(fā)的門檻，盡量做到敏捷化，也就是說我可以寫一個自動化小程序，定時檢測哪一個Spark streaming資源不夠，哪一個閑置，然后自動漂一個Flow，這樣可以做到流式處理的自動化運(yùn)維。這個課題大家也在探索，批量作業(yè)相對很好運(yùn)維，出了問題自動重啟就可以了，但流式處理的話就比較難運(yùn)維了，包括資源大小、重啟Offset等等，我們在上面都做了很多的工作。所以我們不是簡單地包裝Spark，而是做了很多深入的東西的。

關(guān)于開源，我以前就職于eBay，eBay出了幾個Apache頂級開源項(xiàng)目，對我們也是很有影響的，所以我在宜信設(shè)計做這四個工具的時候，一開始就是朝著通用化開源工具的方向進(jìn)行的。不知道在座大家有沒有聽說過這幾個工具，其中Davinci在社區(qū)是很火的，很多公司都有在用。

至此，第一階段工作趨于穩(wěn)定，解決了公司內(nèi)部很多的問題，開源的幾個工具不光是在公司內(nèi)部得到很好的應(yīng)用，在技術(shù)社區(qū)也賦能了很多其他企業(yè)。

第二階段是從去年下半年開始的。2017年我參加了杭州云棲大會，聽過阿里分享的數(shù)據(jù)中臺，那時“中臺”這個詞還沒有流行起來。到了2018年初，我就在思考，認(rèn)為數(shù)據(jù)中臺是當(dāng)下公司需要做的東西，于是跟CTO建議，他也很支持我們，之后沒幾個月，數(shù)據(jù)中臺開始流行起來，所以我們也相當(dāng)于趕上風(fēng)口了。

2、從開源到中臺，關(guān)鍵詞是自助化

ABD時代已經(jīng)做得不錯了，為什么還要再往上做數(shù)據(jù)中臺？除了前面提到的業(yè)務(wù)線多、技術(shù)選型多、需求多等這些大家都知道的問題之外，從數(shù)據(jù)管理層面來看，如數(shù)據(jù)治理、數(shù)據(jù)資產(chǎn)等都還沒有涉及，還有很多切面上的課題也沒有過多考慮。之前因?yàn)殚_源也和一些社區(qū)、公司做過線下交流，都表示“你們的開源工具做得很好，但是離我們業(yè)務(wù)需求想要的中間感覺還差一塊”，其實(shí)差的就是一個類似數(shù)據(jù)中臺的東西。

不管數(shù)據(jù)中臺如何定義，企業(yè)需要一個能夠更加直接賦能業(yè)務(wù)的平臺，因此我們可以在業(yè)務(wù)需求和中間件工具之間再提升一個層次，構(gòu)建一個一體化、標(biāo)準(zhǔn)化、一站式的自助平臺。

進(jìn)入第二個時代，敏捷數(shù)據(jù)中臺ADX。下圖大三角中的藍(lán)色三角，數(shù)據(jù)平臺引擎，從技術(shù)層面來講，我們首先要基于之前的開源工具建設(shè)一個好用的自助平臺。但是單單一個好的自助數(shù)據(jù)平臺，不等同于數(shù)據(jù)中臺。參考了很多數(shù)據(jù)中臺文章和定義后，我們總結(jié)出數(shù)據(jù)中臺還應(yīng)該包括其他三塊。  

• 一塊是數(shù)據(jù)資產(chǎn)體系，數(shù)據(jù)資產(chǎn)是好的數(shù)據(jù)信息的沉淀和復(fù)用，數(shù)據(jù)中臺一定要將數(shù)據(jù)資產(chǎn)建設(shè)納入其中，具體方式比如將數(shù)據(jù)模型方法論固化并下沉系統(tǒng)化，這樣能夠更加規(guī)范化、標(biāo)準(zhǔn)化地支持沉淀數(shù)據(jù)資產(chǎn)。
• 有了數(shù)據(jù)資產(chǎn)，有了好的平臺，但如果壺很大、口很小，數(shù)據(jù)價值賦能業(yè)務(wù)帶寬不足，業(yè)務(wù)部門可能直觀感受會覺得好像只能看報表，會造成數(shù)據(jù)賦能能力不夠。所以對接前臺業(yè)務(wù)不光要能提供報表，還需要能夠提供數(shù)據(jù)產(chǎn)品、數(shù)據(jù)API、自助分析等，這些都可以更好地賦能業(yè)務(wù)。
• 有了這些，數(shù)據(jù)中臺能不能真正運(yùn)轉(zhuǎn)起來，還要看公司的流程制度和運(yùn)營機(jī)制。比如我有好的數(shù)據(jù)資產(chǎn)，卻沒有數(shù)據(jù)運(yùn)營機(jī)制保障，其他業(yè)務(wù)團(tuán)隊也不會敢用，如果要復(fù)用的話我要對其負(fù)責(zé)，這些都是數(shù)據(jù)運(yùn)營的考慮范疇。這些方面都做好之后，才有可能把數(shù)據(jù)中臺做好并運(yùn)作好。

數(shù)據(jù)中臺的價值體現(xiàn)，在上圖右側(cè)也有展示，簡單來說就是“更省更快更準(zhǔn)”，或者換個說法是“降本增效提質(zhì)”，這就是數(shù)據(jù)中臺的價值本質(zhì)。

下面這張圖是ADX上一個大致的使用體驗(yàn)，在自助化數(shù)據(jù)中臺上，整個數(shù)據(jù)中臺研發(fā)團(tuán)隊就成為在其背后的IT團(tuán)隊了。用戶不必和我們直接打交道，在平臺上可以自助地申請資源、申請庫表，自助開發(fā)、自助運(yùn)維、查看監(jiān)控 、設(shè)置報警、診斷問題、上線下線等，我們只要做好平臺設(shè)計、研發(fā)和運(yùn)維，這是我們想達(dá)到的效果，更加全面徹底的自助化、平民化。

數(shù)據(jù)中臺是基于模塊化思想建設(shè)的，拆分為眾多子模塊，之間關(guān)系是分層和聯(lián)合的。比如統(tǒng)一的數(shù)據(jù)歸集、數(shù)據(jù)加工、數(shù)據(jù)模型、監(jiān)控預(yù)警等，這些和其他公司思路都差不多；右側(cè)的數(shù)據(jù)管理、中臺管理，都是在解決切面的課題；上面部分是貼近業(yè)務(wù)使用的模塊。模塊很多這里不一一展開介紹。

值得一提的是，主要核心模塊都不是從零開發(fā)，而是基于ABD開源工具整合打通構(gòu)建的，所以ADX不是推翻了以前的ABD，而是基于ABD更加抽象、更模式化、更面向業(yè)務(wù)去做上層建筑。

現(xiàn)在處于ADX時代，下圖就有所變化了。DataHub整合了數(shù)據(jù)集成和數(shù)據(jù)總線層，以前DBus只支持流式歸集和分發(fā)，而DataHub不管是流式還是批量都可以支持。DataWorks之于Wormhole也是如此，相當(dāng)于ABD功能的擴(kuò)展外延。

下層的切面課題，也都有相應(yīng)的模塊對應(yīng)解決。所以說ADX更加平臺化，不像以前我們做了幾個比較好的開源工具，然后大家自己DIY組合去解決各種場景項(xiàng)目，現(xiàn)在是基于一站式自助平臺，用戶可以在其上完成各種各樣的日常數(shù)據(jù)處理工作。

再提一下DataHub，這個模塊當(dāng)時做的時候沒覺得怎樣，做出來以后大家都覺得真的很方便，很強(qiáng)大。

下圖從DataHub這個模塊外面站在黑盒的角度去看，可以想要什么數(shù)據(jù)就能得到什么數(shù)據(jù)：比如我想要某張表的每天T+1快照，它會返給我；我想要這張表的任何一個歷史時刻的精確快照，它也能返給我；我想要這張表的實(shí)時流數(shù)據(jù)，它還能返給我。之所以能做到這點(diǎn)，因?yàn)槲覀儼阉斜淼娜?增量數(shù)據(jù)都實(shí)時落入數(shù)據(jù)湖，并基于ABD開源工具的整合模式提供各種各樣的所需數(shù)據(jù)形態(tài)，因此從數(shù)據(jù)層面來看，理論上你想要什么，DataHub都可以提供。我們也了解了社區(qū)一些類似的數(shù)據(jù)整合方案，大部分都是提供單純工具層面的功能，而沒有內(nèi)置實(shí)時數(shù)據(jù)湖。DataHub包含了一個數(shù)據(jù)湖，全公司所有的數(shù)據(jù)都可以實(shí)時地統(tǒng)一地歸集和維護(hù)進(jìn)來，所有的數(shù)據(jù)使用方，想要什么就可以返回什么，這是非常方便和徹底的使用體驗(yàn)。

第二個時代ADX時代，從開發(fā)到上線到現(xiàn)在大規(guī)模應(yīng)用，有一年多的時間，基本能力都已具備。到了第三個時代，我們更關(guān)注數(shù)據(jù)資產(chǎn)能力和數(shù)據(jù)治理能力建設(shè)，沒有數(shù)據(jù)資產(chǎn)就談不上數(shù)據(jù)中臺，而數(shù)據(jù)治理是確保數(shù)據(jù)資產(chǎn)有效沉淀和賦能業(yè)務(wù)的重要保障。

數(shù)據(jù)治理這個課題，在數(shù)據(jù)鏈路每一層都有對應(yīng)可能存在的問題，這些問題有些可以在系統(tǒng)層面解決，但更多的是依賴于人去治、依賴于組織去治，且依然不容易得到完美的解決。在這個課題上我們也在思考和摸索中，以下僅限于探討。

3、數(shù)據(jù)治理，更依賴人治還是自治？

下面是我們的一些思考?！白灾巍卑瑑蓪雍x：自動化治理和自助化治理。

中臺，我理解是能力的下沉，數(shù)據(jù)處理能力下沉為加工平臺，數(shù)據(jù)處理結(jié)果下沉為數(shù)據(jù)資產(chǎn)。那么數(shù)據(jù)治理能否下沉？可以下沉出什么東西？

一類是下沉出一些平臺工具，比如元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量管理，這些可以做得很通用化、工具化；一類是下沉出一些方法論的系統(tǒng)化，比如阿里的OneData，是一套內(nèi)部打磨出來的本地化的方法論，落地為一套系統(tǒng)體系，這套體系和方法論不一定適合于每家公司，但我覺得這個思路每家公司都可以借鑒，打磨適合本企業(yè)業(yè)務(wù)體系的方法論，然后將之系統(tǒng)化，更好地約束和規(guī)范化企業(yè)內(nèi)的數(shù)據(jù)治理管理和數(shù)據(jù)資產(chǎn)建設(shè)。

對于“自動化”數(shù)據(jù)治理，以上兩類依然不能覆蓋所有問題，比如企業(yè)有很多遺留系統(tǒng)、遺留流程，無法在短時間內(nèi)進(jìn)行大規(guī)模的、統(tǒng)一的改造和遷移，那么怎樣去管控它、治理它？這依然是一個難題。RPA是一個比較新興的思路，可以很好地處理遺留系統(tǒng)的問題，這一點(diǎn)和數(shù)據(jù)治理也許可以找到很好的交叉點(diǎn)，比如可以利用流程編排、自動執(zhí)行的思想，應(yīng)對一些遺留系統(tǒng)、遺留環(huán)境的數(shù)據(jù)治理問題。

關(guān)于“自助化”數(shù)據(jù)治理，數(shù)據(jù)治理和數(shù)據(jù)處理不太一樣，比如流式處理，這是一個業(yè)務(wù)能夠直觀感受到的剛需，不管什么業(yè)務(wù)都會有很強(qiáng)的需求。而數(shù)據(jù)治理不同，從業(yè)務(wù)角度來看，數(shù)據(jù)治理雖然就長期而言可以為整個企業(yè)和業(yè)務(wù)發(fā)展帶來堅實(shí)的正面影響，但短期內(nèi)可能會限制業(yè)務(wù)快速發(fā)展的速度，所以業(yè)務(wù)方可能不會有特別大的動力去主動支持和配合數(shù)據(jù)治理。

有些企業(yè)會自上而下強(qiáng)制推行數(shù)據(jù)治理的管理和實(shí)踐，這是需要管理層有這個意識和決心的。我們公司不太一樣，數(shù)據(jù)治理需要向業(yè)務(wù)快速迭代和需求快速變更妥協(xié)，無法做到自上而下強(qiáng)推，但又不能不治，因此我們考慮能不能自助化地做數(shù)據(jù)治理。比如業(yè)務(wù)線可以建立自己的私有數(shù)據(jù)資產(chǎn)，如果希望升級成公有數(shù)據(jù)資產(chǎn)，可以進(jìn)行申請審核，當(dāng)然這要可以為業(yè)務(wù)線帶來好處，要和KPI綁定，這樣一來，數(shù)據(jù)資產(chǎn)的運(yùn)營能力可以下放，讓大家主動共同參與到數(shù)據(jù)治理中來，這種柔性數(shù)據(jù)治理推廣方式可能會更有效，這也是我們在嘗試的工作。

上圖只是一個粗略的概念架構(gòu)圖，還不是特別成熟，這也是我們現(xiàn)在在思考的一些思路。如果可以把公司所有的元數(shù)據(jù)歸集起來，形成一個企業(yè)級元數(shù)據(jù)全景圖譜的話，我們就具備了數(shù)據(jù)知識；因?yàn)槲覀冇蠱oonbox，我們就具備了各種數(shù)據(jù)操作能力；基于數(shù)據(jù)知識能力和數(shù)據(jù)操作能力，就可以根據(jù)數(shù)據(jù)治理的經(jīng)驗(yàn)、規(guī)則和現(xiàn)狀的流程梳理，進(jìn)行數(shù)據(jù)治理動作的可視化編排，最終形成一個自動化數(shù)據(jù)治理的體系和框架。

數(shù)據(jù)治理純靠人的話，不確定性因素太大，相對來說我更相信工具，相信通過不斷的抽象、下沉和驗(yàn)證，可以找到一套更系統(tǒng)化的流程方式和配套工具去做得更好。

以上就是我們四年來數(shù)據(jù)中臺建設(shè)的三個時代走過的歷程，前路依然任重道遠(yuǎn)，還需繼續(xù)摸索沉淀，希望可以和大家多多交流探討，感謝大家的聆聽！