指标生命周期管理
前几天一个同学前来诉苦，说他们公司指标太混乱了，一大堆相似的指标，每次用起来都要花大量的时间去确认到底该用哪一个。时不时就会出现彼此对不齐的情况，业务部门满意度不高，数据部门也比较痛苦。受到这个的启发，决定把之前处理类似问题的经验总结下来，希望对大家有所帮助
一、指标上线
一个指标上线前，要明确指标的各种元数据信息，其中包含指标中英文名称，指标类型（原子、派生、复合），指标等级（业务、安全），指标分类（业务、主题、标签），指标负责人（DS、DE、业务）和指标口径（业务、技术）。以上都是最基本的指标元数据信息，实际在业务落地中，可能还会配置支持查询的数据源、指标支持的维度等。
这些的核心是要保证指标的规范和标准，具体的操作方式和需要注意的点举例如下：
- 指标命名：指标命名要有遵循一定的规范，避免出现有的指标用中文“安卓”，有的指标用英文“Android”，这样的情况
- 默认含义：一些默认的含义要提前预定好，避免出现歧义。例如时间指标单位有的是分钟有的是秒，如果默认是秒，那指标单位是分钟的时候就需要进行特别标识。再比如曝光默认是指只要1个像素曝光就算，如果是有效曝光（不同情况下，有效曝光的定义也可能不同）要特别说明。
二、指标使用
指标上线之后，就要开始对指标各方面的情况进行例行监控，发现问题及时处理，以免影响业务。
1. 使用量监控
对指标的使用情况进行分时间段监控，例如配置近30天、90天、180天指标的使用情况的报表，最好包含指标中英文名称、业务负责人、数据负责人和被引用次数等信息。如果之前没做过指标的清理下线，并且业务也发展了一段时间，可能会发现多数指标使用的频率非常低甚至都没有使用（之前出现过近30天，70%多的指标都没有被使用），这些指标是应该被识别和处理的。
2. 一致性监控
一个指标的业务口径往往可以明确且唯一，但技术口径可能会存在多个。例如一个指标在Hive中有，同时也在StarRocks中有，正常情况下不同数据源不同表中出来的数据应该是相同的。但实际在使用过程中，难免会出现数据对不齐的情况，这时就需要检查哪个数据源出现了问题，保障不同数据源不同表产出的同一个指标的数据是一致的。
三、指标下线
随着业务的发展，指标覆盖的场景越来越多，粒度也往往会越来越细，同时一些业务口径也会进行调整，这样就会使得指标的数量会越来越多。指标数量的膨胀不仅浪费存储资源，也会在使用时造成更多的困惑，我们不得不花时间去区分一些相近的指标，进而确认具体使用哪个指标。
基于这样的情况，我们要形成指标下线的流程，具体触发下线的标准可以基于业务和数据量决定。如果现在业务在初期，数据量也并不大，可以把下线阈值放大一些，如果现在数据存储压力大，或者在使用的时候相近的指标已经造成比较大的困扰，这时可以把阈值设置的小一些。
当确认一些指标要下线时，不能简单粗暴的删除，这里主要要考虑两个方面。
一是因为有的指标可能业务只是暂时不用，其实以后还会用到。例如有些指标只在阶段性评估时使用，这样就造成使用间隔比较久，但确实是需要使用的。
二是还可能存在一些对当前指标的依赖，如果删除会造成一些报错。例如有的报表使用了该指标，删除后可能会造成报表整体异常或部分异常。同时一些复合指标使用了该指标，例如ctr = 点击数/曝光数，如果删除了曝光数，ctr也会出问题。
结合具体的业务情况，具体处理的方案有很多，这里提供一个之前使用的方案共大家借鉴：
- 业务沟通：和业务进行沟通，明确指标是否还需要继续使用，如果反馈不需要进行第二步
- 指标下线：对指标进行下线处理，下线意味着不能再基于指标新增报表和指标，但之前使用到指标的地方不受影响，还可以进行进行查询。这一步相当于关闭入水口。
- 指标删除：对使用到下线指标的地方进行删除或者替换，完成后对指标进行删除，删除前最好使用邮件或者群聊的方式周知相关方
上面聊到的都是具体处理问题的方案，但更重要的是方案的执行，要让大家都严格按照一套规则去做事，其实有的时候更难，后面有机会再详细聊聊如何推进落地。
作者：暮雪云然 一个会写代码的数据产品经理版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
