从手动检查到自动监控：一个数据质量工作流的实现

做数据工程的人大概都有过这样的经历：每天到工位第一件事，打开终端敲几条 SQL，看看关键表的行数是不是正常、最新数据更新到几点了、字段空值有没有突然飙高。

这套检查做完，可能半个小时就过去了。

如果某天查出来有问题，还得翻日志、查上下游、挨个通知相关的人。

这些任务虽然不复杂，但琐碎且需每天重复。

时间久了，你可能会想：能不能写个脚本能自动运行这些检查？

本文就来介绍如何用 Python 将日常数据质量检查从手工操作转变为自动化流程。

无需复杂框架，核心代码仅三个 Python 文件，分别对应三个工作流，共同实现数据质量监控、任务调度和报表生成这三项常见重复工作的自动化。

1. 那些看起来很简单的事

先说说为什么这些"简单"的检查做起来并不简单。

1.1. 数据验证：不是看看类型就行了

很多人觉得数据验证就是检查一下字段类型对不对、有没有空值。但真正跑过数据的人知道，麻烦的从来不是这些。

你还得关心这周的数据分布是不是跟上周差不多、有没有突然少了一半的记录、业务规则有没有被违反------比如订单金额出现了负数。

这些情况光靠肉眼查 SQL 结果很难发现，等问题暴露到下游报表里再去排查，往往已经晚了。

1.2. 管道监控：成功不等于正确

一个 ETL 任务显示绿色对勾，不代表输出就一定没问题。

可能数据是跑完了，但写到目标表的行数比平时少了一截；也可能是上游数据延迟到达，任务按时启动了但拿到的是昨天的数据。

反过来，任务报错了也不一定就是天塌了------有的错误是网络超时，重试一下就好；有的是数据本身的问题，重试也没用。

如果不区分这些情况，要么被海量告警淹没，要么漏掉真正需要处理的故障。

1.3. 报表生成：每个需求都不太一样

报表这事烦就烦在，每次来的需求看着差不多，但总有细微差别。

"上次那个报表再跑一下，换成上周的"、"能不能按区域分一下"、"把上个月的数据也加上做个对比"。

手工改 SQL、改格式、跑完截图发邮件，每个步骤都不复杂，但串起来就很耗时，而且容易出错。

这些任务单独看都不难，但每天重复做就是实质性的时间消耗。

下面我们就看看怎么一步步把它们自动化。

2. 工作流一：自动化数据质量监控

第一个要做的事情，是把每天手动跑的那些数据质量检查写成脚本，让它自己跑。

思路很简单：把"检查什么"和"怎么检查"拆开。

检查什么（哪张表、什么指标、阈值是多少）用配置来定义，

怎么检查（具体的 SQL 逻辑和判断方式）写成代码。

这样一来，每次新增检查项只需要加一条配置，不用改代码。

代码里用 QualityRule 这个数据类来定义每条规则：

@dataclass
class QualityRule:
    table: str
    rule_type: str  # volume, freshness, completeness
    column: str = None
    threshold: float = None
    min_rows: int = None
    max_hours: int = None

rule_type 目前支持三种检查：volume（数据量）、freshness（数据新鲜度）、completeness（完整性）。

每条规则绑定到一张具体的表，加上对应的阈值参数。

DataQualityMonitor 类的实现也很直观。核心方法是 run_daily_checks，它会遍历所有规则，根据规则类型调用对应的检查方法：

• volume 检查 ：SELECT COUNT(*) FROM table，判断行数是否达到最低要求
• freshness 检查 ：SELECT MAX(timestamp_column) FROM table，计算数据最新时间跟当前时间的差值
• completeness 检查：计算指定列的非空比例，判断是否满足阈值

每条检查的结果用 QualityResult 返回，包含是否通过、实际值和描述信息。检查失败的结果会被收集到 failed_checks 列表里，方便后续做告警处理。

使用起来大概是这样：

rules = [
    {"table": "users", "rule_type": "volume", "min_rows": 1000},
    {"table": "events", "rule_type": "freshness", "column": "created_at", "max_hours": 2},
    {"table": "users", "rule_type": "completeness", "column": "email", "threshold": 0.8}
]

monitor = DataQualityMonitor('database.db', rules)
results = monitor.run_daily_checks()

传进去的是一个规则列表和一个数据库路径，一行调用就把所有检查跑完了。

加上定时任务（cron 或者 Windows 任务计划），就能实现每天自动跑查检、自动生成报告。

3. 工作流二：管道编排与智能重试

数据质量检查自动化之后，下一个要解决的是管道调度的问题。

如果你的数据流程是"抽取 → 清洗 → 加载"这种串行的，手工跑的话得一步一步盯，上一步跑完了再手动触发下一步。

SmartOrchestrator 干的事情就是把管道之间的依赖关系管起来，让它们按顺序自动执行。你只需要注册每个管道和它的前置依赖：

orchestrator = SmartOrchestrator()

orchestrator.register_pipeline("extract", extract_data_func)
orchestrator.register_pipeline("transform", transform_func, dependencies=["extract"])
orchestrator.register_pipeline("load", load_func, dependencies=["transform"])

注册完之后，调度 extract 就会自动沿着依赖链把 transform 和 load 也跑起来。

prerequisites_satisfied 方法会检查前置管道是否已经执行成功，没成功的话不会启动下游任务。

这个编排器还有一个比较实用的功能：智能重试。

管道失败的原因多种多样，不同原因的处理策略不应该一样。

代码里用 classify_failure 方法把错误分成两类：

• transient（瞬时错误）：网络超时、连接中断这类，重试大概率能解决，直接安排重试
• data_quality（数据质量问题）：数据本身有问题，盲目重试没用，最多试一次让上游刷新一下数据

def should_retry(self, execution: Execution) -> bool:
    pipeline = self.pipelines[execution.pipeline_name]
    if execution.retry_count >= pipeline.max_retries:
        return False
    failure_type = self.classify_failure(execution.error or "")
    if failure_type == 'transient':
        return True
    elif failure_type == 'data_quality' and execution.retry_count < 1:
        return True
    return False

这种分类重试的好处是避免无意义的重复执行，也不会因为瞬时的网络波动就直接宣告失败去骚扰人。

执行记录会写入 SQLite 数据库，方便事后复盘管道的运行情况。

4. 工作流三：自动报表生成

前两个工作流解决了"数据对不对"和"流程跑没跑"的问题，第三个工作流来解决"报表怎么做"。

报表需求最大的特点就是：每次都差不多，但每次都不完全一样。

如果能用自然语言描述需求，然后自动生成对应的查询和报表，就能省掉来回改 SQL 和调格式的时间。

AutoReportGenerator 的处理流程分为四步：解析意图 → 匹配模板 → 构建查询 → 格式化输出。

意图解析由 NaturalLanguageProcessor 完成，它用正则匹配从自然语言中提取关键信息：查什么指标（sales、users、engagement）、按什么维度拆分（region、month、day）、时间范围（last week、yesterday 等）。

比如输入 "Show me sales by region for last week"，解析出来的结构化意图就是指标=sales、维度=region、时间=last_week。

模板匹配会根据指标类型找到预设的 SQL 模板，再由 QueryOptimizer 把时间过滤和分组逻辑填进去，生成最终的查询语句。查出来的数据会被格式化成包含汇总统计的报表结构。

另外还有一个 ReportCache 做查询缓存------同样的查询在缓存有效期内不会重复执行，对于变化不频繁的数据这个优化能减少不少数据库压力。

用起来很简单：

generator = AutoReportGenerator('data.db')

result = generator.handle_request("Show me sales by region for last week")

传入一句话，返回完整的报表结果。

5. 实战：用工作流监控一份数据日报

下面用一个贴近实际的场景把它们串起来走一遍，看看这套东西到底怎么用。

假设你在一家电商平台做数据相关的工作，每天早上要看三张核心表的数据：orders（订单表）、users（用户表）和 events（事件表）。

运营和产品那边每天早会的更新数据就靠这三张表。

你每天到了公司第一件事就是打开数据库，看看今天的数据到了没、量正不正常、空值有没有突然变多。

我们用这套工作流把这件事自动化。

5.1. 第一步：定义质量规则，把你的检查经验写成配置

你平时手工查的东西其实是有规律的，只是每次都在脑子里过了一遍。现在把这些规律写出来：

rules = [
    # 订单表：每天至少有 500 条新订单
    {"table": "orders", "rule_type": "volume", "min_rows": 500},
    # 订单表：最新数据不超过 3 小时
    {"table": "orders", "rule_type": "freshness", "column": "created_at", "max_hours": 3},
    # 用户表：邮箱字段填充率不低于 90%
    {"table": "users", "rule_type": "completeness", "column": "email", "threshold": 0.9},
    # 事件表：最新事件不超过 2 小时
    {"table": "events", "rule_type": "freshness", "column": "event_time", "max_hours": 2},
]

你看，这不就是你每天早上脑子里想的那几件事吗？"订单量不能太少""数据得是新""邮箱不能大面积缺失"------只不过现在写成配置了，机器能读懂。

5.2. 第二步：跑起来，让脚本替你检查

monitor = DataQualityMonitor('ecommerce.db', rules)
results = monitor.run_daily_checks()

这一行跑完，所有检查的结果都有了。results 里面有每条规则是否通过、实际值是多少、以及一段可读的描述信息。

脚本还会自动生成一份文本格式的质量报告，长这样：

==================================================
【第二步】运行数据质量监控
==================================================
检查结果: 1/4 条通过

未通过的检查:
  ✗ Data age: 8.0h (max: 3h)
  ✗ Completeness: 81.0% (min: 90.0%)
  ✗ Data age: 8.0h (max: 2h)

用户表的邮箱填充率掉到了 76%，没过 90% 的线。这个信息你不用自己查 SQL 就能拿到了。

5.3. 第三步：把管道编排加上，检查通过才跑下游任务

光发现问题还不够，你还需要决定下游怎么办。

质量检查通过→正常跑后面的清洗和加载；检查失败→先别急着跑，停一下等数据修复。

def daily_etl():
    monitor = DataQualityMonitor('ecommerce.db', rules)
    results = monitor.run_daily_checks()

    if monitor.failed_checks:
        # 有检查失败，不启动下游任务，发个告警
        notify_team(monitor.failed_checks)
        return

    # 全部通过，正常跑 ETL
    orchestrator.schedule_pipeline("extract")

orchestrator.register_pipeline("extract", extract_orders)
orchestrator.register_pipeline("transform", clean_and_join, dependencies=["extract"])
orchestrator.register_pipeline("load", load_to_warehouse, dependencies=["transform"])
orchestrator.start()

这样一来，你的早间数据流程就不是纯手工盯着了：质量检查自动跑→过了才启动 ETL→没过就停住告警。

你到了公司只需要看一眼通知，如果有问题再去排查，如果没问题就说明数据已经正常入仓了。

==================================================
【第三步】管道编排与智能重试
==================================================

⚠ 质量检查未全部通过，暂不启动下游 ETL 任务。
  建议排查以下问题后再重试:
    - orders 表 freshness 检查失败
    - users 表 completeness 检查失败
    - events 表 freshness 检查失败

5.4. 第四步：把常用报表自动化，减少重复取数

ETL 跑完之后，产品和运营那边通常会来要数据。

与其每次手工跑 SQL 再截图发过去，不如让他们自己查：

generator = AutoReportGenerator('ecommerce.db')

# 产品经理想知道上周各区域的销售情况
result = generator.handle_request("Show me sales by region for last week")

# 运营想看昨天的用户活跃数据
result = generator.handle_request("User engagement metrics yesterday")

如果把这个接口接上一个简单的内部页面或者聊天机器人，取数的人直接输入需求，几秒钟就能拿到结果，不需要你插手了。

==================================================
【第四步】自动报表生成
==================================================

查询请求: "Show me sales by region for last week"
... ...

  报表标题: Sales Report
  时间范围: last_week
  数据记录数: 4
  前 3 条数据预览:
    1. {'region': 'North', 'total_sales': 88903, 'order_count': 163, 'avg_order_value': 545.4171779141104}
    2. {'region': 'East', 'total_sales': 77177, 'order_count': 149, 'avg_order_value': 517.9664429530201}
    3. {'region': 'South', 'total_sales': 74265, 'order_count': 145, 'avg_order_value': 512.1724137931035}
  汇总统计:
    total_sales: 总计=312631.00, 均值=78157.75
    order_count: 总计=600.00, 均值=150.00
    avg_order_value: 总计=2081.05, 均值=520.26

... ...

  报表标题: Users Report
  时间范围: yesterday
  数据记录数: 1
  前 3 条数据预览:
    1. {'user_count': 2, 'active_users': 2}
  汇总统计:
    user_count: 总计=2.00, 均值=2.00
    active_users: 总计=2.00, 均值=2.00

==================================================
工作流执行完毕
==================================================

走到这一步，你每天早上的工作流就从"打开终端→跑 SQL→看数字→发现问题→排查→手动跑 ETL→手动出报表 "变成了"看一眼通知→有异常就处理，没异常就说明数据已经到位了"。

省下来的时间，你可以用在真正需要人思考的事情上。

6. 写在最后

这篇文章介绍的工作流，用的都是 Python 标准库加上 pandas 和 sqlite3 这样最常见的工具，没有什么部署门槛。

比起花几个月去调研和上线一套重型方案，不如先用脚本把每天最耗时的一两个任务替换掉，看看效果。

如果你每天有超过 30 分钟花在重复的数据检查上，这周就可以试试把 DataQualityMonitor 跑起来。

跑几天看看省了多少时间，有了信心再往下做管道编排和报表生成------一步步来，效果会比想象中来得快。

完整代码和使用方法：de-workflows.zip: https://url11.ctfile.com/f/45455611-17569901387470-d4e2ca?p=6872 (访问密码: 6872)