时序数据库与变更数据捕获（CDC）工具

• 理解 Flux 查询语言
• 掌握 TSM 存储引擎
• 认识时序数据库特性

InfluxDB 2.x 使用 Flux 作为查询语言，Flux 是函数式、管道式的查询语言，支持对时序数据做筛选、聚合、join、数学运算等，替代 1.x 的 InfluxQL。存储引擎 TSM（Time-Structured Merge Tree）是专为时序设计的列式存储，采用压缩与时间分片，写入高效、压缩率高，适合高效的时序数据写入与查询。InfluxDB 2.x 用 bucket（替代 database 与 retention policy）组织数据，配合 Flux 处理时序数据分析。

Flux 提供强大的时序查询表达，TSM 提供专用存储。二者构成 InfluxDB 2.x 的查询与存储核心，面向时序分析。

• 理解 designated timestamp
• 掌握 latest by 优化
• 认识时序查询加速

QuestDB 要求每张表指定 designated timestamp（指定时间戳列），作为主时间维度，用于分区与时间索引，使时间范围查询、计算节流等操作高效。latest by 是 QuestDB 的语法，用于按某个键返回每个键最新一条记录（如每只股票的最新价），利用时间索引与列式存储快速定位，避免全表扫描。designated timestamp 提供时间索引，latest by 利用索引做"每键最新"查询，是时序高吞吐查询的关键。

designated timestamp 是 QuestDB 的时间轴，latest by 是"group by 取最新"的优化。两者利用时间索引加速高频时序查询。

• 理解 DolphinDB 金融函数库
• 掌握回测框架
• 认识量化分析能力

DolphinDB 是面向金融时序的分布式数据库，内置丰富的金融函数库（如技术指标、因子计算、时间序列统计、事件分析等），可直接在 SQL 或脚本中调用，无需移植。它还提供回测框架，支持策略回测、历史数据重放与性能评估，把海量历史数据与计算能力结合，降低量化研究的数据与计算成本。这让量化研究可在一个系统内完成数据存储、指标计算与回测。

内置金融函数与回测框架是 DolphinDB 的差异化，面向量化场景，把"存储 + 计算 + 回测"一体化，减少开发成本。

• 理解 Kafka Connect 架构
• 掌握 source connector
• 认识多数据库接入

Debezium 构建在 Kafka Connect 之上，作为一组 source connector 插件，把数据库的变更事件流式发布到 Kafka。它为每种数据库提供专用 connector（如 Postgres、MySQL、MongoDB、SQL Server 等），通过连接器捕获数据库变更，转换为结构化事件（Change Event）写入 Kafka topic。Kafka Connect 负责连接管理、任务调度与分布式运行，Debezium 提供解析与格式转换，实现统一的 CDC 数据管道。

Debezium = Kafka Connect 框架 + 各 DB 的 source connector。它把 CDC 事件流化到 Kafka，是流式数据接入的标准方式。

• 理解 Postgres 逻辑复制槽
• 掌握 MySQL Binlog
• 认识变更读取机制

Debezium 读取变更依赖数据库的日志机制：对 PostgreSQL 使用逻辑复制槽（logical replication slot），订阅 WAL 中的逻辑变更并持久化复制槽位置，支持断点续传；对 MySQL 使用 binlog 作为 slave 读取 binlog 事件，记录 binlog 位置可续传。通过这些机制，Debezium 无需侵入应用即可捕获插入/更新/删除，并记录每个变更的偏移（offset）用于 at-least-once 与恢复。

复制槽/binlog 是 CDC 的数据源。Debezium 消费它们并记录偏移，实现可靠、可恢复的变更捕获。

• 理解 outbox 模式
• 掌握事务与消息一致性
• 认识分布式事务下沉

Debezium 的 outbox 模式解决"业务事务与发送消息"原子性问题。应用在业务事务内把要发布的事件写入同一数据库的 outbox 表（与业务数据同事务），Debezium 捕获 outbox 表的变更，把事件可靠地发布到 Kafka。由于 outbox 写入与业务变更同事务，保证了"要么业务数据与事件都成功，要么都不成功"，避免分布式事务的一致性问题，实现可靠的"事务性发消息"与事件下沉。

outbox 模式用"同库事务 + CDC"实现业务与事件的原子性，替代分布式事务，是微服务/事件驱动的可靠模式。

• 理解 SMT 机制
• 掌握脱敏与路由
• 认识事件处理

Debezium 支持 SMT（Single Message Transform），在 Connector 内对每条消息做转换，常用场景包括脱敏（如把敏感字段替换、打码、哈希）与路由（根据字段值把事件路由到不同 topic）。SMT 在 Kafka Connect 的转换阶段执行，无需修改应用或写下游处理。例如用 ReplaceField 删除敏感字段、用 RegexRouter 按规则路由到动态 topic。这让 CDC 管道在源头即可做数据治理。

SMT 是 Kafka Connect 的轻量转换机制。脱敏保障数据安全，路由实现按内容分发，都是源头治理的常见手段。

• 理解复制槽活跃问题
• 掌握 heartbeat 机制
• 认识 WAL 保留

在低变更场景下，Postgres 的复制槽长时间无新 WAL 消费可能被 WAL 保留增多或连接被视为空闲，Debezium 通过 heartbeat.topic 周期性发送心跳事件。心跳事件即使没有业务变更也会产生，让复制槽持续有活动、offset 更新，从而维持复制槽活跃与 WAL 位置推进，避免复制槽因长时间空闲而膨胀或中断。这确保 CDC 在低流量下也能健康运行。

heartbeat 是"保活"机制，防止复制槽空闲导致 WAL 堆积或连接中断。周期心跳让连接与复制槽保持活跃。

• 理解 Maxwell 的 binlog 解析
• 掌握 JSON 输出
• 认识 Kafka/Redis 输出

Maxwell 是一个 MySQL 的 CDC 工具，模拟 MySQL 从库读取 binlog，解析其中的变更事件，转换为 JSON 格式（含数据库、表、操作类型、数据、时间戳等），并输出到 Kafka topic 或 Redis 等。它支持按表/库过滤、初始全量等，输出格式通用，便于下游消费。相比 Debezium，Maxwell 更轻量、专注 MySQL binlog 到 JSON 流。

Maxwell 用 binlog 模拟从库 + 转换 JSON + 输出到消息队列，是轻量 MySQL CDC 方案，适合简单同步场景。

• 理解 Canal 的 slave 模拟
• 掌握 binlog 解析
• 认识变更订阅

Canal（阿里）以 MySQL 从库（slave）身份连接主库，模拟从库协议接收 binlog 流，解析 binlog 中的行变更事件，转换为 Canal 自定义的 message 格式，供 Canal Client 消费或输出到 Kafka/RocketMQ。模拟 slave 协议让 Canal 无需在 DB 上安装插件，利用 binlog 天然支持主从复制的能力，实现低侵入的 CDC。它支持过滤、增量订阅与断点续传。

Canal 用"假从库"协议接入 binlog，是低侵入的 CDC 方案。解析 binlog 输出变更，广泛用于缓存同步、数据同步。

• 理解 Flink CDC 架构
• 掌握 Debezium 集成与自研 Source
• 认识多数据库接入

Flink CDC 是 Flink 的 CDC 生态，提供可直接使用的 Source connector，接入 MySQL、PostgreSQL、MongoDB、Oracle 等数据库。早期大量复用 Debezium 的解析能力，把 Debezium 变更事件映射为 Flink 的 RowData；后续自研 Source（如 MySQL CDC 的增量快照）以提升性能与可控性。Flink CDC 把变更流作为 Flink DataStream，支持实时计算、流批一体与写下游数仓。

Flink CDC 把数据库变更当作流，结合 Debezium 解析与自研 Source，打通"数据库变更 -> Flink 实时计算"。

• 理解增量快照（Incremental Snapshot）
• 掌握无锁并行快照
• 认识 3.x 全增量统一

Flink CDC 2.2 引入增量快照（Incremental Snapshot）框架，用"chunk 划分 + 高水位（high watermark）"并行读取多个 chunk 的初始快照，同时对高水位之后的增量变更做 binlog 补抓，初始快照与增量读取并行，从而无需对全表加锁，且支持并行大表同步。3.x 演进为"全增量统一框架"，把全量快照与增量同步统一为同一套 pipeline，基于 FLIP-27 的 Source 接口实现统一调度，支持动态分片、无锁、断点续传与更灵活的并行，进一步简化 MySQL/PG 等同步。

增量快照用 chunk 分片 + 高水位避免全表锁，是并行与大表同步的关键。3.x 统一全量/增量，提升架构一致性。

• 理解 at-least-once 语义
• 掌握业务主键去重
• 认识端到端一致性

Flink CDC 的 Source 提供 at-least-once 语义（可能重复），但下游常带业务主键。通过"at-least-once 投递 + 下游按业务主键去重/覆盖"，实现端到端 exactly-once 效果：重复事件因主键相同被覆盖，保证最终一致性。结合 Flink 的 checkpoint 保证状态与下游的幂等写入（upsert），可在不依赖分布式事务的情况下实现可靠的数据同步。这是 CDC 到数仓的常见一致性方案。

exactly-once 端到端靠"可重复 + 幂等写入"。at-least-once 允许重复，业务主键 upsert 去重，实现最终一致。

• 理解 hypertable 概念
• 掌握自动分块
• 认识时序扩展

TimescaleDB 是 PostgreSQL 的时序扩展，核心是 hypertable（超表）。用户创建 hypertable 时指定时间列，TimescaleDB 自动按时间间隔把数据划分为多个 chunk（每个 chunk 是一个底层 PostgreSQL 表）。分块按时间自动发生，新数据落入新 chunk，历史 chunk 可独立压缩/删除/管理。查询时优化器只扫描相关时间范围的 chunk，提升性能。chunk 让时序数据按时间高效组织与维护。

hypertable 用"时间分块"把大时序表拆成多个后台表，实现自动分区、按时间维护与查询剪枝，是 TimescaleDB 的核心。

• 理解 Continuous Aggregates
• 掌握 refresh_interval 自动刷新
• 认识物化聚合

TimescaleDB 的 Continuous Aggregates（连续聚合）是自动维护的物化聚合视图，按时间窗口聚合数据，定期刷新。在 2.x+ 中，可通过 refresh_interval 配置自动刷新策略，让系统按固定间隔自动把新数据聚合进物化结果，无需手动刷新。连续聚合支持增量刷新（只处理新增时间范围），保证聚合结果持续更新，同时查询直接读物化结果获得高性能。

Continuous Aggregates 用物化 + 增量刷新实现"持续最新"的聚合。refresh_interval 自动化刷新，减少人工维护。

• 理解 Real-time 模式
• 掌握 Continuous 模式
• 认识实时性权衡

TimescaleDB 的 Continuous Aggregates 支持两种刷新模式：Continuous 模式只返回已物化的历史聚合结果，性能稳定但最新数据（未物化部分）不包含；Real-time 模式在物化结果之上"实时"合并尚未物化的最新时间窗口数据，即查询时把物化聚合与最新原始数据临时聚合合并，从而返回包含最新数据的结果，更实时但多一次合并开销。Real-time 适合需要近实时聚合的场景，Continuous 适合对一致性/性能更敏感的场景。

差异在"是否实时合并最新未物化数据"。Real-time 实时但多合并，Continuous 稳定但仅物化，按实时性需求选择。

• 理解压缩机制
• 掌握列式压缩
• 认识存储成本

TimescaleDB 提供压缩功能，对历史 chunk 采用列式存储与压缩（如行间 dedup、字典编码、delta 编码等），可显著降低存储占用（通常 90%+）。压缩在 chunk 级别进行，用户可配置压缩策略（如按时间把超过某期限的 chunk 自动压缩）。压缩后查询仍可读（在内存中解压），只是少许性能开销。这适合长期保留大量历史时序数据、控制存储成本的场景。

压缩用列式存储 + 编码降低占用，是历史时序数据降本的关键。按时间自动压缩兼顾保留与成本。

• 理解 retention policy
• 掌握自动删除
• 认识数据生命周期

TimescaleDB 支持 retention policy（保留策略），通过 add_retention_policy 配置，按时间自动删除超过指定期限的 chunk（整个 chunk 被删除，高效）。例如保留 30 天，超过 30 天的历史 chunk 被后台任务自动清理。结合压缩，可先压缩再按保留期删除，实现"热数据压缩、过期数据删除"的数据生命周期管理，降低存储成本并保持表最优。

retention policy 按时间整 chunk 删除，高效治理数据生命周期。与压缩结合实现冷热分层与自动清理。

• 理解 bucket/organization/token
• 掌握多租户隔离
• 认识访问控制

InfluxDB 2.x 用 organization（组织）、bucket（存储桶）、token（令牌）实现多租户隔离。organization 是顶级的租户/组织单元，bucket 是组织内存储时序数据的容器（含保留策略），token 是访问凭证，绑定到 organization 并授予读写权限。不同租户用不同 organization 与 token 隔离，bucket 划分数据域，token 控制访问权限，实现安全的多租户隔离。

三级模型（org/bucket/token）实现租户与权限隔离。org 划租户，bucket 分数据域，token 控权限，构成安全的隔离体系。

• 理解 IOx 列存引擎
• 掌握 SQL 支持
• 认识 3.x 演进

InfluxDB 3.x 用 IOx 重构存储引擎，引入列式存储（把 TSM 从 2.x 的行式/时间分片改为列式），利用 Parquet 格式与对象存储，提升分析查询性能与压缩。同时 IOx 支持标准 SQL 查询，与 Flux 并存，让用户可用 SQL 处理时序数据，并集成 Arrow 生态。列存让大范围聚合分析更高效，SQL 支持降低使用门槛，是 3.x 的重大演进。

IOx 用列存 + Parquet + 对象存储，配合 SQL/Arrow，提升分析与扩展性，代表 InfluxDB 3.x 的架构升级。

• 理解 tasks 机制
• 掌握定时任务与告警
• 认识流式处理

InfluxDB 的 tasks 是基于 Flux 的定时任务，可定期对数据做聚合、转换、下采样，并输出结果或触发告警。用户定义 task 的 Flux 脚本与调度间隔，InfluxDB 按计划执行，把结果写入新 bucket 或检查条件发出告警/通知。tasks 让 InfluxDB 具备内建的流式处理与告警能力，无需外部系统，适合阈值监控、数据降采样等场景。

tasks 用 Flux 脚本定时执行，实现聚合、降采样与告警。它是 InfluxDB 内建的流处理/告警手段。

• 理解 line protocol 格式
• 掌握高效写入
• 认识批量写入

InfluxDB 的 line protocol 是文本行格式，每行表示一条时序数据点，格式为：measurement,tag_key=tag_value field_key=field_value timestamp。tag 用于索引/过滤，field 是数值，timestamp 是时间戳。客户端以 line protocol 批量写入（HTTP/InfluxDB 协议），InfluxDB 解析并落盘。line protocol 简洁高效、支持批量与压缩，是 InfluxDB 的高吞吐写入方式。

line protocol 是 InfluxDB 的写入协议，用文本行表达 measurement/tag/field/timestamp，简洁高效，适合批量高吞吐写入。

• 理解 QuestDB 原生时序表
• 掌握 SQL 与 PG-Wire
• 认识兼容性

QuestDB 是原生时序数据库，表按时间分区、列式存储，针对时序写入与查询优化。它提供标准 SQL 查询，并支持 PG-Wire 协议（PostgreSQL 线协议），使 Postgres 客户端/工具可直接连接查询，降低使用门槛。结合 designated timestamp 与最新值优化，QuestDB 实现高吞吐写入与低延迟查询，同时通过 PG-Wire 兼容主流的 SQL 生态。

原生时序表 + SQL + PG-Wire 让 QuestDB 兼具高性能与生态兼容。PG-Wire 让现有 PG 工具可用，降低接入成本。

• 理解 ILP 协议
• 掌握写入兼容
• 认识生态兼容

QuestDB 7.x 引入 ILP（InfluxDB Line Protocol）写入协议，即支持以 InfluxDB 的 line protocol 格式写入数据。这让使用 InfluxDB 客户端/sdk 的应用能无缝向 QuestDB 写入，降低迁移成本并复用 InfluxDB 生态的采集工具。ILP 与 QuestDB 自有的 PG-wire/HTTP 写入并存，提供多种写入途径，提升兼容性与易用性。

ILP 支持让 QuestDB 兼容 InfluxDB 写入生态，方便采集工具与迁移。多写入协议并存提升集成灵活性。

• 理解列式存储
• 掌握带宽优化
• 认识查询性能

QuestDB 采用列式存储（column-based），数据按列连续存放。查询通常只读取需要的列，而非整行，从而减少 IO 与网络带宽；列式配合压缩（如按列压缩、delta 编码）进一步降低存储与传输量。对于聚合分析（只读写若干列），列式存储显著减少带宽消耗与读取延迟，提升查询吞吐。

列式存储"按需读列"减少无效 IO，配合列压缩降低带宽。聚合查询只读相关列，是列式在时序分析中的核心优势。

• 理解分布式时序存储
• 掌握脚本语言
• 认识一体化分析

DolphinDB 把分布式时序数据库与高性能脚本语言一体化：底层是分布式时序存储，支持海量数据处理；上层提供类 SQL 的脚本语言，支持向量化计算、函数式编程、流计算与金融分析。用户可在脚本中直接对数据库数据做复杂计算，无需在数据库与应用间搬数据，实现"存储 + 计算 + 分析"一体化。这种一体化降低数据搬移成本，提升量化/金融分析效率。

一体化让计算靠近数据，避免数据搬移。脚本语言 + 分布式时序存储使 DolphinDB 适合高性能数据分析。

• 理解 TSDB 引擎
• 掌握 OLAP 引擎
• 认识分库存储

DolphinDB 提供两种存储引擎：TSDB 引擎面向时序数据，按时间与标签组织，支持高吞吐写入、按时间查询与最新值定位，适合高频时序数据；OLAP 引擎面向分析，采用列式存储与压缩，适合批量分析与复杂查询。用户可按数据用途选择引擎，甚至分库存储，把热时序数据放 TSDB 引擎、分析数据放 OLAP 引擎，实现存储与查询的优化分工。

TSDB 引擎优化时序写入与最近查询，OLAP 引擎优化列式分析。分库存储按访问模式选择引擎，兼顾写与分析。

• 理解 stream engine
• 掌握流式处理
• 认识实时计算

DolphinDB 提供 stream engine（流计算引擎），支持对实时流入的数据做流式处理，如聚合、窗口计算、因子计算、实时告警，在数据入库的同时输出计算结果。流引擎与存库结合，实现"边写边算"，支撑实时监控、实时因子与量化交易等场景。用户通过订阅流表并定义计算逻辑，引擎按事件实时响应。

stream engine 让计算跟随数据流实时执行，实现流批一体。边写边算支撑实时监控与策略。

• 理解 initial bootstrap
• 掌握 recover 模式
• 认识全量+增量

Maxwell 的 initial bootstrap 用于同步数据时先做全量初始加载：把表的历史数据全部导出为 JSON 事件输出到 Kafka，之后切换为增量 binlog 同步。recover 模式用于在 bootstrap 中断后恢复：从上次中断的位置继续完成全量，避免重复全量。两者配合实现"先全量后增量"的完整同步，且支持中断恢复，保证数据同步的完整性与可靠性。

bootstrap 提供全量，recover 提供断点续传，二者结合实现可靠的全量+增量同步，避免重复与遗漏。

• 理解 filter 配置
• 掌握过滤语法
• 认识选择性同步

Maxwell 支持 filter 配置，用于限定哪些数据库/表参与同步，如 exclude/include 指定库表，支持通配符。通过 filter 可只同步关注的表，忽略无关表，减少数据处理与输出量，提升同步效率与准确性。filter 支持黑名单/白名单模式，按业务需要选择性捕获变更。

filter 是 Maxwell 的选择性同步开关，用 include/exclude 限定库表，减少无关数据，提升效率。

• 理解 DDL 输出
• 掌握 DDL 变更捕获
• 认识 schema 同步

Maxwell 1.40+ 支持输出 DDL 事件，即捕获 MySQL 的 DDL（如建表、改表结构）变更并作为事件输出到 Kafka。这让下游不仅能同步 DML 数据变更，还能感知 schema 变化，用于 schema 同步、数据管道的一致性维护。DDL 输出配合 DML 让 Maxwell 覆盖更完整的数据库变更场景。

DDL 输出扩展了 Maxwell 的变更捕获范围，支持 schema 变更感知，是数据同步与 schema 治理的重要能力。

• 理解 Server/Client 解耦
• 掌握消息队列输出
• 认识架构设计

Canal 分 Server 与 Client 两部分：Server 负责连接 MySQL 解析 binlog 并维护变更，Client 消费 Server 的变更消息。两者解耦，让 Server 可独立部署、承载多个 Client；同时 Canal 支持直接把变更输出到 Kafka/RocketMQ 等消息队列，替代自定义 Client，实现更松耦合的架构。解耦后，Server 专注源解析，下游通过消息队列/Client 灵活消费，便于扩展与运维。

Server/Client 解耦 + 消息队列输出，让 Canal 的架构更灵活、可扩展。Server 专注解析，下游多样消费。

• 理解 Canal Adapter
• 掌握多目标同步
• 认识适配器

Canal 提供 Adapter（适配器）组件，把同步的变更事件写入 ES、HBase、RDB（关系库）等目标。Adapter 作为消费端，把 Canal 的 message 转换为目标系统的写入格式（如 ES 文档、HBase 行、JDBC 写入），实现 MySQL 变更自动同步到这些存储。通过配置 Adapter，用户无需自写消费代码即可完成多目标数据同步，常用于缓存同步、搜索索引、数据仓储。

Adapter 是 Canal 的目标适配层，把变更同步到 ES/HBase/RDB。用配置代替编码，降低多目标同步成本。

• 理解 Prometheus 集成
• 掌握监控指标
• 认识运维可观测性

Canal v1.1.5+ 支持暴露 Prometheus 指标，通过 metrics 接口输出同步相关的监控指标（如延迟、处理量、binlog 位置等），供 Prometheus 采集与 Grafana 展示。这让 Canal 融入标准监控体系，便于观测同步延迟、吞吐与健康状态，实现运维可观测与告警。指标暴露是 Canal 生产化运维的关键能力。

Prometheus 指标让 Canal 可观测、可告警。暴露延迟/吞吐等指标，便于监控同步健康与性能。

• 理解 Flink CDC 与湖表格式集成
• 掌握实时入湖
• 认识湖仓一体

Flink CDC 可与 Paimon/Iceberg/Hudi 等湖表格式集成，把数据库变更流实时写入湖仓（Lakehouse）。Flink CDC 的 Source 捕获变更，通过 Flink 的 Sink 写入湖表格式，湖表格式提供 ACID、upsert、时间旅行等能力，实现在 Lakehouse 上构建实时数仓。Paimon 尤其擅长流式入湖，Iceberg/Hudi 也支持 Flink 写入。这样"数据库变更 -> 实时入湖 -> 湖上分析"形成完整链路。

Flink CDC 是实时入湖的入口，湖表格式提供 ACID 与 upsert。结合实现数据库到 Lakehouse 的实时同步。

• 理解 CDC 算子 metrics
• 掌握 watermark 协同
• 认识实时度量

Flink CDC 的 Source/Sink 算子提供内建 metrics（如读取速率、延迟、同步进度、事件数等），用于监控 CDC 的实时状态。watermark 是 Flink 事件时间流的时间推进标记，CDC 来自数据库的变更无天然事件时间，需基于 binlog 时间戳或自定义水位生成 watermark，用于窗口/计算的时间推进。metrics 与 watermark 协同：metrics 反映同步健康与延迟，watermark 保证基于事件时间的窗口计算正确，二者结合支撑实时管道的时间语义与可观测性。

metrics 提供可观测性，watermark 提供时间语义。CDC 用 binlog 时间戳生成 watermark，配合 metrics 监控保障实时管道正确运行。