📚 课程目录第4章实时数据接入层监控

4. 实时数据接入层监控：Canal/Debezium CDC监控、数据格式校验、Schema变更监控、接入吞吐量监控

实时数仓的第一道关卡，就是数据接入层。

说白了，数据从业务库流出来，经过 CDC（Change Data Capture）工具，进入消息队列。这个环节要是出了问题，下游的实时计算、OLAP 查询全得跟着遭殃。我在项目中见过太多次了——接入层崩了，整个链路的数据质量直接归零。

所以这一章，我们重点聊聊接入层的四个监控维度：CDC 工具本身的状态、数据格式对不对、Schema 变了没有、吞吐量扛不扛得住。

4.1 CDC 工具监控：Canal 与 Debezium

CDC 工具是实时数仓的“眼睛”。它盯着业务数据库的 binlog，一有变化就往外推。目前主流的两套方案，就是阿里开源的 Canal 和 Red Hat 开源的 Debezium。

核心监控指标

延迟（Lag）：从 binlog 产生到被 Canal/Debezium 消费的时间差。单位毫秒。
心跳检测：每隔 N 秒发一条心跳记录，确保连接没断。
连接状态：与 MySQL/PostgreSQL 的 TCP 连接是否正常。
解析错误率：binlog 解析失败的次数 / 总事件数。

我个人习惯，在 Canal 的 metrics 里重点盯 canal.instance.delay 这个指标。如果延迟超过 5 秒，基本可以判定是网络抖动或者数据库压力过大。Debezium 的话，我建议关注 kafka.connect.mirror.connector.running 和 source.task.delay.ms。

避坑指南

我曾经遇到过一个坑：Canal 的 HA 模式切换时，ZooKeeper 的 session 超时导致两个节点同时认为自己是 master，结果数据重复推送。后来我在监控里加了一条规则——当 Canal 的 running 状态在 30 秒内切换超过 3 次，立刻告警。

4.2 数据格式校验：JSON / Avro / Protobuf

CDC 工具把 binlog 事件转成统一格式。常见的有 JSON、Avro、Protobuf。格式不对，下游解析直接报错。

你想想看，一个订单表有 50 个字段，突然某天 DBA 加了一个 decimal(20,4) 类型的字段，但 CDC 配置里没更新序列化器，结果这个字段被转成了字符串。下游的聚合计算全乱套了。

所以，格式校验必须做。我一般分三层：

语法校验：JSON 是否合法、Avro schema 是否匹配。
字段类型校验：比如 price 字段必须是数字，不能是字符串。
值域校验：比如 order_status 只能是 0、1、2，不能出现 3。

注意

不要只依赖 CDC 工具自带的格式校验。我建议在接入层单独部署一个校验服务，消费 Kafka 消息，逐条校验。校验失败的消息，打入死信队列（DLQ），并触发告警。

下面是一个简单的 JSON 校验示例（伪代码）：

// 伪代码：JSON 格式校验
function validateCDCJson(event) {
    // 1. 语法校验
    if (!isValidJSON(event)) {
        sendToDLQ(event, "INVALID_JSON");
        return false;
    }
    // 2. 字段类型校验
    if (typeof event.payload.price !== "number") {
        sendToDLQ(event, "TYPE_MISMATCH");
        return false;
    }
    // 3. 值域校验
    if (![0, 1, 2].includes(event.payload.order_status)) {
        sendToDLQ(event, "VALUE_OUT_OF_RANGE");
        return false;
    }
    return true;
}

4.3 Schema 变更监控：兼容性检查

这是接入层最容易被忽视的监控点。

业务库的 Schema 不是一成不变的。加字段、删字段、改类型，都是家常便饭。但实时数仓的 Schema 是提前定义好的。两边不一致，数据要么丢失，要么解析失败。

我建议做两件事：

自动检测 Schema 变更：Canal 和 Debezium 都支持监听 DDL 语句。一旦检测到 ALTER TABLE，立刻触发告警。
兼容性检查：新 Schema 是否向后兼容？比如，删了一个下游正在使用的字段，这就是不兼容变更。

兼容性规则（参考）

变更类型	是否兼容	处理建议
新增字段（nullable）	兼容	下游自动填充 null
新增字段（not null）	不兼容	需下游同步更新 Schema
删除字段	不兼容	立即告警，暂停消费
修改字段类型	视情况	检查类型转换是否安全

嗯，这里要注意。Schema 变更监控不能只靠人工。我曾经在一个项目里，DBA 凌晨两点改了表结构，第二天早上才发现实时报表全挂了。后来我写了一个自动化脚本，检测到 DDL 后自动比对 Schema Registry 里的版本，不兼容就直接阻断数据流。

4.4 接入吞吐量监控：流量与压力

吞吐量监控，说白了就是看你的管道能扛多大流量。

核心指标有三个：

每秒事件数（EPS）：Canal/Debezium 每秒推送的消息条数。
每秒字节数（BPS）：原始数据量大小。
Kafka 分区水位：每个分区的消息积压量。

我一般会设置两个阈值：

软阈值：EPS 达到峰值的 70%，触发预警，提醒扩容。
硬阈值：EPS 达到峰值的 90%，触发告警，自动扩容 Kafka 分区或增加 Canal 实例。

实战经验

我记得有一次双十一大促，订单表的 EPS 从平时的 2000 飙到了 15000。Canal 的客户端直接 OOM 了。后来我做了两件事：一是给 Canal 配置了限流（canal.instance.flowControl），二是把 Kafka 的分区数从 6 扩到了 24。从那以后，我再也没遇到过接入层因为流量暴涨而崩溃的情况。

4.5 知识体系总览

下面这张图，把接入层监控的四个维度串起来了。你可以把它当作一个检查清单。

4.6 小结

接入层监控，是实时数仓数据质量的第一道防线。CDC 工具的状态、数据格式的正确性、Schema 的兼容性、吞吐量的稳定性，这四个点盯住了，下游的实时计算和 OLAP 查询才能放心。

我个人习惯，把这四个维度的监控指标统一上报到 Prometheus，然后在 Grafana 上建一个“接入层健康大盘”。每天上班第一件事，就是扫一眼这个大盘。如果全是绿的，今天大概率是个好日子。