簡(jiǎn)介本資源是一份面向數(shù)據(jù)工程師、數(shù)倉(cāng)開(kāi)發(fā)人員及大數(shù)據(jù)初學(xué)者的系統(tǒng)性數(shù)據(jù)模型設(shè)計(jì)指南聚焦數(shù)據(jù)倉(cāng)庫(kù)建設(shè)中模型分層、建模方法與常見(jiàn)問(wèn)題治理等核心痛點(diǎn)。文檔完整梳理ODS→CDM含DWD/DWS/DIM→ADS四級(jí)分層邏輯詳解各層定位、數(shù)據(jù)流向與設(shè)計(jì)原則并提供數(shù)據(jù)域劃分、總線矩陣構(gòu)建、指標(biāo)定義、代碼規(guī)范與命名標(biāo)準(zhǔn)等可落地的實(shí)施路徑。資源為單文件Word文檔.doc大小77KB內(nèi)容精煉、結(jié)構(gòu)清晰適合作為日常開(kāi)發(fā)參考或團(tuán)隊(duì)建模規(guī)范宣貫材料。目前已有182人學(xué)習(xí)下載讀者可直接獲取分層邊界判定方法、高內(nèi)聚低耦合建模實(shí)踐、公共層復(fù)用策略及六類典型問(wèn)題如分層混亂、主題域缺失、主鍵失當(dāng)?shù)母蚍治雠c解決方案助力提升數(shù)倉(cāng)架構(gòu)合理性與長(zhǎng)期可維護(hù)性。1. 數(shù)據(jù)倉(cāng)庫(kù)模型設(shè)計(jì)為什么“照著分層畫(huà)布寫(xiě)SQL”反而讓數(shù)倉(cāng)越建越慢你有沒(méi)有遇到過(guò)這種場(chǎng)景剛上線的DWS寬表BI看板跑得飛快但兩周后運(yùn)營(yíng)突然要加一個(gè)“用戶最近7天在非工作時(shí)段的下單轉(zhuǎn)化漏斗”開(kāi)發(fā)同學(xué)翻出那張寬表發(fā)現(xiàn)里面既沒(méi)“是否工作日”字段也沒(méi)“下單時(shí)間戳的小時(shí)級(jí)切片”更糟的是——這張表的ETL任務(wù)已經(jīng)占滿集群30%的資源連加個(gè)字段都得等凌晨調(diào)度窗口。這不是個(gè)別現(xiàn)象而是大量團(tuán)隊(duì)在“嚴(yán)格遵循ODS→DWD→DWS→ADS四層架構(gòu)”后集體踩進(jìn)的深坑。問(wèn)題不在于分層本身錯(cuò)了而在于把分層當(dāng)成了模板把維度建模當(dāng)成了填空題看到“事實(shí)表要帶時(shí)間粒度”就無(wú)腦按天分區(qū)看到“維表要一致”就把所有業(yè)務(wù)線的“用戶狀態(tài)”硬塞進(jìn)一張dim_user_status看到“DWS要寬表”就堆砌50字段哪怕其中32個(gè)字段半年沒(méi)人查。結(jié)果呢模型看似規(guī)范實(shí)則成了高耦合、低響應(yīng)、難追溯的黑匣子。真正決定數(shù)據(jù)倉(cāng)庫(kù)生死的從來(lái)不是你貼了多少?gòu)埛謱訄D而是每一層背后數(shù)據(jù)契約的清晰度、變更影響的可預(yù)測(cè)性、以及物理實(shí)現(xiàn)與業(yè)務(wù)語(yǔ)義的對(duì)齊精度。本文不講“應(yīng)該分幾層”而是帶你拆開(kāi)這份《數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)模型該如何設(shè)計(jì).doc》文檔里被輕描淡寫(xiě)的機(jī)制——為什么DWD必須冗余維度屬性為什么DWS的“寬表”不是越寬越好為什么ADS層敢直接引用DWD卻嚴(yán)禁反向依賴答案不在PPT里而在調(diào)度依賴圖的箭頭方向、在字段血緣的斷點(diǎn)位置、在一次DQC校驗(yàn)失敗時(shí)你能精準(zhǔn)定位到哪一行代碼。搞懂這些你才能從“建模執(zhí)行者”變成“數(shù)據(jù)契約設(shè)計(jì)師”。2. 分層不是畫(huà)布是數(shù)據(jù)契約的逐級(jí)封裝ODS到CDM的語(yǔ)義升維機(jī)制數(shù)據(jù)倉(cāng)庫(kù)分層常被誤解為“數(shù)據(jù)搬運(yùn)流水線”O(jiān)DS接原始數(shù)據(jù)CDM做清洗ADS供查詢。但真實(shí)機(jī)制遠(yuǎn)比這復(fù)雜——它是一套語(yǔ)義可信度逐級(jí)增強(qiáng)、計(jì)算成本逐級(jí)沉淀、業(yè)務(wù)耦合度逐級(jí)解耦的契約封裝體系。ODS層看似只是“原樣存儲(chǔ)”實(shí)則承擔(dān)著最底層的數(shù)據(jù)契約它用不可變的快照snapshot或帶事務(wù)ID的增量日志如CDC錨定源系統(tǒng)某一時(shí)刻的真實(shí)狀態(tài)。這個(gè)契約的關(guān)鍵不是“數(shù)據(jù)沒(méi)改”而是“任何下游對(duì)ODS的讀取都能通過(guò)回溯源庫(kù)binlog或備份100%復(fù)現(xiàn)其生成邏輯”。一旦這個(gè)契約被破壞比如ODS層做了隱式類型轉(zhuǎn)換、去重、或字段截?cái)嗾麄€(gè)分層體系的信任根基就崩了。CDM層含DWD/DWS/DIM則是對(duì)ODS契約的首次語(yǔ)義升維它不再承諾“和源庫(kù)一模一樣”而是承諾“在明確的業(yè)務(wù)定義下數(shù)據(jù)是可解釋、可驗(yàn)證、可復(fù)用的”。這種升維不是靠人工拍板而是通過(guò)三類強(qiáng)制約束實(shí)現(xiàn)的。2.1 DWD層以業(yè)務(wù)過(guò)程為錨點(diǎn)的“原子事實(shí)封裝”DWD層的核心不是“明細(xì)”而是“可組合的事實(shí)單元”。文檔中強(qiáng)調(diào)“以業(yè)務(wù)過(guò)程作為建模驅(qū)動(dòng)”這句話的底層機(jī)制是每個(gè)DWD表必須綁定一個(gè)且僅一個(gè)不可再分的業(yè)務(wù)動(dòng)作事件如“用戶完成支付”“商品加入購(gòu)物車”“客服創(chuàng)建工單”。這個(gè)事件決定了表的主鍵event_id business_key、時(shí)間粒度精確到毫秒的event_time、以及核心度量payment_amount, cart_item_count。關(guān)鍵在于DWD必須主動(dòng)冗余維度屬性但冗余有嚴(yán)格邊界只冗余那些在事件發(fā)生時(shí)即確定、且后續(xù)永不變更的維度信息。例如“用戶完成支付”事件中冗余user_gender、user_city_id是合理的注冊(cè)時(shí)已確定但冗余user_vip_level就不合理VIP等級(jí)可能在支付后數(shù)分鐘內(nèi)升級(jí)。這種冗余的物理實(shí)現(xiàn)在Hive/Spark SQL中表現(xiàn)為-- DWD層典型建表語(yǔ)句以支付事件為例 CREATE TABLE dwd_payment_detail ( payment_id STRING COMMENT 支付單號(hào), user_id STRING COMMENT 用戶ID, user_gender STRING COMMENT 用戶性別冗余注冊(cè)時(shí)固化, user_city_id STRING COMMENT 用戶城市ID冗余地址快照, item_id STRING COMMENT 商品ID, payment_amount DECIMAL(18,2) COMMENT 支付金額, event_time TIMESTAMP COMMENT 事件發(fā)生時(shí)間精確到毫秒, -- 注意這里不冗余user_vip_level也不冗余item_category_name品類名可能變更 dt STRING COMMENT 分區(qū)字段YYYYMMDD ) PARTITIONED BY (dt);提示DWD表的user_city_id不是簡(jiǎn)單JOIN dim_city獲取而是從源系統(tǒng)支付記錄中直接提取的shipping_city_id字段。這是為了確?！笆录l(fā)生時(shí)的城市”語(yǔ)義不被DIM層后續(xù)變更污染——DIM表可以更新城市名稱但DWD里的user_city_id永遠(yuǎn)代表那一刻的真實(shí)歸屬。2.2 DIM層維度一致性背后的“版本快照”機(jī)制DIM層常被簡(jiǎn)化為“字典表”但其真正的設(shè)計(jì)難點(diǎn)在于如何管理維度屬性的時(shí)變性Slowly Changing Dimension, SCD。文檔提到“建立一致數(shù)據(jù)分析維表”這里的“一致”不是指字段值永遠(yuǎn)相同而是指同一維度鍵如user_id在不同時(shí)間點(diǎn)的屬性快照必須能被下游無(wú)歧義地關(guān)聯(lián)和解釋。主流方案是SCD Type 2為每次維度屬性變更生成新記錄并用start_date/end_date標(biāo)記有效周期。但實(shí)際落地時(shí)很多團(tuán)隊(duì)只實(shí)現(xiàn)了“偽Type 2”——用is_current布爾字段代替時(shí)間范圍導(dǎo)致無(wú)法回溯歷史狀態(tài)。正確機(jī)制要求DIM表必須包含dim_key如user_sk代理鍵永不變更business_key如user_id業(yè)務(wù)主鍵可能重復(fù)出現(xiàn)start_date/end_date精確到秒的時(shí)間范圍is_current僅作查詢優(yōu)化不替代時(shí)間范圍-- DIM_USER表SCD Type 2實(shí)現(xiàn) CREATE TABLE dim_user ( user_sk BIGINT COMMENT 用戶代理鍵, user_id STRING COMMENT 業(yè)務(wù)用戶ID, user_gender STRING COMMENT 性別, user_city_id STRING COMMENT 城市ID, start_date DATE COMMENT 生效開(kāi)始日期, end_date DATE COMMENT 生效結(jié)束日期9999-12-31表示當(dāng)前有效, is_current BOOLEAN COMMENT 是否當(dāng)前有效由start/end_date派生 ) PARTITIONED BY (dt); -- 關(guān)鍵邏輯DWD表JOIN DIM時(shí)必須用時(shí)間范圍過(guò)濾 SELECT d.payment_id, d.user_id, u.user_gender, -- 獲取支付時(shí)刻的性別 u.user_city_id -- 獲取支付時(shí)刻的城市 FROM dwd_payment_detail d JOIN dim_user u ON d.user_id u.user_id AND d.event_time u.start_date AND d.event_time u.end_date -- 精確匹配事件發(fā)生時(shí)的維度狀態(tài) WHERE d.dt 20240520;2.3 DWS層寬表不是“字段堆砌”而是“指標(biāo)契約的物化”DWS層被文檔定義為“基于指標(biāo)需求構(gòu)建公共粒度的匯總事實(shí)表”但很多人忽略了“公共粒度”四個(gè)字的重量。所謂“公共”意味著這張表必須滿足至少兩個(gè)獨(dú)立業(yè)務(wù)方的相同粒度需求如“日粒度用戶訂單匯總”需同時(shí)支撐“GMV日?qǐng)?bào)”和“用戶復(fù)購(gòu)率分析”。而“物化”則揭示了其本質(zhì)DWS是將DWD層中分散計(jì)算的指標(biāo)邏輯固化為物理表結(jié)構(gòu)以換取查詢性能和口徑統(tǒng)一。但物化的前提是“可預(yù)測(cè)的訪問(wèn)模式”。如果某張DWS表90%的查詢只用到5個(gè)字段卻因“寬表”理念堆砌了50個(gè)字段不僅浪費(fèi)存儲(chǔ)更會(huì)因大寬表JOIN導(dǎo)致Shuffle爆炸。因此DWS設(shè)計(jì)必須回答三個(gè)問(wèn)題誰(shuí)在用—— 明確至少兩個(gè)消費(fèi)方避免“偽公共”怎么用—— 分析其SQL模式是SUM聚合還是COUNT DISTINCT決定是否需要預(yù)計(jì)算何時(shí)失效—— 定義該表的SLA如T1產(chǎn)出并配套DQC規(guī)則如dws_user_daily_summary.total_order_cnt必須等于SUM(dwd_payment_detail WHERE dtxxx)。-- DWS層典型表結(jié)構(gòu)日粒度用戶匯總 CREATE TABLE dws_user_daily_summary ( user_id STRING COMMENT 用戶ID, stat_date DATE COMMENT 統(tǒng)計(jì)日期, total_order_cnt BIGINT COMMENT 當(dāng)日訂單總數(shù), total_payment_amt DECIMAL(18,2) COMMENT 當(dāng)日支付總額, first_order_flag BOOLEAN COMMENT 是否首單用戶由DWD事件流實(shí)時(shí)判定, -- 注意不包含user_gender等維度屬性DWS只存指標(biāo)維度關(guān)聯(lián)由ADS層完成 dt STRING COMMENT 分區(qū)字段 ) PARTITIONED BY (dt);注意DWS表絕不冗余維度屬性如user_gender因?yàn)榫S度屬性屬于DIM層契約DWS只負(fù)責(zé)指標(biāo)計(jì)算。強(qiáng)行冗余會(huì)導(dǎo)致“維度漂移”——當(dāng)DIM表更新時(shí)DWS表無(wú)法自動(dòng)同步造成數(shù)據(jù)不一致。3. ADS層應(yīng)用導(dǎo)向不是“隨意發(fā)揮”而是“契約解耦的終點(diǎn)站”ADS層常被當(dāng)作“最終交付層”但文檔中一句“面向應(yīng)用邏輯的數(shù)據(jù)加工”常被誤讀為“隨便建表滿足業(yè)務(wù)就行”。真相恰恰相反ADS是整個(gè)分層體系中契約約束最嚴(yán)、解耦要求最高的一層。它的存在價(jià)值不是“讓業(yè)務(wù)更快拿到數(shù)據(jù)”而是“讓業(yè)務(wù)變化不影響公共層穩(wěn)定性”。當(dāng)運(yùn)營(yíng)提出“我要看華東區(qū)女性用戶在抖音渠道的7日復(fù)購(gòu)率”時(shí)ADS層的工作不是直接從ODS拉數(shù)據(jù)而是像拼樂(lè)高一樣從CDM層已有的積木DWD支付事件、DIM用戶維度、DWS區(qū)域匯總中組合出新視圖。這種組合必須遵循三條鐵律零源依賴、強(qiáng)契約引用、松耦合隔離。3.1 零源依賴為什么ADS嚴(yán)禁直連ODS文檔明確指出“減少對(duì)ODS的依賴”這不僅是運(yùn)維考量更是架構(gòu)契約。ODS層的Schema受源系統(tǒng)變更直接影響如電商系統(tǒng)把user_sex字段名改成user_gender若ADS表直接引用ODS一次源庫(kù)字段變更就會(huì)導(dǎo)致數(shù)十張ADS表報(bào)錯(cuò)。而CDM層DWD/DWS/DIM作為中間契約層承擔(dān)了“源系統(tǒng)變更適配器”角色ODS字段變更時(shí)只需調(diào)整DWD層的ETL邏輯如SELECT user_gender AS user_sex FROM ods_user所有下游ADS表完全無(wú)感。這種解耦的物理體現(xiàn)是ADS層SQL的FROM子句-- ? 正確ADS層只引用CDM層表 CREATE VIEW ads_douyin_female_rebuy_rate_7d AS SELECT u.user_city AS region, COUNT(DISTINCT CASE WHEN d.event_time DATE_SUB(CURRENT_DATE, 7) THEN d.user_id END) AS active_users, COUNT(DISTINCT CASE WHEN d.event_time DATE_SUB(CURRENT_DATE, 7) AND u.user_genderF THEN d.user_id END) AS female_users FROM dwd_payment_detail d -- 引用DWD非ODS JOIN dim_user u ON d.user_id u.user_id AND d.event_time BETWEEN u.start_date AND u.end_date WHERE u.user_city IN (Shanghai, Nanjing, Hangzhou) AND d.channel douyin; -- ? 錯(cuò)誤ADS直連ODS埋下崩潰隱患 -- FROM ods_payment_log d -- 源系統(tǒng)一改名全掛3.2 強(qiáng)契約引用ADS表名與字段名的“語(yǔ)義指紋”ADS層的命名不是風(fēng)格問(wèn)題而是契約聲明。文檔強(qiáng)調(diào)“命名清晰可理解”其深層機(jī)制是表名和字段名必須成為下游消費(fèi)方的“語(yǔ)義指紋”無(wú)需查文檔就能推斷數(shù)據(jù)含義和時(shí)效性。例如表名ads_user_churn_risk_score_dads_前綴聲明應(yīng)用層身份user_churn_risk_score表明業(yè)務(wù)語(yǔ)義用戶流失風(fēng)險(xiǎn)分_d后綴明確T1日粒度字段名churn_risk_score而非scoreis_churn_risk_high而非flag。這種命名強(qiáng)制開(kāi)發(fā)者在建表時(shí)思考“這個(gè)分?jǐn)?shù)的計(jì)算邏輯是什么它的業(yè)務(wù)定義在哪里”——答案必須指向CDM層某張DWS表或DWD表的某個(gè)字段。當(dāng)BI工程師在Tableau里看到churn_risk_score他應(yīng)該能立刻在數(shù)據(jù)目錄中定位到該字段源自dws_user_risk_profile_d.churn_risk_score而后者又由dwd_user_behavior_event中連續(xù)7天的登錄、瀏覽、加購(gòu)行為聚合得出。這種可追溯性才是“命名規(guī)范”的終極目的。3.3 松耦合隔離集市域Mart Domain的物理邊界文檔提出“劃分集市域、共性抽象下沉”其技術(shù)實(shí)現(xiàn)是通過(guò)Hive/StarRocks的Database或Schema級(jí)隔離強(qiáng)制ADS表只能跨集市域依賴禁止同集市域內(nèi)表互相引用。例如mart_user庫(kù)存放所有用戶相關(guān)ADS表ads_user_profile_d,ads_user_retention_wmart_product庫(kù)存放所有商品相關(guān)ADS表ads_product_sales_m,ads_product_hot_rank_d。規(guī)則mart_user.ads_user_profile_d可以引用cdm.dws_user_daily_summary但絕不允許引用mart_product.ads_product_sales_m。否則當(dāng)商品團(tuán)隊(duì)重構(gòu)銷售模型時(shí)用戶團(tuán)隊(duì)的報(bào)表會(huì)意外中斷。這種隔離在SQL層面通過(guò)權(quán)限控制實(shí)現(xiàn)在調(diào)度層面通過(guò)任務(wù)分組隔離。其效果是每個(gè)集市域成為獨(dú)立演進(jìn)單元一個(gè)域的迭代不影響其他域——這才是“松耦合”的工程落地。4. 避坑數(shù)據(jù)模型設(shè)計(jì)中5個(gè)血淚經(jīng)驗(yàn)換來(lái)的高頻翻車點(diǎn)在上百個(gè)數(shù)倉(cāng)項(xiàng)目中以下問(wèn)題反復(fù)出現(xiàn)且往往在上線后才暴露修復(fù)成本極高。它們不是“配置錯(cuò)誤”而是對(duì)分層契約機(jī)制理解偏差導(dǎo)致的系統(tǒng)性風(fēng)險(xiǎn)。4.1 現(xiàn)象DWS寬表查詢?cè)絹?lái)越慢CPU使用率長(zhǎng)期90%原因DWS表設(shè)計(jì)時(shí)未區(qū)分“高頻訪問(wèn)字段”和“低頻訪問(wèn)字段”將所有可能用到的指標(biāo)包括月度、季度、年度累計(jì)值全部堆砌在一張表里。導(dǎo)致每次查詢即使只用1個(gè)字段也要掃描整行Hive/ORC格式按行存儲(chǔ)Shuffle數(shù)據(jù)量暴增。解決按訪問(wèn)熱度垂直拆分DWS表。例如dws_user_daily_active_d只存日活、日均停留時(shí)長(zhǎng)等T1必查字段dws_user_monthly_accumulate_m單獨(dú)存月累計(jì)訂單數(shù)、月總支付額等低頻字段在ADS層通過(guò)UNION或VIEW組合而非在DWS層強(qiáng)行合并。4.2 現(xiàn)象BI看板顯示“用戶性別分布”突變但源系統(tǒng)確認(rèn)未修改原因DIM_USER表未正確實(shí)現(xiàn)SCD Type 2而是用is_currentTRUE標(biāo)記最新記錄。當(dāng)用戶修改性別時(shí)舊記錄被is_currentFALSE覆蓋但DWD表JOIN時(shí)未加時(shí)間條件導(dǎo)致歷史事件關(guān)聯(lián)到新性別。解決強(qiáng)制DIM表必須包含start_date/end_date且DWD層所有JOIN必須顯式添加時(shí)間范圍條件如d.event_time BETWEEN u.start_date AND u.end_date。在DQC中增加校驗(yàn)COUNT(*) FROM dim_user WHERE is_currentTRUE必須等于COUNT(DISTINCT user_id) FROM dim_user否則告警。4.3 現(xiàn)象ADS層新增一個(gè)“用戶地域偏好”指標(biāo)開(kāi)發(fā)耗時(shí)3天上線后發(fā)現(xiàn)數(shù)據(jù)不準(zhǔn)原因該指標(biāo)需關(guān)聯(lián)用戶收貨地址來(lái)自O(shè)DS_USER和商品類目來(lái)自O(shè)DS_ITEM但開(kāi)發(fā)直接在ADS層寫(xiě)兩層JOIN未檢查ODS層地址和類目表的分區(qū)策略是否對(duì)齊如ODS_USER按dt分區(qū)ODS_ITEM按update_dt分區(qū)導(dǎo)致JOIN結(jié)果為空。解決所有ADS層涉及多源JOIN的邏輯必須先在DWD層構(gòu)建“地址-用戶”和“類目-商品”兩張關(guān)聯(lián)表確保它們與DWD事件表共享同一分區(qū)字段dt。ADS層只做單表聚合杜絕跨源JOIN。4.4 現(xiàn)象DWD層某張表每天產(chǎn)出延遲2小時(shí)拖累整個(gè)DWS鏈路原因該DWD表為提升“易用性”冗余了半結(jié)構(gòu)化字段如user_attributes JSON并在ETL中解析JSON提取20個(gè)字段。JSON解析是CPU密集型操作且無(wú)法并行化。解決DWD層嚴(yán)格遵循“原子性”原則——半結(jié)構(gòu)化字段只做原始存儲(chǔ)user_attributes STRING解析邏輯下沉到ADS層按需進(jìn)行。若必須解析應(yīng)在DWS層用UDF預(yù)計(jì)算成結(jié)構(gòu)化字段DWD保持輕量。4.5 現(xiàn)象運(yùn)營(yíng)反饋“昨日訂單數(shù)”和“BI看板訂單數(shù)”差5%DQC監(jiān)控卻顯示通過(guò)原因DQC規(guī)則只校驗(yàn)dws_order_daily.total_cnt SUM(dwd_order_detail)但未校驗(yàn)時(shí)間范圍。DWD表中存在event_time為未來(lái)時(shí)間如測(cè)試數(shù)據(jù)寫(xiě)入的臟數(shù)據(jù)被計(jì)入SUM而DWS表的WHERE條件stat_date dt過(guò)濾掉了這些數(shù)據(jù)。解決DQC必須包含“時(shí)間有效性”校驗(yàn)SELECT COUNT(*) FROM dwd_order_detail WHERE event_time CURRENT_DATE INTERVAL 1 DAY必須為0同時(shí)DWS層ETL必須增加WHERE event_time CURRENT_DATE過(guò)濾。5. 公共層設(shè)計(jì)的終極取舍復(fù)用性、時(shí)效性、穩(wěn)定性的三角平衡當(dāng)你站在DWD/DWS設(shè)計(jì)決策點(diǎn)上文檔里那些“復(fù)用性”“易用性”“穩(wěn)定性”原則最終都會(huì)坍縮為一個(gè)具體問(wèn)題這張表到底為誰(shuí)服務(wù)服務(wù)到什么程度這不是哲學(xué)思辨而是每天要做的工程權(quán)衡。我見(jiàn)過(guò)太多團(tuán)隊(duì)在“追求極致復(fù)用”上翻車——為覆蓋未來(lái)三年所有可能的分析場(chǎng)景DWS表設(shè)計(jì)成100字段的“超級(jí)寬表”結(jié)果上線后發(fā)現(xiàn)80%字段從未被查詢而核心的5個(gè)字段因表過(guò)大導(dǎo)致查詢超時(shí)。也見(jiàn)過(guò)另一些團(tuán)隊(duì)走向反面為保時(shí)效DWS層只做最小粒度聚合如dws_user_hourly_active_h結(jié)果ADS層為算一個(gè)周留存要JOIN 168張小時(shí)表任務(wù)直接OOM。真正的平衡點(diǎn)在于理解這三個(gè)維度的本質(zhì)矛盾維度目標(biāo)技術(shù)代價(jià)典型妥協(xié)方案復(fù)用性覆蓋更多業(yè)務(wù)方、更多分析場(chǎng)景存儲(chǔ)成本↑、ETL復(fù)雜度↑、變更風(fēng)險(xiǎn)↑按“最大公約數(shù)粒度”設(shè)計(jì)如DWS層不建“子公司粒度”和“一級(jí)類目粒度”兩張表而是建“SKU粒度”表讓下游按需GROUP BY聚合時(shí)效性縮短數(shù)據(jù)從產(chǎn)生到可用的時(shí)間計(jì)算資源↑、運(yùn)維復(fù)雜度↑、數(shù)據(jù)一致性風(fēng)險(xiǎn)↑分層SLA分級(jí)DWD層T1保證準(zhǔn)確性DWS層核心指標(biāo)T1長(zhǎng)周期指標(biāo)如年同比T2ADS層按需加速如用Flink實(shí)時(shí)補(bǔ)數(shù)據(jù)穩(wěn)定性下游任務(wù)不因上游變更而失敗開(kāi)發(fā)成本↑、靈活性↓、創(chuàng)新速度↓契約接口化DWD表提供get_user_profile(user_id, as_of_date)UDF屏蔽DIM表結(jié)構(gòu)變更DWS表提供get_daily_metrics(date)視圖隱藏底層分區(qū)邏輯最關(guān)鍵的實(shí)踐是永遠(yuǎn)用“最小可行契約”啟動(dòng)。不要一上來(lái)就設(shè)計(jì)覆蓋全公司的DWS寬表。先問(wèn)當(dāng)前最痛的3個(gè)業(yè)務(wù)需求是什么它們共用的最小數(shù)據(jù)集是什么例如電商團(tuán)隊(duì)最急需“用戶日活”和“商品日銷量”那就先建dws_user_daily_active_d和dws_item_daily_sales_d兩張表字段控制在10個(gè)以內(nèi)。等這兩張表穩(wěn)定運(yùn)行一個(gè)月再根據(jù)實(shí)際查詢?nèi)罩救鏢park History Server的SQL審計(jì)發(fā)現(xiàn)80%查詢都帶WHERE region IN (East,South)這時(shí)再擴(kuò)展region字段而不是一開(kāi)始就猜。這種漸進(jìn)式契約比任何藍(lán)圖都可靠。從那以后我每次設(shè)計(jì)DWS表都強(qiáng)制走一遍“三問(wèn)流程”問(wèn)業(yè)務(wù)這張表上線后第一個(gè)月會(huì)有幾個(gè)業(yè)務(wù)方用他們最常查的3個(gè)字段是什么問(wèn)數(shù)據(jù)這些字段的計(jì)算邏輯能否在DWD層找到100%對(duì)應(yīng)的原子事件如果不能說(shuō)明DWD層缺失契約必須先補(bǔ)DWD問(wèn)運(yùn)維這張表的ETL任務(wù)如果明天失敗會(huì)影響多少下游任務(wù)如果超過(guò)3個(gè)說(shuō)明耦合度過(guò)高必須拆分。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取