某海外住宿平台如何在大规模场景下实现指标一致性：Minerva 指标平台实践

Meta Description： 本文介绍某海外住宿平台如何通过 Minerva 指标平台，在大规模数据分析、实验报告和高管决策场景中统一指标口径，实现指标一致性、数据可信和分析效率提升。

第一部分：Minerva 简介——一个面向大规模数据分析的指标平台

作者：某海外数据平台团队
发布时间：2021 年 5 月 1 日

图片说明：数据是用户声音在大规模场景下的体现。新冠疫情期间，我们通过数据看到，旅行需求已经明显转向本地化。

引言：为什么大规模业务需要指标一致性

在某海外住宿平台，我们依靠数据指导关键决策。我们通过随机对照实验验证产品创意，并持续、严谨地跟踪业务表现，确保为业务和用户创造最大价值。为了实现这些目标，我们需要构建一套强大的数据平台，满足内部用户从数据采集、建模、分析到决策支持的端到端需求。

对于任何数据驱动型组织来说，指标一致性都是数据分析的基础。如果不同团队对同一个业务问题给出不同答案，决策者就很难判断哪个数字可信。Minerva 正是为了解决这一问题而构建的指标平台。

此前，我们已经分享过如何将数据导入数据仓库，以及如何让用户结合上下文数据开展自助分析。但我们还没有系统讨论其中的中间层：如何正确地对数据进行建模和转换，使其成为准确、可信、可用于分析的数据集。

本文将分享我们构建 Minerva 的历程。Minerva 是公司内部的指标平台，被广泛用作分析、报告和实验的单一可信数据源。我们将具体说明为什么要构建 Minerva，介绍它的核心功能及其支持的工具生态，并重点展示它对公司的影响。在后续文章中，我们会进一步深入 Minerva 背后的技术细节，并分享一路走来的经验教训。

我们希望通过这个系列，让读者理解 Minerva 这类系统的价值，并从中获得启发，为自己的组织构建类似的数据指标平台。

数据分析体系的早期发展

与许多数据驱动型公司一样，我们的数据之旅起步也很简单。大约在 2010 年，公司只有一名全职分析师负责数据工作，而他的笔记本电脑实际上就是公司的“数据仓库”。查询经常直接在生产数据库上运行，高成本查询偶尔还会引发严重事故，甚至导致线上网站宕机。

尽管存在这些缺陷，但这种简单方案在随后几年里，依然帮助公司发现了许多增长机会。

2010 年代初期，随着业务规模不断扩大，公司聘请了更多数据科学家，数据量和数据类型也持续增长。正是在这一阶段，我们经历了第一轮数据基础设施变革：升级并稳定数据基础设施。我们放弃了原有调度系统，转而使用后来开源的工作流编排工具 Airflow，并投入资源构建了一套名为 core_data 的关键数据表。

图片说明：公司的业务规模和数据规模在多年间都实现了大幅增长。

以 core_data 为基础，公司的数据分析能力开始快速发展。首先，我们构建并扩展了实验平台，将 A/B 测试文化引入公司。随后，我们构建了内部数据目录 Dataportal，用于组织和记录数据；又创建了后来开源的可视化分析工具 Superset，让更多用户能够独立、交互式地分析数据。

最后，我们还专注于数据教育，推出了“数据大学”项目，为非数据科学背景的员工提供实用技能培训，从而在公司内部推广数据分析能力。

指标体系成长中的问题

虽然 core_data 显著提升了公司的数据能力，但这种成功也伴随着巨大代价。事实上，数据和使用场景的快速增长，给数据生产者和数据消费者都带来了严重的成长烦恼。

首先，随着 core_data 越来越普及，越来越多的数据生产者希望将其用于分析、预测和实验。几乎每天都有人基于 core_data 表手动创建新表，却很难判断仓库中是否已经存在类似表。数据仓库变得越来越复杂，数据血缘也越来越难追踪。

即便上游发现并修复了某个数据问题，也无法保证这个修复能够同步到所有下游任务。因此，数据科学家和工程师花费了大量时间调试数据差异、处理突发问题，常常感到效率低下，也十分沮丧。

图片说明：基于 core_data 构建的派生表不断增加，带来了严重的成长问题。

在数据消费侧，我们也经常听到决策者抱怨：不同团队在回答非常简单的业务问题时，会给出不同数字，而且没有简单办法判断哪个数字才是正确的。

几年前，当公司负责人提出一些看似简单的问题，例如“上周哪个城市的预订量最高”时，数据科学团队和财务团队有时会给出截然不同的答案。原因在于，他们使用的表、指标定义和业务逻辑略有差异。

随着时间推移，就连数据科学家也开始怀疑自己使用的数据。大家对数据质量的信心下降，决策者对数据的信任也随之降低。

用 Minerva 解决指标口径不一致的问题

随着这些痛点不断加剧，公司启动了一项为期多年的数据仓库改造计划，目标是大幅提升整体数据质量。

作为第一步，数据工程团队从零开始重建了几个关键业务数据模型，最终产出了一系列经过认证、精简且规范化的数据表。这些表避免了不必要的连接，并成为新分析仓库的基础。

但这还远远不够。

为了将这些表转化为洞察，我们还需要一种能力：能够以编程方式将它们连接起来，创建便于分析的数据集。我们需要在业务逻辑变化时自动回填历史数据。最后，我们还需要确保数据在不同查看工具中，能够以一致且正确的方式呈现。

这正是 Minerva 诞生的背景。

Minerva 是公司的指标平台。它以事实表和维度表作为输入，执行数据反规范化，并将聚合数据提供给下游应用。Minerva API 弥合了上游数据和下游消费之间的鸿沟，使数据工程团队能够灵活修改核心表，同时持续支持各类下游用户。这个 API 在下一代数据仓库架构中发挥着至关重要的作用。

在类似的数据平台建设中，指标统一并不只是技术问题，还涉及目标设定、需求清理、评审排期、开发测试、发布上线和知识沉淀等完整研发流程。企业可以借助 PingCode 这类智能化研发管理工具，将研发过程中的目标、需求、项目、测试、发布、Wiki 与生态工具连接起来，让指标平台建设中的数据、流程和经验更顺畅地流转；如果团队更关注跨部门任务协作、文档、日历、甘特图、工时和审批等通用协同场景，也可以结合 Worktile 这类项目协作系统提升推进效率。

图片说明：Minerva 是公司的指标平台，在新的数据仓库架构中处于核心位置。

截至目前，Minerva 已经包含超过 12,000 个指标和 4,000 个维度，拥有 200 多名数据生产者。这些生产者分布在不同职能部门，例如数据、产品管理、财务和工程，也分布在核心产品、信任、安全、支付等不同业务团队。如今，大多数团队都将 Minerva 视为公司进行分析、报告和实验的首选框架。

图片说明：过去两年，公司对 Minerva 的使用显著增长。

Minerva 指标平台中的数据生成

从基础设施角度来看，Minerva 构建在多个开源项目之上。它使用 Airflow 进行工作流编排，使用 Hive 和 Spark 作为计算引擎，并通过 Presto 和 Druid 支持数据消费。从指标创建、计算、服务、消费到最终弃用，Minerva 覆盖了指标的完整生命周期。

图片说明：Minerva 管理着公司内部指标的完整生命周期。

指标定义

Minerva 在一个集中的代码仓库中定义关键业务指标、维度和其他元数据。公司内部任何人都可以查看和更新这些定义。

经过验证的工作流

Minerva 的开发流程强制执行数据工程最佳实践，例如代码审查、静态校验和测试运行。

DAG 编排

Minerva 通过最大化数据复用和中间连接结果复用，高效执行数据反规范化。

计算运行时

Minerva 具备复杂的计算流程，能够在作业失败后自动自我修复，并内置检查机制以确保数据质量。

指标与元数据服务

Minerva 提供统一的数据 API，可以按需提供聚合指标和原始指标。

灵活回填

Minerva 对数据定义进行版本控制。因此，当数据集发生重大变更时，系统可以自动追踪并回填历史数据。

数据治理

Minerva 内置成本归因、选择性数据删除、数据访问控制和自动弃用策略等能力。

数据保留

Minerva 建立了基于使用情况的数据保留和垃圾回收机制。成本高但使用频率低的数据集，会被自动删除。

这些能力使我们能够规范指标创建、数据计算和数据交付流程。在下一篇文章中，我们会进一步深入这些功能，并进行更详细的解释。

Minerva 指标平台中的数据消费

Minerva 的产品愿景是：一次定义指标，处处可用。

换句话说，在 Minerva 中创建的指标，应该可以轻松用于公司内部仪表盘工具、A/B 测试框架、异常检测算法、数据分析客户端，以及高管报告等各种场景。过去几年里，我们与其他团队紧密合作，围绕 Minerva 构建了一个完整的数据工具生态。

图片说明：Minerva 的愿景是“一次定义，处处使用”。

数据目录：让指标更容易被发现

首先，我们与分析产品团队紧密合作，将所有 Minerva 指标和维度索引到内部数据门户 Dataportal 中。

当用户访问数据门户并搜索指标时，Minerva 指标会优先显示在搜索结果顶部。数据门户还会展示相关上下文信息，例如认证状态、负责人和受欢迎程度，帮助用户评估指标的重要性和可信度。对于大多数非技术用户而言，数据门户是访问 Minerva 指标的首选入口。

图片说明：Minerva 指标会在数据门户中被索引和编目。

数据探索：基于统一指标发现洞察

选择指标后，用户会被重定向到指标探索器 Metric Explorer。它是数据门户的一个组件，提供开箱即用的数据探索能力。

在指标页面上，用户可以查看指标趋势，并使用“分组依据”和“筛选”等功能进行切片和下钻。如果想进一步分析，用户还可以跳转到更高级的可视化分析视图。

在整个过程中，指标探索器会展示指标负责人、历史发布时间、指标描述等元数据，帮助用户理解数据上下文。这种设计兼顾了技术用户和非技术用户的需求，使他们能够更轻松地发现数据洞察。

图片说明：用户可以在指标探索器和更高级的分析工具之间无缝切换，用于调查趋势和异常。

A/B 测试：让实验和分析使用同一数据源

公司的实验报告框架一直拥有一个名为“指标库”的实验指标存储库。实验人员可以将任意业务指标添加到实验中，并比较对照组和实验组的结果。

然而，这个指标库无法用于实验以外的其他用途。因此，我们决定将 Minerva 与实验报告框架集成，使所有 A/B 测试的基础事件都由 Minerva 定义并提供数据。

在实验和分析中使用同一个数据源，意味着数据科学家可以更有信心地理解某个实验将如何影响关键业务指标。

高管报告：用统一指标支撑经营决策

自公司上市以来，我们一直延续着每周、每月和每季度审查业务表现的惯例。在这些会议上，不同职能部门的负责人会聚在一起，讨论公司当前的经营状况。

这类会议需要简洁、清晰、站在高层视角的高管报告。报告通常会汇总数据，分析并绘制趋势图，并以滚动汇总，例如年初至今，以及时间比率比较，例如同比等方式，呈现各项指标变化。

图片说明：下面是基于 Minerva 构建的新冠疫情仪表盘报告配置示例。

为了实现这类报告，我们构建了一个执行报告框架。该框架会获取用户指定的 Minerva 指标和维度列表，并将它们转换为适合报告生成的聚合指标时间序列。

这一框架自动化了大量手动工作，并允许我们使用与分析和实验相同的 Minerva 指标与维度，实现高保真、业务关键型报告的标准化。

数据分析：在 Notebook 中复用统一指标

最后，Minerva 数据通过 API 向公司内部定制的 R 和 Python 客户端开放。这使得数据科学家能够在 notebook 环境中轻松查询 Minerva 数据。

重要的是，notebook 环境中呈现的数据，与前面提到的工具中的数据计算和呈现方式完全一致。这为数据科学家节省了大量时间，因为他们可以根据分析复杂度选择合适的工具，而不必担心不同工具之间的数据口径不一致。

值得一提的是，这个数据 API 也鼓励大家对内部工具进行轻量级原型设计。这些原型随后可以投入生产，并在公司内部共享。例如，过去两年里，数据科学家已经利用该 API 构建了一个时间序列分析工具和一个邮件报告框架。

图片说明：数据科学家可以使用 Python 客户端从 Minerva 中检索聚合数据并进行分析。

Minerva 如何帮助团队应对新冠疫情危机

随着 Minerva 成为公司数据分析的核心工具，我们一次又一次见证了它为数据团队带来的强大能力和生产力提升。在最后一部分，我们将通过一个具体案例，说明 Minerva 如何在新冠疫情危机期间帮助公司应对挑战。

2020 年 3 月，新冠疫情导致全球旅行几乎停滞。一夜之间，平台预订量暴跌，取消量激增。对我们来说，这是一个令人担忧的时刻，也引发了许多重要业务问题：

新冠疫情如何影响我们的预订积压？如何影响入住率？取消量上升会带来哪些财务影响？疫情如何改变人们的旅行需求，尤其是旅行距离？我们需要迅速而准确地回答所有这些问题。

图片说明：借助 Minerva，我们大幅缩短了从数据整理到洞察发现的时间，并得以评估新冠疫情对业务的影响。

为了应对大量涌入的问题，数据科学团队收集了这些问题，并开始集思广益，探讨如何用数据解答它们。

关键在于，许多重要业务指标和维度，包括供应、需求、财务和客户支持相关指标，都已经在 Minerva 中定义。因此，中央分析团队能够在短短几天内完成高管仪表盘的线框图设计，并发布初始版本。

新冠疫情仪表盘迅速成为唯一可信的信息来源，并在危机期间受到高管团队的密切关注。自发布以来，该仪表盘累计获得超过 11,000 次浏览和 1,500 位独立访问者。不出所料，它也是当年公司内部可视化分析系统中浏览量最高的仪表盘。

借助 Minerva 指标生成的洞察，公司得以更有信心地把握瞬息万变的市场环境。例如，我们发现需求正在转向本地旅行和长期住宿。这些发现促使团队重新设计产品页面上的若干重要触点，以适应用户偏好的变化。

在危机时刻，快速回答问题并挖掘洞察的能力，比以往任何时候都更加重要。得益于 Minerva 这一单一可信数据源，我们能够高效做到这一点。

结语：指标一致性是数据驱动决策的基础

在这篇文章中，我们简要回顾了某海外住宿平台的数据分析发展历程，总结了过去几年中遇到的挑战，并说明了为什么要构建指标基础设施 Minerva。

我们重点介绍了 Minerva 如何生成和消费数据。文章最后，我们还分享了一个具体案例，说明 Minerva 如何帮助公司应对新冠疫情危机。

在下一篇文章中，我们将深入探讨 Minerva 的技术架构，包括设计原则、用户开发流程以及数据计算图。在本系列最后一篇文章中，我们将介绍 Minerva API。它是我们的唯一数据抽象层，也是上述所有集成得以实现的关键。

最后，我们也会分享构建 Minerva 过程中获得的经验教训，希望这些经验能够对正在构建类似系统的开发者有所帮助。

在此之前，敬请期待下一篇文章。