引言

上篇文章
數(shù)倉避坑指南-搞懂維度模型介紹了維度建模經(jīng)典的四部曲：選定業(yè)務(wù)過程、聲明粒度、確定維度、確定事實。

第二步中，粒度的概念著實有點抽象，很難理解。但是，如果粒度整不明白，近乎等于數(shù)倉沒入門，你將會面臨一系列問題。

今天就給大家分享一下，我踩坑粒度的過程。

01 先說說粒度的概念

選定了分析的過程，緊接著就要聲明粒度。看到書里這么說，我當(dāng)時的反應(yīng)是：為什么？粒度是什么？

普通場景里，粒度可以理解為一個東西的大小。比如，鉆石要區(qū)分顆粒度，大小不同的鉆石，價格不一。

而在數(shù)據(jù)分析的語境里，粒度則意味著分析的范圍，分析的細致程度。

舉兩個例子。

系統(tǒng)的注冊總?cè)藬?shù)，可以按照國家、省份來統(tǒng)計，這是地域?qū)用嫔系牟煌y(tǒng)計粒度。

系統(tǒng)的活躍用戶數(shù)，可以按天、按周統(tǒng)計登錄人數(shù)，這是時間層面上不同的統(tǒng)計粒度。

從數(shù)據(jù)表的角度來看，粒度則解釋著什么情況下增加一條記錄。

按國家統(tǒng)計用戶數(shù)，中國只會有一條記錄，按省統(tǒng)計，中國則會有34條記錄。

按周統(tǒng)計活躍用戶，一年只會有 52 行記錄，按天統(tǒng)計，一年則有 365 或 366 條記錄。

02 通過實戰(zhàn)理解粒度

好，看書搞懂了概念，實戰(zhàn)就來了。

公司出了新 APP，老板很關(guān)心新 APP 的用戶活躍程度，于是，用戶端產(chǎn)品經(jīng)理希望做個面板，看每天有多少人登錄。

同時，他提了另一個需求，他希望能支持統(tǒng)計兩個日期區(qū)間內(nèi)的登錄人數(shù)（兩個日期是變化的）。

通過例子理解：某個活動發(fā)布后，要查看不同時間區(qū)間內(nèi)的累積活躍用戶數(shù)，比如1-2號，3-5號，以便及時調(diào)整促活的策略。

初生牛犢不怕虎，說搞咱就搞，就按照維度建模經(jīng)典套路搞。

首先，選定業(yè)務(wù)過程。

這個一目了然，自然就是用戶登錄過程。

其次，聲明粒度。

這里用戶方希望按照不同的日期統(tǒng)計累積人數(shù)，那粒度是天。

然后，是確定維度。

這個例子里，因為要按照日期分析，最主要的維度是日期（為了簡單，例子里就就先不考慮其他維度了），日期維度表設(shè)計如下：

最后，設(shè)計事實表。

這個也不難，用戶登錄事實表(fact_loign）設(shè)計如下：

三下五除二，維度模型搞定！就等寫好 ETL 腳本，按周期調(diào)度啦。

03 維度模型搞不定，是粒度理解不到位

構(gòu)建模型，最終都是為了查出對應(yīng)的指標(biāo)和結(jié)果，所以維度模型通常都會跟標(biāo)準(zhǔn)的指標(biāo)系統(tǒng)配套來使用。

對指標(biāo)體系不太了解的朋友可以看這篇：一文幫你更好地理解指標(biāo)，或者看華為阿里的產(chǎn)品。

當(dāng)我們按照標(biāo)準(zhǔn)套路，進入指標(biāo)設(shè)計階段，問題就會慢慢浮出水面了。

基于事實表模型，我們很容易設(shè)計原子指標(biāo)【登錄人數(shù)】，其計算邏輯為

count(fact_login.user_id)

進而，我們也能設(shè)計出衍生指標(biāo)【日期_登錄人數(shù)】，其口徑為：

select distinct count(fact_login.user_id) from fact_login left join dim_date on date.date_key = fact_login.login_date group by dim_date.date_key

從衍生指標(biāo)這里，就能發(fā)現(xiàn)問題了。

你會發(fā)現(xiàn)，group by 后的結(jié)果，是按照每天進行去重的。最終的結(jié)果，只能是統(tǒng)計每天范圍內(nèi)的累積登錄人數(shù)。

用戶的期望是，統(tǒng)計某個時間區(qū)間內(nèi)的累積登錄人數(shù)，這個需求維度模型產(chǎn)生的指標(biāo)沒法滿足。

如果事實表的真實數(shù)據(jù)如下：

基于維度模型，系統(tǒng)可以生成這樣的匯總表：

但系統(tǒng)無法生成如下匯總表：

需求只能搞定一半，這可怎么交差？

04 粒度是搞清問題的關(guān)鍵

剛開始，我很疑惑，想了各種辦法也沒辦法解決。后來才意識到，問題根源其實是粒度。

讓我們回歸到真實場景里：登錄成功，這個事件發(fā)生在一瞬間。

常見的時間計量單位有年、月、天、小時、分鐘、秒、毫秒、微秒等等。而系統(tǒng)記錄某個操作，常見的記錄粒度是秒。

比如， 2021 年 6 月 27 號 14 : 00 : 00，小明登錄了系統(tǒng)。如果按照秒去統(tǒng)計登錄人數(shù)，則完全不用考慮去重，因為小明在這個粒度的計量單位里，只能登錄一次。

但秒級別的統(tǒng)計粒度，太細了。業(yè)務(wù)方希望從更加宏觀的角度去統(tǒng)計和分析，例子里面，是以天為單位去統(tǒng)計。

那這個時候，統(tǒng)計就要升粒度了，并且，要去重。此時，系統(tǒng)也是可以按照天的粒度進行去重統(tǒng)計的。

那問題又是啥呢？

再看看實際需求時，統(tǒng)計的時間區(qū)間是不固定的。即，業(yè)務(wù)方可能今天想統(tǒng)計 1 號到 2 號的登錄人數(shù)，明天想統(tǒng)計 3 號到 5 號的登錄人數(shù)。

這個時候，就沒法玩了，為什么呢？

粒度不固定：1-2號，間隔時間是1天，3-5號，間隔時間則是2天。

維度建模中，聲明粒度就是要把粒度的大小定下來。不管是什么維度，都要提前把粒度定下來，這樣才能實現(xiàn)累計去重。

從技術(shù)實現(xiàn)的角度來看，如果查詢的粒度，是一個變量，而不是一個固定值，沒法提前計算，只能臨時用明細表算，這就叫做即系查詢。

所以，這個需求中，維度建模只能解決前面部分的需求：按照天去重統(tǒng)計每天登錄人數(shù)。而變化區(qū)間的去重統(tǒng)計，只能即席查詢了。

最后，說點學(xué)習(xí)經(jīng)驗

維度建模工具箱這本書，一再強調(diào)粒度的重要性，大概率就是因為粒度這玩意，太抽象，不好理解。

當(dāng)初，我就在這上面理解出了差錯，陷在維度建模的漩渦里。

本人愚笨，看書好久，都沒明白粒度的真正含義，被真實業(yè)務(wù)需求痛扁一頓后，我才體會到粒度的真正含義。

作為一個新人，接觸到新的方法或者工具，我們是興奮的。

與此同時，我們也要謹防 “撿到錘子，看什么都像釘子”，沒有能解決所有問題的方法和工具，特定場景，選用特定的工具。

死磕核心概念，結(jié)合實際場景去理解，搞懂了，很多問題就通了~

有什么問題，歡迎評論交流。

總結(jié)

以上是生活随笔為你收集整理的数据仓库基础3-整明白粒度的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。