技术分享｜揭秘第三代指标平台的查询加速技术

本文根据 Aloudata 直播专栏 “NoETL 公开课｜*第三代指标平台查询加速能力技术详解”的演讲内容整理发布。

讲师简介： 张乐，Aloudata CAN 指标平台技术负责人。8 年互联网技术架构和数据平台产品相关经验，原蚂蚁集团数据安全合规平台主架构师。在蚂蚁工作期间，历任蚂蚁集团数据共创实验室、数据安全合规平台主架构师以及核心研发，主导蚂蚁数据共创平台、实时数据分类分级平台、隐私安全治理平台的架构演进和核心技术攻坚，在主动元数据、数据安全、隐私合规、多方数据可信计算等领域丰富的实践经验及多项突破性技术创新，拥有多项国家专利。

01 Aloudata CAN 指标定义能力的 6 大技术保障

（该章节是对指标定义技术分享的简要回顾，指标查询加速的分享内容详见第二小节。）

在当今的企业运营中，指标平台的作用日益凸显，它不仅需要具备强大的指标定义能力，还要拥有高效的查询和加速机制。今天我们将重点探讨指标平台的加速能力。

首先，企业对指标平台的需求和痛点主要集中在以下几个方面：

• 指标生产：企业希望指标生产能够规范化、标准化，以及运维保障过程的灵活性。希望指标上线时就能够实现治理，而不是在开发后再花费大量时间和精力进行治理。

• 指标管理：涉及到众多企业级特性，如指标的权限管理，包括行权限、列权限，以及指标在部门和个人之间的权限划分。此外，还包括维度管理、多版本管理和变更影响范围等。

• 指标分析：企业希望分析能够足够灵活，在有大量指标和维度的场景下，也能保证分析的灵活性和查询性能体验，并能基于任意维度进行下钻分析和归因分析，实现指标预警和指标生产时效保障等。

• 分析报表的可视化：企业需要将分析结果以直观的方式展现，以便更好地理解和决策。因此企业可能会构建一些应用和 BI 工具，例如建立管理驾驶舱，或者将已有的 BI 工具与指标平台打通。

需求有这四个大的方面，但在实际指标平台建设的过程中，会面临许多问题。包括指标口径管理问题、复杂指标定义困难的问题以及指标生产效率的问题。如基于一个复杂的指标，BI 提需求给 IT，IT 需要先理解业务需求后进行数据清洗加工，加工得到一份数据后交付给 BI，又有可能与 BI 的预期不一致，导致来回反复修复，最终影响整个生产效率较为低下。

这些问题统一归结为指标定义问题。要支持复杂指标的定义，从 Aloudata CAN 指标平台的理念来看，核心步骤有三个：

首先，需要有一套通用的语义模型，即通过维度表和事实表进行建模，确定模型关系。

其次，需要有一套丰富的指标定义体系，包括基于语义模型来构建原子指标、派生指标和复合指标，以及对应的维度管理，包括维值映射、指标转维度等功能。

最后，还需要有一套完整的函数体系以及指标计算体系，基于这套体系来定义多种复杂指标，例如基于时间智能、时间窗口、LOD 多层聚合窗口计算，以及跨事实转化，如计算留存率、复购率等同期群类指标、漏斗类指标。

Aloudata CAN 以强大的指标定义能力著称，其背后有六大技术支撑能力：

• 完善的数据语义模型。这是所有指标定义的基础。

• 完善的函数体系。除了通用函数外，还包括针对特定指标分析场景的分析函数，这在指标平台中尤为重要。

• 多层次、多聚合的查询构建 DAG 的能力。这能够解决复杂指标的构建问题，无论指标多复杂，都可以通过多层次、多聚合的方式构建 DAG。

• 基于已定义的指标要素，将它们拼接成对应的 SQL 查询。

• 查询 SQL 优化。一是基于指标计算本身的优化，如关联下推、多层 AGG 合并和裁剪；二是基于规则优化器（RBO）进行的优化，如 Limit 下推、子查询裁剪和列裁剪等。

• 自建内存计算引擎提升查询效率。这个计算引擎是专门针对指标场景开发的，包括指标分析器、RBO 和 CBO 的拆分、DAG 构建、任务管理、算子级别执行器、缓存等。

以上六大能力我们曾在直播中进行了详细的介绍，感兴趣的同学可以关注 Aloudata 公众号的直播回放和相关文章。

02 第三代指标平台查询加速技术实现

今天我们重点讨论的是指标定义完成后，如果想基于语义模型，进行多维度、多指标、跨数据集、多层次分析时，会碰到的另外一个问题，即指标加速问题。

这个问题可以拆分为三个部分。

第一个是指标查询性能问题。在企业中，如果要将多个指标结合起来分析，并且这些指标和维度来自不同的表，而且每张表的数据量又很大，那么就会出现指标查询性能问题。

第二个问题是如何有效管理计算与存储的资源消耗成本。

第三个问题是指标的时效问题。比如在高管报表场景下，需要在早上 8 点前能够看到指标结果，指标查询性能要快，而不受其他指标计算或者任务的影响。

Aloudata CAN 指标平台的核心目标是在一个指标平台上完成企业对整个指标的管理和计算的诉求，那么首先指标要能够被定义出来；其次要能够被算出来，并且要能够被加速；第三，指标除了能计算、能定义之外，还要求它的性能好、成本低以及实效有保障。

要满足这三大需求，核心有两个关键项，其一是物化视图，其二是策略。具体来说就是基于指标平台本身的物化视图构建、物化视图调度更新、物化视图命中改写以及物化视图回收。

下面我们来详细讲解这四个方面。

1、物化视图的构建

首先来看基于物化视图的架构，这是 Aloudata CAN 的核心实现机制。

在企业中，数据会存储在不同的数据源上，而指标的定义需要依赖不同数据源的联合查询以及联合模型定义。那么，基于这些不同的数据源，指标平台会构建一个语义模型，包含模型的定义、指标定义、物化加速方案的配置。

有了这三部分之后，我们会基于指标本身的定义和物化加速方案的定义，将其转化成物化和查询的 Node，以及提取物化视图的元数据信息，然后再将这两部分的内容提交到物化视图管理模块。该模块包含了物化视图的构建、命中改写、更新、回收等多种能力。

除此之外，物化视图的构建只是一个定义，还需要进行周期性的任务执行，因此，物化加速会依赖一个任务调度系统。这个任务调度系统里面包含了周期性任务的触发、数据回刷、任务状态管理、告警监控以及 DAG 调度等。通过调度平台，再去与 MPP 计算引擎进行交互，最终把物化视图产出出来。这是它的一个核心机制。

在了解完整体物化视图架构之后，接下来就从物化视图的构建开始讲解。我们知道，在一个物化加速的方案中，它通常会包含以下几个部分：首先是需要分析的指标、维度，筛选、物化周期配置以及分区范围。比如一次性回刷多长时间段的数据或者回刷多少个时间分区。

有了具体的物化加速方案后，我们会根据物化加速的策略来构建一个网络的 DAG 图，即层层依赖的 DAG 构建。如下图，从 Node 1 到 Node 10，分别代表的是不同的计算节点，关于这个图是如何构建出来的，在上期分享中我们已经讲过，本期就不再讲述这方面的内容。

有了这个 DAG 依赖关系图谱之后，接下来需要基于节点依赖关系构建物化视图依赖关系。如上图，从下往上看，首先是基于语义模型构建的星型模型或者雪花模型，再往上是构建一层普通聚合物化视图，它常用于普通的原子指标。比如按照天粒度构建的订单总金额。

有了普通的聚合物化视图之后，我们再往上构建衍生指标的物化视图。例如，计算近 30 天的销售总额，会涉及到数据行间偏移的计算，即每天要计算连续 30 天的数据。

再往上一层是针对复杂指标的构建，比如近一年月日均 AUM 的最大值，或者是股票市场中北向资金净买入额的行业排名。这类指标涉及到多层聚合和多步骤的依赖，也可以作为一个整体进行加速。

最顶层是针对对性能要求非常高的场景，如指标看板类需求，可以通过结果集的物化视图来保障。例如，计算某分行月末存款余额或者贷款余额等等。

总结来说，我们基于物化加速方案，将查询请求转变成 DAG 的构建，然后再将其拆分成五层不同的物化视图，以此来保障整个查询的性能和灵活性。如上图，最底下是企业最明细的事实表和维度表，基于明细表来构建宽表星型模型，一直到最上面的结果物化视图。基于该图，从下往上，性能是逐步提升的，也就是说结果物化视图的查询性能一定是最快的，基本上都是毫秒级。然后从上往下，物化视图的复用性和灵活性又是逐步提升的。例如，如果我们在普通聚合物化视图层构建了一个“天”粒度的销售金额的统计数据，这个物化视图是可以在很多场景被复用的。

上述是核心的物化视图构建机制，除了机制之外，还需要有不同的物化加速策略来指导物化视图的构建，这些策略不但适用于物化视图的构建，也同样适用于物化视图的命中。

第一个是冗余维度打宽。即针对常用的维度，将其与明细事实表进行预打宽，这样上层在使用时就可以基于该明细宽表进行计算，可以减少多次关联带来的计算消耗。

第二个是同事实同实体合并计算。如针对订单表的多个不同的指标，可以放在一起进行计算，减少对事实表的多次扫描。

第三个是长周期依赖短周期。如已有物化视图是基于“天”粒度构建的，那么，派生指标中的近 7 天、本月、近 30 天等等，都可以基于该天粒度的物化视图进行构建。

第四个是细粒度上卷聚合计算。如已有物化视图的维度是 A、B、C、D，当用户新构建的物化加速方案是基于 A、B 两个维度时，则可以来 A、B、C、D 四个维度的物化视图进行上卷，避免了从原始数据进行计算。

以上四种例子较为常见，Aloudata CAN 还设置了许多其他加速数据处理的策略。

2、物化视图的调度更新

物化视图构建完成后，接下来关注如何进行物化视图的调度更新。我们将整个数据处理流程分层，从源数据到物化视图的整个链路都进行了细致的规划。具体来说，我们根据数据源中的不同表来构建不同的数据集，并定义它们之间的关系。比如 DataSet A 和 DataSet B 之间可能存在 1:N 的关系，这种关系一旦建立，我们就可以进一步定义相应的维度和指标。

定义好维度和指标后，结合用户实际需求的分析场景，我们可以构建特定的加速方案。这些加速方案背后的物化视图可以根据不同需求进行相应的调整。在实际调度过程中，按照层次依赖及其网络上下级关系更新物化视图，并且是基于物化视图来构建物化视图以及刷新。

3、物化视图的命中与改写

接下来，我们讨论第三方面的内容：查询命中与改写。

如前所述，在基于用户需求构建加速方案后，我们会创建不同层级的物化视图。在执行查询命中时，系统会将用户从 APP 或 BI 工具发起的查询首先转化为标准的 SQL 查询提交到指标平台，指标平台接收到请求后，会将对应的查询转换为查询 DAG，并对该 DAG 进行遍历，构建出完整的一颗计算节点树，便于后续的命中和改写。

在命中阶段，我们采取一系列策略，优先进行整体命中，检查是否有完全符合查询内容的物化视图。若无法命中，则检查行间偏移的物化视图，随后是普通的聚合物化视图，如按日聚合的物化视图，如果这些都不能命中，最后考虑是否有星型物化视图能够命中。若所有物化视图都无法命中，才会进行原始数据查询。

当在物化视图的匹配过程中存在多个可供匹配的物化视图时，系统会在多个物化视图中选择最优的物化视图，在考虑最优物化视图时，会结合物化视图的维度相似性、数据范围和日期粒度等因素。通过这些策略选择最合适的物化视图以执行查询，这是整个命中过程的核心。

在物化视图的构建、调度、命中改写之后，接下来需要考虑的问题是如何进行物化视图的更新。因为，在指标平台实际的运行过程中，通常会遇到指标口径变更、原始数据集发生变更、数据关系发生变更等情况，那么，为了应对种种可能出现的变更，也需要有一套完整的机制来确保数据的准确性与及时性。

在 Aloudata CAN 指标平台中，我们构建了基于**指标血缘的网络算子图谱**（如上图）。

这个算子图谱左侧是事实表，中间上方是维度表。系统会针对每一个事实表和维度表进行监听（或者由企业的 API 来触发），探测器会探测数据表结构的变更、数据内容的变更、分区是否更新等。当探测器感知到变化后，我们就可以基于图谱刷新下游的物化视图。例如，如果探测到维度表 1 发生了变化，我们就可以通过图谱的横轴和纵轴焦点看出维度表 1 和事实表 A 之间有关系，因为维度表 1 和事实表 A 构建出了原子指标A。那么，当维度表1发生变化时，原子指标 A 会受到影响，调度系统在更新物化视图时则对原子指标 A 以及下游的物化视图进行版本级的数据刷新。此外，原子指标 B 也受影响，因为它与变化的维度表 1 相关。

我们还可以看到原子指标 A 下游有派生指标 A ，派生指标 A 下游又有复合指标 A。这三个指标的下游对应的分析视图 A 和分析视图 B 也受影响。分析视图 A、B 下游分别有物化视图 A、B、C 和 D。因此，我们可以清晰知道一个维度表或事实表变化后，其下游影响的具体范围，从而实现最小范围的数据刷新。不受影响的链路则不会进行刷新。

4、物化视图的成本效益优化

在成本效益优化方面，我们的核心目标是基于物化视图的查询热度和成本收益来减少中间的物化视图。在建立每一个物化视图时，我们会评估它带来的收益大小。上诉这个公式的核心是讲述如何平衡物化视图的成本和效益。

hi代表的是物化视图在未来一段时间内的使用次数。例如，预计在未来一天内它会被使用 5 次，系统会计算出每一次使用的收益。单次使用的收益是单次构建成本（gi）和单次消费成本（ci，例如对表进行 scan 时所消耗的成本）的差额。再乘以使用次数（hi ），就是物化视图的总收益。然后再减去物化视图的构建成本，即构建次数（si）和单次构建成本的乘积，就能得出一个公式：总收益减去总构建成本。如果这个值大于零，代表收益大于构建成本，那么建立物化视图是划算的。如果小于零，则放弃物化视图的构建。

我们对 Aloudata CAN 物化视图的构建、调度、命中、更新与回收的整体机制进行一下小结（如上图）。

最上层是指标查询物化，它涉及到启动时的场景、使用一段时间后的智能加速和治理场景、APP 对接或者 BI 工具对接的场景，如 BI 看板和管理驾驶舱的查询请求。在这些场景中，我们会将查询转换为基于指标和公式的查询。有了指标和公式后，我们会构建一个 DAG 来生成查询结构体。

通过将不同种类和来源的查询统一转变成查询结构体后，在物化视图管理和构建链路中，采取的是同样一套处理流程，即通过对物化视图依赖的源头表进行元数据采集，并且结合物化视图的构建策略和执行计划，完成物化视图的构建、物化视图的命中、物化视图的回收以及物化视图的调度，通过与 MPP 计算引擎相结合，完成 整个指标平台的查询加速。

03 与各种 BI 工具、数据应用和 AI 应用集成

总结来说，Aloudata CAN 是一个定义及生产自动化指标的平台。它的核心目标是让企业里的指标可理解、可管理、易于使用。通过语义层接入不同的数据源，依托指标平台的语义模型定义以及规范化的指标定义和自动化的指标生产，在通过不同的形式对指标和维度的查询和管理进行开放，非常方便的与各种 BI 工具、数据应用和 AI 应用集成。

从前面的讲解我们可以看到，Aloudata CAN 在指标加速方面有四大核心优势：性能、成本、时效以及整个过程中的策略。这些策略围绕 NoETL 理念，考虑物化视图的构建、命中、回收以及成本时效，相当于有一个智能大脑在不断的迭代优化系统中产生的物化视图以及其使用情况，动态平衡性能、成本和时效。

展望 Aloudata CAN 的未来，我们规划了三大方面：

首先，针对底层的物化加速引擎，系统基于指标进行明细物化、星型物化、聚合物化和结果物化，并构建物化的策略中心，实现自动编排和回收物化结果数据。这样能够免去大量繁琐的 ETL 开发、运维和治理工作，最终实现在大数据量下的秒级响应；

其次，针对语义化扩展，我们将依托语义模型，并在此基础上扩展指标的定义能力，尤其是在不同场景下复杂指标的定义能力，以实现在 Aloudata CAN 平台上达到复杂指标定义简单且高效计算；

第三，结合大语言模型，构建指标 Copilot，实现自然语言的对话，包括取数、归因洞察、预警以及分析报告的生成，从而降低用户使用门槛，帮助企业快速理解业务现状、数据波动原因，并做出正确决策。

以上就是本次分享的内容。

我们将在 4 月 16 日 19:00 起进行一系列产品展示直播，由产品经理亲自开箱实测并演示指标定义能力，欢迎大家扫描下方二维码预约观看。