昨天，我們花了許多時間，說明 dbt 的 model 大致的架構，是如何將 sql code 梳理成乾淨的資料流，並透過視覺化的方式，盡量讓工程師們可以最快、最彈性的進入狀態。

不過，光是 dbt 的某些提醒，就足夠讓經驗豐富的工程師大皺眉頭了。

「什麼？你說 mart 只要存放實體，卻不能將事件 group 起來（grain into certain units, like days / users etc）？這樣要怎麼設計指標？」

沒錯，就我的資料哲學而言，data 核心的價值，就是將商業價值量化呈現。這件事情，就是設定指標。

如何透過 dbt 設定指標用的 pipeline？

在 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 的規則的確略為複雜，讓我們明天更細緻的說明），我們就可以計算以下幾件事情：

• 總訂單金額（order_total）：透過將所有訂單的金額聚合起來，我們可以得知一天、一週或一個月的總營收。
• 訂單數量（order_count）：這個度量可以幫助我們了解店內的訂單流量，有助於營運決策。
• 總稅金（tax_paid）：這讓我們可以清楚地知道每一個訂單或一段時間內所需支付的稅金總額。

這樣，阿華炒麵店就可以透過 dbt 來更精確和便捷地了解自己的指標設定，從而更有效地進行商業分析和決策。接著，我們將在明天的文章中更詳細地介紹 YAML 的語法和 dbt 的進階設定，敬請期待！