"老張，我們的用戶畫像模型又崩了，業(yè)務(wù)方明天要數(shù)據(jù)，怎么辦？" 

這已經(jīng)是這個(gè)月第三次了。發(fā)消息的小李是某互聯(lián)網(wǎng)公司的數(shù)據(jù)工程師，入行兩年，技術(shù)不錯(cuò)，但總是被數(shù)據(jù)建模這件事搞得焦頭爛額。 

其實(shí)小李的遭遇并不是個(gè)例。 我在數(shù)據(jù)圈混了十多年，見過太多這樣的場景：團(tuán)隊(duì)花了幾個(gè)月時(shí)間精心設(shè)計(jì)的數(shù)據(jù)模型，上線沒多久就被業(yè)務(wù)方嫌棄太復(fù)雜"不好用"；技術(shù)團(tuán)隊(duì)加班加點(diǎn)優(yōu)化模型性能，結(jié)果業(yè)務(wù)需求一變，前面的工作全白費(fèi)。 

問題到底出在哪里？為什么大部分團(tuán)隊(duì)在數(shù)據(jù)建模上都在做無用功？

第一個(gè)真相：你以為的需求分析，其實(shí)是在自欺欺人

大部分?jǐn)?shù)據(jù)團(tuán)隊(duì)接需求的方式都有問題。

有這么一個(gè)典型的場景：業(yè)務(wù)方找到數(shù)據(jù)團(tuán)隊(duì)說，"我們需要一個(gè)用戶行為分析的數(shù)據(jù)模型，要能看到用戶的點(diǎn)擊、瀏覽、購買行為。"

數(shù)據(jù)團(tuán)隊(duì)聽了，覺得很清楚啊，于是開始設(shè)計(jì)用戶行為事實(shí)表，把點(diǎn)擊、瀏覽、購買這些事件都記錄下來，還貼心地加了時(shí)間戳、設(shè)備信息、地理位置等維度。

結(jié)果模型上線后，業(yè)務(wù)方一臉懵逼："這個(gè)轉(zhuǎn)化率怎么算的？為什么我看到的數(shù)據(jù)和運(yùn)營后臺不一樣？"

問題就出在這里——你以為你理解了需求，其實(shí)你只是聽到了表面的描述。

真正的需求分析不是記錄業(yè)務(wù)方說了什么，而是要挖掘他們?yōu)槭裁匆@個(gè)數(shù)據(jù)。

同樣是"用戶行為分析"，如果是為了優(yōu)化產(chǎn)品功能，那重點(diǎn)應(yīng)該是用戶的操作路徑和停留時(shí)長；如果是為了精準(zhǔn)營銷，那重點(diǎn)應(yīng)該是用戶的興趣標(biāo)簽和消費(fèi)偏好。

我有個(gè)朋友在某電商公司做數(shù)據(jù)架構(gòu)師，他們團(tuán)隊(duì)有個(gè)不成文的規(guī)定：接到任何需求，都要先問三個(gè)問題：

"這個(gè)數(shù)據(jù)最終是給誰看的？"

"他們拿到數(shù)據(jù)后要做什么決策？"

"如果沒有這個(gè)數(shù)據(jù)，他們現(xiàn)在是怎么做決策的？"

這三個(gè)問題看起來簡單，但能幫你快速定位真正的業(yè)務(wù)痛點(diǎn)。很多時(shí)候，業(yè)務(wù)方自己都不清楚要什么，他們只是覺得"應(yīng)該有個(gè)數(shù)據(jù)看看"。

更要命的是，很多數(shù)據(jù)團(tuán)隊(duì)為了顯示專業(yè)性，喜歡把簡單的需求復(fù)雜化。業(yè)務(wù)方要個(gè)"日活用戶數(shù)"，你給他設(shè)計(jì)了一套包含十幾個(gè)維度的用戶活躍度分析模型。

業(yè)務(wù)方看著密密麻麻的表結(jié)構(gòu)，心里只有一個(gè)想法："我就想知道今天有多少人用了我們的產(chǎn)品，為什么這么復(fù)雜？"

第二個(gè)真相：技術(shù)驅(qū)動(dòng)的建模思路，注定要踩坑

很多技術(shù)團(tuán)隊(duì)在做數(shù)據(jù)建模的時(shí)候，習(xí)慣性地從技術(shù)角度出發(fā)。

"我們用星型模型，性能好。"

"雪花模型更規(guī)范，符合第三范式。"

"這個(gè)字段可能以后會用到，先加上。"

聽起來很專業(yè)，但實(shí)際上是在為技術(shù)而技術(shù)。

我見過一個(gè)團(tuán)隊(duì)，為了追求"完美的數(shù)據(jù)模型"，設(shè)計(jì)了一套極其復(fù)雜的雪花模型。用戶維度表拆分成了基礎(chǔ)信息表、行為偏好表、消費(fèi)能力表等七八張表。技術(shù)上確實(shí)很優(yōu)雅，符合所有的建模規(guī)范。

但業(yè)務(wù)方要查個(gè)簡單的"用戶購買轉(zhuǎn)化率"，需要關(guān)聯(lián)五張表，SQL寫了三十多行。每次查詢都要等好幾分鐘，業(yè)務(wù)方直接放棄了，回去繼續(xù)用Excel手工統(tǒng)計(jì)。

這就是典型的"為了建模而建模"。

真正有效的數(shù)據(jù)建模，應(yīng)該是業(yè)務(wù)驅(qū)動(dòng)的。先搞清楚業(yè)務(wù)方最常用的查詢場景，然后針對這些場景來優(yōu)化模型結(jié)構(gòu)。

比如說，如果業(yè)務(wù)方80%的查詢都是按時(shí)間和渠道來分析用戶行為，那就應(yīng)該把時(shí)間和渠道作為主要的分區(qū)字段，即使這樣做會導(dǎo)致一些數(shù)據(jù)冗余。

性能和規(guī)范性之間，永遠(yuǎn)要優(yōu)先考慮性能。業(yè)務(wù)方不會因?yàn)槟愕哪Ｐ头系谌妒蕉o你加薪，但他們會因?yàn)椴樵兯俣嚷对V你。

還有一個(gè)容易被忽視的問題：很多團(tuán)隊(duì)在設(shè)計(jì)模型的時(shí)候，只考慮了當(dāng)前的業(yè)務(wù)需求，沒有考慮業(yè)務(wù)的發(fā)展變化。

之前見過一個(gè)案例，某公司的數(shù)據(jù)團(tuán)隊(duì)為電商業(yè)務(wù)設(shè)計(jì)了一套完美的訂單分析模型。但半年后，公司開始做直播帶貨，原來的模型完全不適用，因?yàn)橹辈ビ唵蔚臉I(yè)務(wù)邏輯和傳統(tǒng)電商完全不同。

結(jié)果就是推倒重來，前面幾個(gè)月的工作全部白費(fèi)。

第三個(gè)真相：落地實(shí)施才是真正的考驗(yàn)

模型設(shè)計(jì)得再好，落地不了也是白搭。

很多團(tuán)隊(duì)在設(shè)計(jì)階段考慮得很周全，但到了實(shí)施階段就開始各種妥協(xié)。

數(shù)據(jù)質(zhì)量不行，就先湊合著用；ETL任務(wù)經(jīng)常失敗，就手工補(bǔ)數(shù)據(jù)；查詢性能不好，就讓業(yè)務(wù)方"耐心等待"。

這種做法的后果就是，模型雖然上線了，但沒人愿意用。

我有個(gè)前同事，現(xiàn)在在某金融公司做數(shù)據(jù)總監(jiān)。他跟我分享過一個(gè)經(jīng)驗(yàn)："數(shù)據(jù)模型的成功與否，不是看設(shè)計(jì)得多完美，而是看有多少人在用。"

他們公司有個(gè)規(guī)定，任何數(shù)據(jù)模型上線后的第一個(gè)月，都要統(tǒng)計(jì)使用情況。如果日均查詢次數(shù)少于10次，就要分析原因，要么優(yōu)化模型，要么直接下線。

這個(gè)做法看起來有點(diǎn)殘酷，但確實(shí)有效。它逼著數(shù)據(jù)團(tuán)隊(duì)從用戶體驗(yàn)的角度來思考問題，而不是沉浸在技術(shù)的完美主義中。

另外，很多團(tuán)隊(duì)在實(shí)施階段還有個(gè)通?。合矚g一次性把所有功能都做完。

業(yè)務(wù)方要個(gè)用戶畫像，你就把用戶的所有屬性都建模進(jìn)去，從基礎(chǔ)信息到行為偏好，從消費(fèi)能力到社交關(guān)系，恨不得把用戶的祖宗十八代都分析一遍。

結(jié)果就是開發(fā)周期拖得很長，等模型上線的時(shí)候，業(yè)務(wù)需求可能已經(jīng)變了。

更好的做法是MVP（最小可行產(chǎn)品）思路：先做一個(gè)最簡單的版本，滿足核心需求，快速上線，然后根據(jù)使用反饋逐步迭代。

比如用戶畫像，第一版可能只包含基礎(chǔ)信息和最近30天的行為數(shù)據(jù)，但能保證查詢速度快，數(shù)據(jù)準(zhǔn)確。等業(yè)務(wù)方用起來了，有了更多需求，再逐步增加維度和功能。

這樣做的好處是，你能快速驗(yàn)證模型的有效性，避免在錯(cuò)誤的方向上浪費(fèi)太多時(shí)間。

結(jié)語

數(shù)據(jù)建模這件事，說到底還是要回歸本質(zhì)：為業(yè)務(wù)創(chuàng)造價(jià)值。

技術(shù)很重要，但技術(shù)只是手段，不是目的。一個(gè)能讓業(yè)務(wù)方快速獲得洞察、做出決策的簡單模型，遠(yuǎn)比一個(gè)技術(shù)上完美但沒人使用的復(fù)雜模型更有價(jià)值。

見過太多技術(shù)團(tuán)隊(duì)，花了大量時(shí)間精力去追求所謂的"最佳實(shí)踐"，結(jié)果做出來的東西業(yè)務(wù)方根本用不上。也見過一些看起來"不夠優(yōu)雅"的模型，但因?yàn)榻鉀Q了實(shí)際問題，成為了公司的核心數(shù)據(jù)資產(chǎn)。

數(shù)據(jù)建模沒有標(biāo)準(zhǔn)答案，只有適合不適合。與其追求完美，不如追求有用。先讓模型跑起來，解決實(shí)際問題，然后在使用中不斷優(yōu)化，這才是數(shù)據(jù)建模的正確姿勢。

記住一句話：好的數(shù)據(jù)模型不是設(shè)計(jì)出來的，是用出來的。