Implementation Examples

The pattern is consistent across tools: the calculation logic lives in exactly one place, named once, and every consumer resolves to that same definition rather than a private reimplementation.

dbt Semantic Layer

Metrics are defined in YAML on top of dbt models, then queried via a consistent API (MetricFlow) regardless of the BI tool on the other end:

semantic_models:
  - name: orders
    model: ref('fct_orders')
    entities:
      - name: order
        type: primary
    dimensions:
      - name: order_date
        type: time
    measures:
      - name: order_total
        agg: sum
        expr: amount
metrics:
  - name: net_revenue
    type: simple
    type_params:
      measure: order_total
    filter: "{{ Dimension('order__status') }} != 'refunded'"

Any tool querying net_revenue gets the same filtered, aggregated number, no one downstream rewrites the refund logic themselves.

Power BI Semantic Model (Direct Lake)

A dataset built on OneLake tables where measures are defined once in DAX and published as a shared model:

Net Revenue = 
CALCULATE(
    SUM(Orders[Amount]),
    Orders[Status] <> "Refunded"
)

Every report built against that dataset inherits this measure rather than each report author writing their own SUM and forgetting the refund filter.

LookML (Looker)

Measures and dimensions are defined in a modeling layer separate from the raw tables:

measure: net_revenue {
  type: sum
  sql: ${amount} ;;
  filters: [status: "-refunded"]
}

Cube

An open-source semantic layer that sits in front of the warehouse and serves consistent metrics over an API to any downstream tool, BI, apps, or notebooks:

cube(`Orders`, {
  measures: {
    netRevenue: {
      sql: `amount`,
      type: `sum`,
      filters: [{ sql: `${CUBE}.status != 'refunded'` }]
    }
  }
});

Pages: 1 2 3