3. 数据质量平台架构设计
数据质量平台怎么搭？说白了，就是解决三个问题：怎么发现问题、怎么通知人、怎么修数据。我这些年看过不少团队，上来就搞高大上的架构，结果跑半年就废了。原因很简单——没想清楚核心链路。
今天我就把平台的整体架构、核心模块，以及几个主流工具的选择逻辑，掰开了讲清楚。
3.1 平台整体架构
先看一张我常用的架构图。这张图在我好几个项目里都验证过，结构清晰，扩展性也好。
这个架构分四层。最下面是数据源层，上面是质量评估层，再往上是核心模块层，最顶层是存储与展示层。每一层只干自己的事，互不干扰。
我习惯把质量评估层单独拎出来。为什么？因为规则引擎和计算引擎经常要换。比如早期用 Griffin，后来发现 Great Expectations 的 profiling 更好用，直接替换评估层就行，上层不用动。
3.2 核心模块详解
3.2.1 监控模块
监控模块是平台的「眼睛」。它负责定期扫描数据，检查是否符合预设规则。
监控分两种模式：
- 离线监控：跑批任务，每天凌晨算一次。适合大表、全量数据。
- 实时监控：流式处理，数据一进来就检查。适合实时数仓、风控场景。
监控规则怎么定？我一般分三类：
| 规则类型 | 检查内容 | 示例 |
|---|---|---|
| 完整性 | 字段是否为空 | user_id 空值率 < 1% |
| 准确性 | 数据是否符合业务逻辑 | 订单金额 > 0 |
| 一致性 | 跨表数据是否匹配 | 订单表金额 = 支付表金额 |
3.2.2 告警模块
发现问题不通知，等于白干。告警模块就是平台的「嘴巴」。
告警级别我分三级：
- P0（严重）：核心表数据丢失、主键重复。立刻电话+短信+钉钉。
- P1（警告）：字段空值率超标、数据延迟。发邮件+群消息。
- P2（提示）：轻微波动、趋势异常。只记录日志，日报里体现。
这里有个坑——告警风暴。我曾经遇到过一次，某个字段规则写错了，结果一晚上发了 2 万条告警。第二天运维直接把我拉黑了。后来我加了两个机制：
- 告警聚合：相同规则、相同表的告警，5 分钟内只发一条。
- 静默期：同一个问题告警后，1 小时内不再重复发。
3.2.3 修复模块
修复模块是平台的「手」。发现问题后，能不能自动修？
修复策略分三种：
- 自动修复：比如空值填充默认值、格式转换。适合确定性规则。
- 半自动修复：系统给出修复建议，人工确认后再执行。
- 手动修复：只记录问题，生成工单，由数据工程师处理。
3.2.4 报告模块
报告模块是平台的「脸」。数据质量好不好，得让业务看得见。
我一般输出三类报告：
- 日报：当天质量评分、异常数量、修复率。给数据团队看。
- 周报：趋势分析、Top 问题表、改进建议。给技术负责人看。
- 月报：整体质量健康度、SLA 达成率、成本分析。给管理层看。
报告里我最看重趋势图。单看一天的数据没意义，连续看一个月，才能发现质量是在变好还是变差。
3.3 技术选型
工具选型是个头疼事。我对比过三个主流方案，各有优劣。
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Apache Griffin | 大数据生态（Spark/Hive） | 原生支持 Spark，扩展性好 | 社区活跃度下降，文档少 |
| Great Expectations | Python 生态、数据科学团队 | 易用性好，Profiling 强 | 大数据量性能一般 |
| Deequ | Spark 数据管道 | 轻量级，与 Spark 无缝集成 | 功能相对单一 |
我个人的选型建议：
- 如果你的数仓是 Hive + Spark，团队有 Java/Scala 能力，选 Griffin。虽然社区冷了点，但核心功能够用。
- 如果你的团队是 Python 为主，数据量在 TB 级以下，选 Great Expectations。它的 profiling 功能是我用过最好的。
- 如果你只需要在 Spark 管道里做简单校验，不想引入太重的东西，选 Deequ。几行代码就能跑起来。
我的实际选择：在最近一个项目中，我用了「Great Expectations + Deequ」的组合。Great Expectations 做离线 profiling 和报告，Deequ 做 Spark 管道里的实时校验。两个工具互补，效果不错。
3.4 架构设计要点总结
最后，我把架构设计的关键点列一下：
- 分层设计：评估层和核心模块层解耦，方便工具替换。
- 规则可配置：规则不能写死在代码里，要支持动态配置。
- 告警防风暴：聚合+静默期，别让告警变成噪音。
- 修复分等级：自动、半自动、手动，按场景选。
- 报告看趋势：单点数据没意义，趋势才能反映质量变化。