三論數據中台之一論:數據中台本質剖析
- 2020 年 2 月 19 日
- 筆記
導語 | 數據中台被譽為大數據的下一站,成為了人們談論的焦點,2019年也被稱為數據中台元年。但是數據中台是什麼?它和數據倉庫、商業智慧、大數據平台有什麼區別?它的主要功能是什麼?本文是對TVP史凱老師的直播演講整理,為大家剖析數據中台的願景和本質。「TVP思享」專欄,凝結大咖思考,匯聚專家分享,收穫全新思想,歡迎長期關注。(編輯:雲加社區 濤濤)
作者簡介:史凱,花名凱哥,騰訊雲最具價值專家TVP,ThoughtWorks數據智慧業務總經理。投身於企業數字化轉型工作近20年。2000年初,在IBM 研發企業級中間件,接著加入埃森哲,為大型企業提供資訊化架構規劃,設計,ERP,雲平台,數據倉庫構建等技術諮詢實施服務,隨後在EMC負責企業應用轉型業務,為企業提供雲遷移,應用現代化服務。現在專註於企業智慧化轉型領域,是數據驅動的數字化轉型的行業佈道者,數據中台的推廣者,精益數據創新體系的創始人,2019年榮獲全球Data IQ 100人的數據賦能者稱號,創業邦卓越生態聚合賦能官TOP 5。2019年度數字化轉型專家獎。打造了行業第一個數據創新的數字化轉型卡牌和工作坊。創建了精益數據創新方法論體系構建數據驅動的智慧企業,並在多個企業驗證成功,正在向中國外推廣。
一、數據中台現象及剖析
去年3月份我寫了一篇關於數據中台的文章,得到了10萬+的瀏覽量。我當時非常意外,怎麼這樣一篇1萬多字,還不是特別好理解的技術類的文章能得到10萬+呢?這個現象是不是意味著,數據中台熱起來了呢?
作為一個數據工作者,我從不靠直覺做判斷,我們儘可能的利用數據作判斷。我第一時間註冊了「數據中台」這個百度指數,然後觀察它的搜索熱度。
因為,不像過去所有的IT概念、雲計算、大數據等全是來源於國外,中台是中國人自己發明的概念。所以我們通過百度的搜索指數,也能夠看到數據平台在行業里的熱度。
下圖展示的是:數據中台和數字化轉型的百度搜索指數的熱度對比,能夠發現數據中台搜索熱度在2019年初,正好是3月份的樣子,已經超越了數字化轉型的熱度,並且在發生啟動前達到頂峰。

再來看跟數據中台相關的商業智慧、數據倉庫兩個概念。
在過去,數據倉庫、商業智慧都是非常火熱的概念,尤其是數據倉庫。
而在今年數據倉庫有了下滑的趨勢,數據中台卻到達了頂峰。
現在數據中台已經超越了數據倉庫加商業智慧兩者的熱度總和,這說明現在行業裡面,特別是甲方的企業需求端,對於數據中台越來越關注。
市場是客觀的,沒有無故無緣無故的愛。
數據中台的火爆一定不僅僅是廠商在炒概念,它也一定承載了很多行業、甲方、想做數字化轉型的企業,對於數據中台的期待。
因為原來的很多需求滿足不了,所以才需要一個新的概念來承載這些期待, 數據中台因運而生,那麼數據中台背後承載的是什麼呢?
我在2019年3月份就發起了一個數據中台行業調研,收到了超過460份有效問卷,對調研者為什麼關注數據中台做了詞頻的分析,如下圖所示:

我們會發現,有四個期待是排名最靠前的:業務,數據服務,價值和快速。解讀如下:
1. 企業為什麼對數據中台概念這麼感興趣?
(1)企業希望數據距離業務更近
以前的數據部門離業務部門有距離,業務部門不能直接使用數據,也不能直接地在數據當中發現價值,業務迫切希望距離數據更近,這是最大的一個需求。
(2)企業希望數據中台能夠提供數據服務
過去數據部門提供的都是可視化輔助決策類的服務,而企業希望數據中台能夠提供高響應更實時的數據服務。
(3)企業希望數據中台能直接提供業務價值
如何能夠讓數據直接產生業務價值,是企業非常關心的問題。
(4)企業希望數據中台能夠快速開發數據服務
如何能夠讓數據的開發,利用更快速?
當然,還有其他的期待:
(5)企業希望數據中台和數據能夠圍繞業務場景來開展工作
(6)提供統一數據
還有諸如:賦能業務更智慧、構建統一數據資產、打通數據孤島等企業方面的迫切需求。
總的來說,很明顯能看到企業對於數據中台這個概念承載的重大期待。
那為什麼數據倉庫、數據平台、商業智慧就解決不了這些問題呢?
2. 數據中台、數據倉庫、數據平台與商業智慧的區別
我在2008年起就負責過一些SAP BW/Cognos/Microstrategy類數據倉庫的項目,對傳統的主數據管理,數據治理很熟悉基於這些經驗,總結了數據倉庫、數據中台和商業智慧之間的區別,還用一個《數據中台鬧革命》的圖片故事做過描述。
實際上它們之間根本不在一個維度上。數據中台是個概念,而數據倉庫是一種具體的技術領域,它也已經有對應的標準化的產品。商業智慧一方面也是一個概念,另一方面它也有對應的產品。
傳統的商業智慧和數據倉庫,是以分析報表為核心。把數據加工成分析報表,提供給決策層去看的。這樣的輔助決策系統,叫商業智慧,它的底層是數據倉庫,因為它要跨域存儲和處理加工企業的歷史數據。
數據平台是企業有了大數據的情況下,希望能夠採集全量的數據,包括採集非結構化數據的大數據平台。
數據倉庫、數據平台都是技術類系統,不能直接服務於業務。而數據中台,企業希望它能直接服務與業務前台。
商業智慧主要的用戶是決策層,它主要提供服務的方法是分析報表、數據湖和數據平台。它的主要的使用對象實際上是數據開發者、數據技術人員和數據分析師。它給這些使用者提供數據集、 Data Set。Database as a Service。
數據中台的用戶則是企業所有的數據用戶,數據消費者,還包括業務系統。
所以總的來說,通過我們前期的調研、溝通、行業里的回饋發現,對於企業的業務用戶來說,企業希望數據中台是能直接服務於業務的平台。它能離具體業務更近,以多種方式為業務、系統提供數據產品。

在這樣的場景下,我們認為數據中台區別於前兩者最大的特點是:它提供的產品是Data API,是數據服務。這是從使用的用戶和它自身的特點出發來看待它們之間的區別。
如果從出發點來說,現在的技術選型、技術工具是很多的,但是最重要的是我們對一件事情的概念上的認知,只要目標和認知清晰了,那麼實現它的辦法是有很多種的。
數據中台和數據平台最大的區別是什麼?我們認為數據中台是離業務更近。業務需要什麼服務?是數據中台和數據服務。
中台的部門或者團隊,最優先考慮的是提供給業務所需要的服務。但數據平台不一樣,數據平台最核心的是數據的存儲、加工。
對於數據平台,是有什麼數據才能幹什麼?所以出發點不一樣,一個是帶有業務視角的,以需求為導向的,另一個是以技術和數據為導向。

還有一點是度量角度不同,數據中台做的好不好,對於企業的價值更多體現在數據服務和的提供數據服務的客戶滿意度。
數據平台看重是數據的品質,它是把數據集提供給用戶去使用,數據品質好和不好是最關鍵的。

上述就是數據中台、數據倉庫、數據平台、商業智慧,它們之間的區別。
在此基礎之上,我們來給數據中台下個定義:
數據中台是為企業所有的數據消費者提供數據服務/產品的平台。
3. 數據中台對企業的價值
在過去做一個應用系統的時候,我們很少會把數據的工作分開。
當需要拿數據去做統計分析的時候,開發人員自己去找數據平台要數據源,然後自己開發。
實際上是應用開發團隊在做數據的事情,而企業是有很多的應用同步在開發的。
這裡帶來的問題就是有三個問題。

第一:效率問題
應用開發的時候可能一張報表需要開發很長時間,因為應用的開發技能和數據的開發技能還是有一些區別的,並不是所有的應用開發人員都會ETL和數據建模。它對數據的模型、數據後台的欄位的含義可能了解不多,開發效率就就比較低。
第二:協作問題
不同應用項目開發的時候,取數邏輯不一致,計算邏輯不一致,取數的版本也不一致。最後兩個應用當中同樣的數據,出來的結果卻不一樣。這不僅僅增加了工作量,而且還帶來了數據不一致的問題。
第三:能力問題
應用開發的人很多,但懂數據開發的人員卻很少。這種情況下,數據中台就可以起到作用。
它幫助原來那些做應用開發的,但是要去做數據開發事情的這些團隊,解決這個問題。讓應用開發專註應用,讓數據開發專註於數據,中間多了一層數據服務的開發。
在中間多一層,讓應用開發團隊都去取,這些數公有的數據服務,實際上有很大的價值。同時它能沉澱企業的數據邏輯,提升企業數據共享的技術能力。
下圖所示的是Gartner的分層架構的理念,和現在講的中台概念實際上是一脈相承的。
在Gartner裡面,它把系統分為三類,一類是最前端的創新型系統,一類是在後端的記錄性的系統。中間這一類是連接創新型系統和技術型系統之間的系統,它把前台叫做敏態,後台叫做穩態。

比如現在企業里的ERP,偏企業後端、生產、財務、HR的這些後端系統,它的變化相對比較小,我們就可以把它叫穩態系統。
但是最前端的,典型的如H5廣告營銷、用戶畫像這樣的一些系統,它是隨著外界市場需求的變化而變化。系統更需要的是快速地應對變化,快速的產生新的功能,我們稱之為敏態系統。
兩者之間的斷層,就是中台的概念。連接前台和後台,讓他們之間的速度更加的協調一致,並且讓後台提供服務,更加的敏捷、快速地為前台做支撐。
對應到數據中台,總的來講可以理解為:加速原數據產生業務價值的服務工廠。
一個客觀的事實是:市場的變化的速度是遠遠快於數據採集的速度的。

這是現在數據品質、數據一致性、實施性和數據集成性的問題的一個根本因素。而數據中台則希望去彌補這樣的一個速度差,加快從數據的採集,到響應市場變化的速度。
二、業界常見數據中台架構
下面重點介紹中國常見的數據中台的架構,從源頭來看,數據中台首先由阿里提出來的,但實際上並不意味著在這個名詞沒有產生之前,企業就沒有數據中台類似的概念。
在2016 ~ 2017年的時候,我們自己的數據資產集成和創新平台,雖然沒有把它叫數據中台,但實際上做的事情是類似的。
阿里的數據中台,最核心的就是三個東西,One Date、One Entity和 One Service。總結為:業務數據化、數據業務化和業務服務化。

因為阿里的業務是由於它企業的性質所決定,它的很多的業務非常相似,基本都是零售型的業務。
這樣的情況下,它的用戶數據,標籤數據、客戶畫像、商品數據、位置數據等這樣的一些數據是廣泛得被它所有的前台業務所使用的,擁有非常強的可復用性。
而阿里又是一個原生的數字化的企業,所以在一開始的時候,它就把所有的業務全部沉澱成數據,這就是阿里整體的數據採集、數據接入和數據資產的管理。
在這個基礎之上,阿里的公共數據中心、One Data體系,構建數據實體,也即業務實體。其中就包括面向業務的,類似於傳統的數據倉庫里的 Data Market 這樣的概念。
然後以中間的加工數據的對象,快速產生它前端的vice service。所有的service提供給它最前台的應用,讓這些應用通過service去調用,保證了數據的一致性。
同時由於它構建了統一的這種電商、零售、用戶為核心的數據體系,前端的應用就能夠從跨域的、全域的數據獲得及時的預測、優化響應等,這就是阿里整個數據中台的體系。
再來看一下菜鳥的數據中台架構,菜鳥雖然和阿里是一個體系,但是它和阿里的中台還是有一些差異的。
菜鳥的數據中台主要分為三個大塊。第1塊是服務層,第2塊是數據層,第3個是數據管理的套件。
實際上它跟阿里的中台一脈相承,最核心的是把數據品質比較高的數據存儲在數據中台,然後通過服務的方式提供給前台的這些運營、業務、商家、貨主和它的生態的公司去使用,這就是菜鳥的數據中台的整個架構。

再來看蘇寧的數據中台。我認為蘇寧是介於互聯網企業和原生企業之間的企業,它的數據中台實際上體現了傳統企業向數字化企業轉型的過程。
它重點強調的是從原來的流程驅動,變成像業務、技術和數據驅動。把原來的IT系統集成,變成通過數據去集成,

下面我們來看看滴滴的數據中台,滴滴的數據中台強調了一個很重要的點,那就是:數據中台,它不是買來的!
滴滴的數據中台和其他的數據中台有所差異,它的數據中台的整個生產價值曲線,跟大部分的企業都不一樣。
滴滴的數據中台跟前面介紹的數據中台,在數據服務、數據資產,底部的數據存儲上是類似的。
但是它更多的會去強調一些阿里的中台里所不突出的東西,比如他強調的數據文化,以智慧數據目錄為核心,以及精益敏捷的數據治理,也非常有借鑒意義。

我們會發現滴滴的數據中台,最大的一個特點,就是價值交付。從場景出發,以業務牽引數據的產生,做到價值交付。

它提到了一個很重要的點,就是利用數據中台去賦能AI。這一點和我們現在所講的數據中台的架構是類似的,因為我們是把機器學習平台放到了廣義的數據中台裡面去了。
當然這種數據中台體系建設也會遇到很多困難:
比如,多場景、全鏈路的複雜訴求。
數據是什麼?數據就是物理世界中的實體在數字化世界裡的投影。
投影就得有個燈照著,但是你站在不同的業務條線,這個燈是不一樣的。
比如說財務,同樣的一個訂單,或者同樣的一個物理世界裡的業務行為,在財務這裡投影出來的 ID和數據,用財務語言描述就是應收應付、憑證等。
但同樣的業務行為在物流那裡,就又不一樣的,描述成收貨單、發貨單等。所以同樣的一個業務行為,在不同的視角下,業務的含義是完全不一樣的。
企業的發展就是要讓這些業務行為更加的分層、更加的細化、更加的多維度。
所以在業務的角度,是希望對用戶的描述、標籤這些維度越多越好!但是這就給數據帶來了多場景的困難?
數據整體的來源不一致,維度不一致,難以採集、管理和加工。
其次,從數據到價值是一個協作的過程,把海量的數據組織在一起協作是是非常複雜的。
總而言之,滴滴提的這兩個數據中台建設的核心難點是非常有價值的。
接下來我們再來看OPPO的數據中台架構,OPPO是一個手機的廠商,但是它現在也構建了海量的數據。
它分成4個層次,第1是統一的工具層,全鏈路接入、治理、開發、消費、數據全鏈路,都通過工具自動化處理
第2,它的核心是在工具體系之上的數據倉庫。在數據倉庫基礎之上構建全域的數據體系,把所有的數據都打通,形成統一的標籤,跟阿里的Data Entity是一致的,然後最頂部是數據產品和數據服務。
在OPPO這個體系裡面,數據倉庫處於非常核心和基礎的位置。

我們最後再來看一個,相對傳統的電信企業的數據中台。
它通過數據中台去打通公共的數據,提供數據模型標準化的數據服務。然後為業務人員和數據的使用方提供個性化的開發工具,滿足一線的數據開發和智慧運營的要求。

所以上面的案例可以看出,實際上前面所講的這些企業,不同行業的,有原生互聯網企業、有傳統數字轉型的企業,也有大型的電信企業,它們的數據中台承載的都是什麼?
實際上都是數據業務化。就是把數據賦予業務的含義,變成一個服務應用到業務當中。
這裡我們回顧一下整個數據從數據到業務化的過程:
最早我們把它叫數據1.0,那個時候少量數據被存儲放到Excel等數據文件裡面,然後慢慢得有了很多跨域的數據被存儲,逐漸形成了跨部門的企業級的數據分析的需求,就有了數據倉庫。
再往後走,企業不僅僅要分析結構化的數據,還要分析非結構化的數據,這種情況下,企業級的大數據平台就出現了。
這種從1.0~3.0都是業務數據化的過程。業務數據化了以後,數據用來幹嘛?最主要的是通過數據去輔助決策,讓人去做決策。

原先支撐數據倉庫大部分都是統計分析類的報表,要麼是產生出報表給領導看,要麼就是有一個數據分析小組團隊,把各種數據彙集在一起做一張報表,再領導彙報。
這裡有幾個特點:
第一:他都是給人看的,給人用的。
人看了這些數據的報表,再由決策者去產生行為。
第二:它的實時性沒有那麼強。它都是需要加工,需要ETL然後分析,處理完了以後,哪怕是實時的報表,也是讓用戶看完了以後,用戶再去思考,從而產生業務行為的。
那麼到了數據中台的數據業務化以後,又有什麼區別?
第一:業務數據化形成最後數據服務,未來去直接驅動業務的行為。
它會嵌入到 oRTO裡面去,原來我們把系統分為oRTP系統、Orap系統,oRTP交易系統採集數據,Orap是把採集來的數據不同的系統匯聚在一起,然後做 ETL 和跨域的分析,產生出報表、歷史的數據分析等,輔助決策。
現在數據中台代表的趨勢是:數據分析出來的結果實時地為交易系統做決策,把Orap分析的結果嵌入到oRTP里去,這是巨大的一個變化。
第二:從原來的只是可視化的供給用戶看變成給系統。
在未來數據和計算會分離,我們把這樣的一個現象,用極限化的方式去思考,再往後走,可能應用是隨用隨構建,用完了就消亡,應用就只負責計算。而所有的數據存儲到數據中台。
應用要做計算,就快速的在Docker里構建出一個鏡像,構建出一個應用,然後快速的從企業的數據中台裡面把數據獲取出來計算。用戶消費完了,應用就釋放了,資源也隨之釋放。
所以對數據的使用的方式和數據給業務產生價值的方式,數據的對象都發生了變化。從原來由人去看數據,變成更多的是由系統、由業務應用去使用數據。
從原來可視化的數據服務的方式,變成這種API的、微服務的直接數據驅動的方式。
這就是我總結下來的從前面各個行業的數據中台的架構中看到的趨勢。
三、數據中台的願景使命
在這樣的一個趨勢下面,數據中台到底承載了數字企業數字化轉型賦予的什麼使命和願景?很簡單,兩句話可以總結。

數據中台承載的是那些傳統企業數字化轉型或者所有企業轉型的一個願景:打造數據驅動的智慧企業。
數據中台承載的使命是通過業務數據化和服務化這樣的方式,把數據的能力賦予給業務人員,讓業務更智慧,賦予給業務系統,讓企業的業務更加智慧。
四、數據中台的本質和六大能力模型
在這樣的願景和使命下,數據中台是什麼?它應該構建什麼樣的能力呢?
1. 數據中台的本質
數據中台是什麼?
數據中台我總結它為數據服務工廠,它是生產加工數據服務的,它為企業提供可復用的數據智慧服務。
這裡的「可復用」指的是,擁有這樣的能力,並不取決於現在有沒有在復用。因為早構建和晚構建,會影響到整體構建的成本和重複建設的周期。

為了方便理解,我們對物理世界裡工廠的概念,把數據中台的概念抽象和分解一下。
任何一個加工製造業的工廠,都會有原材料,對應的就是源數據,有外部的,也有內部的。
然後原材料採購進來要過秤和分析,看看品質是不是合格的,再進入到原材料倉庫啊,對應的是數據服務工廠里的數據湖。
原材料倉庫上面是生產的廠房,對應的是我們的Data Pipeline。廠房裡面有半成品、產品倉庫,對應我們的 Date Market,所有的數據產品和服務都會在一個平台上面進行交易、進行運營。
當然一個工廠,你要不斷的產生新的產品,就要有智慧創新的實驗室,不斷的去驗證,不斷的去探索新的數據產品和新的數據服務。
為了讓工廠減少浪費,運轉的更加的高效。工廠還要有治理,要有辦公室,這就是我們數據治理和服務治理。
這就是一個能夠源源不斷的有創新能力,產生數據服務、數據產品,並且在市場上去銷售,可以度量價值的一個數據服務工廠。

2. 數據中台的六大能力模型
在此基礎之上,我們把數據中台抽象成6大能力,在六大能力基礎之上支撐的就是數據中台的使命和願景:構建數據驅動的智慧企業。

(1)數據資產的規劃和治理
現在很多企業在做數字化轉型,有的企業還不具備基本的資訊化系統,是不是就意味著不需要考慮數據了?或者等數據先有了,把後台建好,再來做中台?
不是這樣的。因為數據是無時無刻不在產生的。即使你這個企業沒有系統,沒有數據倉庫,沒有數據平台,ERP也沒有,全是人工,都不重要。
重要的是:只要業務在生產,或者只要你的業務模式已形成,企業運轉起來,你的數據就會時時產生。
而且用什麼數據也很清晰,區別只是到時候是用人工去處理這些數據,還是用系統去處理這些數據?
所以我們認為數據是不依賴於你的系統是否構建的,它是客觀存在的,只是你沒有通過技術的手段把它存儲,採集下來而已。在這樣的情況下,數據要早於應用規劃。
構建數據中台,首先要有清晰的數據戰略、數據資產的規劃。企業需要清晰的知道自己要的是什麼數據?現在需要什麼數據?未來需要什麼數據?可能會產生什麼數據?數據未來在哪個系統裡面去產生?他們之間的關係是什麼?這個很重要。
這就是你要構建的數據資產目錄,這個目錄是一個邏輯結構,當你清晰的知道了這些結構以後,再去建設你的系統,這樣的話,腦子就會非常清晰,只有這樣才能從根本上去解決數據品質的問題、數據不一致的問題。
所以我們數據全景圖、數據資產目錄、數據的戰略,這才是企業現在數字化轉型的非常重要的第一步。
(2)數據資產的獲取和存儲
數據的全景圖,實際上映射的是你的業務全景圖。在這個基礎之上,構建你的應用,同時採集數據資產。
先採集什麼數據後採集什麼數據?數據之間的關係,採集數據用的工具,這些都是數據平台需要去解決的問題。
(3)數據資產的共享和協作
數據資產獲取和採集以後,就要去讓數據產生新的價值,把數據用起來。
這種情況下,一個非常重要的點是:數據一定要被企業所有的員工,乃至於企業價值鏈上的所有的人共享、開放和協作。
要讓企業的每一個員工都清晰的知道有什麼數據,數據的業務含義是什麼?數據存放在哪裡?只有這樣,才不會出現數據的重複建設。
如何把業務人員的想法變成數據的產品、協作?如何提高數據創新的速度?如何提高數據實驗的速度?
每個企業都需要一個數據資產的協作平台,在這個平台上,業務需求提出人員,數據採集人員、數據開發人員,演算法工程師,數據分析工程師,大家能夠在一個平台自動化的協作,而不需要線下的這種協作。
在同樣的版本的數據基礎上,用共同的溝通語言去交流協作,這樣才能加快企業數據資產開發的速度。
(4)業務價值的探索和發現
業務人員提想法,然後在數據資產的這種探索平台裡面去做實驗,快速的在公有的數據中台的數據集、數據湖的基礎之上,構建不同的數據沙箱。用不同的數據版本,去探索和挖掘業務價值。
(5)數據服務的構建和治理
當你發現一個數據集對業務很有價值,並且通過了驗證以後,就要把它成開發成數據服務,讓數據服務能夠被更多的人使用。
(6)數據服務的度量和運營
有數據開發者,有數據消費者,這樣的話就面臨一個問題,哪些數據有價值?哪些數據服務有價值?
因為計算資源、存儲資源都是有限的,不可能無限制的去開發和存儲,。所以要識別出有價值的服務,讓它被更多的人所使用。讓那些沒有價值的數據服務,沉澱在底層,然後被銷毀和釋放。
這就是一個運營體系,讓數據能夠持續的運營產生價值。只有這6點都具備了,企業才是一個有數據驅動能力的這樣的一個智慧企業。
剛才講的都是廣義的數據中台,下面來看狹義上的數據中台。

其實數據服務就是狹義的數據平台。
如果你想快速的去開發一個為業務去提供價值的數據中台。哪怕沒有數據平台,沒有數據倉庫,但只要搞清楚業務需要什麼數據,然後提供一個數據服務給到它,滿足它的數據的需求,讓業務能夠快速跑起來,這就是數據中台!
只要能夠提供為前台的業務提供快速的數據服務,就是狹義的數據中台。
我們來舉個銀行業的案例。

銀行會有不同的業務部門,每個業務應用裡面都會用到數據。原來就是從數據平台構建Pipeline,然後一個一個的數據集以 Circle或者MongoDB這樣的方式提供給應用開發人員去用,然後應用開發人員會在應用當中直接去調用這些數據表。
在這種情況下,很多企業提供給業務人員、開發團隊的是寬表,並不安全。也無法追蹤到誰訪問了,訪問的次數。開發速度也慢。
業務人員對數據的理解、認知、版本的認知可能也沒那麼清楚,而且還帶來這種數據的不一致。

通過數據中台,讓數據採集的團隊負責採集,數據團隊負責提供API給到業務應用,這裡的API就根據前端的業務場景來開發。
這樣的話,把數據開發和服務開發分開,更安全、更專業、也更復用。API的訪問也能清晰知道誰訪問,訪問次數、包括控制安全也更加精細化。
最後通過前段時間得到的問卷調查數據,我總結了2020年數據中台的七個趨勢,與大家一起交流。

我們會發現數據中台現在處於不斷上升的階段,根據干擾的技術成熟度曲線,它一定會出現被質疑的階段,然後慢慢得趨向於平穩。
所以我認為數據中台在2020年會從概念熱點走向落地的建設,走向實踐。
不用刻意糾結中台這兩個字對不對,名字其實並不重要,重要的是它所承載的願景,它所承載的本質。
數據驅動的數字化轉型,這個趨勢是不會改變的,重要的是我們如何利用這個概念作為抓手去驅動企業的轉型。
哪些企業是真正的數據驅動的企業?