昨天,我們花了許多時間,說明 dbt 的 model 大致的架構,是如何將 sql code 梳理成乾淨的資料流,並透過視覺化的方式,盡量讓工程師們可以最快、最彈性的進入狀態。
不過,光是 dbt 的某些提醒,就足夠讓經驗豐富的工程師大皺眉頭了。
「什麼?你說 mart 只要存放實體,卻不能將事件 group 起來(grain into certain units, like days / users etc)?這樣要怎麼設計指標?」
沒錯,就我的資料哲學而言,data 核心的價值,就是將商業價值量化呈現。這件事情,就是設定指標。
在 dbt 中,model 是透過 sql & yaml 所組建,但 semantic layers,卻只透過 .yml 來構成。
假設,阿華炒麵店每天都會固定收看訂單 & 營收,那我們該怎麼寫這個 semantic layers 的 .yml 呢?
semantic_models:
- name: orders
defaults:
agg_time_dimension: ordered_at
description: |
Order fact table. This table is at the order grain with one row per order.
model: ref('stg_orders')
entities:
- name: order_id
type: primary
- name: location
type: foreign
expr: location_id
- name: customer
type: foreign
expr: customer_id
dimensions:
- name: ordered_at
expr: date_trunc('day', ordered_at)
# use date_trunc(ordered_at, DAY) if using BigQuery
type: time
type_params:
time_granularity: day
- name: is_large_order
type: categorical
expr: case when order_total > 50 then true else false end
measures:
- name: order_total
description: The total revenue for each order.
agg: sum
- name: order_count
description: The count of individual orders.
expr: 1
agg: sum
- name: tax_paid
description: The total tax paid on each order.
agg: sum
沒錯,只需要透過簡單的描述(不過 yml 的規則的確略為複雜,讓我們明天更細緻的說明),我們就可以計算以下幾件事情:
這樣,阿華炒麵店就可以透過 dbt 來更精確和便捷地了解自己的指標設定,從而更有效地進行商業分析和決策。接著,我們將在明天的文章中更詳細地介紹 YAML 的語法和 dbt 的進階設定,敬請期待!