Great Expectations、Deequ、DataWorks DQC——三大DQC工具到底怎么选？

import great_expectations as ge
 
# 加载数据并创建Expectation Suite
df = ge.read_csv('orders.csv')
 
# 期望：order_id字段非空、唯一、且为整数
df.expect_column_values_to_not_be_null('order_id')
df.expect_column_values_to_be_unique('order_id')
df.expect_column_values_to_be_of_type('order_id', 'int64')
 
# 期望：amount字段在合理范围
df.expect_column_values_to_be_between('amount', 0, 1e8)
 
# 期望：status枚举值
df.expect_column_values_to_be_in_set('status', ['paid','refund','cancel'])
 
# 跨字段勾稽
df.expect_column_pair_values_A_to_be_greater_than_B('order_amount','discount_amount')
 
# 执行验证并自动生成HTML报告
results = df.validate()

import com.amazon.deequ.VerificationSuite
import com.amazon.deequ.checks.{Check, CheckLevel}
 
val df = spark.read.parquet("s3://bucket/dwd_order/dt=20240315/")
 
val verificationResult = VerificationSuite()
  .onData(df)
  .addCheck(
    Check(CheckLevel.Error, "订单表核心校验")
      .hasSize(_ >= 1000000)              // 数据量下限
      .isComplete("order_id")            // order_id 100% 非空
      .isUnique("order_id")              // 主键唯一
      .isContainedIn("status", Array("paid","refund"))
      .isNonNegative("amount")
      .satisfies("amount <= 1e8", "金额合理范围")
  ).run()
 
// 失败的约束打印出来
verificationResult.checkResults.foreach { case (_, r) =>
  r.constraintResults.filter(_.status != "Success")
    .foreach(c => println(s"FAIL: ${c.constraint} - ${c.message}"))
}

Deequ还有一个核武器是增量计算（Incremental Metrics）：每次只计算增量数据的指标，再合并到历史指标，对TB级数据非常友好。这点GE和DataWorks DQC都做不到。

DataWorks DQC的实战配置

DataWorks DQC是我在当前出海短剧公司的主力DQC工具。最大的好处是「零开发成本」——业务/数据分析师都可以自己配规则，不用找数据开发：

-- DataWorks DQC支持两种配置方式：
-- 1. 模板规则（界面勾选，零代码）
--    例如：表行数波动、字段空值率、唯一性、枚举值
 
-- 2. 自定义SQL规则（适合勾稽校验）
-- 配置界面填入下面SQL，并设置告警条件
SELECT
  SUM(CASE WHEN ABS(order_amount - discount - paid) > 0.01 THEN 1 ELSE 0 END) AS bad_rows,
  COUNT(*) AS total_rows
FROM ${dwd_order_payment} WHERE dt = '${bizdate}';
-- 强规则：bad_rows = 0 才通过，否则阻断下游
-- 弱规则：bad_rows / total_rows < 0.001 仅告警

强规则 vs 弱规则：DataWorks的精髓在这里。强规则不通过会自动阻断下游任务，弱规则只发告警不阻断。这个机制非常重要，能避免「告警满天飞但没人处理」。

我的真实选型决策树

你的情况	推荐工具	理由
阿里云全家桶	DataWorks DQC	原生集成、零运维、强弱规则机制成熟
AWS+Databricks/Spark	Deequ	性能最强、Spark原生、增量计算
多云/自建Hadoop	Great Expectations	跨平台、社区活跃、生态最完整
数据量<1TB+小团队	Great Expectations	上手最快、报告最美
数据量>10TB+大团队	Deequ或自研	Spark原生才扛得住
业务/分析师为主	DataWorks DQC或GE	可视化配置、人人可用

面试高频追问

追问一：你们用XX工具，遇到过它的什么局限？

DataWorks DQC的局限：跨表勾稽支持弱（只能在单SQL里写）、规则版本管理差（改规则没有Git diff）、告警渠道单一（钉钉/邮件，不能直接推PagerDuty）。Deequ的局限：纯Scala API对Python团队门槛高、HTML报告需要自己做。GE的局限：Spark Backend性能差、Expectation Suite的JSON结构层级太深难维护。回答时要具体到「哪里卡过你」，比泛泛而谈深度强10倍。

追问二：自研DQC框架什么时候考虑？

三个信号：第一，数据量超出现成工具能力（10TB+/规则）；第二，需要深度业务勾稽（横跨10+张表）；第三，组织上需要把质量数据沉淀成资产（规则库、问题库、责任人体系）。我在出海硬件公司就做过半自研——Deequ负责执行，自己写了规则配置中心+告警分发+问题闭环平台。

追问三：DQC和监控告警系统是什么关系？

DQC负责「数据本身」的校验，监控告警系统（Prometheus、阿里云监控）负责「数据基础设施」的可观测性。两者是上下层关系：基础设施告警先于数据告警——任务都没跑，DQC自然报不了。生产实践里一定要把两者打通，比如DQC告警自动带上调度系统链接、Spark UI链接、上下游表血缘，缩短MTTR。

实战踩坑：从GE迁移到DataWorks DQC的那次代价

我刚到当前出海短剧公司时，团队前任技术负责人推过一套基于GE的DQC平台。结果团队成员大部分是阿里云背景的SQL Boy/Girl，Python脚本无人维护，规则越来越脏，半年后基本没人用。我做了次重大决策：把所有规则迁移到DataWorks DQC原生方案。

迁移过程中踩了几个坑：1）GE里的复杂Expectation（比如基于历史分布的）DataWorks不支持，得改写成自定义SQL；2）GE的报告页面是HTML，DataWorks是表格，老用户一开始不适应；3）规则数量从180条精简到95条——很多GE自动生成的规则其实是噪声。最终结果：值班同学告警量降低60%，规则维护成本降到原来的1/4。

教训：工具选型不是「哪个最先进」，而是「哪个团队能hold住」。匹配团队技术栈和能力的工具，永远比技术上最强的工具更可持续。

总结

三大DQC工具：GE灵活、Deequ性能强、DataWorks零成本集成。选型核心看技术栈、团队能力、数据规模。面试时给出选型决策树，再结合一个真实的迁移/选型故事，远比单纯介绍工具特性来得有说服力。

下一篇聊一个看似简单实则高频翻车的题：主键唯一性，光靠PRIMARY KEY真的够吗？ETL链路里去重的5种姿势全梳理一遍。

你们团队用的什么DQC工具？吐槽和好评都欢迎，评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长