指标语义层：Lyft 如何治理与扩展关键数据定义

[

Lyft Engineering

Lyft 工程

](https://eng.lyft.com/?source=post_page---publication_nav-25cd379abb8-56bee3643c29---------------------------------------)

[

Lyft Engineering

](https://eng.lyft.com/?source=post_page---post_publication_sidebar-25cd379abb8-56bee3643c29---------------------------------------)

Stories from Lyft Engineering.

来自 Lyft 工程团队的故事。

Written by Rohit Channe and Simran Mirchandani at Lyft.

作者：Rohit Channe 和 Simran Mirchandani ，来自 Lyft。

Motivation

动机

At Lyft, data isn’t just a resource — it’s woven into everything we do. Metrics drive key forecasts, steer operational decisions, and put our boldest hypotheses to the test. But as Lyft scaled, products launched and evolved, and team members came and went, we found ourselves at risk of different teams using different definitions for a given metric. What did “Metric ABC” actually mean? The answer often depended on the context and application of the team you asked.

在 Lyft，数据不仅仅是一种资源——它已经融入我们所做的每一件事。指标驱动着关键预测，指导运营决策，并检验我们最大胆的假设。但随着 Lyft 规模的扩大、产品的发布与迭代，以及团队成员的来来往往，我们发现面临着不同团队对同一指标使用不同定义的风险。“指标 ABC”到底是什么意思？答案往往取决于你所询问的团队的背景和应用场景。

The consequences were predictable. Without centralized version control or a shared standard, outdated metric definitions crept into decision-making.

后果是可以预见的。由于缺乏集中式版本控制或共享标准，过时的指标定义悄然渗入决策过程。

Our solution was to build an internal Metric Semantic Layer (MSL): a centralized repository that serves as a single, authoritative home for every metric’s definition — providing both a clear, plain-English description and the definitive SQL code. No more hunting across codebases or tribal knowledge — just one place to store and access a standardized, agreed-upon definition. With MSL, we have a single source of truth — consistent terminology and assumptions across every team, so everyone is genuinely...