近几年，指标平台这一概念愈发受到关注，去年以来尤甚。究其原因，主要是随着数字化转型深入开展，企业的数据需求发生了变化。由最初的面向高层的数字化管理，转变为现在针对前线业务人员的数智化运营。在这一转型过程中，我们注意到许多企业渴求运用数据进行分析和洞察，借此寻找新的增长空间。在这个阶段，数据分析的灵活性与实时性尤为关键。

另外，所有大型企业都在讨论数据民主化议题。数据民主化的关键在于确保基层业务人员能够充分获取和利用数据，而对于 IT 团队、CIO 和 CDO 来讲，数据的准确性和标准化则构成了数据民主化的坚实基础。缺乏此基石，数据民主化不仅无法实现，甚至可能为企业带来更深层次的问题。在数据民主化的推进过程中，管理层、业务侧以及 IT 侧均面临各自挑战，包括数据烟囱、信息孤岛以及指标定义不一致等问题。我们观察到，面对数据需求的演变，企业通常采取两种响应模式：一种是数仓 ETL 驱动模式，一种是 BI 驱动模式。

所谓 ETL 驱动模式，其核心是由 ETL 工程师负责响应业务需求。在业务部门提出需求后，ETL 工程师会根据这些需求，在数据仓库中开发表模型，并构建各类汇总表及宽表。这种模式的优势在于，如若企业的数据仓库建设得当，大家都按照一定的管理规范开发，便能实现集中化的数据管理与开发。然而，这样的模式也存在一些弊端：

• 开发响应速度迟缓，需要等待 ETL 工程排期；

• 在满足不同业务需求时，不同的 ETL 工程师可能会针对同一指标采用不同加工口径，导致数据结果的不一致；

• 所产出的报表是静态的，难以灵活应对业务需求的变更。

为了应对上述挑战，一些企业转向了 BI 驱动模式。

在这种模式下，分析师和业务人员可以自助完成分析，通过 BI 工具的 ETL 工具或者自定义SQL，创建大量个性化的数据集。这一做法的优点是反应迅速，无须依赖 IT 排期开发，用户可以独立进行数据处理和分析。然而，此模式同样存在诸多问题：

• 不同数据集的指标口径混乱。由于指标分散在不同的数据集中，缺乏统一规范，导致业务逻辑在多个数据集间缺乏一致性。

• 指标难以复用。特定指标往往仅在某一报表或 BI 工具中存在，这限制了指标在不同 BI 工具或报表之间的共享能力。

• 数据治理成本高，维护难度大。分析师和业务人员仅关注于特定业务场景下的数据处理，从而增加了 IT 团队和数据平台部门在数据治理上的难度及成本。

如何既能满足响应速度又能确保数据有序？构建一个统一的指标平台是最优解。

指标平台能够沉淀统一的指标语义，并实现指标的管理与研发一体化。通过这一平台，各个业务团队可以借助统一的指标语言进行交流，从而减少了之前业务团队、分析师团队与 ETL 工程师之间的沟通误解。所谓“车同轨，书同文”，统一的语言有助于消除理解上的偏差。

此外，指标平台也能弥合 IT 部门与业务部门之间的鸿沟。业务化的表达方式简化了沟通过程，业务人员不必再深究数据库表和字段的具体细节，只需理解指标本身即可。因此，指标平台成为平衡指标一致性和分析灵活性的理想选择。我们看到很多企业都希望通过建设指标平台，来达成快速响应与规范性的平衡。在这个过程中，指标平台也经历了三代的演变。

》第一代指标平台

第一代指标平台的核心任务是从传统的 Excel 和文档维护转向指标登记与管理，旨在将线下的 Excel 数据实现系统化、在线化以及信息化。然而，我们发现该代指标平台未能克服研发与管理的割裂问题。指标研发工作依旧在数仓进行，而指标管理平台只负责登记结果。业务用户仍需关注具体的表和字段，且以单一表格、字段的方式进行数据消费。因此，第一代指标平台的问题可概括为管用分离以及管研分离，物理实现与业务含义仍存在断裂，因此无法保证指标口径的统一。

》第二代指标平台

鉴于此，市场上出现了多家独立的指标平台供应商，这些我们称之为第二代指标平台。第二代指标平台实现了在平台上统一管理指标，并确保最终下游业务场景采用指标形式进行消费。由此，指标的管理与使用达到了一体化，相比之前有了显著进步。

然而，不少企业采用第二代指标平台后，在落地过程中遇到了挑战：在真实的企业环境里，许多指标的生成并非仅通过 SUM、COUNT 等简单函数完成，它们可能涉及复杂的计算，或需处理表与表之间的复杂关联。在真实的场景中，第二代指标平台通常仅能覆盖大约 20% 的指标定义与开发建设需求，大多数指标仍然要回到数仓加工，未能实现指标管理与指标研发的一体化。

》第三代指标平台

为彻底解决这一矛盾，我们发展到了第三代指标平台。第三代指标平台实现了指标的定义、研发、管理与消费在同一平台的完全整合。我们称之为 NoETL 的自动化指标平台。

NoETL 的自动化指标平台具备哪些特点？一代、二代指标平台的数据分析流程，往往涉及将业务系统数据导入，建立贴源层，随后开展数据清洗及加工，最后构建出包括维度表与事实表在内的公共层数据资产。为满足多变的需求，这一过程可能还需对大量的集市层或 DWS 层表进行打宽或汇总，并将其中的指标纳入指标平台中管理。

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

Aloudata CAN 自动化指标平台真实承载了前述的第三代理念，实现了集市层的 NoETL，大幅简化了企业数仓架构与 ETL 作业量。该平台的核心功能涵盖了指标的定义与管理，及数据模型、指标、维度以及物化加速的管理等方面。

在指标应用方面，平台提供了指标目录，便于用户轻松地查找和理解指标资产；其他功能包括看板展示、指标预警、归因分析等。Aloudata CAN 通过标准化和要素化配置指标，实现了指标的高效定义和规范治理，确保指标能够得到统一的命名校验，避免存在同名不同义或同义不同名的问题。此外，通过配置化和标准化的模板，形成统一的企业级指标库，提供字段级的血缘追踪和指标的多版本管理，让指标加工链路更清晰，并确保指标变更的历史记录可以被清楚地追溯。完成指标定义后，可以通过标准 API 和 JDBC 接口，将指标输出至下游 BI 工具、AI 应用场景及自主研发的业务系统中。这意味着，一个指标一经定义，便可跨平台广泛应用。

第三代指标平台在核心能力上相较第二代实现了两大突破：语义化与自动化。

在语义化方面，平台强化了指标定义的能力，用户可以直接在平台内沉淀指标的计算逻辑和语义，通过明细数据即可完成指标的定义，无需返回数仓进行加工，实现做“轻”数仓。这一能力保证了语义资产能在平台上沉淀，并且实现了数据加工与消费的隔离，更有效地支持了业务场景的数据需求。但是面对庞大的企业数据量，平台如何满足查询性能的业务需求？这就是第二点“自动化”所要解决的关键点。

Aloudata CAN 内置高效计算引擎，结合自研的物化策略优化，Aloudata CAN 指标平台不再依赖 IT 人员，系统自动代持宽表和汇总表的开发，并且能够自行实现物理链路的编排、物化以及无效数据的回收。

在数据语义化方面，首先是基于语义化的数据模型实现标准的指标定义。与传统的一代和二代指标平台只能基于单表加工指标不同，Aloudata CAN 通过经典的星型或雪花模型，可以在事实表和维度表之间建立关联关系，实现跨表的指标定义，并且在分析时能够进行灵活的维度分析。其次，在模型的基础之上，我们也抽象了四大的指标要素。基于这样的指标要素，其背后其实都有相应的一个物理实现的逻辑，所以能够做到标准化的指标的定义。最后，基于指标要素组合生成派生指标是非常重要的一环。通过将原子指标、时间限定、业务筛选等要素结合起来，再加上一些衍生方式如占比、排名等，可以生成更加丰富和有价值的派生指标。

通过标准化的要素组合，系统可以自动创建计算查询的 SQL，然后基于这些自动生成的查询 SQL，系统可以自动进行物化加速，从而提升指标开发的效率。

在基于语义模型定义指标的基础上，建立强大的指标定义函数能力，并将其封装为标准化的配置化模板。这样的函数能力可以被抽象成五大类，是一个复杂度逐步递增的过程。

• 最简单的指标定义方式是基于单张物理表来定义指标，比如交易金额这类指标。在我们服务的企业中，这种指标可能占到大约 20% 左右的比例。

• 第二类情况是，为了减少在数据仓库中的工作量，我们可能需要跨表定义指标。例如，在某些指标上，我们可能需要添加业务修饰词，比如金卡会员的交易金额。前两类指标可能占比 50% 左右。

• 第三类，比如一些营销活动场景中，业务需要我们去提供一些指标标签化限定的指标，如“近 30 天领取消费券的用户的订单金额”。前三类占比大概达到了 70%。

• 第四种情况是，在数据分析中，我们可能需要进行多次聚合，而不仅仅是简单的 SUM 和 COUNT。举个实际案例，比如近一年的每月日均 AUM 的最大值需要进行三次聚合计算：首先对 AUM 进行求和，然后基于每月的 AUM 计算月度平均值作为第二次聚合，最后在十二个月的月度平均值中找到最大值作为第三次聚合。我们通过配置化的方式来支持这些多次聚合的指标，而不需要写 SQL。此外，在分析场景中经常会用到比较、排名、占比等衍生指标，我们也会将其抽象成模板。前四类指标可能占到了 90%。

• 最后，企业还可能涉及一些更加复杂的指标，比如留存率等。针对这类指标，我们会提供自定义函数的方式来支持其定义。这些占比在 10% 左右的超复杂指标也无需进行复杂的 ETL 开发，而是可以通过我们的指标平台以自定义函数的方式来定义。

这里我们举两个具体的例子。

• 第一，多次聚合类指标。比如门店月均订单量的最大值，我们可以先按时间维度计算每个月的平均值，然后通过门店维度找出最大值。这种衍生的方式可以实现多次聚合，而且整个过程无需手动编写代码或提前在数据仓库中准备好，也不需要 ETL 书写表达式。这是第一类情况的一个具体示例。

• 第二，针对复杂的衍生方式，比如排名，我们也提供了相应的配置化支持。举个例子，如果要查看门店在大区内的销售订单量排名，我们可以指定排名维度为门店订单量，在特定范围内进行排名。例如，在地区范围内进行排名，而用户也可以根据需要细分到城市级别。比如，可以查看华东地区上海市门店的订单量排名情况。排名方法可以通过降序等方式进行设定。这种复杂指标的定义通过配置化方式实现，无需编写循环加工或复杂函数，能够覆盖 80% 到 90% 的分析场景。

指标可以定义之后，还要保证查询性能，其关键在于第二个核心技术能力——自动化。在自动化方面，在自动化方面，关键是即时计算和物化计算。在即时计算的引擎选择上，我们选择了StarRocks 等新一代查询引擎作为执行引擎，因为 StarRocks 在大规模即时计算、跨表关联查询等方面具有突出的能力。

在物化计算上，我们自研了物化加速策略引擎。我们的物化加速引擎会根据用户查询需求来进行决策。它类似于一个协调者或 AI 大脑，指导何时创建物化视图。在我们的产品中，用户可以手动指定需求，也可以通过智能识别用户常用的指标和维度来提示创建物化视图。

物化视图的加速策略有以下四类：

• 基于人工指定或用户查询行为的数据采集。通过人工指定或分析用户查询行为来采集原始数据信息，确定常规需要结合的指标和维度，以及哪些维度表和事实表经常需要关联。可以通过在数据中引入一些冗余维度，打宽形成宽表，以加速数据分析的效率。

• 为了确保数据查询的最佳体验，还可以为不同的查询需求建立不同的物化表，但为了避免此类物化表的无序膨胀，需要对相同事实和相同实体的物化需求进行合并，在成本与性能之间实现自动平衡。

• 在实际的分析场景中，可能需要分析不同时间粒度的数据，如天、月、年等。因此，在构建物化视图的过程中，需要考虑长周期和短周期的依赖关系，比如，可以在已有天的物化视图的基础上构建月份的物化视图，以提高数据分析的效率。

• 针对用户可能选择的维度组合，如 ABCD 维度，去查看近一天的订单笔数，可以自动进行上卷的聚合计算。这样可以减少用户手动操作的复杂性，提高数据查询的便捷性和速度。

物化视图的加速策略主要是以上四类。在数仓中，作为资深的 ETL 专家，也可能会采取这样的方法。第三代指标平台正是实现了资深 ETL专家能力的自动化。如果成功建立了物化视图，当上游指标口径发生变更时，整个过程都将是系统自动化完成的。因此，一旦上游指标口径发生变更，系统可以自动识别出已建立的物化表结构。

一旦建立了物化表，系统可以自动识别哪些物化表需要对作业脚本进行变更，并自动执行数据回刷操作。整个过程都是自动化的。当然，如果没有建立物化表，在逻辑计算时，一旦指标逻辑发生变化，可以直接推送到下游系统，无需进行变更回刷处理。

总结一下，第三代指标平台在整体运作机制上大体上是有三步：第一步，基于语义化能力实现指标的规范化定义；第二步，在指标规范化定义的基础上，由于平台已经积累了指标计算逻辑，可以实现自动化的指标生产和变更回刷；第三步，基于规范化的指标，可以通过开放化的标准接口开放给下游消费。如果需要确保大数据量查询性能，需要进行自动物化与智能的查询加速。这构成了整个产品的运作机制。

对比二代和三代平台在核心能力方面的差异，主要有几点：

• 指标定义。第三代指标平台可以利用多表关联的语义模型定义复杂指标，并支持灵活的指标定义方式。

• 指标加工。第三代指标平台倡导使用数仓公共层或 DWS 的明细数据进行指标定义，系统代持应用层 ETL 开发与资产管理。

• 服务的灵活性。支持接口设计的灵活性，能够传递多个指标和维度。

• 指标分析。由于基于公共数据资产定义指标，可以实现任意维度的组合分析、下钻分析和指标归因分析，从而更早更本质地洞察数据与诊断原因。

基于前面所述的定义加工能力，我们可以实现同一个指标在不同维度上只需要定义一次，而无需在数据仓库中多次进行加工。这种能力使得指标的共享和复用程度非常高，真正实现了“管、研、用一体化”的目标，并确保了指标口径的百分之百一致性。

最后，我们来分享在金融行业的一个客户实践。客户在与我们合作之前面临两个主要问题：首先，客户存在总行和多家分行之间的协调问题。总行和分行有不同的 IT 部门负责满足业务需求，且总行和分行使用的 BI 工具也不同，导致可能存在指标不一致的情况。其次，这家股份制银行零售业务占比很大，零售业务部门对数据素养要求很高，希望通过数据做出决策。传统方式下，所有需求都需要向 IT 部门提出，响应周期长达两周以上。客户希望提升分析效率，快速满足业务需求。

通过我们的指标平台，现在总行和分行不再需要建立不同的数据集来满足各自需求，而是通过统一的指标语义层和指标平台来沉淀和使用统一的指标。这样一来，大量原本散落在各个 BI 工具中的指标口径可以被下沉到指标平台和指标语义层，实现指标口径的统一和复用。

另外，以前所有指标需求都需要业务部门提出，然后由 ETL 团队开发宽表和汇总表进行加工处理，数据量很大，可能达到百亿级或千亿级，需求响应周期很长。现在通过指标平台的自动化物化加速能力，只需定义好原子指标和派生指标，系统就能够自动进行物化加速处理。这使得原本需要排期等待两周以上的需求响应时间，变成了在小时级甚至分钟级就能够完成。业务部门可以快速从任意维度、任意粒度对指标进行分析，甚至获取明细数据，而无需再向 IT 部门提出需求等待排期。

Aloudata CAN 快问快答

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

1、Aloudata CAN 自动化指标平台和 BI 重合度很高，指标平台会替代 BI 吗？

指标平台与 BI 工具的核心差异在于：指标平台是指标统一管理、自动开发和开放应用的一体化工具，BI 工具侧重指标的可视化分析，所有指标都封闭在 BI 内部使用。

在 BI 工具中，指标散落在各个报表中，指标仍然是分布式管理，无法真正做到指标口径一致；同时，BI 工具中缺乏对指标的规范化管理，比如缺少指标的业务含义、指标血缘、指标口径变更记录等信息，数据标准混乱。

通过指标平台，将指标的业务语义与应用解耦，客户可以打造一个集团级的核心指标库，沉淀一个标准的「业务术语体系」来确保大家都在说同一种「语言」，通过核心指标库可以将过往在业务人员脑海中的业务知识实现线上化、体系化沉淀，能够清楚地知道集团沉淀了多少核心指标资产，每个子公司、每个业务板块有哪些核心指标资产等，帮助集团实现数据的更好流通与消费，充分发挥数据要素的价值。

同时，大应科技指标平台基于数据虚拟化理念自研的数据虚拟化引擎，可以实现指标定义与物理数据（业务）的解耦。客户可以通过数据编织技术实现「不搬家」的子公司数据拉通，基于拉通汇聚后的数据快速定义指标，并基于指标制作看板给领导和业务查看。通过“数据编织技术+集团核心指标库”，当领导或业务提出需求后，可以小时级响应需求，快速开发报表。

2、Aloudata CAN 如何和 BI 系统联动，可以详细介绍下吗？特别是 BI 都有自己的数据集，如何使用指标平台的指标？

BI 工具通过 JDBC 接口与指标平台实现对接。具体来说：

在指标平台上选择指标和维度，形成二维的分析视图变成 BI 工具所需数据集。

在BI工具中通过连接 MySQL 数据源，输入指标平台提供的端口地址信息进行连接。

连接完成后，即可在 BI 工具中看到指标平台生成的所有视图，然后在 BI 工具中进行可视化分析。

3、Aloudata CAN 可以完全替代数据开发（人）吗 有什么局限吗？

Aloudata CAN 第三代指标平台的核心价值之一是实现集市层的 NoETL，数据开发人员不需要做大量宽表与汇总表的开发，从原来人工变成系统自动化生产。Aloudata CAN 核心是降低数据开发人员面向消费场景的数据开发，面向公共层的数据资产沉淀仍然需要数据开发人员进行规范建模与开发。

4、请问 Aloudata CAN 的语义化是如何实现的？

语义层核心遵照 Headless BI 的理念，它是一种新型的商业智能架构，其核心思想是将数据的计算和数据的消费进行分离，将数据计算和数据的可视化进行分离。具体到指标场景，其核心设计思想是以指标管理驱动数据服务，实现了从技术语言到管理语言的抽象，对外提供统一的指标管理以及统一的指标服务能力，进而达到“一处定义、多处使用”的目标。

语义层核心的职责是基于指标平台上用户选定的维度、指标、筛选来进行计算，核心包括 SQL 组装、内存计算、查询加速等能力，并且提供 API 和 JDBC 方便与其他应用或者 BI 分析工具进行对接。

5、查询性能如何保证呢？比如 10 亿级别的表关联统计指标

Aloudata CAN 提供两种指标计算方式。第一种：即时计算。系统会根据底层计算引擎的特性和用户的查询行为，判断是否直接下推查询。比如当数据量不大且查询 SQL 不复杂的时候，直接即时计算。CAN 内置了 MPP 查询引擎，保障即时计算的查询性能。第二种：预计算，即自动物化加速，将指标结果落地存储。当数据量大且查询 SQL 复杂、并发度高的情况下，系统会自动物化加速进行预计算，将指标结果落地存储，用户查询时智能路由改写至物化结果进行查询。

传统模式下，预计算是通过 IT 开发大量的宽表与汇总表保障查询体验；基于 CAN 指标平台，通过自动物化加速来保障大数据量下的查询性能，类似于资深的 ETL 工程师自动进行性能优化，实现应用层 NoETL 。

CAN 集成 ETL 最佳数据工程实践的思想进行物化加速，具体物化策略如下：

• 第一步预打宽。CAN 指标平台将数仓的物理表通过逻辑方式映射成数据集，并建立数据集之间的关联关系，形成语义数据模型。在大数据量场景下，为减少即时计算的 Join 操作，会将常用维度的维表与事实表进行关联打宽操作，作为查询性能的兜底方案。

• 第二步预聚合。根据用户的物化加速需求，进行细粒度汇总计算，相同事实表相同实体维表合并计算，满足业务灵活分析场景的性能需求。

• 第三步聚合上卷。基于细粒度汇总表聚合上卷计算、长周期依赖短周期聚合计算等，以满足管理驾驶舱等固定报表场景的极致查询性能需求。

6、如果业务需求不明确，Aloudata CAN 需要什么样的数据来支撑业务分析呢?

建议引入公共层明细表进行指标定义，可以在业务需求不明确的情况下，保留分析的灵活性，支持业务从不同维度探索分析。

7、在指标平台中定义的指标所计算的值是每天存下来的吗？如果是的话，是以 key、vaule 的方式存下来的吗？

在指标平台上定义的指标分为两种计算方式，一种是即时计算，数据不做存储；另一种是物化加速计算，对于物化加速的指标数值，目前是以列存方式进行存储的

8、指标跟算力的配比是多少？

指标跟算力没有一个相关性的配比，算力的大小取决于数据量和并发。

9、Aloudata CAN 的指标计算都是 sql 吗？

下发给 StarRocks 进行查询的指标计算都是 SQL。

10、Aloudata CAN 是否对 StarRocks 的硬件资源有要求?

StarRocks 的硬件最好是 x86 架构，不要是 ARM 架构，因为 ARM 架构不支持 SIMD 指令集，计算性能会比 x86 慢。

11、Aloudata CAN 用的 StarRocks 版本是多少？

只要是 StarRocks 2.5 以上的版本都可以使用。

👉 如需了解 Aloudata 产品与 Data Fabric 最佳实践，请联系我们。

👉 观看视频，了解 Aloudata AIR 更多功能。