在企业内部具有海量数据的情况下，会陷入成本、质量、效率的平衡难题，第三代数据平台的产生能为企业带来什么价值？
本文围绕NoETL全新的解决思路、指标平台的核心能力、实际落地案例三部分详细展开说明。
分享嘉宾｜杜雪芳 ，Aloudata 合伙人&首席业务架构师
内容已做精简，如需获取专家完整版视频实录和课件，请扫码领取。
随着这几年数字化转型过程，原来只是管理层有看数需求，现在不同的业务部门，无论是运营、产品、项目，都需要通过数据来帮助决策。在此过程中，原本响应各个业务的分析需求，都靠 ETL 围绕场景去开发了面向 BI 层面的宽表和汇总表，该过程叫做反泛式 ETL 的加工。反泛式 ETL 加工会使数仓里的链路越来越长和复杂，导致不堪重负。令企业里陷入平衡成本、效率和质量的难题。这三者很难做到平衡的，高质量、高效率、低成本的解决方案更是难得。原来反泛式的 ETL 加工会导致不同业务场景的重复开发，比如同样的指标，我们可能会开发一堆不同维度的表，对企业来讲，一方面浪费存储计算成本。另一方面整个 ETL 做运维时的成本也会上升。另外原来的方式都要业务提出需求，围绕业务需求去开发。比如管理层的驾驶舱里少了个维度，这时我想换一个视角，如何快速地切换呢？在传统概念里，首先必须回到数仓，把指标、字段的维度加上。整个响应速度非常慢。对于管理层来讲，也无法解释清楚为什么加一个视角、字段这样简单的需求，要用到1-2天才能加出来。第三个越来越多的企业会发现不同报表之间口径不一致，尤其是一些 BI 报表、 BI看板数量。三者之间的问题大家都意识到了，那到底有没有一个解决方案能够真正平衡这三者？可能存在两种方案：刚刚讲到了问题的根源，是因为 ETL 加工了很多的宽表和汇总表。第一个方案是不开发宽表和汇总表，把数仓只做公共层的明细数据。大数据量时代，很多企业的数据规模都是上亿、几十亿的，甚至一张表都可能是百亿、千亿的规模。如果不做宽表、汇总表的开发，显然性能是扛不住的，所以该方案不可行。第二个方案，原来存在大量效率、质量、成本不可行的原因，是因为人工做开发，需要保障人和人之间的不重复，成本非常高。能不能把人工方案变成自动化的方案？因为自动化的话系统能知道指标加工的情况，自然不会存在重复加工。所以从人工变成自动化的方案可行。到底如何真正落地从人工变成自动化呢？我们会发现让系统能够自动化代原来人工做大量的应用层开发，前提必须理解加工指标背后的业务口径。整个应用的自动化前提是要有指标语义的标准化沉淀，相当于我们要告诉系统，指标业务的加工逻辑是什么？因为对机器人来讲没法理解企业里指标的业务逻辑。要沉淀标准的业务语义，那应通过什么方式承载呢？第一个就是要告诉系统表和表之间的关联关系，所谓关联关系是在传统的维度建模里，叫经典的这种新型模型和雪花模型，也就是说事实表和维度表之间建立了关联关系，它没有做这个物理上的这个打宽。然后第二个是说我理解了数仓里面的表和表之间关联关系之后，那具体到这个特定的一个指标，它具体的业务逻辑是什么？把业务逻辑抽象成标准化要素，就像小孩搭积木，积木最原子化的是一个个积木块，那在指标里也抽象了最原子的积木块，把积木块分装成每一个指标的业务逻辑。有了这两个之后，系统就能知道指标底下的表与表之间的逻辑是什么？指标的业务口径是什么？能够自动地实现从人工变成系统自化地生成宽表和汇总表。为什么原来的指标，除了性能的问题，还有很重要的点，就是在真实的业务场景中，包括实际落地中的指标，不是简单通过求和求平均计数的方式能定义出来的。产品具备承载复杂指标的语义，在产品里落地，而不是回到数仓里面进行 SQL 的开发。所以我们认为通过这样的指标平台，要具备一个能力，能实现任意复杂的指标，都能把业务语义在指标平台上呈现。好处就是会把资产沉淀和面向业务场景的指标开发做隔离，这样才能做清数仓。
指标语义能够有产品承载，如何保证能够算、查出来？涉及上文中，要实现 NoETL 的自动化能力。有了系统能理解指标业务语义之后，怎么自动化的把业务语义转化成系统执行的circle，且在大数据量情况下可查。这背后有自动化的指标生产能力，基于用户消费场景需求，自动构建提前预计算的概念，构建物化视图，基于该概念类似于传统数仓里人工做的宽表和汇总表。
这时一个用户的需求查询过来，如果数据量比较大，查询比较复杂，那就会直接下推做提前预计算的物化表，类似于张宽表汇总表去查询。如果数据量比较小，可能就直接去查背后的明细数据，从而保证消费端的查询性能。
实现NoETL自动化的两个核心是自动化和语义化，把结合两个能力的解决方案产品叫做第三代指标平台，区别于原来传统的指标平台，核心的差别是什么？传统的数据开发平台里面，很多厂商在数据开发平台里都有一个模块叫指标字典或指标目录。但原来传统的指标平台依赖于 ETL 在数仓里做应用层的表开发。第三类指标平台，依赖 ETL 开发应用层的逻辑变成了 NoETL自动化，背后有两大能力：1、强大的指标定义能力，能够把所有的指标语义在产品上承载。2、自动化能力，基于在产品上实现承载的语义化，系统能自动实现指标开发，也就是做轻数仓，实现数仓应用层的NoETL。第三代指标平台，基于对指标的定义基础之上，做到自动化生产。原来在 BI 报表里看到了一个指标之后，业务人员不知道指标背后的加工口径是什么，就需要找分析师或ETL去咨询指标是怎么算出来的。现在基于指标平台本身的业务、计算的逻辑都在产品上承载了，所以通过指标，能够清楚地知道指标是通过什么样的逻辑加工出来的，而且指标的业务口径也产品化的承载。还可实现实现管得住。对于很多企业来讲，上指标平台的初衷是做统一的指标管理。为什么很多企业做不到呢？因为指标口径要么在数仓里，要么在 BI 工具里面，且 BI 工具里会存在不同的报表，所以指标没有做统一的管理，如果在数仓里，做到不同人的对于同一指标的口径一致，成本非常高。在指标平台里能实现同样的指标不同的维度，只要定义一次，同时如果口径发生变更时，只改一次，下游所有的指标，从不同维度分析都会生效。那这是管得住。对于最终我们应用指标时能用得好，用得好是指同样的指标能从各个维度进行分析，没有在原来数仓里，经过了数仓的宽表和汇总表的加工，以及从明细的变成了汇总的力度，可能丧失很多维度。在我们的概念里，实际是基于明细数据去定义指标，指标的维度灵活性还能保留。且同样的维度，也能支持从各个指标的角度串连分析。对于数据供给侧，价值在于数仓应用层 NoETL 做轻数仓。上图可知，传统需要2真的满足业务的需求，一定是在数仓里面有四层的架构，就是贴源层、 DWD 层、 DWS 层和 ADS 层。第三类指标平台里，数据应用层的NoETL化，在架构里通过指标平台的语义层，能代替掉复杂的数仓应用层，减轻大量数仓的开发和运维工作，这是供给侧带来的价值。
从消费侧来讲，原来分析的时候以数据集、物理表、字段为中心去消费。会存在一个问题，一定事前得知道从什么样的维度、指标放在一起去分析，比如说a、b、 c 三个指标可能来自于不同的指标，如果数仓里面没有把这三个指标放在一张表里面，那在分析时无法配成可视化的图表。现在以指标为中心，能实现同样的指标，从各个维度去下钻，串起所有的指标。比如一个机构，可以从各个角度来看，存款、贷款、代发等。这是以指标为中心带来的灵活分析。有了指标后，业务日常当中会有疑问，比如指标为什么涨了、跌了？有了指标语义层之后，就能够提供先广度后深度的分析原因。所谓的先广度是说，能从指标的角度定位，比如说企业的利润额今天下降了，原因到底是成本增加了，还收入下降了？这是广度上，可以通过指标的归因定位到具体是哪个指标，定位到广度之后，还可以通过维度的归因定位到深度，具体指标是哪些维度影响了效果？所谓的深度，是因为我们提供了指标，能从各个维度分析，所以在做归因时，不放过任何一个可能错失的分析角度。1、自然语言 to SQL，很多企业通过大模型，能够实现自动写SQL或拿到数据。在交流过程中，会发现两个效果差别很大，原来传统的这种自然语言 to SQL 会出现不明白在问什么的情况，或者给出的数据是错误的，因为它并不理解企业里面的“黑话”。也不理解数据里表和表的关联关系。而这些“黑话”、表的关联都会通过指标平台的语义层沉淀好，所以基于指标语义层加大模型，能够真正实现精准式的对话分析，这是消费侧能够给企业带来的效果。银行、证券企业实践案例
3.1 头部股份制银行实现指标统一沉淀与复用
1、数据量非常大。在 BI 场景下给到业务做报表看板或自助分析时，性能的问题比较明显。为什么性能问题较明显呢？因为整个业务需求的灵活性越来越大。如果还是走传统的方式，通过技术的视角考虑数据模型的设计，很难满足灵活性的需求。2、希望给业务去做自助分析，但最终会发现还差最后一步，就是业务用不起来。因为市场变化速度与业务节奏很快，我们会发现业务的需求表达不清楚，或者业务的需求经常发生变化。对于业务人员来讲非常痛苦，因为他必须要在看到数据之后，才给他更多的灵感。所以为什么会少了最后一公里，原来 IT 部门或者分析师给业务人员准备了数据，看完数据后产生更多的想法，又要从更多的视角分析，需要找到 IT 或者分析师提需求，最后一公里的需求不能自主分析，还是要寻求 IT 和业务分析师的帮助。3、银行里会有总行和分行，用了不同的 BI 工具、 IT 团队去满足。存在总分行之间指标口径的不一致。不同 BI 工具之间指标的重复开发，所以数据共享、指标共享之间也面临了很多的挑战。
基于以上问题，我们给到客户一个思路，产品界面层分为界面层和下面的指标语义层，客户用到了指标语义层。1、对于业务用不起来的问题，该解决方案通过指标语义化的方式，用户自助完成指标的定义，不需要提需求给 ETL 了。用户不能自定义的原因用户没有技术门槛，无法保证查询性能的问题。该方案通过自动物化加速来保证查询性能，对于最后一公里的业务人员来讲，只要理解指标的业务逻辑，就能够完成指标的定义。所以整个数据交付的效率从原来依赖 IT，到现在业务线的10个分析师可以自己完成，整个交付效率以人的角度就完成了从一扩大到 10 个人。2、从本身定义指标、开发指标的工艺发生了变化，原来是要写 SQL 开发，现在通过配置化的模板点选的方式就可完成开发，工艺上的变化也导致交付效率的提升。在定义过程当中，把整个集市层虚拟化了，类似于对业务人员来讲，给它交付的是一个虚拟的宽表，不是物理的宽表，虚拟的宽表背后实际上是多个事实表和多个维度表，通过了新型模型和雪花模型形成逻辑关联的关系，对于业务人员来讲，比如说零售线，原来可能只能实现客户的类型分析，现在能实现到某一个客户的分析，甚至客户的具体交易明细分析，整个分析力度非常细，能够指导更细致的业务策略和动作。3、指标语义层原本在数仓和下游 BI 工具之间独立了一层，能够实现指标的共享和复用。该解决方案帮助银行总行的零售和批发业务线落地，实现了三种效果。业务自主做指标定义和交付数据集的占比达到65%。通过指标语义层沉淀了1w+的指标。原来的查询性能，可能三秒内的占比不到70%，现在三秒内的占比能够提升到95%。3.2 证券行业运用指标平台提升开发效率，灵活分析
第二个客户的产品基于第三代的指标平台，原来IT 、业务、分析师铁三角的协作模式发生了变化。原来协作模式是最终业务人员看数据，或自己做自助分析，都得依赖 IT 开发的表，有了表之后，业务分析师才能做报表与交付业务。现在基于第三代指标平台，它的交付模式就自己总结的它叫136的协作模式。136指 10% 的工作由科技人员完成。主要定义核心的原子指标。每一条业务线的业务分析师角色，完成定义业务线里共享复用的派生指标，占 30% 的工作量。剩下的60%，是业务自己做分析时，基于指标和维度灵活组装的场景，让业务人员自己在 BI 工具里通过指标和维度的积木组合方式，灵活的组装。所以叫 136 模式。第一个客户，本身已经有了大量的数据沉淀和积累的客户，第二个客户的基础可能没有那么好。合作之前面临的问题是：1、配管理驾驶舱的看板，原来通过大量的 ETL 任务管理驾驶舱，要从什么样的维度、指标去分析， ETL 任务就开发成这样，所以要设置专岗做管理驾驶舱背后的 ETL 任务的维护。2、证券行业的专业知识门槛非常高的，比如投资经理的数据意识、业务敏感度非常高，但是没有写 SQL 的能力。原来投资经理和 IT 沟通的时候，本身指标口径的理解，沟通核对成本非常高，包括业务也需要看口径，明天换一个口径。这个时候 IT就要跟业务沟通，理解业务逻辑。还要对指标口径做变更和维护，维护成本非常高。3、公司规模没有那么大，IT人员少，业务盘子又很大，各个业务线都要对接，怎么快速响应业务需求？我们提供了管沿用一体的指标平台，带来了几个亮点：
第一不需要做应用层的开发，IT人员只要加工到公共层的数据资产就好了，应用层的核心价值之一是NoETL化。重新定义的指标的开发模式，现在只要开发到公共层，基于公共层之上去配看板就可以了。管理层如果要加一个维度、指标，换一种展示方式，能够快速地去响应、调整。第二企业里只定义了原子指标， IT 完全没有定义派生指标，把这项任务交给了业务，在做分析的时候拖指标、拖维度去组装。IT 的指标开发数量大幅减少。第三最终是要让业务人员、投资经理自己做分析。原来投资经理做不了分析是因为，理解表，理解字段，对于投资经理来讲门槛非常高的。以指标为中心，指标本身就是业务含义。屏蔽掉了原来底下的表的概念，屏蔽掉了是说这个字段的这种技术的概念，只要知道要从什么指标和维度分析，就可以灵活地拖拽，生成想要的各种视角。解决方案里，是以数据集甚至是应用层给到业务去消费，这里面会存在不同应用层的开发链路口径可能不一致，同样的指标我要去开发多次，口径又不一致。现在以指标为中心，同样的指标只要定义一次。在落地的应用过程中，以资管业务线为例，只定义了技术指标和复合指标共 68 个基础指标，大概 19 个复合指标，通过不到 100 个的技术指标就能满足整个资管业务线的无人管理驾驶舱，还可满足投资经理做自助分析的诉求。在场景下整个指标的开发工作量，不止节省70%， 80 多个指标就满足了整个业务条线的需求，在原来概念里同样的持仓规模，要从机构、债券类型、日期、币种多维度看，至少要放大十倍。业务人员既是用户，也是派生指标的定义者。基于指标平台，给了使用者轻量级、低门槛的工具，只需要理解业务的逻辑就好了，可通过配置化的界面去定义。对整个 it 团队来讲，降低了数据开发的门槛。对业务来讲，他不认为自己在做派生指标的定义，在 BI 分析工具里拖指标、维度就能够生产出指标。通过第三代指标平台，经过客户实践，半天不到完成了 20 个指标的开发，指标开发的效率以10 倍以上的幅度提升。 1、真的让企业把数仓做得比较轻，即视层可以通过指标语义层代替，可完成自动化的语义开发。2、工艺上的变化，从原来一定要写SQL，让IT去开发，现在不懂 SQL 的人，也能通过指标平台，实现业务人员自助做大量派生指标的定义，实现指标“管沿用”一体化。以上就是本次分享，如需获取专家完整版视频实录和课件可扫码领取。
⩓
12年数据业务从业经验，3年管理咨询经验。历任阿里集团淘宝商业分析负责人、阿里音乐商业智能中心负责人、蚂蚁集团用户增长分析与洞察产品负责人。在数据体系搭建、数据分析、用户标签建设、用户洞察、用户增长等方面，拥有丰富的数据驱动业务实践经验。
注：点击左下角“阅读原文”，领取专家完整版实录和分享课件。
