簡(jiǎn)介面向企業(yè)數(shù)字化轉(zhuǎn)型與數(shù)據(jù)中臺(tái)建設(shè)規(guī)劃該52頁(yè)P(yáng)PT方案系統(tǒng)梳理了數(shù)據(jù)中臺(tái)的核心認(rèn)知、解決方案與實(shí)踐匯報(bào)。內(nèi)容涉及數(shù)據(jù)服務(wù)化、數(shù)據(jù)資產(chǎn)化、數(shù)據(jù)標(biāo)準(zhǔn)化、模型萃取等體系化建設(shè)層次重點(diǎn)解決數(shù)據(jù)孤島與口徑不一致等問(wèn)題并給出高內(nèi)聚低耦合、公共邏輯下沉、數(shù)據(jù)可回滾等設(shè)計(jì)原則適合企業(yè)信息化負(fù)責(zé)人、架構(gòu)師及數(shù)據(jù)團(tuán)隊(duì)參考。資源包為單個(gè)pptx文件大小約9.52MB已有47人瀏覽學(xué)習(xí)。方案基于阿里云平臺(tái)的企業(yè)中臺(tái)架構(gòu)完整展示了從全域數(shù)據(jù)采集、統(tǒng)一數(shù)據(jù)資產(chǎn)管理到主題式數(shù)據(jù)服務(wù)的演進(jìn)路徑通過(guò)概念理解與建設(shè)方法雙重視角幫助讀者掌握數(shù)據(jù)中臺(tái)從理論到落地的關(guān)鍵要點(diǎn)同時(shí)涉及管理、平臺(tái)、數(shù)據(jù)、功能四個(gè)層面也可作為企業(yè)編制數(shù)據(jù)中臺(tái)建設(shè)方案時(shí)覆蓋各模塊的內(nèi)容參考。1. 別急著畫(huà)架構(gòu)圖先看清數(shù)據(jù)中臺(tái)跌落神壇的真相這幾年我接觸過(guò)不少正在做或者已經(jīng)做完數(shù)字化轉(zhuǎn)型的企業(yè)一個(gè)很明顯的現(xiàn)象是數(shù)據(jù)中臺(tái)這個(gè)詞從2019年前后的“逢會(huì)必講”到現(xiàn)在的“人人喊打”中間只隔了三四年。不少企業(yè)花了大幾千萬(wàn)把平臺(tái)搭起來(lái)了BI報(bào)表跑通了領(lǐng)導(dǎo)駕駛艙也能看了但業(yè)務(wù)部門(mén)該不用還是不用最后中臺(tái)變成了一個(gè)只會(huì)燒錢(qián)的“數(shù)據(jù)垃圾桶”。問(wèn)題出在哪很多人歸咎于技術(shù)不行、選型不對(duì)、供應(yīng)商不給力但我個(gè)人覺(jué)得大部分失敗的項(xiàng)目從一開(kāi)始就搞錯(cuò)了方向——把數(shù)據(jù)中臺(tái)當(dāng)成了一套軟件系統(tǒng)而不是一套企業(yè)級(jí)的數(shù)據(jù)能力建設(shè)方案。我見(jiàn)過(guò)太多這種情況售前PPT畫(huà)得無(wú)比宏大52頁(yè)方案里有30頁(yè)在講技術(shù)架構(gòu)——Lambda架構(gòu)、Kappa架構(gòu)、實(shí)時(shí)數(shù)倉(cāng)、離線數(shù)倉(cāng)、數(shù)據(jù)湖、流批一體搞得老板熱血沸騰。等真正落地的時(shí)候才發(fā)現(xiàn)最難的壓根不是這些技術(shù)選型而是企業(yè)自有的數(shù)據(jù)根本沒(méi)理清楚。財(cái)務(wù)部的數(shù)據(jù)叫“客戶(hù)收入”銷(xiāo)售部的數(shù)據(jù)叫“訂單金額”市場(chǎng)部的數(shù)據(jù)叫“GMV”三個(gè)口徑對(duì)不上你算出來(lái)的任何指標(biāo)都是“薛定諤的營(yíng)收”——看起來(lái)有數(shù)實(shí)際上沒(méi)人敢信。所以這篇文章我不打算給你講那些花哨的架構(gòu)圖而是結(jié)合我這幾年做數(shù)據(jù)中臺(tái)咨詢(xún)和實(shí)施的實(shí)際經(jīng)驗(yàn)拆解一份真正能落地的數(shù)據(jù)中臺(tái)能力平臺(tái)建設(shè)方案應(yīng)該包含哪些核心內(nèi)容每一塊為什么要這么做以及最常見(jiàn)又最隱蔽的那些坑在哪里。適合誰(shuí)看呢正在主導(dǎo)企業(yè)數(shù)字化轉(zhuǎn)型的CIO/CDO、數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)人、解決方案架構(gòu)師還有那些眼看公司要上中臺(tái)、想提前搞清楚狀況的業(yè)務(wù)線負(fù)責(zé)人。不管你目前處在什么階段這篇文章能幫你提前規(guī)避掉我踩過(guò)的那些大坑。2. 數(shù)據(jù)中臺(tái)不是技術(shù)平臺(tái)而是企業(yè)數(shù)據(jù)能力的“總裝車(chē)間”在拆解方案之前先花點(diǎn)時(shí)間把概念對(duì)齊一下?，F(xiàn)在市面上對(duì)數(shù)據(jù)中臺(tái)的定義五花八門(mén)有說(shuō)“數(shù)據(jù)中臺(tái)就是數(shù)據(jù)倉(cāng)庫(kù)的升級(jí)版”的有說(shuō)“數(shù)據(jù)中臺(tái)是一套中間件集合”的還有干脆把數(shù)據(jù)湖命名成數(shù)據(jù)中臺(tái)來(lái)賣(mài)產(chǎn)品的。如果連概念都是混沌的方案設(shè)計(jì)自然就是空中樓閣。2.1 用總裝車(chē)間的思路理解數(shù)據(jù)中臺(tái)的定位我比較喜歡打一個(gè)比方如果說(shuō)各業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)是“零部件生產(chǎn)車(chē)間”——ERP管物料、CRM管客戶(hù)、SCM管供應(yīng)那么數(shù)據(jù)中臺(tái)就是汽車(chē)工廠里的**“總裝車(chē)間”**。它不直接生產(chǎn)零部件但它把來(lái)自不同車(chē)間的零部件統(tǒng)一檢查、統(tǒng)一標(biāo)準(zhǔn)、統(tǒng)一組裝最后交付給下游——報(bào)表系統(tǒng)、自助分析工具、AI模型、業(yè)務(wù)API——一輛可以上路的整車(chē)。沒(méi)有總裝車(chē)間零部件再多也只是散件不但裝不到一起連規(guī)格都對(duì)不上。這個(gè)比喻對(duì)應(yīng)到數(shù)據(jù)中臺(tái)上意味著三件事。第一數(shù)據(jù)中臺(tái)必須有自己的數(shù)據(jù)標(biāo)準(zhǔn)體系就像總裝車(chē)間有扭矩標(biāo)準(zhǔn)和公差標(biāo)準(zhǔn)否則哪個(gè)車(chē)間的螺絲都擰不上你的車(chē)架。第二數(shù)據(jù)中臺(tái)必須具備跨域的數(shù)據(jù)整合能力它要能把分散在財(cái)務(wù)、銷(xiāo)售、供應(yīng)鏈各個(gè)系統(tǒng)的數(shù)據(jù)通過(guò)統(tǒng)一的規(guī)則合并清洗。第三數(shù)據(jù)中臺(tái)得有服務(wù)化的輸出能力不能光把數(shù)據(jù)規(guī)整好了放在那里還必須能按下游的需求把數(shù)據(jù)包裝成API、標(biāo)簽、指標(biāo)等多種形態(tài)交付出去。這三件事就是數(shù)據(jù)中臺(tái)所謂的“能力平臺(tái)”的核心內(nèi)涵。2.2 數(shù)據(jù)中臺(tái)與數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖的真正差異很多企業(yè)決策者有一個(gè)誤區(qū)一聽(tīng)到上數(shù)據(jù)中臺(tái)就問(wèn)“我們不是已經(jīng)有數(shù)倉(cāng)了嗎為什么還要再搞一套”這問(wèn)題背后的潛臺(tái)詞是把數(shù)倉(cāng)和中臺(tái)視為同一類(lèi)東西的新舊版本。但實(shí)際上二者解決的問(wèn)題維度完全不一樣。傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)解決的是“怎么把數(shù)據(jù)集中存起來(lái)供報(bào)表查詢(xún)”的問(wèn)題——注意它偏重的是存儲(chǔ)和計(jì)算解決的是數(shù)據(jù)的匯聚和結(jié)構(gòu)化問(wèn)題。數(shù)據(jù)湖解決的是“怎么把各種格式的原始數(shù)據(jù)都保留下來(lái)”的問(wèn)題——偏重規(guī)模和靈活性。而數(shù)據(jù)中臺(tái)解決的是“怎么讓數(shù)據(jù)能夠持續(xù)、穩(wěn)定、安全地被業(yè)務(wù)消費(fèi)”的問(wèn)題——偏重服務(wù)能力和復(fù)用機(jī)制。一個(gè)更直白的區(qū)別是數(shù)倉(cāng)面向的是“數(shù)據(jù)集”,中臺(tái)面向的是“數(shù)據(jù)服務(wù)”。你可以建一個(gè)背著幾十張寬表但幾乎沒(méi)人用的數(shù)據(jù)倉(cāng)庫(kù)但你不能建一個(gè)沒(méi)有任何業(yè)務(wù)場(chǎng)景在調(diào)用API的數(shù)據(jù)中臺(tái)——因?yàn)橹信_(tái)的價(jià)值只能通過(guò)業(yè)務(wù)被使用來(lái)體現(xiàn)。所以方案設(shè)計(jì)里數(shù)據(jù)服務(wù)層永遠(yuǎn)應(yīng)該放在最核心的位置來(lái)設(shè)計(jì)而不是先設(shè)計(jì)存儲(chǔ)再回頭想怎么用。2.3 能力平臺(tái)是對(duì)“不是所有數(shù)據(jù)都要進(jìn)中臺(tái)”的承認(rèn)再來(lái)說(shuō)說(shuō)“能力平臺(tái)”這四個(gè)字。和很多只講“數(shù)據(jù)匯聚整合”的傳統(tǒng)方案相比“能力平臺(tái)”這個(gè)表述其實(shí)是個(gè)很關(guān)鍵的進(jìn)步它暗示了一個(gè)重要原則數(shù)據(jù)中臺(tái)不是企業(yè)數(shù)據(jù)的唯一歸宿也不是所有數(shù)據(jù)都必須納入中臺(tái)統(tǒng)一管理。什么都往中臺(tái)里塞是中臺(tái)建設(shè)最常見(jiàn)的翻車(chē)姿勢(shì)之一。有些企業(yè)恨不得把服務(wù)器上的日志文件都拉進(jìn)中臺(tái)結(jié)果數(shù)據(jù)量上去了、存儲(chǔ)成本暴增、治理難度翻倍核心的財(cái)務(wù)、客戶(hù)、供應(yīng)鏈數(shù)據(jù)反而因?yàn)殡s音太多被淹沒(méi)了。能力平臺(tái)的設(shè)計(jì)思路是先明確企業(yè)核心的數(shù)據(jù)資產(chǎn)范圍再以“能力”為單位來(lái)組織數(shù)據(jù)——客戶(hù)統(tǒng)一視圖是一種能力訂單全鏈路追蹤是一種能力供應(yīng)鏈風(fēng)險(xiǎn)預(yù)警也是一種能力。每種能力聚焦一個(gè)明確的業(yè)務(wù)價(jià)值點(diǎn)有自己的數(shù)據(jù)輸入、處理邏輯和服務(wù)輸出就像一個(gè)一個(gè)可以獨(dú)立交付的“總裝模塊”。這種設(shè)計(jì)讓中臺(tái)的建設(shè)和投資能夠按優(yōu)先級(jí)分階段進(jìn)行而不是一次性的大爆炸工程。3. “先有數(shù)、再有臺(tái)”——數(shù)據(jù)資產(chǎn)盤(pán)點(diǎn)和治理是整個(gè)方案的隱性地基我在前面提到過(guò)數(shù)據(jù)中臺(tái)項(xiàng)目最容易翻車(chē)的地方不在技術(shù)選型而在數(shù)據(jù)基礎(chǔ)。如果你的企業(yè)連一份可靠的數(shù)據(jù)資產(chǎn)目錄都沒(méi)有你建出來(lái)的中臺(tái)就是一個(gè)無(wú)源之水。但現(xiàn)實(shí)是幾乎所有的售前方案都把這一塊輕描淡寫(xiě)地帶過(guò)了好像幾頁(yè)“數(shù)據(jù)治理體系”的框架圖就能搞定一樣。真正動(dòng)起手來(lái)你會(huì)發(fā)現(xiàn)這遠(yuǎn)比Spark調(diào)優(yōu)、Flink部署要痛苦得多。3.1 盤(pán)點(diǎn)到底盤(pán)什么從“系統(tǒng)清單”到“字段級(jí)血緣”很多企業(yè)說(shuō)“我們有數(shù)據(jù)資產(chǎn)清單”拿出來(lái)一看就是每套系統(tǒng)有哪些表、每張表大概存了什么。這只能叫“系統(tǒng)清單”離數(shù)據(jù)資產(chǎn)盤(pán)點(diǎn)差了十萬(wàn)八千里。真正有用的資產(chǎn)盤(pán)點(diǎn)至少要細(xì)化到字段級(jí)而且必須搞清楚三件事這個(gè)字段的業(yè)務(wù)含義是什么它是由哪個(gè)上游系統(tǒng)的哪個(gè)流程產(chǎn)生的它被下游哪些報(bào)表和接口在消費(fèi)只有把這三件事畫(huà)出來(lái)你才擁有了一張真正意義上的企業(yè)數(shù)據(jù)地圖后續(xù)做標(biāo)準(zhǔn)定義、質(zhì)量規(guī)則、安全分級(jí)才有抓手。我之前為一個(gè)零售客戶(hù)做盤(pán)點(diǎn)的時(shí)候光“會(huì)員”這個(gè)實(shí)體就在CRM、訂單系統(tǒng)、積分商城、客服系統(tǒng)里找到了六個(gè)不同的ID每個(gè)系統(tǒng)的“會(huì)員唯一標(biāo)識(shí)”都不一樣。更離譜的是還有兩個(gè)系統(tǒng)的“會(huì)員等級(jí)”字段同一個(gè)人的同一等級(jí)一個(gè)叫V2另一個(gè)叫銀卡。這種數(shù)據(jù)如果不盤(pán)出來(lái)后面做會(huì)員畫(huà)像、做分群運(yùn)營(yíng)全是空中樓閣。盤(pán)點(diǎn)這件事沒(méi)有捷徑只有一個(gè)辦法——業(yè)務(wù)人員和技術(shù)人員坐在一起一張表一張表地過(guò)。這種方式很笨但也是唯一能真正出效果的方式。3.2 數(shù)據(jù)標(biāo)準(zhǔn)的落地策略不要追求一步到位的“全企業(yè)大一統(tǒng)”傳統(tǒng)咨詢(xún)公司給你的方案里大概率會(huì)有一個(gè)很大的章節(jié)叫“數(shù)據(jù)標(biāo)準(zhǔn)體系”里面定義了各種編碼規(guī)范、命名規(guī)范、分類(lèi)規(guī)范。聽(tīng)上去特別完美但實(shí)際推行的時(shí)候基本都會(huì)遭遇業(yè)務(wù)部門(mén)的消極抵抗——因?yàn)閷?duì)業(yè)務(wù)團(tuán)隊(duì)來(lái)說(shuō)改一套用了十年的編碼規(guī)范意味著所有線下表格、習(xí)慣叫法、歷史口徑全要跟著動(dòng)短期內(nèi)看不到任何收益純粹是增加工作量。所以我在實(shí)際操作中更推薦“核心先行、增量推進(jìn)”的策略。第一年只對(duì)真正制約數(shù)據(jù)互通的核心實(shí)體定標(biāo)準(zhǔn)比如客戶(hù)、產(chǎn)品、組織、供應(yīng)商這類(lèi)主數(shù)據(jù)先把“一個(gè)客戶(hù)到底是誰(shuí)”這個(gè)問(wèn)題解決了。非核心的領(lǐng)域數(shù)據(jù)只做登記不強(qiáng)行統(tǒng)一。等核心標(biāo)準(zhǔn)跑通了業(yè)務(wù)部門(mén)開(kāi)始嘗到“數(shù)據(jù)能對(duì)上了”的甜頭后續(xù)的標(biāo)準(zhǔn)推廣就會(huì)順暢得多。數(shù)據(jù)治理不是一次性的運(yùn)動(dòng)而是持續(xù)演進(jìn)的過(guò)程——這句話聽(tīng)起來(lái)老生常談但它決定了你方案里那套漂亮的治理體系到底能落地三成還是七成。3.3 數(shù)據(jù)質(zhì)量不能只靠“清洗腳本”要嵌入數(shù)據(jù)產(chǎn)生的源頭數(shù)據(jù)質(zhì)量這個(gè)話題幾乎每個(gè)方案都會(huì)提但絕大多數(shù)方案都停留在“通過(guò)清洗、去重、補(bǔ)全等手段提升數(shù)據(jù)質(zhì)量”這種一句帶過(guò)的層面。真正做過(guò)的人都知道靠ETL階段寫(xiě)清洗腳本是最被動(dòng)的方式——臟數(shù)據(jù)已經(jīng)在業(yè)務(wù)系統(tǒng)里產(chǎn)生了你是靠各種正則、對(duì)照表去猜它本來(lái)應(yīng)該長(zhǎng)什么樣這個(gè)過(guò)程的維護(hù)成本極高而且永遠(yuǎn)有猜錯(cuò)的時(shí)候。我更建議在方案里增加一個(gè)“源頭質(zhì)量規(guī)則前置”的設(shè)計(jì)思路通過(guò)數(shù)據(jù)同步工具或業(yè)務(wù)側(cè)接口改造在數(shù)據(jù)從源系統(tǒng)流入中臺(tái)的那一刻就進(jìn)行質(zhì)量規(guī)則的校驗(yàn)和攔截。比如用戶(hù)手機(jī)號(hào)格式不符合規(guī)則這條記錄直接進(jìn)“異常庫(kù)”在源頭打上標(biāo)記推送給對(duì)應(yīng)的業(yè)務(wù)系統(tǒng)去修正而不是默默清洗掉。這樣做的價(jià)值不只是讓中臺(tái)的數(shù)據(jù)更干凈更重要的是讓業(yè)務(wù)系統(tǒng)意識(shí)到“我產(chǎn)生的數(shù)據(jù)是會(huì)被審計(jì)的”從機(jī)制上倒逼源頭治理。這一步比你在中臺(tái)后面堆一百個(gè)清洗算法都管用。4. 技術(shù)架構(gòu)設(shè)計(jì)的核心不是“選哪個(gè)引擎”而是“怎么能讓數(shù)據(jù)持續(xù)流轉(zhuǎn)”技術(shù)選型是數(shù)據(jù)中臺(tái)方案里最容易讓團(tuán)隊(duì)產(chǎn)生爭(zhēng)論的部分包括我自己也曾經(jīng)在Hadoop和Spark的版本選擇、ClickHouse和Doris的對(duì)比上花費(fèi)了大量時(shí)間。但這些年下來(lái)我逐漸意識(shí)到在業(yè)務(wù)場(chǎng)景還沒(méi)有被驗(yàn)證之前過(guò)度糾結(jié)所謂“最佳引擎”是一種偽優(yōu)化。數(shù)據(jù)中臺(tái)技術(shù)架構(gòu)的真正核心是構(gòu)建一套讓數(shù)據(jù)能夠從源頭穩(wěn)定流向消費(fèi)端的管道體系并保證這個(gè)過(guò)程可運(yùn)維、可觀測(cè)、可擴(kuò)展。4.1 一套靠譜的數(shù)據(jù)分層模型勝過(guò)所有花哨引擎無(wú)論底層用什么樣的技術(shù)組件數(shù)據(jù)中臺(tái)的數(shù)據(jù)組織都應(yīng)該遵循清晰的分層邏輯。我常用的分層模型是ODS操作數(shù)據(jù)存儲(chǔ)層、DWD明細(xì)數(shù)據(jù)層、DWS匯總數(shù)據(jù)層、ADS應(yīng)用數(shù)據(jù)層的四層結(jié)構(gòu)這是目前業(yè)內(nèi)實(shí)踐最成熟的一種模式。ODS層貼源存儲(chǔ)保留從各業(yè)務(wù)系統(tǒng)抽取過(guò)來(lái)的原始數(shù)據(jù)不做任何處理做數(shù)據(jù)備份和審計(jì)用。DWD層清洗、去重、標(biāo)準(zhǔn)化后的明細(xì)數(shù)據(jù)保持業(yè)務(wù)過(guò)程的最小粒度。這是整個(gè)數(shù)據(jù)體系中復(fù)用價(jià)值最高的一層也是數(shù)據(jù)質(zhì)量的關(guān)鍵承重層。DWS層按業(yè)務(wù)主題進(jìn)行輕度匯總比如按客戶(hù)、按商品、按門(mén)店維度匯聚指標(biāo)降低下游取數(shù)的計(jì)算成本。ADS層面向具體應(yīng)用場(chǎng)景定制的數(shù)據(jù)比如某張BI報(bào)表專(zhuān)用的寬表或者某個(gè)推薦系統(tǒng)的特征表。這套模型最核心的價(jià)值在于數(shù)據(jù)在層與層之間的流轉(zhuǎn)是單向的、可控的每一層都有明確的作用和輸出標(biāo)準(zhǔn)。很多做不好的數(shù)倉(cāng)項(xiàng)目最后都變成了“一張大寬表走天下”——沒(méi)有分層所有指標(biāo)都從ODS直接計(jì)算一旦業(yè)務(wù)邏輯調(diào)整整個(gè)鏈路都要返工。分層看似多了一道工序?qū)嶋H上是在保護(hù)你后續(xù)的每一個(gè)改動(dòng)。這里我也要提醒一點(diǎn)分層不是越細(xì)越好務(wù)必根據(jù)實(shí)際場(chǎng)景做裁剪中小型企業(yè)也許用三層就夠了硬套四層反而增加管理成本。4.2 實(shí)時(shí)與批處理用“湖倉(cāng)一體”思想代替實(shí)時(shí)與離線的二元對(duì)立近兩年大家不怎么提Lambda架構(gòu)了不是因?yàn)槟翘走壿嬘袉?wèn)題而是湖倉(cāng)一體的理念逐漸成熟讓流批兩套管道可以共享同一份存儲(chǔ)。這個(gè)演進(jìn)對(duì)數(shù)據(jù)中臺(tái)方案的直接影響是你可以不用在方案里把實(shí)時(shí)和離線拆成兩條完全獨(dú)立的鏈路來(lái)設(shè)計(jì)而是把它們看作一個(gè)數(shù)據(jù)管道在不同時(shí)效要求下的兩種表現(xiàn)形式。具體到架構(gòu)設(shè)計(jì)我建議采用一套具備流批一體能力的數(shù)據(jù)底座底層用數(shù)據(jù)湖格式如Iceberg或者Hudi統(tǒng)一存儲(chǔ)ODS和DWD層數(shù)據(jù)上層用一套SQL引擎同時(shí)支撐批處理和流處理。這樣做的好處非常實(shí)在第一極大降低了運(yùn)維成本——不用同時(shí)維護(hù)兩套集群兩套任務(wù)調(diào)度第二實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)天然保持口徑一致——因?yàn)樗鼈冏x的是同一份數(shù)據(jù)不會(huì)再出現(xiàn)實(shí)時(shí)看一個(gè)數(shù)、T1又變成另一個(gè)數(shù)的尷尬第三數(shù)據(jù)架構(gòu)更簡(jiǎn)潔新成員上手也更快。當(dāng)然這個(gè)方案對(duì)團(tuán)隊(duì)的技術(shù)能力要求不低如果你們團(tuán)隊(duì)前兩年主要寫(xiě)的是Hive SQL突然切換到Flink SQL和Iceberg會(huì)有不小的學(xué)習(xí)成本。我的建議是如果公司實(shí)時(shí)需求不強(qiáng)烈先踏實(shí)做好離線鏈路等離線數(shù)據(jù)質(zhì)量穩(wěn)定了再在DWD層增加實(shí)時(shí)管道分支沒(méi)必要一上來(lái)就圖“全鏈路實(shí)時(shí)”。4.3 數(shù)據(jù)服務(wù)層企業(yè)數(shù)據(jù)中臺(tái)是否有“活力”的分水嶺很多企業(yè)的數(shù)據(jù)中臺(tái)做完分層、跑通調(diào)度、掛上BI報(bào)表之后項(xiàng)目就宣布“成功上線”了。但在我看來(lái)這恰恰是問(wèn)題的開(kāi)始——因?yàn)锽I報(bào)表只是數(shù)據(jù)消費(fèi)的最原始形態(tài)。判斷一個(gè)中臺(tái)有沒(méi)有真正內(nèi)化成企業(yè)的能力平臺(tái)關(guān)鍵要看數(shù)據(jù)服務(wù)層是否成型。數(shù)據(jù)服務(wù)層的核心是一套統(tǒng)一的數(shù)據(jù)API網(wǎng)關(guān)把對(duì)底層數(shù)據(jù)表的訪問(wèn)能力封裝成標(biāo)準(zhǔn)API提供給業(yè)務(wù)系統(tǒng)調(diào)用。舉個(gè)例子一個(gè)零售企業(yè)線上線下都有業(yè)務(wù)會(huì)員系統(tǒng)的用戶(hù)畫(huà)像需要同時(shí)取數(shù)CRM、訂單、小程序?yàn)g覽行為如果沒(méi)有數(shù)據(jù)服務(wù)層每次取數(shù)都要讓開(kāi)發(fā)去提數(shù)、寫(xiě)臨時(shí)SQL、做接口一趟下來(lái)沒(méi)有三兩天搞不定。但如果有統(tǒng)一的數(shù)據(jù)服務(wù)層數(shù)據(jù)分析師把數(shù)據(jù)封裝成一個(gè)“會(huì)員全景畫(huà)像查詢(xún)API”下游的應(yīng)用只要調(diào)一個(gè)接口就能拿到規(guī)整好的全維度數(shù)據(jù)既快又穩(wěn)還能做訪問(wèn)權(quán)限控制。這才是數(shù)據(jù)中臺(tái)對(duì)業(yè)務(wù)響應(yīng)能力的真正價(jià)值所在。所以方案里數(shù)據(jù)服務(wù)層一定不能缺席哪怕第一版只規(guī)劃兩三個(gè)API也要把機(jī)制和規(guī)范建起來(lái)讓“數(shù)據(jù)是用出來(lái)的”這個(gè)理念從一開(kāi)始就扎根。5. 應(yīng)用場(chǎng)景不是“最后想想的事”而是倒推整個(gè)方案設(shè)計(jì)的起點(diǎn)這是我見(jiàn)過(guò)最普遍的方案結(jié)構(gòu)問(wèn)題絕大多數(shù)數(shù)據(jù)中臺(tái)建設(shè)方案都把“應(yīng)用場(chǎng)景”放在最后幾頁(yè)作為整套方案的“展望”和“愿景”。但在我的實(shí)踐經(jīng)驗(yàn)里這個(gè)順序完全反了。數(shù)據(jù)中臺(tái)建設(shè)的最優(yōu)路徑恰恰是從應(yīng)用場(chǎng)景出發(fā)倒推需要哪些數(shù)據(jù)能力再推導(dǎo)到需要哪些數(shù)據(jù)資產(chǎn)、哪些技術(shù)組件。場(chǎng)景先行中臺(tái)才有靶心。5.1 用“3-5個(gè)核心場(chǎng)景”鎖定中臺(tái)的首期建設(shè)范圍數(shù)據(jù)中臺(tái)建設(shè)最怕的就是“大而全”。我建議無(wú)論是方案設(shè)計(jì)還是項(xiàng)目規(guī)劃都必須明確一個(gè)原則一期項(xiàng)目只圍繞3到5個(gè)高價(jià)值場(chǎng)景展開(kāi)這些場(chǎng)景必須具備幾個(gè)特征——跨多個(gè)業(yè)務(wù)系統(tǒng)取數(shù)、業(yè)務(wù)價(jià)值明確、數(shù)據(jù)基礎(chǔ)相對(duì)可用。比如對(duì)零售企業(yè)我通常推薦從以下場(chǎng)景切入客戶(hù)全生命周期洞察打通線上線下交易、會(huì)員互動(dòng)、客服反饋數(shù)據(jù)構(gòu)建客戶(hù)統(tǒng)一視圖支撐精準(zhǔn)營(yíng)銷(xiāo)和流失預(yù)警。供應(yīng)鏈協(xié)同優(yōu)化貫通采購(gòu)、庫(kù)存、銷(xiāo)售預(yù)測(cè)數(shù)據(jù)建立跨部門(mén)的供應(yīng)鏈可視化看板輔助補(bǔ)貨和調(diào)撥決策。經(jīng)營(yíng)分析一體化統(tǒng)一財(cái)務(wù)、銷(xiāo)售、生產(chǎn)口徑讓集團(tuán)和各分公司的經(jīng)營(yíng)數(shù)據(jù)“同表同數(shù)”消滅多版本報(bào)表。這3個(gè)場(chǎng)景走通后團(tuán)隊(duì)積累了數(shù)據(jù)接入、治理、建模、服務(wù)輸出的全套經(jīng)驗(yàn)再做二期擴(kuò)展成功率會(huì)高很多。反過(guò)來(lái)如果你上來(lái)就規(guī)劃二十個(gè)場(chǎng)景那大概率是哪個(gè)場(chǎng)景都做得不深最終價(jià)值感稀薄項(xiàng)目淪為“報(bào)表中心”甚至“數(shù)據(jù)墳場(chǎng)”。5.2 數(shù)據(jù)指標(biāo)體系是場(chǎng)景應(yīng)用的“度量衡”在做應(yīng)用場(chǎng)景設(shè)計(jì)的時(shí)候有一個(gè)工作必須提前做扎實(shí)那就是指標(biāo)體系的梳理和標(biāo)準(zhǔn)化。這件事不到一定規(guī)模的企業(yè)很容易忽略但它恰恰是業(yè)務(wù)部門(mén)最關(guān)心的東西——因?yàn)闃I(yè)務(wù)要看的就是指標(biāo)指標(biāo)口徑對(duì)不上整個(gè)中臺(tái)在業(yè)務(wù)心中的信任度就崩塌了。我們來(lái)想象一個(gè)場(chǎng)景生產(chǎn)部門(mén)說(shuō)這個(gè)月產(chǎn)量達(dá)標(biāo)率96%銷(xiāo)售部門(mén)說(shuō)業(yè)績(jī)完成率只有72%兩邊在經(jīng)營(yíng)會(huì)上吵起來(lái)——你已經(jīng)實(shí)現(xiàn)了業(yè)務(wù)系統(tǒng)數(shù)據(jù)的打通可一旦涉及指標(biāo)又回到了一本糊涂賬?！皫?kù)存周轉(zhuǎn)天數(shù)”到底怎么算“訂單滿(mǎn)足率”的分母是客戶(hù)下單量還是訂單需求量“新客”是看首單時(shí)間還是注冊(cè)時(shí)間這些不捋清楚數(shù)據(jù)中臺(tái)建得再漂亮業(yè)務(wù)用起來(lái)還是會(huì)覺(jué)得“這數(shù)不對(duì)”。所以一個(gè)完整的數(shù)據(jù)中臺(tái)建設(shè)方案里必須包含一個(gè)企業(yè)核心指標(biāo)字典對(duì)指標(biāo)的定義、口徑、來(lái)源、負(fù)責(zé)人做顯式化的管理。這一塊沒(méi)有捷徑就是和業(yè)務(wù)一場(chǎng)會(huì)接一場(chǎng)會(huì)磨出來(lái)的。但也正是這個(gè)過(guò)程讓你的中臺(tái)真正從“技術(shù)平臺(tái)”變成了“業(yè)務(wù)能力平臺(tái)”。5.3 場(chǎng)景運(yùn)行后的反饋閉環(huán)一次交付不是結(jié)束而是數(shù)據(jù)服務(wù)迭代的開(kāi)始最后想強(qiáng)調(diào)一個(gè)方案里幾乎不會(huì)被寫(xiě)進(jìn)去、但極其重要的環(huán)節(jié)——場(chǎng)景上線后的運(yùn)行反饋閉環(huán)。很多中臺(tái)項(xiàng)目一上線就沒(méi)人管了指標(biāo)開(kāi)始偏差也沒(méi)人修復(fù)數(shù)據(jù)質(zhì)量下降也沒(méi)人發(fā)現(xiàn)半年之后業(yè)務(wù)又開(kāi)始用回自己的Excel表。要避免這個(gè)結(jié)局需要在方案里設(shè)計(jì)一套持續(xù)運(yùn)營(yíng)機(jī)制每個(gè)核心場(chǎng)景都要有指定的“數(shù)據(jù)產(chǎn)品經(jīng)理”來(lái)負(fù)責(zé)對(duì)接業(yè)務(wù)反饋、跟蹤數(shù)據(jù)質(zhì)量、迭代指標(biāo)口徑同時(shí)通過(guò)數(shù)據(jù)質(zhì)量監(jiān)控平臺(tái)對(duì)關(guān)鍵鏈路設(shè)置告警一旦某個(gè)表的字段異常率超過(guò)閾值自動(dòng)觸發(fā)修復(fù)流程。說(shuō)白了數(shù)據(jù)中臺(tái)不是一個(gè)一次性交付的工程而是一個(gè)需要持續(xù)運(yùn)營(yíng)的產(chǎn)品。那些最終失敗的項(xiàng)目大多數(shù)不是技術(shù)不行而是沒(méi)有運(yùn)營(yíng)意識(shí)。把“一次交付”的心態(tài)換成“持續(xù)運(yùn)營(yíng)”的模式你的中臺(tái)才有活過(guò)第一年的可能性。6. 數(shù)據(jù)安全與組織保障——中臺(tái)方案里最容易被低估的兩個(gè)硬約束前五節(jié)我重點(diǎn)講了數(shù)據(jù)中臺(tái)怎么建、怎么用但如果一個(gè)方案只有技術(shù)藍(lán)圖和應(yīng)用規(guī)劃那它還缺了半邊天——數(shù)據(jù)安全和組織保障。這兩件事在52頁(yè)P(yáng)PT里通常是被壓縮在最后三五頁(yè)的內(nèi)容但恰恰這是項(xiàng)目成敗和可持續(xù)性的硬性約束我單獨(dú)拉出來(lái)說(shuō)一下。6.1 數(shù)據(jù)安全的本質(zhì)是“在共享和管控之間找平衡”數(shù)據(jù)中臺(tái)的一個(gè)重要目標(biāo)是打破數(shù)據(jù)孤島實(shí)現(xiàn)共享。但共享和管控天然是一對(duì)矛盾——共享程度越高風(fēng)險(xiǎn)暴露面越大管控過(guò)嚴(yán)共享的效率和價(jià)值就無(wú)從談起。好的數(shù)據(jù)安全設(shè)計(jì)不是“一刀切的封禁”而是通過(guò)分級(jí)分類(lèi)體系做到“該通的通、該堵的堵”。具體到方案落地至少要覆蓋這么幾層第一數(shù)據(jù)分級(jí)分類(lèi)把企業(yè)數(shù)據(jù)按照敏感程度分成公開(kāi)、內(nèi)部、敏感、高敏感四個(gè)等級(jí)不同等級(jí)對(duì)應(yīng)不同的訪問(wèn)控制策略第二數(shù)據(jù)脫敏機(jī)制在生產(chǎn)環(huán)境暴露給開(kāi)發(fā)和測(cè)試環(huán)境之前對(duì)手機(jī)號(hào)、身份證號(hào)、銀行卡號(hào)等個(gè)人敏感信息進(jìn)行不可逆的脫敏變形第三數(shù)據(jù)訪問(wèn)審計(jì)記錄每一次數(shù)據(jù)訪問(wèn)行為做到“誰(shuí)在什么時(shí)間通過(guò)什么方式訪問(wèn)了什么數(shù)據(jù)”全程可追溯。這三層能力是數(shù)據(jù)中臺(tái)安全管理的底線缺一不可。我見(jiàn)過(guò)一些企業(yè)安全意識(shí)非常強(qiáng)把所有數(shù)據(jù)都鎖得死死的連內(nèi)部BI報(bào)表都要層層審批結(jié)果中臺(tái)活活變成了一個(gè)“數(shù)據(jù)冷宮”。這其實(shí)和沒(méi)有任何安全管控的文化同樣危險(xiǎn)。所以我特別建議方案里引入“安全與效率的動(dòng)態(tài)平衡機(jī)制”——定期審視數(shù)據(jù)訪問(wèn)的權(quán)限策略把那些不再需要高權(quán)限的角色降權(quán)同時(shí)給確實(shí)有數(shù)據(jù)需求的崗位開(kāi)“輕量審批”的綠色通道。數(shù)據(jù)安全的目的不是讓人用不了數(shù)據(jù)而是讓正確的人能高效地使用正確的數(shù)據(jù)。6.2 沒(méi)有“數(shù)據(jù)Owner”機(jī)制數(shù)據(jù)治理就是一場(chǎng)空談最后來(lái)談組織保障。技術(shù)方案寫(xiě)得好甚至都落地了為什么數(shù)據(jù)質(zhì)量還是持續(xù)劣化、指標(biāo)口徑還是頻繁變更十有八九是組織機(jī)制沒(méi)跟上。很多企業(yè)雖然把數(shù)據(jù)團(tuán)隊(duì)從IT部門(mén)獨(dú)立出來(lái)成立了一個(gè)“大數(shù)據(jù)部”但這個(gè)部門(mén)只有技術(shù)人員沒(méi)有業(yè)務(wù)側(cè)的人真正為數(shù)據(jù)負(fù)責(zé)。結(jié)果就是數(shù)據(jù)出問(wèn)題了誰(shuí)都可以指出問(wèn)題但誰(shuí)也不覺(jué)得自己有責(zé)任去修。我比較推薦在方案中建立一套“數(shù)據(jù)Owner數(shù)據(jù)責(zé)任人機(jī)制”按數(shù)據(jù)域把責(zé)任劃分到具體的業(yè)務(wù)部門(mén)。比如客戶(hù)數(shù)據(jù)域的商業(yè)負(fù)責(zé)人是CMO他會(huì)指定一個(gè)業(yè)務(wù)骨干做客戶(hù)數(shù)據(jù)的Owner數(shù)據(jù)團(tuán)隊(duì)會(huì)和這個(gè)Owner一起定義指標(biāo)口徑、制定質(zhì)量規(guī)則、評(píng)審需求變更。這樣做的好處是把“數(shù)據(jù)好不好用”這個(gè)模糊的命題變成了一件有人負(fù)責(zé)、有KPI約束的具體工作。數(shù)據(jù)團(tuán)隊(duì)從“天下的數(shù)據(jù)都?xì)w我管”變成“我和業(yè)務(wù)共建數(shù)據(jù)”整個(gè)治理體系的執(zhí)行效率會(huì)完全不一樣。這個(gè)機(jī)制建立起來(lái)初期一定會(huì)遇到阻力——業(yè)務(wù)部門(mén)會(huì)覺(jué)得“我只是用數(shù)據(jù)的為什么數(shù)據(jù)臟了要我負(fù)責(zé)”。這時(shí)候就要靠高層來(lái)推動(dòng)在制度層面把數(shù)據(jù)質(zhì)量納入業(yè)務(wù)部門(mén)負(fù)責(zé)人的績(jī)效指標(biāo)。說(shuō)到底數(shù)據(jù)中臺(tái)不是IT部門(mén)給業(yè)務(wù)部門(mén)做的“外包項(xiàng)目”而是整個(gè)企業(yè)協(xié)同共建的基礎(chǔ)工程。組織機(jī)制不到位再多技術(shù)投入都是打水漂。7. 最后說(shuō)幾句大實(shí)話別把52頁(yè)P(yáng)PT當(dāng)交付物要把它當(dāng)作戰(zhàn)地圖寫(xiě)了這么多不知不覺(jué)話也說(shuō)得差不多了。最后這點(diǎn)篇幅我想聊幾句不那么“方案化”的東西純粹是個(gè)人這幾年的真實(shí)體會(huì)。很多團(tuán)隊(duì)在數(shù)據(jù)中臺(tái)項(xiàng)目啟動(dòng)階段最大的產(chǎn)出就是一份精美的PPT匯報(bào)材料恨不得每頁(yè)都是架構(gòu)圖、路線圖、實(shí)施計(jì)劃表。我理解這種處境因?yàn)閷?duì)內(nèi)要說(shuō)服老板對(duì)外要統(tǒng)一認(rèn)知一份有說(shuō)服力的方案確實(shí)必不可少。但我接觸越多越發(fā)現(xiàn)那些成功落地?cái)?shù)據(jù)中臺(tái)的企業(yè)幾乎都有一個(gè)共同特點(diǎn)他們從第一天開(kāi)始就沒(méi)有把PPT當(dāng)成交付物而是把它當(dāng)成一份“作戰(zhàn)地圖”。地圖的意義在于它是用來(lái)找路的不是用來(lái)供奉的。方案里的每一個(gè)模塊、每一張架構(gòu)圖最終都應(yīng)該被轉(zhuǎn)化成有人負(fù)責(zé)、有時(shí)間節(jié)點(diǎn)、可驗(yàn)證的任務(wù)項(xiàng)。數(shù)據(jù)標(biāo)準(zhǔn)由誰(shuí)來(lái)定、什么時(shí)候定完指標(biāo)字典的v1.0版覆蓋哪些域首個(gè)API服務(wù)的上線日期是哪天——這些才是比52頁(yè)更重要的東西。另外如果你是公司內(nèi)部推動(dòng)中臺(tái)的人請(qǐng)一定做好打持久戰(zhàn)的心理準(zhǔn)備。數(shù)據(jù)中臺(tái)在技術(shù)層面也許一套集群加幾個(gè)月的開(kāi)發(fā)就能“跑起來(lái)”但在組織層面它是一場(chǎng)至少以年為單位的演進(jìn)過(guò)程。我第一次做中臺(tái)項(xiàng)目時(shí)天真地以為數(shù)據(jù)打通了大家就會(huì)用事實(shí)證明我錯(cuò)得離譜——“數(shù)據(jù)通了”和“業(yè)務(wù)相信這些數(shù)據(jù)”之間隔著無(wú)數(shù)輪的指標(biāo)對(duì)賬、數(shù)據(jù)質(zhì)量申訴、口徑解釋會(huì)議。這個(gè)過(guò)程沒(méi)有捷徑只能靠一次次穩(wěn)定的交付慢慢把信任攢起來(lái)。最后再分享一個(gè)小建議如果你所在的企業(yè)正準(zhǔn)備啟動(dòng)數(shù)據(jù)中臺(tái)建設(shè)預(yù)算和時(shí)間都有限那就不要貪多求全。先圈定一個(gè)最痛、最能產(chǎn)生業(yè)務(wù)價(jià)值的場(chǎng)景用最小閉環(huán)的方式把從數(shù)據(jù)接入到數(shù)據(jù)服務(wù)輸出的全鏈路走一遍形成范式后再?gòu)?fù)制到其他場(chǎng)景。這個(gè)策略聽(tīng)起來(lái)沒(méi)有“五年規(guī)劃”那么宏大但在我接觸過(guò)的項(xiàng)目里它的成功率遠(yuǎn)高于一步到位的大規(guī)模建設(shè)。數(shù)據(jù)中臺(tái)這條路很難走但方向?qū)α寺稽c(diǎn)也能到。本文還有配套的精品資源點(diǎn)擊獲取