DAY 21 - dbt 中階 (8) - 專案架構及命名原則 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

2023 iThome 鐵人賽

DAY 21

AI & Data

DAY 21 - dbt 中階 (8) - 專案架構及命名原則

15th鐵人賽 dbt

374 瀏覽

如同軟體開發領域，Best Practices 雖是多數人所認同的大方向，但卻非適用所有情境，且隨時在進化，沒有永久適用的通則。

今天我想分享的是我從使用 dbt 以來，從官方的建議作法出發，加入在 Teamson 導入 dbt 的考量後，在我個人腦中所塑造出來，但卻尚未定型的 dbt 專案架構及命名原則。

相信大家在導入 dbt 時，也能發展出一套屬於自己的 Best Practices Guide。

一個檔案可以放多個 macro，但我喜歡一個檔案只放一個 macro，且檔名與 macro 名稱相同，方便查看。
我習慣將自己開發的 macro 名稱加上 tmsn_ 的前綴，代表是由 teamson 自行開發的。如此一來在文件中能一眼就和 dbt 內建或由 packages 來的 macro 有所區隔。

在 DAY 05 我們拆出了簡易的架構：source -> staging -> final output，現在要進一步介紹 dbt 建議的三層架構：staging -> intermediate -> marts。

資料夾結構：對齊資料來源。
yaml：一個資料來源使用一個 yaml 檔。
model 名稱：stg_[source]__[table_name]，使用雙底線區分資料源及 table 名稱。此處的 table name 我傾向對齊資料來源，因此如果原始 table 名稱是大寫，這裡我也會使用大寫，此為 snake_case 的一個例外。
Materialization： views
一個 source 對應一個 staging model，為一對一的關係。
我們 SAP 的資料來源為同樣的 table。一模一樣的 table 名稱，類似的欄位，出現在多個 schema。為了方便使用，我們在 staging 把這些 table union all 合併起來，避免後續重複的 transformation 要做很多次。

資料夾結構：對齊商業目的
Materialization：tables 或 incremental models
不放代表資料類型 fact 或 dimension 的 fct_ / dim_ 或是 f_ / d_ 前綴，model 名稱盡量用低技術門檻的詞彙。
謹慎考量運算資源及更新時間。
我們最後有再多一層: exposures，我們把最終要呈現出來的資料 materialize 成 table 之後，再多做成 views 給終端使用者。其中一個原因是我們在這個 exposure 層處理不同的 custom schema, alias, 和 user 權限。另一個考量是，如果同樣的資料源，要長成多個 exposure，做成 view 能避免重複跑多個一樣的 table，耗費運算資源及時間。