给 BI 砍头？聊聊指标平台的崛起
作者 / Joanna
“ 我最开始听说的指标平台是来自国内很多大型互联网公司，比如滴滴，贝壳找房，有赞等，都有很不错的指标平台建设实践。这让我一直以为指标平台是一个国内特有的比较火热的概念。而最近对北美市场进行调研后，我惊喜地发现原来指标平台的概念不止是国内才有，下面就和大家分享一下我了解的海外指标平台的建设情况。”
01.现状分析
现有 BI 方案的痛点
在目前的数据平台方案中，指标通常是被定义在 BI 层或数据仓库层中的，这样的方式引发了以下的几个问题：
- 数据架构复杂度高，数据分析效率低下
- 用 SQL 定义指标太复杂，门槛太高
- 指标只能 BI 工具中使用，无法对接更多业务系统
- 指标定义口径不一致，无法支撑业务决策
1. 数据架构复杂度高，数据分析效率低下
将指标物化在数据仓库层是目前来说常用的一个解法，数据仓库支持将指标定义在视图（View）中，然后让其他工具去查询视图。
我接触的不少企业目前就是在使用视图来解决分析最后一公里的查询问题。使用视图的问题是仅能针对一些查询需求进行物化，在各类查询需求繁多的时候，数据工程团队需要准备大量的视图，开发成本极高，数据管道复杂不说，还很容易出错。
当上游的数据出现问题的时候，下游系统很难知道，就无法及时同步修复，这会导致数据的消费者如数据科学家，工程师需要花费大量时间来 debug 数据不一致问题，这使得他们的工作效率非常低下。
上图为引入指标平台之前的 Airbnb 数据平台：建立在核心数据之上的衍生表大量激增，带来了一系列问题
2. 用 SQL 定义指标太复杂，门槛太高
数据分析系统有些分析常用指标，比如用户 session 数，漏斗分析用户转化率。
如果用 SQL 来定义这些业务分析指标的话，企业通常需要依赖专业的数据工程师，来撰写上千行的 SQL 才能够完整定义出来。
3. 指标只能 BI 工具中使用，无法对接更多业务系统
而且就算能用 SQL 定义出这些指标，业务人员使用指标的场景是非常广泛的，不是简单的 BI 分析就可以满足的。
比如当某用户在使用某公司产品快要达到容量限制的时候，销售人员希望接收到容量使用率指标的告警通知，从而及时联系用户；比如为了降低用户流失，运营人员希望及时获取近30天未活跃用户，采取激活策略，如给用户一个免费续用。
仅在 BI 中定义、分析指标是不能够满足这些需求场景的，这些场景会涉及对接下游的 CRM 系统，订单系统等。
我之前也提到过主流 BI 厂商如 Tableau，Power BI 等都有自己的语义层概念，你可以在其生态中定义常见的层级结构，计算指标等。
Tableau 的语义层和其他方案相比会更专注于其软件生态中的复用，当在企业内有其他 BI 平台存在时（不同部门拥有不同 BI 平台是很多大企业的常态），这个语义层能力很难在更大范围内复用。
Power BI 虽然提供了 XMLA 终端支持语义层在更大范围复用，其考虑的场景还是通用 BI 分析场景的延伸，比如将 Power BI 的数据集同步给 Excel，Tableau 等来分析，而没有展现用指标层来支撑其他业务场景的能力。
4. 指标定义口径不一致，无法支撑业务决策
一个很简单的业务问题在不同团队那里会得到不同的汇报数字。更糟糕的是，没有人知道究竟哪个数字是对的。
02.理想中的指标层
Ankur Goyal 和 Alana Anderson 两位硅谷投资人在这篇博客中提出了 Headless BI 的概念
“Headless BI：指标只需定义一次，就可以统一地在仪表盘，以及自动化工具中使用”
他们认为理想中的指标层应该通过 Headless BI 的方式来实现，需要满足以下条件：
- 无需写 SQL 就能够轻松定义指标
- 指标可以被灵活的用在 BI 可视化，下游应用系统，并通过 API 消费
- 指标支持大规模查询，从而支持大量的自动化流程，比如触发邮件通知，支撑交互式产品体验等
于是在可视化和自动化流程中间就出现了一个空缺的市场机会，需要由 Headlesss BI 来填补。
Headless BI 倡导的理念是“指标一次定义，就可以支持 BI 工具或在其他应用简单有效的使用指标”，在大型组织中，通常存在多种 BI 工具，各类需要供数的下游系统，统一的指标定义，多工具复用就是一个共性的需求。
在现在的解决方案中，指标层和使用消费它的 BI 系统的紧耦合，限制了指标数据在更多应用场景发挥价值。
如果能够将指标层和 BI 解耦开，打造出 Single Source of Truth 的指标层，那么各类下游系统数据消费的时候，就可以达到真正的口径统一。
如下图所示，不同系统都能拿到统一一致的 Revenue 指标。
个人用大白话诠释下对 Headless BI 的理解：Headless BI 要实现的是砍掉 BI 的“头”（报表可视化），只保留指标层，通过提供各类消费接口，满足企业内丰富的消费场景；在现在普遍观点中，BI 总是和报表/可视化画上等号，而 Headless BI 将对 BI 的主流认知带来又一次革新，颠覆现在 BI 的使用方式。
Headless BI 方案给企业带来的价值也很多：随着分析决策的完成，BI 报表可能会结束其生命周期，而一个可以对接业务流程（产品、销售、市场、客户支持等业务流程）的指标层，可以将指标资产沉淀下来，多系统复用，企业对其依赖更强，粘性更高，因此这样的方案将更难被替代。
企业可以更灵活地对接各类系统、应用、下游前端技术，不会受到特定 BI 端、分析技术的限定。
为什么说做指标层很有必要的，我的理解是：指标体系建设后的成果是业务团队更容易感知到的价值；业务指标口径的不一致，业务指标结果不对，对业务是会产生直接的负面影响的，而实现了统一的指标层后的价值对业务来说也是更加显而易见的，这样就更容易获得业务决策人的认可从而推动指标平台的搭建。
03.北美的那些指标平台们
原来指标平台不是中国特有的概念，来看看北美的那些指标平台们
我在调研过程中发现，原来 Metric Layer(也叫 Metric Platform / Headlesss BI)这个概念正在北美市场萌芽，其中发展最为成熟的应该是 Airbnb 的指标平台 Minerva 了。
来自 Airbnb 的 Minerva
Minerva 会将维度表，度量表作为输入，进行数据反范式化（笔者注：应该是指将数据打平，聚合）并为下游应用系统提供聚合的数据。
Minerva 的 API 填补了上游数据和下游消费系统之间的空缺。数据工程团队可以灵活的修改核心表，同时维护对下游消费者的支持。
Minerva 的 API 在 Airbnb 的下一代数据仓库的建设中起到了至关重要的作用。
目前 Minerva 支持了 12000 多个指标和 4000 多个维度，各种职能（数据，产品管理，财务，工程）和团队（核心产品，信用，支付）有 200 多个数据生产者 。
在 Airbnb 大部分团队将 Minerva 认定为他们首选的分析，报表和实验的平台。
Minera 指标平台的理念
Minerva 的产品愿景是让用户能够 “define metrics once, use them everywhere” 即“定义一次指标，在所有地方使用。”
“Define metrics once, use them everywhere”
Minerva 的指标被用于下游的多种数据消费出口，比如可视化/仪表盘工具 Superset(笔者注：Apache Superset 是 Airbnb 开源的 BI 工具)，A/B 测试框架 ERF，异动算法用来检测业务异常点，数据分析和科学工具 R 和 Python。
从 Airbnb 出来创业的 Transform
介绍完 Airbnb 内部的指标平台 Minerva，再来看几家北美初创公司，专注在 metric store，metric layer 领域的。首先第一家是 Transform ，创始团队正是从 Airbnb 出来的。
Trasnform 的理念是：
- 创建公司级统一的关键指标，帮助企业通过统一的指标框架来助力业务扩张。
- 减少重复性工作，为每个人提供统一的空间来协同，注释数据图表和查看个性化的数据流。让数据团队可以围绕上下文来产生数据故事，减少重复性工作和时间花费。
- 提供一套能将指标和其他企业工具集成的 API ，帮助丰富数据，维度建模和提升灵活度。
目前 Transform 已获得来自 Index Vendture、Redpoint Venture、Fathom Capital 和 Work Life Ventures 2450 万美元的融资。
以开发者为中心的 Supergrain
Supergrain 是 2021 年刚刚成立的硅谷创业公司，创始人团队来自 Uber，Lyft 等知名硅谷公司，其意在打造以开发者为中心，API 优先的 headless BI ，来统一业务逻辑并为团队提供统一一致的指标体系，可供在任意时间，任意方式消费。
Supergrain 为开发、测试、发布指标定义提供了简化的工作流，为决策者提供了 single source of truth 的指标，在任意偏好的工具和可视化中进行查询消费。
Supergrain 提供了几方面的能力：
- 指标框架 ： 一个基于 YAML 的，灵活的指标定义语言，以及命令行界面（ CLI ）工作流来支持快速的指标开发。
- 指标门户 ： 一个为团队整理他们发布的指标，并管理集成工具的目录。
- 指标 API ： 一个开放的 API 即指标查询语言，让任何数据应用或工作流都可以来消费指标。
目前 Supergrain 获得来自投资方 Benchmark，Base Case Capital 及 Operator Collective 680 万美元的天使投资。
从开源项目到商业的 Cube.dev
Cube.dev 来自于一个开源的分析 API Cube.js。Cube.js 是一个开源的分析 API 平台，一个 Headless 的API 层，帮助生成指标的 API，可以对接现代的云数据仓库，如 Google BigQuery 或 Snowflake。
Cube.js 帮助开发者生成语义层，管理访问控制，缓存和聚合数据。Cube.js 可以对接多种前端库来制作自己的自定义 UI。
Cube.js 的 Data Schema 可以将原始数据源建模成为有特别业务含义的指标，并通过查询 API 将这些预聚合后的数据暴露出去。
根据 Cube.dev 的文档，用户可以通过类似 SQL 的命令来定义带有业务含义的信息，比如原始表中只包含 ID，是否支付，城市，公司名称等字段。
用户可以定义维度度量，比如定义维度“公司名称”，“城市”，定义度量“用户数量”，还可以为度量添加筛选条件，比如定义带有筛选条件的度量“已支付用户”用来回答问题“已经支付的用户数是多少？”
然后用户就可以通过多种下游的 API 来使用这些定义好的维度，度量了，比如前端工程师开发 UI 时可以通过 Rest API 对接，分析师可以直接使用 SQL API 来对接 Superset 等 BI 工具。
04.总结
通过了解这些北美的指标平台（也叫 Headless BI）我们可以看到海外指标层的一些共性的特点：
希望解决企业内数据口径不一致的问题，实现多端的数据消费复用。
在上面的一些截图和创始人对于产品的定位可以看出，北美的指标层主要面向的直接用户群体是数据开发人员，因此海外指标平台的指标定义部分多是使用SQL 或者简单代码来实现的。
而在调研过程中，我看到国内一些互联网公司的指标平台在指标定义部分会更多采用UI 界面的形式，方便业务分析师或者业务人员直接定义使用。
指标平台这个话题真的太大了，越挖越发现有很多内容可以展开，今天我就先分享到这里。