技术分享｜揭秘第三代指标平台如何解决复杂指标的定义与计算问题

本文根据 Aloudata 直播专栏 “NoETL 公开课｜第三代指标平台如何解决复杂指标的定义与计算问题？”的演讲内容整理发布。

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

欢迎大家参加“NoETL 公开课”。今天我们将详细讨论 Aloudata CAN 指标平台对复杂指标的定义和计算的技术实现。今晚的分享主要包括三个方面：第一，描述企业对指标平台需求和痛点；第二，从技术角度解析指标平台的核心能力——指标定义能力；第三，描述 Aloudata CAN 自动化指标平台未来的规划和展望。

企业在建立指标平台时，从数据存储到数据消费，存在着多方面的需求，主要包括指标生产、指标管理、指标分析以及指标消费这四个方面。而在每个方面又都存在着不同的需求。

在指标生产过程中，企业要求指标是规范化和标准化的，并且可以灵活配置；

在指标管理方面，针对不同的指标，存在不同的权限管理要求，比如对不同区域的经理，他们只能看到特定区域的详细数据，而无法查看其他地区的情况。另外，在维度和指标变更方面也有特定的需求，企业希望指标变更按照标准化规范进行，且在变动时能够清晰了解变更的影响范围；

在指标分析阶段，企业希望分析灵活且性能良好，能够应对不同的分析场景；

在最后的指标消费阶段，不同企业有不同的消费场景，BI 软件可能更多地采用 JDBC 形式，而有自己管理驾驶舱的企业则希望通过 API 接口消费。具体的消费需求包含指标的查看、分析、预警以及数据消费的时效保障等。

这些是企业对指标平台的理想需求。而实际上，企业的指标生产、管理与消费面临着多个问题和痛点。

• 首先，在指标的口径定义方面，存在着同名不同义、同义不同名以及口径定义入口分散等问题，导致口径不一致的情况；同时，在复杂指标定义时，如年月日均值、最大值等指标，涉及多层聚合，通过页面操作难以定义出来，存在较大挑战；

• 其次，效率问题也是一个挑战，因为通常在企业中，IT 人员和数据分析人员之间的沟通和理解需求需要时间，指标开发时间较长，IT 人员可能成为瓶颈；

• 此外，在指标查询中，当模型表较多或数据量大时，性能可能会出现问题。另外，在集群计算资源消耗方面也存在挑战，包括重复计算和资源消耗较大。

• 最后，指标的时效性也是一个问题，影响了报表准时产出的目标。

图 1：指标平台面临的问题&痛点

上述的不同问题，实质上可归类为指标定义问题 和 指标加速问题。今晚我们的核心话题是关于指标定义方面的问题，而我们将会在 4 月 7 号晚上 7 点讨论指标加速的问题。

对于指标定义，特别是复杂指标的定义，在企业中，通常需要依赖 ETL 同学进行加工，加工流程包括将业务系统数据、日志数据以及第三方数据导入数据仓库，形成维度表和事实表，然后基于这些维度表和事实表生成宽表和汇总表。在某些情况下，这些宽表和汇总表可能无法直接满足业务的需求，需要进一步的打宽和汇总，导致形成更大的宽表和汇总表，除此之外，部分汇总表又单独新建分支链路，从明细层直接加工，形成穿透的情况，就会造成整个数仓体系缺乏明确的层次限定，呈现出类似于蜘蛛网状的结构。这对于整体数据体系来说，数据链路复杂性在不断增加，而数据质量信心却在不断下降 。

传统的 ETL 指标加工方式是通过创建大量的宽表和汇总表来处理数据，而 Aloudata CAN 的核心理念是改变这种数据加工的方式。我们的目标是无需依赖大量的宽表和汇总表，而是在明细数据接入后，通过语义模型来定义维度表、事实表以及它们之间的关系，然后再基于语义模型来定义原子指标、派生指标和复合指标。在数据消费阶段，我们将基于这些指标进行具体的消费。这就是 Aloudata CAN 指标平台的解决方案。

图 2：Aloudata CAN 指标平台 vs 传统 ETL 指标加工流程

接下来, 我们将通过具体案例来演绎这个方案是如何解决企业中复杂指标的问题的。

在典型的电商场景中，常见的数据模型包括买家表、卖家表、订单表和产品表等。

在建立这样的数据模型时，需要设置它们之间的关联关系，包括一对一关系或一对多关系。当语义模型建好之后，接下来就可以定义具体的指标，例如定义一个近 7 天的 VIP 用户消费额的指标。

但是，在定义这个指标时，由于该指标涉及到多步骤的计算，存在一定的复杂性和难点。

首先，对于 VIP 用户的定义是其在平台上累计消费金额需要达到 2 万，因此需要计算每个用户的累计消费金额。

其次，需要计算累计消费金额超过 2 万的时间点。

然后，需要以 VIP 会员成为 VIP 的时间为锚定时间，向后计算近 7 天的消费金额。最后，由于该指标涉及多层动态聚合，可能会带来一些性能问题。

图 3：复杂指标定义在电商场景的案例难点

我们拿一个实际的数据对这个场景进行演绎。左边的表展示了用户的订单数据，包括用户 ID、订单时间和消费金额，我们基于该表来做具体是数据计算推演。

首先，我们需要计算每个用户的累计消费金额。例如，用户 ID 为 1 的用户在 3 月 1 号消费 5,000，3 月 2 号消费 6,000，因此他在 3 月 1 号的累计消费金额为 11,000；到了 3 月 2 号，累计消费金额为 21,000；而在 3 月 3 号又消费了 1,000，所以截止到 3 月 3 号，累计消费金额为 22,000。而蓝色部分代表 ID 为 2 的用户，其计算逻辑与 ID 为 1 的用户相同。

计算出累计金额后，接下来我们要计算每个用户成为 VIP 的日期。对于 ID 为 1 的用户来说，他在 3 月 1 号的累计消费金额仅为 10,000，到了 3 月 2 号才达到 20,000，因此他成为 VIP 的日期就是 3 月 2 号，之后的消费统计也都基于这个日期。而 ID 为 2 的用户的计算逻辑也是相似的。他在 3 月 4 号和 3 月 6 号都未达到 20,000，到了 3 月 7 号才达到，因此他的成为 VIP 的日期就是 3 月 7 号。

计算出每个用户成为 VIP 用户的日期后，第三步就要计算他们成为 VIP 后近 7 天的消费金额。这个近 7 天的消费金额是一个滚动窗口，对于 ID 为 1 的用户，他在 3 月 1 号并不是 VIP，因此消费金额为 0，到了 3 月 2 号成为 VIP，这个时候计算的是 1 号和 2 号的消费金额，所以为 21,000；以此类推，到了 3 月 8 号，他的近 7 天消费金额是 17,500。对于每个 VIP 用户，我们要从他成为 VIP 的日期开始向前追溯 7 天来计算近 7 天的消费金额。

图 4：指标计算在电商场景的实际案例推演

数据的计算过程中涉及多个步骤。若要使用 SQL 实现，复杂度较高，因为需要多层聚合。

计算 VIP 用户近 7 天的消费金额后，还可以基于此结果定义其他复杂指标。

例如，可以根据 VIP 用户近 7 天的消费金额进行分层标记，如将消费金额大于 3 万的 VIP 用户定义为高级 VIP 用户，2 万到 3 万的为中级 VIP 用户等。

此外，还可以计算这些不同级别用户所在城市的占比、排名，以及其消费金额同比情况。

这些都构成了数据计算的复杂过程。

那在 Aloudata CAN 平台上，操作被简化如下：

首先，我们需要定义数据模型，比如用户表和订单表的一对多关系，其关联键为用户 ID；

其次，我们要定义一个维度，即用户成为 VIP 的日期。在这个维度的定义上，我们使用函数体系来实现；

接着，我们定义指标，例如 VIP 用户近 7 天的订单金额。在这一步，我们设定了时间限定为近 7 天，并且业务限定为订单日期大于或等于用户成为 VIP 的日期。

通过这三个步骤，我们就能够定义出我们所需的指标。定义好之后，我们可以在分析页面中选择"VIP 用户近 7 天 的订单额"作为指标，选择指标日期和用户 ID 作为维度。当我们选择了比如说 2024 年一月份的时间，就可以得到我们需要的结果。在 Aloudata CAN 平台上，我们只需要通过简单的几步操作，就能够定义并计算出这种复杂的指标。这就是产品的工作流程。

图 5：Aloudata CAN 通过简单操作即可实现复杂指标的定义与计算

那么上述定义能力在技术侧是通过怎样的机制来实现的呢？

首先是标准化和要素化的指标配置，实现了指标的高效定义和规范治理，确保指标能够得到统一的命名校验，避免存在同名不同义或同义不同名的问题；

Aloudata CAN 具有基于数据模型的标准化能力，用户可以通过配置化模板来定义指标，无需编写复杂的 SQL 语句，形成统一的数据语义层。这种方法的优势在于提高了指标分析和定义的灵活性，以及实现了维度的下钻分析；

Aloudata CAN 还支持统一指标要素，其中包括原子指标、多层时间限定、业务限定、衍生指标和指标维度化。这意味着用户可以实现多层的时间限定，对业务进行筛选，进行衍生分析，以及对维度进行指标化，从而完成指标定义。通过这一设定，用户只需选择派生指标所引用的原子指标、时间限定、业务限定以及衍生方式，就能够实现派生指标的定义。

这些能力使 Aloudata CAN 在指标定义方面具有强大的灵活性与多样性。

图 6：Aloudata CAN 基于数据模型的标准化指标定义

其次是指标函数系统的设计。要实现灵活多样的指标计算，我们首先需要建立一个完备而灵活的函数体系。

首先，在 Aloudata CAN 的指标平台中，我们定义了通用基础函数，包括文本函数、数学函数、日期函数等常见函数；

其次，针对分析场景，我们定义了大量预聚合函数、调节函数和快速计算函数。举例来说，如果要计算订单量的周同比，我们只需使用 "SAME PERIOD" 函数，对订单表的订单 ID 进行计数，并按照 "WEEK" 进行同比计算；

此外，我们还设计了窗口函数，如排名、累计、位移和滑动，这些函数在开窗计算中尤其有用，使得分析更加灵活。有了这些函数体系，我们就能够非常灵活地进行开窗计算，比如只需使用 "COUNT" 函数就可以计算出累计订单量。

除了这些，我们还设计了其他通用的聚合逻辑运算符等相关的函数。因此，指标体系中的函数体系是我们的第二项重要能力。

图 7：Aloudata CAN 基于函数体系灵活进行指标定义

第三个能力是基于多层聚合查询依赖的指标计算。以刚才的例子为例，计算近 7 天的消费金额需要逐步向上进行计算。

首先，我们需要定义一个节点（Node），即第一个计算节点，用于按用户层级计算累计订单金额，即订单表和用户表的关联，并求出累计订单金额；

接着，基于第一个节点，我们可以计算出用户成为 VIP 的日期，只需要使用聚合函数和筛选条件，如用户的累计消费金额大于 20,000；

然后在筛选后的数据上形成一个宽表，其中仅包含 VIP 用户相关的数据。最后，基于这份数据，我们计算出 VIP 用户近 7 天的消费数据。

值得注意的是，在每个节点中，其逻辑都与 SQL 强映射。举例来说，我们使用的 Groups、Agg、Filter 和 Source Table 等概念，对于熟悉 SQL 的人来说，这些都是常见的操作。

图 8：Aloudata CAN 基于多层次、多聚合的查询依赖构建

在处理数据时，我们会将所有需要的元素集中在一个 Node 中，然后将其抽象成独立的 Item。每个 Item 又会对应到 SQL 语句中的一个子句（Clause），例如包含 "SELECT"、"FROM"、"WHERE"、"GROUP BY"、"HAVING"、"ORDER BY" 和 "LIMIT" 等关键字的子句。通过这些子句，我们最终会形成一条完整的 SQL 语句。

图 9：Aloudata CAN 基于指标要素构建查询 SQL

可能有人会担心，如果将整个处理流程拆分成多个步骤并转换成一条 SQL 语句，那么这条语句可能会变得复杂，查询性能也可能受到影响。为了优化这种多步骤、多层级的数据加载过程，并生成高效的 SQL 语句，我们通常会采取以下三种性能优化策略：

首先，我们会根据指标平台设置的查询策略和基于规则的优化器（RBO，Rule-Based Optimizer）来优化 SQL 语句，以生成高性能的查询；

其次，我们会使用内存计算引擎来提高查询效率；

最后，我们会利用物化视图技术来加速整个查询过程。

具体来说，优化流程的第一步是将指标的定义转化为 RelNode，然后基于 RelNode 应用一系列的优化规则，例如模型关联关系下推、同层或多层 AGG 的合并，以及日期范围的裁减或筛选；

接下来，对经过规则优化的 RelNode 生成 Optimized Node，然后将其转换为 Calcite RelNode；

随后，基于 RBO 的优化规则对 RelNode 进行优化，如列裁剪、合并下推和子查询裁减。经过这些规则的优化后，形成了优化后的 Calcite RelNode，然后将其转换为一条 SQL 语句。

图 10：Aloudata CAN 基于指标定义以及 RBO 规则进行 SQL 优化

内存计算引擎是我们自行研发的核心模块，旨在提升指标场景下的查询效率。该引擎主要由三部分组成。

首先，针对用户的输入（例如公式和函数体系），我们首先会利用内存计算分析器评估指标的复杂度，包括指标数量、涉及的表数量以及具体的计算逻辑；

其次，基于 RBO 进行任务上下游节点的拆分。

第三，基于 CBO（Cost-Based Optimizer）进行维度表和事实表的情况分析，包括表的大小、行数以及历史执行成本等信息，然后构建任务执行的 DAG（Directed Acyclic Graph）任务图。这个 DAG 任务图将转化为具体的执行计算的任务图；

接下来，内存计算引擎将进行任务路由，负责将计算任务分发到多台机器，并处理任务状态的执行以及失败重试机制。

最后，引擎将实现各种算子的计算，包括 AGG 算子、JOIN 算子、GROUPBY 算子、SORT 算子等，以提高整个计算过程的效率。

图 11：Aloudata CAN 通过内存计算引擎提升查询效率

总结起来，Aloudata CAN 指标平台的核心理念是 “指标要素化” 的抽象，即从中提炼出有限的原子指标。因为原子指标通常并不多，但我们期望它们的派生指标具有很高的灵活性和扩展性。

因此，我们的指标定义方法应该具有抽象性，包括语义模型、原子指标、维度和派生。

这一方法能够实现对复杂指标的定义，例如基于时间智能函数的指标（如近 30 天的累计下单人数和同环比），基于 LOD （Level of Detail）窗口的指标（如本年至今年月的均值和最大值、店铺销量排名）；跨事实转化的指标（如同期群内的留存率和复购率、领券后的开卡率）。这些派生指标的核心都依赖于原子指标。

原子指标又支持三种类型：可累加指标，即可在任意维度下进行累加；半累加指标，在某些场景下可累加，而在另一些场景下则不可累加；不可累加指标，即在任意维度下都不可累加。

除此之外，还存在许多其他场景，都可以利用这一模型和方法进行定义。

指标平台的核心目标是实现指标的普适性，让用户易于理解，并让企业能够有效管理和充分利用这些指标。

首先，关键在于确保口径一致性，解决同名异义或异名同义指标的管理问题；

其次，需要缩短指标开发周期，实现分钟级指标开发；

进一步降低指标沟通成本，使业务语义在平台中得到统一沉淀，并展现指标加工和变更历史；

此外，指标应能够通过 API、JDBC 等形式，在多样的场景中进行消费。

自动化指标平台的核心优势主要体现在强大的指标定义能力、指标的自动化生产以及指标分析的灵活性。

这三大优势需要有一个整体的运行机制，从企业数据源到数据存储和计算，再到模型和指标的定义，以及分析，通过这四个步骤提供统一的服务化，包括 API、GraphQL、JDBC、ODBC、SDK 等，以实现不同场景下指标的消费。

对于 Aloudata CAN 指标平台的未来规划和展望，主要包括以下三个方面。

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

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

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

这些规划和扩展将提升 Aloudata CAN 指标平台在定义、查询和交互方面的能力，以满足未来需求。

图 12：Aloudata CAN 第三代指标平台未来规划与展望

那么最后的话就是用一句话来对 Aloudata CAN 指标平台来做一个总结：当风吹叶动，山河皆随之摇。

这句话有两层含义，企业里有大量的指标，每一个指标可能展现的价值是微观的。但假若第一个、第二个、第三个……指标都出现问题，这些指标之间相互联动，长此以往，会导致整个企业指标体系崩溃；

其次，对于复杂指标体系的定义，在系统层面需要依赖完善的技术框架支持。针对复杂指标，关键在于逐步叠加，无论多么复杂的指标，通过多层计算和多步骤都可以实现定义。

以上就是今晚要分享的内容。

接下来我们预告一下下一期的 “NoETL 公开课”直播活动， 4 月 7 号晚上 7 点，我会给大家介绍 Aloudata CAN 指标平台的物化加速技术。物化加速解决的的核心问题在于，当企业面临海量数据（例如百亿级别）、复杂模型（涉及数十甚至上百张表的星型或雪花模型）以及复杂指标定义时，我们是否有一种方法能够实现指标的秒级甚至毫秒级响应？

欢迎大家前往视频号预约观看。

看完这篇文章，您是否对第三代指标平台 Aloudata CAN 强大的指标定义和计算能力产生了更多好奇，是否提出了新的疑问。下方是在用户交流过程中出现的高频问题，我们整理为了 Q&A，尝试为您解答。

Q1：聚合或复杂计算的算力基础怎么估算？

Aloudata CAN 会结合查询数据量、聚合计算层数、以及每层统聚合计算的分组维度组合基数、计算函数类型来评估单次计算需要消耗的算力。整体指标平台的算力基础需要根据企业的数据表数量、单表数据量、查询并发等来进行估算。

Q2：复杂计算的指标能支持排序吗？

支持。

Q3：存算引擎是 Hadoop 吗？

可以是 Hadoop，取决于企业已有的基础设施以及基于基础设施的复用性来决定。

Q4：Aloudata CAN 和其他指标平台相比在指标平台定义能力上有什么差别？

• 对复杂指标的支持度更全面。如在原子指标，可以定义普通聚合以及半累加、不可累加、可累加等。在派生衍生方面，可以支持多种不同的衍生方式。在时间限定方面，支持不同的形式进行自定义，支持多层时间粒度多次聚合。

• 在性能方面，所有类型的指标均可被加速，包括上述的多层聚合的复杂指标，都可被加速，保证查询性能。

Q5：为何定义为第三代？

• 第一代指标平台：以指标口径登记和管理为主，这种方式下指标的管和用是分离的，管和指标研发也是分离的。

• 第二代指标平台：依赖 IT 进行大宽表的研发，这种方式下指标的管和用是一体的，但是管和指标研发是分离的。

• 第三代指标平台：NoETL 自动化的指标平台，管、用、指标研发是一体的。利用指标语义层取代了传统的汇总层，从而实现应用层 ETL 自动化。系统能够自动执行数据加工与查询加速，以适应不同的性能场景。由此，数据资产能够得到有效沉淀，并可依据业务场景来隔离资产消费。在该平台上，我们仅需导入公共层明细表，基于业务语义模型定义原子指标、派生指标及复合指标，然后在最终业务中以指标形式进行数据消费。

Q6：是基于 cube 的模型吗、和 kylin 类似吗？

Aloudata CAN 的语义模型只需要建立数据集和数据集的关系，并基于该关系来定义维度和指标，查询时基于该模型来动态翻译 SQL 进行执行，无需构建大宽表。Kylin 的 cube 模型用来做加速，而 Aloudata CAN 的指标加速能力支持更全面，包括宽表加速，cube 加速，和多层聚合的加速等等，更加面向分析场景以及会综合考虑指标的查询量、数据量、层次依赖等等。

Q7：这些逻辑都是比较简单的聚合计算。有没有能够基于源头业务系统例如 ERP、MES、CRM 这些数据库里源头的表，自动计算的方法？

语义模型可以直接连接源头中的表，基于源头表进行关系的定义，系统会基于关系来创建虚拟的逻辑模型用于指标定义和计算。指标计算支持多步骤、多层级、多时间粒度下的聚合、开窗计算，支持指标转维度和筛选。

Q8：性能怎么保障呢？目前客户实际场景中的性能情况大概是什么样的？

系统会基于三方面来进行性能保障。第一方面是生成计算性能优的 SQL 语句，第二方面是通过内存计算引擎将一部分计算在服务端的内存中完成，第三方面是通过构建物化加速方案来实现预聚合。在客户的实际场景中， 50 亿数据在 50 个并发情况下，查询耗时小于 500 毫秒。

Q9：语义模型具体是什么内容？

具体包括模型要使用的数据集、关联关系（1:N），系统基于这三方面的内容构建逻辑的语义模型，用于后续的指标定义和分析，指标定义和分析可根据关系来跨数据集进行定义。

Q10：基于多业务过程的事实表计算指标，筛选条件是动态的情况下，有解决方案吗？

可以先使用系统提供的函数体系来定义成维度，也可以将指标转为维度，然后基于维度的值来做筛选。指标在计算的时候，会优先计算出维度值，再基于维度值计算指标值来满足动态的条件。

Q11：1 号注册用户 T+7 日的购买转化率，应该怎么计算？

产品提供行间偏移类型的指标定义、指标转维度和筛选能力，以及复合函数，可以定义出来，直接进行计算。

Q12：累计或者全量类的指标的时间周期怎么定义？

时间周期有多种形式，如历史至今、本年至今、期初期末等等，系统提供多种方式来满足时间周期的定义，并且用户可以自定义时间周期用来计算。

Q13：复杂指标由多个原子指标做四则运算得来，那这个复杂指标是能支持排序的吗 是在哪一层算的呀？

支持排序。在哪一层计算取决于实际的计算数据量和计算算子，聚合计算在底层 MPP 计算引擎进行排序，当数据量小时，四则运算可以在内存计算引擎中计算。

Q14：轻量化，最小规模的方案是怎么样的？

目前通用的部署方案是 24C 的服务器，可以结合企业具体的数据规模以及并发数量进行评估。

Q15：指标与模型的映射关联是通过多模型的自由组合，还是大宽表类的模型？

多模型的自由组合。

Q16：原子指标、派生指标、复合指标，与 Data Cube 的关系？与物化视图的关系？

物化视图会基于指标的具体计算逻辑来构建。在 Aloudata CAN 上构建好指标后，可根据实际的查询性能需求来创建对应的加速方案，并且考虑物化视图的复用性。

Q17：数据模型与指标模型的关系？

数据模型是数仓中的分层模型，指标模型是基于业务分析场景来构建的模型，面向指标构建场景和分析场景。

点击此处 访问官网，了解更多信息。欢迎留言、反馈、分享，期待与您交流。