引言对于开发者而言离线数据开发中数据质量建设的核心挑战从来不是“能否配置规则”而是质量规则能否像代码一样低成本、高可靠地融入研发交付全流程。当质量规则游离于开发链路之外治理便退化为被动补救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(idBIGINT COMMENT主键,user_idSTRING COMMENT用户ID,item_idSTRING COMMENT商品ID,shop_idSTRING COMMENT店铺ID,nameSTRING COMMENT用户姓名,family_nameSTRING COMMENT姓氏,birth_timeDATETIME COMMENT日期类型的生日,order_urlSTRING COMMENT下单地址是一个web页面地址,create_timeDATETIME COMMENT日期类型的下单时间,order_timeSTRING COMMENT下单时间,user_ipSTRING COMMENT下单客户端ip,user_macSTRING COMMENT下单客户端mac地址,user_agentSTRING COMMENT下单时的客户端标识,emailSTRING COMMENT用户账号的邮箱,phone_numberSTRING COMMENT用户的联系方式,amountSTRING COMMENT购买数量,unit_priceDECIMAL(38,18)COMMENT单价,client_tokenSTRING COMMENT下单时生成的全链路唯一标识避免失败重试的重复下单,statusSTRING COMMENT订单状态Ready - 就绪、WaitingPayed - 待付款、Payed - 已付款待发货、Canceled - 已取消、Shipped - 已发货、WaitingCollecting - 已送达未领取、Delivered - 已收货、Confirmed - 已确认)PARTITIONED BY(ds STRING COMMENT日期分区格式yyyymmdd)LIFECYCLE365;2.2.1 在 IDE 中配置规则在 SQL 开发完毕后可以点击编辑器工具栏中的“质量测试”按钮打开”质量测试“面板开始定义数据质量监控 Spec。如下图所示是一份同时监控两张表的Spec的结构。这里我们简单讨论一下数据质量监控定义方式上的取舍。在 DataWorks 既有的数据质量产品流程中都是优先引导用户使用表单的方式来定义数据质量监控和规则这种交互方式的好处在于上手门槛低配合数据质量产品层面提供的智能化推荐能力在大多数场景下可以做到一键配置。但是这种交互也有一定的问题信息密度低尤其是多表一次性多表监控场景下需要填写多张表单表单和表单之间可能还会有相互跳转交互繁琐程度大大提升必须先有表才支持配置数据质量监控否则会没有配置入口在跨项目迁移、跨 region 迁移、搬站流程时这个问题会更加明显在很多数据迁移场景中会先迁代码再建表表不存在时无法把数据质量规则快速迁移到目标环境中与 SQL 节点一起验证可迁移能力差如果大部分表都使用同一份配置那么表单模式下用户需要反复选表再填写表单。引入 Spec 之后上述问题都可以得到解决Spec 的信息密度很高如果对于很多常用规则只需要一到两行代码即可定义整个数据质量监控也基本可以在十行代码之内搞定无需先搜索表再写 Spec表名和所属数据源直接使用 Spec 定义只需要确保在 Spec 执行时表存在即可另外DataWorks 的数据质量 Spec 兼顾了 AWS Glue Data Quality、Soda、Google Dataplex 等数据质量产品中的相关设计可以把这些产品的数据质量配置转换成 DataWorks 数据质量 Spec为搬站提供助力。可以快速的复制粘贴快速拷贝能力通过Agent配置规则DataWorks Agent 智能体基于自然语言交互结合大模型的深度认知与规划能力能够完成复杂的数据集成、开发及治理任务实现从需求到成果的端到端自动化大幅提升工作效率。Spec 的书写相对于表单式的配置门槛更高些这里建议通过 DataWorks Agent 对话式的方式让 AI 辅助生成 SpecAI 辅助生成时会感知 SQL 写入的表和分区并生成合适的数据质量规则。如果默认生成的 Spec 需要调整也可以通过对话的方式做调整比如下图基于上一步中生成的数据质量 Spec我们让 AI 帮助去掉除了 id 字段之外其他字段的非空规则。当然也可以手动编辑 Spec我们提供了一些能力来提升手动编写的效率。模板插入表/字段自动补全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 的变更也体现了数据质量监控的变更统一了版本管理。三、未来工作更广覆盖、更低门槛、更主动治理3.1 多引擎覆盖当前能力已支持 MaxCompute SQL其他类型 SQL 正在推进中目标包括 EMR、Hologres、StarRocks 等让不同引擎在质量能力上获得一致体验。3.2 降低 Spec 门槛我们会持续强化“对话式生成 局部自动修改”的编写方式在现有高亮、表/字段提示能力基础上进一步推进更强的代码级提示与批量化编辑能力同时增强基于AI自动生成质量Spec能力让 Spec 的编写成本持续下降。3.3 更深融入 IDE下一阶段会把质量治理更深度地融入研发工作流在 IDE 中基于DataWorks Agent主动检测质量配置缺失提供智能修复建议将治理动作收敛至研发链路。我们致力于让“质量随交付演进”成为离线数据开发的默认体验。欢迎各位开发者试用反馈共同推动数据质量治理的工程化实践。