兩個案例搞定數據指標口徑的一致性

點擊上方“數據管道”，選擇“置頂星標”公眾號

干貨福利，第一時間送達

一、背景

在數據倉庫中，常常使用一些中間表來做數據的過度，這些中間表的產生，都是依托于基礎的埋點表/業(yè)務明細表/用戶明細表等，旨在提高數據提取與輸出的效率。

舉個栗子：

客戶端上報的埋點數據，或者某個功能的明細表，需要與用戶明細表做關聯可使用。這些數據一天的產生都是以億級為單位，數據人員如果每次都將這些數據重跑一次，數據復用性低下，勢必會造成資源和人員的浪費，有些使用第三方數據庫（阿里云）的公司，每次數據提取都是需要錢的，數據量大的話，每次損耗也不少。

同時，明細表的數據存儲，有時會依托于業(yè)務，邏輯比較復雜，對新人不友好（例如，研發(fā)同學會將信息以json格式存儲）。而隨著業(yè)務線的增加，跨表引用增多，如果邏輯口徑發(fā)生變化，勢必會成為一個災難。

所以，中間表的作用，就是在dws層，將基礎事實層的數據，通過與產品人員既定的規(guī)則編寫，用”case when”或syscode系統(tǒng)碼表來將業(yè)務口徑標簽化，將數據固定在對應主題域中，方便日常的匯報或者用戶分析使用。

那么如何來構建有價值的中間表呢，下面看兩個例子，一個是供給端，一個是消耗端：

?

二、案例一（供給端）

某App為辦公協(xié)同類產品，內部附有公司動態(tài)、通知、新聞、培訓課程、留言等功能，管理員或領導層可使用這些功能，下發(fā)一些公司內部的信息，分為全公司可見或者指定部門可見。

如果該App的運營部，想查看某一功能的使用情況，所需要的數據為：

?

形成了一個從供給到消耗的轉化漏斗，來觀測某功能帶來了多少活躍，判定此項功能的使用情況。

該轉化漏斗的難點在于供給人數，可能是發(fā)給全公司的，也可能是發(fā)給個人的，同時涵蓋了上述舉例的多種功能。業(yè)務明細表會記錄該功能的發(fā)布者ID、內容ID，發(fā)送對象ID，發(fā)送類型（公司、部門、個人）等。

這時取數的麻煩點在于，發(fā)送類型如果為全公司，那么業(yè)務明細表關聯用戶明細表時，發(fā)送對象ID（公司ID）與公司ID關聯；發(fā)送類型為部門時，發(fā)送對象ID（部門ID）與部門ID關聯；發(fā)送類型為個人時，發(fā)送對象ID即是用戶ID。用union all 將數據合并，得出了供給人數。

這種數據提取，單次可行，代碼也可復用，但是每次提取花費較大，也比較耗時間，數據都是存儲在邏輯里，并沒有一張表來記錄。OK，那我們就創(chuàng)建一張中間表，將所有功能數據存儲，對于有關需求可以隨取隨用。

?

需要注意的幾點：

1. 考慮供給用戶正常情況下（工作日），數據量較大，所以設計報表時，考慮為每一個業(yè)務進行單獨建表，后續(xù)只考慮總供給的話，可對分表進行處理，去掉內容ID等，進行合并去重。

2. 本表記錄數據較多，所以內容ID對應的其他信息不做記錄，如有需要，與對應業(yè)務表連接即可。

三、案例二（消耗端）

某App為內容資訊類產品，用戶可在其查看各種文章和音視頻，瀏覽入口分為推薦feed流，banner焦點圖，關注頻道，收藏，消息公眾號推送等。

運營人員除了關注整體的文章閱讀外，還會關注各個入口的轉化情況，數據如下：

以上數據，除日活外，都屬于用戶的行為數據，用埋點表即可提取，關鍵在于埋點的數據每天是以億級產生。以上數據當然可以做成BI報表，但是數據依然只是存在于邏輯中，每次需要，每次重新跑，沒有復用性，消耗時效和人效，依然可以用中間表解決這個問題。

與產品/運營人員，開會商議，確定每個來源入口的規(guī)則，對埋點表進行處理，用case when使不同的來源入口標簽化：

?

這樣，一張只記錄用戶關于內容的消耗表就做好了，需要注意以下幾點：

1.本表旨在記錄用戶對內容的消耗，方便數據人員快速解決運營人員的需求，也可做RFM等分析。目前只記錄觀看和播放，是否應記錄互動（點贊、評論、分享等），需要商議。

2.除課程、文章外，是否有必要添加其他類型內容等。

3.由于每天對內容的消耗用戶量較多，所以內容的相關信息本表不做存儲，如有需要，與內容的事實表進行連接。

四、結束語

通過建立中間表，確實可以提高數據的輸出效率，但是光建立是遠遠不夠的，后期的維護也同樣重要。

由于規(guī)則是與產品/運營商定的，必須形成規(guī)范的數據字典文檔，存儲在公共平臺上（wiki、SVN等），有改動或者新增，需及時調整。

有新增的業(yè)務時，也要在發(fā)版之后，添加至中間表中，避免數據遺漏或者重跑。