做數(shù)據(jù)中臺這幾年我最大的感受是平臺組件可以買、可以搭但真正讓中臺有價值或者沒價值的往往是那一張張表怎么設(shè)計。數(shù)據(jù)模型看著是個老話題幾乎所有中臺項(xiàng)目都會喊“我們要做指標(biāo)統(tǒng)一、數(shù)據(jù)打通”但一落到模型設(shè)計上經(jīng)常就是各業(yè)務(wù)線各建各的最終中臺變成一個巨大的轉(zhuǎn)發(fā)層。數(shù)據(jù)中臺里的數(shù)據(jù)模型到底有哪些可以復(fù)用的設(shè)計模式每種模式解決什么問題、代價是什么、在什么階段用什么這些坑我基本都踩過這篇把這些內(nèi)容完整梳理一下希望能給正在搞中臺的團(tuán)隊一些能直接抄作業(yè)的參考。數(shù)據(jù)中臺的模型設(shè)計本質(zhì)量和方案套路其實(shí)完全不遜于軟件工程里的設(shè)計模式。好消息是不需要你重新發(fā)明輪子經(jīng)典數(shù)據(jù)倉庫的建模方法論加上湖倉時代的演進(jìn)思路已經(jīng)積累了足夠多的成熟模式。這里不討論理論層面的“如何用ER建模畫出完美邏輯模型”而是聚焦到中臺實(shí)際落地時長期能跑得穩(wěn)的幾種設(shè)計模式。1. 先搞明白數(shù)據(jù)中臺為什么對數(shù)據(jù)模型這么挑剔1.1 數(shù)據(jù)模型設(shè)計在中臺里的角色容易走偏很多團(tuán)隊一提數(shù)據(jù)中臺第一個反應(yīng)是上組件采集同步用某工具、存儲用數(shù)據(jù)湖、計算引擎用Spark或者StarRocks、調(diào)度用 DolphinScheduler以為把這堆組件串起來中臺就成了。實(shí)際項(xiàng)目干到中期大家真正頭疼的往往不是組件而是怎么把幾十個業(yè)務(wù)庫的數(shù)據(jù)組織成一套能被信任的指標(biāo)體系。數(shù)據(jù)模型就是這套體系的地基。為什么中臺比普通數(shù)倉對模型更挑剔因?yàn)槠胀〝?shù)倉的模型面向單一的報表需求——BI看板要什么就建什么表。中臺不一樣它要面向全公司的多業(yè)務(wù)線復(fù)用。訂單域的數(shù)據(jù)供應(yīng)鏈要用、財務(wù)要用、運(yùn)營要用、客服要用同一張事實(shí)表、同一個維度的口徑定義必須全公司統(tǒng)一。這就不是“建一張星型模型”就能解決的事而是要設(shè)計一套能橫向擴(kuò)展、能在多個團(tuán)隊之間共識的模型規(guī)范。我的經(jīng)驗(yàn)是數(shù)據(jù)模型在中臺項(xiàng)目中真正解決的是兩個問題——口徑一致性問題和數(shù)據(jù)復(fù)用性問題。模型設(shè)計不好這兩個問題會變成無休止的會議扯皮。模型設(shè)計好了很多協(xié)作矛盾被前置化解因?yàn)閺谋斫Y(jié)構(gòu)上就杜絕了各搞一套的空間。1.2 設(shè)計模式是一種“有約束的套路”在軟件工程里設(shè)計模式的定義是“針對特定上下文的可復(fù)用解決方案”。數(shù)據(jù)模型里的設(shè)計模式也差不多本質(zhì)是一套被驗(yàn)證過的數(shù)據(jù)組織套路。面對同樣一堆源數(shù)據(jù)是直接同步一份照原樣放著還是拆成維表事實(shí)表還是按Data Vault的Hub/Link/Sat結(jié)構(gòu)做增量集成每種選擇背后都有明確的假設(shè)和代價。我比較認(rèn)同一句話設(shè)計模式之所以有價值恰恰因?yàn)樗恰坝屑s束的”。沒有約束的建模每個人都能說出理由來最后模型一定爛。舉一個很常見的場景業(yè)務(wù)方提了個指標(biāo)叫“銷售額”有人說按支付時間算有人說按下單時間算還有人說按發(fā)貨時間算。如果模型里沒有對訂單事實(shí)表的粒度做硬性約束這些口徑會長期共存下游每張報表各寫一套過濾邏輯。數(shù)據(jù)中臺想做到“一處定義、處處引用”就得靠標(biāo)準(zhǔn)建模模式把約束固化到表結(jié)構(gòu)里。數(shù)據(jù)模型設(shè)計模式和軟件開發(fā)的設(shè)計模式還有一個非常像的地方都沒有銀彈。任何一種建模模式都有它的適用場景和反模式。如果不分青紅皂白地全域采用某一種模式就等于把軟件開發(fā)里“所有問題都用單例解決”的壞味道搬到了數(shù)據(jù)領(lǐng)域。2. 中臺里最常用的三套建模模式維度建模、Data Vault、湖倉新范式2.1 維度建模中臺DWD層當(dāng)之無愧的主力模式維度建模是Kimball提出的方法論核心就是事實(shí)表加維度表。在中臺體系里這套模式至今仍是DWD層最實(shí)用的設(shè)計套路。我先說結(jié)論如果你的中臺主要承載BI報表和指標(biāo)分析又缺資深數(shù)據(jù)建模師維度建模是默認(rèn)選項(xiàng)不要糾結(jié)。事實(shí)表和維度表怎么區(qū)分我習(xí)慣用一個簡單的判斷題這張表記錄的是“發(fā)生的一件事”還是描述這個事“是誰、在哪、什么時間、什么屬性”比如訂單表里記錄了訂單金額、下單時間、支付時間這就是典型的事實(shí)。而商品表里的商品名稱、品類、品牌就是典型的維度。事實(shí)表會持續(xù)增加新行記錄新發(fā)生的事件維度表的主鍵保持不變但屬性會隨時間變化。在維度建模中從“買一送一”甚至“買一送多”變成“一對多”或“多對多”的。做數(shù)據(jù)模型時一定要對這層關(guān)系做明確限定否則后面跑數(shù)會產(chǎn)生嚴(yán)重的重復(fù)計算而且一線業(yè)務(wù)人員很難發(fā)現(xiàn)這個數(shù)據(jù)水分等發(fā)現(xiàn)問題時報表早就發(fā)到各業(yè)務(wù)群了這是高危問題。其實(shí)實(shí)戰(zhàn)中大量維度已經(jīng)退化了。比如訂單號它本身可以作為一個維度來描述訂單的各種屬性但更多時候我們在事實(shí)表里直接保留訂單號同時把訂單屬性的其他字段都退化到事實(shí)表里形成一張大寬表。為什么這樣干因?yàn)槎嘁淮侮P(guān)聯(lián)就多一次IO和計算在中臺的DWD層我們優(yōu)先保證的是查詢性能和數(shù)據(jù)易用性。很多直接用BI工具做自助分析的業(yè)務(wù)同事你讓他去關(guān)聯(lián)一張幾十個字段的維表他會崩潰你把維表字段直接冗余到事實(shí)表業(yè)務(wù)用起來就順手得多。2.2 維度建模的進(jìn)階緩慢變化維和代理鍵要提前想清楚維度建模有個核心概念叫“緩慢變化維”SCDSlowly Changing Dimension這是中臺數(shù)據(jù)模型設(shè)計必須提前想清楚的問題因?yàn)闃I(yè)務(wù)維度的屬性會變——用戶的手機(jī)號會換、商品會從一個類目調(diào)整到另一個類目、員工會從A部門調(diào)到B部門。而數(shù)據(jù)中臺的指標(biāo)必須能回溯歷史你不能用戶換了個手機(jī)號他過去一年的訂單全都算到新手機(jī)號這邊。處理緩慢變化維最常用的三種策略SCD1是直接覆蓋只保留最新值實(shí)現(xiàn)簡單但不保留歷史SCD2是增加一條新記錄把舊記錄標(biāo)記為失效保留完整歷史分析“當(dāng)時是什么”很有用SCD3是增加“當(dāng)前值”和“原值”兩列只能保留最近一次變化。中臺里最常用的是SCD2。SCD2落地時我建議至少加四個字段valid_from生效時間valid_to失效時間默認(rèn)9999-12-31is_current是否當(dāng)前版本管理上用0/1標(biāo)記查詢當(dāng)前態(tài)時效率高出不少version_no版本號實(shí)際執(zhí)行時每次同步來源表要開一個窗口——把當(dāng)前有效記錄的valid_to更新為新記錄生效時間的前一秒再插入一條新的“當(dāng)前”記錄。ETL邏輯稍復(fù)雜一點(diǎn)但能保證你在任意一個時間點(diǎn)切進(jìn)去都能還原當(dāng)時維度的情況。代理鍵同樣值得注意。很多直接從業(yè)務(wù)庫同步過來的維度表直接用業(yè)務(wù)主鍵當(dāng)維表主鍵遇到源系統(tǒng)里主鍵復(fù)用或更新刪除的情況就會出問題。代理鍵就是給每一行維度記錄一個與業(yè)務(wù)無關(guān)的自增ID。這個鍵保證了幾件事歷史記錄和當(dāng)前記錄能同時存在不沖突、事實(shí)表關(guān)聯(lián)不受業(yè)務(wù)鍵變化影響、ETL對賬時有唯一追蹤依據(jù)。所以我在設(shè)計統(tǒng)一維表時都會加一個無業(yè)務(wù)含義的dim_id作為代理鍵業(yè)務(wù)主鍵只作為普通屬性保留在biz_key字段里。2.3 Data Vault模式適合多源集成和審計需求強(qiáng)烈的場景Data Vault是另一種被中臺團(tuán)隊討論很多的建模模式但真正落地的不如維度建模那么多。它的核心思路是把業(yè)務(wù)實(shí)體、實(shí)體之間的關(guān)系、實(shí)體的屬性分成三種結(jié)構(gòu)Hub核心業(yè)務(wù)實(shí)體保存業(yè)務(wù)主鍵比如客戶、產(chǎn)品、訂單Link實(shí)體之間的關(guān)系保存關(guān)系雙方的主鍵比如“客戶下單”這個Link記錄了customer_id和order_id的關(guān)聯(lián)Sat實(shí)體的屬性和狀態(tài)變化比如客戶名稱、電話、地址這些會變化的屬性都放在Sat里這種拆法的設(shè)計動機(jī)非常清晰用標(biāo)準(zhǔn)化的結(jié)構(gòu)來應(yīng)對源系統(tǒng)變化。Hub和Link的核心身份穩(wěn)定業(yè)務(wù)系統(tǒng)再怎么改字段、加屬性都只是往Sat里加列不需要改動已有結(jié)構(gòu)。Data Vault在數(shù)據(jù)集成層也就是中臺的DWD以下有明顯的優(yōu)勢特別是當(dāng)源系統(tǒng)多、數(shù)據(jù)質(zhì)量參差不齊、審計要求又高的時候。我在一個零售中臺項(xiàng)目里試過Data Vault用在訂單集成層它帶來的最大好處是加載性能驚人——因?yàn)镠ub和Link的主鍵不更新只插入不需要維護(hù)狀態(tài)版本ETL幾乎不用做復(fù)雜的update操作加載時間遠(yuǎn)低于SCD2的加工鏈路。但代價也很明顯Data Vault對業(yè)務(wù)分析師極不友好Sat表動輒十多個擴(kuò)展列怎么拼出一張可讀性好的下單事實(shí)表還得再做一層視圖或?qū)挶?。所以我的建議是Data Vault適合作為中臺的“運(yùn)營數(shù)據(jù)存儲”層用它來承接多源原始數(shù)據(jù)并保證可追溯性但在DWD和ADS層仍然要落成維度建模風(fēng)格的表。純Data Vault一把梭所有層團(tuán)隊協(xié)作和血糖尿酸都會失控迭代。核心思想是集成層使用Data Vault建模分析層使用維度建模兩者并不互斥。雖然會多出DWD、DWS到ADS加工的層級往返但換來的是可審計、可回溯和高擴(kuò)展性。2.4 湖倉時代的模型設(shè)計從固定表結(jié)構(gòu)走向開放Schema近幾年數(shù)據(jù)中臺都在湖倉化Iceberg、Hudi、Delta Lake這些湖格式讓“建?！边@件事發(fā)生了兩個重要的變化一是表和文件的Schema可以演進(jìn)加列不用再重建表二是支持了ACID事務(wù)流批可以共用一套存儲。于是模型設(shè)計上出現(xiàn)了一些新設(shè)計模式。最典型的是“寬表延遲物化”模式。以前你怎么都得在ODS或DWD階段把所有可能用到的字段都塞進(jìn)去因?yàn)楸斫Y(jié)構(gòu)定了不好改?，F(xiàn)在可以先把明細(xì)數(shù)據(jù)作為主表存放在數(shù)據(jù)湖中明確定義初級的模型結(jié)構(gòu)等真實(shí)分析場景和統(tǒng)計口徑沉淀清楚再通過增量列補(bǔ)丁的方式逐步完善模型寬表的結(jié)構(gòu)。該利用Iceberg這種可先定義原子字段而后續(xù)增加冗余、演化列的能力避免過早固化存儲結(jié)構(gòu)大幅減少早期設(shè)計返工的推倒重來。另一個湖倉帶來的新設(shè)計模式是“流批同表”——一套模型同時服務(wù)于實(shí)時鏈路和離線鏈路。以前實(shí)時鏈路基本是獨(dú)立建一套Kafka主題加OLAP表與離線模型不對齊導(dǎo)致實(shí)時和離線指標(biāo)打架現(xiàn)在主流方案是在Iceberg這類湖格式上建統(tǒng)一主表明細(xì)層實(shí)時寫入以微批的形式打進(jìn)去下游分析直接用這張表。這個模式的有效實(shí)現(xiàn)比想象中要難因?yàn)樗蕾嚤斫Y(jié)構(gòu)設(shè)計的一體化——實(shí)時和離線字段、主鍵、分區(qū)策略必須完全一致。建模時就得按“CDC增量事件全量快照”這種雙語義來設(shè)計這對模型設(shè)計者的要求比傳統(tǒng)數(shù)倉高很多。3. 中臺模型分層的通用做法與設(shè)計模式落位3.1 分層是模型設(shè)計的頂層框架數(shù)據(jù)中臺的模型設(shè)計做得好不好分層是第一步。現(xiàn)在業(yè)界基本形成了ODS、DWD、DWS、ADS這樣的分層共識。不同公司命名略有差異但本質(zhì)一致。我個人在做新的數(shù)據(jù)中臺架構(gòu)時會在這四層之外再加一層“統(tǒng)一維度層”。維度建模里Kimball一直強(qiáng)調(diào)“一致性維度”——全公司只有一個客戶維度、一個商品維度所有事實(shí)表都要關(guān)聯(lián)這一套維度。這一個原則沒有體現(xiàn)在四層結(jié)構(gòu)里往往是各層級在建設(shè)過程中各建各的維度表最終出現(xiàn)了客戶維度表在DWD層有訂單維度、在DWS層又搞一個匯總客戶維度表的情況兩套客戶維度代碼不同、屬性不同指標(biāo)對比自然就爆雷了。統(tǒng)一維度層就是強(qiáng)制把全公司核心維度客戶、商品、組織、渠道、日期的設(shè)計納入統(tǒng)一管理由中臺團(tuán)隊集中維護(hù)。所有事實(shí)表需要關(guān)聯(lián)維度時一律從統(tǒng)一維度層讀取不允許自己再造一套。各層推薦的模型設(shè)計模式如下分層功能定位推薦設(shè)計模式主要產(chǎn)出ODS原樣接入各業(yè)務(wù)源數(shù)據(jù)鏡像表/Data Vault簡化版貼源增量表、全量表DWD清洗、標(biāo)準(zhǔn)化、明細(xì)整合維度建模事實(shí)表DIM統(tǒng)一維度明細(xì)事實(shí)表、維表DWS按主題做輕度匯總多維匯總表、寬表按日/周匯總、用戶維匯總ADS應(yīng)用級數(shù)據(jù)業(yè)務(wù)自定義寬表、Cube報表、接口、指標(biāo)集市3.2 ODS別過度設(shè)計DWD才見建模功夫我見過不少團(tuán)隊把ODS層也設(shè)計得非常復(fù)雜加了各種清洗邏輯、類型轉(zhuǎn)換、甚至做了數(shù)據(jù)標(biāo)準(zhǔn)化后再落表。這里我直接給一個判斷ODS層的設(shè)計模式就是“盡量保持原樣”越簡單越好。ODS是數(shù)據(jù)中臺和數(shù)據(jù)源之間的緩沖。因?yàn)樵聪到y(tǒng)的變動、補(bǔ)數(shù)、數(shù)據(jù)質(zhì)量問題是常態(tài)ODS如果加了太多業(yè)務(wù)邏輯一旦源系統(tǒng)數(shù)據(jù)結(jié)構(gòu)變化追溯問題時會非常困難。我的做法是ODS只做簡單的增量/全量同步按業(yè)務(wù)主鍵做冪等處理最多對時間字段做統(tǒng)一格式化別的加工一律不管。ODS表的命名和源表保持一致字段類型以源系統(tǒng)為主這樣數(shù)據(jù)團(tuán)隊遇到對不上的數(shù)據(jù)能直接在ODS層定位是數(shù)據(jù)source本身的問題還是中臺加工的問題。真正的建模功夫在DWD。DWD的設(shè)計目標(biāo)是把跨業(yè)務(wù)系統(tǒng)的數(shù)據(jù)整合成一套統(tǒng)一、干凈的明細(xì)數(shù)據(jù)。這里有幾個關(guān)鍵動作統(tǒng)一編碼規(guī)則比如訂單來源線上電商可能叫“1”、線下POS可能叫“A”DWD里必須統(tǒng)一成一套枚舉統(tǒng)一單位與幣種金額統(tǒng)一用分還是元匯率如何處理必須在DWD層完成統(tǒng)一時間口徑所有時間字段明確是業(yè)務(wù)時間還是系統(tǒng)時間清洗與去重明細(xì)數(shù)據(jù)在DWD層要完成主鍵去重、非法數(shù)據(jù)剔除DWD的設(shè)計模式我強(qiáng)烈建議以維度建模為主。事實(shí)表明確描述業(yè)務(wù)過程比如下單事實(shí)表、支付事實(shí)表、發(fā)貨事實(shí)表。每個業(yè)務(wù)過程單獨(dú)建事實(shí)表不要一上來就想做一張“萬能大寬表”把下單、支付、售后全塞進(jìn)去那會導(dǎo)致嚴(yán)重的數(shù)據(jù)發(fā)散。3.3 DWS層如何用“公共匯總模式”減少重復(fù)加工DWS層是為了讓下游應(yīng)用不必每次都面對幾百億行的DWD明細(xì)做聚合。最好的模式是建立一套公共匯總模型做到“一次加工、多處復(fù)用”。這里推薦構(gòu)建多維匯總事實(shí)表主鍵是維度組合加時間粒度。舉個例子在交易域DWS層可以建一張交易匯總事實(shí)表主鍵是“日期渠道商品店鋪”。DWD層的每一筆訂單明細(xì)都會被聚合到這張匯總表對應(yīng)的維度組合中。這樣運(yùn)營要看某店鋪某天某渠道的銷售GMV時直接查DWS表不需要跑DWD明細(xì)。財務(wù)要做月度結(jié)算時同樣直接基于這張表。更常見的做法是“多粒度匯總”同一張匯總表分三份產(chǎn)出日匯總、周匯總、月匯總。周和月不采用“累加日匯總”的方式實(shí)現(xiàn)否則日表的某個數(shù)據(jù)修正后周表和月表也得跟著修正。做增量刷新時采用按月數(shù)據(jù)由全量月事實(shí)重算來實(shí)現(xiàn)避免累計誤差污染。設(shè)計匯總表時的細(xì)節(jié)問題如果你的匯總表里要放“金額”和“數(shù)量”并且后續(xù)可能會加“上年同期”“環(huán)比”這類衍生指標(biāo)建議把基礎(chǔ)事實(shí)和衍生指標(biāo)分開兩張表或在字段注釋里明確標(biāo)注而非強(qiáng)行全部放進(jìn)一張極寬的表。上游表一張寬表動輒四五百個字段一旦需要加字段就要全表重刷存儲和運(yùn)維成本都是負(fù)擔(dān)。3.4 公共維度層設(shè)計模式里的“單例模式”把統(tǒng)一維度層的設(shè)計單獨(dú)拿出來強(qiáng)調(diào)是因?yàn)樗趯?shí)際中臺項(xiàng)目中被破壞的頻率最高。如果說維度建模的“事實(shí)表”是中臺數(shù)據(jù)模型的產(chǎn)物那“統(tǒng)一維度”就是建模中的單例——全公司只能有一份絕不允許多實(shí)例。設(shè)計維度模型時我會重點(diǎn)考慮這幾個點(diǎn)主鍵策略用代理鍵還是自然鍵、SCD策略用1/2/3哪一種、維度的層次結(jié)構(gòu)比如類目層級是固定三層還是可變多層。這里面類目層級是典型的易翻車點(diǎn)。電商的類目經(jīng)常調(diào)整類目層級從樹形變成了有向圖。常見的錯誤做法是直接用三列存一級類目、二級類目、三級類目。今天某個類目從二級調(diào)整到三級下游所有匯總表就要重刷。我的做法是維度表只保存當(dāng)前類目關(guān)系把層級關(guān)系以“遞歸映射”的形式保留parent_id各級匯總報表統(tǒng)一用遞歸查詢邏輯處理。這樣類目調(diào)整時只有變更的維度記錄需要更新事實(shí)表完全不受影響。日期維度表我每次都建議單列一張可能有人覺得日期表有必要做成表嗎其實(shí)非常有必要因?yàn)橹信_幾乎所有指標(biāo)都會涉及到工作日、自然周、節(jié)假日而這些判斷邏輯高度重復(fù)。做一張標(biāo)準(zhǔn)的日期維度表把年、季、月、周、日、工作日標(biāo)記、節(jié)假日標(biāo)記、是否月末全部算好下游各層一律關(guān)聯(lián)它節(jié)假日調(diào)整只需要改一張表不用到處改口徑。4. 選型不是選最先進(jìn)的是選匹配團(tuán)隊現(xiàn)狀的4.1 多維評估從數(shù)據(jù)質(zhì)量到團(tuán)隊能力看這五個維度數(shù)據(jù)模型的三種主要模式——維度建模、Data Vault、湖倉建模——不是替代關(guān)系而是分層共存的伙伴關(guān)系。但具體到某一張表怎么選我建議從這五個維度評估。第一是源系統(tǒng)數(shù)據(jù)的穩(wěn)定性。如果業(yè)務(wù)源系統(tǒng)里的字段三天兩頭改、主鍵混亂那DWD層貿(mào)然做維度建模會很痛苦因?yàn)槟憬ǖ木S度和事實(shí)關(guān)系經(jīng)常被源系統(tǒng)的變化打斷。這時集成層用Data Vault的Hub/Link/Sat思路承接再由標(biāo)準(zhǔn)模板加工成維度模型應(yīng)用層會更從容。第二是需求的變化速度。如果業(yè)務(wù)方的數(shù)據(jù)分析需求還處于快速試錯階段今天要這個維度組合、明天要那個布局提前把模型設(shè)計得過度精細(xì)反而浪費(fèi)。在分析層直接用寬表的ES或ClickHouse、StarRocks頻繁試驗(yàn)讓模型跟隨需求演化成型之后再規(guī)范化會讓數(shù)據(jù)團(tuán)隊的壓力小很多。第三是團(tuán)隊的建模能力。數(shù)據(jù)建模是個專業(yè)活具備較強(qiáng)建模能力的團(tuán)隊才能用Data Vault。如果你團(tuán)隊的主要精力都耗在SQL取數(shù)和臨時需求支持上那就老老實(shí)實(shí)用維度建模至少它簡單、共識度高、出活快。Data Vault在集成上確實(shí)優(yōu)雅但一個不熟練的團(tuán)隊會在Sat表的擴(kuò)展維護(hù)上把時間全搭進(jìn)去。第四是數(shù)據(jù)量真實(shí)水平。很多中臺方案動不動就說自己上PB級數(shù)據(jù)實(shí)際上大部分公司的數(shù)據(jù)規(guī)模在百TB量級以內(nèi)。這個體量下維度建模合理的分區(qū)/索引已經(jīng)完全夠用不需要為了“超大管網(wǎng)”的假設(shè)犧牲開發(fā)效率和應(yīng)用靈活性。第五是成本和性能之間的平衡。維度建模的寬表理念本質(zhì)上是“以存儲換時間”。大量字段冗余進(jìn)事實(shí)表查詢確實(shí)快但存儲和計算成本也隨之增加。如果對數(shù)據(jù)量和成本空間不敏感寬表模式確實(shí)方便成本壓力比較大就需要更克制的模型設(shè)計和對查詢模式的預(yù)判優(yōu)化。4.2 按場景走三個典型決策路徑不用把選型抽象成理論真實(shí)項(xiàng)目里大多數(shù)是中臺建設(shè)走向中期的實(shí)際決策。這里直接給三個我遇到過的典型場景和對應(yīng)決策路徑。第一個是集團(tuán)型公司多個子公司都在接入中臺數(shù)據(jù)模型需要兼容各種各樣的源系統(tǒng)。這種場景下ODS到DWD之間的集成層適合引入Data Vault模式關(guān)鍵是把跨子公司沖突字段的管理放在標(biāo)準(zhǔn)化的Sat結(jié)構(gòu)里。核心KPI的分析層用維度建模但不同公司的數(shù)據(jù)口徑由于業(yè)務(wù)差異大不能強(qiáng)制統(tǒng)一因此需要額外的“口徑映射層”。第二個是業(yè)務(wù)波動大、指標(biāo)口徑在快速變化的互聯(lián)網(wǎng)公司。很多分析都是探索性的今天要看平臺補(bǔ)貼效率明天可能換社交裂變角度分析。這種情況下模型設(shè)計要輕DWD只保留最細(xì)粒度的明細(xì)不做過多冗余計算DWS做輕度匯總主題ADS才能靈活組合指標(biāo)。早期就上維度建模的大寬表等口徑變了改表的重成本會很酸爽。第三個是傳統(tǒng)企業(yè)數(shù)字化轉(zhuǎn)型數(shù)據(jù)量沒那么夸張但業(yè)務(wù)流程標(biāo)準(zhǔn)。這種場景下維度建模最合適周期短、見效快、業(yè)務(wù)也容易理解。傳統(tǒng)企業(yè)數(shù)據(jù)團(tuán)隊往往不大如果直接上Data Vault這套標(biāo)準(zhǔn)化的建模思路在人員不充足的時候會變得很重維度建模加幾個核心維表就可以先支撐財務(wù)月結(jié)和領(lǐng)導(dǎo)駕駛艙這類核心輸出。模式不是越新越好能最大程度利用現(xiàn)有團(tuán)隊維持長期建設(shè)節(jié)奏的才是正確的選擇。4.3 混合模式組合模型設(shè)計沒有銀彈但可以有最優(yōu)解實(shí)際的模型設(shè)計從來不是只能用一種模式。我做中臺這么久最終會發(fā)現(xiàn)演進(jìn)路徑基本都是組合型ODS是簡單的鏡像模式集成層用貼近Data Vault的三個對象拆分邏輯管理多源數(shù)據(jù)DWD和DWS層用維度建模形成統(tǒng)一事實(shí)和維度ADS層再根據(jù)應(yīng)用需求采用寬表或Cube。這個混合模式的核心難點(diǎn)在Data Vault向維度建模的轉(zhuǎn)換這是ETL里最復(fù)雜的一段要把Sat.客戶表的多行狀態(tài)記錄按維度模型要求處理成SCD2的當(dāng)前和歷史版本把Link的多對多關(guān)系解析成事實(shí)表外鍵。處理不好結(jié)果就是數(shù)據(jù)丟或者重復(fù)。解決這個問題我建議搭建一條成體系的轉(zhuǎn)換模板按照映射字段標(biāo)準(zhǔn)完成處理而不是每次都新寫SQL這樣可維護(hù)性會高很多。這套組合本身也構(gòu)成了中臺里的一條數(shù)據(jù)生產(chǎn)線——從多源異構(gòu)數(shù)據(jù)到統(tǒng)一模型再到可復(fù)用指標(biāo)。你想清楚每一段用哪種模式團(tuán)隊的執(zhí)行才有了標(biāo)準(zhǔn)作業(yè)程序。每個數(shù)據(jù)開發(fā)拿到需求時第一反應(yīng)不是“這個需求我要怎么寫SQL”而是“這個需求對應(yīng)到哪個層的哪個模式”這是數(shù)據(jù)中臺建模能力成熟的重要標(biāo)志。5. 實(shí)戰(zhàn)中模型設(shè)計最容易踩的坑與排查方法5.1 建模階段容易埋雷的五個反模式模型設(shè)計階段踩坑后患無窮。這里直接給一份反模式清單感覺都踩過第一是主鍵不統(tǒng)一源表用自增ID業(yè)務(wù)上又要用訂單號關(guān)聯(lián)時間一久關(guān)系就亂了第二是對賬體系欠缺每一層的行數(shù)變化、金額匯總只能在報表里憑感覺第三是“萬能事實(shí)表”的陷阱下單一件事里把支付、退款、評價都揉進(jìn)同一張表造成多維分析時數(shù)據(jù)成倍膨脹第四是維度表SCD策略不透明下游各取所需導(dǎo)致對照解讀一團(tuán)亂麻分析結(jié)果對不上第五是分區(qū)策略拍腦袋用日期分就好結(jié)果業(yè)務(wù)查詢習(xí)慣按店鋪維度跑全表掃描極其耗時。關(guān)于主鍵缺失問題這里多說一句有些業(yè)務(wù)系統(tǒng)根本沒有主鍵同一張表里的記錄連唯一標(biāo)識都沒有。接入中臺時必須在ODS層就幫它補(bǔ)一個技術(shù)主鍵不然后面做增量同步、做去重、做關(guān)聯(lián)全部寸步難行。這個主鍵一般用“源表標(biāo)識同步批次行序號”的方式來生成保證全局唯一且可溯源。萬能事實(shí)表的反面模式我實(shí)操過教訓(xùn)很慘烈一張訂單明細(xì)表硬塞了支付流水、退款記錄、物流軌跡等各種事件由于各業(yè)務(wù)過程的粒度還不同導(dǎo)致同一個訂單在不同統(tǒng)計口徑下被計算多次所有下游報表數(shù)據(jù)都失真。故障定位用了一周多最后決定還是按業(yè)務(wù)過程重新拆分事實(shí)表并清理數(shù)據(jù)。早知道按維度建模的標(biāo)準(zhǔn)設(shè)計這個坑完全可以避開。還有分區(qū)策略設(shè)計如果在第一天就不花半小時分析真實(shí)查詢模式后面幾個月都會替這個半小時買單。所以建模評審時我把查詢條件作為硬性指標(biāo)納入設(shè)計審查范圍。5.2 中臺模型上線后的典型數(shù)據(jù)問題速查模型設(shè)計完、ETL跑上線真正的考驗(yàn)才開始。這里整了一份我實(shí)際排查中發(fā)現(xiàn)的高頻問題參考表不一定覆蓋全部但遇到類似情況能快速定位。問題現(xiàn)象常見根因排查思路修復(fù)建議同一指標(biāo)不同報表跑數(shù)差異大口徑未在DWD層統(tǒng)一各報表各自寫過濾條件定位指標(biāo)來源表和過濾條件梳理出所有SQL版本將口徑下沉到DWS公共匯總層所有取數(shù)統(tǒng)一引用明細(xì)行數(shù)與源系統(tǒng)對不上ODS同步丟數(shù)據(jù)或重復(fù)同步對比ODS和源表行數(shù)、主鍵去重數(shù)在ODS層做冪等校驗(yàn)確認(rèn)同步依賴的主鍵邏輯關(guān)聯(lián)維表后數(shù)據(jù)膨脹事實(shí)表與維表存在一對多關(guān)系但未識別檢查維表主鍵是否有重復(fù)驗(yàn)證關(guān)聯(lián)基數(shù)對維表做唯一性約束事實(shí)表字段按最小粒度明確關(guān)聯(lián)歷史數(shù)據(jù)回溯結(jié)果變化SCD策略設(shè)計不當(dāng)維表歷史版本被覆蓋對比當(dāng)前和歷史數(shù)據(jù)的維表關(guān)聯(lián)版本統(tǒng)一改用SCD2并以快照存儲事實(shí)表數(shù)據(jù)查詢速度和引擎壓力大匯總粒度選擇過大、寬表冗余過多檢查查詢條件與表分區(qū)、索引匹配度把固定多粒度明細(xì)做預(yù)聚合驅(qū)動引擎級別的物化以減少掃描量有一類“維度退化后造成的關(guān)聯(lián)失效”問題也值得單獨(dú)說很多DWD層的寬表會把商品名稱、款號等字段直接退化進(jìn)來但商品維度表后來發(fā)生變化時寬表里的舊值已經(jīng)固化。此時除非你專門做維度歷史回溯否則歷史報表和最新報表之間的對比就會出現(xiàn)不可解釋的差異。應(yīng)對方案是你的事實(shí)明細(xì)表必須至少保留一個可回溯到當(dāng)時的維度版本鍵——通常是保留當(dāng)時的商品代理鍵同時冗余當(dāng)下的名稱。這在一定程度上會增加存儲但犧牲存儲追求可解釋性是值得的。5.3 想清兩張“審計表”讓你排查省一半力氣最后一個很實(shí)用的建議每一層做完加工建議創(chuàng)建一個自定義數(shù)據(jù)質(zhì)量審計表。我自己基本固定兩張輔助表來支撐全局排查定位。第一張是“分層血緣與行數(shù)變化表”字段大概包括層、表名、調(diào)度周期、源表行數(shù)、目標(biāo)表行數(shù)、變更類型、運(yùn)行時間。每次調(diào)度完把本周期該表的行數(shù)、變化率寫進(jìn)去。這樣如果某天某張報表數(shù)據(jù)異?？梢韵瓤词悄囊惶淖兓砍隽撕侠矸秶艽蠓i定出問題的環(huán)節(jié)而不至于大海撈針分析幾十張模型表。第二張是“指標(biāo)口徑注冊表”——數(shù)據(jù)中臺的指標(biāo)不是開發(fā)完就完了后續(xù)隨時會有新同學(xué)來問“付費(fèi)用戶數(shù)”為什么和你對不上?？趶奖淼某Ｒ娮侄斡兄笜?biāo)名稱、所屬域、模型來源表、計算邏輯、過濾條件、更新頻率、指標(biāo)負(fù)責(zé)人。這張表建議從第一天就開始維護(hù)別等指標(biāo)多了再回頭補(bǔ)。數(shù)據(jù)中臺能不能讓人信服很大程度取決于出了問題時能不能快速定位哪里的口徑和哪張表出了問題以及是否有一張表讓業(yè)務(wù)方和開發(fā)都一目了然。把指標(biāo)的歸屬責(zé)任人、口徑、取數(shù)SQL都固化成文檔本身就是模型設(shè)計模式的一部分。數(shù)據(jù)模型不只是數(shù)據(jù)庫里的表結(jié)構(gòu)還包括讓這套結(jié)構(gòu)長期保持清晰的組織約定。所有該沉淀的抽象都沉淀下來才是一個數(shù)據(jù)模型能夠持續(xù)服務(wù)業(yè)務(wù)的穩(wěn)定基礎(chǔ)。6. 一些關(guān)于模型設(shè)計模式的經(jīng)驗(yàn)總結(jié)實(shí)際把幾種設(shè)計模式在自己的項(xiàng)目里走完一遍我更確信數(shù)據(jù)模型的推進(jìn)思路是遞進(jìn)而非一步到位初期業(yè)務(wù)和團(tuán)隊都沒成熟時不要硬上高大上的建模方法先把OneData模型與分層關(guān)系落地讓分層可信當(dāng)企業(yè)模型穩(wěn)定進(jìn)入多業(yè)務(wù)系統(tǒng)擴(kuò)展期再引入Data Vault的集成思路保證可擴(kuò)展性等湖倉基礎(chǔ)設(shè)施成型后模型的演化工作交給跨層快速迭代的能力——該重構(gòu)時不要手軟。踩過太多由模型設(shè)計粗糙帶來的坑之后我的體會是模型評審要當(dāng)成與需求評審?fù)戎匾氖虑閬碜?。一張建錯的表改的不只是這張表還有下游十幾個任務(wù)、十幾張報表和數(shù)據(jù)口徑的連鎖調(diào)整。每次建模前把事實(shí)表的粒度、退化維度字段的依據(jù)、SCD策略、指標(biāo)口徑所屬層這幾個基本點(diǎn)一次性敲定模型的返工率基本能下降一半以上。最后再分享一個不算新但值得重新想起的小技巧當(dāng)你在一個“已有運(yùn)行多年系統(tǒng)”的中臺做存量模型治理別試圖一次性把歷史所有表都重構(gòu)到標(biāo)準(zhǔn)設(shè)計模式迭代路徑最好是“新需求全部按規(guī)范建模老表影響大的按優(yōu)先級分批整改整改一類再切一類”切完每個模塊后立刻做行數(shù)、金額、任務(wù)、下游查詢的整體回歸驗(yàn)證。否則一個“全量重構(gòu)”計劃大概率會在無盡的排期中原地踏步。數(shù)據(jù)模型的設(shè)計模式本質(zhì)是把你對業(yè)務(wù)的理解變成一套長期穩(wěn)定的數(shù)據(jù)契約。理解業(yè)務(wù)再選擇合適的模式剩下的就是堅持維護(hù)和持續(xù)迭代了。