從 staging 到 marts 這幾個階段分別要做什麼轉換，過去有蠻多人討論過的，這邊挑一篇讓大家參考（連結）。

今天想來談談看了文件的切分方法之後，實作時仍遇到需要討論跟共識的轉換：

欄位篩選

在建置 staging 時，我們想了很久，究竟應該將全部欄位都先加入進來，還是只選擇必須的欄位呢？

全部都加進來乍看之下省時省力，但資料庫就會變得稍嫌雜亂，以工程師的角度而言，最麻煩的是，要多寫很多文件 = =

只選擇必須的欄位的話，則是在一開始建立就需要思考，哪些是有需要的欄位，花時間是一點，另外則是需要擔心只抓了目前必要的欄位，未來開發新功能時，是否會忘記其實原始資料中還有其他有價值的資訊。

我們最後的作法是，看起來完全棄用、在現行服務下往未來看，還看不到用途的欄位不錄入資料表中，這部分可能需要有共識，另外一點小提醒，若要選擇全部欄位，用 select * 無法提供資訊，我們通常在模型的開始跟結束，都會把欄位全部列出來。

異常資料

異常資料有蠻多類型的，像是過去曾經因為平台有 bug，而出現的不合理紀錄；或是使用者不合理的使用方式，導致紀錄出現不可能的數值；陰錯陽差沒有記錄到某些欄位的資訊，或是不知為何重複了很多筆同樣的紀錄。總之，bug 總會用意想不到的方式出現在我的生命中。

針對這種情況，由於我們認定這些資料是「異常、不合理、不應該出現」的，所以我們最後的共識是盡早在 staging 環節中就將這些有問題的資料篩除。當然最好還是直接在原始資料中直接移除，不過，這種要跨組溝通的業務相對來說就耗時耗力了。

業務邏輯

業務邏輯這個部分，通常會預設在 marts 中處理，畢竟 marts 本身就是以業務單位或業務邏輯來做切分的。

至少在導入初期是如此。

後續在重構時，我們逐漸將模型甚至是程式碼做拆解，找到重複的部分，就將其拉至 intermediate，以利重複使用。

像是平台中，我們需要運算以班級為單位的各種數據，原先在 marts 中，哪個業務單位需要班級數據，我們就在該模型中去以班級為單位整理資料。

而當我們把班級單位的轉換搬移至 intermediate 中，任何業務單位需要班級數據，只要拿這張表去跟使用數據做 join，就可以取得數據，不需要各自在做運算，省工是其次，重點是，同樣的事情只做一遍，避免多做做的不一樣、要改的時候漏了改。

建立指標

建立指標就比較有趣，dbt 有專門建立一個 semantic layer（文件中有手把手的教學），可以定義業務指標，不過我們目前沒有使用，這個部分比較複雜，不使用的原因後面再另外討論。

目前我們的指標會建立在 marts 層級中，不過先決條件是這個指標已經經過驗證，或是我們將其視為必須十分重視的指標，因為不會期待每次業務單位都來提出需求，調整指標的邏輯。

如果有經常變動的指標怎麼辦？

我們目前的視覺化工具是使用 metabase，對於常變動的指標，我們就將邏輯寫在 metabase，方便調整，甚至業務單位如果看得懂基礎的 sql code，可以自由取用。

時間分段

不同需求可能會需要日、週、月為顆粒度的資料，如果有需求的話，我們會在 marts 層級中分別建立這幾張不同顆粒度的表。

這邊想提一個講出來很簡單、但在一開始規劃時我們遺漏掉的細節：

一開始我想說資料先整合成日顆粒度的資料，之後要做週或是月顆粒度的資料，都可以從這張表往下做。

後來發現錯得離譜，如果要計算不重複使用者、不重複使用內容，當我以日為顆粒度加總時，我是無法得知週或是月的不重複使用狀況的，當初自己發現時實在是有夠懊惱，望週知。