数据指标是数据化管理的核心内容之一，从事数据工作的同学相信都经历过以下场景：
1.经营分析汇报会上，产品和运营的汇报内容都包含了AppMAU指标，但是数据却不一样，老板“什么情况，谁的数据是准的！”
2.数据可视化平台上，经营概况页面上有一个指标叫券后营收，营销概况有一个指标叫优惠券抵扣营收，两个指标什么关系呢，数据相同（指标口径一样，名称不一样）。
3.数据产品上很多指标看名称并不理解指标含义，指标文档维护，线下传播，想确认一个指标的统计逻辑要几经周转。
同名不同义，指标名称相同，统计口径不一致，缺少命名规范限制，不同业务仅从自己部门出发，缺少全局视角，如财务口径的营收要严格按照严谨的逻辑计算实收实付的每一分钱，而产品/运营端则更多考虑转化效果，但在各自的KPI监控报表中，都把指标命名为营收。
同义不同名，指标统一逻辑一致，但不同产品命名不一致，不同阶段、或不同业务方/产品经理对指标命名不同，导致在不同数据产品页面，同一指标不同名。
口径不清晰，只是同义词再复述一遍，如活跃用户数：访问用户数。
命名难理解，表意不清模棱两可，或过于专业化仅指标创建人才可以懂。例如转化率指标，有创单转化率、成单转化率，直接叫转化率可读性就非常差。
逻辑不准确，指标口径描述有误，例如UV指标，口径描述为“按照设备ID去重”，实际上不同平台去重逻辑并不一致，如微信小程序按照UnionID去重、APP按照DeviceID去重，PC和H5按照loginkey去重。
数据难追溯，数据产品指标数据来源缺少直观的链路追踪能力，指标数据异常问题排查通过翻代码去看数据来源，路径长，耗时久，早上业务反馈指标问题，排查出结论后可能一上午就过去了。
数据质量差，指标管理常见的问题综合在一起，往往会导致业务对数据指标的信任度大打折扣，发现数据波动后，第一反应是先和数据部门确认数据是不是有问题，而不是去考虑业务上有何变动。
指标化管理的概念很多年前就存在，各个互联网公司都在建设自己的管理平台，学习了很多关于指标管理系统建设的文章会发现，做的事情大同小异。主要是围绕指标管理的痛点问题，以阿里的OneData理论为方法论依据，相同的事情只要做一遍，剩下的是提供产品化的解决方案，让指标建设、指标复用更加的规范和高效。主要包括：
建立指标生产协同机制，指标的诞生要经过需求申请、审核、数据开发、上线应用流程，收口指标创建过程，避免指标建设的随意性带来的“污染”制定指标命名、口径说明规范，按照原子指标+业务限定+统计维度的方式，将规则集成到平台内，通过系统规则来把控指标输出。
指标字典线上化，解决线下文档（excel）管理指标存在的共享难、更新不及时、权限管控缺失等问题。指标数据逻辑绑定，即除了维护指标的业务元数据外，还要建立指标的技术元数据，指标数据从哪个模型、哪个字段、何种计算逻辑得到指标输出，指标管理最大的价值还是为数据产品提供数据输出，将Hive层模型同步到MySQL、Greenplumn、Kylin、CK等查询性能更优可以秒级响应的查询引擎，通过接口调用JDBC连接方式直接获取数据。
（1）指标字典
目标：指标业务元数据、技术元数据信息查询和检索，在线、共享式的指标字典，方便用户快速找到目标指标，确定统计口径，申请权限，直接复用数据，提供一站式指标应用服务。
指标列表：提供所有公开指标列表展示，元数据不设权限，使用时需获得授权，以促进指标共享、减少重复开发。列表展示最关键信息，列表字段默认展示最关键信息，可以设置表格字段，操作列固定。
指标操作：查看和编辑到指标详情页，查看页面是禁用状态。当有指标权限时，可以直接使用，无权限需要申请权限。更多操作包括：删除、监控、血缘查询等功能。
添加指标：指标开发人员直接进入指标编辑页面，其他角色进入指标需求申请弹窗。开发者角色需要填写指标的业务基础信息，并绑定数据源。
指标应用：指标经过分析/产品验证通过后，即可在指标字典列表中查看，用户可申请权限使用。指标输出到其他数据产品，由系统拼接每个指标和应用方式对应的查询SQL，生成API接口，应用端每次只需要传入指标标识、Where条件（筛选条件）、GroupBY字段（维度），即可获取对应指标和维度的数据。
要想达到指标口径的统一，还需要建立业务、数据产品、数据开发、数据分析、应用开发的协同机制。所有业务都可以提交指标需求，但需要经过指标审核进行评审审核，确认指标是否已经存在、需求是否明确，评审通过后，由数据开发进行指标配置，如果指标所需的数据模型已经存在，可以直接进行配置，否则需要先进行ETL工作，构建模型，数据开发配置指标并自测完成后，交付数据测试人（数据产品兼任或专职QA），确认没问题后，指标上线。业务开发接入应用到数据产品页面。详细工作流转见下图：
相应的，指标管理平台的用户需要划分为以下几类角色：- 普通用户：可以申请指标需求，查看指标口径，使用自己有权限的指标。
- 指标审核员：负责审核用户提交的指标需求，一般由数据分析师、数据产品或数据开发担任。
- 指标开发人员：数据开发担任，负责指标生产、运维及管理。
- 数据测试：验证数据准确性，一般数据产品或分析担任。
数据集管理和数仓建设模型管理的区别是：数仓模型建设是面向主题的，而指标管理的数据集模块一般是面向分析的，联系是数仓模型可以作为数据集的数据源，在分析应用时，在进行模型的关联。指标基于数据集进行逻辑规则配置后，在数据产品端输出，因而在查询性能方面要求更高，因此数据集模块另一个作用就是把Hive层模型推送到MySQL、Clickhouse、Greenplum等适合OALP即席查询分析的引擎。
数据集创建过程支持SQL代码模式和模型可视化配置两种模式，数据集支持权限审批流程设置，默认审批流一般为业务发起，发起方上级审批（确定的确有必要使用），数据集负责人审批。还有一种场景是数据集是数仓人员为某业务线创建，使用权限的审批该有业务负责人审批，或者加入其它个性化流程，此时选择自定义审批流程可以支持用户自己定义审批节点及审核人。
关联维度：数据集模型用到维度字段枚举值映射操作。即建立模型维度字段与维度表字段映射关系，指标应用到对应维度时，直接获取枚举值。
指标血缘是指可以链路追踪指标数据加工的来源，以及输出的报表或API应用，当业务端质疑指标异常或需要确认指标口径时，可以基于血缘工具找到产出表，以及最源头的数据来源。同时，当数据质量监控测发现数据质量问题时，可以及时反馈到下游应用，应用端对用户进行提醒，避免错误的数据给用户带来负面的决策影响。通常数据血缘是服务于整个数据中台体系，所以指标平台可以复用公共的血缘查询能力，没必要单独建设，只需要把平台内的模型、数据集、指标、应用的关系数据采集好，反馈给血缘模块，血缘模块进行数据链路扩展即可。
系统管理提供资源权限管理、用户权限管理、数据权限管理的功能，即通过管理和追踪某一指标有哪些用户有权限，或者某一用户有哪些资源权限，来保证用户只有权限看到相应的数据，以此来保证数据安全。系统管理主要包括：
资源管理：指标资源、数据集资源、维度资源的引用次数、访问频率，可直观展现资源的使用情况以及权限范围；
数据权限：主要是指标、维度以及数据集的字段权限管控，例如订单数指标可以区分地域维度，不同城市的城市经理只可以查看自己所负责的区域，因此需要对区域维度的维度值进行权限管控。用户管理：查看用户信息，以及所拥有的资源范围，并对用户角色、权限进行管理和绑定。
角色管理：主要是解决批量管理用户权限的问题，例如给运营角色开通对应权限后，绑定这个角色的用户都具有相同的权限，不需要再逐个开通。角色管理解决通用权限需求，用户自定义申请或资源权限绑定解决个性化权限需求。
从指标管理平台提供的解决方案可以看出，主要是指标建设流程的规范化，以及指标生产到应用流程的全链路产品化。流程的规范化涉及一个指标需求在不同工种之间的需求流转，在系统初期指标上线效率整体还是比较低的。再者就是数据中台的思想是提高数据输出效率，很多数据中台的产品解决方案会包括自主BI数据产品，即产品和运营可以直接基于数据集进行拖拽式的分析和可视化报表配置。规范化和自助化存在交叉和冲突。不做指标统一管理，指标永远是错综混乱，指标标准化，一定程度又会影响数据分析的时效性，那到底该如何权衡，或者确定好指标管理平台的目标和边界呢？指标的建设是需要长期的积累和完善的，可能规范化的初期会有一段时间的阵痛期，但随着平台内指标的丰富，新增的需求可能会越来越少，即可以确定的是对于业务条线多的企业是需要将指标统一管理，对于在公共层面的通用指标，必须由指标管理平台统一生产和管理。而对于一些业务临时性、个性化强的指标或者数据报表需求，可以基于自助BI工具，以及SQL取数工具等，快速自助化获取所需的数据即可。例如，某运营部门需要对端午节新上线的一个盲盒活动进行数据监控分析，直接基于盲盒数据模型，利用自助分析进行可视化配置的效率远远高于先生产指标，再利用指标的流程。
指标管理平台是可以帮助企业进行指标规范化管理的有效工具，但规范化带来的牺牲就是流程的冗长和效率问题。对于共用的指标以及缓慢变化的业务，可以基于系统进行管理和维护，而对于小范围的业务条线以及时效性要求更高的业务场景，可以用自助BI等产品加以辅助，但最终的原则一定是公共指标系统化管理、流程化生产。另外，指标输出应用场景方面，还可以继续扩展如指标波动监控、分析报告自动生成推送等能力，把指标管理平台作为数据中台能力的出口之一，不断完善系统功能。
<END>