美团 BI 在指标平台和分析引擎上的探索和实践

速读

在美团，我们构建了以指标平台为核心的新一代 BI 架构，通过自动语义和增强计算两种核心能力的建设，部分解决了传统 BI 平台在个性化数据集驱动下产生的数据口径混乱、查询性能差等问题。

自动语义能力实现了"定义即研发"。它将业务语言定义的指标自动解析为结构化的逻辑表达，并通过主外键关系将数仓模型自动关联成星型、雪花等模型，从而扩展出复杂指标。该能力贯穿了指标定义、模型关联、指标高亮与路由选表以及查询语义构建的全流程。我们利用自动语义能力，并结合指标仓库的预计算模式，不但使业务能够灵活扩展、查询、分析复杂指标，也满足了在有限时间内完成指标扩展、模型关联等复杂查询前置依赖计算的要求。

增强计算能力则旨在平衡运营监控（要求秒级响应）与灵活分析（处理海量数据）两种场景下的性能与成本挑战。它通过智能查询服务（支持多引擎模型、查询降级策略）和智能物化（自动构建宽表和汇总表）来提升查询稳定性和性能。此外，我们也对增量计算引擎进行探索，利用其存算分离、弹性伸缩、向量化执行等特性，进一步提升了查询性能和系统稳定性。

目前，该平台已支持公司百余业务线，查询量达百万级，查询成功率超过 99.9%，并在新引擎评测和灰度中验证了性能优势。未来，美团将继续在自动语义、增强计算深化演进，为数据分析智能化做好准备。

1 指标平台概述

1.1 指标平台和核心能力

近年，各种组织都在使用 BI/ABI（Busniness Intelligence/Analytics and Business Intelligence）平台，对数据进行建模、分析、可视化，支持有效决策和价值创造。随着技术的进步，BI 已由传统的以报表为核心的 ETL 驱动模式，变为了以数据集为核心的敏捷驱动模式。在后者，数据消费者（数据运营、数据产品、分析师等）可以通过 BI 平台中的无代码 ETL 工具或者 SQL 构建个性化的数据集，进行图表制作、自助分析，无需完全依赖数据研发进行开发和排期，具有一定的灵活性。但也带来了数据质量低（大量数据集导致口径不一致，数据混乱），查询效率低（非研发建立 SQL 数据集性能难以保障，抽取到各种分析引擎中又导致查询资源浪费），可复用性差（指标维度无法跨数据集分享，更难以在不同工具不同系统间使用）等问题。

为了解决上述问题，2021 年由 Airbnb/Minerva 等公司首先提出了指标平台这一概念。指标平台使用唯一的指标层来连接下层数据和上层应用，贯穿指标定义、管理、研发、应用全流程，来解决数据混乱问题。在强调数据治理的同时，也通过指标复用在一定程度上避免了资源浪费，理论上可以达到治理、成本、效率的平衡。近些年来，指标平台逐渐发展和完善，从最开始的仅仅进行指标口径治理的管理平台，过渡到了能够连接下游 BI 应用的管理、应用打通阶段。国内大型云计算供应商和传统 BI 产品厂商，均在分析套件中提供了指标平台产品，国外 Gartner ABI 分析报告在 2023 年将指标仓库（Metrics Store）列为了 BI 关键的 12 项能力之一，并在 2025 年将指标层（Metrics Layer）列为了 BI 常见能力的第一位。

指标平台的核心能力通常分为以下几点：

指标的定义和管理：指标定义描述了业务活动表现的量化标准，需要具有明确唯一、标准易懂、灵活扩展等特征。
逻辑拓扑和模型路由：指标平台可以将用户配置在指标定义中的业务语言进行结构化和逻辑化处理，转化为底层指标、维度、模型间的拓扑关系，自动建立业务语义和研发语义之间的桥梁。
语义查询和分析计算：语义查询允许基于 SQL 查询的方式表达部分指标的消费过程，分析计算负责根据语义查询的结果还原部分指标构建过程，并为跨源等场景的指标表达和统计分析需求提供解决方案。两者共同完成对全体指标的表义、计算、分析。
可视化分析和开放数据服务：指标平台通过集成类型丰富、使用便捷的可视化分析组件，为业务提供数据分析和报表搭建能力。同时也提供统一的接口服务，允许第三方应用通过 API 访问指标数据，体现了指标平台一处定义，多处运行的设计理念。

1.2 指标平台的挑战

指标平台已经在业界有一定规模的实践，但从其驱动特性和具体落地看，比较适合于规模中小，数据需求相对固定的业务模式。面对数据体量大，需求变化迅速的业务（例如互联网、零售、金融等），往往有以下要求和挑战：

（1）更丰富的指标定义能力和表述语义，例如，指标限定指标（e.g. "本月营业时长大于 50 小时的商家平均营业额"）、忽略维度（e.g. "商品类型收入占比"="收入/收入【忽略商品】"）、二次计算指标（e.g. "日均订单量"）、期初期末指标（e.g."月初入职人数"）、存留指标。

（2）灵活的分析和扩展能力：业务不仅需要查询指标数据，同时也提出大量的分析需求（同环比、时间窗口、占比合计等），这些分析需求在由数据集驱动的 BI 工具中，往往由业务自助对数据集进行扩展和丰富完成。但在指标平台中，由于强治理诉求（例如：同环比定义的一致性）以及指标数据的具体实现被系统屏蔽，这些分析方法需要由平台能力进行统一的实现和沉淀。此外，业务需要在指标平台之外，灵活的扩展已有指标维度，进行实验性质的分析和探索。

（3）自动化、快速响应的语义层：一方面，要求根据指标定义，从明细层生成原子指标，衍生、计算成上层复合指标，并支持上述的查询、分析、扩展语义。另一方面，面对万级别的模型，指标，维度，迅速构建实际查询 SQL，有限时间内（BI 工具一般要求秒级响应）完成指标维度拓扑，模型选择淘汰，查询、分析语义生成。

（4）计算性能挑战：在定义即研发的模式下，指标取数和分析会转化为面向数仓明细层的海量数据查询，对查询引擎算力要求更高。指标平台一处定义，多处运行的模式意味着对运营监控（Serving）和探索分析（Ad-hoc）场景的兼顾：一方面是传统的面向运营用户看数模式，指标维度数量大，组合和筛选条件相对固定，要求性能响应高于数据规模；另一方面是灵活的分析探查模式，指标维度组合灵活，分析方法不固定，筛选条件和时间周期分散，要求数据规模高于性能响应。这两种矛盾的性能需求模式，对底层计算能力提出了更高挑战。

2 美团 BI 在指标平台上的探索

美团指标平台是美团内部自建的元数据及模型管理平台，面向数据研发、数据产品团队，提供业务全域下数仓规划、指标维度统一管理、标准建模及指标自动生产的产品能力与方法论。美团 BI 平台是公司级一站式数据分析平台，面向数据产运营、研发、分析师、管理者等多种角色，支持多种数据源便捷查询，灵活进行数据可视化分析，快速搭建数据报表和数据监控，提供安全、高效、敏捷的数据分析服务。

在建设初期，技术团队也遇到了业界自助敏捷 BI 的共性难题：一方面业务创建了百万级别的数据集，造成了口径混乱、数据不一致等问题，对查询性能也难以保障；另外一方面，初版指标平台提供的指标维度丰富程度无法满足业务需求，且仅提供查询语义，不能在 BI 工具上进行高阶数据分析，也无法进行指标维度衍生和扩展。为了解决以上问题，技术团队进行了新一代 BI 平台的开发：新架构以建设指标平台并打通 BI 应用为主要思路，在解决数据消费侧传统问题的同时，也注重数据生产侧的效率提升。

新一代指标平台对数据仓库、自动语义、增强计算和分析工具等四个方面都进行了演进：

数据仓库：传统数据仓库需要完成明细层、汇总层和应用层的数仓开发，由于规范难落地、定制化需求和历史包袱等问题，数仓的烟囱化建设越来越严重，形成多个无法流通的数据孤岛，同时也导致库表数量快速上升，加剧存储资源浪费。在指标平台中，数仓研发的精力从承接业务需求转向夯实基础数据，提供标准的明细模型和统一的聚合模型，这些结构稳定、质量良好、可复用高的数仓模型为上层提供了完善且统一的基础指标维度。
自动语义：传统数据工具的指标管理更偏向于表面的口径描述和简单的审核流程管理。在美团指标平台中，元数据管理以自动语义为核心，涵盖了指标定义的配置和使用全流程，实现了指标定义即研发。在配置能力上，指标平台提供了命名规范、标准模板、口径治理、变更校验、智能推荐等功能，保障了指标口径的标准和统一。在使用能力上，指标平台将业务语言解析为结构化和逻辑化的表达，通过多表自动关联成星型模型、雪花模型和星座模型，并结合指标血缘最终扩展出复杂指标。在指标消费场景，通过全局路由和数据集分别表征全局的统一口径和细分场景的特定口径，满足不同阶段不同场景下的数据治理和数据使用诉求。在查询服务上，分析计算服务可以依据指标定义和模型关联，根据实际业务需要灵活选取构建的逻辑宽表，通过执行计划加物理查询的方式实现指标消费。
增强计算：传统的数据工具依赖于数仓对数据的汇总加工，而在指标平台中，通过明细数据即可完成指标的定义，并通过自动语义的能力实现指标的查询。但面对庞大的明细数据量，如何满足业务的查询性能和稳定性成为要解决的关键问题。在查询性能方面，我们研发了智能物化，不再依赖数仓 RD 开发，系统根据指标定义自动完成宽表和汇总表的开发，并能自动完成物化任务周期调度、数据回溯；在稳定性方面，我们有一套完整的指标路由、降级策略，保证查询的稳定性。在此基础上，我们进一步调研并集成了新架构计算引擎，基于其强大计算能力和稳定性设计，在查询性能和可靠性方面有了更有力的保障。
分析工具：传统分析工具中，同环比等分析需求往往由业务自助在数据集中完成，切换分析场景或者分析工具需要重新找表和写 SQL，整体分析流程割裂且不连贯。在美团指标平台中，同环比、时间窗口、占比合计等分析需求都由平台统一进行实现和沉淀，各个分析工具基于平台的统一口径进行指标消费，实现一次定义全局消费。指标平台也支持用户快捷配置各类丰富的自定义指标维度进行实验探索。

以上的各层系统演进，重点在于"自动语义"和"增强计算"两大核心能力的建设，下面我们将分别进行详细阐述。

2.1 自动语义

自动语义将业务语言定义的指标口径解析为结构化的逻辑表达，并通过主外键关系将数仓模型自动关联成星型模型、雪花模型和星座模型，给原子指标提供了更丰富的分析视角，并扩展出衍生、复合指标。在实际执行查询计算时，自动语义根据指标定义和模型拓扑，通过智能路由选表构造逻辑执行计划和物理查询计划，实现定义即研发。

2.1.1 指标定义及加工

指标定义采用业务口径和技术口径定义相连接的设计，业务团队负责描述指标的业务计算口径，数仓团队负责提供指标的原子生产过程，指标平台可以根据注册的业务和技术信息推导非原子指标的生产过程并进行指标表达。美团指标平台具有以下能力：

指标定义及管理：美团指标平台支持丰富种类的指标模板，包括原子指标、四则运算指标、二次计算指标、留存指标、条件判断指标、复合指标等指标类型，也支持指标限定指标、忽略维度，受限维度、强制维度、GroupingSets 维度组、SQL 模型变量、多语言维度等特性，这种配置化和模板化的业务语言不仅有助于业务进行自助灵活的配置，也便于下游推导复杂指标的生产过程。系统还基于标准的词根词库、口径含义检查实现标准易懂、明确唯一的指标口径。
标准化建模：对于不同层次、不同阶段、不同场景的数仓建设诉求，美团指标平台提供丰富的模型类型。对于规范化的数仓模型，可以手动关联多张物理表构建，形成星型或雪花逻辑结构的组件模型。对于下层数仓建设成熟度不够，需要添加较多处理逻辑和变量，可以通过灵活的 SQL 构建组件模型。对已存指标维度，支持快速物化生产主题层、应用层模型，通过圈选指标维度并且智能构建 ETL 的汇总模型。系统也提供指标一致性校验和质量校验，帮助用户发现数据问题并辅助业务数仓的指标治理。
数据消费：对于通用分析并且数仓规范程度较高的场景，可以将指标平台资产发布到 BI 平台的公共池，采用全局路由对下游提供统一的指标维度口径。新业务或者特定业务场景常常需要快速获取特定口径的指标维度以满足业务的敏捷发展，为了避免污染全局统一指标口径，此时可以将指标平台资产发布到 BI 工具的非公共池，并在数据集中圈选对应的模型、指标和维度，对下游提供指标维度口径。全局路由和数据集满足不同阶段、不同场景下的数据治理和数据使用诉求，平衡了口径治理和业务快速发展的矛盾。

基于模板表达完指标定义后，指标平台将其加工为结构化和逻辑化的指标血缘，指标血缘描述了复杂指标依赖哪些底层指标维度，采用树形结构来表达。指标血缘会将复杂指标的限定修饰、忽略维度、留存配置、二次计算配置等信息下推到底层指标维度上，从而等标记出底层指标实际查询时需要考虑的语义。指标血缘还对底层指标的查询语义进行唯一标识，帮助下游复用。如下 3 个计算指标（K1、K2、K3）都依赖了指标 K4，前两个 K4 的限定修饰都是【商家类型 = 大连锁】，可以复用同一个查询语义，而第三个 K4 具有不同的限定修饰【商家城市 = 北京】，需要单独进行查询。

2.1.2 模型关联和指标扩展

指标血缘描述了复杂指标依赖哪些底层指标及下推信息，但是仅仅依靠单个模型无法支持复杂指标的查询，比如上文提到的指标 K4 所在的事实模型可能不支持品类维度。为了扩展出更多的复杂指标，指标平台首先根据主外键对数仓模型进行连结，将多表关联星型模型、雪花模型和星座模型，为事实表上的指标提供更多的分析视角，从而扩展出复杂指标，节省了数仓开发成本。

如下所示是一个雪花模型例子，订单事实表上有商家维表的主键"商家"维度和日期维表的主键"日"维度，事实表就自动关联上商家维表和日期维表。同时商家维表也包含商家品牌维表的主键"商家品牌"维度，和商家蜂窝维表的主键"商家蜂窝"维度，商家维度也关联上商家品牌维表和商家蜂窝维表。如此通过层层关联最后形成如下的雪花模型，最终订单事实表上的指标多了商家的品牌维度、蜂窝维度、城市维度等分析视角，从而能支持"大连锁订单量"之类的复合指标，同时事实表上的指标也可以进行四则计算从而支持"单均价"之类计算指标。

经过自动关联后的雪花模型能提供丰富的维度，任意多个雪花模型都能对齐构建星座模型，如下表所示，星座模型数目 = 任意 2 个雪花模型对齐的星座模型数目+任意 3 个雪花模型对齐的星座模型数目+...+全部 N 个雪花模型对齐的星座模型数目。

可见从雪花模型出发构建星座模型存在模型数目爆炸风险，并且这些星座模型大多数对实际查询是无用的，因此指标平台舍弃构建全量星座模型，而是从指标的定义出发按需构建星座模型。但如果计算指标的成分指标有多个，那么星座模型数目等于各个成分指标雪花模型数目的乘积，也存在模型数目爆炸风险。考虑在后续查询过程中依旧需要对各个成分指标的雪花模型单独进行路由判定，所以指标平台舍弃提前进行组合，仅记录各个成分指标的雪花模型，称之为半成品星座模型。在查询时根据查询条件对雪花模型进行淘汰后再组合，大幅度减少星座模型数目。

自动关联模型后就可以计算指标的扩展方案，不同类型的指标定义具有不同的扩展方式，例如：

维度限定的复合指标需要依赖指标和限定维度能从同一个雪花模型扩展出来；
四则运算指标则要求依赖的成分能各自从某个雪花模型扩展出来；
忽略维度则会减少对模型维度集合的要求；
指标限定指标需要限定指标的模型和主指标的模型在粒度上对齐。

根据指标血缘的树形结构，最终复杂指标的扩展方案数目随着树深度和广度非线性增加，穷举容易导致扩展方案爆炸。在实际路由时指标平台考虑优先选择上层的、成分较少的成分指标来生成扩展方式，设计了带阈值和权重的广度优先搜索策略得到 TopN 的可扩展方式组合，保障了预计算和路由淘汰的计算量不会过大。

由上述细节可以看出，模型关联和指标扩展的计算逻辑存在各种遍历和排列组合，计算复杂度高，并且部分业务场景的请求需要全量的模型关联和指标扩展方案（比如后续介绍的指标高亮），现场请求计算往往无法在秒级内返回结果。技术团队在系统中采用空间换时间的策略，建设了"指标仓库"模块。该模块监听到上游元数据变更自动触发模型关联和指标扩展，将计算结果放在持久存储和缓存中，下游请求时为具体业务逻辑提供预处理的模型关联和指标扩展结果。

2.1.3 指标高亮和路由选表

完成模型关联和指标扩展后，指标平台为下游提供了丰富的指标维度，但是因为部分业务场景之间天然存在隔离，某些指标一定无法在特定视角进行分析，技术团队在产品上采用高亮的方案进行相关信息的展示。指标平台采取点选的形式为用户提供报表配置或灵活分析配置，初始态所有指标维度都处于可选状态，当用户选择某个指标维度后，指标平台计算还有哪些指标维度能参与一起分析，能一起分析的指标维度处于高亮的可选状态，不能一起分析的指标维度处于置灰的可不选状态。高亮的计算逻辑主要分为模型匹配和指标可分析维度两个步骤。

模型匹配 是指根据用户配置和查询条件对所有模型进行匹配判定。不同业务场景有不同的匹配诉求，目前已有如下规则，用户可以根据需求自由选择组合：

数据范围判定：模型的数据范围必须包含用户查询的数据范围，比如特定物理城市、指定日期范围等；
引擎范围判定：部分场景下用户只希望路由到特定类型引擎，例如灵活取数场景下路由到 Spark 引擎；
强制维度判定：模型上的强制维度限定了该模型只能在某些分析视角进行探索；
GroupingSets 维度组判定：预聚合模型提供了多个可以分析的维度组，同时基于指标是否可以二次上卷和维度是否支持占位符值对查询条件进行判定；
模型标签或动态范围：根据用户自定义标签或动态模型范围进行匹配判定；
分区策略判定：为了避免扫描全表，用户必须对模型的分区字段进行范围选择，否则禁止使用该模型进行查询；
SQL 模型判定：用户需要为 SQL 模型中的变量赋值才能使用对应的 SQL 模型；
多语言环境判定：多语言背景下同一维度支持不同语言维值，模型上绑定和扩展的维度需要和用户的查询语言匹配；
维度集合判定：自动关联形成的星型模型和雪花模型必须提供用户选择的分析维和过滤维。

模型通过判定规则后就进入指标可分析维度的计算，这里的计算逻辑分为雪花模型和星座模型两种情况：

雪花模型：

指标 K1 有雪花模型 M1 和雪花模型 M2 支持，那么 K1 的可分析维度 = UNION(Dim(M1), Dim(M2))=（D1，D2，D3，D4）
指标 K2 有雪花模型 M3 和雪花模型 M4 支持，那么 K2 的可分析维度 = UNION(Dim(M3), Dim(M4))=（D1，D3，D5）

星座模型：

指标 K3 有依赖成分 K1 和 K2，那么 K3 的可分析维度等于成分指标各个雪花模型组合交集的并集：UNION{INTERSEC(Dim(M1), Dim(M3)), INTERSEC(Dim(M1), Dim(M4)), INTERSEC(Dim(M2), Dim(M3)), INTERSEC(Dim(M2), Dim(M4))}=（D1，D3）

通过高亮点选的形式完成指标维度选择和筛选条件的输入后，用户点击查询就进入路由阶段，此阶段根据用户查询条件为分析目标选择最优模型，从流程上来说分为模型匹配、维度路径选择和模型选择三部分。(1) 模型匹配可复用高亮计算逻辑。(2) 维度路径选择是对于雪花模型中维度选择最优的模型及其关联路径。考虑到各个模型中的维度值存在差异，模型选择策略根据数据完整性优先级递减分为以下五个层次：指标所在事实模型 > 维表模型 && 主键 > 维表模型 && 唯一键 > 非维表模型 && 主键 > 非维表模型 && 唯一键。模型集合确定后，可根据用户推荐、热度、查询性能选择模型，并选择评分最高的路径集合（通常基于贪心算法）覆盖所有查询的维度。针对部分场景对路由选表的确定性要求更高，也设计了非全局计算的稳定选择策略，保障多次规划结果一致。（3）在完成维度路径规划后，需要选择最优模型，此时指标平台通过评分机制进行选择，考虑因素包含引擎类型、推荐度、聚合类型、是否物化、计算方式、时间分区、底表数据量等。

2.1.4 查询语义构建

查询语义服务基于指标仓库构建的逻辑视图和 OLAP 引擎提供的分析计算能力，允许用户描述查询意图(DSL，Domain Specific Language)并从中分析出需要表达的目标指标内容，再用执行计划加物理查询的的方式表达出目标指标的构建过程(SQL)，实现指标表义和数据消费。

查询语义服务的能力分为以下四个部分：

灵活多元的指标定义：业务可以基于已有指标、维度扩展定义私有的或一次性指标和维度，兼顾了通用（强治理）和定制化（灵活探索）场景。

自定义指标：允许基于已有的指标、维度，通过定义四则运算、限定关系、同环比、占比、周期平均、累计加和、期初期末等计算过程，定义和表达新的指标口径。
自定义维度：允许基于已有的指标、维度，通过条件分组、数值区间映射、日期分组等方式，定义和表达新的维度表达口径。

查询意图表达：允许用户通过 DSL 表达其在指定分析场景下的查询意图，包含以下内容：

查询上下文：查询提交人业务线、业务场景、语言类型等环境信息，构建方法、缓存策略等行为信息。
数据源和自定义资产元数据：负责圈选可用资产范围，包括业务线公共资产，数据集私有资产，以及服务于特定业务场景的自定义资产。
查询现场：包含分析指标和维度、限定条件、排序和截断、多维查询等信息。
统计分析：允许基于查询现场中的分析维度和指标，衍生定义同环比、占比、合计小计、TopN 及其他计算过程。

执行计划：将用户查询内容经分析转换，表达为任务拓扑，用拓扑节点之间的依赖关系表示指标的构建和表达过程，经过逻辑编排、分组、优化，确定最终的执行计划。

拓扑：单一维度、指标的构建，可以根据其资产定义将其构建过程表达为拓扑结构（AST），一组维度、指标的拓扑又可以合并为一个整体的逻辑拓扑，该逻辑拓扑的数据结构决定了后续执行计划的具体执行过程。
编排：编排主要的职能是判断一个具体的过程指标对应的逻辑构建计划（逻辑拓扑的子拓扑），是否有可能下推到物理查询，基于引擎能力直接表达。编排的过程也是逻辑拓扑剪枝的过程。
分组：将逻辑拓扑中的所有物理查询叶子节点，按数据源、引擎、口径等预设规则进行分组，分组的结果决定了实际需要提交的物理查询。
优化：对上述逻辑拓扑进行结构优化，去除无用计算过程和冗余节点，提升执行计划的执行效率。
执行：依据拓扑排序的结果，顺次执行拓扑节点的动作，当所有节点的动作完成，指标数据的表达亦即完成。

物理查询：物理查询以拓扑任务节点的形式参与执行计划，物理查询节点是执行计划拓扑的叶子节点，一个物理查询节点代表了一个具体的物理查询过程。物理查询 SQL 的内容组织结构，采用自下向上的三层（数据源层、模型层、逻辑层）结构表达：

数据源层：数据源层负责表达模型结构，模型内容来源可以是指标仓库提供的逻辑宽表，也可以是内置了复杂的、非标准化的 SQL 计算逻辑。
模型层：模型层负责根据资产配置元数据，将数据源层提供的数据表或视图表达出来的字段元数据映射为表达原子化的指标和维度的计算过程。
逻辑层：逻辑层负责基于原子指标和已经表达的低阶非原子指标，递归构建高阶非原子指标。

2.2 增强计算

在灵活的指标定义之后，还要保证查询性能和稳定性，在美团指标平台和 BI 分析平台，我们通过智能查询服务和探索最新计算引擎，分别从应用层和引擎层进行优化。

2.2.1 智能查询服务

2.2.1.1 自动降级查询

前文中提到，我们会存在性能响应高于数据规模的面向数据运营用户看数模式（Serving），也有数据规模高于性能响应的灵活分析探查场景（Ad-hoc）。为兼顾这两种查询模式，我们在计算层采用了多种模型和执行降级的策略。

多引擎模型：同一套指标维度可以绑定多种不同引擎类型的模型，比如既可以绑定到 BSP 架构引擎（e.g. Hive 表模型)也可以绑定到 MPP 架构引擎（e.g. OLAP 引擎表模型)，以应对不同场景的查询需求。
查询降级策略：如果有多套模型，我们首先会基于查询条件和查询代价选择最优模型进行查询，但如果查询失败或查询未在一定时间内返回，系统会自动降级到次优查询，以应对大数据量耗时久的灵活分析场景，提升查询成功率。降级策略分为以下两大类：
- 同源降级（模型不变）：模型的物理存储不变，切换查询引擎，借助查询引擎的能力进行外表或联邦查询。期间的 SQL 适配和方言改写，由查询服务自动完成。
- 异构降级（模型改变）：平台支持相同指标绑定不同的物理模型，在查询期间，当最优的物理模型未能返回结果，系统可以降级到次优物理模型进行查询。同样，系统将屏蔽不同引擎间的查询细节，自动进行方言改写、函数适配等工作。

2.2.1.2 智能物化

指标平台通过增强指标定义能力，实现了计算逻辑与语义在平台内的统一沉淀。用户可直接基于明细数据进行指标定义，无需依赖数仓复杂加工，但随之而来的是查询海量数据的性能挑战。"智能物化"方案应运而生，该方案充分发挥指标仓库的维度定义与智能路由优势，自动构建应用模型与汇总模型，并完成任务调度与数据回溯。物化后的模型将重新注册至指标仓库，为业务提供高效的指标化消费体验。通过预计算与数据聚合，智能物化大幅提升了查询响应速度。

智能物化主要分为两种实现形式：数据集物化和全局物化，两者的执行时机和目标各有侧重。

（1）数据集物化由用户主动发起，适用于用户定义新数据集并希望加速查询的场景。物化结果直接应用于数仓的应用层，供查询使用。我们提供了两种物化策略：

1.轻度聚合物化：适用于维度指标不固定的灵活分析场景，该模式下我们只物化所选指标依赖的原子指标和维度（包括私有维度），生成轻度聚合模型，物化后的模型保持支持灵活上卷下钻特性。

宽表构建：基于用户选择的指标和维度，扩展物理表生成逻辑宽表。在执行层，通过多表 Join 操作预先固化为宽表，减少查询时的性能消耗。
预聚合：对细粒度数据进行汇总计算，将不同模型的相同维度合并处理，减少数据量，从而满足灵活分析场景的性能需求。
上卷操作：针对常用维度组合，进行预上卷操作，进一步减少数据扫描量，提升查询效率。

2.结果物化：适用于指标维度固定的场景，该模式下我们不再化原子指标，而是直接物化指标的计算结果，减少查询时的计算成本，进一步提升查询效率。

构建 GroupingSets 表：根据用户常用维度组合配置，生成 GroupingSets 的 ETL 代码，通过以空间换时间的方式提升查询性能。

在技术实现上，数据集物化过程主要分为以下几个阶段：

元数据准备：根据用户在数据集中圈选的指标和维度信息，从指标仓库获取指标维度语义及模型路由信息。
智能模型选择：由于指标仓库获取到的是能够支持指标查询的所有模型信息，在这个阶段我们会对每个对模型进行评分，选择最优的查询模型。
变更兼容处理：主要是针对已在线的数据集再次编辑上线的场景，判断在不删除模型的情况下增加新指标维度的物化。
指标智能分组：指标分组是基于一定的规则将指标进行分组的过程，每一个分组在后续会构建一个物化 SQL，生成一个物化模型。
SQL 构建：基于每个分组内的指标、维度语义及模型信息，构建 ETL SQL 和物化模型元信息的过程。
执行部署：基于物化 SQL 生成 ETL 任务注册调度，并将模型注册回指标仓库供查询分析使用。

（2）全局物化由系统根据用户查询行为（包括指标、维度、过滤条件等）自动触发。通过指标维度查询热度、关联统计、行为分析（过滤条件、分析方法等）、相似度检测、查询与存储成本分析，系统构建最优数据模型，以最低成本应对可变的查询条件。全局物化的构建结果将自动注册回指标平台，在指标仓库模型选择和查询服务路由中成为候选，和用户绑定模型、数据集物化模型互为补充。全局物化结果也受数仓管理，物化过程严格遵循数仓规范，可被数仓其它下游复用。

2.2.2 分析引擎探索

2.2.2.1 现状分析

传统的大数据生产服务链路中，由通用引擎（GP）进行数据生产，输出明细和轻度聚合数据；而后导入分析引擎（AP），进行服务层和应用层构建，对接 BI 等各种消费应用。其中，通用引擎和分析引擎，主要区别如下：

GP 通常采用 BSP(Bulk Synchronous Parallel)架构进行 Stage/Task 粒度的调度，Stage 结果持久化，数据规模要求高于性能响应，典型的代表是 Spark；
AP 通常采用 MPP(Massively Parallel Processing)架构进行 Query 粒度的调度，内存计算/Pipeline 执行，性能响应要求高于数据规模，例如 ClickHouse。

指标平台的计算部分具有以下特性（1）原子指标定义在数仓明细层，上游的复杂指标经过拆解后，查询 SQL 面向海量数据，事实表维表频繁关联（2）查询 SQL 由语义服务自动生成，类似于机器生成代码，逻辑正确但复杂度高、性能差（3）常用分析语义（同环比、占比等）也由查询服务即时生成，而非传统 BI 中的固化结果，带来了更大的计算量。以上三点对计算引擎的性能和可靠性提出了更高的要求。

通过降级查询和物化策略，我们可以在应用层面部分解决上述问题，将需要快速查询响应的物化在 MPP 引擎上，数据规模大的明细层查询作用在 BSP 引擎上，在保证性能的同时也保留了灵活分析的能力，但依然有以下不足：

系统架构分散，数据链路长，运维成本高、时效差。链路上分为 BSP、MPP 多类型系统，数据需要在多个系统间进行同步，影响成本和时效性，在回刷场景尤其明显。
面对灵活分析场景，仍存在性能瓶颈，并缺乏必要的隔离保护。BSP 架构可以在大查询中限制任务的最大调度单元数量，但受限后往往需要分钟甚至小时级别才能返回结果。MPP 架构虽然可以提供更快的响应时间，但缺乏必要的隔离保护，大查询往往会耗用整个集群的资源，对系统的稳定性造成影响。
资源缺乏弹性机制：业务分析负载具有显著的"潮汐效应"，即查询并发量在日、周、月等不同时间周期内呈现显著的波峰波谷。当前架构（尤其是 MPP），资源必须按照峰值需求进行配置，且业务集群之间相互隔离。上述因素带来了高昂的成本和资源的浪费。

近年来，随着关键技术（Native runtime，向量化执行，Delta Table 格式等）发展和存算分离、湖仓一体等概念的引入，两种引擎都有了飞速的进步。BSP 侧通过 Native runtime 和向量化执行，缓存优化，在小数据量和单点查询上性能大幅提升，直接对接数据消费应用层成为了可能；MPP 侧通过存算分离、CBO 改进，在保证性能的同时，数据规模/查询复杂度支持加强，逐渐向生产侧下移。两种架构的界限变得模糊了许多，在这种趋势下，出现了云原生、存算分离、单一引擎（SingleEngine）的架构路线，其中最典型的是国外的 Snowflake；国内也涌现出一些成熟的供应商，其中我们对云器科技的 Lakehouse 进行了深入的调研和合作。

2.2.2.2 Lakehouse

云器 Lakehouse 是由云器科技自主研发的新一代云湖仓。使用增量计算的数据计算引擎，性能可以提升至传统 BSP、MPP 开源架构的数倍，实现了海量数据的全链路-低成本-实时化处理，也为诸如 AI 创新提供了支持全类型的数据存储、计算平台。云器 LH 通过引入统一计算引擎，扩展弹性支持，存储优化，多重调度模式，向量化执行等几个方面，对传统的计算引擎在性能、成本、可靠性上进行了大幅提升，主要包含：

通用增量计算引擎：云器 LH 通过通用增量计算技术(Generic incremental Computing，GIC)，实现了对多种计算形态的统一。计算模式上，GIC 面向通用场景，通过一套增量计算逻辑，统一当前的流、批、交互三种模式。系统架构上，从 Lambda 进化为 Kappa 架构，提供面向数据新鲜度、查询性能和资源成本三方面的多种平衡点。
资源弹性伸缩能力：云器 LH 通过 VirtualCluster 实现横向和纵向双维度弹性。横向扩展根据 QPS 动态调整实例数量，支持 0 到 100+实例的秒级伸缩；纵向扩展根据查询复杂度调整单实例规格，从 2 CORE 到 64 CORE 灵活配置。两者相结合，对前文提到的查询潮汐效应，提供了平衡性能和成本的解决方案。
向量化执行：执行引擎使用 C++开发，并利用 SIMD 指令集进行批量运算，配合列式存储减少 I/O 开销，提升 CPU 利用率。这些优化在处理大规模聚合和多表 JOIN 时效果显著，符合指标平台进行指标多维度查询时的典型特征。
存储层优化：LH 内表存储采用 Parquet 格式配合 ZSTD 压缩，压缩比达 10:1。构建三级缓存（内存、SSD、对象存储）体系，缓存命中率超过 95%。这些优化对于处理时序数据和维表关联特别有效。
双模式执行：系统提供 BSP/DAG 和 MPP/Pipeline 两种执行模式。BSP 模式用于 ETL 和批处理，支持作业级 Failover，吞吐优先；MPP 模式用于交互查询，通过 Pipeline 流式处理降低延迟，支持算子级并行和并行度自动调整。

2.2.2.3 系统集成

美团数据生产消费具有海量数据（PB 级），查询量大（日百万级），实时性强（分钟级），稳定性要求高，安全合规严等高准入门槛，因此在接入云器 LH 作为计算引擎的过程中，既要能够验证生产环境下的性能收益，也要保障不影响线上查询和其他系统稳定性。我们设计了流量回放、线上双跑、灰度放量等多个接入阶段，在保障功能兼容、结果准确、线上稳定的同时，对性能和成本指标进行评估。

当前云器 LH 已经在美团两个数据中心进行了集群的部署。对接现有 BI 生态的系统方案，主要由以下设计考量/取舍：

嵌入式架构：云器 LH 采用引擎嵌入方式部署到美团生产、消费集群，遵循现有存储、计算、服务层已有标准和协议，进行必要的适配
异步查询：指标平台通过异步接口提交到云器 LH，通过提交、状态通知、拉取数据 3 个阶段完成整个异步查询的操作，与当前系统的查询方案一致
语法兼容：通过流量回放识别不兼容语法和函数，对于业务 Spark UDAF/UDF 天然支持无需改造，对于其他 MPP 引擎少量 C++ UDAF/UDF 通过开发进行适配
安全对接：云器遵循美团 Kerberos（KDC 认证）对接，接入数据账号和授权体系，在访问元数据（HMS）及数据（HDFS）对接时均采用授权认证方式。指标平台在 API 层对指标、维度、维值等进行鉴权，与当前系统鉴权方案保持一致。
数据存储：复用既有 HDFS 作为主存储，云器 LH 通过外表方式读写已有数据表，无需数据导入。使用对象存储作为结果存储，与现有 MPP 系统查询结果获取方案一致，提高指标平台拉取结果的性能和稳定性。

3 业务实践

美团指标平台经过几年的建设和应用，当前承接公司百余个业务线，其中模型规模达万量级，指标维度规模达十万量级。对应的 BI 应用，日查询量达百万级别，第三方应用日 API 调用量千万级别。查询成功率超过 99.9%，灵活探索场景查询时长 90 分位控制在分钟级别，运营监控场景查询时长 90 分位达到秒级别。

在云器 LH 的探索和实践上，为了确保线上稳定性和准确性，我们采取线上双跑和线下压测两种方式进行实验和评测。线上双跑，指在生产环境中对任意一次物理查询分别对不同引擎发起一次查询，异步对返回数据进行正确性校对并记录性能数据；线下压测，我们使用生产环境中大流量报表的真实流量进行回放，采用递增 QPS 方式测试系统极限性能并记录各阶梯压力下的性能指标。

在灵活探索（Ad-hoc）场景，我们采用线上双跑方式进行评测，灰度了部分时间内某业务线下的全部指标平台查询流量，涉及 84 张表，1000+TB 数据。对比组采用流行开源引擎 Trino 和云器 Lakehouse。Trino 采用 MPP 部署架构，千核集群；云器 LH 采用同配置（CPU 核数、内存、网络带宽）的 AP 模式，最大 VC 副本量设为 3。云器 LH 比 Trino 集群有 2 倍的性能提升，其中具体的查询百分位数据如下（单位毫秒）：

在运营看数（Serving）场景，我们采用线下压测云器 LH 方式进行评测，回放某大流量业务报表单工作日全部查询流量，涉及 20 张物化加速表，0.79T 数据。压测三轮，QPS 从 40 开始递增至 80 结束（线上实际 QPS 小于 10），每阶段持续 5 分钟，云器 LH 性能指标在各种压力下表现平稳，展现了优秀的弹性和资源隔离能力。具体数据（单位毫秒）如下：

4 未来展望

美团 BI 和指标平台的下一步发展，将继续在自动语义和增强计算两部分演进，并发展智能化能力。

在自动语义层面，我们计划根据业务的实际需求，增强标准数据（指标维度平台）和非标数据（传统 SQL 数据集）的联合查询能力和相互转换能力，并在配置化的基础之上，增加函数表达、开放算子接口等功能，支持更加复杂、个性化的语义配置、路由选表、语义生产能力。
在增强计算层面，放量新版本计算引擎灰度场景，获取更大性能成本收益，在架构上将当前服务层中部分缓存、降级、物化、查询优化能力下沉到引擎层，使查询服务更适配计算引擎的发展趋势。
在智能化层面，指标平台相对于传统 Text2SQL 方式具有天然优势：可以使用已沉淀的指标维度业务和技术信息，避免二义性提高准确率，并能够复用原有鉴权体系，保障数据安全。

美团 BI 工具结合指标平台能力，已经孵化了自然语言数据助手、仪表板分析板助手等智能化产品，下一步将扩大业务场景范围，在数据准备配置、自然语言取数、分析辅助和自动报告生产上进一步提升产品能力，帮助业务持续提升运营效率。

阅读更多

| 关注「美团技术团队」微信公众号（meituantech），阅读更多技术干货！

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明"内容转载自美团技术团队"。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至 tech@meituan.com 申请授权。