管理学大师德鲁克曾说过,没有指标就没有管理。混乱的指标口径带来的是分析上的低效和研发人力成本的高消耗,甚至影响业务决策。指标中台的出现非常有效的解决了这一问题。
衡石科技从4.0版本开始引入指标管理能力,更是在4.3版本中重磅发布了指标中台,轻量化指标定义的过程,让用户能够对指标进行统一创建和管理,实现指标可复用,降低了分析门槛,并基于ELT+指标中台的能力形成完整的分析闭环,让数据分析进一步走进业务端,提升业务数据价值。今天我们就一起来了解下指标中台的缘起、现在和未来。
在传统BI阶段,业务人员通过查看报表和看板的方式进行业务分析,而查看报表仅仅是数据分析流程中的末端,在这之前是非常重的数据加工和处理过程,也就是传统ETL的过程。
一方面,这种过重的前端数据处理过程,导致中间表数量快速膨胀,造成了大量存储及计算资源的浪费。另一方面,分析的本质是强运营的,业务运营过程中会不断产生新的分析需求,导致数据研发团队疲于应对随时变化的报表需求,研发投入的价值大大降低。同时,由于前端数据处理过程严重依赖于研发人员的技术支持,业务人员无法实现自主分析,必然导致业务分析效率低下。
而敏捷BI阶段是通过将建模过程后置,并将物理建模改为了逻辑建模的方式,即将数据处理的过程从ETL模式改变为ELT模式,业务团队可以自主完成建模,不需要再依赖于数据团队,由此来提供分析的敏捷性。
敏捷BI方式也带来了一些新的问题,首当其冲的是口径混乱。由于建模过程是由不同业务团队完成的,每个团队定义同一指标的方式可能不一样,从而导致口径不一致引发管理混乱。第二个问题是重复建模,同一个模型或指标可能在不同的团队被进行重复建模和定义,造成较大的人力成本浪费。第三个问题是由于数据建模和数据处理的门槛高,业务团队并不能轻松完成建模的过程,无法完全实现分析平民化、自主化。
指标中台的出现很好的解决了这些问题。指标中台与敏捷BI的最大差别是,大部分数据建模的过程是被抽象出来进行中心化管理的,这部分中心化管理的建模过程围绕指标这一核心概念而构建,通过指标中台来解耦底层的数据与上层的分析应用。指标中台为实现分析平民化带来的价值体现在三个方面:一是通过集中管理和分发使用的中心化管理方式,实现了口径的统一管理,消除了口径不一致带来的混乱。二是提升了建模效率,指标的统一定义就是数据建模过程的复用,大大减少了重复建模和中间表的工作。三是极大降低了分析门槛,业务人员面对的是具有业务意义的指标和维度等业务概念,而不是晦涩难懂的物理数据表和字段,真正落地和实现业务人员的自助分析。
合格的指标中台需要具备三个能力:
首先是建模语言能力。指标最关键的特性是可复用性,不同的SQL数据库有不同的方言,基于某一种SQL语义定义的指标逻辑,在其它数据环境中可能无法计算,很难实现一处定义随处可用的复用效果。另外SQL语义本身是面向结构化查询的语言,书写较为复杂,在建模上表达能力较弱,而指标体系构建是不断迭代的业务建模过程,要求建模语义表达能力足够强,才能高效完成指标制定和迭代工作。所以大部分指标中台产品都会有自己的建模语言。
其次是指标计算加速能力。指标层本身是一个逻辑语义层,不存储任何实际数据,只存储一段计算逻辑。所以在指标中台的分析场景下,相较于传统查询,会产生大量的实时计算,以及对底层明细数据的查询。在 HENGSHI SENSE 的架构中,是通过内置数仓及开放式设计的产品架构来支撑指标中台的查询功能。内置数仓有两方面的作用,一方面是可以落地智能Cube,加速复杂指标计算;另一方面,衡石在内置数仓做了一个插件式的设计,可以实现在分钟级的时间内通过配置的方式随时替换成先进的MPP数据库或云数仓,如Doris、Clickhouse、Redshift、Snowflake等,这就使得衡石的指标中台具备一个其它指标中台没有的能力:可以随时引入业内一些先进的计算引擎,借助业内最先进的计算技术,帮助加速计算过程,为指标中台提供一个高性能的计算底座。
最后是直达分析应用的能力。指标定义和管理的最终目的,是方便的被业务使用,让业务侧的分析工作能够更灵活、有效的进行,所以指标中台需要有可视化应用支撑,需要与分析应用层以及底层数据紧密结合。
HENGSHI SENSE 就是以指标中台为中心构建的一站式分析平台。在4.3版本之前,衡石的分析应用创作和数据服务就已经可以非常灵活的引入指标层定义的指标来进行报表制作,或者封装数据API服务。在4.3版本中,进一步加强了指标层和应用层的打通,在分析应用层增加了自助分析的模块,使得在应用层可以更方便地引用指标来完成业务上的自助分析,为指标提供了更高效的价值出口。
自ChatGPT横空问世以来,业内讨论最多的就是ChatGPT如何在各行业的场景里落地应用,甚至有不少BI行业伙伴推出了类似Chat2SQL的产品原型。但我们认为Chat2SQL的方式并不是AI+BI的最合理、最有效的方式,而应该是基于指标中台的AI+BI,可以称为Chat2Metrics。
以分析上个月渠道用户留存率为例,在Chat2SQL模式下,ChatGPT对于留存率的定义通常是根据业内的一些通识来定义的,和实际分析场景中的留存率定义可能存在差异,这就需要分析人员进行反复、多轮的信息反馈及同步。
AI落地的大模型学习,一般包括通识学习和场景化学习两部分,分析场景中往往场景化学习的比重更大(包含大量行业Know-How)。场景化学习的效果又取决于prompt和提问质量。
如果使用Chat2GPT的方式,就会对用户的prompt及提问者的提问质量有非常高的要求,才能让AI在场景化的学习过程中能够足够好、足够细的学习到行业Know-how,才能帮助用户完成比较有效的AI+BI分析。
而在基于指标中台落地的AI+BI形式中,大部分场景化的知识已经通过指标定义的过程提前固化在指标中台中,因此只需要在prompt中将定义好的指标提供给ChatGPT,并做一些简单的提问,ChatGPT就可以非常清晰地将自然语义中的指标概念和指标中台定义的指标关联起来,从而生成一个基于指标的查询过程,具体查询过程对应的计算逻辑以及SQL代码也已经在指标中台中进行了详细的定义,无需AI处理,更能保障查询结果的准确性和可解释性。基于指标中台的AI+BI的方式,在降低业务人员分析门槛的同时,也大大降低了AI的学习成本,帮助AI更好地在分析场景中落地。
此外,AI在分析领域落地的另外一个场景是帮助用户更好地进行洞察分析,挖掘数据价值。而在指标中台里,指标与指标之间存在天然的数据关联关系,更容易落地根因分析、异常定位、预测分析等智能分析应用。
衡石在4.3版本中重磅发布指标中台的能力,基于指标中台的产品形态,为以后进一步做AI+BI的结合提供了先天的优势,以及更有效、更低成本的落地路径,帮助衡石未来更好地在分析场景中落地AI价值。