dbt 是個很彈性的工具,像是光一個 model 要設定形式是 table or view 就有3個地方可以寫
version: 2
models:
- name: base_events
description: "general event"
test:
config:
materialized: view
sort: event_time
dist: event_id
columns:
- base_col
test:
- unique
3.每個 model.sql 的最上方有個 config 區塊
{{
config(
materialized = "table",
sort = 'event_time',
dist = 'event_id'
)
}}
select * from ...
聰明的朋友可以發現,3種設定方式有階層關係,dbt_project.yml > schema.yml > model.sql,而dbt 設定中,下層的設定會覆蓋上層的,例如: 你在 a_model.sql config 設定 materialized = table,就算最上面 project 層級的 dbt_project.yml 設定該 database 下皆為 view,下層的設定都會覆蓋掉上層的。
以上看到 dbt 就是這麼彈性的工具,但也因為彈性,可能讓你的 project 變得混亂難以管理,例如:你要改個 materialized 就可以去3種地方,那我們要如何管理這些設定呢?
首先要認識這些設定其實分兩種:
配置(configs)
configs 是有層級性可以被繼承的,例如: materalized, tags,bigquery 的 project 下的所有 table 可以都可以繼承上層設定
屬性(properties)
properties 是屬於 model 層級的設定,像是 description, column, test,每個 model 有各自的 description 和 tests
根據官方文件的 rule of thumb, migo data 團隊討論出比較好管理的規則如下:
資料夾層級範例
# dbt_project.yml
models:
migo_dbt:
migocorp:
+tags: migo
+materialized: table
+database: migocorp-2209
migocorp:
datamart:
+schema: datamart
analytical:
+schema: analytical_data
dashboard:
+schema: dashboard
thinker:
+database: migocorp-2209
+schema: migocorp_sql_lounge
+materialized: view
# schema.yml
version: 2
models:
- name: migocorp.datamart.LineMember
description: "Line會員"
columns:
- name: line_uid
description: "line uid"
tests:
- unique
- not_null
- name: migocorp.datamart.LineMemberTags
description: "漸強Line會員 Tag "
- name: migocorp.datamart.Lit_Member
description: "Lit 會員資料"
columns:
- name: third_party_line_uid
description: "line uid"
# source.yml
version: 2
sources:
- name: migocorp_api_lobby
schema: migocorp_api_lobby
database: migocorp-1806
tables:
- name: line_member
columns:
- name : line_uid
tests:
- not_null
- unique
tags:
- migocorp