dbt 是什麼？為什麼最近在台灣資料工程工作當中廣泛應用？
在科技業、網路業、零售及電商業、金融業等，比較多數據的產業，越來越多前端的決策 (比如說：自動化行銷、顧客旅程的實踐)，都越來越仰賴「數據」，但是很多時候其實是卡在數據從搜集，到後面資料工程的轉換 ETL (Extract, Transform, Load)，都需要時間、也需要工程師的參與。
有些較小型的零售及電商業，可能沒有資料工程的資源跟人力，那前端部門 (行銷、業務、營運部門) 取得資料的時間就會變長，甚至是無法取得。
所以為什麼這時候 dbt 出現，讓很多小型單位得到天降甘霖的協助！
在 dbt 出現之前，資料工程的工作流程是什麼 (ETL)？
最經典 (傳統) 的資料工程流程 (data pipeline)，是我們俗稱的 ETL，流程大概如下：是將資料從資料源頭擷取 (E)、轉換 (T)、載入 (L) 到資料倉儲的一個流程：
- 資料源頭搜集：資料源可以是各種內部或外部系統，例如資料庫、應用程式、檔案、網站等
- 用自動化的排程，將資料用 E、T 的方式完成，並且儲存到資料倉儲當中，例如：資料庫、AWS、Azure、GCP 等地方
- 接著把資料倉儲當中的資料，設計成「資料表」的形式，提供給資料分析師或是其他業務團隊應用
更多經典 (傳統) 的資料工程流程 (why & how)、還有學習路徑，以及 project 製作，可以參考我的文章 (我也是這樣慢慢學過來的)：轉職資料工程師之前先做這個專案！還有要提前知道的 5 件事 ！
dbt 出現之後，工作流程的轉變 (ELT)？
dbt 是 data build tool 的縮寫，簡單來說是 ETL 工具的一種，他用於「簡化資料轉換」的過程。
dbt 使用 SQL 語法來定義資料轉換的規則，算是降低了做資料工程的難度，所以一般資料分析師也可快速上手！
dbt 出現之後，他注重在 T (Transform) 的部分，以下是 ELT 的資料工程步驟：
- 資料 Raw Data 進入資料庫中 (常見的雲服務，如：AWS、Azure、GCP)，意思就是先把資料塞到資料倉儲 (data warehouse) 當中！(也算是受惠於目前雲服務的普及，可以儲存越來越多資料、費用也越來越便宜 !?）
- dbt 進行 low code 的 Transform 階段，資料分析師只要用 SQL 語法就可以將自己想要的 table 轉換出來：T 的轉換就讓他在資料倉儲內就輕鬆完成，解決了資料在 EL 過程中，不斷轉移又進入資料庫！這樣就不再高度仰賴工程師去做 ETL 給業務團隊，資料分析師只要熟悉 SQL，就可以完成 ELT！接下來就來詳細拆解這部分！
dbt 在資料工程中的應用：2 步驟解析！
1. 把 Raw Data 的資料源頭搞定
- 先把 Raw Data 的源頭整理清楚
- dbt 支援滿多的資料倉儲系統：大部分公司愛用的、常見的比如：Postgres、BigQuery、Apache Spark、Snowflake、Presto 都支援
- 第一步驟，當然就是讓資料 Raw Data 進入資料庫中，也就是完全不用做 ETL，就先把資料塞到資料倉儲 (data warehouse) 當中
2. Develop+Test+Deploy：開發 Transform、測試、部署上線一次搞定
- dbt 讓「有 SQL 資料分析技能的資料分析師」透過 SQL 來建立、轉換、測試、部署資料倉儲中的資料
- 這等於是，如果未來的各部門內都有自己 in house 的資料分析師，他們就可以用 SQL 自己定義各部門的資料邏輯，接著自己做自動化測試，最後再部署程式碼
如果我們用官方給的圖來解釋：dbt 應該是參考演進很久的軟體開發流程，開發 → 測試 → 部署
- Develop 開發：SQL 生成 Transform。dbt 用模組化的方式，讓 code 易於維護，且 dbt 模型之間的依賴關係可以幫助確保 dbt 模型的正確執行順序
- Test & Documents：Test 是編寫測試 (有點像 QA)、寫檢查，讓數據有錯時不會進入下游。Document 是會幫我們紀錄「數據定義」跟「相互依賴的關係」(從哪個倉儲、哪邊來的)，讓其他人可以方便維護 XD 而且整個流程 dbt 會幫我們做好 version control，這樣對於 CI/CD (跨平台的整合跟部署) 就會方便很多！！
- Deploy 部署：測試沒問題，進行最後的部署 (就是上線囉～)
dbt 中英文學習資源推薦
- dbt 中文教學 (搭配官方資源)
- 英文資源：dbt in 1 hours Series
- 英文資源：Snowflake (很火的資料倉儲) + dbt + Airflow (很常見的自動化排程工具) Project
個人滿推薦如果不想碰傳統的 ETL 專案，coding 能力 (python) 也不強，可以直接試試 dbt 工具！至少在台灣，已經慢慢開始部署到資料工程的流程當中～
數據分析師也能開始做資料工程 (ELT)？
一般的初階數據分析師熟悉的工具，不外乎是 excel、SQL、BI tools 跟少量 python，在這樣的情況下，要直接去做傳統的 data pipeline (ETL) 其實有一點困難～
我個人覺得 dbt 這個工具，可能正在加速整個數據流程的演化！以前我們需要有人搞定 pipeline 之後 (data warehouse 資料倉儲 → data mart 資料表) 才可以用到資料，現在是 raw data 一進到 data warehouse 之後，資料分析師就可以憑一己之力 (low code 工具 – dbt) 去完成數據取得！
這樣一來前端部門用到數據的速度也會加快！決策也會加快！決策利用數據的程度也能越來越高！！
dbt 帶來的優點：3 個主要優勢，尤其對新手！！！
- low code：用 SQL 就可以做 data pipeline & 自動化，減少人工執行跟程式碼的維護成本，團隊也不一定要具備很扎實的 python 技能就能完成～
- Test、版本控管、CI/CD 比照軟體工程的開發流程：整個流程 dbt 能夠做到 version control、也可以用 Git (常用來做版本控管的工具) 來控管 dbt 相關專案，這樣對於 CI/CD (跨平台的整合跟部署) 就會方便很多！！
- 資料依賴關係 & 文件一併紀錄：資料工程師最討厭做 document 啦～～但 dbt 都幫我們做好了，當團隊的數據分析說需更改條件的時候，可以憑藉著流暢的 document 快速上手
總之，dbt 就是一個把資料工程的學習曲線降低的工具，如果工程團隊能把 dbt 架好，後面的維護其實就能交由初階數據分析師去維護！這也會讓初階數據分析師進步得更快，畢竟碰到的 scope 變大，經歷就能累積的更快！！
dbt 帶來的缺點
我個人整理後，認為比較大的缺點是：需要依賴其他工具完成部分功能：因為 dbt 本身擅長資料轉換的部分，也就是 T (Transformation) 的部分，但資料擷取 (EL 部分的 E) 和資料載入 (EL 部分的 L) 可能需要其他工具協助完成～
就像上面的 project 範例：Snowflake (很火的資料倉儲) + dbt + Airflow (很常見的自動化排程工具) Project，他需要資料倉儲、也需要自動化排程工具的參與！
不過整體來說，他能夠把 low code、跟以 SQL 完成 data warehouse 資料倉儲 → data mart 資料表這件事，我已經覺得，對於初階數據分析師而言，是很幸福的一件事了！！
資料工程的門檻也越降越低了嗎？
資料工程以前是比較適合軟體工程師轉職，或是數據分析師轉職的行業！但最近一兩年，我認為門檻有降低的趨勢，主要因為幾個因素：
- 資料轉換工具的發展：dbt 等資料轉換工具的出現，讓 data pipeline 更輕鬆的進行資料轉換
- 雲端服務的普及：例如 Amazon Web Services (AWS)、Google Cloud Platform (GCP) 和 Microsoft Azure 等雲端服務提供商都提供了各種資料基礎設施服務，包括資料倉庫、資料湖、資料分析工具等。企業也不太需要再自己搭建和維護資料伺服器了！
數據分析也要會資料工程？
目前觀察到，市場上會有些數據分析工作期待大家也能協助做資料工程，所以轉職之前，歡迎先參考：轉職資料工程師之前先做這個專案！還有要提前知道的 5 件事 ！，再來決定要不要轉職！
如果你還是希望轉職數據分析，但發現技能需求「越來越複雜」，越來越多聽不懂的，也可以參考底下我的陪跑計劃！
