前面介紹了 dbt 主要的功能 (ELT 中的 T)，以及 dbt power user 更方便的應用，接下來會介紹一些 dbt 的其他功能，也許跟 ELT 不是那麼直接相關，但對於完善 data pipeline 也很大的幫助。

Data Quality Test

資料工作者應該有不少跟資料品質相關的痛苦經驗。可以把資料倉儲想像成水庫，資料就像河水一樣，每天都有河水從上游往下流，也許今天的水質沒有問題，但這也不代表明天的水質沒有問題。因此如何每天監控資料的品質，就需要 data quaity monitor 來協助我們完成。dbt 的 test 就是其中一項很好的工具，可以透過在 .yml 裡面加上 tests 的屬性，去檢查單一表格或是單一欄位有沒有符合相關的規定。

之後只需要透過 terminal 輸入 dbt test ，就可以完成每天的資料品質檢測。

Unit test

在做資料轉換時，可能會進行一些很複雜的轉換，舉例來說，可能想要將一些 URL 中的參數分解出來

上面的 URL 可以拆解成下面幾個欄位：

也許我寫了一個邏輯如下：

SELECT 
    url,
    split_part(url, 'utm_source=', 2) AS utm_source,
    split_part(url, 'utm_campaign=', 2) AS utm_campaign,
    split_part(url, 'utm_content=', 2) AS utm_content,
    split_part(url, 'utm_medium=', 2) AS utm_medium
FROM {{ ref("my_model") }};

但我不確定我寫的邏輯是不是適用所有會出現的 url，這時候就可以利用在開發時利用 unit test 去列舉 URL 可能會有的 pattern 以及對應的各個欄位結果，看看這樣的邏輯能不能處理所有的可能情形。

簡單說 data quality test 是每天的例行公事，因為每天都會有新的資料產生，自然就需要每天都檢查。而 Unit test 比較像是在開發時確認複雜的邏輯有沒有寫對，只會在開發或是上版前確認。

套件（Packages） 以及 dbt 相關工具 (dbt native tools)

受惠於 dbt 是一套開源工具，也有不少開源工具建立在 dbt 上，讓我們可以更快速地開發 data pipieline，以下就簡單列出幾個：

套件

• codegen: 可以快速產生一些 models 下常用的程式碼，像是因為 staging 通常是對每個欄位重新命名以及統一資料型別，他就能自動產生類似

select
    column1,
    column2,
    column3,
    ....
from {{ source("source_system","source_table") }}

這樣的程式碼，開發人員只需要針對要改名或是更改資料型別的欄位做修改就好

• dbt-utils：提供一些較複雜的以及常用的資料轉換獲釋 data quality test 的共用函數 （Macros)

• dbt-date: 一些跟日期相關奇怪的東西都在裡面了，像是財務年度之類的。

• [dbt-elementary] (https://github.com/elementary-data/elementary): 幫你把 terminal 產生的 log 收集起來分類好做成表格，有了它搭配視覺化工具，就可以方便地監控 data pipeline 的健康程度。

dbt 衍伸出來的工具：

• Elementary:剛上面的 Elementary 是同間公司開發的，但多了一些像是如果發現 error 會寄通知給 slack 的功能。

• Recce：每次的程式碼更改都有可能影響到資料的分佈情形，讓 Recce 協助你在將資料轉換邏輯異動上到正式版前，了解程式碼對資料造成的影響。