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

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

01 数据分析的本质：快、全、准

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

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

所谓快，核心有四点。

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

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

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

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

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

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

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

02 “数仓 + BI” 为什么无法满足业务需求？

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

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

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

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

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

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

最后，传统 ETL 汇总和打宽