從一個資料科學家或是分析師的角度來看 ETL，就是寫一個接著一個的 SQL，當然有些 Transform 可以使用程式更快速的達到目的，然而怎麼管理這些 SQL 就是這一個題目要討論的問題

通常這是一個在 Serving 階段才會需要注意的課題，但我認為在 Experiment 階段就把這樣的 Mindset 帶入，會讓你在後續銜接 Serving 階段時，更容易實踐好的工程管理

回到我們在架構提到的，第一階段數將資料從 OLTP 同步到 OLAP 階段，這階段比較貼近 資料工程的範疇，一般會使用像是 Airbyte 這樣的工具或是直接透過 Message Queue/ Cloud Service 來實作 Data Engineering Pipeline，最終建立一個 Data Warehouse

而今天要介紹的一個工具叫 DBT (Data Build Tool)是一個開源的數據工程工具，它的目標是使數據工程更像軟體工程，並規範化 Select 以外的步驟 (像是 Insert, Update, Store Data, Push Code, Calculation Optimize ...等等)

換句話說，用戶只要寫一個 SQL，用戶不需要擔心其他的問題，這裡的問題包含了:資料源頭以及資料目的地相依性問題, Query 執行的錯誤偵測和優化，DBT 把這類的功能模組化，使其容易根據模組優化維護

用 Git 管理 SQL 有什麼問題?

只用 Git 會有一個最大的問題，Data Warehouse 會充滿非常多非常多的 Table, 但是你不一定可以找到這些 Table 是怎麼來的

DBT 讓每一張 Table 都要有一個朔源的標章來解決這個問題

DBT 還提供了

• 資料測試驗證工具: 如何驗證你的 Query 在執行後是拿到正確的資訊，就像是 Sql 的 unit test
• 資料操作的紀錄，與快照：可以做還原和監控
• Lineage Graph：可以查詢資料怎麼來的跟被哪裡使用

DBT 常與 Airflow 搭配使用，Apache Airflow 是一個任務排程工具，你可以透過 Airflow 做以下的操作：

每天 00:10 執行 DBT 中的 IP counting extract label 的 SQL Query 來更新 Table

回到一開始提到的，這比較貼近一個 Serving 才會遇到的問題，原因是上面這一張 Table 的產出，就可以作為一個 Model Inference 會用到的 Feature，通常這種每天定時計算，對於實時數據相對不敏感的模型特徵，我們通常稱為 Batch Feature，這個在 Serving 階段會繼續討論

然而有這套 Data Processing Control 在心裡，在實驗階段會比較知道我哪些特徵可以去設計成這種 Batch Feature 哪些不同，這樣比較不會在 Deploy 階段時遇到 Training Dataset 與 Inference Feature Pipeline 有 Conceptual Drift 的問題