为什么说第三代指标平台的本质是做轻数仓？

来源：Aloudata 

数据价值的挖掘正在成为各行各业头部企业的核心竞争力。在同大量企业交流的过程中，我们发现，一方面企业的“用数需求”日益旺盛，数据分析活动在企业各个职能中广泛开展，业务团队的“数据素养”持续提升；而另一方面，数据平台侧则面临着日益沉重的建设、开发和管理负担，而专业数据人才的匮乏又进一步加大了 CDO 的压力。

本文尝试从数仓开发角度分析各种“乱象”产生的原因，提出通过语义化与自动化做“轻”数仓的思路，希望对企业数据团队有所启发和帮助。

1、用数需求旺盛，加剧数仓“乱象”

在计算机领域，数据仓库是一个比较“古老”的概念，经过三十多年的发展，建立了成熟的技术体系与方法论。然而，数据仓库是为稳态的数据分析场景而设计的，典型应用是管理驾驶舱；移动互联网和云计算的蓬勃兴起让“大数据”成为必然，不仅数据源、数据类型不断丰富，数据量爆炸式增长，敏态的数据分析需求更成为常态，让传统的数仓分层建模体系招架不暇。

在我国，“数字化转型”让大量传统企业在近十年开始迅速接轨互联网的商业模式和技术体系，很多数据团队来不及打牢数据平台的“地基”，缺乏成熟规范的数仓建设体系和团队建制，就被业务推动着通过人工开发大量报表的形式满足分析需求。往往一个需求就是一张宽表，业务分析师 80% 时间用于发现和准备数据，ETL 工程师 70% 的时间用于宽表模型的变更、生成各类汇总表以及数据链路的运维。随着时间的推移，分析数据集之间彼此嵌套越来越深，数据链路越来越复杂，数据时效、查询性能、指标口径保障日趋困难，最终形成错综复杂的数据治理难题。 

（图 1：“数仓 + BI”模式下的 ETL 工程架构）

此外，专业数据人才的匮乏又进一步加剧了数据平台部门的压力。根据清华大学经管学院发布的《中国经济的数字化转型：人才与就业》报告显示，2021 年我国大数据领域人才缺口高达 150 万，到 2025 年预计将达到 200 万。很多 ETL 工程师简单学习了 SQL 代码便仓促上阵，报表开发逻辑因人而异，更因团队人员更迭加剧了口径的混乱和宽表冗余。

随着云计算和大数据基础设施的日新月异，很多企业近几年经历了多次的基础设施升级，从本地数仓到本地湖仓，从私有云到公有云，往往每升级一次便意味着一次全局数据的拷贝与搬运。根据 Aloudata 与众多客户交流的情况，企业湖仓数据冗余平均在 5 倍以上，这意味着大量存算成本的浪费。某证券行业数据资产部门负责人认为如实施了有效的数据治理，该企业每年可以节省超过 1,000 万元的存算成本。

而上述问题最终会反映到业务部门用数效率与用数质量的冲突上。不同于管理层的“看数”需求和少数可固化的主题分析需求，在日常运营活动中普遍存在着“探索性数据分析”场景，这类需求数量多，共性小，并且生命周期短，意味着 ETL 团队要进行频繁的数据模型变更和数据准备，业务人员无法快速、灵活地实现自助分析。而匆忙无序的宽表开发势必导致口径混乱，业务人员面临“数据不好找、找了不敢用、用了用不对”的窘境。   

2、探讨一种根治思路——做“轻”数仓

既然依赖人工的反范式 ETL 作业从本质上便不适用于敏态用数场景，那么是否可以跳出固有方法的窠臼，采用全新的思路和工具实现数据分析“效率、质量、成本”三者兼顾的目标呢？这正是 Aloudata 团队多年来的核心课题。

数据分析过程中发现数据不足是最正常不过也是最普遍的情形，因此需要分析师介入引入更多数据，数据准备与数据分析被割裂成两个独立的过程，分析进程被中断；而当探索性数据分析遇到亿级以上数据量的关联分析场景时，查询性能不足便普遍存在，这时更加依赖 ETL 工程师的介入，经由他们专业评估后，生成各种宽表和汇总表，以及选用更适合的数据查询引擎，这会导致更加漫长的排期与等待。上述两个常见场景导致业务人员要么在一个“数据缺失”的窘境里分析，要么在一个“IT 驱动”的窘境里分析。

打破上述窘境，我们认为最彻底的方案是实现 NoETL 的“业务自助用数”。有两个关键点：

1)语义化，基于数仓明细数据表形成强大的数据语义模型，并通过配置化模板点选操作而无需 SQL 支持复杂指标定义，形成统一的数据语义层，沉淀企业指标语义资产，既跨越了技术与业务之间的语义“鸿沟”，又规避了分析时数据不足的问题；

2)自动化，以智能的 ETL 工作引擎，实现自动编排、物化和回收数据管道，免除 ETL 工程师大量繁琐重复的工作，最大程度通过 ETL 作业的自动化和智能化确保查询性能，降低冗余成本，统一分析口径。

在这样的思路下，Aloudata 团队设计、开发了一款自动化的指标平台 Aloudata CAN，其核心技术便是强大的语义模型和智能的 ETL 工作引擎，通过强大的指标定义能力与自动物化加速能力实现任意指标可配置化定义、可自动化开发、可开放化应用，真正实现指标“一次定义、处处使用”、“一次变更，处处生效”，彻底杜绝指标口径定义的分散化，由系统代持数仓应用层的 ETL 报表开发作业，实现指标分析的敏捷性和指标口径的一致性兼顾。    

（图 2：引入指标平台，对接明细层数据，系统代持数仓应用层 ETL）

那么通过一款强大的自动化指标平台，企业如何实现做“轻”数仓，兼顾数据分析的“敏捷、有序与成本可控”。

Aloudata CAN 设计的初衷在于彻底实现数仓应用层的 NoETL，消除混乱、低效的根源。而实现这一目标有两个前提：

1)可定义：任意指标可基于明细数据被业务人员配置化定义，从而指标的生产才不会回到数仓开发的老路；

2)可查询：系统可自动化实现“反范式的宽表/汇总表”加工，自动实现物化链路编排和查询加速，确保指标口径的一致性和保障大数据量下的查询体验，真正实现“定义即生产”。

Aloudata CAN 直接基于明细数据，利用多表关联的语义模型来定义指标，意味着用户可以跨多个表定义和分析指标，解决了最常见的数据准备中断数据分析的痛点；同时，Aloudata CAN 还提供强大的指标定义函数（如窗口函数、预聚合分析函数），支持复杂指标的配置化定义（例如，近 1 年月日均 AUM 最大值、北向资金净买入额行业应有个股总数）。

在此基础上，Aloudata CAN 还支持更为复杂的衍生方式，包括同环比、均值/最值、排名、占比、累加等，所有反范式的 ETL 开发过程均由指标平台通过自动生产和自动物化加速代持，确保大数据量下的查询体验。这样的设计，不仅减少了对 ETL 工程师的依赖，还大大提高了指标加工的灵活性和深度，支持用户能够根据业务需求进行任意维度、任意粒度的数据洞察。   

强大的定义能力与自动化的指标开发能力是 Aloudata CAN 同其他指标平台相比最突出的差异，为了区别于仍旧依赖人工报表开发的指标平台，我们定义真正具有数仓应用层 NoETL 能力的指标平台为“第三代”。

Aloudata 倡导做“轻”数仓的最佳实践如下：

1)数据团队专注于企业公共层数据的建设，通过规范的数据清洗和转换等操作保障明细层数据的一致性和准确性，并实现企业数据资产的有效沉淀与管理；

2)利用 Aloudata CAN，基于明细层数据实现指标的配置化定义与开发，自动化代持数仓应用层 ETL 作业，实现数据分析的敏捷与有序

根据真实案例验证，通过上述方案，某客户在一条业务线，ETL 团队只需要准备 10 张公共层明细表完成 100 个原子指标的定义，就可以支持业务人员使用逾 300 个维度与指标组合进行灵活分析，代替了过去数百张宽表开发与维护的工作。客户反馈 Aloudata CAN 帮助其在工作量和成本方面真正实现了做“轻”数仓的目标，ETL 作业工作量下降 70%，存算成本节约 50% 以上，同时提升了业务用数的满意度，解决了数据团队最大的痛点。

3、总结

最后我们总结一下。从企业数据管理与治理的角度看，终极目标是以最优成本实现数据分析的高效率与高质量，从这个角度来看，做“轻”数仓既是手段也是目标，而“第三代”指标平台便是做“轻”数仓的最佳方案。

Aloudata 团队具有在中国最顶尖的数字化企业近 20 年的数据管理专业经验，从中得出的结论是：数仓应用层的大量人工反范式 ETL 开发是“效率、质量、成本”这组矛盾体形成的根源，如果依赖既往经验与路径，将数仓建设与开发、敏捷 BI 工具、指标管理工具、数据治理视作彼此独立、互相接驳的工具与方法，最终必将面对此起彼伏的数据困境，而破局的关键是重新思考，选择恰当的时机落地一套真正实现数仓应用层 NoETL 的解决方案。   

从这个意义上来说，Aloudata CAN 不仅仅是一款指标平台产品，更承载了 Aloudata 团队对数据架构、数据管理方法体系多年实践与深刻思考后，从本源出发力求“根治”的方案设计。Aloudata 期待同更多 CDO 与数据团队建立沟通，共同探索企业数智化的最佳路径。

*欢迎点击结尾左下角“阅读原文”，了解第三代指标平台 Aloudata CAN 。