dbt(Data Build Tool) Part 2 — How KKday Apply
閱讀之前或許可以複習一下 Part 1 後，再繼續閱讀 Part 2 唷！
Storage Layer
概覽一下 KKday 在 Data Storage 的架構，我們使用 Google Data Storage(GCS) 作為資料物件儲存的空間，儲存所使用到的結構與非結構化資料，依照資料量的大小決定新增的方式。使用 BigQuery 作為我們的 Data Warehouse。資料流會透過 dbt 結合 BigQuery 轉換至 Data Lake，再依照不同業務導向內容直接轉換至 Data Mart 或先轉換至 Data Warehouse，若有需求再轉換至 Data Mart，這些過程多半使用 Apache Airflow 做任務的調度，少部分需求會使用到 BigQuery 排程。
下圖為 KKday 資料平台 Data Stroage 的示意圖，圖中有標示不同層之間皆有使用 dbt 輔助資料轉換。
Structue dbt project
當在建立一個資料平台時，會根據情境結合出一個合適的架構，可能是針對 Data Storage、針對業務場景等切出不同的分層，以 dbt 應用來說，不可能使用預設單一專案做應用，這樣在 models 部分會將不同的應用放在同一個資料夾中，變得很混亂且不易控管。
下圖為 Stefano Solimito 的 Medium 文章，作者依照他的經驗切分成四大塊：
Monolithic: 在一個 dbt 專案中同時做清理數據、報表分析等工作。
1. 優點: 在同一個地方容易執行所有內容。
2. 缺點: 當量變大時，會變得難以管理，工程師也難以協作。
Micro-Services: 這不是真正的 Micro-Services，而是引用其概念拆成很多 dbt 專案做不同目的的應用。
1. 優點: 拆成各 project 具有不同的目的，工程師之間也比較好協作。
2. 缺點: 分散在不同 project，資料的沿襲難以追蹤，可能需要一些基礎建設來追蹤也保證不會在不同 project 重複建立 models。
Layers: 在 dbt 專案底下，依照資料平台的邏輯建立各層結構，可以視為 dbt 的子專案，作者主要是以 Reporting、Warehouse、Data Quality、 Raw Data 四層切分。
1. 優點: 能清楚的了解其資料如何沿襲並確保不會重複建立。
2. 缺點: project 規模越來越大時，若管理不當，還是可能混亂。
Layers & Verticals: 類似層的結構，但是在 Data Quality 層後，依照公司特定領域建立一些 Vertical 延伸的服務。
1. 優點: 同 Layers，多了一塊在分層底下，針對不同業務內容再做垂直的延伸分層。
2. 缺點: 夠了解業務內容才能做垂直的延伸分層，有些單一應用業務與公司共享的業務只有些微差距。
dbt Layers in KKday
補充一些使用 Layers 應用的優點：
1. 比起預設的架構 ，更好新增或刪除各層之間的依賴部分，較容易修改。
2. 層與層之間可以獨立運行與測試不互相影響。
3. CI/CD 更加容易。
4. 資料的沿襲對使用者更加友善。
以 KKday 應用來說，目前依照資料平台的架構切分為四塊並依照業務在 models 底下再細分。
DATA_LAKE: 照資料的原樣導入資料平台存放，不用預先處理資料結構定義。
DATA_WAREHOUSE: 定期從不同的資料源豐富資料存入，分析師、工程師、決策者等可以透過 SQL、BI 工具或其他分析工具應用這些資料。
DATA_MART: 針對公司特定業務所加值後的資料，供特定的業務加速分析與決策。
TEMP: 加值後資料的暫存層，像是自動化報表會將 SQL 分析結果透過 TEMP層將資料( csv、xlsx 等) 導出檔案後寄信送出或是反向倒回其他資料源的資料庫做應用。
而資料品質會透過各層底下的 tests 做加值後的資料驗證。
Setting yml
主要是在 models 底下， data_warehouse 分層中設定，要自動化建立的表的形式 View 或 Entity 以及 schema 與 tags 的定義。
analysis-paths:
- analysis
clean-targets:
- target
- dbt_packages
config-version: 2
macro-paths:
- macros
model-paths:
- models
models:
+persist_docs:
columns: true
relation: true
data_warehouse:
ANALYSIS_RECORD:
+schema: analysis_record
+tags:
- analysis_record
ANALYTICS_DATA_WAREHOUSE:
+materialized: view
+tags:
- analytics_data_warehouse
KKDB:
+schema: kkdb
+tags:
- kkdb
THIRD_PARTY:
+schema: third_party
+tags:
- third_party
snapshot-paths:
- snapshots
target-path: target
test-paths:
- tests
version: 1.0.0How to generate docs
在 KKday 的資料導入的案例中，基本會分兩種：
- 內部資料導入：依照業務需求向各部門抓取不同部門或業務中 Database 集中化管理與應用，而針對此種資料流，需要先在 Database 設定 etl_catalog(統整表)並透過 KKdayer 開發的 Python Scripts ，將資料表的 schema 與資訊自動化 generate 成 dbt 的 docs、yml、sql 等檔案，也能在 BigQuery 上查看欄位與資料表的描述。
可以看到下方的 yml ， description 都用 dbt 的 jinja 指向 doc 取得資料表與欄位描述。
version: 2
models:
- name: dbb_airport
description: '{{ doc("dbb__airport") }}'
config:
tags: ['dbb']
columns:
- name: seqno
description: >
{{ doc("dbb__airport__seqno") }}
- name: create_date
description: >
*此為 partition key |
{{ doc("dbb__airport__create_date") }}
- name: create_user
description: >
{{ doc("dbb__airport__create_user") }}
- name: modify_date
description: >
{{ doc("dbb__airport__modify_date") }}Example Command:
此 Command 只為示意，不一定可以直接使用，通過設定好的 doc、yml、sql 等，執行 dbt run ，就會在 BigQuery 上針對 tag 設定的名稱，建立 dataset 與 tables。
dbt run --select tag:dbb- 外部資料導入：依照 API 、爬蟲等方式導入的資料，此種資料流，可以看到下方 yml ，在 dbt 的 schema 與 sql 手動定義清楚，才能在 BigQuery 查看欄位與資料表的描述。
version: 2
models:
- name: aviation_info_airport_info
description: >
aviation edge airport info
config:
tags: ['aviation_info_airport_info']
columns:
- name: airport_id
description: airport id
- name: gmt_diff
description: diff GMT+0 local timezone
- name: airport_iata_code
description: airport iata code
- name: city_iata_code
description: city iata codeExample Command:
同內部資料導入
dbt run --select tag:aviation_info_airport_infoTEMP 層應用
- 直接取用 BigQuery 上的資料計算後，輸出到 GCS ，最後透過 Python Script 與 Airflow 做任務調度將定期的報表寄出又或是 Load 倒回原資料庫讓需求方做應用。
補充： post-hook: executed after a model, seed or snapshot is built.
- 在 models sql 寫 post_hook 觸發 SQL 檔案輸出設定與 SQL 分析。
- 在 schema yml 相關的設定。
# models/daily_report.sql
# 輸出 BigQuery 搜尋結果到 GCS 並存成 CSV 檔案
{{
config(
post_hook="
EXPORT DATA
OPTIONS(
uri='gs://data-temp/{{ this.identifier }}/*.csv',
format='CSV',
overwrite=true,
header=true)
AS
SELECT
user_id,
user_name,
user_phone,
tag,
FROM `data_platform.dm_customer.member_profile`;
DROP TABLE {{ this }};
"
)
}}
SELECT 1 as tmp# schema/daily_report.yml
version: 2
models:
- name: daily_report
config:
materialized: table
labels:
team: data
tags: ['daily_report']Finally
在此篇分享一些 dbt 架構有關的文章與知識，也簡介 dbt 在 KKday 的應用，希望能與不同的使用者們一起交流。
在 KKday 的 Data Platform 逐漸擴大，應用正在增加的情況下，我們的 dbt project 應用或許越來越多，以現在的情況 Layers 架構還算好管理， 但是未來呢？
未來可能將走向 Layers & Verticals 架構，讓較常應用的業務內容有更良好的區分與維護。
Reference
Practical tips to get the best out of Data Build Tool (dbt) — Part 1
step-by-step-guide-to-run-dbt-in-production-with-google-cloud-platform
