編輯導語：在數倉中，你理解什麼是粒度嗎？這是一個很抽象的名詞，但同時它又是數倉中重要的一個概念。作者透過五個方面總結如何把粒度整明白的方法，我們一起來看下吧。

上篇文章數倉避坑-搞懂維度模型介紹了維度建模經典的四部曲：選定業務過程、宣告粒度、確定維度、確定事實。

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

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

一、先說說粒度的概念

選定了分析的過程，緊接著就要宣告粒度。看到書裡這麼說，我當時的反應是：為什麼？粒度是什麼？普通場景裡，粒度可以理解為一個東西的大小。

比如，鑽石要區分顆粒度，大小不同的鑽石，價格不一。而在資料分析的語境裡，粒度則意味著分析的範圍，分析的細緻程度。舉兩個例子。

系統的註冊總人數，可以按照國家、省份來統計，這是地域層面上的不同統計粒度。系統的活躍使用者數，可以按天、按周統計登入人數，這是時間層面上不同的統計粒度。

從資料表的角度來看，粒度則解釋著什麼情況下增加一條記錄。按國家統計使用者數，中國只會有一條記錄，按省統計，中國則會有34條記錄。

按周統計活躍使用者，一年只會有 52 行記錄，按天統計，一年則有 365 或 366 條記錄。

二、透過實戰理解粒度

好，看書搞懂了概念，實戰就來了。公司出了新 APP，老闆很關心新 APP 的使用者活躍程度，於是，使用者端產品經理希望做個面板，看每天有多少人登入。

同時，他提了另一個需求，他希望能支援統計兩個日期區間內的登入人數（兩個日期是變化的）。

透過例子理解：某個活動釋出後，要檢視不同時間區間內的累積活躍使用者數，比如1-2號，3-5號，以便及時調整促活的策略。

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

首先，選定業務過程。這個一目瞭然，自然就是使用者登入過程。

其次，宣告粒度。這裡使用者方希望按照不同的日期統計累積人數，那粒度是天。

然後，是確定維度。這個例子裡，因為要按照日期分析，最主要的維度是日期（為了簡單，例子裡就就先不考慮其他維度了），日期維度表設計如下：

最後，設計事實表。這個也不難，使用者登入事實表（fact_loign）設計如下：

三下五除二，維度模型搞定！就等寫好 ETL 指令碼，按週期排程啦。

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

構建模型，最終都是為了查出對應的指標和結果，所以維度模型通常都會跟標準的指標系統配套來使用。對指標體系不太瞭解的朋友可以看這篇：

一文幫你更好地理解指標，或者看華為阿里的產品。當我們按照標準套路，進入指標設計階段，問題就會慢慢浮出水面了。基於事實表模型，我們很容易設計原子指標【登入人數】，其計算邏輯為

count（fact_login。user_id）

進而，我們也能設計出衍生指標【日期_登入人數】，其口徑為：

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

從衍生指標這裡，就能發現問題了。你會發現，group by 後的結果，是按照每天進行去重的。

最終的結果，只能是統計每天範圍內的累積登入人數。使用者的期望是，統計某個時間區間內的累積登入人數，這個需求維度模型產生的指標沒法滿足。如果事實表的真實資料如下：

基於維度模型，系統可以生成這樣的彙總表：

但系統無法生成如下彙總表：

需求只能搞定一般，這可怎麼交差？

四、粒度是搞清問題的關鍵

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

讓我們迴歸到真實場景裡：登入成功，這個事件發生在一瞬間。常見的時間計量單位有年、月、天、小時、分鐘、秒、毫秒、微秒等等。而系統記錄某個操作，常見的記錄粒度是秒。

比如， 2021 年 6 月 27 號 14 ： 00 ： 00，小明登入了系統。如果按照秒去統計登入人數，則完全不用考慮去重，因為小明在這個粒度的計量單位裡，只能登入一次。但秒級別的統計粒度，太細了。

業務方希望從更加宏觀的角度去統計和分析，例子裡面，是以天為單位去統計。

那這個時候，統計就要升粒度了，並且，要去重。此時，系統也是可以按照天的粒度進行去重統計的。那問題又是啥呢？再看看實際需求時，統計的時間區間是不固定的。

即，業務方可能今天想統計 1 號到 2 號的登入人數，明天想統計 3 號到 5 號的登入人數。這個時候，就沒法玩了，為什麼呢？

粒度不固定：1-2號，間隔時間是1天，3-5號，間隔時間則是2天。維度建模中，宣告粒度就是要把粒度的大小定下來。

不管是什麼維度，都要提前把粒度定下來，這樣才能實現累計去重。

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

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

五、最後，說點學習經驗

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

當初，我就在這上面理解出了差錯，陷在維度建模的漩渦裡。

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

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

與此同時，我們也要謹防 “撿到錘子，看什麼都像釘子”，沒有能解決所有問題的方法和工具，特定場景，選用特定的工具。死磕核心概念，結合實際場景去理解，搞懂了，很多問題就通了~

作者：lee；公眾號：樂說樂言

本文由 @lee 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議