导读腾讯欧拉平台是腾讯 PCG（平台与内容事业群）推出的数据治理平台化解决方案，目前已在腾讯内部广泛使用。腾讯欧拉 t-Metric 指标中台基于 DataOps 理念，结合 Headless BI 实践，提供一站式指标建、管、查、用能力，以提升指标生产和治理水平，沉淀企业安全可靠、使用便捷、质量可信的数据资产。t-Metric 指标中台主要为用户提供配置驱动的指标生产方式、统一查询服务、以及完善的指标生态等核心能力。

本次分享题目为腾讯欧拉 t-Metric 指标中台 Headless BI 实践，具体内容将围绕以下几大部分展开：

1. 欧拉平台建设思路和目标

2. t-Metric与Headless BI

3. 配置驱动指标生产

4. 统一指标查询服务

5. t-Metric指标生态

6. 问答环节

分享嘉宾｜陈建峰 腾讯 大数据研发高级工程师

编辑整理｜阿东同学

内容校对｜李瑶

出品社区｜DataFun

首先做个简单的自我介绍，我叫陈建峰，毕业于2015年。过去八年我一直致力于数据研发以及大数据平台建设相关的工作，在数据采集、传输、存储、计算全链路的平台化建设方面，拥有较丰富的经验。目前，我就职于 PCG 大数据平台部，主要负责指标中台的构建。

01欧拉平台（OLA）建设思路和目标

首先来介绍一下欧拉是什么。欧拉是腾讯 PCG 大数据平台部的企业级数据资产平台，我们的价值主张是聚焦可信数据资产沉淀与交付，提升数据价值及应用效率。欧拉在数据接入治理工具 datamesh，作业调度平台 us，数据仓库 tdw，一站式机器学习平台 venus 之上构建了全链路数据血缘图谱，为我们的用户提供数据发现、资产工场、指标中台、治理引擎四大核心能力，其中 t-Metric 指标中台就是我今天分享的主题。

02t-Metric 与 Headless BI

1．指标中台

我们为什么要做指标中台？或者说指标中台是为了解决什么问题？我们知道现有的架构通常是这种前后端分离的模式，后端就是我们生产、存储数据的地方，像数据仓库 Hive、关系型数据库 MySQL 以及 ClickHouse、StarRocks 这些 OLAP 引擎，前端就是我们消费数据的地方，典型的例如各种BI工具、实验平台、机器学习平台等等。

这种架构的特点是，对于同一个指标，我们无法跨平台复用，指标的度量公式是分散在不同平台的，它隐藏在各个仪表板中。这些指标在没有被监督或指导的情况下重复定义了多次。重复意味着难以维护、意味着发散式的修改，自然会带来同名不同义、同义不同名的情况。此外，数据开发具有一定的技术门槛，需要专业人员参与，分析人员无法做到自助生产，从提出需求到上线指标，时间周期较长。最后指标字典通常是开发人员人工维护在各种文档、wiki 中，很容易出现遗漏的情况，用指标的人也没有有效的检索方式快速找到自己想要的指标。

2．Headless BI

既然问题的根源是重复，那么如何消除重复呢？这里就要介绍一个关键词------Headless BI。我们知道有几个重要的软件设计原则：DRY (Don't Repeat Yourself)、封装、抽象，Headless BI 就是借助软件设计的思想，在指标的生产者和消费者之间引入指标库 Metric-Store 以一种标准化方式来集中定义和管理指标，为指标使用方提供统一的查询服务，以此来消除指标重复定义的现象，收敛指标出口。此外 Headless BI 系统通常还具备物化加速、指标目录等功能。

3．建设思路

在把 Headless BI 理念落地前，我们还有一些现实问题需要考虑。可能任何一个中台都得思考如何兼顾存量和增量。对于我们来讲，让业务在指标中台上重新生产存量指标是不切实际的。因此对于存量指标，用户可以把已经生产好的 ADS 表、ClickHouse 的宽表注册到平台，基于这些表登记指标的计算口径，补全维度、业务主题等必要的信息，由指标中台提供统一的检索能力及查询服务来统一指标的出口，确保一致性。

针对新增指标，我们提供一套自底向上的标准化解决方案，涵盖指标定义、物化加速、指标检索、查询等能力。最后也是非常关键的一点是指标生态的建设，我们不能把指标中台变成指标孤岛，需要和 BG 内其他平台无缝衔接，方便用户能够在这些平台上快速应用。

4．核心能力

最终，我们基于 Headless BI 的理念打造了一套核心能力，涵盖指标的建、管、查、用四方面。

• 建，就是生产指标。支持用户基于单表或多表模型以一种规范化、标准化的配置驱动方式生产指标，以达到生产即治理的目的。我们还提供一些低代码的能力，方便用户不写或少写 SQL 即可生成物化任务。
• 管，就是管理指标。包括指标权限的管理，指标上下线、认证、审批等。如果指标有变更，我们会以消息通知的形式触达使用这些指标的用户。
• 查，就是发现指标。上线的指标即可被检索，我们提供基于关键词、维度、表、指标等级、业务主题等多种检索方式高效查找想要的指标。
• 用，就是使用指标。我们向使用方提供一套统一的 API，与整个 PCG 生态更好的打通。

5．t-Metric 架构

下图展示了 t-Metric 的完整架构，底层是各种存储和 OLAP 引擎，其上我们构建了语义层旨在统一定义和管理指标；物化层提供物化加速、历史数据追溯和 SLA 保障；查询层为用户提供统一 API 以打通指标生态。

03配置驱动指标生产

指标中台，要为指标的生产者和消费者服务。我们为生产者提供了一套配置驱动的生产方式来生产指标。

我们如何表达一个指标呢，通常一个指标包含度量（原子指标）、维度、业务限定、统计周期四个部分，比如说最近7天各省市区体育类视频总播放时长这样一个指标，我们把它转换成 SQL，度量就是我们用什么样的聚合方式进行计算；维度对应的就是 group by 的部分；业务限定对应的是 where 条件；统计周期就是这个指标要以什么样的时间窗口，以什么样的粒度去做统计。语义层的作用就是把表和列映射到有意义的业务实体，用户可以用业务友好的语言定义指标。

目前，我们支持 BG 内常用的四种存储引擎，包括 Hive、MySQL、ClickHouse 和StarRocks。维度建模是数仓开发过程中一个普遍需求。我们提供了可视化建模的能力，用户可以通过拖拽、点选等方式选择表和字段，配置多个表之间的关联关系，得到一个逻辑大宽表。当然，我们会对模型进行去重校验，以避免用户重复构建。

有了数据表和数据模型之后，接下来就可以定义指标了。对于简单的逻辑，可以在界面上选择字段、聚合函数和运算符以完成指标定义。对于比较复杂的计算逻辑，可以填写 SQL 片段，我们会进行语法校验，确保保存后能够正常使用。

所有指标的中英文名称会按照 PCG 规范自动生成并做重复性校验。同时我们也会校验口径是否冲突，例如 avg(price)既被当做"平均金额"又被当做"总金额"，这是不被允许的。配置驱动能够达到生产即治理的目的，从根源上杜绝同名不同义、同义不同名的情况的出现。

一旦指标被配置并上线，就可以在数据发现门户中找到它们。用户可以通过关键词、类型、等级、业务主题等快速查找指标并进入相应的详情页查看基本定义信息和取数 SQL。我们还提供了指标认证能力，用户可通过在线认证流程，提升指标的可信度和权威性，认证信息也会在详情页显示。如果用户需要使用指标，则可在详情页发起申请。

到目前为止，已定义的指标仅仅是个逻辑概念，为了提升查询性能，还需要进一步物化加速。我们支持在四种存储引擎之上定义指标，根据用户的应用场景和引擎特点提供不同的物化加速方案。对于定义在 MySQL 表上的指标，通常用户挂载了一张ADS结果表，并且数据量不会太大，可以直接查询原始表，只在查询服务做结果缓存。

对于定义在 Hive 上的指标，根据应用场景会有不同的区分。如果是报表场景，通常具有明确的维度组合且需要稳定的产出时间。我们提供了基于指标集的物化加速方案，用户可以选择关心的指标和维度组成指标集，我们会自动解析任务依赖，生成物化任务并定时调度，将预计算后的结果存储到 MySQL、StarRocks 等引擎。查询时直接路由到加速好的结果。对于归因等需要灵活的上卷下钻的多维分析场景，我们会把底表导出到 ClickHouse，利用 ClickHouse 的 OLAP 能力快速响应用户的分析需求。如果仅需要快速预览或探索，这种场景是允许快速失败的，我们直接通过 Presto、Impala 或 MixQuery 等引擎查询底表。如果指标是定义在 ClickHouse、StarRocks 等 OLAP 引擎，我们也提供按需创建指标集的能力，自动帮助用户创建物化视图，并转换成对物化视图的查询。下图是创建指标集的交互页面，左侧会列出所有的指标和维度信息。用户选择完指标后，对应的维度信息会自动展开。如果选择多个指标，交集的维度会出现在下方，方便进行点选操作。选完维度后，用户可以选择所有维度组合得到一个 Cube，也可以对 Cube 进行裁剪避免维度爆炸。

代码是如何生成的呢？首先，我们会将指标集中的指标按照它们所属的模型和表进行分组。然后再依次处理每个维度组合，对于单个模型，根据字段和关联关系拼接得到逻辑宽表。当然，在指标计算时可能只用了宽表中的某些字段，我们会对无用字段进行裁剪，并进行一些谓词上提和下推的改从而使出自同一个表（模型）的指标可以放到一个 select 语句中。最后，将同一模型中的不同维度组合，以 union all 的形式拼接起来，从而生成整个指标集的物化代码。

物化任务的 SLA 如何保障呢？这就要提及我们的基线预警能力。举个例子，如果用户希望每天早上8点生成某个报表，传统的及时性监控只会关注任务本身是否在8点完成，也就是数据"有没有"按时产出。如果产出失败，用户收到告警可能已经来不及处理了。而基线预警关注的是数据"会不会"在未来的某个时间产出。除了关注报表任务本身，基线预警还会关注目标任务依赖的上游任务，根据这些任务的历史平均运行时长，找到耗时最长的一条关键路径，对关键路径上的任务实施监控，一旦发现某些任务在预期时间无法完成，就会提前告警。这样用户就可以尽早介入处理，保证报表能够按时产出。

图中的甘特图展现了整个关键路径上任务的运行情况，下方则是我们关注的目标任务历史运行产出情况。

04统一指标查询服务

在解决了指标生产问题之后，再来看如何服务指标消费者。我们为用户提供了两种形式的 API：Restful 风格的 API 和类 SQL 的 MQL 查询语言。

查询服务收到用户请求后，会先进行一系列的语法、词法校验，检查所需的指标和维度是否真实存在，生成 AST 抽象语法树。我们的查询路由机制会在不同的指标集和存储引擎中自动选择成本最小的结果集。执行器将拆解后的执行计划直接转换为 SQL 方言获取查询结果。如果用户需要二次计算，则对结果做二次聚合后并返回。当然，我们还会对查询结果做一二级缓存。一级缓存是针对请求体粒度的结果缓存，例如我现在要获取7月3日到7月10日广东省某个体育类视频的播放量，当查询完成后，整个查询结果将被缓存下来，如果下次查询完全相同，则可以命中一级缓存快速返回。同时，我们还会按指标、维度和时间将查询结果拆分成更细粒度的二级缓存。如果下次要获取1到10号的结果，其中一部分已经在缓存中，我们只需要查询未命中的部分并将结果合并后返回即可。

我们使用 RESTful 风格的 API，所有查询都面向指标，而不是表和字段。用户只需告诉我们要查询的指标名称，关注的维度和时间范围，无需编写冗长的 SQL。

另外一种选择是基于 Antlr4 自定义的查询语法。我们称其为指标查询语言 MQL。它的语法非常接近 SQL，几乎无学习成本。SQL 查询是面向表和字段的，用户需要知道指标如何通过表和字段计算，是过程性的；而 MQL 面向的是指标，用户不用关心数据存在哪儿，也不用关心是怎么算的。MQL 还支持丰富的聚合函数，例如最大值、最小值、同环比计算、某个维度下的占比等。若要获取6月1日的 DAU 以及其日环比和周同比，只需写一段简单的代码：从某个指标集中选择 DAU 指标及其日环比和周同比。指标集可省略，因为会自动路由。

05t-Metric 指标生态

t-Metric 已经和 PCG 的多个平台打通，包括可视化报表平台 DataTalk、智能决策平台、天眼归因分析平台、实验平台等，方便用户在这些平台上快速应用指标。下面选取其中一部分做简单介绍。用户在指标中台申请权限后，所有有权限的指标都会自动出现在 DataTalk。配置报表时，用户只需拖拽需要的指标和维度，无需编写任何 SQL。

此外，我们融合了 PCG 天眼平台的指标异动归因能力。如下图，右上角会给出对比周期和当前周期的波动情况总结，列出对指标增长影响最大的 n 个维度和下跌影响最大的 n 个维度。单维分析对所有维度按贡献度从大到小排名。选中某个维度后，该维度下各枚举值的波动明细会自动列出，用户可以从贡献度、波动量、波动率三个视角查看。多维分析可以按不同维度分组，方便用户上卷、下钻，逐级拆解后观察不同维度组合下的波动情况。

这是指标应用血缘相关的内容，指标详情页展示应用信息，应用列表中会列出该指标在下游的使用情况，并提供跳转链接，用户点击链接后即可进入相应平台查看数据。

以 ChatGPT 为代表的大型模型正在各行各业掀起一股热潮。在这样的形势下，欧拉也在积极探索和实践如何利用大模型来提升用户找数据、理解数据、使用数据的效率。

我们希望未来用户可以通过交互式对话的方式轻松获取所需的指标和数据。一旦大型机器人收到用户 query 后，可以理解用户的意图，并返回准确的指标结果、SQL 语句、看板或分析报告。在这种背景下，指标库的建设变得更加重要，因为只有提供高质量的指标元数据和查询服务，才能实现这个愿景。

06问答环节

Q：关于欧拉平台中的衍生指标，有三个疑问：首先，它是否支持实时分析，即能否立即分析我正在采集的定义的衍生指标，它的性能是否足够高效？其次，如何保证这个衍生指标是有价值的或有效的？例如，如果我定义的衍生指标由5个基础指标组成，而其中一个基础指标的系统出现了异常，那么这个衍生指标会受到影响吗？第三个问题是，对于业务人员，欧拉平台有什么价值？他们是否可以受益于衍生指标？例如他们可以通过观察指标的突增或突降来判断相关的业务状况，或者欧拉平台是否提供了相应的算法功能，以提示周期对比并展示过去一周或近7天的指标情况，从而为业务人员提供相应的辅助功能。谢谢。

A：第一个问题，能否做实时的分析，取决于用户所使用的存储引擎。如果指标已经定义在 MySQL、ClickHouse 或者 StarHouse 这些宽表上，那么是可以直接查询的。但如果指标定义在 Hive 上，就需要物化加速。我们的物化加速方案是基于指标集的，用户在配置完指标集之后，我们会根据指标自身的统计周期定时调度。这样用户在第二天或者某个时间点就可以得到结果了。如果做了物化加速，查询效率就会非常高。通常 P95 只需要一两秒。

第二个问题是关于衍生（复合）指标血缘的识别。如果一个衍生指标是由前面的五个指标组成的，我应该如何确定这个指标是自身存在的问题，还是源自前面指标的问题？如何监测这些问题，并保证 SLA？这个问题涉及到我们先前提到的基线预警能力。基线预警会识别目标任务的关键路径，如果上游任务出现故障，我们的系统也会提前告警，确保目标任务在规定时间内产出。

第三个问题，业务同学通过指标的突增突降判断业务状况与我们提到的指标归因相关。我们会自动分析这个指标波动的原因，用户可以在指标的归因页面中查看增长贡献最高的几个维度和下降贡献最高的几个维度。也可以进入单个维度，查看该维度单个枚举值的波动明细，以及按照不同维度做上卷下钻，逐级拆解波动原因，从而辅助业务同学快速找到指标异动的原因。这正是我们平台为业务带来的价值。

Q:这个平台最多支持的维度的个数是多少？如何解决指标爆炸的问题？这个平台如何感知和处理指标异常？由于这个平台采用拖拽式的开发，而不是传统的方式，因此感知和处理异常指标的方法也有所不同。但是这个平台需要处理一个信任度问题，因此必须感知大家对其产出指标的信任度。

A：维度个数主要取决于所选择的引擎，因为每个引擎的特点是不一样的。有些存量指标是直接定义在用户生产好的 ADS 表上，这种指标通常存储在 MySQL 中，且维度数量不会太多。但对于 ClickHouse 这样的宽表引擎来说，用户的宽表有多少字段和维度，我们的指标就支持多少维度。关于维度爆炸的问题，如果一个定义在 hive 中的指标需要经过物化加速，那么维度太多确实会存在维度爆炸的情况，前面提到我们的物化加速是基于指标集的，用户可以只选择自己关心的维度组合进行物化，也就是对 cube 做提前裁剪。

确实由于平台配置化的特点，所有人都可以轻松操作。比如产品或者分析人员可以自行添加指标并上线。我们会对指标名称进行冲突检测，避免创建过多的重复指标。另外，也会检测口径冲突。例如，不能将用于计算平均值的指标与用于计算总和的指标视为同一个指标。我们会在这方面加以检查。

第三个问题是关于指标被别人信任的问题。我们有一个认证的机制，每个业务的认证流程都是独立的。例如，某些团队的一个指标需要由数据工程团队、数据分析团队、数据科学委员会的相关人员认证。经过认证的指标可以确保它的口径是正确的，我们会在指标详情页透出认证标记表示这个指标是有官方背书的，是具有一定权威性的。

Q：欧拉的 t-Metric 是腾讯的，是部门内部在用还是整个腾讯公司在用？还是后面有开放出来的计划？另外，我们知道维度建模里面，细粒度的事实表和维度建设的比较好，是回答企业里面各种数据分析问题的一个基础。如果他回答不了的话，我们上层的指标体系也回答不了，分享中提到有一个后续的规划，是用 ChatGPT 这种机器人去做这个事情，用户可以跟他聊天的方式让他去写这个 SQL 直接获取数据。我原来建了很多的指标体系，是为了方便用户去使用。既然用户可以用自然语言的方式直接去获取数据了，那我这个指标体系是不是还需要或者那个 Metric Store 还需要建的这么完善吗？

A: 我们一开始在 BG 内推广使用指标中台来管理腾讯新闻、腾讯视频等核心业务的指标。目前，有一些 BG 外的业务也在使用，但未来计划将其推广至全公司。

第二个问题，首先欧拉的资产工场里面有很多用户建好的数仓表，大模型会理解这些表的字段和含义，当用户查找指标时，它可以自动地帮用户生成一个取数的 SQL。其次即使用户可以通过语言获取指标，我觉得指标库的建设还是非常有必要的，如果不能提供非常高质量的元数据跟查询服务给到大模型，那么它可能就变成 garbage in， garbage out 了，元数据本身的质量决定了最终效果的天花板。

假设我们把底层的数仓表字段的描述都标注很好了，但是你问他说，某业务的 DAU 是多少？他可能给你写出一个 SQL，但你能信任他吗？你肯定很担心对不对？但是有了指标库才能让这个精确性得到提升。

Q：指标有一个路由的机制，所以说明它下游一个指标可能是对了很多表，那么如何保证这个指标在多个表里边的一致性的？

A：如果用户的一个指标可以从多个表出，那么如何检测指标之间的冲突呢，一方面，我们可以通过具体某一维度下的枚举值对应的指标结果来进行比较，从而判断它们的结果是否一致，这是基于结果的检测；另一方面，我们可以通过解析指标的字段血缘，从指标出发往上追溯上游的来源表和字段，判断它们是否从同一个源头产生。这样就可以保证其数据口径的一致性。

Q：关于指标异动分析，分享中提到会自动下钻去寻找相应的维度，但考虑到业务可能涉及多个维度，这个过程是否需要进行配置？另外，该分析可以选择最高或最低的几种指标，这和归因模型有关，那么欧拉平台用的是哪一种归因模型呢？

A: 用户在使用归因分析前需要进行配置，提供他关注的核心维度，我们只会对这些特定的维度做自动拆解。多种归因模型结合，单维、多维、比值类型的指标所采用的方法不太一样。

今天的分享就到这里，谢谢大家。