1. 先搞清楚数据治理到底在治什么1.1 一个被过度包装的概念三个真正要解决的问题做了这么多年数据工作最怕听到的一句话就是我们要上数据治理。这句话一出往往意味着接下来半年一群人会围着一堆概念争论不休而业务部门在旁边看得一头雾水。数据治理体系、数据治理平台、数据质量、数据标准——这四个词几乎出现在每一份方案PPT里但真正把它们讲清楚、落到实处的少之又少。如果抛开所有包装数据治理本质上只解决三个问题数据能不能被信任、能不能被找到、能不能被合规使用。能不能被信任看的是数据质量能不能被找到看的是元数据和数据标准能不能被合规使用看的是安全策略和权限体系。所谓数据治理体系就是围绕这三个问题搭起来的一套组织、制度、流程和工具的组合。所谓数据治理平台则是把这套组合落到系统层面的载体。很多人觉得数据治理是技术问题其实它在前期更像管理问题。我见过不少企业买了昂贵的数据治理平台元数据采集、质量规则、血缘解析全配好了结果三个月后还是没人用。原因很简单公司里没人对数据负责业务部门觉得数据是IT的事IT部门觉得数据是业务的事。数据治理平台再强也解决不了责任真空。所以在看任何一份数据治理PPT或者方案之前建议先问自己一个更基础的问题我要解决的是老板焦虑、监管合规、还是实际业务报表对不上不同答案对应完全不同的治理路径。1.2 治理、管理与运维的边界还有一个被搞混的概念数据治理和数据管理到底什么关系我的理解是数据管理是日常执行层面的事比如数据库运维、报表开发、ETL调度、数据备份恢复数据治理是决策和规则层面的事比如指标口径统一、数据质量要求、数据分级分类、权限审批流程。治理定规矩管理守规矩。平台和数据中台则是在这两个层面之上提供技术承载。很多项目失败就是因为把治理做成了运维。上来就抓元数据采集、建血缘关系、配质量规则但指标口径没有拉齐、数据责任人没有指定、跨部门的数据共享协议没有签。结果平台跑起来了人没跑起来规则也没跑起来。这也是为什么我会建议后来者接手数据治理工作先花两周做现状摸底画一张数据流向图和一张责任人清单比急着部署平台有用得多。下面要展开讲的体系、平台、质量、标准这四个部分也是按照这个逻辑来组织的先理解框架再选工具最后抠细节。这份116页PPT里其实也是类似的顺序后面我会专门拆解它的内容结构。2. 数据治理体系的四大支柱拆解2.1 数据标准一切治理的锚点没有标准的治理等于在流沙上盖楼。我参与过的项目里凡是数据治理效果差的几乎都能追溯到标准缺失或标准形同虚设。举例来说一家集团企业有三个子公司A公司把客户编号叫CUST_ID字段长度10位B公司叫CUSTOMER_NO长度12位C公司更随意叫KHBM而且是字符串和数字混用。总部要做客户统一视图光这一步就对不上。数据标准要解决的就是这类问题。它通常分三层来建基础标准数据类型、长度、格式、命名规范、数据元标准业务含义、值域、编码规则、指标标准统计口径、计算公式、时间维度。很多PPT会把这三层画成金字塔但在实际落地中我建议不要追求一步到位先抓住单位、编码、口径这几种高频冲突点。一个比较实用的筛选原则找出全公司查询最多、共享最多、报表最多的20个核心数据项把这20个数据项的标准先定死。别贪多20个跑通了再扩到50个、100个。我在第5章会专门讲数据标准落地的具体阻力这里先记住一句话标准最大的敌人不是技术是业务习惯。2.2 数据质量可度量的治理效果数据治理做得好不好不能靠感觉要靠度量。数据质量有六个经典维度完整性、准确性、一致性、及时性、唯一性、有效性。这六个维度几乎覆盖了日常数据问题的全部类型——字段空值属于完整性数值算错属于准确性多表口径不一属于一致性数据延迟属于及时性重复记录属于唯一性格式错误属于有效性。有意思的是很多企业上线质量平台后最关注的不是这六个维度里的疑难杂症而是最简单的空值率。为什么因为空值率好统计、好汇报。这也没错但光看空值率远远不够。我在一个制造企业的项目里见过这样的情况所有产品的重量字段都没空值看上去完整度100%但十吨和十公斤都填成了10单位不统一导致库存统计差了整整一千倍。这个问题的本质就是数据标准缺位和数据质量规则没覆盖到。所以我的建议是质量规则的设计必须跟着业务主链路走而不是跟着平台功能走。后面第4章我会详细讲一套从规则配置到统计度量的完整方法包括用标准差、均值等统计量来监控数据波动这些都是这116页PPT里数据质量部分的延伸。2.3 数据安全合规底线的技术落地数据安全在数据治理体系里的位置越来越靠前。以前是先治理后安全现在监管要求出来以后安全开始倒逼治理。数据分级分类是典型的治理动作它要求企业先摸清自己有哪些数据、这些数据涉及什么业务、敏感程度如何然后才能定加密、脱敏、访问控制策略。一个容易踩的坑是数据分级分类变成了纯手工台账。安全部门发一个Excel模板让各业务线自己填填完收上来就再也没人更新。这样的分级分类是静态的、失效的。真正的做法应该把分级分类标签嵌入到元数据管理里每新增一张表、一个新字段都通过自动扫描加上安全标签然后由数据owner确认。数据资产清单和安全策略才会同步更新。另外权限模型也很重要。很多企业把权限控制做到库表级别但业务人员的操作往往是字段级别的。比如客服需要查看客户姓名和订单信息但不能看客户身份证号和收入。如果权限粒度太粗要么过度授权要么一刀切拒绝业务和安全的矛盾不断激化。这个部分往往在PPT里只是一页安全架构图但真正落地时是细活中的细活。2.4 数据架构与生命周期看不见的地基和前三个支柱相比数据架构和生命周期管理是最容易被忽略的。它的作用像房子的地基平时看不见出问题时整个系统都跟着遭殃。具体来说它包括数据模型设计、数据分布、数据流转链路、数据存储策略、数据归档和销毁机制。在实践里我见过最典型的架构问题是烟囱式建设每个业务部门按自己的需要接一套数据从采集到加工到应用完全独立造成大量冗余。数据血缘图一画出来密密麻麻全是线但没人能说清一条订单数据到底经历了几次转换。没有清晰的数据架构数据质量问题的定位和追溯就非常困难——出了问题不知道源头在哪。生命周期管理的核心是让数据活得合适。热数据放高性能存储温数据压缩归档冷数据转存低成本介质到期数据按合规要求销[内容缺失]。我在项目里见过最夸张的情况某系统积累了七年的日志数据占用了几十TB的高性能存储成本高昂却从来没有人查询过。做好生命周期策略不仅是治理更是实打实的降本增效。这些内容在第6章的案例里会有具体的量化展现。3. 数据治理平台选型和落地中的真实取舍3.1 平台功能清单元数据、血缘、质量规则、资产目录市面上主流的数据治理平台功能清单长得都差不多。基本配置一般是元数据管理、数据血缘、数据质量、数据标准、数据安全、数据资产目录这几大模块。但有和好用是两回事。就我的经验选平台时要重点看重三个能力能力维度考察要点常见坑元数据采集的深度能否解析到字段级是否支持自定义采集只能做到表级字段级信息缺失血缘解析的准确性能否识别复杂的SQL嵌套、存储过程血缘关系残缺图上一堆孤点质量规则的灵活性能否配置跨表校验、自定义SQL规则只支持单表空值、重复的简单规则另外还要关注平台的开放性和生态。数据治理平台很难独善其身它需要和数仓、数据中台、BI工具、调度平台打通。如果平台API能力弱集成成本会高得离谱。我在选型时都会让厂商提供实际项目的API文档而不只是看演示PPT。还有一个容易忽略的软性指标——易用性。数据治理平台不光治理人员要用业务数据owner也要用比如在线确认数据表、补充业务元数据、处理质量问题工单。如果系统交互太工程师化业务人员用几次就不愿意碰了治理流程就断了。3.2 两条建设路线先标准化再平台化还是先平台化再标准化这是我在不同企业里反复遇到的路线之争。A路线主张先把数据标准、指标口径、质量要求全部梳理清楚再选平台落地B路线认为标准永远理不清应该先买平台把数据管起来边用边建标准。两种路线都有成功案例也都有失败案例。我的判断标准是看企业数据基础如果企业连统一的数据字典都没有各部门系统极其分散那A路线会陷入无穷无尽的调研和文档编写半年都出不了成果反过来如果主数据相对集中核心系统已经上了ERP、CRM这类规范系统那A路线会更稳妥。比较折中的做法是标准先行、平台快速跟进先花两到三周聚焦20个核心数据项定标准与此同时立刻启动平台部署用这些标准去平台里配置校验规则。标准不需要全部定完才动系统用最小闭环来推动。这套思路我在第6章的案例里完整拆解过。3.3 平台落地中的三个常见误区误区一认为平台装上就自动治理了。实际层面平台只是工具规则要靠人配置标准要靠人制定问题要靠人处理。很多公司买了平台之后没有安排专门的owner结果平台成了摆设。误区二盲目追求大而全。厂商的标准产品包可能包含十多个模块但你们实际需要的可能只有三四个。全量上马光权限配置就够忙活几个月。我建议分阶段激活功能第一阶段只管元数据质量标准跑通后再考虑安全增强和数据资产门户。误区三忽视历史数据清理。治理平台跑起来之后会瞬间暴露海量质量问题。如果不对历史数据进行预处理质量报告会红成一片业务部门直接失去信心。正确做法是先在平台里设置存量与增量分离的治理策略历史数据分批清洗新增数据实时监控。这些误区在PPT的实施方法论章节里也有相应提醒但因为PPT篇幅有限它没法讲得很透。我这里多说几句就是希望正在看这篇文章的读者别再去踩一遍。4. 数据质量从规则配置到统计度量的完整打法4.1 把六个质量维度变成一条条可执行的规则理论上讲数据质量大概十分钟就够了难的是把理论翻译成SQL。拿准确性维度举例。一个订单金额字段怎么判断它准不准只能做跨表校验订单表里的金额和支付流水表里的实际支付金额是否一致或者做取值范围校验折扣金额不应该大于订单总金额。这就是把质量要求变成质量规则的常见过程。规则不是越多越好而是要和业务风险挂钩。我在制定质量规则的时候会先和业务方一起梳理关键数据链也就是一条数据从产生到使用的完整链路。以零售企业为例核心链路是商品主数据-采购入库-销售订单-财务结算。每一步都定义出主数据表和业务表然后针对每个环节设计质量规则比如主数据不允许重复、入库数量不能为负、销售订单金额必须等于商品单价乘以数量。规则要落在系统里通常分为两种模式离线批量校验和实时流式校验。离线校验适合跑数仓里的批量数据比如每天凌晨跑一次完整性、唯一性检查生成质量报告实时校验适合业务系统接口层比如在API返回数据前检查关键字段是否有值、格式是否正确。不同模式对应不同的平台配置方式。4.2 标准差、均值这些统计量在质量监控中到底怎么用在数据质量监控里很多人忽略了统计分析的价值只会用固定阈值来判断数据是否异常。固定阈值有个死穴业务是有周期波动的。比如每日订单量平时一万单左右周末两万单双十一直接冲到十万单。如果固定阈值设成日均单量大于25000为异常那每个周末和每个大促都会误报。就算你设了周末单独阈值大促当天还是会把你折腾得够呛。一个更聪明的做法是引入统计监控。比如对最近30天的业务数据计算均值和标准差然后用均值加减n倍标准差动态生成波动区间超出区间的数据点才判定为异常。标准差σ反映的就是数据集的离散程度——σ越大说明业务波动越大阈值就应该放宽σ越小说明业务稳定阈值就收紧。实际配置里我给过很多项目一个通用基线日常指标用均值±3σ作为告警线核心财务指标用均值±2σ作为预警线。以一道真实例子来说明计算方式某班级期末考试成绩平均分是80分标准差σ算出来是6分那任何一个学生的成绩落在68分到92分之外的都算显著离群。这个思路搬到业务数据上就是识别偏离正常波动的异常成绩或异常交易。这套统计监控方式尤其在银行、零售、制造行业非常实用。比如库存金额异常波动、交易量突然断崖、日活瞬时飙升用均值±3σ基本都能提前捕捉到。平台里如果自带统计监控算法最好没有的话自己写一个定时任务也不复杂——先取窗口期数据算均值和标准差再和当天实际值比较输出波动幅度和告警等级。多模态感知数据融合领域的质量评估本质上也是类似思路把不同传感器的数据先做分布估计再根据偏离程度判断感知数据是否可靠。4.3 质量规则一配置就失效问题出在哪很多人配置完质量规则后发现跑出来的问题一大堆但业务方根本不认。仔细一查不是规则本身错而是规则定义时没有和业务对齐语义。举一个我实际遇到过的例子有一家公司定义了客户联系电话格式校验必须是11位数字结果三个省份的客户数据大量报错。业务人员来投诉说这些电话是座机本来就不是11位你们的规则写错了。这就是标准定义和业务现实脱节。后来我们把校验规则改成手机号11位或者座机号形如区号-号码问题才解决。另一个常见问题是质量规则跑一遍就完。数据治理是个持续运营的活数据特征会随业务变化规则也必须有生命周期管理。新业务上线了规则要不要增加业务规则调整了阈值要不要更新很多企业的质量规则配置完就不再维护用了半年后规则已经完全失真只是在空转。所以我在做质量治理的时候有一个铁律每季度做一次规则有效性复盘把过去90天触发过的告警全量拉出来分类统计哪些是真实问题、哪些是误报、哪些是规则需要调整。经过两三个轮次的迭代质量规则的准确率能做到比较靠谱的水平。这套打法是可以在团队里复制和沉淀的。5. 数据标准不是文档是执行协议5.1 从数据元到字典的标准化层级数据标准在实际落地中分成几个颗粒度颗粒度从小到大依次是数据元 → 数据字典 → 代码集 → 指标 → 业务术语。底层的是数据元也就是最小数据单元比如客户编号订单金额商品条码每个数据元要定义名称、数据类型、长度、值域。再往上是代码集比如性别代码0/1/2代表什么、订单状态10/20/30代表什么这几乎是所有系统集成时最疼的地方。业务术语则解决同一概念、不同叫法的问题比如财务叫回款额销售叫到账金额其实是一回事。很多PPT喜欢画一个标准体系金字塔从国家标准到行业标准到企业标准一层层往下。理论上没问题实操中不能反着推——通常要先建立企业自己的标准字典。我建标准字典的习惯是先去找最核心的那几个字段比如客户号、产品编号、订单号把它们在现有各系统中的类型、长度、编码规则、更新频率全部拉出来对比再结合未来规划选择一个最合理的作为目标标准同时设计新旧映射关系。这个映射关系是数据标准能否落地的关键。5.2 标准落地的阻力和破局办法数据标准项目最难的不是起草而是让各方签字确认。业务部门来一句我们系统已经跑了十年改编码规则会死人的研发部门来一句改字段类型成本太高要动底层表结构项目就很难推进了。我的应对思路是三板斧第一目标标准适度兼容历史。不强制业务立刻改源系统而是先在数据中台和数仓里做标准化映射把物理标准和逻辑标准分开。源系统暂时不改没问题但进到数据平台里的数据必须转换成标准格式。第二找一个能快速见效的切入点。比如主数据管理里的客户主档通过标准化让客户唯一ID打通业务方马上就能看到跨系统客户合并后的价值有了甜头后面的推动就顺了。第三把标准挂进开发流程。要求新上线的系统、新开发的报表必须先过数据标准的评审。不满足标准的接口和数据模型原则上不允许上线。这一步如果公司有架构评审委员会会好推很多。5.3 标准与质量规则的联动关系很多团队分头建设数据标准和数据质量两边各干各的。这是非常大的浪费。本质上来讲标准是质量规则的输入——只有先定了标准质量规则才有依据。比如满足代码集标准的字段质量规则里才能写值域校验必须匹配代码集满足格式标准的字段质量规则里才能写字段格式校验。我在实施中会把标准配置和质量规则配置做在一个工作流里每个数据元除了有名称、类型、长度等描述还要挂一个质量规则模板。一旦数据的标准化映射关系确定系统自动生成对应的质量校验规则。这样标准变更一个字段质量规则自动联动更新不用人工去两套系统里各改一遍。有个实际数据可以说明联动的重要性在某集团项目里我们上线了380条标准数据元自动生成和调整了2100多条质量校验规则。如果靠人工在质量平台里一条条配置至少需要两三个月而且极易漏配、错配。标准质量联动后不到两周全部生效。这个设计思路建议在做治理平台配置时优先考虑。6. 案例拆解一个新零售数据中台治理项目6.1 背景与现状看起来数据都有用起来一处都对不上2022年我参与一个新零售企业的数据治理项目。这家企业有线上商城、线下门店、加盟体系和自营物流光核心业务系统就超过十二套。老板提出要求很直接做经营分析时线上订单和门店销售能不能在一个报表里直接对比不要每次都要人工调口径。摸底下来问题典型得几乎可以当教材案例会员数据在三套系统里分别存储会员ID互不通用一个客户可能被识别成三个不同的人销售额这个指标在各个部门有五种以上的定义有的算含税有的算不含税有的算实收有的算订单金额数据质量方面订单表空值率不高但商品编码和名称匹配错误等问题很突出。这些现象单看都不算严重合在一起就是数据根本没法直接用。也正是这样的现状让我觉得这个项目非常适合放出来作为数据治理体系平台质量标准的综合案例参考也方便你把下面的实施过程和那份116页PPT的内容互相印证。6.2 实施路线图三个月看到成效六个月初步成形整个实施分四个阶段推进节奏非常关键。第一阶段第1-2周做标准聚焦。一分钱平台先不买先和业务部门一起从3000多个报表字段里圈出21个核心业务术语和字段定出统一口径和编码规则。这一步是打地基所有争议在这里解决掉而不是等系统上线后让平台来背锅。第二阶段第3-6周部署平台并接入元数据。采集了12套系统的元数据梳理出800多张核心表和13000多个字段。平台自动生成数据资产目录同时我们把第一阶段定义的标准配置进系统对9个关键代码集做了标准化映射。大家在资产目录里搜索会员能清晰看到哪几张表在管理会员数据字段分别对应什么含义。第三阶段第7-10周配置质量规则。围绕订单、会员、商品、库存、结算五条主链路配置了1300多条质量规则。其中一批规则采用统计监控方式对订单量、库存金额、毛利率等32个核心指标配置了均值±3σ波动告警。上线第一周就帮财务发现了一个结算金额连续三天偏离正常波动的问题后来查出来是结算批次程序漏跑。第四阶段第11-12周做标准与质量联动。将第一阶段定义的数据元和代码集在资产目录中打标并同步到质量规则引擎。从那以后只要标准字典有更新相关质量规则自动调整运维工作量明显下降。6.3 量化效果与踩坑复盘哪些指标能汇报哪些坑必须说项目运行半年后几个关键指标还是很有说服力的核心经营报表数据准备时间从原来的每周两天压缩到四小时内跨系统会员去重后识别出近40万条重复会员记录修正后营销触达准确率提升了大概11%结算模块每天自动跑质量监控月度差异金额下降了约25%——从几十万降到十几万。踩过的坑也必须记录一下。最大的一个坑是初期把会员唯一ID的打通想得太乐观业务规则里加盟体系的客户和线上商城客户到底能不能算同一个会员光这个定义就讨论了两周。如果一开始没留够这个时间后期代码改了又改成本会大得多。另一个坑是第三阶段一开始质量规则太激进把一些历史原因导致的老问题全部暴露出来告警报表一片红。我们后来调整了策略新增数据实时监控历史数据分批治理业务方的接受度才慢慢上来。还有一个公开场合不太讲、但做项目一定会遇到的现实问题数据owner的积极性。数据治理是典型的前人栽树后人乘凉工作业务部门平时已经忙得要死凭什么抽人出来给你补齐业务元数据、确认数据标准我们后来申请了专项奖金并且把治理成果纳入了各部门的季度绩效指标情况才真正好转。7. 这份116页PPT的内容地图与使用建议7.1 六大部分内容概览说回这份流传很广的116页可编辑PPT我认为它最有价值的不是又多又全而是把数据治理涉及的几个大模块系统地串了起来并且包含了可参考的案例适合用来搭内部培训材料和项目立项汇报的基础框架。从结构上看它大体覆盖了六块内容数据治理概述和体系框架、数据治理平台的模块拆解包括元数据、血缘、质量、安全、资产目录、数据标准体系的搭建方法、数据质量管理流程、实施路径与保障机制、行业案例与实践模板。这个结构和我上面讲的正文逻辑基本一致——没有上来就讲产品功能而是先讲体系再讲平台再讲质量与标准最后落到案例。对于刚接触数据治理的读者我建议先重点看数据治理体系和实施方法论这两部分把为什么做、怎么做搞清楚再看平台功能细节才有意义。对于已经有实践经验的读者可以重点看数据标准和数据质量部分从中提取一些可以直接改写的规则模板和标准分类方式。7.2 怎么用这份PPT做内部培训和方案汇报PPT资源的价值在于可编辑这意味着你不需要从零画框架。实操中我的建议是拿到PPT后先做一次拆解-筛选-重组第一步通读全部116页按章节记录哪些内容和你们现状强相关、哪些当前用不上。大部分企业用不上的部分可能是跨行业案例和某些咨询公司特定的理论模型先删掉或移到附录。第二步用自己的案例替换PPT中的示例。PPT里的案例再典型也不是你们公司的数据。把你的真实问题、真实表名、真实指标口径放进去汇报的说服力会上升好几个等级。第三步调整篇幅重心。如果你面向管理层汇报重点保留体系框架、痛点分析、实施路径和量化收益平台功能页尽量精简如果你面向技术团队那元数据采集、血缘解析、质量规则配置这些页面才是重点。关于PPT转培训材料我自己的习惯是每页只提炼三个要点配一个我们自己的例子让听众能在两分钟内理解这一页到底想解决什么问题。单纯念PPT上的字效果会很差切换成场景问题方案的表达方式大家才会真正听进去。7.3 一点使用上的提醒别把PPT当实施方案最后提醒一点PPT毕竟是知识框架和参考案例的载体不是实施手册。我见过有人拿着一份这样的PPT去跟老板汇报说照着这个做就行。这很危险因为每家企业数据基础、组织架构、业务痛点完全不同同样的114[原文如此]页内容能落地多少差异极大。更务实的用法是把PPT当作知识地图和沟通工具用来统一团队对数据治理的认知、向领导争取资源、向业务部门讲解治理价值。真正推动落地时节奏把握和细节执行还是要按我在前面几章分享的方法来——标准聚焦在核心数据项上平台分阶段激活质量规则跟着业务链走标准和质量规则联动起来再配上一个愿意持续推进的团队才有可能把治理这件事从PPT变成生产力。