一、ETL 的原罪和 NoETL 的全新思路
1. 应对数智化分析需求，反范式 ETL 加工不堪重负
数字化转型多年，现在很多业务人员都依赖数据来做日常决策。传统的方式是业务提需求给 IT，IT 会根据每个特定需求开发定制化的宽表和汇总表，再做成 BI 工具里的报表。在这个过程中，会有很多反范式的 ETL 加工，使得整个数仓的数据管道越来越长、越来越深，企业数据治理的难度也越来越大。
2. ETL 工程陷入“效率、质量、成本”的不可能三角
反范式的加工给企业带来高成本、低质量、低效率的问题。
- 高成本：IT 接到不同业务部门不同业务人员提出的需求，为了快速响应业务的需求，直接开发数据集市层表，结果导致不同 IT 之间存在大量重复的宽表和汇总表建设，占用大量存储计算资源的消耗，带来高成本。
- 低效率：在原来传统的反范式 ETL 加工过程中，业务一开始提的需求是模糊化的，因为业务没有看到数据，也想不清楚。IT 开发完交付给业务的时候，业务发现开发的需求跟原本设想的不一样，于是就有了再改一个口径、再加一个字段等类似的需求。整个过程存在反复沟通，IT 需要排期，业务需要等待，所以，ETL 成了数字化分析过程中一个核心的瓶颈。
- 低质量：大量重复的宽表和汇总表开发会导致同一个指标分散在不同的报表里，进而可能出现不同报表里数据对不上的问题。比如，各个业务部门去向公司领导汇报的时候，每一个部门的绩效都完成得特别好，但是公司整体的绩效并不是那么好。真的是各个业务部门业绩完成得好，公司层面出了问题吗？可想而知，情况肯定不是这样的，应该是各业务部门的数据口径不一致，最后出现了在公司总体层面数据对不上的情况。
3. 如何将“效率、质量、成本”不可能的三角变为可能？
有没有什么办法能解决“效率、质量、成本”不可能三角的问题呢？整体来说，有两种思路：
第一个思路是不开发宽表汇总表。既然“不可能三角”的原罪在于人工的大量的反范式加工，那能不能不进行这样的加工呢？早期，数据量较小，这个模式是可行的，直接开发公共层的明细表提供给业务去消费，可以大幅减少不可能三角。然而在大数据量的情况下，不做宽表和汇总表的开发很难保证性能，因此这条路行不通。
第二个思路是将人工 ETL 方式变成 NoETL。原来“不可能三角”是人工做开发，那么能不能将人工的方式变成自动化的方式？这条路是可行的。
二、如何实现数仓应用层 NoETL
1. 应用层 NoETL 自动化的前提是指标语义的标准化沉淀
把人工变成自动化的前提是让机器和系统理解业务需要的指标的业务逻辑，即实现应用层 NoETL 自动化的前提是指标语义的标准化沉淀，也就是需要将业务指标体系以及指标的计算逻辑告诉系统。
从上图中可以看到，原来数仓是从贴源层到公共层再到集市层的开发，现在将集市层用指标语义层代替。这样，原来需要在集市层做大量的反范式的开发，现在只需要将业务的指标以及指标的计算逻辑通过配置化方式告诉系统即可，不需要做物理链路的开发实现。所以，要有指标语义标准化沉淀的过程。
2. 如何做到指标语义标准化沉淀
基于标准化语义，自动化生成反范式的宽表与汇总表。
- 首先，需要有星型模型、雪花模型等强大的模型能力。原来，在数仓里需要将维度表里的维度打宽到事实表里面生成新的宽表，或者是基于某些维度做轻粒度或重粒度的汇总加工。现在，只需要建立明细事实表和维度表之间的逻辑关联关系，无需物理打宽，保持模型的灵活性，支持灵活的跨表指标定义和灵活的维度下钻分析。
- 需要标准化指标定义的能力，能够把指标的计算逻辑通过标准化的方式定义出来。
有了指标标准化定义的能力和模型能力，反范式的宽表和汇总表的加工就可以实现系统自动了。系统可以自动将一个事实表和多个维度表的维度组合在一起，也可以实现多个事实表背后的不同指标和多个维度一起分析。业务人员不用关心多个指标到底来自于哪一张物理表，屏蔽了底层的技术概念，用户感受到的是指标和维度这样偏业务语言的概念。
原来传统的方式为什么做不到呢？要实现指标定义能力承载在指标平台上，要求平台具备强大的指标语义表达能力。如果平台没有很强大的语义表达能力，就需要在数仓或者BI 工具里写 SQL 开发来定义指标的计算逻辑。
怎么保证所有的指标定义都在平台上承载。
指标定义可分成四大类：
- 窗口计算函数，如证券行业中看资金净买入额在行业中的排名。
- 多层聚合嵌套，不是简单的一次聚合。比如，在求平均的基础之上，再去看最大值或者最小值。求近一年、月、日均 AUM 的最大值，需要进行三次聚合，第一次算出每一天 AUM，第二次算出一个月 AUM 的均值，第三次基于每个月的均值算出一年十二个月中月均/日均的最大值。类似这种多层聚合的嵌套，一千个人有一千种写法，系统很难判断如何表达，可以通过配置化的方式实现标准化模板化。
- 行间计算，比如近三十天的销售量。
- 模型计算，跨多个事实表和维表之间的计算。在活动中经常遇到的场景，是先把指标变成一个标签或者变成一个维度，再计算特定客群的表现。比如，近三十天领取消费券客户的购买金额。
除此之外，还有常规聚合类和日期函数等，通过将函数抽象封装成配置化的模板来支持复杂的指标计算，让技术能力不是很强的业务分析师或者业务人员无需写 SQL 也可以自助定义指标。原来面向业务场景的大量的反范式的宽表和汇总表一定需要 IT 开发，现在业务人员能够自主做数据准备，不需要有很强的技术能力。
指标定义转计算节点，支持复杂指标自动转成一个节点。
上图中展示了指标链路：先定义原子指标“销售额”，然后在原子指标的基础上定义派生指标“近 7 日销售额”，又在派生指标的基础上定义衍生指标“销售额占比”，在衍生指标的基础上定义复合指标“销售额占比去年同期的增长率”。整个指标定义链路很复杂，涉及从原子到派生到衍生到复合再到衍生的过程，通过语义层，可以将这个链路变成相对 SQL 来说非常简单的函数。
3. 指标语义+最佳数据工程实践，实现自动化指标生产
分成三个策略：
- 自动化数据编排。多个指标和多个维度放在一起分析，比如查看不同日期、不同品类的下单量和退款量，下单量和退款量可能来自于两个不同的事实表。自动化指标生产的时候会基于物理表的拆分逻辑，对不同的事实表进行拆分，保证数据产出的时效不受影响，同时不造成数据膨胀。自动化数据编排优化还遵循了数仓中的最佳的数据工程实践：冗余维度属性打宽；长周期依赖短周期；粗粒度依赖细粒度。
- 自动化代码生成。数据编排后，系统根据指标语义自动生成优化后的最佳 SQL 供计算引擎执行。
- 自动化变更回刷。上游的数据发生变更怎么去做自动的分析和回刷呢？首先，自动化感知上游的变更有两种方式，第一种是通过任务的 DAG 图自动获取上游的信息，实时进行数据回刷；第二种是通过定时任务的配置进行定期刷新。一旦上游数据发生了变更，系统会自动识别变更点及回刷范围，自动化进行变更回刷，以保证数据的准确性。
4. 自动化指标生产的核心能力
自动化指标生产的核心能力分为两层。
- 计算引擎层：通过内置 MPP 计算引擎或者利用企业自有的 MPP 引擎，所有的 SQL 查询都在查询引擎中进行，目前支持 StarRocks、Doris 等 MPP 查询引擎。
- 物化加速层：MPP 查询引擎之上是物化视图的构建策略和命中策略，类似物化加速策略大脑。支持通过人工物化或者智能物化两种策略，实现物化视图的构建，和指定指标与维度的物化加速。同时，基于用户查询行为，系统自动进行查询改写，通知 MPP 层的查询引擎直接查明细数据还是物化表，保证大数据量场景下的查询性能。
三、第三代指标平台的能力与价值
1. 第三代指标平台的能力
总结来说，应用层 NoETL 的核心是语义化和自动化两个能力。通过语义化提供任意复杂指标的配置化定义，通过自动化实现指标的定义即开发。如果没有性能问题，只要完成了语义化的定义，用户就可以直接消费数据了，这个过程叫做定义及服务。如果数据量比较大，系统会自动化进行宽表汇总表加工，来保证查询性能，这就是第三代指标平台，将原来 ETL 人工开发变成了 NoETL 的自动化开发。
2. 第三代指标平台的价值
Aloudata（大应科技）公司推出的第三代指标平台产品名为 Aloudata CAN，实现了 NoETL 的自动化生产。
指标从定义到开发到应用是一体化的，保证业务人员能够看懂。原来业务人员做分析的时候，面对的是数据集、物理表、字段这种偏技术的概念，现在面对的是指标和维度这些偏业务的概念，更容易理解。除了指标的业务含义外，还提供指标血缘，让业务能够清晰地了解指标的加工过程和口径。同时，如果指标口径发生了变更，平台会保存所有的指标版本，可以进行历史口径版本的对比。
对于承担数据管理职责的 IT 团队来讲，能够实现管得住。原来大量的指标逻辑是在数仓中由不同 IT 人员开发实现的，沟通协调比较复杂，需要花费很大的成本才能保证指标口径的一致性。现在，针对同样的指标进行不同维度的分析，只需要一次定义，就可以处处使用了。
同时，指标是基于公共层的明细数据生成的，保留了原来在公共层事实表和维度表的灵活性与丰富度，同一个指标能够支持多个维度下钻分析和任意维度的筛选组合，提供良好的用户体验。
第三代指标平台 Aloudata CAN 为业务带来的价值可以总结为两方面：
（1）基于 Aloudata CAN 实现数仓集市层 NoETL
指标语义层替换传统数仓中的集市层，通过指标语义层实现自动化集市层开发。
在质量方面做到百分之百的指标口径一致。因为所有指标语义都是通过标准化、配置化的模板实现的，通过原子化指标的组装，系统能够提供指标重复校验，方便知道指标的计算逻辑是否一样，规避了“同名不同义”、“同义不同名”等二义性问题。
在效率方面也得到了提升。原来指标的开发依赖于 IT 人员，一体化后，将指标的开发和定义能力交给业务人员去做，降低了 IT 与业务的沟通成本，提高了效率。
在成本方面做到了节约。原来反范式的加工方式导致大量重复的宽表和汇总表开发，现在指标语义层通过自动化的方式可以规避重复开发。比如原来集市层做了一百张宽表和汇总表，可能因为重复开发，实际上只需要开发八十张表；八十张表里面，六十张表可以直接查询无需物化，二十张表因为数据量比较大，系统可以自动化开发宽表和汇总表；又因为一开始 ETL 的时候不清楚业务想要什么，为避免因漏掉业务常用的维度而反复变更，会把冗余的维度放在事实表里面，造成字段利用率低。现在系统按需进行开发，在相同的二十张宽表和汇总表里面可以减少冗余字段的开发，大大节约计算和存储成本。
（2）Aloudata CAN，提供智能且灵活的洞察分析
上述是从“不可能三角”的视角来看价值，更偏向于管理层和 IT 方面。业务人员能感知到的则是分析的灵活性和指标数据的一致性。
原来做指标归因依赖数仓已经开发的表，会有维度的缺失。基于 Aloudata CAN 指标平台，只要是在公共层的维度表存在的维度，都可以用来做指标归因和下钻分析，使得业务人员能够找到指标波动背后的根本原因。
原来做自助探索分析的时候，希望增加一个视角来看数据，需要向 IT 提需求。现在通过 Aloudata CAN 指标平台，可以从任意的颗粒度和维度进行分析，甚至可以拿到背后的明细数据。
目前，有很多金融行业的头部客户都在尝试用大模型打造新的对话式的体验。原来通过 NL2SQL 的方式返回数据，存在数据精准度不够的问题，会有答非所问的情况出现。现在，基于 Aloudata CAN 指标平台，通过指标语义层加大模型能为企业对话式分析带来更为精准的体验。
四、第三代指标平台做轻数仓实践
助力某证券公司实现指标统一管理与复用。
该客户面临的挑战是：
- 指标口径不一致。原来，为了响应不同的业务需求，相同的指标有不同的开发链路，导致了指标口径的不一致。
- 排查耗时。因为缺少指标加工链路和指标血缘，排查和定位指标口径工作量会特别大，耗费大量的时间。
- 对业务来讲，灵活性不够，缺少分析所需要的各种维度。
通过 Aloudata CAN 指标能够解决这些问题。
- 指标规范管理，同一个指标只需要定义一次。
- 由业务人员定义派生指标。IT 只需要进行公共层事实表和维度表的数据模型开发，并进行最小颗粒度的原子指标定义。业务人员可以根据自己想要的各种场景，基于指标和维度自助地组装出自己想要的派生指标，减少了很多 IT 的开发工作。
在传统方式中，业务向 IT 提了三十个指标和二十个维度的分析需求，IT 在沟通过程中发现其中的五个指标和五个维度已经开发，只需要开发二十五个指标和十五个维度。IT 完成开发后，交给业务人员验收，业务人员发现指标和维度可能少了，需要反复沟通，一般这个过程至少要循环往复两到三轮。这样的模式下，从需求提出到交付验收需要两周的周期。
通过 Aloudata CAN 指标平台不断地沉淀已经定义好的指标和维度，IT 就能越做越轻。同样面对业务提出的三十个指标和二十个维度的分析需求，发现二十五个基础指标已经定义，而且基于基础指标的维度都已存在，就可以请业务通过拖拉拽进行自助分析了。针对原来没有进行基础指标定义的五个指标，双方要沟通指标口径定义，因为是原子指标，业务逻辑并不复杂，所以沟通过程也会很简单。而且，IT 定义完指标后，业务可以实时进行指标预览，业务人员能快速看到指标是否符合预期，并且可以切换不同的维度去看，如果符合预期，业务就可以验收并进行数据分析了。
传统的数仓基于反范式模式的开发，IT 越做越重，因为表越来越多，链路的依赖越来越长，问题排查也越来越难。基于指标语义层，数仓可以越做越轻，一旦做好原子指标的沉淀，就会越做越少，越做越轻松。分析效率有显著的提升，从原来的两周缩短到了两天。
对于整个行业来说，可以提升创新试错的效率。原来一轮试错可能要一个月，现在可能仅用一周即可完成。
