数据治理这几年被讲得很多但真正动手做过的人都知道这活儿远比想象中要复杂。我见过不少团队一开始雄心勃勃要上治理平台结果搞了半年连元数据都没理清楚更别提数据质量评分、血缘追踪这些进阶功能了。单纯就“第19章 数据治理的发展趋势”这个话题来说如果只是停留在概念层面那这篇文章没有任何意义。我想结合自己实际跟项目、搭架构、跑批处理的经验把这章拆成几个真正能落地的方向聊聊趋势背后到底是什么技术在驱动以及你在实际落地时会踩到哪些坑。1. 盘子已经变了从“成本中心”到“价值引擎”1.1 数据治理为什么突然变得这么重要前几年大家提数据治理第一反应是“合规”“管控”“成本”感觉就是个花钱的部门。但现在风向完全变了。企业手里积累的数据越来越多如果不能用起来那这些数据就是躺着吃存储成本的包袱。治理的价值已经从“不出事”变成了“能赚钱”。我举个例子。某零售企业做了会员标签体系一开始没做治理各业务线自己定义“活跃用户”A部门说30天内登录算活跃B部门说7天内下单算活跃结果营销投放的时候两个部门拉出来的数据对不上投放预算直接浪费了30%。后来做了统一的数据标准和元数据管理把“活跃用户”这个口径固定下来同样的投放预算ROI提升了将近一倍。这才让大家真正意识到数据治理不是成本是杠杆。1.2 从人工驱动到平台工程化驱动早期做数据治理很多公司靠的是“人肉”。数据标准靠Excel统计数据质量靠人工抽检血缘关系靠开发人员拍脑袋画图。这种模式在数据量小的时候勉强能用一旦数据量上来业务线变多人工模式立刻崩溃。现在的趋势很明显数据治理正在从“文档驱动”走向“平台工程化”。也就是说数据标准、数据质量规则、数据血缘、数据权限这些能力必须沉淀到平台上通过自动化的方式去采集、去校验、去分析。我在实际做项目的时候就深有体会如果数据治理还停留在“写文档、开会、对齐口径”的阶段那大概率是做不成的。一定要把规则落到系统里让系统去发现问题而不是靠人去发现问题。2. 核心流程铁律先采集再清洗2.1 为什么顺序这么重要很多团队在实际做数据治理的时候最喜欢问的问题是“我们是先做清洗还是先做采集”我直接说结论先采集再清洗。这个顺序看着简单但真的有很多团队搞反了。先采集是为了先把数据“纳管”进来。不管数据质量高不高、结构乱不乱你首先得知道企业有哪些数据、在哪里、属于谁、量有多大。这一步的本质是“摸底”。如果连企业有什么数据都不知道你清洗什么清洗的前提是已经被纳管的数据。先清洗再做采集的想法看起来很美好想先把脏数据挡在门外。但问题是数据源千千万业务系统的数据结构每天都在变如果没有一个统一的采集层先去把数据拉过来你那套清洗规则根本没地方跑。清洗规则跑在哪儿总得有一个数据载体吧。所以不要想着先清洗再采集那是不现实的。2.2 采集阶段具体做什么采集阶段核心要做三件事元数据采集、数据概要分析、数据字典生成。元数据采集就是把数据源的表结构、字段信息、分区信息、更新频率这些信息抓下来。这个环节最怕的是数据源类型太多有MySQL、Oracle、SQL Server、PostgreSQL还有HDFS、Hive、Kafka这些大数据组件。每类数据源的采集方式都不一样有的走JDBC有的走API有的要读日志。我在做项目的时候一般会先用一个统一的采集框架把这些数据源都接进来先不追求采得多深而是先把连通性搞定。数据概要分析就是对采集上来的数据做一轮快速的统计。比如每个字段的空值率、唯一值数量、最大值最小值、常见值分布。这一步不要做太重的逻辑只需要让治理平台对这批数据有一个初步的“体感”。有了体感后面做清洗规则的时候才有依据。如果没有概要分析直接凭经验写清洗规则大概率会漏掉很多特殊情况。数据字典生成是把元数据和概要分析的结果整理成企业级别的数据字典。这份字典是后续数据标准管理、数据质量监控的基础。很多团队忽略了这一步直接从元数据跳到质量监控结果监控规则都不知道该建在哪个字段上只能拍脑袋。2.3 清洗阶段具体做什么清洗阶段是把脏数据变成干净数据的过程。这个阶段就不是“摸底”了而是“动手术”。第一步是格式标准化。比如日期字段有的源系统存的是“2024/01/01”有的是“2024-01-01”有的甚至是“20240101”。如果不统一后面做分析的时候会非常痛苦。我见过最夸张的一个项目同一个日期字段有7种格式光写转换逻辑就写了两天。第二步是去重。这里要去重的不仅是重复的记录还有重复的属性。比如客户表里面同一个客户出现了三次但是三次的姓名、电话、地址都不一样哪条是真的这就需要制定合并规则通常是按优先级来以最近更新时间为准或者以主数据系统为准。第三步是异常值处理。比如年龄字段出现负数金额字段出现文本经纬度字段超出范围。这些异常值有些可以自动修正有些只能标记出来让业务方确认。清洗阶段最忌讳的事情就是自作主张把数据改了。一定要留审计日志改了什么都记下来否则后面业务方找过来你解释不清楚。3. 数据治理工具选型与硬件配置建议3.1 工具选型的三条铁律市面上数据治理工具很多商业的有Informatica、Collibra开源的有Apache Atlas、DataHub、Amundsen还有国内厂商做的各种治理平台。选型的时候我一般只看三件事。第一元数据采集能力是否够强。很多工具宣传的时候说得天花乱坠实际接一个Oracle RAC都要折腾半天。你在选型之前一定要把企业现有的数据源列一个清单然后让厂商一个一个去测连通性这个做不了后面全白搭。第二数据血缘的解析能力是自研的还是用开源的。血缘解析是数据治理里技术含量最高的部分之一。如果是解析SQL有没有支持你用的方言如果是解析存储过程效果怎么样这些都要实测不能光看演示PPT。第三平台能不能做二次开发。数据治理平台不可能开箱即用每个企业都有自己的特殊需求。如果平台是封闭的后面想接内部系统做自动化就非常困难。所以我一般比较倾向于选API丰富、有开放平台能力的工具。3.2 硬件配置到底怎么算关于数据治理工具建议的硬件配置网上说法很多但大多数都太笼统。我直接给一套我们自己实测下来比较稳的估算方法。先看数据规模。假设你要治理的元数据规模是1万张表每张表平均50个字段每天的采集任务跑一次全量、每小时的增量采集任务跑一次。这种情况下我建议你按如下的配置去起步组件建议配置说明管理节点8核CPU / 32GB内存跑元数据采集调度、数据标准管理、权限管理采集节点16核CPU / 64GB内存跑并发采集任务建议按数据源数量动态扩容数据库节点8核CPU / 64GB内存 / 1TB SSD存储元数据、数据字典、血缘关系图搜索引擎节点8核CPU / 32GB内存 / 500GB SSD支撑数据资产搜索、数据地图检索对象存储视备份策略而定建议保留至少3个月的采集日志和快照这里有一个很重要的判断标准不要光看采集任务的多少还要看数据源的分散程度。如果数据源分散在多个网络分区采集节点要尽量靠近数据源部署否则网络带宽会成为瓶颈。像我们之前有一个项目业务系统在东区机房治理平台在西区机房中间还隔了一堵防火墙每次全量采集都要跑三四个小时后来把采集节点下沉到东区时间直接缩短到40分钟。再补充一点如果企业数据量比较大动辄几十万张表或者有实时采集的需求那就要上分布式采集架构了。这个时候建议把采集节点横向扩展每增加1万张表的采集任务大概增加一个16核32GB的采集节点。这个比例是我们自己压测出来的不同工具会有一点差异但可以作为参考。3.3 部署方式物理机、虚拟机还是容器这个问题很多人纠结。我的建议很简单看团队的运维能力。如果团队有专门的运维人员用容器化部署是最好的。Kubernetes管理采集节点非常方便扩容缩容都是秒级的而且环境一致性有保障不会出现“在我机器上是好的到服务器上就挂了”的尴尬情况。如果团队没有专门的运维那直接用虚拟机或者物理机反而更省心。因为数据治理平台本身不是一个高并发系统它的核心是采集任务调度、数据血缘解析、质量规则校验这些偏批处理的任务对资源的弹性要求不高。用虚拟机固定配置反而更容易排查问题。我自己踩过的一个坑是一开始图省事所有组件都装在一台机器上结果元数据采集任务和血缘解析任务高并发的时候CPU直接打满平台界面卡成PPT。后来把采集节点和管理节点拆开问题才解决。所以组件分节点部署不是矫情是真的有必要。4. 数据治理的智能化演进方向4.1 元数据采集的自动化与智能化传统元数据采集靠的是人工配置数据源、手动触发采集任务。未来趋势是自动发现。也就是说治理平台能够自动扫描企业网络里的数据源自动识别新增的表、字段、分区自动更新数据字典。这个能力在数据湖和数据仓库混用的场景下特别有价值。现实一点说自动发现不会完全替代人工配置但它可以大大减少人工干预的频率。你只需要在第一次接入数据源的时候配置好连接信息之后新增表、新增字段这些动作平台可以自动感知。实现这个能力技术上一般靠的是数据源的事件监听或者定时轮询系统的元数据表。实际项目中我一般是这么做的对关系型数据库开启Binlog或者CDC机制一旦有DDL操作自动触发元数据采集对Hive数仓每隔一段时间扫描一次Hive Metastore发现有新表就自动注册到治理平台。这两种方式结合起来基本能做到元数据“分钟级”感知。4.2 数据质量规则的AI辅助生成数据质量规则怎么定一直是数据治理里的老大难问题。传统的做法是业务方提需求治理团队写规则。但业务方往往说不清楚治理团队又不懂业务规则写出来要么太松、要么太严。现在比较前沿的方向是基于数据分布自动生成质量规则。平台可以先做数据概要分析拿到字段的空值率、唯一值比例、值域分布、格式分布然后根据这些统计特征自动生成一套初始规则。比如某个字段的非空率常年稳定在95%以上那就可以自动生成一条“非空率不低于90%”的规则某个字段的值域是有限的枚举值那就可以自动生成一条“只允许枚举值范围内取值”的规则。这套思路落地的时候特别实用。我之前在一个制造企业做设备数据治理设备状态字段有“运行”“停机”“维修”“报废”四种取值但接进来的数据里出现了“停機”这种繁体字还有一些空值。靠人工去查根本发现不了但通过自动生成的枚举值规则一键就筛出来了。4.3 DataOps与Data Fabric对治理的深刻影响DataOps这个概念火了几年它的核心是让数据开发、数据运维、数据治理一体化。以前数据团队和业务团队是接力赛现在强调的是DevOps式的协作通过自动化流水线把数据从采集、清洗、加工、发布整个过程串起来。DataOps对治理的影响在于治理能力不再是一个独立的平台而是嵌入到了数据开发的流水线里。开发人员在写数据管道的时候就要同时配置数据质量规则、数据血缘标签、数据权限策略。上线的时候如果质量校验不通过流水线直接阻断发布动作根本走不下去。Data Fabric数据编织则是另一个趋势。它强调利用知识图谱技术把元数据、数据血缘、业务术语、数据质量这些信息编织成一张语义网络。用户不需要知道数据在哪里直接通过业务语义去查找数据资产。我在调研的时候发现国内真正落地Data Fabric的企业还不多但它的思路确实很超前——用语义层来屏蔽底层数据源的复杂性对数据治理来说是一个革命性的变化。4.4 数据资产入表对治理的倒逼效应近两年“数据资产入表”成了一个热点话题这对数据治理的影响比任何技术趋势都来得直接。因为数据要作为资产入表就必须有清晰的估值依据而估值的前提是数据要“可识别”“可计量”“可确认”。这三个“可”每一项背后都是治理工作。我在帮一家企业做数据资产盘点的时候发现他们连自己有多少张表、每张表的数据量多大、数据来源是哪里都回答不上来。这种状態下谈资产入表基本就是空中楼阁。所以数据资产入表表面上是财务问题本质上是个数据治理问题。企业想在数据资产化上有所作为第一件要做的事情就是老老实实把元数据管起来。5. 实操项目中的常见问题与排查实录5.1 采集任务偶发失败别急着看工具先看网络采集任务失败是数据治理项目里最经常遇到的问题。我见过很多团队一看到采集失败就找工具厂商排查结果折腾半天发现是网络策略变了。你自己排查的时候可以按这个顺序来先看网络连通性Telnet一下数据源IP和端口看看通不通。很多时候是安全组策略、防火墙规则调整了导致采集节点的IP被限制访问。再看账号权限数据源的账号密码是否过期是否有表级别的访问权限有时候业务方给的是只读账号但账号权限被误改了。最后看工具日志如果网络和权限都没问题再去看治理平台的采集任务日志确认具体报错信息。这里我特别提醒一点采集任务的告警一定要配上。不要等业务方来投诉才发现采集挂了那太被动了。建议配置任务失败告警、延时告警、数据量异常告警三类。数据量异常告警尤其重要如果某天的采集数据量比平时少了50%那很可能源系统做了变更或者采集进程提前退出了。5.2 数据血缘解析不准不要过度依赖“自动”数据血缘是数据治理平台里看起来最酷、但实际上最容易翻车的功能。自动解析SQL、自动解析存储过程演示的时候效果都很惊艳但一到生产环境各种不支持的语法、动态SQL、临时表就把解析器搞懵了。解决这个问题我的经验是自动解析加上人工补录。自动解析可以先处理掉80%的场景剩下的20%必须靠人工维护。比如存储过程里的动态SQL解析器根本没办法提前预知会生成什么表这时候就必须在平台上手动建立一条血缘关系。还有一种情况是跨系统调用。A系统的数据通过接口推送给了B系统这在血缘关系上是断开的。自动解析只能看到系统内部的数据流向跨系统的血缘必须靠人工维护。我的建议是在治理平台上建立“手动血缘”功能让数据负责人定期维护跨系统的数据流向至少保证核心链路的血缘是完整的。5.3 数据质量规则误报率高要设置合理的阈值数据质量规则上线之后最大的问题是误报。一条规则动不动就告警业务方第一周还看第二周就麻木了第三周就把告警屏蔽了。避免误报的关键是给规则一个合理的阈值和调度周期。举个例子非空率规则如果你设置的阈值是100%那几乎每天都会有告警因为总有那么几条数据会因为各种原因为空。但如果你设置成95%那可能一个月才告警一次告警频率就合理多了。阈值怎么定不要拍脑袋要看历史数据分布。先跑两周的概要分析看看每个字段的非空率、值域分布、格式合规率的正常波动范围然后取正常范围的边界值作为告警阈值。这样定下来的阈值既能发现真正的数据质量问题又不会频繁打扰业务方。5.4 硬件配置不够的应急预案如果你的治理平台已经上线了但硬件配置明显不够用比如采集任务排队严重、平台页面打开很慢、血缘解析一直超时。在申请新硬件之前有几个临时优化手段可以先试一下降低采集频率从每小时一次改为每两小时一次或者把全量采集改成分区增量采集。错峰执行任务把耗时的血缘解析任务放到凌晨执行避开白天的采集高峰。清理历史数据把超过3个月的采集日志归档到对象存储减少数据库和搜索引擎的压力。关闭不必要的实时计算有些平台有实时数据质量监控功能如果硬件扛不住可以先关掉改成每天定时跑批校验。这些手段都是权宜之计长期还是要把硬件配置升上去。但从我的经验来看90%的治理平台性能问题通过错峰和清理历史数据就能缓解一大半真正需要加硬件的情况反而是少数。6. 一点实操建议从趋势到落地的最小闭环最后聊聊怎么把趋势落地。很多人看完一堆趋势分析回到公司还是不知道从哪里下手。我的建议很简单找一个核心业务域做一个小闭环。闭环包含五步确定范围、盘点资产、定标准、跑质量、持续监控。不要一上来就铺开几百张表那不现实也容易被业务方抵触。先挑一个数据质量最差、业务价值最高的域比如客户域或者供应链域把元数据采了、数据字典建了、质量规则跑了发现问题就整改。等这个域跑通了看到成效了再逐步推广到其他域。我在实际做项目中的体会是数据治理最怕的不是技术难而是范围失控。每多接入一个业务域就要多处理一堆历史遗留问题。与其全面铺开然后烂尾不如小步快跑做深一个域。等这个域的治理效果被业务方认可了后面的推进自然会顺畅很多。还有一个细节容易被忽略数据治理项目的成功一定要有业务方参与。不要关起门来做治理每个核心数据域都要指定一个业务负责人定期对齐数据标准和数据质量规则。没有业务方背书的治理规则基本都会在执行阶段变形。这一点无论趋势怎么变都不会变。
