Meta Description： 本文介绍某海外住宿平台如何通过 Minerva 指标平台，在大规模数据分析、实验报告和高管决策场景中统一指标口径，实现指标一致性、数据可信和分析效率提升。
第一部分：Minerva 简介——一个面向大规模数据分析的指标平台
作者：某海外数据平台团队
发布时间：2021 年 5 月 1 日
图片说明：数据是用户声音在大规模场景下的体现。新冠疫情期间，我们通过数据看到，旅行需求已经明显转向本地化。
引言：为什么大规模业务需要指标一致性
在某海外住宿平台，数据是我们做关键决策的依据。我们靠随机对照实验来验证产品创意，同时持续、严谨地追踪业务表现，确保为用户和业务创造最大价值。要做到这些，必须搭建一套强大的数据平台，满足内部用户从采集、建模、分析到决策支持的端到端需求。
指标一致性，是任何数据驱动型组织的基础。要是不同团队对同一个业务问题给出不同答案，决策者就很难判断哪个数字靠谱。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 在下一代数据仓库架构中起着关键作用。
在类似的数据平台建设中，指标统一不只是技术问题，还涉及目标设定、需求清理、评审排期、开发测试、发布上线和知识沉淀等完整研发流程。企业可以借助智能化研发管理工具，把研发过程中的目标、需求、项目、测试、发布、Wiki 与生态工具连接起来，让指标平台建设中的数据、流程和经验更顺畅地流转；如果团队更关注跨部门任务协作、文档、日历、甘特图、工时和审批等通用协同场景，也可以结合项目协作系统提升推进效率。
图片说明：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 过程中获得的经验教训，希望这些经验能对正在搭建类似系统的开发者有所帮助。
在此之前，敬请期待下一篇文章。