數(shù)倉避坑-整明白懂粒度

6 評論 6377 瀏覽 13 收藏 10 分鐘

編輯導(dǎo)語:在數(shù)倉中,你理解什么是粒度嗎?這是一個很抽象的名詞,但同時它又是數(shù)倉中重要的一個概念。作者通過五個方面總結(jié)如何把粒度整明白的方法,我們一起來看下吧。

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

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

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

一、先說說粒度的概念

選定了分析的過程,緊接著就要聲明粒度。看到書里這么說,我當(dāng)時的反應(yīng)是:為什么?粒度是什么?普通場景里,粒度可以理解為一個東西的大小。

比如,鉆石要區(qū)分顆粒度,大小不同的鉆石,價格不一。而在數(shù)據(jù)分析的語境里,粒度則意味著分析的范圍,分析的細(xì)致程度。舉兩個例子。

系統(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 條記錄。

二、通過實戰(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)度啦。

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

構(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è)計階段,問題就會慢慢浮出水面了?;谑聦嵄砟P停覀兒苋菀自O(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)無法生成如下匯總表:

需求只能搞定一般,這可怎么交差?

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

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

讓我們回歸到真實場景里:登錄成功,這個事件發(fā)生在一瞬間。常見的時間計量單位有年、月、天、小時、分鐘、秒、毫秒、微秒等等。而系統(tǒng)記錄某個操作,常見的記錄粒度是秒。

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

業(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)的角度來看,如果查詢的粒度,是一個變量,而不是一個固定值,沒法提前計算,只能臨時用明細(xì)表算,這就叫做即系查詢。

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

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

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

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

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

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

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

 

作者:lee;公眾號:樂說樂言

本文由 @lee 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自?Unsplash,基于 CC0 協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 沒太理解這個需求的難度在哪里,sql改改,或者復(fù)雜點直接用spark,都很容易啊

    回復(fù)
    1. 手寫SQL自然是可以隨便改呀,我想強調(diào)的是,粒度不同,SQL也不同,那基于指標(biāo)口徑就沒辦法生成了。
      某個方法給了一個方的模具,用這個方法,搞出來的肉丸子肯定是方的,但需求方希望肉丸子是圓的。我重點想說的是,用這個方模具搞不來圓的。然后您說,用手捏可以捏出來圓的。大概如此吧。

      回復(fù)
  2. 顆粒度還有一個重要的概念,就是大的顆粒并不是小顆粒的累加。就像2兩一個的螃蟹賣10元一只,4兩一個的螃蟹并不賣20元一只,有可能是40元。

    來自江西 回復(fù)
    1. 數(shù)據(jù)分析的場景里面,粒度問題多數(shù)都是去重引起的。
      不過您這個生活化的例子挺好,感謝補充~

      來自廣東 回復(fù)
    2. 2兩的螃蟹和4兩的螃蟹,你這不是顆粒度了,是維度了。

      來自四川 回復(fù)
    3. 2個2兩一個的原價必然賣20。

      來自北京 回復(fù)