前言
在數據倉庫開發的過程中,常常會遇到很多值得思考的問題,它們不僅關乎技術的深度,也涉及業務理解、個人的成長,甚至是數據行業未來的價值。回顧過去的經歷,有很多問題反復出現,甚至成為繞不開的課題,我自己挑選了9個問題,將其分成了四類,重新進行回答。
關于數據建模的終極追問 ?
為什么建模?必須建模嗎?
提起建模,大家都會說是為了規范數據存儲,提升查詢效率,支撐業務分析。但有時也會思考:如果業務需求足夠簡單,是否真的需要構建復雜的模型?
我的當前答案則是:數倉開發不一定必須建模,但大多數情況下,建模能夠提升數據的可維護性、復用性和查詢性能。是否需要建模,取決于業務需求、數據復雜度以及數據消費方式。大體的判斷分類可以分為:
結論:建模不是目的,而是手段
如果數據需要標準化、優化查詢、跨系統整合,那么建模是必要的。
如果數據規模小、變化快、或者是探索性分析,直接查詢可能更適合。
怎么證明你建的模型就比別人的好?
既然要比較,必然先有評價標準的。
首先,一個“好”的模型應該具備 高質量(數據可用性)、高性能(查詢優化)、高擴展性(支持未來需求)、高復用性(減少重復開發),但如何量化這些指標?是數據查詢的速度?業務團隊的滿意度?還是系統的穩定性?
我自己想到可以從以下幾個方面來看:
只有用數據說話,才能真正證明你的數據模型比其他團隊的好。
當然,公司也有內部數倉建模規范2.0/3.0,對于建模選擇都有明確的說明,可便于大家參考。
必須由數倉來做嗎?業務系統不能做嗎?
這個問題的本質是:數據處理的邊界在哪里?業務系統和數據倉庫如何分工?
我分3大點來嘗試回答。
1、數據倉庫的本質和核心價值
首先,先復習一下關于數據倉庫的定義:
數據倉庫之父比爾·恩門(Bill Inmon)在1991年出版的“Building the Data Warehouse”(《建立數據倉庫》)一書中所提出的定義被廣泛接受——數據倉庫(Data Warehouse)是一個面向主題的(Subject Oriented)、集成的(Integrated)、相對穩定的(Non-Volatile)、反映歷史變化(Time Variant)的數據集合,用于支持管理決策(Decision Making Support)。
所以,數據倉庫的核心并非僅僅是存儲或OLAP能力,而在于:
數據整合:跨業務系統的數據清洗、標準化、統一建模(如星型/雪花模型)
歷史數據存儲:長期存儲業務系統通常不保留的歷史數據(如10年交易記錄)
復雜分析支持:優化查詢性能應對大規模關聯分析、時間序列分析
數據治理:元數據管理、數據血緣、權限控制體系
2、業務系統能否替代數倉
部分場景可以,但存在明顯邊界:
可行場景:單業務系統的簡單報表、實時性要求高的OLAP查詢(如PolarDB HTAP能力)
不可替代場景:對于跨多個業務系統、跨時間周期長、大規模的數據查詢分析
3、傳統數倉 VS 現代數倉的演變
隨著存儲和計算等新技術的發展,對于原本的數倉開發也帶來了一定的改變,具體的比較見下,雖然在某種程度上,雙邊的界限會存在一定的模糊,但是 兩者還是有所不同。
技術演進的影響:
PolarDB等HTAP數據庫確實模糊了OLTP/OLAP的硬件層邊界
但數倉的核心邏輯(數據整合、建模、治理)仍需通過架構設計實現
未來可能形成“業務系統負責實時分析,數倉負責跨系統深度分析”的互補架構
結論:由上面的3點,數倉 ≠ 業務數據庫,只是數據倉庫的適用場景不同。對于面向復雜分析的很多數據不應該放在業務數據庫里,而應該交給數倉做統一管理、優化查詢、支撐決策分析。
數據研發的價值證明體系
需求已經寫得那么明確了,你的建模體現在哪里?
在真實的開發場景中,有些時候數據bp比研發人員還要更加的了解數據的全流程以及具體的使用,這種場景下,還有所謂的建模嗎?
這個問題的本質是:數據建模的價值在哪里?是否只是簡單地“翻譯”需求?
如果數據開發只是“翻譯”需求,那和直接寫 SQL 計算數據沒區別。AI不就可以干了么。但真正的建模價值體現在:
(1) 數據整合
? 通過數倉分層(ODS → DWD → DWM → APP),把零散的業務數據整合為統一數據資產。
? 例如:“用戶登錄、支付、訂單”分散在不同系統,數倉建模后可快速計算用戶生命周期指標。
(2) 數據標準化
? 例如:在“GMV 計算”中,不同業務線的“GMV”定義可能不同(是否包含退款、稅費等)。
? 通過數倉建模,制定統一的GMV口徑,所有報表和數據產品使用相同的計算方式。
(3) 提高查詢性能
? 例如:一個業務查詢需要跨 5 張表進行 Join,查詢時間很長。
? 通過建模,將計算結果提前寫入寬表(DWM層),查詢時只需直接查詢寬表,大幅提升性能。
(4) 數據復用
? 例如:多個團隊都需要“日活用戶數 (DAU)”,如果不建模,每個團隊都要重復計算。
? 建模后,所有人都可以直接使用,避免重復開發。
但是,在實際情況中,比如,在之前開發中對于財務數據這種專業性較強的建設,可能會感覺建模的效果沒有體現出來。說明可能以下幾點沒有做好:
只是簡單寫 SQL,沒有建立數據資產。
沒有考慮數據復用,導致相同數據多次計算。
沒有優化數據結構,查詢性能低下。
缺乏業務理解。
所以,即使需求已經很明確,建模仍然是數據開發的核心價值。
它決定了數據的組織方式、計算性能、可復用性,影響整個數據架構的可持續發展。
你的建模是業界通用的嗎?
還是你自己制定的?如果是業界通用的,那么你的特色體現在哪里?
這個問題翻譯過來是:什么時候用通用模型?什么時候需要自定義模型,以及兩者之間如何比較,有可量化的指標嗎?
業界的通用建模方法大家都知道,有 Kimball、Inmon、Data Vault 等,那么在實際的開發過程中,如何選擇更適合的模型呢?
個人認為是需要根據業務場景、技術棧特性和數據規模進行深度適配,形成通用底座+業務增強的特色模式。
常規上來說,一般的比對指標有以下幾種:
但是呢,看起來依舊有點主觀,所以,我在想,有沒有一種什么方式可以將其量化,抽象為一個計算公式?
查了查,發現想法類似于字節的三維模型,因此,個人認為也可以抽象為「場景復雜度-技術約束-ROI」三維評估模型。(僅為初步想法,并未真實驗證)
1、量化評估公式
模型適配度評分 =(業務契合度 × W1) + (技術適配度 × W2) + (經濟性指數 × W3);其中:
權重系數(W1+W2+W3=1)可以分階段進行動態調整,比如:
業務導向型:W1=0.6, W2=0.2, W3=0.2
技術驅動型:W1=0.3, W2=0.5, W3=0.2
成本敏感型:W1=0.4, W2=0.3, W3=0.3
2、參數定義與計算方法
業務契合度 (0-10分)
業務契合度 = (場景覆蓋度 + 查詢效率增益)/2 + 敏捷性修正值 ?
場景覆蓋度?= (當前業務需求匹配數 / 模型支持最大場景數) × 10
例:某模型支持5種促銷分析模式,當前需覆蓋3種 → 得分6分??
查詢效率增益?= (基準模型延遲 - 候選模型延遲) / 基準模型延遲 × 10
例:從星型模型(8s)切換到寬表(1.2s) → 得分(8-1.2)/8×10=8.5分
敏捷性修正值:?
需求變更頻率 ≤1次/月: +0 ?
1次/周: -1 ?
每日變更: -3 ?
技術適配度 (0-10分) ?
技術適配度 = (工具鏈匹配度 + 團隊能力指數)/2 *可維護性系數 ?
工具鏈匹配度?= (支持該模型的工具數 / 企業現有工具數) × 5 + (專用優化功能存在性 × 5)?
團隊能力指數?= (團隊成員平均建模經驗年限 × 2) ,最高5分 ?
可維護性系數?= 1 - (模型復雜度指數 × 0.1) ?
復雜度指數 = 表數量 × 0.3 + 關聯層級 × 0.7
經濟性指數 (0-10分)
經濟性指數 = 可接受成本/(開發成本 + 三年運維成本) ?
可接受成本?= 項目預算
開發成本?= 人力成本(人天×單價) + 資源消耗?
運維成本?= (日常維護工時 × 單價) + 存儲費用 + 計算費用 ?
3、決策規則
分別計算出模型A和模型B的分數,如果差別不大,可以使用偏向通用模型。如果差異過大,可以使用自定義模型。
怎么證明數據的價值?
輔助決策,有具體的例子嗎?
回顧ERP的項目,更多都是財務方向的建設,我們一直在說數據的建設是輔助管理層決策,但是,有沒有辦法直觀的感受到或者量化這個決策的影響度。這個我也沒有找到更好的量化方式,也期望得到大佬們的解答。
職業發展的本質思考
?除了技術本身,做數據倉庫的這幾年,也讓我不斷思考職業發展的問題。
對于職業發展的焦慮?
當一個行業或崗位無法提供新的挑戰和成長空間時,很多人會選擇尋找新的機會。對于我個人而言,最核心的問題是:對于職業發展的焦慮。
我所在乎的一般有3點
技術成長曲線(新技能突破)
業務貢獻度(受認可,工作內容可以影響核心指標)
所在環境提供必要挑戰(如團隊不斷有新的業務)
當感受不到技能成長的時候,會問自己,我的技能還能走多遠?新的技術的出現,是不是會導致自己很快被淘汰?當衡量不出來價值的時候,會質疑自己存在的必要性,嚴重會上升到對于數倉開發的懷疑。
如果讓你再做一次,你會怎么做?
如果重來一次,則要關注數據資產化治理,與業務方加強溝通,多多理解業務知識。讓數據不僅是業務的支撐,而是成為業務的資產。同時,我會更注重數據治理,保證數據一致性、可復用性、可追溯性,而不是只關注“報表跑得快不快”。
面向未來的生存法則
技術環境變化太快了,按照自己現在的規劃路線,還能走多遠呢?
AI 時代,數據研發還值錢嗎?
這是我最近思考最多的問題之一。AI 的發展讓數據的價值進一步凸顯,但同時也對數據研發提出了更高的要求。未來的數據工程師,不僅僅是建模、ETL,還需要具備數據治理、數據質量管理、流計算、AI 結合數據分析等能力。
AI 可以加速數據處理,但不能完全取代數據治理和數據決策。數據研發仍然重要,但角色正在進化,未來的數倉開發可能不只是建模,而是構建“智能數據平臺”,讓數據更好地服務于 AI 和業務。
總結
過去 4 年讓我從一個數據開發者成長為一個更懂業務、懂建模、也懂數據價值的人。讓我對數據的本質有了更深刻的理解,也讓我意識到:數據的核心價值不在于使用了多么高大上的技術,而在于它如何影響決策,為業務帶來價值。
歡迎大家對上述問題,展開探討,留下你的想法,將抽取5位同學,送上“滴滴技術雙肩電腦包”!