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

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

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

• 治理滞后：规则配置晚于数据上线，问题发现延迟

• 迭代不同步：SQL口径逻辑变更后，规则未联动更新

• 版本管理缺失：规则脱离代码评审、Diff、回滚体系，难追踪

• 信任成本攀升：下游因数据约束不透明而反复确认，沟通负担加重

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

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

• 开发即治理：在 IDE 中直接为 SQL 节点编写质量 Spec，规则与代码同生命周期。

• 工程化管理：Spec 支持版本控制、代码评审、Diff 对比，随发布流程自动部署至生产环境。

• 闭环执行：规则成为节点交付物的一部分，在调度中自动执行，确保质量保障前置化。

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

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

• 规则通常在数据上线后才补配置：治理滞后，问题发现延迟。

• SQL 迭代与规则不同步：字段口径、过滤条件、分区逻辑变化后，规则仍停留在旧假设上，最终造成误报/漏报。

• 质量治理变成“出了问题再补救”：规则配置与修复工作被动插入到事故之后。

• 规则与任务割裂：规则不在代码评审链路里，难评审、难追踪、难回滚。

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

• 从“事前预防”退化为“事后补救”，影响数据消费者信任。

• 生产者与消费者的预期难以对齐，沟通成本攀升。

• 规则维护变成长期负担：一旦规模扩大，就会出现“规则越配越多，但可信度越配越低”的反直觉现象。

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

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

• 在 IDE 中直接配置：编写 SQL 的同时编写质量 Spec。

• 天然支持版本管理：规则随代码一起 Diff、评审、回滚。

• 随发布自动执行：规则不再依赖“事后补配置”，而是成为节点交付物的一部分，在生产调度中自动执行。

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

下面，我们结合首次开发 -> 测试验证 -> 提交发布 -> 调度运行 -> 迭代发布的流程，来说明如何做到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 既有的数据质量产品流程中，都是优先引导用户使用表单的方式来定义数据质量监控和规则，这种交互方式的好处在于上手门槛低，配合数据质量产品层面提供的智能化推荐能力，在大多数场景下可以做到一键配置。但是这种交互也有一定的问题：

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

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

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

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

2.2.2 开发与测试

数据质量Spec定义完毕后，可以在IDE中直接进行测试验证。

2.2.3 提交发布

测试符合预期后，执行任务的提交发布流程，数据质量Spec会跟随节点的代码一同被发布到调度，并一同被纳入版本管理。

这里注意，在运维中心的质量节点中也可以看到对应的配置。这就又带来了一个好处：依赖这个节点的开发可以更加明确的知道这个节点产出的数据的约束，增加下游节点对这个节点的信任程度。

2.2.4 查看执行结果

上线后，生产调度会自动执行规则，你可以查看扫描日志与结果：

2.2.5 迭代开发

现在 dws_d_dqc_suggesion_demo 这张表的监控已经得到了保障，随着需求的推荐，我们需要为 dws_d_dqc_suggesion_demo 增加新的字段，此时在 SQL 开发完毕后，可以重新使用上述流程增量的修改数据质量监控 Spec，保证数据质量与 SQL 的一致性。

如图，我们添加 status_comment 字段的加工和监控逻辑，发布时可以看到版本变更中，不仅体现了 SQL 的变更，也体现了数据质量监控的变更，统一了版本管理。

当前能力已支持 MaxCompute SQL；其他类型 SQL 正在推进中，目标包括 EMR、Hologres、StarRocks 等，让不同引擎在质量能力上获得一致体验。

我们会持续强化“对话式生成 + 局部自动修改”的编写方式；在现有高亮、表/字段提示能力基础上，进一步推进更强的代码级提示与批量化编辑能力，让 Spec 的编写成本持续下降。

下一阶段会把质量治理更深度地融入研发工作流：在 IDE 中主动检测质量配置缺失，提供修复建议，将治理动作收敛至研发链路。

我们致力于让“质量随交付演进”成为离线数据开发的默认体验。欢迎各位开发者试用反馈，共同推动数据质量治理的工程化实践。