基于 Zerobus Ingest 与 Debezium 的推送式 CDC 写入 Unity Catalog
内容提要
Debezium Server 3.7 新增开源 Zerobus Ingest sink，由 NVIDIA 与 Databricks 合作贡献，可将数据库变更事件直接写入 Unity Catalog 管理的 Delta 表，无需部署 Kafka。NVIDIA 贡献的 envelope 模式以固定九列表保存完整变更事件，并提供幂等键与持久确认等投递保障；投递语义为至少一次，下游需按幂等键去重。落地后可用 AUTO CDC 按源 LSN 排序，构建当前状态表。
延伸解读
推送式架构的适用边界
文章强调该方案适合数据库位于私有网络、仅允许出站连接的环境。Debezium Server 在源侧读取 WAL 并主动向外推送，Zerobus Ingest 作为服务端接收并写入 Unity Catalog Delta 表，从而绕过 Kafka 和云对象存储暂存区。若组织已把 Kafka 作为统一事件总线，或需要 Connect 的分布式 worker、SMT 与 schema registry，传统两跳架构仍有价值。选择时应先评估网络约束与现有基础设施，而非单纯追求链路缩短。
至少一次投递与幂等键的实际含义
文章明确投递语义为至少一次：若后续记录组失败，先前已持久化的组可能被再次投递。每个事件携带由目标、分区、键、操作和源位置派生的 SHA-256 幂等键，重复投递会得到相同键，但该键本身不排序、也不自动去重。因此下游必须按幂等键显式去重，不能假设表内天然唯一。理解这一点对设计 Bronze 层和后续合并逻辑至关重要，否则重复事件可能污染当前状态表。
Envelope 模式保留的证据链
NVIDIA 贡献的 envelope 模式把完整 Debezium 变更事件落入固定九列表，保留操作类型、键、值、源位置和幂等键等信息，并支持 JSON（VARIANT 列）或 Protobuf 编码。相比默认的 typed 模式直接映射源表列，envelope 模式为下游处理保留了排序与审计所需的证据。配合 AUTO CDC 按源 LSN 排序，可构建保留每个键最新版本的 Type-1 当前状态表；若需保留全部历史版本，则应构建 Type-2 表。
落地前需关注的限制
Zerobus Ingest 为只追加写入，落地后的原始变更表不会自动合并为当前状态，需要额外执行 merge 或 AUTO CDC 作业。Envelope 模式还会按目标和操作过滤，并在写入前拒绝超大记录，使其偏移量不被提交。这些机制降低了无效数据进入湖仓的风险，但也意味着运维方需监控被拒绝的记录，并确保下游去重与排序逻辑正确，才能让至少一次投递在业务层表现为可靠结果。
Q&A
Debezium Server 3.7 新增的 Zerobus Ingest sink 是什么？
它是 Debezium Server 的一个 sink，由 NVIDIA 与 Databricks 合作贡献并开源，可将数据库变更事件直接写入 Unity Catalog 管理的 Delta 表，无需部署 Kafka 集群。
envelope 模式与默认的 typed 模式有什么区别？
typed 模式（默认）将变更事件映射到源表自身的列；envelope 模式（NVIDIA 贡献）将完整的 Debezium 变更事件存入固定的九列表，保留操作、键、值、源位置和幂等键等信息，供下游处理。
这个 sink 的投递语义是什么？如何避免重复数据？
投递语义为至少一次（at-least-once）。如果后续记录组失败，之前已持久化的组可能被重新投递。每个事件携带一个 idempotency_key（基于目标、分区、键、操作和源位置的 SHA-256 标识），下游需按该键去重。
如何将落地的变更事件转换成当前状态表？
使用 AUTO CDC 构建 Type-1 表，按源 LSN 排序变更，保留每个键的最新版本。若要保留所有历史版本，则构建 Type-2 表。
相比传统的 Debezium + Kafka + Spark 架构，Debezium + Zerobus 方案有哪些优势？
该方案为本地推送架构，仅需源网络出站访问，无需运行 Kafka 集群，消除了中间消息总线，简化了端到端架构，降低了运维开销，同时保留完整的 Debezium 连接器生态。
Zerobus Ingest 支持高吞吐和并发吗？它是否只追加写入？
Zerobus Ingest 是无服务器的推送式摄取服务，专为高吞吐、高并发工作负载设计。它是仅追加（append-only）的，变更事件落地后需通过 merge 等操作构建当前状态表。
