CDO 解决 ETL“不可能三角”的新思路：做“轻”数仓

以 NoETL 思路破解效率、质量、成本的不可能三角

随着企业数字化转型的不断推进，不仅是管理层，企业中各个职能都需要通过数据来辅助决策与日常工作。各个业务部门的数据分析又通常会高度依赖 ETL 团队去开发大量面向业务服务管理（BSM）的报表，以及为了保障查询性能开发的许多宽表和汇总表。然而，这种反范式的 ETL 加工会导致数据仓库中的数据链条变得越来越长、越来越复杂，从而使得整个 ETL 作业难以持续。

这种不可持续，其本质就是成本、效率和质量三者无法兼顾的困境。

反范式的 ETL 作业会导致面向不同业务场景出现大量重复开发，一方面造成了大量的存储和计算成本浪费，另一方面增加了 ETL 链路的运维成本。

其次，传统开发方式难以满足快速、灵活的分析需求。比如管理层可能会要求在管理驾驶舱中增加一个维度或者切换一个视角，ETL 工程师就必须返回数仓进行指标字段和维度的添加，响应速度非常慢，并且很难对管理层解释，为什么增加一个字段需要花费一两天的时间。

另外，越来越多的企业发现，特别是一些拥有大量 BI 报表和 BI 看板的企业，不同报表之间存在口径不一致的问题。

既然传统的 ETL 作业不可持续，那么是否存在一个 NoETL 的方案可以打破成本、效率、质量这组不可能三角呢？

有两种可能性。

一种是不开发宽表和汇总表，仅将数据仓库做到公共层的明细数据。然而，在大数据量的时代，许多企业的数据规模都是上亿的甚至达到几十亿的规模，甚至某个表的规模就可能达到百亿千亿。在这种情况下，不开发宽表和汇总表会导致查询性能无法保障。因此，这个方案不可行。

另一个方案是将人工开发转变为自动化开发。这是因为人工开发需要保证不同需求的开发作业不重复和口径一致，背后的管理成本非常高。通过自动化，系统会知道一个指标是否已经加工过。这样，第二个机器人进行加工时就不会存在重复加工的情况。因此，将人工开发转变为自动化是可行的。关键在于如何真正实现人工向自动化的转变。

实现自动化的前提是系统需要理解指标背后的业务语义，因此需要进行指标语义的标准化沉淀。例如，需要告诉系统及机器人这个指标的业务加工逻辑是什么，因为机器人无法理解每个企业内部指标特定的业务逻辑。

这些标准的业务语义通过表与表之间的关联关系来承载，这些关联关系通常在传统维度建模中被称为经典的星形模型和雪花模型，它们描述了事实表和维度表之间的关联关系。

针对数仓中表与表之间的关联关系，具体到每一个指标的业务逻辑，都可以被抽象成一些标准化的要素，让我们可以像搭积木一样抽象并封装每一个指标的业务逻辑。这样就可以帮助系统理解和应用这些业务逻辑，实现对指标加工的自动化处理。

通过建立统一的指标口径和数据模型，指标平台能自动化实现宽表和汇总表的生成，从而实现从人工向系统自动化的转变。但这需要两个条件：

首先，在实际业务场景中，很多指标并不仅仅是通过简单的求和或求平均等方式定义的。因此，指标平台需要能够实现任意复杂指标的业务意义的呈现，而无需返回数仓写 SQL 开发。这也将指标资产的沉淀与面向业务场景的指标开发进行有效隔离，实现了轻数仓的理念。

其次，即使指标平台可以承载指标语义，还需要保证计算与查询性能。这就涉及到实现 NoETL 的第二个能力，即自动化指标开发的能力。在系统理解了指标的业务语义之后，要自动将这样的业务语义转化成系统可执行的 SQL，再基于用户消费场景的需求，自动构建类似于预计算的物化视图。类似于传统数据仓库中人工开发的宽表和汇总表。当用户的查询需求涉及大数据量或复杂查询时，系统会直接推送到预计算的物化表进行查询，类似于查询宽表或汇总表；而对于数据量较小的情况，系统可能会直接查询底层的明细数据。

因此，实现应用层 NoETL 的两个核心能力分别是语义化和自动化，即强大的指标定义能力和自动化的指标开发能力，将这两个能力整合在一起的解决方案产品我们叫做第三代指标平台。传统的指标平台通常包含指标字典或指标目录模块，但这些传统的指标平台高度依赖 ETL 在数据仓库中进行应用层表的开发。而第三代指标平台则将这种依赖 ETL 开发应用层逻辑的模式转变为了 NoETL 自动化，进而帮助企业实现了轻数仓的效果。

第三代指标平台重塑数据消费与供给

Aloudata CAN 就是这样一个 NoETL 自动化的第三代指标平台。对企业而言，这样的产品能带来什么效果呢？

我们先来看数据消费侧的变化。

首先，对于业务人员来说，他们能够更容易理解指标的含义。在以往，当在 BI 报表中看到一个指标时，业务人员通常不清楚该指标背后的计算逻辑，需要咨询分析师或者 ETL 开发人员了解该指标是如何计算的。而通过 Aloudata CAN，业务人员能清楚地了解每个指标的计算逻辑和业务逻辑。这是第一个方面。

以往我们分析时通常是以数据集、物理表和字段为中心进行消费。以物理表为中心存在一个问题，就是必须在事前知道要从哪些维度对哪些指标进行分析。

比如，如果我需要分析 ABC 三个指标，而这些指标来自不同的事实表，如果我没有将这三个指标放在同一张表中，我就无法将它们配合成可视化的图表进行分析。而现在以指标为中心的模式则能实现同一个指标从不同维度进行下钻，同一个维度能够串起来分析多个指标，比如，对于一个机构，可以从存款、贷款、代发等角度进行多维分析。传统数仓开发模式还有另外一个问题，经过加工的宽表和汇总表通常会导致数据丢失了很多维度信息，使分析变得不够灵活。而基于第三代指标平台所定义的指标是基于明细数据，维度的灵活性得以保留。因此，第三代指标平台带来了更加灵活的分析体验，这是第二个方面。

第三个方面是，在获得了指标数值后，业务人员通常会问到某个指标为什么上升了或下降了。沉淀了指标的语义层之后，我们就能够提供一种先广度、后深度的分析能力。所谓的广度分析是指首先从指标- 因子的关系角度进行归因。比如，如果某企业的利润下降了，我们需要定位到是成本增加了还是收入下降了，这就是广度分析，通过指标的因子的归因定位到具体是哪一个指标。然后在定位到这个广度后，通过维度的归因，我们可以定位到指标从哪些维度受到影响。Aloudata CAN 提供了指标分析的各种维度，所以在进行这样的归因分析时，能够覆盖到每一个可能出现的分析角度，让深度归因分析成为可能。

第四方面是关于大语言模型。根据我们与企业的交流和头部客户的共创过程可以发现，大模型在自然语言生成 SQL 以及自然语言到指标语义两个方面的应用效果差别很大。自然语言处理指标语义的错误率很高，因为它们可能无法理解企业的特定术语和数据表之间的关联关系。这些术语和表的关联关系是通过指标平台的语义层进行沉淀和定义的。通过指标语义层和大型模型的结合，我们能够真正实现精准的对话式分析。

再来看供给侧的变化。

传统数仓开发通常需要三层或四层的架构，即贴源层（ODS）、数仓明细层（DWD）、数仓汇总层（DWS）和应用数据层（ADS）。第三代指标平台能够高效实现数据应用层的 NoETL 化，通过指标平台的语义层代替原本在数仓应用层的宽表和汇总表的开发工作，从而大幅减轻了数仓开发和运维工作，为数据供给侧带来了极大的改变。

第二个效果是我们能够实现统一管理。这也是许多企业引入指标平台的初衷。以前之所以做不到这一点，是因为指标的定义要么散落在数仓开发链路内，要么分布在 BI 工具中的不同报表中。在人工开发模式下，要做到不同部门、不同的人对同一指标的定义一致与开发逻辑一致是非常困难的，成本很高。而在第三代指标平台中，我们可以实现同一指标在不同维度下的管理，只需要定义一次。当指标的定义发生变更时，只需修改一次，所有的下游指标和报表都能够立即生效，管理成本大幅下降。

概括来说，第三代指标平台帮助数据团队将数仓应用层开发转变为 NoETL 模式，从而实现了从开发到运维到管理的“轻数仓”的价值。

真实场景验证价值

接下来我们结合两个企业的实际情况，来看看第三代指标平台具体为这两个客户解决了什么问题，带来了怎样的效果。

第一个客户是一家银行，在与我们合作之前主要面临三个问题。

首先，由于数据量很大，当业务人员进行报表查看或自主分析时，性能瓶颈非常明显。

其次，无法实现 100% 的业务自主分析。这是因为业务需求随着市场变化非常迅速，业务人员在观察数据后会得到更多灵感，从而产生更多的想法。然而，这需要从更多的维度进行分析，业务人员经常需要与 IT 或分析师交流，提出额外需求，传统的 ETL 排期开发方式很难快速满足这类需求。

另外，银行中的总行和分行通常使用不同的 BI 工具，并且由不同的 IT 团队支持，导致总行与分行之间的指标口径不一致，以及不同 BI 工具之间重复开发。这也给数据共享和指标共享带来了挑战，增加了管理难度与成本。

Aloudata CAN 指标平台为该银行带来的核心价值和优势包括：

首先，通过指标语义化的方式，用户可以自主完成指标的定义，无需向 ETL 提出需求。同时通过自动物化加速，确保了查询性能。因此，业务人员只需理解指标的业务逻辑，就能够自行完成指标的定义，改变了数据交付依赖 IT 的局面。

第二个变化是指标定义和开发供给发生了变化。在过去，需要编写 SQL 来进行指标开发，而现在可以通过配置化的模板进行开发，从而提高了交付效率。

再次，数仓集市层在这个过程中实现了虚拟化。业务用户获得的是一个虚拟的宽表，而非物理的宽表。这个虚拟的宽表背后实际上是多个事实表和多个维度表通过星型模型和雪花模型形成的逻辑关联关系。因此，业务人员可以实现更细致的分析，甚至到客户的具体交易明细级别的分析，从而指导更细致的业务策略和决策。

指标平台的语义层实际上独立于数据仓库和下游的 BI 工具之间，因此它具有指标共享和复用的优势。通过我们的解决方案，客户在第一期合作中已经看到了明显的落地效果。首先，业务能够自主进行指标定义和交付数据集的占比增长至 65%。其次，通过指标语义层的沉淀，该客户已经积累了 1 万个指标。此外，查询性能在三秒内响应的占比提升到 95%，较之前的不到 70% 有了显著的提升。

第三代指标平台也让 IT、业务和分析师之间的协作模式发生了变化。以前，业务人员需要依赖 IT 来开发数据表，然后分析师才能进行报表的开发与交付。而现在，基于第三代指标平台，形成了“136”协作模式，即 10% 的工作是由科技人员负责定义核心的原子指标，每个业务线的业务分析师则负责定义特定业务指标和共享的派生指标，占 30% 的工作量，剩下的 70% 工作则交由业务人员基于指标和维度的灵活拖拽组装自行开展灵活分析。

第二个案例来自证券行业的一家客户。在与我们合作之前面临着一些问题：首先，该企业的管理驾驶舱需要大量的 ETL 作业来保障，需要配置专人负责 ETL 任务的开发和维护。其次，证券行业专业知识门槛较高，投资经理等人员对数据敏感度较高，但缺乏编写 SQL 的能力，业务与 IT 的沟通以及指标口径的解释和理解成本较高。另外，IT 人员数量较少，快速响应业务需求面临较大挑战。

Aloudata CAN 为该客户提供了一个集指标“管、研、用”于一体的解决方案。通过该方案，客户实现了以下价值：

首先，他们不再需要进行应用层的开发，只需要将数据加工到公共层的明细数据资产即可，通过指标平台便可基于公共层来配置管理驾驶舱看板。这也意味着，管理层如果希望做任何变动，比如添加维度、指标或调整展示方式，都能够得到快速响应。指标平台重新定义了指标的开发模式，“应用层的 NoETL 化”是其关键。

其次，技术部门只需要定义原子指标，而派生指标的定义完全交给了业务部门通过拖动指标和维度进行组装。IT 人员的指标开发数量大幅减少，并让业务人员和投资经理实现了自主数据分析。以指标为中心，业务人员只需要理解这些指标本身的业务含义，他们就可以根据需要灵活地组合维度，生成所需的各种分析视角。这种方式屏蔽了底层表和字段的技术概念，大大降低了业务人员的分析门槛。

而不同的应用层开发链路导致口径不一致，以及固定维度限制业务分析灵活性的困扰也都不复存在。以持仓规模这一指标为例，以前可能需要从不同角度开发多张集市层表，而现在只需要定义一次指标，即可满足多种维度结合持仓规模的分析需求。在资产管理业务线，该解决方案只义了 68 个基础指标和约 19 个基于基础指标进行加减乘除计算的复合指标，就能够满足整个资管业务线的管理驾驶舱和投资经理自助分析的需求。

所以当这个客户跟另外一家同业客户交流经验的时候，介绍说过去可能一个 IT 人员一天只能开发 3.12 个指标，通过 Aloudata CAN 第三代指标平台，一个 IT 人员半天不到就完成了 20 个指标的开发，指标开发的效率实现了 10 倍以上的提升。

作者简介

杜雪芳，Aloudata 合伙人兼首席业务架构师。12 年数据业务从业经验，3 年管理咨询经验。历任阿里集团淘宝商业分析负责人、阿里音乐商业智能中心负责人、蚂蚁集团用户增长分析与洞察产品负责人。在数据体系搭建、数据分析、用户标签建设、用户洞察、用户增长等方面，拥有丰富的数据驱动业务实践经验。