Tapdata 技术博客

数据采集：从CDC到实时数据服务的完整指南

2025-09-15 16:49 TapData

适用对象：企业架构师、数据平台负责人、数据工程/应用团队。目标：用一页讲清“数据采集”的方法、架构与落地路径，并把它升级为可直接消费的“实时数据服务”。

为什么现在要重视“实时数据采集”？

传统批处理的数据采集（按小时/天跑批）在报表时代尚可接受，但面对电商促销、金融风控、制造质量监控、线上线下统一库存等业务场景，“延迟的数据=过期的决策”。实时数据采集通过捕获增量变化，让数据在写入源系统后，几乎立刻能安全地流向需要它的地方，用更小的源负载支撑更高频的业务协作。对业务而言，这意味着：及时的客户画像、稳定的一致库存、快速的风控响应、可追溯的生产过程，以及更短的产品迭代周期。

数据采集的三条技术路线

数据采集的核心并不神秘，关键在于取舍：延迟、源系统负载、变更兼容性与运维复杂度之间的平衡。

1. 轮询（Query/Polling）

原理：按固定频率查询源表，对比时间戳/版本号增量拉取。
优点：易实现、对系统改造小。
限制：延迟受频率限制；高并发下易放大源库压力；误差与漏数风险需要额外校验。

2. 触发器（DB Trigger）

原理：在表级安装触发器，写入变更日志表。
优点：变更捕获更及时，延迟较低。
限制：侵入性强、影响事务；版本升级/表结构调整需要同步维护触发器；复杂场景易失控。

3. 日志解析 CDC（Log-based Change Data Capture）

原理：读取数据库事务日志/归档日志，解析出插入/更新/删除事件。
优点：对源负载低、延迟可控、能复原事务边界与顺序；对模式演进（新增列、重命名）更友好。
限制：实现复杂度更高，需要完善的位点管理、断点续传、追平与回放策略。

实践建议：在生产级实时场景，优先采用日志解析 CDC，以“低源负载 + 强一致序”的方式将增量变更交付给后续的平台层。

参考架构：从采集到“可消费”的服务层

目标：不仅把数据“拉出来”，更要把它“组织好、服务好”。

标准路径：

1. 源系统：Oracle / MySQL / SQL Server / PostgreSQL / MongoDB / 主流国产库（GaussDB、达梦DM、KingbaseES、OceanBase、TiDB 等）以及业务系统（ERP、MES、WMS、POS、CRM、PMS、HIS/LIS 等）。

2. CDC 层：以日志解析为主的增量捕获，保证有序、可回放、可追平，支持断点续传与位点管理。

3. ODH（Operational Data Hub）统一域模型：在平台中进行标准化、主数据对齐、轻量变换与治理，形成“可复用的业务域”（如：客户、商品、库存、订单、设备、能耗等）。

4. IVM（增量物化视图）：将域数据按消费场景增量聚合与展开，形成读优化视图，支撑高并发、低延迟访问。

5. 服务与分发：面向应用与数据消费者，以API / 事件 / 数据仓库/湖等多形态交付：

API（REST/GraphQL）：面向应用/伙伴，以版本化与鉴权机制输出“业务域数据”；
消息流：以事件形式继续分发；
OLAP/检索：写入 Doris/ClickHouse/StarRocks/Elasticsearch 等；
缓存/KV：以小视图支撑“写少读多”的热点查询。

9.15（1）.png 常见“源→目标”路径

Oracle → Doris（实时明细入仓与聚合查询场景）
SQL Server → ClickHouse（报表加速与近实时分析）
MySQL → MongoDB（以 IVM 支撑应用读路径扩展）
Kafka → Elasticsearch（日志/事件索引与检索）
GaussDB / 达梦 DM / KingbaseES / OceanBase / TiDB → Doris（信创环境下的实时数仓落地）
……

延伸阅读：Oracle→Doris 实时数据采集（CDC）手册：初始化到增量切换

行业场景速览：把“采集”变成可见的业务价值

制造（含 MES/设备/质量）：从 PLC/OPC UA/SCADA、温湿度、条码/RFID 到 MES 与质检系统，按 OEE 与 SPC 目标构建“实时可追溯”流程，异常即时预警并记录全链路证据。

延伸阅读：MES 数据采集实战：OEE、质量与温湿度的实时闭环

零售/电商：订单、库存与优惠事件在 ODH 中统一，IVM 输出“可用库存”“客户权益”“订单状态”等域视图；线上线下一致性体验与客服/售后即时查询成为常态。
医疗机构（HIS/LIS）：在合规与最小权限下实现采集，脱敏与审计留痕；按科室/路径构建域视图，提升就诊流程透明度与数据可用性。
金融/保险：交易与保单变更以低延迟进入 ODH，配合对账与序列保障，支持风控与客户服务；IVM 使核保、理赔节点的数据查询与回溯更直接。
政务/信创：金仓/达梦等国产数据库的 CDC 采集与统一建模，配合跨网传输策略与合规审计，以 API 与交换标准对外服务，支持共享与复用。

选型清单（RFP/评估要点）

延迟与吞吐：是否能稳定实现低延迟增量传递？是否具备追平与受控回放能力？
源系统负载：是否以日志解析为主？在高并发写入时能否不干扰业务？
模式演进：新增/重命名列、类型变更、软删场景是否可平滑适配？是否支持自动/半自动演进？
一致性与对账：是否提供行/字段级校验、双写一致性校验、差异告警与纠正流程？
安全与合规：字段级脱敏、RBAC/ABAC、租户隔离、访问审计是否内建？
可观测性：是否有端到端监控指标、背压可视化、容量规划与告警策略？
回退与演练：是否支持初始化/增量的灰度切换、断点续传、可控回退？
交付形态：是否能以 API/事件/OLAP/缓存等多形态输出，避免重复造管道？
生态与适配：是否覆盖主流商用/开源/国产数据库与常见 SaaS/消息系统？
运维复杂度：是否提供统一管理与模板化运维能力，降低学习与维护成本？

对比与选型延伸阅读

[A5｜Kafka Connect vs 实时数据采集平台]

[E1｜数据采集平台选型清单（RFP 模板）]

常见误区与最佳实践

误区 1：只把采集当“搬运”，忽略“可消费”。

建议：在 ODH 层完成统一域模型与轻度治理，再以 IVM 输出可直接被应用/分析消费的视图；别把“业务理解”丢给每个下游。

误区 2：过度依赖轮询/触发器，后期运维代价高。

建议：核心业务以日志解析 CDC 为主，轮询/触发器仅用于特例与补救，确保在源负载与一致性上的可预期性。

误区 3：忽视模式演进与回退演练。

建议：把 Schema 变更与回退作为流程内建，设置演练节奏与检查清单，避免上线后被“改表”打得被动。

误区 4：工具堆叠，无法统一治理与观测。

建议：以统一平台承载采集、建模、治理、服务化与观测，将“多工具拼装”转为“端到端可控”。

延伸阅读：CDC 数据采集全景：从轮询到日志解析，如何把延迟压到最低

延伸阅读：增量物化视图 IVM：把数据采集直接变成可消费的域服务

FAQ

Q1：TapData 与 Kafka/Kafka Connect 是什么关系？

A：共存与互补。Kafka 更适合消息总线与事件分发；TapData 侧重从数据库/业务系统 CDC 到 ODH/IVM/服务的端到端平台能力。必要时也可与 Kafka 对接作为分发通道。

Q2：如果源库压力很大，实时采集会不会影响业务？

A：以日志解析 CDC 为主的方式能显著降低源读压力；同时通过位点管理、背压与节流策略控制下游波动对源的影响。

Q3：表结构经常变更，采集会不会失败？

A：平台需要支持模式演进（新增/重命名列、类型变更、软删等）的自动/半自动处理，并提供演练与回退机制。

Q4：如何保证一致性与可追踪性？

A：通过事务序与事件顺序保真、字段级校验、对账与审计日志，保障端到端的可验证性。必要时提供重放与修复流程。

Q5：落地到应用，一定要自建 API 层吗？

A：建议平台原生输出版本化 API，并结合 IVM 提供读优化视图，减少应用侧重复建模与运维负担。

Q6：实时数仓/湖（Doris/ClickHouse/StarRocks/ES 等）如何配合？

A：采集到 ODH 后，按消费模式写入 OLAP/检索系统；对“写少读多”型应用可优先以 IVM+API 支撑，再与数仓/湖形成互补。

Q7：国产数据库与信创环境能否支持？

A：可支持主流国产数据库与相关安全合规要求（如等保/分级、国密、跨网策略等），并在 ODH 层统一治理与服务化。

Q8：如何开始？需要停机迁移吗？

A：通常采用“初始化装载 + 增量切换”的灰度路径，不需要停机。上线前建议完成对账演练与回退演练。

与 TapData 的关系

TapData Live Data Platform 专注于实时数据平台：覆盖多源 CDC（含主流国产数据库）、统一域模型（ODH）、增量物化视图（IVM）与多形态服务化交付（API/事件/OLAP/缓存），并内建可观测性与校验/对账能力。我们坚持以低源负载、可复用、易治理的路径，帮助团队把“采集”真正变成“可消费的实时数据服务”。