前面幾篇介紹了 dimensional modeling, dbt 的功能以及 dbt Power User 方便的地方。這邊就總結一下，用 dbt 作為資料轉換的主要工具，可以做到哪些事

dbt 有哪些功能

ELT 中的 T

隨著儲存成本降低，現代資料棧越來越傾向於將未經任何轉換的資料直接輸入資料倉儲中，在這樣的工作流程下 dbt 就很適合作為資料清洗、轉換的主要工具。而在這樣的資料倉儲中，資料轉換在資料倉儲中大概會依序經過以下幾個不同資料建模的階段：

data source → snapshot / CDC → staging → intermediate / data vault → data mart (dimensional modeling) → Report (one big table)
其中 data source 以及 snapshot / CDC 的部分可以在 EL (Data ingestion）時透過好的source 層的資料模型設計就直接完成。其中 dbt 提供 dbt seed ，可以將含有少量資料的 csv 輸入到資料庫中：另外，即使 data source 是沒有保留歷史狀態的設計，也能透過 dbt snapshot 做到定期的快照 (Snapshot）。而之後資料建模間的轉案可以說是 dbt 的主要功能，透過 dbt run 將寫好的資料轉換模型，依序有規模地將原始資料轉換成分析用的資料模型。

文件紀錄以及 DAG

如果問我，資料團隊最困難的工作是什麼，我會認為是該如何讓每次 query 出來的資料都是一致的。因此 dbt 也提供了 documentation 的功能，讓開發者可以定義每張表格以及欄位，並可以dbt docs generate ，dbt docs serve 架設一個靜態網站讓每個人可以查詢。另外也有自動生成的 DAG ，讓表格的上下游關係一目瞭然。

資料品質檢驗

每天都會有新的資料從資料源系統，流入資料倉儲中。透過 dbt test 有效把關資料品質，在使用者使用儀表板發現問題前，就可以找到資料品質問題的源頭，並進行修復。

每日任務自動化

如果呈現在儀表板的資訊需要每天更新，以批量處理為例，那這整個 data pinepline 的執行順序大概會是以下：

資料倉儲跟資料源同步 → dbt seed (Optional) → dbt snapshot → dbt run → dbt test。

當然可以選擇每天都手動在 terminal 輸入以上指令，但也可以透過 cron job 進行排程，如果資料更新的頻率相對複雜，也可以使用 Orchestration Tool (如： Airflow, Dagster, Kestra 等等）協助排程。

dbt 以及 data mart 的設計大概就介紹到這邊，明天會開始介紹 Power BI 的 語意模型設計 (Semantic Dataset)。