一、数据质量平台概述：什么是数据质量、为什么需要数据质量平台、核心功能与架构

1.1 什么是数据质量？先别急着背定义

数据质量这个词，听起来挺高大上的。说白了，就是你的数据能不能用、好不好用。

我见过不少团队，数据量攒了几个T，报表也跑得飞起。结果业务方一问「这个数准不准？」没人敢拍胸脯。这就是数据质量没跟上。

数据质量通常从六个维度来衡量，业内叫「数据质量六性」：

维度	通俗解释	我踩过的坑
完整性	该有的字段有没有？有没有空值？	曾经有个订单表，用户手机号空了30%，营销活动直接废了
准确性	数据跟真实世界一致吗？	汇率表少刷了一次，当天财报差了200万
一致性	不同系统之间对得上吗？	CRM和ERP的客户ID编码规则不一样，一合并就乱
及时性	数据产出够快吗？	实时大屏延迟了10分钟，运营以为活动没效果
唯一性	有没有重复记录？	用户表里同一个身份证号出现了3次
有效性	数据格式、取值范围合规吗？	年龄字段出现了-5，明显是前端没做校验

你想想看，如果这六个维度随便哪个出问题，下游的分析、报表、模型全得跟着遭殃。所以数据质量不是锦上添花，是地基。

1.2 为什么需要数据质量平台？

有人会问：「我写几个SQL脚本定时跑一下，不也能发现问题吗？」

嗯，我刚开始也是这么干的。写了几十个脚本，每天手动看结果。后来数据源从3个涨到30个，脚本数量翻了两倍，维护成本直接爆炸。而且脚本之间没有统一标准，张三写的规则和李四写的规则，跑出来的结果完全没法对比。

这时候你就需要一个数据质量平台。它解决的核心问题就三个：

• 统一管理：所有质量规则、监控任务、告警策略，一个地方搞定
• 自动化：定时扫描、自动告警、甚至自动修复
• 可观测：质量分数、趋势图、问题溯源，一眼看清数据健康度

我个人习惯把数据质量平台比作「数据管道的安检机」。数据从源头流到目标，中间经过每一道关卡，平台都能帮你扫一遍。有问题就报警，严重了就拦截，别让脏数据流到业务系统里。

1.3 核心功能拆解

一个成熟的数据质量平台，通常包含以下五大模块。我按实际落地顺序来讲：

1. 规则引擎：定义「什么是好的数据」。支持SQL模板、自定义脚本、机器学习异常检测。
2. 任务调度：什么时候跑、跑哪些表、跑完怎么处理。支持定时、事件触发、上下游依赖。
3. 监控告警：发现问题后通知谁、怎么通知。短信、邮件、钉钉、企微，一个都不能少。
4. 质量度量：给数据打分。按表、按字段、按规则维度，生成质量报告。
5. 问题治理：发现问题后的闭环。自动修复、人工介入、回滚、重跑。

我曾经在一个金融项目中，规则引擎里配了2000多条规则。刚开始觉得太多了，后来发现每条规则背后都对应着一个真实的事故。所以别嫌多，规则就是经验。

1.4 平台架构长什么样？

下面这张图是我自己画的一个简化版架构。不复杂，但核心链路都在里面了。

这个架构图我简化了，但核心链路很清楚：数据从源头进来，经过规则校验、调度执行、结果处理，最后展示在仪表盘上。每一层都可以横向扩展，这也是为什么平台能支撑几百张表的校验。

1.5 一个简单的规则示例

光说不练假把式。我们来看一条最基础的非空校验规则，用SQL怎么写：

-- 检查订单表的 user_phone 字段是否为空
SELECT
  COUNT(*) AS total_rows,
  SUM(CASE WHEN user_phone IS NULL OR user_phone = '' THEN 1 ELSE 0 END) AS null_count,
  ROUND(
    SUM(CASE WHEN user_phone IS NULL OR user_phone = '' THEN 1 ELSE 0 END) * 100.0 / COUNT(*),
    2
  ) AS null_rate
FROM ods_order
WHERE dt = '2025-01-15';

这条SQL跑完，如果 null_rate > 5%，平台就会触发告警。我曾经就因为这条规则，在凌晨2点接到电话，说订单表手机号空值率飙到了40%。一查，是上游接口改了字段映射，没通知我们。如果没有这条规则，第二天业务方打电话投诉的就是我了。

1.6 避坑指南

1.7 本章小结

数据质量不是某个人的事，是整个数据团队的共同责任。平台只是工具，真正起作用的，是你对数据的敬畏心。