Skip to content

LYFT

Read original ↗

Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions

Summary

Lyft built an internal Metric Semantic Layer (MSL) — a centralized Python package that serves as the single, authoritative repository for every "Golden Metric" definition in the company. Each metric is codified as a YAML configuration with Jinja-templated SQL, exposed through Python methods and APIs. The system solves the problem of metric definition drift that emerges when teams independently define the same metrics with subtly different SQL, leading to inconsistent decisions. MSL enforces consistency through three pillars: (1) simplified onboarding via config-driven definitions that propagate changes automatically to all downstream consumers, (2) intentional governance via a dual-ownership model (Business Owner + Operational Owner) with required mutual approval for changes, and (3) transparency through API access, data catalog integration with Amundsen, self-service UI, and MCP (Model Context Protocol) integration for AI agents.

Key takeaways

  1. Metric definition drift is the core problem: As Lyft scaled, different teams used different SQL definitions for the same metric, leading to inconsistent decision-making. Without centralized version control, outdated definitions crept into production dashboards and ML models.

  2. Implementation as a versioned Python package: MSL is a Python package (not a service), distributed and versioned with automated code refactors pushing updates to all dependent applications. This gives deterministic, reproducible SQL generation without runtime dependencies.

  3. YAML + Jinja for DRY metric definitions: Each metric is a YAML file declaring metadata (owners, data sources, dimensions, granularities) with SQL logic stored in Jinja templates. Jinja was chosen over other templating frameworks for its lower learning curve and ability to avoid redundant SQL declarations across granularities (DRY methodology).

  4. "Golden Metrics" selection criteria gates onboarding: Not all metrics enter MSL — only "Golden Metrics" with at least two distinct use cases or applications qualify. This prevents the package from becoming a dumping ground of niche team-specific metrics.

  5. Dual-ownership model enforces accountability: Every Golden Metric requires both a Business Owner (data analyst/scientist — responsible for metric health, definitions, limitations) and an Operational Owner (data engineer — responsible for data health, ETL pipelines, DQ checks, backfills). Both must approve changes, providing informed coordination and quality control.

  6. Team-based ownership for resilience: Owners must be teams, never individuals — deliberately designed to survive org changes, team rotations, and attrition.

  7. Multi-channel access pattern: The Python API is the core, but MSL is also surfaced through Amundsen (discoverability/search), a self-service Metric UI (no-code SQL generation), and an MCP server for AI agents (natural-language metric queries with reduced hallucination).

  8. AI-native by architecture: Because metric definitions are stored as clean, structured YAML, they serve as a knowledge base for AI agents with "greater accuracy and fewer hallucinations." Guardrails baked in using ground-truth evaluation and LLM-as-a-judge techniques.

  9. Automated downstream propagation: When a metric definition changes, the updated package version is deployed to all dependent applications through automated code refactors — consumers don't need to take manual action.

  10. Evolving toward vendor-managed solutions: Lyft acknowledges MSL as a "great foundation" but is exploring vendor-managed options for broader third-party BI/database integration and AI-driven analysis.

Systems / concepts / patterns extracted

Systems

Concepts

Patterns

Operational numbers

  • YAML config per metric includes: operational_owner, data_sources, view (SQL template), time_attribute, time_granularity (day/week/month), dimensions, and metric definitions with type annotations (Additive, etc.)
  • Python package is versioned with periodic automated deployment to all consumers
  • MCP integration uses ground truth + LLM-as-a-judge evaluation guardrails

Caveats

  • The article does not disclose scale numbers (how many Golden Metrics exist, how many downstream consumers, latency of SQL generation).
  • MSL is a Python package, not a service — which means it requires periodic re-deployment to consumers (push model), not real-time resolution (pull model). The article frames this as a feature (deterministic) but doesn't discuss the propagation delay.
  • The article acknowledges MSL is a "homegrown solution" and Lyft is actively evaluating vendor-managed alternatives for broader integration, suggesting the approach may not scale to all BI tool integrations.

Source

Last updated · 542 distilled / 1,571 read