编辑导语：管控治理类数据产品是更高能力要求的一个细分工种，它需要我们具备数据分析以及工具建设能力的同时，还需要我们拥有团队统筹等多方面的能力。作者分享了他的数据治理策略，我们一起来看下吧。
一、前言
为什么想开这个话题，一是因为目前业内数据产品也基本完成了从0-1的建设工作，但主要集中在数据生产加工和数据应用分析两侧，对于数据管治方向的建设多分散在了包括安全、指标元数据、SLA等在内的各个环节，缺乏统一的规划统筹。
笔者认为，数据产品可以分为工具类数据产品、业务分析类数据产品和管控治理类数据产品三类，而工具类数据产品和业务分析数据产品市面上也开始趋近饱和，但管控治理类数据产品其实是更高能力要求的一个细分工种，既需要懂工具建设也需要懂数据分析，还需要具备跨多团队横向协调的项目推动能力和策略运营能力。
二呢，笔者曾经就做过一次失败的大治理工作，也做过一次相对成功的安全治理工作，也参与过指标监控、安全工具等的建设，所以也想把这其中那的成功和失败的经验分享出来供大家参考。
二、概念定义
根据笔者的研究，目前业内数据治理总结起来一共分为两类，一类是狭义的数据治理，是指数据指标口径一致性的治理，此类数据治理主要是解决指标口径的一致性，解决数据“不准”的问题，也由此引申出一些智能数仓、指标元数据工具，比如美团的起源、快手的盖亚、阿里的dataphin等等。
另一类是指广义的数据治理，是指包括数据指标口径治理、数据安全治理、数据资源成本治理、数据资产元数据治理、数据产出治理等在内的大治理，此类数据治理是需要综合解决数据从采集加工到应用分析再到销毁全生命周期内的口径、成本、安全、合规和产出问题。
在工具建设上，目前笔者看到的多是分散在数据安全、资产中心、SLA中心等不同的产品领域。
三、结论先行
这次笔者就不卖关子了，直接抛观点，笔者认为，数据治理战略层面的设计总结就两点：
第一，数据治理是一个系统性工程。
数据治理主要面对三个问题，一是用户心智培养问题，二是组织保障问题，三是系统提效问题。
所以，单纯从组织保障层面发力会面临效率和质量不高成本却奇高的问题，单纯从运营机制建设层面发力会面临缺乏组织和工具来落地策略的问题，单纯从建设工具发力会面临缺乏组织抓手且找不到核心使用用户，需求无法进入正向循环的问题。
以上问题一句话总结就是靠组织无法长期有效，靠运营无法落地实施，靠工具又缺乏用户和需求持续跟进，因此，数据治理是一个需要组织保障、运营实施和工具建设三位一体跟进的工作。
第二，数据治理又是一个抓大放小的工程。
世界本质是一个熵增的过程，即任何事物本质是一个自发的由有序向无序发展的过程，这个既是人性也是客观规律，而数据治理本质是减熵的过程，是建立秩序，因此任何的治理本身是逆人性和逆客观规律的，需要源源不断投入能量（资源）才能维持熵值平衡。
但问题就在于，人性天然有建设性和破坏性两面，想要秩序的存在并维持下去，本身就是需要投入非常大的建设精力和成本的，而且这个成本还不是一成不变的，它是随着公司资产的累加而增加的，也是会随着公司战略、制度和文化的革新变化而变化的。
因此，数据治理工程中追求完美主义是不可取的，我们要学会分类分级，学会判断优先级，学会抓大放小，允许有序和无序的并存。
四、问题分析
数据治理到底解决什么问题？或者说什么问题的存在才需要数据治理？首先，我们来场景化模拟下数据从诞生到销毁的一生中遇到的主要问题。
场景1：小明是A视频公司的策略产品经理，工作职责之一就是分析用户的特点和行为习惯，从而帮助算法工程师优化视频推荐策略，从而提高用户对视频APP的使用黏性。
这天，小明抽样了部分用户浏览行为数据，发现部分用户单位时间内视频切换速率较高，停留时长较短，且点赞和关注数都较少，小明猜测是算法推荐的质量有问题，小明找了算法RD，算法RD却回复最近视频推荐的准召率（准确率和召回率）没有问题，并没有出现下降，肯定不是算法的问题，是视频内容质量的问题，或者是抽样数据的问题。
小明很苦恼，为什么数据分析下来，小明觉得用户对视频的喜好度是不够高的，但研发说准召率却没问题，那问题出在哪？
场景2：小红是B咨询公司的新来的数据分析师，最近她接到一个任务，需要为客户的一个市场咨询报告提供数据分析支持。
因此小红从业务经理那里了解完需求后，开始从公司数据库和第三方数据库获取数据，但事情却一波三折，就单单在业务数据分析的定义上就来回沟通了好几次，业务经理告诉小红她想知道a指标的数据，小红翻阅了前人关于a指标的统计口径记录发现，a指标居然有不下10个统计口径，诸如a1字段在x1维度下的聚合、a2字段在x2维度下的聚合等等，到底应该遵循哪个规范？
结果咨询一堆同学，发现每一个口径都有特定的需求背景和定制化规则，这一通忙活。
场景3：小东是C公司的数据RD，最近他经常半夜被各种数据跑批任务延迟和失败告警给吵醒。
原来是公司最近要迎接618，活动量的爆炸式增长导致业务数据量的爆炸式增长，而业务报表的数据统计逻辑和背后的数据源却没有及时优化，导致集群计算资源不足以支撑暴涨的需求而出现任务延迟或者失败的情况，这个情况又影响了业务报表的数据及时展示，影响了公司各业务KP邮件报表的及时性。
场景4：小阳是D公司的安全运营，最近公司上线了一个新业务，和已经上线的几家公司形成了假正经关系，然后他最近经常收到市场情报反馈，竞品公司能迅速感知到公司的投放数据和增长数据，到底是哪个环节出了问题，为什么竞品公司能这么快知道公司核心数据机密，这让他最近压力倍增？
分析以上问题，场景1其实是数据指标准确性的问题，场景2的问题主要是数据指标规范性和唯一性的问题，场景3主要是数据产出及时性的问题，而场景4是数据安全性的问题，以上，笔者认为都属于数据治理需要解决的问题。
五、治理目标
综上，数据治理的目标主要是解决以下四方面的问题：
- 规范治理：解决数据完整性、规范性和唯一性问题
- SLA治理：解决数据产出及时性问题
- 口径治理：解决数据指标准确性和口径一致性问题
- 安全治理：解决数据采集生产应用各环节中账号注册认证、权限管理、安全审计和隐私保护等安全治理问题
六、策略概述
1. 成立数据治理委员会，提供立法和组织保障
- 成立治理制度执委会，负责研究和出台相关治理制度和规范标准，目标是促成公司内各个业务团队达成共识，形成统一规范，避免信息孤岛。
- 成立治理产品执委会，负责梳理数据各环节的需求处理流程和业务流转流程，负责各环节的治理工具建设，形成可执行方案，然后报制度执委会推行。
- 成立治理技术执委会，负责数据各环节的技术定义、模型设计和口径维护，对数据资产的落库规范性和唯一性等负责。
成立第三方治理审计监察组，负责治理效果的评估、badcase的运营跟进和事后追溯审计。
2. 建设数据治理套件，提供工具保障
建设资产治理中心，目标是为解决数据元信息的完整性、规范性、唯一性提供技术支持。
- 建设SAL治理中心，目标是为解决数据生产加工任务产出的及时性和任务调度的运维提供技术支持。
- 建设指标治理中心，目标是统一指标定义、指标生产和服务，解决指标口径一致性和服务的效率问题。
建设安全治理之心，目标是为数据安全5A领域）（账号、认证、授权、审计、隐私保护）的问题提供技术支持。
七、策略详述
1. 流程保障策略
图1：数据治理流程保障规划示意图
思路：如上图所示，数据治理流程保障规划整体思路参考PDCA循环，即制定详细规范方案，然后去验证并解决问题，接着检查问题是否真实被根本解决，最后根据反馈再继续爹迭代方案，进入下一个循环。
机制：如上图所示，数据治理流程保障规划整体解决机制上分为三个部分，分别是事前预防，事中监控和事后处理。第一部分的目标是尽量将潜在问题在未爆发前就消灭掉；
- 第二部分的目标是尽量将问题都找出来，减少影响范围；
- 第三部分的目标是对暴露出的问题进行快速响应和解决，并总结经验。
整体流程：如上图所示，数据治理流程保障规划整体流程上将以解决数据质量六性问题（唯一性、规范性、完整性、准确性、及时性、安全性）为目标，按照“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程，贯穿整个事前、事中和事后的环节。
具体实施：如上图所示，数据治理流程保障规划的具体实施细则上，会重点依托易龙的“数据治理五大项目模块”，然后每个模块都按照“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程进行梳理和规划。
（1）定义理想态
① 发现问题
- 召回率（覆盖率）100%
- 准确率100%
指标释义：
召回率（覆盖率）：召回率又叫覆盖率，是指所有真实存在的问题中，系统或者人工检测出的问题占比。例如一共100条数据，其中20条存在异常，系统报警显示有30条存在问题，事后被验证30条报警中真实存在问题的有10条，则召回率（覆盖率）=10/20100%=50%
准确率：是指所有被系统或者人工检测出的问题中，真实存在问题的占比。例如一共100条数据，其中20条存在异常，系统报警显示有30条存在问题，事后被验证30条报警中真实存在问题的有10条，则准确率=10/30100%=33.3%。
注意：理论上最理想的状态就是一次监控任务中，所有问题都被发现，且所有报警的数据中没有掺杂虚报情况，也就是召回率达到100%，准确率为100%。
但是实际场景中，这样的理想情况几乎是不存在的！过度追求高召回率，监控规则一定会设置的异常简单，那往往会有很多正常的波动会被系统判定为“异常”。
同理，过度追求高准确率，监控规则一定会设置的异常苛刻，那自然被报警的数据都是存在异常的，准确率100%，但是这样往往很多异常数据会被监控系统给漏掉，漏报率就会异常的高！
因此，优秀的监控系统都是根据实际场景一直在找寻召回率和准确率间的平衡点。
② 解决问题
- 响应时长：24小时内响应问题
- 定位问题：3天内完成问题的定位
- 解决问题：2周内彻底解决问题
③ 数据通道质量
- 丢失率<0.1%
- 重复率<0.1%
- 延迟率<0.5%
（2）规范建设
① 唯一性
- 指标、纬度、模型、库表、数据、报表的唯一
- ID唯一
- 名称唯一
- 定义唯一
- 加工逻辑唯一
- 产出渠道唯一
- 相似的指标、纬度、模型、库表、报表做减法，减少冗余
② 规范性
- 流程规范
- 需求→评估→处理→测试→上线→验收环节严格执行
- 数据和流程double check
- 测试、试验验证数据质量和流程执行情况
- 日志、库表、模型、报表、代码有统一的设计和输出规范，信息齐全、分层合理、资源使用合理
③ 完整性
- 日志、库表的元信息完善，灰度测试阶段只有空值率、异常值占比、分区缺失等指标合格后方可上线发布
（3）发现问题：监控体系建设
如图2和图3所示，对于重要级别的日志、指标、库表数据，除了粗粒度的质检外，还需要每天进行更加严格和科学的监控，以提前发现问题并推动解决：
图2：数据埋点质量监控报表
图3：数据指标准确性监控报表
① 完整性（是否缺失或不可用）
- 日志
- 丢失率
- 库表
- 丢失率
- 分区缺失
- 信息缺失（0、空值、NULL）
② 准确性
- 业务侧
- 相同指标不同报表间建立交叉验证
- 相同报表不同指标间建立逻辑验证
- 相同报表相同指标建立波动验证
- 技术侧
- 埋点间的交叉验证
- 多层库表间相同指标交叉验证
- 明细层和统计层建立数据量、行数、计算结果的比对验证
③ 及时性
- 日志上报
- 有效上传率
- 延迟率
- 资源使用
- 当前占用占比
- 剩余资源占比
- 任务调度
- 完成率
- 失败率
- 延迟率
（4）问题分级
① 监控分级
- 对业务的影响度
- 模型、库表、报表使用热度
- 作业耗时热度
- 故障分级
② 预警分级
- 蓝色预警
- 黄色预警
- 红色预警
③ 报警方式
- 电话
- 邮件
- 短信
- 企业微信
（5）事后处理
① 问题跟踪处理
- 问题分发（按业务、主题、部门等划分问题归属）
- 问题跟踪
- 问题原因追溯
- 问题解决排期
- 问题解决反馈
② 问题验收
- 业务验收
- 监控系统验收
③ 定责存档
责任划分：以“规范建设-质检审查-发现问题-评估问题-解决问题-验收问题”的闭环流程为切入点，将“需求规划组、模型工程组、质检监控组、审计评估组、数仓工程组、应急响应组”分别配属到对应的环节中去，以提供流程执行的组织人力保障。
平台支持：重点建设埋点管理平台、元数据管理平台、质检监控平台、工单管理平台，为各流程环节中的组织人效提供帮助和支持。
具体实施：如上图所示，数据应用PM、数据平台PM和模型工程师将对整个数据治理组织和平台的健康高效运转负责，并对其向数据治理委员会汇报。
（1）成立数据治理委员会，提供立法和组织保障
- 成立治理制度执委会，负责研究和出台相关治理制度和规范标准，目标是促成公司内各个业务团队达成共识，形成统一规范，避免信息孤岛。
- 成立治理产品执委会，负责梳理数据各环节的需求处理流程和业务流转流程，负责各环节的治理工具建设，形成可执行方案，然后报制度执委会推行。
- 成立治理技术执委会，负责数据各环节的技术定义、模型设计和口径维护，对数据资产的落库规范性和唯一性等负责。
- 成立第三方治理审计监察组，负责治理效果的评估、badcase的运营跟进和事后追溯审计。
（2）项目落地实施划分一系列项目小组
- 成立需求规划小组，对所有业务需求的接待和规范负责
- 成立模型工程小组，对接数据应用PM，对数据从业务关联到技术侧的文档和规范负责
- 成立质检监控小组，对数据业务测试和技术测试的实施负责，对数据上报的质量筛查负责，对数据质量的监控负责
- 成立审计评估小组，对上报的问题评估定级负责，对问题的合理分发和处理进展负责
- 成立数仓工程小组，对数仓的规范建设负责，对问题的修复负责
- 成立应急响应小组，对紧急高优先级的需求快速高质量负责
3. 运营思路
数据治理项目规划地图横向一共分为机制、流程保障、细则、责任划分、工具平台和各个子项目模块（包括日志埋点模块、通道传输模块、内容规范模块、加工过程模块、语义定义模块）数据治理项目机制划分为：事前预防——事中监控——事后处理。
数据治理项目流程保障划分为：规范建设→质检审查→发现问题→评估问题→解决问题→验收问题。
图5：数据治理项目规划地图
八、结语
本期主要从数据治理的问题分析、治理目标和治理策略进行了阐述，下期起将重点介绍数据治理涉及的相关工具和平台建设，包括资产治理中心、SLA治理中心、安全治理中心和指标治理中心等，欢迎关注~
作者：明明，美团数据安全与易用性工作组PM，在线教育行业双师直播模式的第一批参与者，立志成为一名受人尊敬的产品经理。
产品教练
若有收获，就点个赞吧
0 人点赞
