：数据服务于业务，因为业务是在不断的发展，所以当数据建设到了一定阶段的时候，各种问题随之而来，既有底层数据模型过于冗余、链路过于复杂等问题，也有业务侧使用数据时的体验问题。

当大家谈到数据治理时，常常都想从根本出发解决问题，指定一系列指标规范，建模规范，借助元数据管理工具完成强制实施。开发侧做了很多动作，但往往会出现业务侧无感，形成开发同学自嗨的局面。

笔者在实践过程中从用户体验的角度出发，推动数据治理的落地，让业务同学直接体验到数据治理带来的数据服务升级。

由于本文所讲的内容，更多是业务线服务（数据 BP）中沉淀的经验，所以对服务于具体业务线的数据开发/产品更有借鉴意义。

02 方法论

2.1 现状分析

：笔者服务的业务对于数据的使用 90% 的场景都基于自助计算，但目前指标维度数据易用性较差，导致业务使用成本高，甚至多次因为指标混乱而取错数。

核心原因主要有两个：一方面建设过程中，对于核心指标体系不清晰，所以拓展了很多阶段性的指标维度另一方面由于业务经历多年的发展，数仓围绕许多 “昙花一现” 项目做过建设，业务下线后指标维度未做梳理下线。

：针对业务相关的数据集（基于业务线划分的指标维度集合）做指标维度的治理，降低数据集使用的难度并沉淀出一套适用业务服务体系的数据集治理 sop 雏形。

2.2 

贴合业务实际使用情况，梳理指标维度当前存在四类问题：

1）大量命名擂台的指标（中体内容量/内容量/中台内容量-去重），从表面完全看不出具体差异。有新老模型的原因，也有不同场景下对应的元数据系统中取数方式不一样的原因

2）复合指标冗余严重：比如 “新增中台发布态内容量” 类指标非常多，可以考虑通过维度组合核心指标的方案实现（限定「是否当日新增内容」维度下的「中台发布态内容量」）

3）指标命名不规范（如：信息流_侵入态曝光_七日留存率，并不知道是什么动作到什么动作的留存）

4）指标注释无法说明其真实意思（中台内容量：“中台内容量（状态不限）”。其实底层是限定了发布态的）。

1）商业分析同学基于对业务的理解，归纳出核心指标维度体系

2）数据产品对出现以上四类问题的指标维度做重点标注说明

3）业务方根据指标维度的使用热度及业务需要，确认指标是否可以下线

4）数据开发对于可以简化通过维度组合计算的指标给出建议（比如：「是否当日新增内容」维度 与「中台发布态内容量」指标做出新增内容漏斗，原先的新增指标可以砍掉）。

整个过程由数据产品经理发起主导，其他角色的同学从自己的专业知识上提建议。

优先做指标维度的表层治理，提升业务侧可感知的数据体验，对应不同的情况应用层做三类动作：

1）不规范指标重命名（对于命名不易理解，不规范的指标维度，按照公司标准重新做命名）

2）无用指标/数据模型下线（部分指标维度不再使用的模型做字段下线对应所有指标均已经确认可下线的模型做模型下线）

3）同义不同名维度/维指标做整合（举例：笔者所在团队，造成同义不同名的维度的原因主要是因为前期数据建设不规范，例如对城市名称维度，不同事实表模型接入了不同的城市维度表，而不同维度表中对该字段有不同的命名，我们需要对各事实表模型中用到的维度表做统一即可）。

在指标维度表层治理完成后，数仓进一步展开数据链路的优化工作，做深层的数据治理，更多帮助提升底层数据建设效率、数据生产效率。

2.3  

项目结束后，业务指标从 200+ 个精简至约 80 个，维度从 150+ 个精简至约 70 个。治理成果上线后业务侧反馈：“确实提效了！再也不用担心点错指标了。同时让其他协同的业务方用数据集的时候也降低了沟通成本”。

03 总结

项目实践中值得总结的思想：

 。由表及里实施治理，先从业务最能感知到的指标维度层做精简操作其次再提高业务使用过程中的速度体验，从底层根本去治理数仓链路，同时达到长期降低数据开发成本的效果。

，协同 ba 及业务方一起思考优化方案，不仅从多角度保证了最终实施成果的可靠性，也能让相关方感知到数据治理这个非常底层的工作。最终才得以让治理项目获得斐然的成果。

-END-