想象你经营一家连锁餐厅「美味阁」，每天从供应商那里进购成百上千箱食材——这些食材就是你的数据。如果混入发霉的蔬菜、过期的冻肉，后厨再努力也会做出砸招牌的菜。所以你需要一套食材质量监控体系：先写出明确的收货标准（哪些菜必须新鲜、哪些肉必须在保质期内），再安排质检员快速抽查大批货，最后在总部挂一块大屏，把所有门店的食材损耗、退换记录汇总成报警信号。有了这套体系，问题食材还没下锅就会被拦住，餐厅口碑稳了，顾客也放心了。 在 AI 和大数据的世界里，这套逻辑完全成立。数据科学家每天面对百万行数据，却常被“空值、越界、口径不一”折磨。本文要讲的正是数据质量监控的三件法宝：Great Expectations（GE） 像一个写满验收标准的“菜谱本”；Deequ 像拿着大锅快速翻查入库食材的“巡店质检团”；Apache Griffin 则像高高在上的“总部食安指挥中心”。读完这篇，你会明白它们各自擅长什么、如何组合成一层层规则体系，并从“发现异常”到“复盘改进”形成完整的告警闭环。

岗位关联

学习数据质量监控，能让 AI 从业者从“模型调参师”升级为“数据守门人”——提前拦截脏数据，大幅降低模型踩坑与业务事故的概率，这在大厂数据团队是稀缺的核心能力。

目录
  1. 可视化演示
  2. 质量监控初识
  3. GE规则定义
  4. Deequ分析校验
  5. Griffin平台架构
  6. 三者对比选型
  7. 多层规则体系
  8. 告警闭环流程
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示GE/Deequ/Griffin三大框架对比、多层规则体系告警闭环、以及AI数据质量管道全链路检查，切换模式查看不同环节。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三大数据质量框架对比 GE: 200+内置Expectation，声明式规则，Data Docs可视化 Deequ: 基于Spark分布式检测，适合TB级数据 Griffin: 端到端平台，含Service/Measure/UI/Storage 选择依据 = 数据规模 × 生态匹配 × 运维成本 三大框架各有侧重，根据数据规模和团队能力选择。

质量监控初识

回到「美味阁」，主厨老王最怕什么？不是客人多，而是供应商送来的西兰花看着绿油油，切开才发现里面全是虫眼。数据世界同理：数据质量就是数据满足业务使用要求的程度——新鲜、完整、口径一致，如同蔬菜要饱满、无虫、按重量计价。坏数据有几个典型来源：采集端埋点漏传（食材掉了包）、ETL 转换出错（切菜切坏了）、多源口径不一致（明明是一斤菜却按两斤记账），还有上游系统迁移产生的历史遗留问题。

这些“坏食材”对 AI 系统危害极大。机器学习模型讲究“垃圾进，垃圾出”，训练数据里有 5% 的异常值，就可能让模型学会奇怪的规律。数据质量监控的价值就在于：在数据进入模型和报表之前设关卡，像老王在收货区就拦截虫眼菜，不让它进冷库，更不让它上餐桌。监控出来的问题还能倒推修复上游采集链路，形成良性循环。

为了量化“食材好坏”，业界定义了多个质量维度，通常加权汇总成一个健康分：

有了这把“健康分”的尺子，接下来就需要趁手的工具来量。老王决定先请一位“标准制定官”——把收货标准写成白纸黑字的菜谱，这就是 Great Expectations。

Q=∑i=1nωisi∑i=1nωi\displaystyle Q = \frac{\sum_{i=1}^{n} \omega_i s_i}{\sum_{i=1}^{n} \omega_i}
这个公式的含义：把完整性、准确性、一致性等维度的得分 s_i 按重要程度 ω_i 加权平均，得到一个 0 到 1 之间的综合质量评分，方便业务侧一眼看出数据是否“可下锅”。
  1. 质量维度得分 s_i先对每个维度单独打分。比如完整性维度检查空值比例，90% 非空就得 0.9 分，像是给每筐蔬菜评一个新鲜度等级。
    si=合格样本数总样本数\displaystyle s_i = \frac{\text{合格样本数}}{\text{总样本数}}
  2. 权重 ω_i每个维度的重要性不同。电商订单金额的完整性权重高，用户头像的完整性权重低；就像主菜的食材要精挑，配菜松一点无妨。
    ωi∈[0,1]\displaystyle \omega_i \in [0, 1]
  3. 加权求和与归一化把每个维度得分乘权重后累加，再除以权重总和，防止权重之和不为 1 造成偏差。最终 Q 越接近 1，数据越健康。
    Q=ω1s1+ω2s2+⋯+ωnsnω1+ω2+⋯+ωn\displaystyle Q = \frac{\omega_1 s_1 + \omega_2 s_2 + \dots + \omega_n s_n}{\omega_1 + \omega_2 + \dots + \omega_n}

GE规则定义

「美味阁」的老王发现，新来的帮厨总把“盐少许”理解成一把盐，把“大火”烧成焦炭。于是他请来一位标准制定官，把每道菜的验收标准写成一本厚厚的菜谱手册。Great Expectations（GE） 正是数据世界的这本菜谱——它用声明式规则描述“数据应该长什么样”，而不是写一堆 if-else 检查代码。声明式的好处像菜谱：不关心厨师的烹饪过程，只关心出锅的菜是否符合标准。

在 GE 中，每条规则叫作一个 Expectation（期望），多个期望组成 Expectation Suite（期望套件）。例如对订单表，你可以声明“order_id 必须全局唯一”“amount 必须在 0 到 10 万之间”“status 只能取 PAID/REFUND 两个值”。GE 执行校验后会生成 JSON 格式的结果对象，包含成功/失败、通过样本数、异常样本数，还可以自动渲染出漂亮的数据文档，把“表里有多少空值、哪些列经常超范围”直观展示给团队——相当于菜谱自动附带每道菜的质检照片。

GE 还支持校验结果通知：可以接入 Slack、邮件或自定义回调，当某条规则失败时立刻通知值班的数据工程师。它定位在“规则定义与校验”环节，与计算引擎解耦，既能跑在 Pandas 上做小样本探索，也能通过 Spark 适配器做大表校验。它的通过率统计如下：

菜谱写得再漂亮，也得有人拿着大锅翻查实际货物。老王需要一个能“扫货”的队伍——于是请来了 Deequ。

PassRate=NpassNtotal\displaystyle \text{PassRate} = \frac{N_{\text{pass}}}{N_{\text{total}}}
这是 GE 校验输出的核心指标：一次校验中，符合期望的样本数 N_pass 除以总样本数 N_total。比如 1000 条订单里 998 条金额非负，通过率就是 99.8%，低于团队设定的 99.9% 阈值就会告警。
  1. 统计通过样本 N_passGE 逐行或逐列检查数据，凡是满足期望的样本计入通过数。例如检查“amount 非空”，1000 行里有 990 行通过。
    Npass=∑j=1N1{rowj 满足期望}\displaystyle N_{\text{pass}} = \sum_{j=1}^{N} \mathbb{1}\{\text{row}_j \text{ 满足期望}\}
  2. 统计总样本 N_total参与本次校验的全部样本数。GE 的校验结果中会同时记录通过数和总数。
    Ntotal=数据集的总行数\displaystyle N_{\text{total}} = \text{数据集的总行数}
  3. 计算通过率两者相除得到 0 到 1 的比例。GE 会把这个值与 expectation 中设定的阈值比较，低于阈值则校验失败，触发告警通知。
    PassRate=NpassNtotal∈[0,1]\displaystyle \text{PassRate} = \frac{N_{\text{pass}}}{N_{\text{total}}} \in [0, 1]

Deequ分析校验

老王发现，菜谱虽好，但帮厨们要一本一本翻，几百箱货验完天都黑了。他雇了一支巡店质检团队，他们推着一台高速扫描仪，一次性扫过所有入库食材，几秒就能报告“今天有 3% 的番茄超期”。Deequ 就是这支团队——它构建在 Apache Spark 之上，利用分布式计算对海量数据做全量分析，单次就能算出空值率、唯一值比例、均值、分位数等四十多种指标。它由亚马逊开源，专为“大数据质量”而生。

Deequ 最亮眼的设计是 Constraint Suggestion（约束建议器）：你只需写两行代码，它就会自动分析数据分布，推荐可能成立的约束，比如“amount 最小值是 10.5”“status 的取值集合是 {PAID, REFUND}”。这相当于质检团队先摸底扫描一遍，然后主动提出“这些标准应该是这样吧？”，省去人工倒推规则的时间。Deequ 还集成了异常检测，对时序数据自动发现指标突变，比如今天的空值率突然从 1% 飙到 20%，它会标记为异常。此外它无缝融入 Spark 测试流水线，在构建阶段就能对 DataFrames 做断言，保证清洗逻辑不把好数据洗坏。

Deequ 的分析核心是统计各种质量指标，其中完整性是最常用的一个：

巡店质检团跑得快，但每家门都单独跑一遍太费劲。老王想要一个能把所有门店数据汇总、统一指挥的总部食安中心——这正是 Apache Griffin 的定位。

Completeness=Nnon-nullNtotal\displaystyle \text{Completeness} = \frac{N_{\text{non-null}}}{N_{\text{total}}}
完整性衡量“该有的数据有没有”。N_non-null 是非空样本数，N_total 是总样本数。Deequ 在 Spark 上对这两个计数做分布式聚合，因此能秒级跑完上亿行数据。
  1. 非空计数 N_non-nullSpark 对目标列执行 count(column) 后，再执行 count(column where not null) 得到非空数量，这一步会触发分布式任务。
    Nnon-null=count({x∣x≠null})\displaystyle N_{\text{non-null}} = \text{count}(\{x \mid x \neq \text{null}\})
  2. 总量 N_total对目标列执行 count(*)，得到总行数。
    Ntotal=count(∗)\displaystyle N_{\text{total}} = \text{count}(*)
  3. 比值输出两者相除后，Deequ 的输出是一个 Analysis 对象，可序列化成 JSON 或写入指标仓库，供后续校验和告警使用。若完整性低于阈值，比如订单表的 order_id 完整性只有 0.98，就说明有脏数据混入。
    Completeness=Nnon-nullNtotal\displaystyle \text{Completeness} = \frac{N_{\text{non-null}}}{N_{\text{total}}}

Griffin平台架构

老王的事业越做越大，「美味阁」开到了 30 家分店。靠人工逐店检查已不现实，他在总部建了一个食安指挥中心：所有门店的食材数据实时汇聚到一块大屏，哪家店退货率异常、哪个供应商的货反复出问题，大屏立刻亮红灯。Apache Griffin 就是这样的端到端数据质量监控平台，它提供从数据接入、质量度量、规则执行、结果展示到告警分发的全链路能力。

Griffin 的核心优势在于多数据源支持：它能同时连接 Hive、Kafka、关系型数据库等，既支持批量离线任务，也支持流式数据实时检查。可视化看板是它的门面——管理者不必写 SQL，在网页上就能配置质量任务、查看趋势折线、下钻异常明细。告警通知支持邮件、Webhook 等，能按规则严重程度分级推送。相比 GE 和 Deequ 的“库级”定位，Griffin 更像一个完整的平台产品：有元数据管理、任务调度、权限控制，还内置了 Spark 作为计算引擎。

Griffin 里一个经典指标是准确性（Accuracy），它通过对比源表和目标表来验证数据转换有没有出错。比如订单总量源表是 10000，目标表只有 9980，准确率就是 99.8%：

读完三种工具，老王陷入了选择困难。它们是竞争关系还是互补关系？我们把它放在一张选型表上对比。

Accuracy=NcorrectNtotal\displaystyle \text{Accuracy} = \frac{N_{\text{correct}}}{N_{\text{total}}}
准确率衡量“算对的数据占比”。Griffin 将源表和目标表做 join 取交集，得到正确匹配条数 N_correct，再除以目标表总条数。若低于预设阈值，比如 99%，就会在看板上亮红灯并触发告警。
  1. 匹配正确数 N_correctGriffin 对源表和目标表按业务主键做 join，能匹配上的记录视为“正确”，相当于把总部台账和门店实收食材逐一核对。
    Ncorrect=∣source∩target∣\displaystyle N_{\text{correct}} = |\text{source} \cap \text{target}|
  2. 总量 N_total一般取目标表行数，代表“应该有多少条”。若目标表本身有缺失，准确率会明显下降。
    Ntotal=∣target∣\displaystyle N_{\text{total}} = |\text{target}|
  3. 准确率输出公式结果可视化到看板，同时写指标库。当该值连续 N 次低于阈值时，Griffin 通过插件机制发邮件或调用 Webhook 给数据负责人。
    Accuracy=NcorrectNtotal\displaystyle \text{Accuracy} = \frac{N_{\text{correct}}}{N_{\text{total}}}

三者对比选型

选工具就像给「美味阁」配后厨设备：街边小面馆买个家用灶台（GE）就够；开 50 家分店就得用中央厨房流水线（Deequ）；如果要接受食药监总局的定期巡检、输出全集团食安报告，就得有总部指挥中心（Griffin）。三者不是替代关系，而是不同体量的解决方案。

从架构对比看：GE 是一个轻量 Python 库，部署成本极低，适合单机或小团队；Deequ 是构建在 Spark 上的 Scala 库，需要 Spark 集群资源，适合数据量大、已有大数据平台的团队；Griffin 是完整的 Java/Spark 平台，自带 Web 服务、MySQL 元数据库和调度模块，运维成本最高但能力最全。从性能对比看：GE 处理百万行级别数据尚可，上亿行会吃力；Deequ 利用 Spark 分布式计算能处理数十亿行；Griffin 同样依赖 Spark，但多了平台开销，更适合作为统一监控底座。从适用场景看：GE 常用于数据管道开发期的快速验证，Deequ 常用于大规模离线 ETL 每日常规质检，Griffin 则适合企业级数据中台对多团队数据资产的统一监管。学习成本上，GE 最低、文档友好；Deequ 需要一定 Scala/Spark 基础；Griffin 需要理解整体平台概念，上手门槛最高。

做选型决策时，可以用一个简单的加权评分模型。假设你列出 m 个工具、n 个评估维度（数据规模、部署成本、功能完整度等），每个工具的最终得分是：

选定了工具，老王还发现一个关键细节：质检不能只在收货口做一道，从供应商、冷库、切配到出锅，每个环节都得有人盯。这引出多层规则体系的设计。

Stotal=∑j=1nwj×scorej\displaystyle S_{\text{total}} = \sum_{j=1}^{n} w_j \times \text{score}_j
这个公式把“选型”变成了一道算术题：先给每个维度设权重 w_j（比如数据规模权重 0.4），再给每个工具在该维度的表现打分 score_j（比如 Deequ 在数据规模上打 5 分），相加后选总分最高的工具。
  1. 评估维度 j包括数据规模、实时性要求、团队技术栈、运维成本等。每个维度相当于选型表里的一列。
    j∈{1,2,…,n}\displaystyle j \in \{1, 2, \dots, n\}
  2. 维度权重 w_j表示该维度对你公司的重要程度，所有权重相加应等于 1。预算紧张时“部署成本”权重调高。
    wj∈[0,1],∑wj=1\displaystyle w_j \in [0, 1], \quad \sum w_j = 1
  3. 维度得分 score_j对每个工具在每个维度打 1~5 分。5 分表示完全满足，1 分表示基本不满足。
    scorej∈{1,2,3,4,5}\displaystyle \text{score}_j \in \{1, 2, 3, 4, 5\}
  4. 加权汇总将各维度得分乘权重后相加，得到该工具的最终评分，用于横向比较。
    Stotal=w1score1+w2score2+⋯+wnscoren\displaystyle S_{\text{total}} = w_1 \text{score}_1 + w_2 \text{score}_2 + \dots + w_n \text{score}_n

多层规则体系

老王有个惨痛教训：他只在下锅前验一次菜，结果有次供应商送来的冻虾解冻后才发现是去年的存货，但那时菜已上桌。后来他把质检拆成了三层：供应商入仓时查农药残留、冷库存储时查温度曲线、出锅前查摆盘和克重。数据世界同样需要规则分层。一个成熟的数据平台通常分三层设规则：仓库层做字段级原子检查，如非空、唯一、外键合法性；应用层做业务口径检查，如“订单金额 = 商品金额 - 优惠金额 - 退款金额”；展示层做报表合理性检查，如“日活环比波动超过 50% 触发预警”。

分层之外，还要考虑离线与在线协作：离线批量任务（凌晨跑的 Hive ETL）用 Deequ 做大规模扫描，在线实时链路（Kafka 实时特征）用轻量规则在 Flink 里做秒级检查；GE 和 Deequ 可以共享同一套规则描述，用工具把规则导出成通用 JSON。调度执行策略上，规则要绑定数据任务的依赖关系——先跑完非空检查，再跑口径校验，避免上游数据还没准备好就产生误报。规则资产管理则要求每条规则有负责人、有阈值、有历史版本，就像餐厅的食安台账要记录每次检查的时间、批次、责任人。

分层规则体系的总体验收质量，可以用各层质量的加权组合来表示：

规则体系建好了，但老王发现最容易被忽略的是发现问题之后怎么办。报警了没人处理，等于白报。最后一块拼图就是告警闭环。

Qoverall=λ1Qlayer1+λ2Qlayer2+λ3Qlayer3\displaystyle Q_{\text{overall}} = \lambda_1 Q_{\text{layer1}} + \lambda_2 Q_{\text{layer2}} + \lambda_3 Q_{\text{layer3}}
这个公式把三层规则各自算出的质量分 Q_layer1（仓库层）、Q_layer2（应用层）、Q_layer3（展示层）按权重 λ 组合。因为仓库层出错会向下游扩散，通常给它最高的权重，比如 λ₁=0.5。
  1. 各层独立打分 Q_layer每一层按自己管辖的规则集计算通过率或质量分，比如仓库层用 Deequ 跑完整性、唯一性，算出 Q₁ = 0.99。
    Qlayer1=1m∑k=1mPassRatek\displaystyle Q_{\text{layer1}} = \frac{1}{m}\sum_{k=1}^{m} \text{PassRate}_k
  2. 权重 λ_i 设置根据影响范围分配，下游层依赖上游，所以仓库层权重最高，应用层次之，展示层最低。
    λ1≥λ2≥λ3,λ1+λ2+λ3=1\displaystyle \lambda_1 \geq \lambda_2 \geq \lambda_3, \quad \lambda_1 + \lambda_2 + \lambda_3 = 1
  3. 加权求和三层加权后得到的 Q_overall 就是平台的“数据健康总分”，可用于周会汇报和跨部门对账。
    Qoverall=0.5×0.99+0.3×0.97+0.2×0.90=0.967\displaystyle Q_{\text{overall}} = 0.5 \times 0.99 + 0.3 \times 0.97 + 0.2 \times 0.90 = 0.967

告警闭环流程

老王在总部大屏上看到一家分店亮起红灯：昨日食材损耗率从 3% 跳到 15%。他立刻打电话给店长，店长查了冷库记录，发现是供应商那批冻虾温度记录仪坏了，导致一批虾解冻变质。第二天，他要求供应商更换温度记录仪，并把损耗率纳入供应商考核。从发现异常到根因定位再到改进复检，这个循环就是告警闭环。

在数据平台中，闭环的第一步是异常检测与告警：规则引擎发现指标越界后，按严重程度分级通知——P0 级别立即打电话给值班人，P2 级别发邮件汇总。第二步是事件追踪定位：每个告警生成一个事件 ID，关联到具体的数据表、任务、规则，方便工程师去查上游任务日志和依赖血缘，像查冻虾的批次记录一样找到根因。第三步是质量复盘改进：定期的数据质量周会回顾所有告警的 Trend（趋势），将反复出现的坏数据根因列成整改清单，并把新学到的经验固化成新的规则或阈值调整。最后一步是持续优化循环：每轮闭环结束，规则库和阈值都在进化——就像老王每季度更新一次食安手册，把新供应商的验收标准补充进去。

闭环的效率可以用平均恢复时间（MTTR）来度量，它衡量从数据异常发生到完全恢复正常的耗时：

至此，从认识数据质量，到写规则（GE）、扫数据（Deequ）、看大屏（Griffin），再到分层设防、闭环告警，一套完整的数据质量监控体系已经搭建完毕。恭喜你，现在你和老王一样，都是懂得“守护数据食安”的专家了。

MTTR=tdetect+tlocate+tfix\displaystyle \text{MTTR} = t_{\text{detect}} + t_{\text{locate}} + t_{\text{fix}}
MTTR 就是“出问题到恢复好”的总时长，等于检测耗时、定位耗时、修复耗时三者之和。闭环做得好的团队能把 MTTR 从几小时压到十几分钟，意味着数据事故对业务的影响时间大幅缩短。
  1. 检测时间 t_detect从数据异常实际产生到监控系统发出告警的时间间隔。这取决于规则的调度频率——每日任务粒度是小时级，实时链路可以做到秒级。
    tdetect=talert−tanomaly\displaystyle t_{\text{detect}} = t_{\text{alert}} - t_{\text{anomaly}}
  2. 定位时间 t_locate从收到告警到定位根因的时间。依赖血缘和事件追踪系统能显著缩短这一步，像通过食品批次号反查供应商。
    tlocate=trootcause−talert\displaystyle t_{\text{locate}} = t_{\text{rootcause}} - t_{\text{alert}}
  3. 修复时间 t_fix从定位根因到数据被重新处理后恢复正常的时间。修复可能是重跑任务、修补脏数据或回滚上游变更。
    tfix=trecovered−trootcause\displaystyle t_{\text{fix}} = t_{\text{recovered}} - t_{\text{rootcause}}

AI 应用场景

场景一：数据仓库入仓前的质量闸门

阶段：数据准备与 ETL 加工阶段

解决的问题：数仓团队每天凌晨从业务库抽取数据，传统做法是人工写校验 SQL，容易漏检且维护成本高。使用 Deequ 的 Constraint Suggestion 自动生成约束，在 Spark ETL 任务末尾加一个质量断言，数据不达标任务直接失败，防止坏数据流入下游报表和模型训练。

具体案例：某电商公司每日订单表约 5000 万行，此前因金额字段偶尔混入负数导致 GMV 报表出错。接入 Deequ 后，自动校验 order_amount ∈ [0, 100000] 且非空，异常时任务阻断并发送告警至数据团队，误报率从每周 3 次降至每月不足 1 次。

场景二：ML 特征管道持续监控

阶段：特征工程与模型上线前验证

解决的问题：特征数据一旦发生分布漂移（如用户年龄字段突然大量缺失），模型线上效果会骤降。使用 Great Expectations 在特征管道中定义期望套件，每次生成训练集、测试集时自动校验，并将数据文档分享给算法团队。

具体案例：某推荐团队用 GE 对用户特征表设置“latest_login_days 非空比例 > 99%”“device_type 取值集合 = {ios, android, web}”等 12 条期望。一次上游埋点改动导致 30% 特征缺失，管道在数据写入前即被拦截，算法同学收到的不是“指标暴跌”的投诉，而是一份 GE 生成的异常报告。

场景三：企业级数据中台统一质量看板

阶段：数据治理与运维监控阶段

解决的问题：多团队、多数据源共享的数据中台需要统一的质量基线。使用 Apache Griffin 对所有核心数据资产配置质量任务，在网页看板上集中展示各团队数据资产的健康分，并按 SLA 自动发送日报给各业务方。

具体案例：某大型集团部署 Griffin 后接入 200 多张核心表，每日自动执行 800 多条质量规则，覆盖 Hive 批数据和 Kafka 实时数据。某业务线的买家数指标连续三天偏低，看板趋势图触发 P1 告警，值班工程师沿血缘追踪定位到上游埋点日志丢失，2 小时内修复异常并重放数据。

Python 演示

python96 行
# -*- coding: utf-8 -*-"""模拟一个基于规则的轻量级数据质量检查器灵感来自 Great Expectations 的声明式规则设计"""import pandas as pdimport numpy as np  class ColumnChecker:    """针对单个字段的质检规则"""     def __init__(self, column, rules):        self.column = column        self.rules = rules     def validate(self, df):        """逐条执行规则，返回每条规则的通过情况"""        results = {}        for name, func in self.rules.items():            results[name] = bool(func(df))        return results  def check_not_null(df, col):    return df[col].notna().all()  def check_in_range(df, col, low, high):    return df[col].between(low, high).all()  def check_unique(df, col):    return df[col].is_unique  def build_suite(df_meta):    """根据字段元信息生成检查套件（类似 GE 的 expectation_suite）"""    suite = {}    for meta in df_meta:        col = meta["name"]        rules = {}        if meta.get("required"):            rules["not_null"] = lambda d, c=col: check_not_null(d, c)        if "min" in meta and "max" in meta:            rules["range"] = lambda d, c=col, lo=meta["min"], hi=meta["max"]: check_in_range(d, c, lo, hi)        if meta.get("unique"):            rules["unique"] = lambda d, c=col: check_unique(d, c)        suite[col] = ColumnChecker(col, rules)    return suite  def run_quality_report(df, suite):    """执行全部规则，汇总生成质量报告"""    total = 0    passed = 0    report = {"data_asset": df.shape, "rule_results": []}    for col, checker in suite.items():        result = checker.validate(df)        report["rule_results"].append({"column": col, "result": result})        for name, ok in result.items():            total += 1            passed += 1 if ok else 0    report["pass_rate"] = passed / total if total else 1.0    return report  def main():    # 模拟一段销售流水数据，包含少量脏数据    np.random.seed(42)    n = 1000    sales = pd.DataFrame({        "order_id": range(n),        "amount": np.random.uniform(10, 500, n),        "status": np.random.choice(["PAID", "REFUND", "PAID"], n),    })    sales.loc[7, "amount"] = -999   # 注入异常值    sales.loc[50, "status"] = None  # 注入空值     # 声明式规则：像写菜谱一样定义期望    meta = [        {"name": "order_id", "required": True, "unique": True},        {"name": "amount", "required": True, "min": 0, "max": 1000},        {"name": "status", "required": True},    ]    suite = build_suite(meta)    report = run_quality_report(sales, suite)     # 输出质检报告    print("数据质量报告 ->")    for item in report["rule_results"]:        print("字段 {}: {}".format(item["column"], item["result"]))    print("整体通过率: {:.1%}".format(report["pass_rate"]))  if __name__ == "__main__":    main()
目的：模拟 Great Expectations 的声明式规则工作流——用元信息描述“数据应该长什么样”，然后对 DataFrame 执行多字段质检并输出通过率报告。
  1. class ColumnChecker定义一个字段质检器，把规则字典和列名绑定，类似 GE 中一个 Expectation 的载体。
  2. def validate(self, df)遍历该字段绑定的所有规则函数，逐条执行并记录布尔结果。
  3. check_not_null / check_in_range / check_unique三个基础规则函数，对应“非空、范围、唯一”三类最常用的数据质量检查。
  4. build_suite(df_meta)根据字段元信息生成检查套件，等价于 GE 中把多个 Expectation 组合成 Expectation Suite。
  5. rules["not_null"] = lambda d, c=col: ...用闭包把当前列名固化进规则函数，避免循环变量共享的问题。
  6. run_quality_report执行全部规则并汇总通过率，模拟 GE 校验后输出的 JSON 结果对象。
  7. sales.loc[7, "amount"] = -999主动注入一条 dirty data，用于验证规则是否真的能发现异常。
  8. report["pass_rate"] = passed / total计算整体通过率，低于阈值时在实际工程中可触发告警或阻断任务。

常见误区

误区“上线前把所有规则跑一遍，通过率 100% 就万事大吉了，之后不用再管。”

正解数据质量是动态的，上游埋点改动、业务规则变化、新数据源接入都可能让曾经通过的规则突然失败。数据质量监控应该像餐厅每天早晨的食材验收一样，形成日粒度甚至小时粒度的持续检查。GE 和 Deequ 也鼓励把校验嵌入 CI/CD 流水线，每次表结构或 ETL 逻辑变更都自动触发。

为何常见：初学者常把质量检查等同于软件测试的“上线前冒烟测试”，忽略了数据是持续流动的，而软件版本是相对稳定的。

误区“Great Expectations 不是也能跑 Spark 吗？那还学 Deequ 干嘛？”

正解GE 的强项是规则定义、文档生成和体验友好，Spark 适配器只是它的可选后端；Deequ 的强项是大规模分析效率和约束自动建议，它原生构建在 Spark RDD 之上，能做面向全量数据的 Profile 分析。实际组合常常是：用 GE 写语义丰富的规则，用 Deequ 处理超大批量数据的计算密集型检查，两者互补而非互斥。

为何常见：人们倾向于把工具理解成“全能替代品”，忽略了每个工具的设计发源场景——GE 发源于数据探索，Deequ 发源于 AWS 大规模数据管道质检。

误区“我把所有能想到的规则都加上去，通过率低就说明质量差。”

正解规则过多会产生大量低价值告警，团队会产生告警疲劳，真正严重的异常反而被淹没。规则设计要讲究 ROI：优先覆盖核心字段和直接影响业务指标的规则；对低频变化、低业务影响的字段设置较低优先级或仅记录不告警。多层规则体系也强调分层设防，而不是每层都堆满规则。

为何常见：初学者容易把“监控力度”等同于“规则数量”，而忽略了运维成本和告警信噪比，就像餐厅不可能对每粒米都做 DNA 检测一样。

误区“配置好邮件通知，只要规则失败会发告警，数据质量工作就算做完了。”

正解监控的终点不是告警发出，而是问题被定位、修复并验证。没有闭环的告警就是噪音。真正成熟的质量团队会将告警关联到事件管理平台，跟踪处理人、响应时间和修复动作，并在周会上复盘高频告警的根因，将改进措施固化到规则库中。MTTR 是比告警数量更重要的一线指标。

为何常见：把“发现问题”当成了目标，忽略了质量监控的根本目的是“减少问题影响”，这与餐厅的食安管理“以事故数为考核”而非“以报警次数为考核”是同一个道理。

面试题

Q1. Great Expectations 的核心设计理念是什么？

单选题 · easy

  • A.声明式定义数据期望← 正确答案
  • B.手工编写检查脚本
  • C.完全替代数仓存储
  • D.只做数据可视化

答案：A。GE 的核心理念是用声明式规则描述“数据应该长什么样”，就像写菜谱一样定义标准，而不是写 if-else 检查脚本。B 是 GE 出现之前的传统做法，C 和 D 均与数据质量校验无关。

Q2. Deequ 主要运行在哪个计算引擎之上？

单选题 · easy

  • A.Apache Spark← 正确答案
  • B.Apache Flink
  • C.MySQL 数据库
  • D.单机 Python

答案：A。Deequ 是一个构建在 Apache Spark 之上的 Scala 库，利用 Spark 的分布式计算能力处理大规模数据质量分析。Flink 主要用于流式计算，MySQL 是存储引擎，单机 Python 无法支撑 Deequ 设计的海量数据场景。

Q3. 在 GE 中，一组数据期望的集合称为什么？

单选题 · easy

  • A.Expectation Suite← 正确答案
  • B.Data Frame
  • C.SQL Query
  • D.Spark Session

答案：A。GE 中把多个 Expectation（期望）组合成一个 Expectation Suite（期望套件），类似把多道菜的验收标准装订成一本菜谱。DataFrame 是数据容器，SQL Query 是查询语句，Spark Session 是 Spark 入口，均与规则集合无关。

Q4. Apache Griffin 相比 GE/Deequ 最突出的定位优势是什么？

单选题 · mid

  • A.端到端质量监控平台← 正确答案
  • B.规则种类最丰富
  • C.完全不需要计算引擎
  • D.只能监控流式数据

答案：A。Griffin 的定位是提供数据接入、质量度量、规则执行、可视化看板、告警分发等完整能力的端到端平台，而 GE 和 Deequ 更偏向库级工具。Griffin 依赖 Spark 计算引擎（C 错），既支持批数据也支持流数据（D 错），规则种类并非它最突出的优势。

Q5. 数据完整性指标主要关注什么问题？

单选题 · mid

  • A.字段是否存在空值缺失← 正确答案
  • B.数据量是否足够庞大
  • C.数据存储是否安全加密
  • D.数据颜色样式是否统一

答案：A。完整性衡量的是“该有的数据有没有”，核心检查对象是空值、缺失值比例，对应公式 Completeness = 非空数 / 总数。B 是规模问题，C 是安全权限问题，D 是展示格式问题，均不属于完整性维度。

Q6. 在做 GE/Deequ/Griffin 选型时，最核心的考量因素是什么？

单选题 · mid

  • A.数据规模与团队技术栈← 正确答案
  • B.网页界面是否美观
  • C.工具名称是否好听
  • D.是否来自大厂出品

答案：A。选型的核心是匹配自身场景：数据量小、团队偏 Python 选 GE；已有 Spark 集群、日均处理上亿行数据选 Deequ；多团队、多数据源需要统一监管平台选 Griffin。界面美观、名称、出品方都不是选型的决策依据。

Q7. 某条质量规则的通过率连续 5 天从 99% 缓慢降到 97%，但业务逻辑并未变化，最可能的原因是什么？

单选题 · hard

  • A.上游数据源质量在恶化← 正确答案
  • B.规则阈值设置有问题
  • C.监控看板渲染出错
  • D.模型预测精度下降

答案：A。业务逻辑未变而通过率持续缓慢下降，通常是上游数据源的质量变化导致，比如埋点开始丢失、供应商数据字段格式漂移。阈值设置问题会导致通过率从第一天就异常，看板渲染错误不会影响实际指标，模型精度与规则通过率无直接因果关系。

Q8. 一个完整的告警闭环流程包含以下哪些环节？

多选题 · mid

  • A.规则校验发现异常← 正确答案
  • B.告警通知值班人员← 正确答案
  • C.事件追踪定位根因← 正确答案
  • D.清理掉所有历史数据

答案：ABC。告警闭环 = 发现（规则校验触发）→ 通知（分级告警）→ 定位（事件追踪与血缘分析）→ 修复 → 复盘。D 不是闭环环节，盲目清理历史数据会丢失排查证据，正确做法是先定位根因再决定是否修复重放。

Q9. 构建多层数据质量规则体系时，需要综合考虑哪些方面？

多选题 · hard

  • A.按仓库层、应用层、展示层分层设规则← 正确答案
  • B.离线批量与在线实时规则协作互补← 正确答案
  • C.为每条规则配置负责人和调度策略← 正确答案
  • D.规则数量越多越好不必管理

答案：ABC。多层体系的核心设计思路是分层覆盖（A）、离线在线配合（B）、规则资产化管理（C）。D 恰恰相反，规则过多会造成告警疲劳，应强调规则的精简、分级和资产维护，而非盲目堆量。

Q10. 关于 Griffin 平台架构，以下描述正确的是哪些？

多选题 · extreme

  • A.支持 Hive、Kafka 等多数据源接入← 正确答案
  • B.提供可视化看板与分级告警能力← 正确答案
  • C.内部依赖 Spark 作为计算引擎← 正确答案
  • D.只能用于离线批处理场景

答案：ABC。Griffin 典型架构支持 Hive、Kafka、关系型库等多源接入（A 对），自带 Dashboard 看板和通知告警模块（B 对），计算层基于 Spark（C 对）。它同时支持批处理与流式数据质量监控，并非只能用于离线场景（D 错）。