Skip to content

PATTERN Cited by 1 source

YAML-config-driven metric definitions

Pattern

Codify business metric definitions as YAML configuration files declaring metadata (owners, data sources, allowed dimensions, time granularities, metric type) alongside SQL logic stored in Jinja templates. The YAML serves as both human-readable documentation and machine-parseable input for SQL generation.

Structure (Lyft's MSL)

operational_owner: rides_table_owners
data_sources:
  - rides_table
time_attribute: ds
time_granularity: [day, week, month]
dimensions:
  - dimension_name: region
    dimension_expression: ride_region
    dimension_definition: Ride region
metric:
  - metric_name: rides_completed
    metric_description: Rides with drop off completed
    metric_type: Additive
    business_owner: rides_owner
    aggregated_expression: "1.0*count_if(is_dropped_off)"

Why YAML + Jinja

  • Readability — non-engineers (Business Owners) can review definitions
  • DRY — Jinja macros avoid redundant SQL across time granularities and dimension combinations
  • Lower learning curve — Jinja chosen over alternative templating frameworks for accessibility
  • Machine-parseable — AI agents and tooling can consume definitions directly as a knowledge base

(Source: sources/2026-06-10-lyft-metric-semantic-layer)

Relationship to other patterns

This is a metric-governance-specific variant of patterns/config-driven-dag-generation, which Lyft also uses in its Feature Store (SparkSQL + JSON config → Airflow DAGs). The key difference: here the config generates SQL queries, not orchestration DAGs.

Seen in

Last updated · 542 distilled / 1,571 read