解读

在国内金融、电商、物流等实时数仓或微服务解耦场景里，面试官真正想确认的是：你是否理解 Cloud SQL 的 CDC 链路（通常借助 Pub/Sub + Datastream 或 Debezium Connector）在“表级”粒度上的性能与成本权衡。事件过滤不是简单的 WHERE 条件，而是 在日志解析阶段就丢弃无关事件，避免下游订阅方收到冗余消息，从而节省 跨域网络流量、Pub/Sub 费用、Flink 计算资源，并降低 消费端 Rebalance 延迟。一句话：把“只同步必要业务表”这件事做在源头，而不是做在下游。

知识点

1. MySQL binlog_row_image = FULL|MINIMAL|NOBLOB 对过滤效率的影响
2. PostgreSQL logical replication slot + pgoutput plugin 的表级发布（PUBLICATION FOR TABLE）
3. Cloud SQL Auth Proxy 与 Private IP 在 CDC 链路的 SSL 强制传输 角色，过滤可减少加密开销
4. Pub/Sub 消息计费模型：每 64 KB 按一条计费，过滤大字段可直接降本
5. Exactly-once 语义：过滤必须在 解析线程内完成，否则重复消费时无法幂等
6. 国内合规：个人信息去标识化（《个人信息保护法》）可在过滤阶段做 列级脱敏，避免敏感字段出云

答案

事件过滤在特定表 CDC 中的核心作用是 在日志解析层仅保留目标表及相关列的变更事件，从源头减少 70% 以上的无效流量。具体收益：

1. 成本：按量计费的 Pub/Sub 消息数与跨可用区出流量费直接下降；
2. 性能：Flink/Spark 作业消费线程数减少，降低 CPU 与 Checkpoint 耗时；
3. 稳定性：避免大表全字段更新触发 Cloud SQL 只读实例延迟飙高；
4. 合规：可在过滤规则里内置 列级掩码，确保手机号、身份证等敏感数据不出云，满足国内等保与《个人信息保护法》要求。
   实现方式：MySQL 场景下，在 Datastream 配置“表包含列表”+列排除列表；PostgreSQL 场景下，使用 CREATE PUBLICATION pub_order FOR TABLE orders, order_items WITH (publish = 'insert, update')，并在 Debezium JSON 里开启 table.include.list。过滤动作必须在 解析线程完成，以保证 offset 连续且支持断点续传。

拓展思考

如果面试官继续追问“过滤会不会导致 binlog 位点空洞”，可回答：

• Cloud SQL 的 binlog 保留期最长 7 天，过滤规则变更后需要 重建 slot 或重启 Datastream 任务，此时必须先用 gcloud sql export 做一致性快照，再用 Datastream 的 backfill 模式重拉历史数据，防止 GTID 跳号造成下游幂等失效。
• 若业务表存在 外键级联，过滤掉父表而保留子表会导致 孤儿记录，需在过滤层 级联展开或通过 业务层补偿保证最终一致性。