1. 数据治理赛道的分野为什么2026年成了分水岭干了十多年数据这行我最大的感受是数据治理这件事从来不是技术问题而是组织问题。但2026年这个时间节点很特殊特殊到我觉得必须把一些观察写下来。过去几年几乎每一家做数据平台、数据中台、数据仓库的厂商都在讲治理讲元数据、讲血缘、讲质量、讲安全。可真正落地到客户现场你会发现一个很尴尬的现实大部分项目最后都退化成了工具堆叠——买了一堆产品装了一堆组件报表还是对不上口径还是打架业务方还是不信数据。标题里说的谁在真做治理谁还在堆工具这句话戳中了行业的痛点。我参与过不少项目也见过不少厂商的方案慢慢总结出一个判断标准真做治理的厂商卖的是流程标准组织能力堆工具的厂商卖的是功能清单组件数量PPT架构图。这两者的差别在项目启动阶段看不出来在POC阶段也看不出来但到了上线半年后差距会大到无法掩盖。2026年之所以成为分水岭有几个背景因素叠加在一起。第一信创进入深水区。信创目录产品名单每年都在更新2026最新版的信创产品目录里数据治理类产品的准入标准明显提高了不再只看能不能跑在国产化环境上而是看有没有完整的治理方法论和落地案例。第二AI大模型的冲击。AI大模型、AI Agent、AI应用开发这些词从2024年火到现在数据治理领域也被裹挟进来了。很多厂商开始讲AI驱动的数据治理但真正把AI用对的没几个。第三DataOps和DataFormula的兴起。DataOps强调数据交付的敏捷性和可观测性DataFormula则代表了一种更工程化的数据加工范式这两者正在重塑治理的技术底座。我写这篇东西不是要给哪家厂商站台而是想把传统治理AI治理双赛道能力这三个维度拆开用从业者的视角讲清楚到底什么样的能力才算真治理什么样的产品只是在堆工具。如果你正在选型或者正在做治理项目的规划这篇内容应该能帮你少踩几个坑。2. 传统治理能力的底层逻辑别被功能清单忽悠了2.1 元数据与血缘治理的地基不是装饰传统数据治理的核心说白了就四件事元数据管理、数据血缘、数据质量、数据安全。这四件事听起来老生常谈但真正做到位的厂商少之又少。我先说元数据。元数据管理不是把表名、字段名、注释采集过来存到一张表里就完事了。真正的元数据管理要解决三个层次的问题技术元数据、业务元数据、管理元数据。技术元数据是表结构、分区、存储格式这些业务元数据是指标口径、业务定义、责任人管理元数据是权限、生命周期、变更记录。很多厂商的产品只做了第一层第二层靠人工填第三层基本没有。结果就是元数据平台变成一个死的资产目录没人用也没人维护。血缘分析也是重灾区。我见过太多产品血缘只能做到表级字段级血缘要么不准要么干脆没有。字段级血缘为什么重要因为当业务方问这个指标为什么变了的时候你必须能追溯到是哪个源系统的哪个字段出了问题。如果只能追到表级那排查效率会低到让人崩溃。字段级血缘的实现难度在于SQL解析尤其是复杂嵌套SQL、存储过程、动态SQL的解析。能做好字段级血缘的厂商技术底子都不会差。提示选型时一定要让厂商现场演示字段级血缘的解析能力拿你们自己最复杂的SQL去测别用他们准备好的Demo。2.2 数据质量规则引擎只是起点数据质量这块大部分厂商都能提供规则引擎支持空值检查、唯一性检查、值域检查、正则检查这些。但规则引擎只是起点不是终点。真正难的是质量问题的闭环管理。什么叫闭环就是发现问题、定位问题、分派问题、修复问题、验证问题这一整套流程要能跑通。很多产品只做到了发现问题和告警后面的环节全靠人工在群里喊。这就导致质量问题越积越多最后大家干脆把告警关了。我在一个项目里见过质量告警每天几千条没人看因为看了也没法处理。质量闭环的关键在于和工单系统、调度系统、元数据系统的打通。质量问题要能自动生成工单工单要能关联到责任人和影响范围修复后要能自动触发验证。这套流程跑通了质量治理才算真正落地。2.3 数据安全合规是底线不是卖点数据安全在信创背景下变得格外重要。信创79号文件原文虽然我没有直接引用但业内都知道信创的核心要求是自主可控安全合规。数据安全治理包括分类分级、脱敏加密、权限管控、审计追溯这几个方面。分类分级是基础。很多厂商提供的是基于规则的自动分类分级但准确率堪忧。我实测过几家对身份证号、手机号这种结构化数据的识别还行但对地址、姓名这种非结构化数据的识别准确率能到70%就不错了。所以分类分级一定要支持人工复核和持续优化不能全指望自动。权限管控这块细粒度要到行列级。但行列级权限对性能的影响很大尤其是当数据量大的时候。我见过一个方案行列级权限用视图实现结果查询性能下降了十几倍。所以权限管控的实现方式很关键能下推到存储层做的最好下推不能下推的要做缓存和预计算。3. AI治理能力的真实成色大模型不是万能药3.1 AI辅助元数据能提效但不能替代AI大模型火了之后几乎所有数据治理厂商都在讲AI辅助。最常见的场景是AI辅助元数据补全——用大模型自动生成表注释、字段注释、业务定义。这个场景确实有价值尤其是面对历史遗留系统元数据缺失严重的时候AI能快速补全一部分。但我实测下来的感受是AI生成的元数据准确率大概在60%到80%之间取决于数据本身的规范程度。如果表名字段名本身就有意义比如user_idorder_amountAI能猜得比较准。但如果表名字段名是t1f1col1这种AI基本抓瞎。所以AI辅助元数据一定要有人工审核环节不能直接入库。另外AI辅助元数据还有一个隐患幻觉。大模型会编造一些看起来合理但实际上错误的信息。比如把user_id解释成用户身份证号实际上它是用户主键。这种错误如果没被发现会误导后续的数据使用。所以我的建议是AI生成的元数据要标记来源并且要有置信度评分低置信度的必须人工确认。3.2 AI辅助数据质量规则推荐是亮点AI在数据质量领域最有价值的应用是规则推荐。传统方式下质量规则靠人工配置一个中等规模的数据仓库配几千条规则很正常工作量巨大。AI可以通过分析数据分布、历史问题记录、相似表结构自动推荐质量规则。我见过一个实现得不错的方案AI先对数据做采样分析识别出可能的枚举值、值域范围、空值率、重复率然后推荐对应的质量规则。人工只需要审核和调整效率能提升好几倍。这个场景的AI应用是实打实的提效不是噱头。但要注意AI推荐的规则不能直接上线。因为数据是动态变化的今天合理的值域明天可能就不合理了。所以规则推荐要配合动态阈值调整让规则能自适应数据变化。3.3 AI Agent在治理中的角色别急着上AI Agent是2025年到2026年最热的概念之一。很多厂商开始讲治理Agent说能用Agent自动完成治理任务。我对此持谨慎态度。原因很简单治理任务大部分是需要人工决策的。比如一个质量问题是数据源的问题还是加工逻辑的问题修复方案是什么影响范围有多大这些决策需要业务知识、系统知识、历史经验AI Agent目前还很难胜任。它可以在信息收集、影响分析、方案推荐这些环节提供辅助但最终的决策和操作还是得人来。我见过一个相对靠谱的Agent应用当质量告警触发时Agent自动收集相关信息血缘、历史问题、责任人、影响报表生成一份分析报告推送给责任人。责任人看完报告后决定怎么处理。这个场景里Agent做的是信息聚合和初步分析不涉及决策风险可控价值也明确。注意任何声称能全自动治理的方案都要打个问号。治理的本质是人和流程AI是辅助不是替代。4. 双赛道能力拆解传统与AI如何协同4.1 双赛道不是两条平行线而是螺旋上升传统·AI·双赛道这个提法我的理解是传统治理能力是底座AI能力是增强层两者不是替代关系而是协同关系。没有传统治理能力AI就是空中楼阁没有AI增强传统治理的效率瓶颈很难突破。举个例子。元数据管理是传统能力AI辅助元数据补全是增强。但如果元数据采集本身就不全、不准AI补全就是在错误的基础上继续犯错。所以双赛道的第一步是把传统能力做扎实然后再叠加AI。再比如数据质量。传统方式是人工配规则AI方式是推荐规则。但如果数据质量的问题闭环没打通AI推荐再多规则也没用因为问题还是没人处理。所以双赛道的核心是传统能力解决有没有AI能力解决快不快。4.2 DataOps与DataFormula双赛道的技术底座DataOps和DataFormula这两个概念在双赛道里扮演的是技术底座的角色。DataOps强调数据交付的敏捷性、可观测性、可重复性它把软件工程里的CI/CD、监控、版本控制这些理念引入到数据领域。DataFormula则更偏向数据加工的工程化强调用声明式的方式定义数据转换逻辑而不是写一堆存储过程。这两个东西和治理的关系是什么我的理解是DataOps和DataFormula让治理从事后补救变成事前预防。传统治理模式下数据出了问题才去查、去修。而在DataOps模式下数据管道在开发阶段就内置了质量检查、血缘采集、权限校验问题在开发阶段就被发现了不会流到生产环境。我见过一个用DataFormula做治理的案例所有的数据转换逻辑都用声明式的方式定义系统自动解析出字段级血缘自动生成质量规则自动做权限校验。开发人员只需要关注业务逻辑治理的事情由平台自动完成。这个方案的前提是DataFormula的解析能力要足够强能覆盖各种复杂的转换场景。4.3 信创适配双赛道的硬门槛信创是2026年绕不开的话题。信创目录产品名单、信创系统目录、信创适配及安全管理这些词在选型时都会遇到。我的观察是信创适配不是简单的能跑就行而是要在国产化环境下保持完整的治理能力。我见过一些产品在x86环境下功能完整但到了国产化环境比如ARM架构、国产操作系统、国产数据库功能就缩水了。比如字段级血缘解析不支持国产数据库的SQL方言质量规则引擎在国产数据库上性能下降严重AI模型在国产芯片上推理速度慢到不可用。这些都是信创适配的坑。所以选型时一定要在真实的信创环境下做POC不能只看厂商的适配证书。适配证书只能证明能跑不能证明跑得好。5. 厂商能力对比谁在真做谁在堆工具5.1 判断真治理的三个硬指标我总结了一个简单的判断框架用来区分真治理和堆工具。三个硬指标第一有没有字段级血缘的完整解析能力。这是技术底子的试金石。能做好字段级血缘的元数据、质量、安全都不会太差。第二有没有质量问题的闭环管理。从发现到修复到验证全流程能不能在平台内完成。如果还要靠人工在群里喊那就是没闭环。第三有没有在信创环境下的完整落地案例。注意是完整落地不是POC验证。POC可以造假落地案例造不了假。这三个指标能同时满足的厂商在我接触的范围内不超过三分之一。5.2 传统厂商的转型困境传统数据治理厂商比如做元数据管理、数据质量起家的那些在AI浪潮下面临很大的转型压力。他们的优势是传统治理能力扎实元数据、血缘、质量、安全这些模块经过多年打磨功能完整、稳定。但劣势也很明显AI能力薄弱DataOps和DataFormula的工程化能力不足。我见过一些传统厂商的AI功能基本就是调个开源大模型的API做个问答界面就号称AI治理了。这种AI功能实际价值很低。真正的AI治理需要把AI能力深度集成到治理流程里比如AI辅助血缘解析、AI辅助质量规则推荐、AI辅助影响分析。这些需要大量的工程投入和领域知识积累不是调个API就能搞定的。5.3 新兴厂商的短板与机会新兴厂商尤其是那些从DataOps、DataFormula方向切入的优势是工程化能力强、AI原生。他们的产品从设计之初就考虑了自动化、可观测性、AI集成在敏捷性和智能化方面有优势。但短板也很明显传统治理能力的深度不够。比如元数据管理新兴厂商可能只做了技术元数据业务元数据和管理元数据很薄弱。再比如数据安全分类分级的准确率、权限管控的细粒度可能都不如传统厂商。所以新兴厂商的机会在于用工程化和AI能力把传统治理的短板补上做出差异化的双赛道能力。5.4 一张表看清能力差异能力维度传统厂商新兴厂商真双赛道厂商元数据管理完整但AI弱技术元数据强业务元数据弱完整AI增强字段级血缘支持但国产库适配差支持但复杂SQL解析弱支持国产库适配复杂SQL数据质量规则引擎强闭环弱闭环强规则引擎弱规则引擎闭环AI推荐数据安全分类分级强性能差性能好分类分级弱分类分级性能优化AI能力浅层集成原生集成深度集成到治理流程信创适配适配证书多实际体验差适配证书少实际体验好适配证书实际体验都好DataOps弱强强DataFormula弱强强这张表是我根据实际项目经验总结的不一定全面但能反映大致的格局。真双赛道厂商的特征是传统能力不弱AI能力不虚信创适配不水。6. 实操建议治理项目怎么选型、怎么落地6.1 选型阶段用POC代替PPT选型阶段最大的坑就是被PPT忽悠。厂商的PPT都做得很漂亮架构图都很完整功能清单都很长。但PPT不代表实际能力。我的建议是一定要做POC而且POC要用真实数据、真实场景、真实环境。POC的设计有几个要点用你们自己最复杂的SQL测血缘解析。别用厂商准备的DemoDemo都是精心挑选的简单场景。用你们自己最脏的数据测质量规则。脏数据才能看出规则引擎的鲁棒性。在真实的信创环境下测性能。别在x86环境测然后假设国产化环境也一样。让业务方参与POC验收。业务方说好用才是真好用。POC的时间建议不少于两周太短的POC只能测功能测不出稳定性和性能。6.2 落地阶段先流程后工具落地阶段最大的坑是先上工具后建流程。很多项目一上来就装产品、配规则、接数据结果工具装好了流程没建起来大家还是按老方式干活工具成了摆设。正确的顺序是先梳理治理流程明确角色和职责再选工具支撑流程。比如质量问题先明确谁发现、谁分派、谁修复、谁验证然后再看工具能不能支撑这个流程。如果工具支撑不了要么改流程要么换工具。我见过一个成功的落地案例项目启动前先花了两个月梳理治理流程定义了数据Owner、数据Steward、数据开发、业务方各自的职责和协作方式。然后才选工具工具选型时重点看能不能支撑这个流程。结果上线后治理流程跑得很顺工具的使用率也很高。6.3 运营阶段治理是长期活不是项目活治理项目最容易失败的地方是把治理当成项目而不是运营。项目有明确的起止时间运营是长期的、持续的。很多治理项目上线后初期大家很积极过几个月就松懈了质量问题又反弹了。所以治理一定要有运营机制。比如定期的治理例会review质量指标、血缘覆盖率、元数据完整度。治理KPI把治理效果和团队绩效挂钩。持续的优化迭代根据业务变化调整治理规则和流程。我在一个客户那里见过一个不错的做法他们设了一个数据治理运营岗专门负责治理的日常运营包括规则维护、问题跟进、指标监控、培训推广。这个岗位不写代码但价值很大因为治理的很多问题不是技术问题而是协调问题。7. 常见问题与排查技巧实录7.1 血缘解析不准怎么办血缘解析不准最常见的原因是SQL解析器不支持某些语法。比如存储过程、动态SQL、嵌套子查询、窗口函数这些。排查思路先确认是哪种SQL解析不了。把解析失败的SQL收集起来分类分析。如果是标准SQL的复杂语法找厂商升级解析器。如果是存储过程或动态SQL看厂商有没有专门的解析方案。没有的话考虑用人工补录的方式兜底。如果是国产数据库的方言确认厂商有没有做适配。实操心得血缘解析不可能100%准确能达到90%以上就很好了。剩下的10%要有手工补录和修正的机制。7.2 质量规则太多管不过来怎么办质量规则太多是治理初期常见的问题。我的建议是分级管理P0规则影响核心报表和决策的必须100%监控告警必须处理。P1规则影响一般报表的监控但不强制告警。P2规则参考性的只记录不告警。分级之后P0规则的数量通常能控制在几十条以内管理起来就轻松多了。P1和P2规则可以定期review该升级的升级该淘汰的淘汰。7.3 AI功能效果不好怎么调AI功能效果不好通常有几个原因训练数据不足。AI模型需要大量的样本才能学好。如果你们的元数据本身就少AI补全的效果肯定差。领域知识缺失。通用大模型不懂你们行业的业务术语需要做领域微调或者提示词优化。集成方式不对。AI功能如果只是独立的一个问答界面和治理流程脱节效果肯定不好。要把AI集成到具体的治理场景里比如血缘解析、规则推荐、影响分析。7.4 信创环境下性能下降怎么优化信创环境下性能下降是普遍问题。优化思路确认瓶颈在哪。是数据库查询慢还是计算引擎慢还是AI推理慢。数据库慢看有没有做索引优化、分区优化、查询重写。计算引擎慢看有没有做并行化、缓存、预计算。AI推理慢看能不能用量化、蒸馏、模型裁剪来加速或者用国产芯片的专用推理库。7.5 常见问题速查表问题现象可能原因排查方向解决建议血缘解析失败SQL语法不支持收集失败SQL分类升级解析器或人工补录质量告警太多规则未分级统计告警分布分级管理P0强制处理AI补全不准训练数据不足检查元数据完整度补充样本人工审核信创环境慢数据库/引擎/推理瓶颈逐层压测定位索引优化、并行化、量化治理流程跑不动职责不清梳理角色和流程先建流程再上工具元数据没人用业务元数据缺失检查业务元数据覆盖率补充业务定义关联指标8. 我个人的一些观察和体会干了这么多年数据治理我最大的体会是治理这件事技术只占三成组织和流程占七成。很多项目失败不是因为工具不好而是因为组织没准备好、流程没理顺、职责没分清。所以选型的时候别只看工具的功能要看厂商能不能帮你把组织和流程也理顺。另一个体会是AI是好东西但别神化它。AI在治理领域的价值目前主要集中在提效上比如元数据补全、规则推荐、影响分析。真正需要决策的地方还是得靠人。那些声称能全自动治理的方案我建议你多留个心眼。最后说一个我踩过的坑别一次性上太多功能。治理是个循序渐进的过程先把元数据和血缘做扎实再做质量和安全最后再叠加AI。一次性上太多功能团队消化不了最后哪个都做不好。我见过一个项目一上来就上了元数据、血缘、质量、安全、AI五个模块结果半年后只有元数据在用其他都荒废了。所以小步快跑持续迭代才是治理落地的正确姿势。这个领域后续还可以关注几个方向一是DataOps和DataFormula的进一步融合二是AI Agent在治理场景的深度应用三是信创环境下治理能力的标准化评估。这些方向我都会持续跟踪有新发现再跟大家分享。
