引言

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

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

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

01 先說說粒度的概念

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

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

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

舉兩個例子。

系統的注冊總人數，可以按照國家、省份來統計，這是地域層面上的不同統計粒度。

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

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

按國家統計用戶數，中國只會有一條記錄，按省統計，中國則會有34條記錄。

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

02 通過實戰理解粒度

好，看書搞懂了概念，實戰就來了。

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

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

通過例子理解：某個活動發布后，要查看不同時間區間內的累積活躍用戶數，比如1-2號，3-5號，以便及時調整促活的策略。

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

首先，選定業務過程。

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

其次，聲明粒度。

這里用戶方希望按照不同的日期統計累積人數，那粒度是天。

然后，是確定維度。

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

最后，設計事實表。

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

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

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

構建模型，最終都是為了查出對應的指標和結果，所以維度模型通常都會跟標準的指標系統配套來使用。

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

當我們按照標準套路，進入指標設計階段，問題就會慢慢浮出水面了。

基于事實表模型，我們很容易設計原子指標【登錄人數】，其計算邏輯為

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 后的結果，是按照每天進行去重的。最終的結果，只能是統計每天范圍內的累積登錄人數。

用戶的期望是，統計某個時間區間內的累積登錄人數，這個需求維度模型產生的指標沒法滿足。

如果事實表的真實數據如下：

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

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

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

04 粒度是搞清問題的關鍵

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

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

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

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

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

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

那問題又是啥呢？

再看看實際需求時，統計的時間區間是不固定的。即，業務方可能今天想統計 1 號到 2 號的登錄人數，明天想統計 3 號到 5 號的登錄人數。

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

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

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

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

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

最后，說點學習經驗

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

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。