数据中台：指标管理中台演进路径及价值.docxVIP

数据中台：指标管理中台演进路径及价值 收到一个朋友关于指标管理中台的问题咨询，关于设计指标管理中台时，针对同一个指标业务口径和财务口径不一致时，在指标数据集绑定时是否需要支持多个数据源。就着这个问题，展开聊一聊指标管理中台的产品演进过程。 一、指标管理中台的产品演进路径 中台的概念没出来之前，会称之为指标管理平台。对于指标管理平台这个偏后端数据资产管理与治理的数据产品来讲，其建设的初衷主要解决以下几个问题，如果你也要做指标管理，可以看下这几个需求场景是否都覆盖了。 1.指标字典的存档与信息查询 企业发展初期数据产品不成熟，经营管理会上不同部门（产品、运营、销售等）一起给老板开会汇报业绩，发现数据对不上。于是为了方便排除数据问题，就形成了指标统计口径说明字典，那个时候在线文档还不流行，主要是excel或者Wiki维护。 主要问题：信息传递困难、流程不清晰、更新不及时，且无法和报表产品联动。指标管理平台1.0的版本首先先要把指标统计口径能够线上化维护起来，并且可以把信息输出给下游报表应用，鼠标悬浮时，tooltips就可以展示指标说明。 2.统一指标口径的业务流程规范 有了指标字典，还是没法解决数据对不上的问题，于是老板给数据部门下了个需求，数据团队牵头把指标口径统一一下，下次会议不要再出现会上对数的问题了。 于是，数据PM想了个办法，新增指标需求的时候，要有统一的流程，业务部分申请，数据分析师审核，数据PM整理需求，数据开发进行数据报表开发，把这个流程集成到指标管理平台当中。并且可以通过工单流转的方式，进行IM或者邮件的提醒。 这样一来，流程是规范了，但是牺牲的是指标开发效率，比较涉及不同角色协同。对于指标数量比较少，且更新不频繁的业务是没问题的。 3.指标的数据统计逻辑 业务统计口径是明确了，但业务经常反馈数据问题，数据开发排查时，要逐层翻代码才能知道这个指标使用的是哪个数据源，SQL逻辑是什么，每个任务光点开操作就要好几层，有时不小心误操作保存了，就导致了数据bug，所以，指标还需要和数据源绑定。 有了指标和数据源的映射，就可以把指标血缘做起来了。 指标血缘是指可以链路追踪指标数据加工的来源，以及输出的报表或API应用，当业务端质疑指标异常或需要确认指标口径时，可以基于血缘工具找到产出表，以及最源头的数据来源。同时，当数据质量监控测发现数据质量问题时，可以及时反馈到下游应用，应用端对用户进行提醒，避免错误的数据给用户带来负面的决策影响。 通常数据血缘是服务于整个数据中台体系，所以指标平台可以复用公共的血缘查询能力，没必要单独建设，只需要把平台内的模型、数据集、指标、应用的关系数据采集好，反馈给血缘模块，血缘模块进行数据链路扩展即可。 4.指标数据API接口输出 主要是在做定制化Dashboard或者可视化大屏开发时，需要前端开发改造Echart，Java后端开发写接口查数据开发清洗好的数据表（根据数量大小和实时性要求，放到不同的查询引擎，如MySQL，Greenplum，Clickhouse等）。 这样一来，一个可视化页面可能就需要一周的时间。对于报表需求来说，就是指标和分析维度，指标API的结构相对固定，能不能让系统配置化，而不是Java开发写没技术含量的代码呢，这里其实有点低代码和中台的意思了。因为指标已经和数据源绑定，查询逻辑也有了，自动生成一个查询体的接口，通过一些JDBC/ODBC的链接返回数据，给前端画图使用。 5.自助式指标分析 数据化运营促使人人都需要用数据，会员业务部要看会员的订单量，营销部门要看活动订单量。都是一个订单数指标，限制条件不同。标准化的指标生存流程已经很难支撑业务爆炸式增长的数据需求。所以，业务人员开始手写SQL或者推动公司自研或者外采自助BI产品。 知道了数据集、字段含义后，自己拖拉拽进行可视化分析，配置可视化Dashboard。这样一来，定制化开发的可视化报表需求越来越少，主要在一些大屏或者给管理层使用的定制化功能方面了。 这个时候，指标平台想要发挥余热，就要和自助BI分析结合（自研产品），把指标管理平台作为一个数据源类型，用户可以直接选择指标、共有的分析维度，借助自助BI的可视化配置能力，基于指标配置报表。毕竟相比较基于数据模型来说，指标的加工程度更高。 6.智能AI指标分析 ChatGpt火了后，各行各业都想着蹭上热点，很多人担心被AI替代。对于数据结构化程度较高的指标管理平台，天然就有了可以和AI结合的优势，18年在携程的时候尝试做过一个数据问答的产品，即用户输入数据指标需求，通过知识图谱返回指标的拆解分析。现在AI更加智能，能够做的事情和功能会更加强大。比如昨天App订单数是多少？帮我做一个营销效果分析的报表（利用NLP和AI把营销域的指标呼唤出来，组合成一个可视化报表）。 二、指