NoETL 自动化指标平台打造自由分析

在企业里，我们经常听到业务部门抱怨数据分析体验：排期太久，数据不全，指标口径混乱……那业务期待的理想体验究竟应该是怎样的？又如何突破现有数据架构与技术的局限，交付理想的数据分析体验呢？

对于企业来说，数据的真正价值在于支撑业务流程和经营决策。从以前凭经验决策到依赖数据决策，在数字化时代，无论是公司的高管还是部门经理，都会通过管理驾驶舱对整个公司的绩效进行考核，依靠数据做出更好的决策；而一线员工，如活动运营、用户运营和渠道运营等，也希望通过数据来指导微观的业务决策，达成业绩目标。

在这个过程中，我们对业务期望的数据分析体验总结为三个字：快、全、准。

所谓快，核心有四点。

第一点是“试错快”。为了应对市场的快速变化，企业在持续创新，而创新探索类的业务需要快速利用指标刻画结果，衡量创新的好坏。

第二点是“决策快”。比如上线一个活动，做了一个 AB 实验，怎么能快速拿到活动、AB 实验的数据，基于这些数据快速调整策略，调整周期是周？天？还是小时？

第三点是“定位快”。当持续监测的数据发生异常，不符合预期，我们需要快速定位数据变化的原因，以快速发现和解决问题或识别与利用机会。

第四点是“查询快”。企业的数据量越来越大，如何快速满足业务对数据查询效率的需求，也是一大挑战。

除了速度，还有一个重点是“全”。

相信所有有过分析体验的业务同学其实最希望能够拥有一张大明细表。这张明细表中包含了所有可以分析的字段。为什么需要明细表呢？因为数据分析很多时候是一个灵活探索的过程，我们可能最初并不能完全确定需要哪些字段，甚至不确定要得出怎样的结论。因此，有了这张最全的表，我们可以灵活地筛选出自己想要的数据，可以灵活地透视这些数据。

而在“快”和“全”的同时，数据的准确性是它的底线和生命线。“准”的含义有两点：第一点是数据的一致性，即时间概念上的前后一致性；第二点是口径的一致性和清晰性，即在不同的报表中，同样的一个指标，它的口径是否一致，不同的业务人员对同一个指标是否有着清晰和统一的理解。

既然业务期望“快、全、准”的分析体验，那么我们的数据服务模式能否满足这种需求呢？

目前，大部分企业采用的是经典的“数仓 + BI”的开发与分析模式。ETL 工程师通过数据开发平台进行了大量的数据资产沉淀和物理表开发。这些物理表开发完成后，被引入到 BI 工具中，将其转换为数据集，用于报表制作或自助分析。经典的数仓分层建模严重依赖于 ETL 专业知识和人工作业。大部分场景下，BI 工具消费的是我们的应用层或集市层的宽表和汇总表。

这种模式存在一系列问题：

首先，整个数仓的加工链路比较长。如果 ADS 层没有现成的表可以满足需求，那么就要排期开发；如果业务需求发生变更，也要走冗长的变更流程。人工开发让业务需求响应速度较慢，可能需要长达两周甚至一个月的时间。业务要么等待，要么凭经验做决策。如果不等，试错成本可能比较高；如果等，决策迭代速度就会比较慢。

其次，我们在 BI 中是以固定报表的方式展开分析的。如果数据集是一张汇总表，业务就无法从汇总数据下钻到明细数据；如果需要从更多视角去分析，而数据集不包含这些维度，就会发现分析字段是欠缺的。这些都会导致分析不灵活。

第三个问题是口径的一致性问题。不同的数据集可能包含同一个指标，但这个指标可能来自于不同的 ETL 开发链路，背后可能是不同业务部门提的需求口径不一致，这会导致指标命名相同但口径不一致。或者，业务部门提的需求相同，但不同的 ETL 工程师在开发过程中用了不同的加工逻辑，也会导致同一个指标的口径不一致，从而可能导致决策失误。

最后，传统 ETL 汇总和打宽的开发模式也会导致大量维度冗余，叠加相似需求和不同的口径定义会进一步加剧冗余开发，企业数据部门面临着较大的人力与存算成本压力，维度冗余也会导致口径变更维护的成本很高。

总结一下，传统的“数仓 + BI”的指标开发模式，给数据分析带来了“慢、缺、乱”的弊端，而数据分析的成本也持续推高。

如何变“慢、缺、乱”为“快、全、准”？

我们认为，通过在数仓和 BI 之间引入一个全新的、独立的指标平台（或者叫做指标语义层），将指标的业务逻辑和物理口径进行解耦，可以实现这一目标。

但前提是这样的指标平台需要具有 NoETL、自动化的特点，即基于数仓公共层的明细数据和维度表进行自动化语义建模，并由系统自动化代持数仓应用层宽表和汇总表的开发，实现“管、研、用”的一体化：首先从管理角度，可以实现指标口径的统一管理；其次从开发的角度，避免重复开发，提高指标交付的效率；最后从使用的角度，提供给业务侧快速、灵活、一致的指标消费体验。

Aloudata CAN 作为一款 NoETL 自动化指标平台，能够交付“快、全、准”的分析体验，其两大基础分别是“标准化的指标定义”和“自动化的指标开发”。

首先，业务希望得到的是一个全面准确的数据体验。要做到指标数据的全面性，前提一定是基于数仓公共层的明细数据定义指标，这样可以获取所有分析维度，并能实现最细粒度的下钻；要做到指标的准确性，则需要将所有指标在统一的指标平台上沉淀和落地，将原来的数仓开发的数据资产和面向业务消费的消费层资产进行隔离。这背后依赖于一个强大的标准化指标定义能力。即所有的指标定义都不需要按照业务需求定制化编写 SQL 开发，而是基于一个强大的语义模型和丰富的函数能力，实现复杂指标的配置化定义。只要一次定义，下游的各个场景就可以消费。

其次，业务希望需求能够快速满足，唯一方法就是将人工开发转变为自动化开发。我们为了保证分析的全面性，要基于数仓公共层的明细数据定义和开发指标，这需要指标平台的自动化开发能力有着强大的性能保障。Aloudata CAN 通过智能的物化加速策略，保障指标的秒级查询响应。

接下来我们从“快、全、准”三个方面，详细介绍如何借助 Aloudata CAN 实现理想的数据分析体验。

3.1

快

“快”的需求，体现为“试错快”、“决策快”、“定位快”、“查询快”。

首先介绍下企业指标体系建设的四大原则。

最核心的原则是客观性，必须确保指标能够真实反映业务发展状况。如果指标不能准确反映当下的业务发展状况，就是失效的。

第二个原则是系统性。即指标体系的建设，一定要考虑全局性、结构性和层次性，才能自上而下形成一套指标体系，将企业最大的战略级目标横向和纵向拆解成一线业务人员能够追踪和执行的细分指标。

第三个原则是指标体系需要有动态性。在企业的经营过程中，不可能一开始就建成一个大而全的完善的指标体系。随着业务规划的调整和策略的迭代，指标体系也需要快速地进行动态调整。

第四个原则是指标一定要有敏感性，能够反映出业务的变化。比如，早期的业务规模比较小，如果用 DAU 去衡量，变化不快，可能要用 MAU 才能更有效地捕捉到变化。

在上述四项原则中，我们要强调的是动态性原则。如果可以快速试错，就能够低成本地判断指标是否客观、敏感。Aloudata CAN 自动化平台的一大价值就是帮助企业建立指标体系的快速试错机制。

通过 Aloudata CAN，业务人员可以用配置化的方式快速完成指标的业务口径定义，并能立即获取指标的数值，因此可以快速验证这个指标是否符合预期，能否客观地反应业务情况，是否能够敏感地捕捉到业务的变化。如果不能，我们可以对这个指标的口径进行快速调整，或者随时重新定义另一个指标来衡量。

相较于写 SQL 开发的方式，Aloudata CAN 的配置化指标定义的体验让企业可以快速迭代指标，降低指标体系建设过程中的试错成本。而实现任意指标标准化、配置化定义的前提，是 Aloudata CAN 强大的指标定义能力。

我们将指标的定义和计算逻辑拆分为三个核心的原子要素。

第一个是指标的基础度量。最简单的方式是求和。其次是时间维度的多次聚合，比如求月日均交易金额的最大值。需要先求出月日均值，再求出月日均值的最大值。这种聚合是在时间维度上进行的。同时，我们还经常需要在非时间维度上进行多次聚合。例如，如果我们想查看某个地区的门店日均订单量，我们需要将这个地区所有门店的日均订单量进行汇总，这种是非时间维度的多次聚合。

第二个核心要素是业务限定。在企业中，经常会用指标来筛选数据。比如，想要查看上个月交易量大于零的用户，本月的交易金额情况。因此，指标结果作为筛选是非常重要的。此外，还需要基于指标结果进行排名，进一步查看指标的表现。比如，当日持仓金额前三的债券，它的持仓规模占比到底是前三还是前五，需要进行试错。Aloudata CAN 可以便捷地实现指标标签化筛选数据进行分析。

最后，所有的指标都需要有一个统计周期。我们希望快速查看不同时间周期内指标的表现。因此，我们将时间周期抽象为常见的近多少日期初期末或者本年至今等统计周期的限定。对于一些上市公司来说，他们需要查看财年或某个运营动作，需要自定义周期去看指标的表现。还有一些特殊的行业，比如证券业，需要查看交易日，可以通过自定义日历查看指标的表现。Aloudata CAN 支持将这些复杂的指标通过配置化的方式快速定义，不需要在数仓里面写 SQL 层层开发才能看到指标的值，就能看到指标的结果，实现指标的快速探查。

企业都希望业务可以快速获取数据，实现自助分析。但在真实业务场景中，“数仓 + BI” 的模式会导致数据分析的最后一公里仍依赖于 IT 人员或分析师进行数据准备。业务会提出他们想要的指标、维度和分析角度，传统开发模式下，分析维度被固化。一旦需求变更，还需要找 IT 人员提需求。

有了指标平台，IT 只需要做好公共层的数据资产沉淀和原子指标的定义，业务人员就可以用原子指标加上任意维度，灵活地进行自主分析。因为给到他们的分析维度是全的，业务能够真正能够完成从数据准备到数据分析的最后一公里。

这样的业务全流程自助分析同时解决了 IT 和业务的痛点。传统模式下，IT 的排期开发任务很多，也很担心业务经常修改需求，但通过 Aloudata CAN 实现了业务自主分析后，大大降低了 IT 的指标开发和变更成本。对于业务来说，能够实现指标维度的灵活扩展，实时获取分析结果。实践证明，通过 Aloudata CAN，决策效率可以提升 10 倍以上。

企业持续观测指标的目的是通过指标的波动变化发现问题或识别机会。因此能够快速定位指标变化的原因是一项核心诉求。

为支持更加快速的数据分析，Aloudata CAN 提供了两种智能归因的分析方法。

第一个是从各个维度层层下钻分析。与 BI 工具中的指标归因不同，Aloudata CAN 下钻的归因维度是全面的。数仓公共层维度表中包含的所有维度，都不需要通过 SQL 开发进行打宽固化。因此，Aloudata CAN 保留了最全面的分析维度。在归因时，也能够下钻直到获取明细数据，定位到根本原因。

第二个是指标因子关系的归因分析。比如，企业将利润定为北极星指标。利润可以拆分为收入减去成本。收入可能等于 A 收入加 B 收入加 C 收入。通过指标的因子关系，我们可以找出指标间的相关性，判断对于利润影响最大的指标因子是收入还是成本。然后，我们可以结合指标维度下钻归因分析收入或成本变化的根本原因。

根据指标因子关系归因是一种广度定位的方法，帮助我们找到主要原因，然后再根据指标维度下钻定位到深度的原因。这两种方式相结合，可以帮助企业快速洞察指标波动的原因。

业务自主分析或打开报表时，默认需要秒级体验。

Aloudata CAN 的指标定义直接基于明细数据，如何保证全量数据的快速查询体验呢？我们自研了一个物化加速策略引擎。它会基于用户的查询行为，提供物化加速的策略建议。

Aloudata CAN 基于一整套物化视图构建、物化视图调度更新、物化视图命中改写的策略，将原来需要人工在数仓进行的宽表和汇总表的开发，变成系统自动化构建。当用户发起一次查询，相当于对某些指标和维度进行筛选和计算，系统会自动判断是否命中物化表，进而自动进行路由的查询改写。通过这套机制，我们能做到 10 亿数据的秒级响应。

小结一下，通过上述试错快、迭代快、定位快和查询快四个方面，我们介绍了 Aloudata CAN 如何交付快速的分析体验。

那么第二大方面“全”又是如何体现的呢？

3.2

全

所谓全，其实本质就是给业务一个完整的明细表。

传统方式要通过人工打宽和汇总的方式实现对明细数据的查询和分析，业务拿到的是维度和粒度完全固化的结果表。一旦发现字段不全，想从更多视角进行分析，就还需要找 IT 排期开发。

Aloudata CAN 其实是建立了模型的逻辑关联关系，而不是物理关联。有了这样的一个逻辑的关联关系之后，实际上是形成了一个虚拟的明细大宽表。

比如下图中例子里面是两个事实表和三个维度表。订单表和退款表都与客户、产品、类目的维度表建立了关联关系，因此有着同样的公共维度。只要是这两个事实表的公共维度，就可以去串联分析跨事实表的指标，而不需要在数仓里把它们写到一张表里。这样就给业务提供了一个虚拟的明细大宽表，可以对指标和维度实现灵活的组装和分析。

此外，我们也不需要提前把维度表的字段冗余到事实表里去。用户可以自主选择来自不同维度表的维度，去展开不同切片的分析。切片可粗可细，用户可以灵活地去调整。

在线上运营场景中，我们还经常会进行留存分析。留存分析最大的痛点是留存率的 SQL 比较复杂，第二个痛点是监控留存率时只能按天粒度开发好一张固定的物理表，如果发现留存率波动，想要分客群看时数据不全。

现在借助 Aloudata CAN 指标平台，可以通过指标标签化的能力实现人群的快速圈选，进而很方便地从不同维度下钻，看不同客群的留存率表现。

具体操作上，我们可以先定义一个基础指标“访问次数”，接下来对“访问次数”进行时间和条件筛选（“上月访问次数” > "0" ），就完成了监控人群的圈选，将这个筛选条件应用于基础指标“活跃客户数”，即可完成派生指标“留存客户数”的定义。留存率的定义就非常简单了。

因为指标的背后实际上是 Aloudata CAN 的语义模型而不是物理表，我们将访问事件表和客户维度表建立关联关系，对留存率做分析时，就可以从客户维度表的各个维度进行下钻。不同维度的组合实际上是把客群做了不同的划分。这样不仅能看到整体时间维度上的留存率表现，还能基于时间维度下钻看不同年龄段、不同地区、不同消费等级用户的留存率表现，业务上就可以针对细分人群去做动作了。

还有一个常见的分析场景是根据丰富的维度进行客户画像的圈选和分析。同样通过指标标签化的方式，业务可以拿到最全的数据，自己圈选出想要分析的人群，再通过丰富的维度准确地刻画出想要的客户画像。这就是 Aloudata CAN 通过基于数仓明细数据进行语义建模、结合丰富的分析函数，给业务提供了一个虚拟的明细大宽表的分析体验。

3.3

准

最后，我们来看“准”。

对于“准”，最基本的要求是指标口径一定要一致。这依赖于 Aloudata CAN 在指标规范管理方面的产品能力。

我们将指标的规范管理分为三个阶段。

实现指标管理，首先要有一个全局的规划。在这个阶段，Aloudata CAN 支持企业按照业务和管理的需求定义指标的类目，以及对指标按照影响面或重要程度进行分类分级。同时我们也支持自定义扩展属性，适配企业的指标管理与使用规范。

有了全局规划后，进入具体的指标定义、管理和使用阶段。

在这个阶段，我们首先会做指标的生命周期管理，提供指标上线、变更和下线的发布审批功能。对于指标口径变更，我们会提供指标的多版本。

其次是指标的质量管理。我们经常发现指标同名不同义、同义不同名的情况。这种情况在数仓和物理表中普遍存在，需要进行专门的口径治理。现在我们希望通过指标平台将这种事后治理变成事前管控。

所谓事前管控，就是指通过指标重复的校验，避免相同名称或相同计算逻辑的指标的重复定义。因为 Aloudata CAN 由系统实现自动化的指标开发，因此在发布时，具有自动进行同名或同义校验的能力，检查相同名称的指标是否已经存在，以及相同计算逻辑的指标是否已经存在。

很多企业存在指标盘点梳理的痛点，Aloudata CAN 会清晰地展示指标之间的血缘关系和开发链路，为指标管理和治理提效。

指标预警监控对企业至关重要，Aloudata CAN 支持设置告警规则，系统自动进行指标监控，一旦指标数据异常，会自动通知。

在指标的使用管理方面，Aloudata CAN 提供丰富的权限管控，包括指标的查看权限和使用权限，以及使用的数据范围和行级权限设置。

最后，每个企业的指标会随着业务发展动态调整。指标在全生命周期中需要持续的运营和监控。Aloudata CAN 提供指标的使用分析和资源分析功能，帮助企业随时了解指标的消费情况。对于没有消费的指标会提出下线建议，以形成指标治理的闭环。

上述是产品层的能力，但为了确保指标质量的“长治久安”，我们建议要将工具与管理机制相结合。

在管理流程和制度方面，Aloudata 建议分为三个环节。

首先是需求环节。在业务提出指标需求时，我们建议通过指标平台的搜索功能先检索是否存在相应的指标。如果存在，业务申请查看或使用的权限；如果不存在，则提出需求申请。在需求申请中，业务必须填写指标的口径和标准属性，做好指标需求的描述。

然后进入企业定义的需求审批环节，如果需求合理，审核通过，就可以进入指标开发环节；如果不合理，业务需要完善需求，审批通过后进入指标开发环节。

在开发环节中，指标开发部门可以借助工具进行血缘追踪、版本管理和口径发布校验，将口径混乱的问题在事前就规避掉。上线后再结合指标权限管理功能，确保数据消费的安全可控。

业务所向往的自由分析，实际上是一个“快、全、准”的分析体验。“快”的终极目标是业务决策效率要快；所谓“全”，业务最终希望获得一张虚拟的明细数据大宽表，零字段的缺失，支持任意分析；最后的“准”，核心是指标的口径要百分之百一致，所有人对指标口径的理解也是百分之百统一的。

这就是我们今天跟大家分享的，通过 NoETL 自动化指标平台，帮助业务打造“快、全、准”的分析体验。

往期推荐

点个在看你最好看

SPRING HAS ARRIVED