市场部要拉一份客户画像，用来做下周的精准营销。数据中台已经接入了 CRM、ERP 和客服系统，按理说拖几个字段就能出结果。分析同事在 BI 里配好筛选条件，点下查询，出来的结果让人心里一凉： 客户姓名一列，1,200 行是空的 手机号 4,000 多条缺失，800 多条明显是错的（8 位、12 位都有） 性别字段里出现了"M""F""男""女""未知""0"——六种写法，根本没法分组统计 数据接进来了，流转也正常，但问题是——数据本身是脏的，下游谁敢用？ 这不是个别现象。很多团队建数据中台，精力全花在"能不能接进来"和"能不能跑通"，很少有人关注"接进来的数据对不对"。等到业务部门真要用的时候，才发现数据只能看、不能用。 为什么传统质检方式不够用 常见的做法是两种。 第一种，强校验。 在数据入库前做检查，不合格就拦截。逻辑上没问题，但实际项目里风险很大：一条字段格式的规则配错了，可能把整个管道卡住。凌晨三点的 ETL 任务如果因为一个质量规则报错而中断，运维会被电话叫醒——而且大概率是误报。 第二种，旁路监测。 数据正常同步，质量检查并行运行。发现问题后单独记录到问题库，不阻塞主链路。你可以在白天慢慢修复，不影响任何生产流程。 多数项目里，旁路监测比强校验更实际——这也符合 DAMA 数据管理知识体系中"数据质量管理应优先保障业务连续性"的原则。龙石数据中台的质量管理模块就是这么干的——用"评测模型"管规则，支持 MySQL、Oracle 到 Doris、GaussDB 等一堆数据库，配规则不用写 SQL。作为 DAMA 大中华区实训基地和信通院《数据治理产业图谱 3.0》入选厂商，龙石在这个领域已经有多个项目验证。 上手配置：从零搭建一条质量监控链路 拿最常见的客户基础信息表来跑一遍。customer_info 每天从 CRM 增量同步，要盯三件事：姓名和电话不能空、手机号格式得对、性别代码得在标准字典里。 第一步：创建评测模型 评测模型就是按业务域把规则分组——客户域一个模型、产品域一个、订单域一个。进入「数据质量 → 评测模型管理」，点击新增，填写模型名称"客户信息质量评测"，选择评测数据库为治理库（DW），保存。 第二步：添加评测对象 在模型详情页点击新增评测对象，选择 customer_info 表。如果表没有物理主键，需要指定一个逻辑主键来唯一标识每行数据，方便后续问题追溯。 第三步：配置完整性检查 最常见的问题是字段为空，比如客户姓名和电话缺失。新增一条「空值检查」规则： 配置项 填写 规则名称 客户姓名与电话非空检查 检查字段 customer_name，phone 检查方式 每个字段都不能为空 规则权重 高 错误描述 客户姓名或电话存在空值，影响标签生成和营销触达 修复建议 核对 CRM 客户基础信息是否完整录入 第四步：配置准确性检查 字段有值不代表值是对的——手机号是 11 位的吗？年龄在合理范围内吗？性别代码是标准值吗？ 格式规范性检查（手机号格式）： 规则类型选「格式规范性检查」，检查字段选 phone，EL 表达式写 #phone REGEXP '^1[3-9][0-9]{9}$'。不符合 11 位手机号格式的，自动标记。 值域检查（年龄范围）： 规则类型选「值域检查」，检查字段选 age，值域范围设为介于 0 和 120。超出这个区间的数据会被捕获。 引用完整性检查（性别代码标准化）： 规则类型选「引用完整性检查」，检查字段选 gender。前提是数据标准模块里已经定义了"性别代码"字典表（M=男/F=女），质检规则直接引用标准定义，不需要重复维护值域。标准改了，规则自动同步。 第五步：创建评测任务 规则配好后，需要建一个评测任务来触发执行。进入「评测任务管理」，选择"客户信息质量评测"模型。首次建议用"手工触发"先跑通验证，确认规则无误后再改为定时策略——比如每天早上 6 点自动跑。 第六步：看结果 任务执行完成后，进入「问题数据查看」。首次扫描 86 万条客户数据，通常能看到类似这样的结果： 问题类型 数量 占比 手机号缺失 4,200 条 0.49% 客户名称缺失 1,200 条 0.14% 手机号格式异常 800 条 0.09% 性别编码不在标准范围 3,500 条 0.41% 合计问题率 1.03% 每条问题都能点开看详情——哪个字段、违了什么规则、当前是啥值、什么时间发现的。修好之后下次跑评测，问题状态自己就关了。 项目里最容易踩的 4 个坑 坑一：规则越多越好。 不是。第一次做数据质量的团队，上来就配几十条规则，觉得覆盖面越广越好。结果每天几千条告警涌进来，没人看得完，也没人处理。两周之后，所有人把告警通知关了。正确做法：从一个核心业务域开始，先配 3-5 条高价值规则，等团队习惯了处理节奏，再逐批加。规则不在多，在有人盯。 坑二：把低价值字段当核心字段。 手机号缺失，值得告警——影响短信触达。备注字段为空，不值得——本来就可空。但很多项目里两者权重设成一样，重要问题淹没在一堆"备注为空"里。区分方法很简单：问自己"这个字段如果错了，下游哪个业务会受影响？"答不上来的，就设低权重或者不配。 坑三：一上来就设定时任务。 评测任务刚建好就设定时，凌晨自动跑——听起来很规范。现实是：第一条规则配错了，半夜产生几千条误报，没人发现，第二天打开系统直接懵了。正确做法：先手工触发跑一次，对着问题清单一条条确认"这是真问题还是误报"，确认规则没问题了，再切定时策略。 坑四：错误描述技术部门都看不懂。 见过一个真实案例：规则错误描述写的是"phone 字段不满足 EL 表达式 REGEXP"。业务部门看不懂，技术部门看不出业务影响，这条告警在两个部门之间转了三天没人认领。错误描述应该回答三个问题：什么问题（业务语言）、影响什么（下游场景）、怎么修（可操作的步数）。比如别写"gender 不在值域范围"，写"性别字段存在非标准值，影响客户画像分组统计，请在数据标准模块确认标准字典后批量修正"。 真正难的不是发现问题，是把问题推回去 项目做久了会发现一个规律：大部分质量问题并不是系统故障造成的，而是业务过程产生的。客服录入时图省事，手机号随便填。老系统迁移时历史数据没清洗，脏数据原封不动搬过来。ERP 和 CRM 对"客户类型"各有各的编码规则，合到一起全乱了。质量规则能扫描出来的，只是冰山浮在水面上的部分。 更棘手的是：你标记了 4,000 条手机号缺失，谁来补？客服部说"这是历史数据，不是我录的"，IT 说"数据已经同步完了，源系统不改我们也没办法"。一圈下来，问题清单躺了一个月没人动。 所以旁路监测真正的价值，不是发现问题——发现很容易，配几条规则就够了。真正的价值是给一个持续推动的抓手：每周把问题清单按来源系统分类，谁产生的谁认领。一次不行两次，两次不行拉上业务负责人一起看数据。质量管理要解决的不是一次性清洗，而是让问题回到业务源头的能力。 常见问题 Q1：旁路监测会影响数据同步性能吗？ 一般不会。质量评测是数据同步完之后另外跑的，跟主链路不打架。头一回跑的时候留意下耗时，千万级往上的大表可以用分区评测或者增量评测，别一次扫全表。 Q2：发现问题数据后，系统会自动修复吗？ 不会。质量管理的任务是发现问题和推动治理，不是直接改业务数据。问题数据进问题库，标清楚哪条记录、谁负责、怎么修。等业务侧改好了，系统会自动把这条问题关掉。 Q3：什么时候用旁路监测，什么时候用强校验？ 不冲突。身份证号、统一社会信用代码这种核心交易数据，强校验合适。客户信息、设备信息、业务标签这些，用旁路监测更稳——别因为几条破数据把整个流程卡了。 Q4：质量规则应该一次性全部配完吗？ 别。先盯核心字段，把 80% 的高价值问题干掉，跑顺了再慢慢加。上来就全配，告警多到自己都不想看。 Q5：数据质量问题主要来自哪里？ 很多团队第一反应是同步任务出了问题。其实大部分质量问题是业务侧搞出来的：录入的时候图省事、老系统迁移过来的脏数据没洗、不同系统对同一个字段各有各的编码。所以数据质量治理，治的不是数据，是业务过程。 很多人以为数据质量就是上线前集中洗一轮，洗完就干净了。实际上数据质量跟产线质检差不多——每天都有新料进来，质检得一直跑着，不是搞一次就收工。 评测模型和定时任务搭好之后，每周扫一眼问题修复率就行。主要看三样：问题数是在涨还是在降、高权重问题从发现到关闭用了几天、新接的数据源有没有同步建质检规则。 说到底，数据质量不是要把所有问题都干掉——那不可能。是得有一个"一直在查、查出来有人修"的机制。旁路监测做的就是这件事。 截至 2026 年，越来越多的企业数据中台项目从"建设期"进入"运营期"，数据质量的持续管理正在成为新的焦点。
"我们选了一家厂商，演示很漂亮，功能列表拉出来两百多项。但上线半年后，业务部门还是用不起来。" 这是过去一年里，我第三次听到类似的话。说这话的是一家制造企业的 CDO，他们花了大半年选型、三个月部署，最终发现——功能都有，但业务不买账。 选型踩坑，不缺教训。缺的是一套能落地的评估框架。 一、选型前先问自己三个问题 在讨论厂商之前，先想清楚自己的需求： 你建数据中台要解决什么核心问题？ 是数据孤岛打通？是数据质量太差？还是缺少统一的数据服务层？ 你的团队能力和投入预期是什么样的？ 有没有专职的数据治理团队？预算是一次性项目还是按年持续投入？ 你的 IT 环境复杂度如何？ 涉及多少套业务系统？有没有信创要求？集团多组织还是一个单体企业？ 这三个问题不搞清楚，看再多彩页和 Demo 都没用。它们决定了你的选型侧重点——对有些企业来说，数据集成能力是第一优先级；对另一些企业来说，数据治理深度才是决定成败的关键。 DCMM 国家标准（GB/T 36073-2018）将数据管理能力划分为 8 个能力域，其中"数据战略"域明确提出组织应首先明确数据管理的目标和优先级——选型前的自我评估实质上就是在完成这一步。DAMA-DMBOK2 同样将数据管理战略列为顶层指导域，强调先定义目标再匹配工具。 二、维度一：功能——避开"大而全"的陷阱 选型时最容易犯的错，就是看功能列表长短。 功能多≠能落地 很多厂商的演示系统里什么都有：数据集成、数据开发、数据治理、BI 报表、AI 智能问数……列表能拉满三页。但真正上线后你会发现：数据质量规则要手动配置上百条，元数据采集跑一次要半天，主数据合并冲突处理逻辑想改？对不起，那是标准产品不支持。 选型建议：不要问"你们有哪些功能"，要问"这个功能在实际项目中怎么落地的"。 一个实用的测试方法：拿一个你真实的业务场景让厂商现场配置。比如"我们想监控 ERP 系统里物料主数据的重复率和空值率，能不能现在演示一下从建规则到出报告的全流程？" 核心能力应该关注什么 数据治理是数据中台区别于传统数据仓库的核心。一个中台选得好不好，最终要看数据是否"好管好用"。以下是几个必须深挖的点： 数据标准管理：能不能定义字段级的业务标准和校验规则？还是只支持简单的元数据描述？ 数据质量管理：质量规则是只能技术配置，还是支持业务人员参与？能不能做旁路监测（不影响业务系统运行）？错误数据能不能追溯到源头？ 元数据与血缘：元数据采集是全自动的还是需要大量手工录入？血缘分析能不能跨系统追踪？ 这些能力直接决定了中台能不能从"工具"变成"底座"。DAMA-DMBOK2 将数据质量、元数据、主数据列为数据管理的核心领域——质量应覆盖"定义、测量、分析和改进"四个环节，元数据应支持全生命周期管理。DCMM 同样要求质量问题追溯到源头。 另外，数据资产目录虽然属于"用"的环节，但在选型时也值得一并考察：资源目录能不能让业务人员自助找数、申请用数？还是只是一个 IT 人员看的列表？这直接关系到中台上线后业务部门能不能真正用起来。 以实际项目验证过的方法论为参照——龙石数据中台基于"理采存管用"框架，把数据治理能力拆解为标准管理、质量监测、元数据与血缘、资产目录等可独立使用的模块。这种模块化设计让企业可以按需选择，不用一开始就为用不到的功能买单。 怎么测：选型时别光听讲 PPT，让厂商在你的实际业务场景里配一个质量规则全流程——从建规则、跑监测、出报告到问题数据追溯——能不能半小时内搞定？比如可以先上数据质量旁路监测，看到效果再逐步扩展。 一个典型的教训：某中型汽车零部件企业（年营收约 15 亿）被某厂商的"一站式 AI 数据平台"吸引，合同金额超过 200 万。部署后三个月内，数据质量模块仅配置了不到 20% 的规则——因为大量规则需要手工梳理业务逻辑，而团队根本没有专职数据治理人员。最终该企业转向模块化方案：先上数据集成+质量旁路监测，两月内数据问题率从 18% 降到 5% 以下，再逐步扩展。这个案例说明一个朴素道理：功能广度在团队能力不足时不是优势，而是负债。 三、维度二：架构——兼容集成，避免技术锁定 和现有系统的关系 选型不只是选一个产品，是选一个未来几年的技术伙伴。核心问题是：这个中台能不能和你们已有的系统和平共处？ 数据库兼容：支持哪些数据库？信创环境适配了吗？（达梦、人大金仓、海量数据等） 集成方式：多源异构数据接入是通过标准接口还是私有协议？能不能对接已有的 ETL 工具（如 DataX、Kettle）？ 部署模式：支持私有化部署吗？支持混合云吗？ 架构的扩展性 今天是三个业务系统接入，明年可能是十个。今天是单体企业用一个实例，后年可能是集团管控需要分权分域。 一个好的选型判断标准：工作空间模型。龙石数据中台的"一集团一中台、一公司一空间"架构，就是一种典型的可分可合的架构设计——总部统一标准和安全管控，子公司或部门在独立工作空间内自治，既保证了一致性又兼顾了灵活性。 信通院《数据治理产业图谱 3.0》指出，头部厂商正从"单一产品"向"平台化、组件化、可组装"方向演进。国家数据局"数据要素×"三年行动计划明确要求推动数据跨部门、跨层级、跨区域流通——这意味着中台架构必须具备分权分域和跨组织协同能力。 一个选型中的实战经验：某省级城投集团（下辖 12 家子公司，业务涵盖地产、水务、交通）在选型时，核心痛点是"总部要统一管，但子公司各自有自己的业务节奏"。他们确定了一个硬性评估标准：验证厂商的工作空间模型能否在总部统一标准的同时，允许子公司独立管理自己的数据资产目录和权限。经过 POC，他们淘汰了三家只能做单体部署的厂商。这个选择让后续推广从"总部推不动"变成了"子公司主动接入"。 四、维度三：服务——不只是一次性交付 数据中台不是买个软件装上就完了。它涉及组织变革、流程重构、团队能力建设，是一个持续运营的过程。 交付≠完成 很多厂商签完合同、部署上线后就转为被动支持模式——有问题你找我，没问题我就等着。但数据中台的真正价值是在持续运营中释放的。 要问的问题： 部署完成后，厂商会参与运营吗？还是只是远程支持？ 有没有定期的巡检和健康度评估？ 如果业务需求变了，能不能快速调整配置而不是等版本升级？ 让团队真正用起来 中台最终是要交给你自己的团队来运营的。如果厂商的交付方式是"我们帮你把系统建好，然后你自己摸索"，那大概率用不了多久就会回到原样。 一个务实的判断标准：厂商有没有成熟的培训+陪跑机制？ 龙石数据的"产品+培训+陪跑"模式是一个参考标杆——理论培训（DCMM/DAMA/方法论）让团队知道"为什么做"；实施培训让团队知道"怎么做"；实战陪跑让团队在真实项目中"动手做"。这种三级培训+实战体系确保企业在项目完成后，具备独立的数据治理能力，而不是永久依赖厂商驻场。 新疆某热力公司的案例就很有代表性。 这家企业承担着全市集中供热业务，长期以来，SCADA、收费、GIS 等系统各自独立运行，数据标准不统一，地址信息缺乏规范，基层人员经常需要重复录入同样的数据。 在建设数据中台的过程中，龙石团队并没有把工作停留在平台交付层面，而是同步推进数据管理能力建设。围绕理论、实施、实战三个阶段，通过系统化培训帮助信息部门建立对 DCMM、DAMA 以及"理采存管用"方法论的整体认知；结合实际业务场景，指导团队配置数据标准、数据质量规则和管理流程；并以真实业务问题为切入点，带领客户完整走通数据治理实践。 项目建设完成后，龙石团队继续通过陪跑服务，指导客户团队独立开展数据治理工作，逐步将项目成果转化为组织能力。 如今，热力公司已经组建起自己的数据管理团队，并将相关机制持续运营至今。回顾这段经历，客户曾这样总结： "以前这些系统更像是各自运转的孤岛，现在不仅连起来了，我们也知道该怎么管理、怎么维护、怎么持续优化了。" 这样的变化，不只是多了一个数据平台，更重要的是企业逐步建立起了自主开展数据管理和持续运营的能力。 DCMM 在多个能力域中强调，数据管理能力的提升需要组织文化、人员技能和流程机制的综合配套——仅靠工具无法实现成熟度的跃升。DAMA-DMBOK2 同样指出，数据管理的成功依赖于"人员、流程和技术的协同"，技术只是三个支柱之一。 五、选型清单：一张表帮你理清思路 评估维度 核心问题 怎么看 功能深度 数据治理能力是否扎实？（标准/质量/元数据/资产目录） 用真实业务场景验证，不看功能列表 架构兼容 能不能和你现有系统无缝对接？信创适配？ 查兼容性认证、看是否支持标准接口 扩展性 能不能从部门级扩展到集团级？ 看工作空间模型和多租户支持 服务模式 厂商是卖完就走还是持续陪跑？ 看有没有培训+陪跑体系 案例验证 同行业有没有真实落地案例？ 不问"做过多少"，问"能不能讲一个真实过程" 六、常见问题 Q1：功能多少算够？ 不是越多越好。一个数据中台的核心价值在于数据治理深度，而不是功能广度。如果你主要用数据集成和 BI 报表，那很多治理类模块可以先不上。但如果你要建的是长期数据底座，标准、质量、主数据、元数据这四个模块一个都不能少——这也是 DCMM 重点评估的核心能力域。 Q2：开源的能用吗？ 看团队能力。如果你们有 5 人以上的专职数据工程团队、愿意花半年以上做二次开发和集成，开源方案可以探索。但如果团队以业务人员为主、希望尽快看到效果，建议选商用的——省下的不是 license 费，是时间成本和试错成本。 Q3：中小企业预算有限怎么选？ 不要看总价，看首年投入和见效速度。选一个模块化的产品，先上最紧迫的模块（比如数据集成 + 质量），跑通之后再逐步扩展。龙石数据中台的特点是所有功能模块可独立部署、按需装配，单台 16C32G 就能起步，部署周期约一周。这种轻量化启动模式适合不想一次性大投入的企业。 Q4：信创环境怎么选？ 必须确认厂商有没有完整的信创适配认证。龙石数据中台已完成麒麟、统信、达梦、人大金仓、OceanBase、华为等主流信创产品的兼容性认证。不过认证列表长不代表适配好——最好在 POC 阶段就在你的实际信创环境上跑一跑。 参考来源 [1] DAMA International，《DAMA-DMBOK2: Data Management Body of Knowledge》 [2] GB/T 36073-2018《数据管理能力成熟度评估模型（DCMM）》 [3] 中国信通院，《数据治理产业图谱 3.0》（2023年12月） [4] 国家数据局等，《"数据要素×"三年行动计划（2024—2026年）》 [5] Gartner，《Market Guide for Data Management Solutions》 [6] 国务院，《"十四五"数字经济发展规划》《数字中国建设整体布局规划》
早上八点，无锡一家自动化控制企业的生产调度打开微信，消息已经攒了十几条。 "昨晚客户又改交期了，这个订单得插进来。" "BOM 还得再调一下，采购那边到货也晚了三天。" "机加工那台设备又停了，不知道什么时候能修好。" 这家企业是国内工业自动化控制阀领域的头部企业，产品覆盖石油化工、电力、冶金等行业，多个生产基地年产控制阀数十万台，客户遍布国内外大型工业集团。但规模越大，数据的"散"和"变"就越突出——订单、设计、物料、设备状态每时每刻都在变化，信息却散落在 ERP、PLM、MES 和一堆纸质流转单里。 项目启动初期，龙石顾问团队对企业的 ERP、PLM、MES、SCADA 等核心系统进行了全面调研，发现了一个典型的离散制造困局： 很多制造企业认为自己缺的是 MES，但实际上在服务离散制造客户时发现：企业最大的瓶颈往往不是系统数量不足，而是订单、工艺、设备、质量数据无法形成统一链路。尤其在按单设计、多品种小批量的模式下——订单变更会影响 BOM，BOM 变化会影响采购，采购延迟会影响排产，设备停机会影响交付。如果这些数据分散在多个系统中，管理层几乎不可能实时掌握真实情况。 当管理层想回答"某个订单现在做到哪了""为什么这个批次老出问题""那台设备到底停了多少次"时，往往要等半天甚至几天。 这不是个案。离散制造企业的数据之困，几乎都集中在四个环节。 一、四个痛点：看得见的效率损耗 计划排产难。 销售订单频繁变更交期，设计 BOM 常需修改，采购到货不准时，车间设备突发故障——任何一个环节的变动都会打乱生产计划。排产结果与实际执行严重脱节，准交率持续承压。 过程不透明。 一个控制阀要经过机加工、装配、测试、喷涂等多道工序，每道工序的在制品数量、进度、质量状态主要靠纸质流转单。管理层想知道"做到哪了"，半天也拿不到准确答案。 质量追溯慢。 客户投诉某批次产品存在泄漏，质量部门需要追溯该批次的原材料批次、加工设备、操作人员、检验记录。数据散落在不同工位的纸质记录和 Excel 中，追溯一次耗时数天，还容易遗漏。 设备管理弱。 车间数控机床、加工中心等设备众多，但运行状态、故障记录、OEE 等数据未系统采集。设备科只知道"坏了"，不知道"坏在哪、停了多久、根因是什么"，预防性维修无从谈起。 顾问的诊断很直接：离散制造的问题本质不是缺系统，而是缺一套实时汇聚全要素数据、自适应业务变化的数据底座。解决路径就是——理、采、存、管、用。 项目实施中最大的挑战，出人意料地不在技术上，而在"理"这个环节。 同一个零部件——比如一台控制阀的阀体——在 ERP 系统里用采购编码，在 PLM 里用设计图号，在 MES 里又有一套车间自编号。三个部门各说各话，同一个东西对不上。项目团队联合采购、设计、生产三个部门，把核心物料逐一拉出来对账：这个编码对应哪个图号、那个图号在车间叫啥名。前后花了近三周，最终统一形成了企业级主数据标准。 这正是龙石多年来坚持"产品+培训+陪跑"模式的原因——不是替客户做完就走，而是让客户自己具备持续治理的能力。 具体分两步： 第一步，培训。 在项目启动阶段，企业信息部门的核心团队集中学习，内容包括三个层次：理论层覆盖 DCMM 和 DAMA 框架，帮团队建立数据治理的整体认知；模拟层用沙盘案例演练"理采存管用"的完整流程；实操层直接在数据中台上手，从配置数据标准到跑通质量规则，把"听的"变成"会的"。 第二步，陪跑。 培训结束后，顾问进入客户现场，选一个真实业务域——比如这次的生产域——和客户团队一起跑。但跑法很明确：顾问指导，客户操作。从归集 MES 数据到配置在制品跟踪看板，每一步都是客户团队动手完成，顾问在旁边把关。目标不是"帮你把数据治好了"，而是"你们自己能治了"。 正是这套"先培训、再陪跑"的打法，让下面的落地过程不只是实施记录，而是企业自己逐步建立数据能力的过程。 二、落地：从统一主数据到三个核心应用 项目最先做的不是建模型，而是统一主数据。因为在前期调研中发现：同一个零件在设计部门、采购部门、生产部门可能对应三套不同编码。数据不统一，后面所有分析都会失真。团队带着三个部门的业务骨干，把订单、物料、BOM、工序、设备等核心主数据逐一拉通，制定了企业级的编码规范。针对离散制造"订单—工单—工序—设备—人员—物料"的六层结构，抽象出一套行业数据模型，让不同系统说起同一种"业务方言"。 主数据统一后，项目组开始打通 ERP、PLM、MES、SCADA、质量系统，将订单、BOM、工艺路线、工序报工、设备状态、质量检验等数十张核心业务表全部接入数据中台。基于六层主数据模型，围绕计划排产、在制品跟踪、质量追溯、设备 OEE 四个主题构建了关联模型——通过统一的订单号、物料编码、设备编号，跨系统数据首次实现了按需关联。 数据接入的同时落地治理规则：物料主数据去重与合并、工序编码标准化、质量检验项字典统一。元数据自动采集和血缘分析——遵循 DAMA 数据管理知识体系（DMBOK2）的最佳实践——让数据"从哪里来、经过了什么处理"一目了然。 在此基础上，项目组交付了三个核心应用： 在制品跟踪看板：通过集成工序报工、设备状态等数据，自动计算每个订单在各工序的完成数量、在制数量、合格数量，关联工艺路线中的标准工时，自动生成订单进度看板。管理层点击任一订单，即可下钻到该订单当前所在工序、预计完成时间、已延误原因。 质量追溯查询：建立"原材料批次—加工设备—操作人员—检验记录"的关联模型。当遇到质量问题时，通过订单号自动关联出所用原材料的采购批次、各工序的加工设备与操作人员、每个检验项目的实测值。 设备 OEE 分析：通过设备运行信号与停机记录等数据，计算每台设备的 OEE（时间开动率、性能开动率、合格品率），并按故障、换型、待料等维度分类统计停机原因。设备科据此制定预防性维护计划。 三、效果：五个可量化的改变 1. 准交率：从"靠电话催"到"看屏幕知"。 项目建设前，订单进度全靠电话和微信沟通，计划调度每天花大量时间追问车间，准交率长期徘徊在 70% 左右。在制品跟踪看板上线后，管理者点击任一订单即可看到当前工序、完成进度和预计延误风险。准交率从约 70% 提升至 86%，客户投诉率下降 40%。 2. 质量追溯：从"两三天"到"几分钟"。 过去遇到客户投诉，质量部门要翻遍纸质流转单和散落的 Excel，追溯一个批次的完整记录通常需要两到三天。现在输入订单号即可一键获取原材料批次、加工设备、操作人员、检验记录的全链路数据。质量追溯从 2-3 天缩短到几分钟，一次客户审计中 1 小时内即完成全部资料导出。 3. 设备管理：从"说不清"到"可量化"。 项目前设备科只知道设备"坏了"，停机多久、根因是什么、影响了多少产出——全凭经验估算。现在 OEE 自动计算，停机原因按故障、换型、待料等维度分类统计。设备科据此制定预防性维护计划，非计划停机时间减少 35%。 4. 数据标准：从"各说各话"到"一套语言"。 项目前，同一个物料在 ERP、PLM、MES 里各有各的编码，生产、采购、财务三套口径经常对不上。现在物料编码、BOM 结构、工序名称在全公司统一，大幅消灭了"账实不符"的差异项，跨部门沟通不再需要反复核对口径。 5. 数据资产：从"散落各处"到"持续沉淀"。 项目前，订单、设备、质量等核心数据散落在各个系统中，既不可见也不可用。现在这些数据已沉淀为企业的数字化资产，成为后续推进预测性维护、智能排产等 AI 应用的基础数据底座。 四、启示：离散制造的数字化路径 这个案例的经验可以总结为三点： 治理先行，不急于上应用。 正如 DAMA 在《数据管理知识体系指南》（DMBOK2）中反复强调的：数据治理是数据价值实现的基石。先统一主数据标准、建立数据质量规则，再谈报表和分析。很多人一上来就想做大屏看板，但数据没理清楚、标准没统一，看板上的数字再漂亮也是"假数据"。 用真实场景倒逼落地。 在制品跟踪、质量追溯、设备 OEE 这三个场景不是因为"功能列表上有"，而是因为企业每天都被这三个问题困扰。用最痛的点驱动治理，比按部就班推进更有效。 六层数据模型是离散制造的关键。 "订单—工单—工序—设备—人员—物料"这套模型，把离散制造的核心要素串成了一个可计算、可追溯的数据链。这一思路与国际自动化学会（ISA）发布的 ISA-95（IEC 62264）标准不谋而合——该标准将制造企业划分为企业层、车间层、设备层等功能层次，强调各层级数据的标准化建模与互操作。不同类型的企业需要构建自己行业的数据模型——化工行业的"批次—配方—工艺参数"，建筑行业的"项目—标段—分项"——但思路是一致的。
国际数据管理协会（DAMA International）是全球最具影响力的数据管理专业组织之一。其发布的《DAMA-DMBOK（Data Management Body of Knowledge）》被广泛视为数据管理领域的基础知识体系。 DAMA 对数据管理给出了经典定义： "Data Management is the development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance the value of data and information assets throughout their lifecycles." —— DAMA International 即 数据管理是围绕数据和信息资产全生命周期开展规划、执行和监督的一系列制度、流程与实践活动，其目标是交付、控制、保护并持续提升数据资产价值。 在此基础上，DAMA-DMBOK 将数据管理拆解为多个知识领域，覆盖治理、架构、质量、安全、元数据、主数据等核心能力，构建了一套完整的数据管理理论框架。 但在实际项目中，很多企业都会遇到同一个问题： DAMA 告诉我们应该做什么，却没有直接告诉我们应该从哪里开始，以及具体如何推进。 尤其是在数据中台建设过程中，企业真正需要的往往不是一套知识体系，而是一套能够指导项目实施的工程化方法。 经过大量项目实践可以发现，龙石数据提出的“理采存管用”方法论，恰好能够将 DAMA 的理论框架转化为可执行的落地路径。 一、DAMA 的 11 个知识领域：一张全景图 先快速过一遍 DAMA-DMBOK 的核心领域，为后续的映射做铺垫： 领域 核心关切 在中台建设中的含义 数据治理 谁决策、谁负责、制度怎么定 治理组织和制度建设 数据架构 数据怎么组织、怎么流动 数据模型和集成架构设计 数据建模与设计 概念模型、逻辑模型、物理模型 数仓分层和模型设计 数据存储与操作 数据存在哪、怎么管 存储选型和运维 数据安全 谁能看、谁能改 权限和脱敏 数据集成与互操作 不同系统的数据怎么通 多源异构数据汇聚 文档与内容管理 非结构化数据怎么管 文档和知识库 参考数据与主数据 核心实体的统一编码 主数据管理 数据仓库与 BI 分析怎么支持 报表和可视化 元数据管理 数据从哪来、什么意思 元数据采集和血缘 数据质量 数据准不准、全不全 质量规则和监控 从内容覆盖范围来看，DAMA 已经回答了企业数据管理“应该建设哪些能力”的问题。 但对于很多企业而言，更现实的问题是： 这些能力应该如何组织？ 哪些先做？ 哪些后做？ 如何形成建设闭环？ 二、DAMA 与 DCMM：国际理论与中国标准 在国内数据治理领域，除了 DAMA，还有一个经常被提及的标准——DCMM。 DCMM（Data Management Capability Maturity Model）即《数据管理能力成熟度评估模型》，是我国首个数据管理领域国家标准（GB/T 36073-2018）。 注：DCMM 2.0（GB/T 36073-2025）已正式发布，将于 2026 年 7 月 1 日起实施。相较 1.0 版本，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。本文以现行 GB/T 36073-2018 为基础论述，实际引用时建议参考 2.0 版本。 标准指出： “帮助组织运用先进的数据管理理念和方法，建立和评价自身数据管理能力，持续完善数据管理组织、程序和制度，充分发挥数据在促进组织战略达成方面的价值。” DCMM 将数据管理能力划分为八大能力域： 数据战略 数据治理 数据架构 数据标准 数据质量 数据应用 数据安全 数据生命周期 同时建立了五级成熟度评价体系： 一级：初始级 二级：受管理级 三级：稳健级 四级：量化管理级 五级：优化级 从本质上看： 体系 关注重点 DAMA 数据管理知识体系 DCMM 数据管理成熟度评价 数据中台 数据能力平台建设 理采存管用 数据治理实施路径 三者并不冲突，而是关注点不同。 DAMA 解决的是：应该建设什么能力 DCMM 解决的是：能力建设达到什么水平 而数据中台项目需要解决的是：如何把这些能力真正建设出来 三、理采存管用：DAMA 的工程化落地 如果说 DAMA 是"理论教材"，那龙石数据的"理采存管用"就是"落地手册"。 五阶方法论不是对 DAMA 的简化，而是按照工程落地顺序对 DAMA 各领域的重新编排： 可以看到，DAMA 的知识体系被系统性地分配到了五个阶段中。其中"管"阶段承载了最多的治理职能——质量、元数据、主数据、安全，多个领域在这一环节集中落地。 这不是简单的分类对应。关键在于顺序——DAMA 告诉你"要做什么"，理采存管用告诉你"先做什么、后做什么、怎么串起来"。 四、为什么顺序很重要？ 很多中台项目失败，不是因为某个领域没做，而是顺序错了。 典型错误一：在"理"之前就做"采"。 数据资产还没盘点、标准还没定、治理组织还没建，就开始写 ETL 脚本接数据。结果是接进来的数据口径不一致，后面还得返工。上海某化工企业的教训很典型——中台项目启动后直接开始接 MES 和 ERP，三个月后发现物料编码在两边完全对不上，之前的集成工作全部重来。而正确的顺序是先做"理"：统一主数据标准、建立数据质量规则，再进入采集环节。该企业调整路径后，交付及时率从不足 70% 提升到了 91%。 典型错误二：在"管"之前就做"用"。 数据标准没统一、质量没控制、元数据没采集，就开始做报表和 AI 分析。一个常见的后果是：同一个销售额，BI 页面和财务系统差了几百万，业务部门再也不敢用。 典型错误三："管"只做技术检查，不做业务治理。 DAMA 强调数据治理首先是组织治理——要有明确的权责和考核机制。如果质量规则只在技术层面跑，没有人对业务口径负责，那数据问题永远不会从源头解决。 五、AI时代，为什么更需要数据治理？ 随着大模型快速发展，越来越多企业开始建设：AI问数、AI分析助手、AI数据助手、企业知识库。但实践证明：AI效果的上限往往取决于数据质量。 近年来兴起的 Data-Centric AI 理论认为： 与持续优化模型相比，持续提升数据质量和数据治理能力，往往能够获得更大的业务收益。 原因很简单，如果指标定义不统一、主数据不统一、元数据缺失、数据质量不可控，那么AI只会把错误答案生成得更快。 因此，AI时代并没有削弱数据治理的重要性，反而进一步提高了数据治理的战略价值。对于企业而言：数据治理是AI的基础设施。 理采存管用中的"管"，本质上是在为未来的AI应用打基础。而"用"阶段中的智能问数、智能分析，则是治理成果的集中体现。 这一趋势已在政策层面得到印证。2026年，江苏省数据局统筹启动了高质量数据集建设先行先试项目，依据国家"人工智能+"部署及《江苏省发展数据标注产业建设高质量数据集实施方案（2025—2027年）》要求，全省共 147 个项目入选省级试点。龙石数据联合江苏省市场监督管理局数据中心、苏州大学共同申报的"高质量数据集智能底座"项目顺利入选平台搭建类试点——这意味着高质量数据集建设正在从政策驱动走向工程落地，而数据治理能力是这一进程的核心基础设施。 六、怎么落地？一个实操路径 结合 DAMA 框架和理采存管用方法论，建议按以下路径推进： 第一步：用 DAMA 做成熟度评估。 在启动中台建设之前，对照 DAMA 的 11 个领域做一个快速自评：哪些领域已经有基础？哪些是空白？这一步只需要一周，但能避免后面几个月的方向性错误。 第二步：用"理"阶段建治理基础。 根据评估结果，优先建立治理组织和数据标准。DAMA 讲的"数据治理"领域对应到实践，就是在这一阶段完成——明确谁对数据质量负责、统一核心主数据编码、建立变更管理流程。 第三步：采、存、管螺旋推进。 不追求一步到位。选 1-2 个高价值数据域（比如客户域、产品域），走通"采集→建模→治理"的闭环，形成可复用的模板后再扩展。 第四步："用"推动持续迭代。 治理的目的是用。把治理后的数据通过 API 共享、BI 报表或 AI 智能问数等方式推向业务端。业务使用中产生的新需求，反馈回"理"阶段，启动新一轮规划。 七、常见问题 Q1：DAMA 和 DCMM 是什么关系？ DAMA 是国际数据管理协会发布的知识体系（DMBOK），DCMM 是中国国家标准（GB/T 36073-2018）。DCMM 参考了 DAMA 的框架，但增加了成熟度等级评估（1-5 级）。两者的核心思想一致：数据治理首先是组织治理，其次才是技术治理。2026 年 7 月起 DCMM 2.0（GB/T 36073-2025）将正式实施，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。 Q2：中小企业需要关注 DAMA 全部 11 个领域吗？ 不需要。建议重点关注数据治理、数据质量、主数据、元数据这四个基础领域，先把数据"管明白"再扩展。四个领域跑通后，数据仓库和 BI、数据安全的优先级自然上升。 Q3：理采存管用和 DAMA 冲突吗？ 不冲突。DAMA 是知识框架，理采存管用是工程落地方法。可以把理采存管用理解为"DAMA 的施工版"——它保留了 DAMA 的核心思想，但按照工程实践重新编排了顺序和重点。 Q4：治理能力建设需要多长时间？ 取决于起点。如果已经有一定的数据基础（系统建设、团队配置），可以在一个数据域内快速验证： 短期（3 个月）：完成一个数据域的盘点、标准和治理闭环，跑通"理→采→存→管→用"全流程，让业务看到效果 中期（6-12 个月）：将成功模式扩展到 3-5 个核心数据域，建立治理运营常态机制 长期（1-2 年）：形成全企业的数据治理文化，治理活动从"专项项目"变成"日常习惯" 关键在于不要追求一步到位。先跑通一个域，用效果争取更多资源，比一开始就铺开更有可持续性。 参考来源 [1] DAMA International，《What is Data Management?》 [2] DAMA International，《DAMA-DMBOK2 Data Management Body of Knowledge》 [3] GB/T 36073-2018《数据管理能力成熟度评估模型（DCMM）》 [4] GB/T 36073-2025《数据管理能力成熟度评估模型（DCMM 2.0）》，2026 年 7 月 1 日起实施，能力域扩展至九个，新增"数据资产" [5] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [6] Andrew Ng 等，《Data-Centric AI Resource Hub》 [7] 中国电子信息行业联合会，《DCMM标准解读与实施指南》
随着重点领域行业高质量数据集的逐步建成，以及“场景—数据—模型—应用”双向循环反馈机制的形成，我国有望建立起一条完备的数据安全供给链。通过全面落实《实施方案》中的各项技术与治理举措，人工智能治理得以在数据输入端筑起坚实的合规屏障，实现技术快速演进与治理体系协同共生的新局面。
AI+数仓不是噱头，它能落地，但需要选对场景、管好预期、打好基本功。别指望AI一步到位解决所有问题，也别因为AI有缺陷就否定它的价值。用对了地方，它就是提升效率的好工具。
最近跟几个做数据治理的朋友聊天，大家的焦虑感出奇地一致：大模型在元数据标注、数据质量检测、血缘分析这些场景上越做越好，很多以前需要人工干的活，AI能自动干了。那数据团队以后还能干什么？ 这个问题问得好，也问得及时。2026年以来，AI+数据治理已经成为行业共识——IT之家、天极网等多家技术媒体近期发布的分析报告都指出，数据治理平台正在从"被动规则引擎"转向"主动智能协同中枢"。三维天地、数语科技等厂商也相继推出了AI驱动的治理产品。 但我想先把一个关键认知摆在这里：AI接管的不是数据团队的工作，而是数据团队工作中那些重复性高、标准化程度高的部分。剩下的部分——策略制定、复杂判断、跨部门协同、业务价值评估——恰恰是数据团队真正应该投入精力的地方。 一、AI在数据治理中到底能干什么？ 在讨论"数据团队该干什么"之前，先明确"AI能干什么"。目前来看，AI在数据治理中的价值主要集中在四个场景。 场景一，元数据智能管理。传统模式下，元数据的采集、标注、分类分级几乎全靠人工——逐张表、逐个字段地写注释、定义业务含义。大模型在自然语言理解上的能力，可以自动识别字段的业务语义、推断数据分类、推荐数据分级建议。人需要做的是审核和确认，而不是从零开始标注。 场景二，数据质量智能检测。传统数据质量治理依赖人工定义检核规则——空值检查、格式校验、一致性比对等。AI可以从历史数据中自动发现异常模式，推荐质量检核规则，甚至预测潜在的数据质量问题。比如AI发现某个字段的值分布突然发生偏移，可能是上游系统变更导致的，它会主动预警，而不是等问题被业务方投诉了才发现。 场景三，数据血缘自动追踪。传统血缘分析依赖人工维护或工具半自动采集，覆盖范围有限且容易断裂。AI可以通过分析SQL逻辑、ETL脚本、API调用链路，自动生成端到端的数据血缘图谱，并在数据变更时自动评估影响范围。 场景四，合规风险智能识别。随着《数据安全法》《个人信息保护法》的实施，数据合规成为治理重点。AI可以自动识别敏感数据字段（如身份证号、手机号等），匹配合规策略，并生成合规风险报告，帮助团队提前发现潜在的合规风险。 下面这张图展示了AI与人在数据治理中的协作关系。 从图1可以看出，AI和人各有分工、相互配合。AI负责执行和辅助，人负责决策和审核。这个关系定义清楚了，后面的事情就好 二、AI治理的能力边界在哪？ 谈AI赋能，不能只说好处不说局限。AI在数据治理中能做到什么程度，我画了一张成熟度模型来界定。 如图所示，我把它分成了四个层级。需要客观说明的是： L1（人工规则驱动）是目前不少企业所处的阶段。治理工作高度依赖人工，效率低但可控。这个阶段不丢人，关键是要有向L2升级的意识。 L2（AI辅助治理）是当前可行的目标。AI负责生成初稿（规则、标注、报告），人负责审核确认。这个阶段投入产出比相对较高，也是目前头部厂商产品主推的方向。 L3（AI深度参与）需要较强的数据基础。要让AI主动检测异常、推荐治理策略，前提是元数据完善、数据质量基线清晰、治理流程标准化。如果这些基础没打好，AI的能力也无法充分发挥。 L4（自治治理）目前更多是愿景。完全由AI自主处理治理任务、人只在关键节点把关——这个目标在技术上还有不少挑战需要克服，短期内不建议作为企业的主要目标。 务实建议：大多数企业应该把目标定在L2到L3之间——让AI承担执行层面的重复工作，让人聚焦于策略和判断。不要被厂商的营销话术带着跑，以为买了个AI治理平台就能直接跳到L4。 三、数据团队的角色怎么变？ AI接管的越多，数据团队就越需要重新定义自己的价值。我用一张图来说明这个转变。 如图所示，数据团队的角色正在从"治理执行者"转向"数据资产运营者"。具体来说，有四个变化。 3.1 从 写规则 到 审规则 以前数据团队的大量精力花在编写和维护数据质量规则上——一张表几十个字段，每个字段可能需要好几条检核规则，几百张表下来就是海量的规则维护工作。AI介入后，这部分工作可以大幅缩减。AI根据数据特征和历史模式推荐规则，数据团队的重点变成审核这些规则是否合理、是否覆盖了业务关注的质量维度。 3.2 从 做治理 到 建体系 AI能帮你发现数据质量问题，但"发现之后怎么办"需要人来设计：这个质量问题由谁负责？修复优先级怎么排？跨部门的数据口径冲突怎么协调？这些是治理体系建设的问题，AI替代不了。数据团队需要把更多精力放在治理组织架构、流程机制、考核标准的建设上。 3.3 从 对内支撑 到 对业务赋能 传统数据治理大多是"对内"的——给技术团队用、给数据团队用，业务方的感知很弱。AI介入后，数据团队可以从重复性工作中释放出精力，去思考一个更关键的问题：治理的成果怎么转化为业务价值？比如，数据质量提升之后，报表的准确率提高了多少？决策效率改善了多少？这些量化评估能让业务方看到治理的实际价值，从而更愿意配合治理工作。 3.4 从 被动响应 到 主动运营 以前数据治理的模式是"出了问题再处理"——业务投诉数据不准，再去排查修复。AI的主动检测能力让"事前预防"成为可能。数据团队可以基于AI的预警信息，提前介入处理潜在的数据风险，把治理从被动响应转变为主动预防与持续优化。 四、落地过程中容易踩的坑 基于行业观察和实践经验，总结几个常见的坑。 坑一，跳过基础建设直接上AI。有些团队元数据管理还没做起来、数据标准还没建立、质量基线都没量，就急着引入AI治理工具。结果AI生成的建议质量很差——因为连AI都不知道哪些字段是什么含义。数据基础是AI治理的前提，这个顺序不能颠倒。 坑二，把AI治理当成纯技术项目。数据治理本质上是一个管理问题。AI能提升治理的执行效率，但"数据标准由谁制定""质量不达标的责任怎么界定""跨部门数据冲突由谁协调"这些管理层面的问题，AI解决不了。必须有配套的治理组织、流程和机制。 坑三，期望AI完全自动化。目前阶段，AI在数据治理中更适合"辅助"定位。让AI自动执行所有治理任务、完全不需要人工介入——这个目标在当前技术条件下不现实。尤其在涉及敏感数据分级、合规判断等场景，人工审核环节不能省。 坑四，忽视AI自身的治理风险。网易的一篇文章提到，当AI Agent从"能对话"演进到"能执行"时，其引发的数据治理与安全风险较传统AI显著提升。比如AI在执行数据治理任务时可能误操作敏感数据，或者AI生成的治理规则本身存在偏见。因此，对AI的治理行为本身也需要建立监控和约束机制。 五、几个关键的优化建议 最后，给几个实操层面的优化建议。 建议一，分场景逐步引入AI，不要贪多。建议从元数据管理和数据质量检测这两个场景切入——这两个场景标准化程度高、效果容易衡量、投入产出比相对明确。验证成功后再逐步扩展到血缘分析、合规识别等场景。 建议二，建立"AI生成+人工审核"的标准流程。无论哪个场景，都应该设计明确的人机协作流程：AI生成治理建议→人工审核确认→执行→记录反馈→优化AI模型。这个闭环是AI治理效果持续提升的关键。 建议三，量化治理效果，让价值可见。AI介入前后，数据质量问题的发现效率提升了多少？元数据标注的人工投入降低了多少？数据治理报告的出具周期缩短了多少？这些量化指标不仅能评估AI治理的实际效果，也能帮助数据团队向管理层和业务方展示治理工作的价值。 建议四，关注AI治理平台的安全与合规。引入AI治理工具时，要确认其对敏感数据的处理方式——数据是否会上传到云端？是否支持私有化部署？对AI的治理行为是否有审计日志？《数据安全法》和《个人信息保护法》对数据处理有明确要求，AI治理工具也必须满足这些合规要求。 六、写在最后 回到开头的问题：当AI介入数据治理，数据团队该干什么？ 答案其实很清楚：AI接管的是"执行"，数据团队应该聚焦于"策略、协同和价值"。制定治理策略、审核AI的建议、推动跨部门协同、量化治理的业务价值——这些才是数据团队在新阶段的核心工作。 换个角度看，AI不是在抢数据团队的饭碗，而是在帮数据团队从繁琐的执行工作中解放出来，去做更有价值的事。关键在于你能不能抓住这个转变的窗口期，主动调整自己的定位和能力结构。 来源（公众号）：华哥聊数据
一、为什么突然都在聊AI+数仓？ 过去两年，大模型的风刮到了数据基础设施领域。从Text-to-SQL到AI辅助建模，从自动化ETL到智能数据治理，各大厂商和开源社区陆续推出一系列工具，试图用大模型改造传统数仓的工作方式。 这个方向的内在逻辑不难理解。传统数仓建设有几大痛点：建模周期长、数据清洗依赖人工规则、ETL链路出问题需要运维半夜爬起来定位。每个环节都存在大量重复性劳动，而这些恰好是大模型擅长的事情——理解自然语言、生成代码、识别模式规律。 但一个有意思的现象是：同样一套技术方案，有的公司用得比较顺畅，建模效率明显提升，数据质量问题大幅减少；有的公司投入了不少资源，折腾了大半年，最后得出的结论是"大模型没啥用"。相似的底层技术，结果差别很大。 这背后的原因在哪？结合我这几年的一线观察，我总结了四个层面的关键分水岭。 二、跑得通的公司，做对了什么？ 1. 先把数据底子打扫干净 这是最基础、也最容易被忽视的一点。跑得通的公司，在引入AI之前，已经完成了数据标准化的基础工作——字段命名规范统一、数据字典完整、指标口径明确、元数据管理到位。大模型进来之后，有标准的元数据做上下文，不需要去"猜"某个字段的业务含义。 反过来，跑不通的公司往往是"数据裸奔"状态。同一个客户ID，CRM系统里叫customer_id，订单系统里叫user_no，日志系统里叫uid。大模型面对这种混乱的局面，别说生成准确的SQL，连理解都费劲。很多项目一上来就希望大模型"端到端"解决问题，结果数据质量不过关，大模型输出的东西也是错的，团队信心一下就被打没了。 一个判断标准：如果你现有的数仓连基本的指标口径都没有对齐，先别急着上AI。把标准定了，把字典建了，再谈大模型赋能。 2. 选对了切入点，从小场景开始跑 从我了解到的情况来看，跑得通的公司通常遵循"小切口、速赢"的策略。很多不会一上来就搞一个"企业级AI平台"，而是先挑一个高频、痛点明确、价值可量化的场景。 比如： Text-to-SQL查询：让业务人员用自然语言查数，减少数据开发写SQL的重复需求 数据质量自动稽核：用大模型识别异常数据，补充人工校验规则的不足 元数据自动补充：根据表结构和业务上下文，自动生成字段描述和业务定义 这些场景的共同点是：边界清晰、见效快、业务方感知强。一旦跑通一个场景，团队信心建立，后续推进其他场景就容易得多。而一上来就想"用AI重构整个数仓体系"的公司，项目周期拖得太长，业务方耐心耗光，往往无疾而终。 3. 懂得"什么该交给AI，什么不该" 这是很多技术团队容易忽略的问题。大模型不是万能的，也不是所有任务都适合交给它。从我观察到的做法来看，跑得通的公司普遍建立了一套分层分工机制： 任务类型 处理方式 典型场景 简单、规则明确的 传统脚本/SQL 基础数据校验 固定报表查询 复杂、需要语义理解的 大模型处理 模糊查询转SQL、异常归因分析 高频且对延迟敏感的 轻量级模型或规则引擎 实时数据质量拦截 低频且对准确度要求高的 大模型+人工审核 复杂建模、数据口径映射 核心原则是：大模型只做"需要理解能力"的事情，不碰"可以用规则解决"的事情。这样做既能控制调用成本，又能保证效率和准确率的平衡。 三、跑不通的公司，踩了哪些坑？ 坑一，数据没清干净就上AI 最典型的场景是：企业把全量业务数据直接丢给大模型，期望它自动完成清洗和治理。结果大模型面对各种不一致的字段、缺失的关联关系、混乱的编码体系，输出的数据质量大打折扣。 举个常见的例子：供应商名称这个字段，在不同业务系统里可能写成完全不同的格式——全称、简称、中英文混写、带标点不带标点。如果不在入库前做标准化映射，大模型花再多精力去"理解"这些变体，效果也不如先把数据洗干净再喂给模型。这背后是一个基本的顺序问题：AI不能替代数据治理，但它能加速已经标准化的数据治理流程。顺序反了，结果就是事倍功半。 坑二，一上来就搞"全场景覆盖" 这个问题在传统IT项目中就常见，到了AI时代被放大了。从我的经验来看，AI项目的不确定性比传统项目更高，因为你无法预判大模型在某个具体场景下的表现。场景越多，不确定性叠加，项目失败的几率也随之上升。 常见的情况是：公司成立AI+数据专项组，目标同时覆盖销售、运营、供应链、客服多个场景，预算和周期定得很高。结果几个月过去了，连第一个场景还没跑通——每个场景都需要不同的数据准备、不同的Prompt调优、不同的评估标准。资源有限却全面铺开，很容易每个场景都做不透。 一个务实的建议：如果团队还在探索阶段，先集中资源打穿一个场景，验证了价值再横向复制。 坑三，技术部门单干，业务部门不参与 大模型需要"学"业务知识。如果业务部门不参与需求定义、不提供高质量的业务语料、不参与结果评估，大模型生成的SQL和模型很可能跟实际业务需求对不上。 举个例子，"计算客户流失率"这个需求，不同部门的理解可能完全不同。销售部门认为"三个月未下单"就算流失，运营部门认为"六个月未登录"才算，财务部门可能按"账户余额为零"来定义。口径差异，大模型自己是"悟"不出来的。 坑四，忽视成本与效率的平衡 大模型的API调用成本因模型和厂商而异，按token计费的模式下，高频调用会产生一定的开销。如果所有数据操作都走大模型，月结时的费用可能会比较可观。 比如，日常的GMV查询、转化率报表这类高频查询，用大模型走一遍自然语言转SQL，延迟可能比直接跑一条预计算的SQL慢不少，调用成本也更高。把任务分层——高频、确定性高的走规则引擎或预计算，低频、模糊的走大模型——可能是更合理的做法。 四、优化方向，怎么从"跑不通"变成"跑得通"？ 方向一，从高频痛点场景切入，快速验证 如果你的公司还在探索阶段，可以考虑从这些场景入手： 数据质量稽核：大模型识别异常数据的能力在一些场景下已经具备实用价值，落地门槛相对较低 元数据自动补全：基于表结构和字段名生成业务含义描述，能较快提升数据字典的覆盖率 自然语言查询（Text-to-SQL）：适用于报表需求频繁、数据开发资源紧张的团队 ETL脚本辅助生成：适合数据量大、重复性ETL任务多的场景 每个场景建议先做小范围POC验证，确认价值后再投入资源做生产化。 方向二，建立闭环验证机制 大模型输出结果建议配合人工确认机制： 项目初期：人工复核比例适当提高，重点关注大模型输出是否符合预期 稳定期：复核比例逐步降低，同时建立自动化监控基线 成熟期：通过bad case反向驱动模型和Prompt的持续优化 每次发现大模型输出有误，记录下来分析原因——是Prompt写得不够精准？是数据本身有问题？还是场景超出了模型的能力边界？这些积累会成为后续优化的重要基础。 方向三，数据安全底线不能破 数仓里存储着大量业务数据和用户信息，直接送到公有云大模型接口存在合规风险。在实际落地中，建议做到： 敏感字段（手机号、身份证、邮箱等）在输入大模型前进行脱敏处理 所有API调用留存审计日志 明确数据使用边界，不超出业务需要的范围 有条件的企业可优先考虑私有化部署方案 五、未来展望，AI+数仓会走向哪里？ 从过去两年的行业实践来看，AI+数仓的发展有几个方向已经逐渐清晰： 第一，AI辅助能力会逐步融入数仓工具链。就像OLAP引擎成为数仓标配一样，AI辅助建模、智能数据质量稽核、自动化运维诊断等能力，在未来几年可能会成为数据平台的基础功能。企业需要思考的不是"要不要用"，而是"用在哪些环节最合适"。 第二，不同规模的模型会协同工作。大模型擅长复杂推理和语义理解，在需要"理解"的场景下优势明显。而小模型或规则引擎在处理高频、确定性任务时，在成本和响应速度上更具优势。两者配合使用，可能是更务实的方案。 第三，数据治理的重要性不会降低，反而会提升。AI越强，对数据质量的要求越高。一条不准确的数据口径，经过大模型处理后，可能产出一份看起来逻辑严谨但结论错误的报告。数据治理不是可以被AI替代的工作，而是需要和AI同步加强的基础工程。 第四，人机协同是现阶段较为可行的模式。短期内"AI替代数仓工程师"不太现实。更务实的路径是：AI处理重复性、规则清晰的常规任务，人工负责复杂决策、异常处理和效果兜底。从我接触到的案例来看，这个分工模式在成本、效率和质量三个维度上综合表现不错。 最后说句实在话：AI+数仓这件事没有捷径。先把数据管好，选对场景，边界划清楚，再让AI进来干活。按这个顺序走，大概率能跑通。反过来，跳过前两步直接上AI，十有八九要交学费。 来源（公众号）：华哥聊数据
做数据这行的朋友，大概都熟悉这个流程：业务抛过来一个取数需求，你得先搞清楚人家说的"活跃用户"到底是哪个口径，然后翻表结构写SQL，跑完数还得跟业务对齐一遍，"这个数字跟你预期差多少？"整个流程走下来，快的两三天，慢的一周都不稀奇。 但2026年的风向已经很明朗了，这一切正在被Agent改写。 微软在Fabric里嵌入了Data Agent，阿里云推出了Agentic Lake，安克创新也在公开场合分享了第三代AI数据平台的架构设计。这些头部玩家不约而同在做同一件事：让数据仓库从一个"被动等着你查"的存储系统，变成一个"能理解你要什么、能自己想清楚该怎么做"的智能体底座。 这不是PPT上的画饼。接下来，我会基于当前已经公开的行业实践和技术走向，把Agent和数仓融合这件事拆开讲清楚，进展到哪一步了、架构长什么样、落地有哪些坑。 一、先纠正一个认知偏差，Agent要改造的不是数仓本身 很多人的第一反应是"Agent要替代数仓"，这个理解是有偏差的。 数据仓库真正的护城河，统一的数据存储、标准化的建模体系、稳定的计算性能，这些东西Agent替代不了，也不需要替代。Agent改变的是另外两件事：第一，人和数仓怎么打交道；第二，数仓自己怎么管自己。 具体来说，Agent在数仓场景里解决三个层面的问题： 门槛问题。业务人员不用再学SQL了，说人话就能查数据。但要注意，这跟早年那些"自然语言查数"产品有本质区别。那些产品本质上是个翻译器，你问一句它翻一句SQL，准确率惨不忍睹。Agent的做法是：先理解你的业务意图，再决定查哪些表、怎么关联、用什么口径，生成SQL之后还会自动校验，语法对不对、业务规则有没有违反、跑出来的数据合不合理，全部过了才给你结果。 效率问题。数据治理、质量监控、ETL调度这些日常运维工作，Agent能扛下来大部分。自动发现数据异常、沿血缘链路追踪问题源头、生成治理报告，这些以前需要数据工程师花大量时间做的事情，现在可以让Agent去跑。 决策问题。传统数仓的交互模式是"你问它答"，本质上是被动的。Agent驱动下的数仓能主动发现问题、提出建议，甚至在明确规则下直接执行修复。这形成了一个"感知-分析-决策-执行"的闭环，数仓从"被查询的工具"变成了"主动服务的系统"。 二、数仓架构的三代演进 要把Agent和数仓融合这件事讲透，得先把数仓自身的演进脉络捋清楚。大致可以分成三代： 第一代：传统数仓（约2000-2015年）。关键词是"批处理ETL +固定报表"。数据通过定时任务从业务库同步到数仓，工程师写ETL脚本做清洗转换，分析师写SQL出报表。这套东西跑起来很稳，但太笨重了，业务要加一个分析维度，可能要改好几个层级的表结构和ETL脚本，响应速度跟不上。 第二代：湖仓一体+语义层（约2015-2024年）。数据湖解决了非结构化数据的存储问题，湖仓一体进一步把存储和计算打通。语义层（比如dbt的Semantic Layer）让指标定义有了统一标准，业务方理论上可以自助取数了。但"自助分析"的门槛还是不低，你得懂数据模型，还得学BI工具怎么用。 第三代：Agent原生数据平台（2025年起）。在湖仓和语义层的基础上，Agent作为一层"智能中间件"插进了人和数据之间。它能理解自然语言意图、自动编排数据访问路径、自主执行治理任务。数仓不再只是个"存储+计算引擎"，而是一个具备感知和执行能力的智能体底座。 三、Agent原生数据平台的五层架构 综合微软Fabric、阿里云Agentic Lake、安克创新等公开实践，Agent原生数据平台的架构可以拆成五个层次。下面逐层讲。 1. 交互层：业务侧的入口 交互层支持文字、语音、图片等多模态输入。用户用自然语言描述需求，比如"帮我看看华东区上个月各品类的销售走势"，交互层负责把这个模糊的需求转成结构化的任务指令。 这里有一个关键的行业认知需要澄清：交互层的核心不是做一个"好看的聊天框"，而是意图理解的准确率。直接拿通用大模型来理解业务查询，准确率通常只有60%-70%，离生产可用差很远。真正的解法是在交互层和Agent编排层之间加一层语义校验机制，Agent生成的SQL要过三道关：语法校验、业务规则校验、数据合理性校验，全部通过后才返回结果。 2. Agent编排层：多智能体协作的中枢 这是整个架构的核心。它不是一个Agent单打独斗，而是一个由多个专业Agent组成的协作网络。根据当前公开案例，常见的Agent角色包括： Agent角色 核心职责 当前成熟度 意图识别Agent 解析自然语言，识别查询意图、筛选条件和聚合维度 较高 SQL生成Agent 基于语义层和元数据，生成可执行的SQL 较高 数据质量Agent 监控数据质量异常，自动触发告警和修复 中等 ETL调度Agent 智能调度数据同步任务，处理依赖和异常 中等 指标管理Agent 维护指标定义，检测口径冲突，自动对齐 早期 多个Agent之间怎么协作？当前行业主流的做法是"编排式"架构，一个中央编排器（Orchestrator）根据任务类型分派给对应的专业Agent。好处是可控、可审计；缺点是复杂任务的协作规则需要预先定义，灵活性受限。 另一种是"对等式"多Agent架构，各Agent自主协商完成任务。但目前基本还在学术研究阶段，企业级生产环境落地的案例非常少。 3. 语义与知识层：Agent的"业务常识" 这一层是Agent准确理解业务的前提。没有语义层，Agent就像一个精通SQL语法但完全不懂业务的人，能写出语法正确的查询，但结果可能南辕北辙。 语义层的建设核心包括三块： 业务词汇表。定义业务术语与物理表字段的映射。比如"活跃用户"在不同业务场景下怎么算、数据从哪来、计算逻辑是什么。这是Agent理解业务意图的地基。 知识图谱。存储数据之间的关联，数据血缘、指标依赖、业务实体关系。Agent做根因分析时，需要沿着图谱的关联路径进行推理。 指标存储。标准化的指标定义和管理，保证同一个指标在不同Agent、不同场景下的计算结果一致。 阿里云在2026年峰会上提出的"Agentic Lake"架构，核心思路就是把DLF（数据湖管理平台）升级成Agent的"记忆底座"，让Agent记住企业的数据资产关系、业务口径和历史交互上下文。这个思路很关键：语义层不只是翻译字典，更是Agent的长期记忆。 4. 数据存储与计算层 这一层本质上还是湖仓一体的存储和计算引擎，架构层面变化不大。核心组件包括数据湖（Iceberg/Hudi/Delta Lake）、数仓计算引擎（Spark/Flink/StarRocks等）、实时和离线两条计算链路。 Agent在这一层的价值主要体现在执行优化上，根据查询特征自动选择最优的计算引擎和资源配比，而不是靠人工经验配置。Snowflake的Cortex和Databricks的AI/ML功能已经在这个方向上做了不少探索。 5. 数据源层 结构化数据库、日志系统、SaaS应用、IoT设备、文件系统等，与传统架构没有本质区别。但Agent可以自动化完成更多的数据接入和Schema推断工作，降低运维成本。 四、数据治理，Agent最有可能率先规模化落地的场景 数据治理是数仓运营中最吃人力、也最容易被Agent改造的环节，值得重点展开。 传统的数据治理高度依赖人工，工程师发现问题、分析原因、修复问题、更新文档。整个链路是被动响应式的，出了事才处理，效率很低。 Agent驱动的数据治理，核心转变是从"被动响应"到"主动闭环"，六个环节形成自动化链条： 感知层：Agent充当数据哨兵 通过持续的数据探查（Data Profiling）和变更监控，自动捕捉异常。比如某个字段的空值率从2%突然跳到15%，或者某张表的行数同比减少了30%。这些异常散落在海量监控数据中，人工很难第一时间发现，但Agent可以7×24小时不间断扫描。 理解层：Agent充当数据侦探 发现异常后，Agent沿数据血缘链路追踪问题源头。比如某张报表数据异常，Agent可以自动追溯到上游ETL任务的调度延迟、源表Schema变更、或上游业务系统的数据传输故障。这一步技术难度最高，严重依赖元数据管理的完善程度。 决策层：Agent充当治理参谋 根据异常的严重程度和影响范围，Agent给出处理建议：低优先级问题自动创建工单排队，高优先级问题（如影响核心报表数据）立即告警并推荐修复方案。 执行层：Agent充当自动修复工 对于规则明确的问题（数据格式不统一、字段缺失、编码错误等），Agent可以直接执行修复。对于需要人工判断的问题（如业务口径变更），Agent生成详细的诊断报告和修复建议，交给数据治理专员审核后执行。 需要实话实说：完全自动化的数据治理闭环目前还做不到。行业实践采取的是人机协同策略，Agent处理80%的常规任务，剩下20%需要人类判断的复杂问题交给专员处理。这个比例在未来一两年内有望继续提升。 五、现实的进度条，哪些已经能落地，哪些还在画饼 已经可以落地的场景 Text-to-SQL查询。技术已相对成熟，dbt Copilot、Microsoft Fabric Data Agent等产品已支持生产级使用。前提条件是语义层建设到位，且查询场景相对标准化（如固定维度的销售分析、用户分析）。 自动化数据质量监控。规则明确的质量检测（空值率、唯一性、格式校验等）已可自动化。Agent在此基础上能做异常根因的初步分析和影响评估。 元数据管理和文档生成。Agent可以自动扫描表结构、生成数据字典、维护血缘关系文档。这是目前落地门槛最低的Agent应用场景之一。 仍在探索中的场景 自动化ETL开发。Agent能根据业务需求生成ETL脚本，但复杂的数据转换逻辑（多表Join、窗口函数、自定义UDF等）仍然需要工程师深度介入。当前Agent生成的ETL脚本需要人工Review的比例在60%以上。 智能数据建模。Agent可以根据业务描述建议维度模型的设计（事实表、维度表的选择），但数据建模需要对业务有深度理解，完全自动化尚不现实。 多Agent自主协作。"对等式"多Agent架构在学术层面有不少探索，但企业级生产环境的案例极少，可靠性和可审计性都不够。 一句话概括当前状态：Agent在数仓场景中的定位是"提效工具"，不是"替代方案"。它能显著降低数据消费的门槛、减少治理的人力投入，但离"完全自主运行"还有相当距离。2026年是Agent+数仓从POC走向规模落地的关键年份，但短期内的务实预期是"人机协同"，而非"全自动"。 六、给想动手的团队三条建议 如果你所在的数据团队正在考虑引入Agent能力，基于当前行业实践，有三条务实的切入路径： 第一条，先把语义层建好。语义层是Agent理解业务的前提。没有语义层，Agent就是"瞎子摸象"，能写SQL但不理解业务。语义层建设不依赖AI技术，核心是梳理业务指标体系、定义标准口径、建立术语表。这个工作即便不引入Agent，也是数据治理的基础工程，早做早受益。 第二条，从数据治理场景切入。相比直接让Agent写SQL给业务方用（涉及数据安全和准确性风险），让Agent先承担数据质量监控、元数据管理、文档生成等内部运维任务，风险更低、见效更快。这也是目前行业落地最成熟的路径。 第三条，建立 信任分级 机制。Agent在数仓场景中生成的SQL、做出的治理决策，必须经过可信度分级。高置信度的操作自动执行，低置信度的必须人工审批。微软Fabric Data Agent的设计中就包含明确的权限和审批机制，这个思路值得借鉴。 写在最后 Agent与数据仓库的融合，正在从技术讨论变成工程现实。2026年的信号已经非常清晰：头部云厂商和标杆企业都在围绕Agent重新构建数据平台的能力边界。 但作为从业者，需要保持清醒的认知。Agent不是万能药，不会一夜之间颠覆数仓的底层逻辑。数据仓库的核心价值，统一、标准、可信的数据基座，依然不可替代。Agent真正改变的是"人怎么用数仓"和"数仓怎么管自己"这两件事。 真正值得思考的问题不是"Agent会不会取代数仓"，而是"你的数仓准备好迎接Agent了吗"，语义层是否完善、元数据管理是否到位、治理流程是否标准化。这些基础功课做扎实了，Agent能力的引入才会水到渠成。 来源（公众号）：华哥聊数据
一、传统数仓的“三座大山” ETL脚本上千行，调度任务上百个，元数据却一团乱麻。传统数仓的“三座大山”：开发效率低，一个ETL任务从需求到上线至少两三天；治理靠人工，元数据补全、质量监控还在用Excel维护；分析门槛高，业务方看个数据得排队，分析师70%的时间花在取数上。 2025年至2026年，AI Agent技术突然火了，给这些老问题带来了新解法。这篇文章不扯概念，直接说怎么落地。 二、Agent + 数仓到底是个啥？ 先说清楚，Agent不是来取代数据工程师的，就是个辅助。说白了就是给大模型接上API，让它能看懂元数据、能写SQL、能调接口、能盯着任务跑、出问题了还能自己试着修。数据工程师的角色从“写代码”变成“指挥Agent干活”，把精力腾出来做更有价值的事。 Agent + 数仓的核心逻辑很简单：把那些确定性的、重复的工作交给机器，不确定的、需要判断的留给人。不是无人驾驶，是辅助驾驶。 从架构上看，大概分三层： 三、四个能落地的方向 1. 智能ETL 这个方向目前落地最多。以前做个ETL任务，先跟业务对需求，再写SQL，配调度，上线后发现数据不对还得排查。现在Agent可以这么干：你丢一句“把昨天新增用户按省份汇总”，它自己去查元数据找到对应的表和字段，把SQL写好，跑测试用例校验数据质量，配好调度和告警，任务失败了还能自动翻日志找原因。 我们在一个200多张表、日均500多个任务的数仓上试过，ETL开发效率大概提了60%，数据质量出问题到发现的时间从小时级降到了分钟级。当然，复杂的业务逻辑和模型重构还是得人盯着。 2. 元数据管理 干过数仓的都懂，元数据基本是“欠债”状态。字段没注释、表关系不清楚、口径文档跟实际代码对不上——太常见了。 Agent在这块能干三件事：一是自动补全，读SQL脚本推断字段的业务含义，准确率能到85%以上，人工过一遍就行；二是血缘解析，自动建字段级的血缘关系，上游表结构变了能评估影响范围；三是对口径，对比同名指标在不同报表里的SQL实现，发现不一致的地方标出来。 注意，Agent不是从零建血缘，它是在已有的SQL解析结果上补充业务语义，让血缘关系变得“能看懂”。 3. 数据质量 传统质量监控两个痛点：规则全靠人工配，太累；告警太多，看不过来。Agent的做法是：根据字段的数据类型和分布特征，自动推荐质量规则，你审核一下就行。告警触发了，Agent自动拉上下游数据分析原因，给出修复建议。常见问题像空值填充、格式标准化这些，Agent直接修了，复杂问题生成方案等人确认。 在某电商数仓项目里，质量规则覆盖率从35%干到了79%，误报率降了大概36%。 4. 智能BI 这个场景用户感知最强。业务方直接问“上个月华东区销售额TOP10品类是哪些”，Agent理解问题、查元数据、生成SQL、出结果。追问“按周看趋势”，Agent保持上下文继续往下分析。还能定时扫关键指标，发现异常主动推预警。 但别指望Agent替代分析师，它只是把“取数”这个环节的门槛降低了。真正有价值的洞察，还得靠人。 来源（公众号）：华哥聊数据
