【流式数据处理】Debezium 与 Change Data Capture
从 Debezium 变更事件信封(op、before/after、source)入手,拆解 snapshot 与 streaming 两阶段、Kafka Connect 的 connector task 与 offset/schema history 主题,并说明引擎侧如何保证主键顺序与幂等,衔接 lakehouse 第 19 章 upsert 入湖。
发布来自土法炼钢兴趣小组的知识、笔记、进展和应用。主题包括数据结构和算法、编程语言、网络安全、密码学等。
共 4 篇文章 · 返回首页
从 Debezium 变更事件信封(op、before/after、source)入手,拆解 snapshot 与 streaming 两阶段、Kafka Connect 的 connector task 与 offset/schema history 主题,并说明引擎侧如何保证主键顺序与幂等,衔接 lakehouse 第 19 章 upsert 入湖。
承接数据湖流式入湖:从 Kafka 日志与副本语义,到 Flink 事件时间、watermark、窗口、RocksDB 状态与 checkpoint,再到端到端 exactly-once 与 Debezium CDC 入湖。面向数据平台与实时工程师,补全批式湖仓之外的实时计算层。
拆解流式数据进入 Iceberg/Delta/Hudi 的入湖侧机制:Flink/Kafka Connect/Spark sink 如何提交、exactly-once 怎样把引擎 checkpoint 与表格式的原子提交对齐、CDC 如何借 equality delete 与 record index 做 upsert,以及高频提交与小文件、compaction 的拉扯。只讲入湖侧,流处理引擎本身的窗口与状态留给后续。
支付与账务系统里,"这笔操作能不能重放一遍"几乎是每一次故障复盘都会问到的问题。本文从网络重试的本质谈起,讲清楚幂等(idempotency)的三层设计、Idempotency-Key 的工程细节、订单状态机的落库方式,并横向对比 2PC、TCC、SAGA、可靠消息四种分布式事务方案,配合 Outbox Pattern、CDC、补偿策略与真实事故案例,给出一份可以直接落地的检查清单。