在优步，商业指标对于发现我们的业绩、衡量新产品的影响以及优化决策过程至关重要。度量的用例可以从运营人员诊断旅行级别的票价问题，到机器学习模型的动态定价，从而在全球范围内实时塑造一个平衡和稳健的市场。

当我们将度量标准民主化并将其反馈给人类和机器时，我们发现度量标准是必要的。如果没有指标标准化，我们经常会观察到为同一业务逻辑在不同通道中定义或生成的指标的多个版本，这可能是不准确的或具有误导性的。因此，指标的下游消费者可能会做出不一致或糟糕的决策。

要解决这个问题，我们最近建立了umetric，一个统一的内部度量平台，从而为本的全部生命周期定义，发现，规划、计算,质量至消费．到目前为止，我们已经了解了一些乘法器，以扩展董事会标准化的生产力：定义编写、治理、质量和访问控制管理．

案例研究

优步市场团队致力于通过促进乘客和司机的匹配来培育一个拼车市场。衡量效率的一个著名指标是“司机验收率“， 表示为：

驾驶员合格率=接受司机的请求总供应给司机

如果我们提高“驾驶员接受率”，乘客更有可能经历更短的等待时间。更短的等待时间使优步更有可能成为未来出行的首选，从而增加司机获得更多收入的可能性。

驾驶员接受率有几个因素，但旅行价值因素对我们来说越来越重要和有趣。它揭示了价值的一个新定义，名为网络价值:有了更多的访问请求的行程，司机根据当前请求的行程和未来潜在的赚钱机会来评估自己的收入。

例如,t艾克两次来自同一起源，假设它们具有相同的旅程定价：T（跳闸时间）+ D（距离）。司机樱桃挑选一趟旅行B，因为他们知道一旦他们到达旅行B的目的地，他们未来的潜在收益下降与停留在城市中，其中请求的旅行/＃可用驱动程序的数量更高。

为了为司机创造更多的赚钱机会，我们的团队利用机器学习算法，结合实时和历史数据，计算未来可能的收入＃ 的请求的行程/可用司机的编号指标。

数据民主化时代的度量标准化

前面的案例研究展示了指标是如何被评估的，以及如何在优步的决策生态系统中发挥关键作用。为了增强全公司产品的能力，优步的团队对每个指标层都进行了投资:摄入、计算、存储和消费，目的是消除障碍，让决策者能够更广泛地获取指标。

与优步的努力类似，数据民主化也是一个行业趋势。今天，度量消费者比以往任何时候都有更多的选择和不受限制的数据访问。与此同时，工程师也有更多的灵活性来酝酿内部解决方案，利用公共云技术，或者将这两种技术结合起来用于他们的产品用例。

我们受益于数据民主化的发展,我们还面临着一个共同的挑战,许多其他公司:同样的业务度量,不同的团队自己的数据管道工艺和表面数据到个人消费的工具,从而导致观察指标之间的差异。因此，人们倾向于根据他们使用的度量标准的版本得出不同的结论。

例如，“购物会话的指标计算的是骑手会议的次数，并且是最重要的指标之一，可以测量Uber移动应用程序中的骑行者活动。在以下两个可视化工具中，您可以看到给定相同的城市和持续时间，所示度量标准不相互排行。

该问题是root揭示了其中一个工具（摘要）在其静态查询中使用了陈旧过滤器，这些静态查询在会话期间未捕获最新和完整的骑手状态列表。

问题不会结束在这里。我们发现更多客户痛点，因为我们了解更多用户与指标的互动，例如：

• 数据用户，如数据科学家、工程师、运营和产品经理都很难找到所需的表和指标。
• 未管理的、不可靠的和低效的计算管道。
• 缺少必要的信息(描述、SLA、数据源等)。
• 需要系统全面的质量检查。
• 不一致的细粒度访问控制。

我们把这些归结为一个需要:公制标准化，度量标准和业务逻辑有严格的一到一个映射在整个生命周期中没有歧义。

u

优步(Uber)的统一度量平台uMetric起源于一个简单的想法:构建工程解决方案，以解决关键业务度量的差异。快进到今天,我们的团队已经成功地建立了下面的柱子进入生态系统,使完整的生命周期的度量指标和扩展到机器学习功能,不仅为指标标准化,也为“作为服务指标和机器学习功能”。

• 定义每个人都可以编写一个明确且不与现有指标重复的指标。
• 发现：单个搜索和查看的源。
• 规划师:集中知识和执行中心，生成资源效率计划。
• 计算:用于批量，实时度量和回填的可靠和优化的数据流水线。
• 质量:验证和监控所有数据源依赖于依赖和度量标准结果。
• 消费：标准化和多方面的访问接口，可缩放度量标准消耗。

在其余的文章中，我们将分享一些经验教训，发货的技术亮点，以及对公制标准化的持续工程努力。

少即是多

你可能会好奇度量定义是如何工作的每个人都可以编写一个明确且不与现有指标重复的指标。”

定义模型

我们通过与30多个团队和10K+指标的合作发现了两个最常见的重复指标或模糊指标场景:

• 压倒性的度量实例每个切片/骰子尺寸和值过滤器的组合，如“纽约已完成旅行”，“旧金山已完成旅行”，“旧金山每日已完成旅行”等。根据我们的观察，可以有10X或100X实例派生出一个流行的度量，更糟糕的是，它们的一些名称具有误导性，并且不能捕获维度和过滤器的完整细节。
• 混淆度量实例每个源存储类型。为了满足不同度量使用者对新鲜度、延迟和时间跨度的需求，相同的源数据通常在多个存储中可用。例如，一个运营团队定义了“完成旅行”作为一个Presto/Hive SQL在过去18个月的每日仪表板，而定价工程团队创建自己的完整行程指标从Cassandra表的实时服务。从每个团队的角度来看，两者都是有效的。但是，由于不同存储类型的本质，交叉验证关于业务逻辑、维度等的两个定义的一致性是非常重要的。因此，它们为其他团队解释和重用度量标准引入了最复杂的问题之一，最终以团队创建自己的度量标准结束。

为了解决这些问题，uMetric设计和工程了度量定义模型，该模型表示度量逻辑包括:

• 查看定义，它为来自不同存储类型的表的相同源数据创建统一视图。
• 度量定义，详细介绍了如何在SQL中计算指标的业务逻辑，如聚合和表达式，以及关于指标作者、主要业务用例等的基本信息。
• 尺寸&过滤器,这相当于逐个组和SQL中的条款。它们的参数值由消费者在运行时API调用期间提供。因此，在度量定义的存储库仍然倾斜时，对消费者的大部分度量卸载到消费者。

定义模型伪造在运行时或批量/流处理作业的底层表中将度量定义进行实质化的基础，以便在组件中预定策划者和计算．

算法Dedupe

因为视图和指标是用SQL语句表示的，所以指标作者经常在不同的查询格式中草拟重复或类似的指标，但实际上的意思是一个SQL语义．因此，对于给定的规模，构建等价SQL查询的智能算法重复是uMetric的决定因素。

SQL等价性检查被证明是一种np完全问题鉴于其语义为关系代数。基于SQL等效检查的限制，我们实现了一种启发式方法来将查询转换为规范格式，然后比较查询之间的差异。该转换被认为是线性代数属性，如换向，关联和分配。此外，它还平衡SQL查询以消除嵌套查询结构差异。

在图7中，“新的Metric Trip_Completed_ratio."建议…"completed_trips / total_trips“重复使用现有的指标。

在图8中，“起草视图trip_requests"派生为重复视图，尽管它是嵌套查询，具有不同的结构和别名"现有的trip_requests.”的观点。我们的重复数据删除算法通过规范转换消除了结构差异和别名差异。

通过消除重复和不明确的指标，uMetric使得用户从发现到使用的过程中与指标的交互更有效率，而且更易于管理。

治理与护卫舰

在采用uMetric的早期阶段，我们将最重要的业务关键度量划分为优先级，比如完成的旅程。考虑到它们的受欢迎程度，它们在公司中被大量复制，而且是有充分理由的。例如，“完成旅行的指标通常会根据产品类型(UberX、Uber Pool等)进行细分，以跟踪拼车市场的表现。另一方面，Uber Eats团队更感兴趣的是订单类型(中文、泰国语等)的维度，这些不适用于拼车产品。当完整的行程度量被应用到两个组织下的子团队的产品(定价、促销、票价等等)时，分歧会继续扩大，变得更加复杂。因此，不难发现许多团队创建了自己的数据管道来计算指标。

尽管我们丰富了重复数据删除算法，但仍有一些问题没有得到解决，无法实现标准化:

• “一个商业逻辑”的范围是什么？返回“已完成_TRIPS”度量标准的使用情况，该团队决定将驾驶员相关的维度合并到一个指定最多的一个度量标准，并且来自相同的上游源。
• 对于度量定义，比如质量、下游用例的覆盖率、对实时和批处理的支持等等，哪一个是最适合生产的数据源?
• 在没有数据源的符合条件的情况下，应该采取哪些行动，谁是业主？

为了解决这些问题，我们组成了一个团队核查委员会在组织的层次上，个人拥有每个产品线或业务的深入领域知识，并提供解决方案或与能够提供解决方案的产品团队联系。这是一个耗时的过程，需要跨团队的努力才能在最终计划上签字，但是考虑到这些度量标准的影响和众多涉众，这也是必要的。

此外，由于委员会的带宽有限，将流程扩展到更多的度量标准变得越来越紧迫，而且度量作者也需要灵活性，以便在当地小组/团队级别上使用新的度量标准进行实验，而无需经过委员会的审查。

“分层“就是为此目的而提出的:

• 通过区分哪些是重要的，哪些不是，来协调委员会和作者的优先事项。
• 将更多的责任和权限委托给度量作者，以扩展标准化工作。

质量和值得信赖的

通过对指标质量提供透明和可操作的见解，我们成功地赢得了客户对uMetric数据的信任，质量组件是至关重要的。

特别是上游源质量对度量质量有直接影响。一旦在源上定义了生产指标，它的质量就需要被监控，它的所有者要负责一个或多个检查所触发的警报:

• 新鲜的测试验证来源是否在一定的新鲜期内。源新鲜度描述数据的最新程度，其值由源所有者定义。一个度量的新鲜度被导出为所有上游源的新鲜度的MAX。
• 上游跨数据中心一致性测试验证数据中心之间的源数据行数彼此之间的距离在x%以内。一个指标的跨数据中心一致性受到最小的跨数据中心一致性源的限制。
• 上游完整性/重复测试验证指标的源表的完整性和副本，以确保用于计算指标的数据是完整的，没有重复的行。

为了满足我们的质量标准，每个上游来源必须通过所有测试。以上检查的阈值是由下游的度量标准确定的，作为度量作者和验证委员会的资格评估过程的一部分，但是维护质量的艰苦工作落在作为度量标准的基石的源所有者身上。

访问控制

有了uMetric管理的度量的完整生命周期，我们的首要任务是维护一致性在上游源和最终消费者的访问控制策略之间，包括但不限于：

• 继承来自群集/表/列/行级别的源的访问控制策略，以识别使用原始数据权限的消费者。
• 传播对存储层中预先计算的度量数据继承的策略。
• 执行每个用户/服务的策略，在使用期间进行身份验证。

例如,

在图10中的步骤5中，可以直接连接“over_trips.的度量trip_requests.表和trip_uuid列从select count(trip_uuid) FROM trip_requests．但是，度量定义的SQL查询可以与别名，带有或加入的别名进行任意复杂，在SQL中引入源表列中的匹配标识符的挑战。

要解决此问题，请通过利用来构建强大的SQL处理器Apache方解石，它将SQL字符串解析为结构树模型，然后分析节点之间的底层关系。

未来的工作

我们的客户越多，就越清楚我们在组织和产品之间共享的问题空间。然而，每个客户团队总是有定制需求。我们仍处于度量标准的早期阶段，但我们坚信并继续投资于度量标准的主要主题定义编写、治理、质量和访问控制管理．他们建立一个平衡结构，系统地将平台工作和计划整合到uMetric中，并有明确的期望，与相应的涉众合作，并委派相关的责任来扩展标准化。如果您有兴趣加入uMetric团队，请申请加入我们的队伍！