告别先开发后治理：Agent 驱动的数据质量一体化交付

2026-03-12 125

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文介绍DataWorks如何通过Data Contracts理念实现“代码即质量”：将数据质量规则以YAML Spec形式嵌入SQL开发流程，支持IDE内配置、版本管理、自动部署与闭环执行，解决传统治理滞后、迭代不同步、版本缺失等痛点，推动数据质量工程化、前置化。

引言

对于开发者而言，离线数据开发中数据质量建设的核心挑战，从来不是“能否配置规则”，而是：质量规则能否像代码一样低成本、高可靠地融入研发交付全流程。当质量规则游离于开发链路之外，治理便退化为被动补救：SQL上线后补配质量规则、字段变更引发误报漏报、规则与代码版本脱节……最终导致规则越配越多，忙于补救的恶性循环。

开发和治理割裂流程下的工程代价

治理滞后：规则配置晚于数据上线，问题发现延迟
迭代不同步：SQL口径逻辑变更后，规则未联动更新
版本管理缺失：规则脱离代码评审、Diff、回滚体系，难追踪
信任成本攀升：下游因数据约束不透明而反复确认，沟通负担加重

DataWorks 解法：以 Data Contracts 思想驱动“代码即质量”

DataWorks 数据质量引入 Data Contracts 理念，将质量规则以 YAML Spec 形式嵌入开发流程，实现“代码即质量”的一体化开发治理：

开发即治理：在 IDE 中直接为 SQL 节点编写质量 Spec，规则与代码同生命周期。
工程化管理：Spec 支持版本控制、代码评审、Diff 对比，随发布流程自动部署至生产环境。
闭环执行：规则成为节点交付物的一部分，在调度中自动执行，确保质量保障前置化。

本文将从开发治理分离带来的问题出发，详细介绍 DataWorks 如何通过一体化开发治理流程，把质量规则变成节点交付物的一部分，并进一步说明为了实现这条链路，底层架构升级带来的外溢收益与后续规划。

一、当前困境：开发与治理分离

目前在常见工程化链路中，SQL开发与数据质量监控配置是分离的，现象包括：

规则通常在数据上线后才补配置：治理滞后，问题发现延迟。
SQL 迭代与规则不同步：字段口径、过滤条件、分区逻辑变化后，规则仍停留在旧假设上，最终造成误报/漏报。
质量治理变成“出了问题再补救”：规则配置与修复工作被动插入到事故之后。
规则与任务割裂：规则不在代码评审链路里，难评审、难追踪、难回滚。

这就导致质量保障很难工程化：

从“事前预防”退化为“事后补救”，影响数据消费者信任。
生产者与消费者的预期难以对齐，沟通成本攀升。
规则维护变成长期负担：一旦规模扩大，就会出现“规则越配越多，但可信度越配越低”的反直觉现象。

二、DataWorks 的解决方案：一体化开发治理

DataWorks 数据质量借鉴当前业界中 Data Contracts 的思想，把数据质量的声明通过 Spec 的方法融入到整个数据开发流程中，让开发者可以一体化的维护数据加工代码和数据质量声明，二者能够及时的与数据开发代码一同变更，确保数据质量能够得到及时的保障。

2.1 核心思路：SQL与数据质量Spec一体化开发交付

在 DataWorks 新范式中，数据质量规则以 YAML Spec 形式存在，并具备与代码一致的工程化属性：

在 IDE 中直接配置：编写 SQL 的同时编写质量 Spec。
天然支持版本管理：规则随代码一起 Diff、评审、回滚。
随发布自动执行：规则不再依赖“事后补配置”，而是成为节点交付物的一部分，在生产调度中自动执行。

可以把它理解为：把“质量”从一个平台治理动作，变成研发交付链路中的标准步骤。

2.2 完整工作流

下面，我们结合首次开发 -> 测试验证 -> 提交发布 -> 调度运行 -> 迭代发布的流程，来说明如何做到SQL开发和数据质量保障一体化。

假设我们要开发一张表，建表语句如下：

CREATE TABLE IF NOT EXISTS dws_d_dqc_suggesion_demo(
  `id` BIGINT COMMENT '主键',
  `user_id` STRING COMMENT '用户ID',
  `item_id` STRING COMMENT '商品ID',
  `shop_id` STRING COMMENT '店铺ID',
  `name` STRING COMMENT '用户姓名',
  `family_name` STRING COMMENT '姓氏',
  `birth_time` DATETIME COMMENT '日期类型的生日',
  `order_url` STRING COMMENT '下单地址，是一个web页面地址',
  `create_time` DATETIME COMMENT '日期类型的下单时间',
  `order_time` STRING COMMENT '下单时间',
  `user_ip` STRING COMMENT '下单客户端ip',
  `user_mac` STRING COMMENT '下单客户端mac地址',
  `user_agent` STRING COMMENT '下单时的客户端标识',
  `email` STRING COMMENT '用户账号的邮箱',
  `phone_number` STRING COMMENT '用户的联系方式',
  `amount` STRING COMMENT '购买数量',
  `unit_price` DECIMAL(38,18) COMMENT '单价',
  `client_token` STRING COMMENT '下单时生成的全链路唯一标识，避免失败重试的重复下单',
  `status` STRING COMMENT '订单状态，Ready - 就绪、WaitingPayed - 待付款、Payed - 已付款待发货、Canceled - 已取消、Shipped - 已发货、WaitingCollecting - 已送达未领取、Delivered - 已收货、Confirmed - 已确认'
)
PARTITIONED BY(
    ds STRING COMMENT '日期分区，格式yyyymmdd'
)
LIFECYCLE 365;

2.2.1 在 IDE 中配置规则

在 SQL 开发完毕后，可以点击编辑器工具栏中的“质量测试”按钮，打开”质量测试“面板，开始定义数据质量监控 Spec。

如下图所示，是一份同时监控两张表的Spec的结构。

这里我们简单讨论一下数据质量监控定义方式上的取舍。在 DataWorks 既有的数据质量产品流程中，都是优先引导用户使用表单的方式来定义数据质量监控和规则，这种交互方式的好处在于上手门槛低，配合数据质量产品层面提供的智能化推荐能力，在大多数场景下可以做到一键配置。但是这种交互也有一定的问题：

1. 信息密度低，尤其是多表一次性多表监控场景下，需要填写多张表单，表单和表单之间可能还会有相互跳转，交互繁琐程度大大提升

2. 必须先有表才支持配置数据质量监控，否则会没有配置入口；在跨项目迁移、跨 region 迁移、搬站流程时这个问题会更加明显，在很多数据迁移场景中，会先迁代码再建表，表不存在时，无法把数据质量规则快速迁移到目标环境中与 SQL 节点一起验证

3. 可迁移能力差，如果大部分表都使用同一份配置，那么表单模式下，用户需要反复选表再填写表单。

引入 Spec 之后，上述问题都可以得到解决：

1. Spec 的信息密度很高，如果对于很多常用规则，只需要一到两行代码即可定义，整个数据质量监控也基本可以在十行代码之内搞定

2. 无需先搜索表再写 Spec，表名和所属数据源直接使用 Spec 定义，只需要确保在 Spec 执行时表存在即可；另外，DataWorks 的数据质量 Spec 兼顾了 AWS Glue Data Quality、Soda、Google Dataplex 等数据质量产品中的相关设计，可以把这些产品的数据质量配置转换成 DataWorks 数据质量 Spec，为搬站提供助力。

3. 可以快速的复制粘贴，快速拷贝能力

通过Agent配置规则

DataWorks Agent 智能体基于自然语言交互，结合大模型的深度认知与规划能力，能够完成复杂的数据集成、开发及治理任务，实现从需求到成果的端到端自动化，大幅提升工作效率。

Spec 的书写相对于表单式的配置门槛更高些，这里建议通过 DataWorks Agent 对话式的方式让 AI 辅助生成 Spec，AI 辅助生成时会感知 SQL 写入的表和分区，并生成合适的数据质量规则。