3. 数据集成与入仓策略

数据集成是数仓建设中最容易被低估、却最容易拖垮整体交付节奏的环节。源系统形态各异——业务库是行式事务存储、日志是半结构化文本、API 是带分页与限流的接口——它们进入云数仓的路径、时效、成本与一致性保障方式完全不同。本节围绕三类主流同步方法展开：批量抽取（Batch Extract）、增量捕获（CDC，Change Data Capture）与实时流式写入（Streaming Ingest），重点讲清各自的适用场景、关键配置点，以及如何组合成一条可运维的入仓链路。

一、先判断源系统的“可抽取形态”

选型的第一步不是比较工具，而是判断源端能提供什么。业务库通常具备自增主键或更新时间戳，可做基于水位线的增量抽取；若开启了 binlog/redo log，则可做日志级 CDC。日志文件一般按时间分区落盘，适合按目录或时间窗口批量拉取，也可通过采集代理转为流。API 则受限于分页、限流、鉴权与全量/增量接口差异，往往需要“全量初始化 + 增量轮询”的组合。

一个实用的判断顺序是：源端是否有可靠变更日志 → 是否可接受分钟级以上延迟 → 单次抽取数据量与窗口是否可控 → 目标端写入是否支持幂等。这四个问题基本能锁定方法区间。

二、批量抽取：稳定、低成本，适合 T+1 场景

批量抽取的核心是“水位线（watermark）”。以订单表为例，若存在 updated_at 字段，可每次抽取 updated_at > 上次最大水位线 的记录。首次全量初始化后，后续每天只拉取变更部分。配置要点包括：水位线字段必须单调且被正确索引；抽取窗口要留出重叠区间（如回退 5 分钟）以覆盖事务提交延迟；目标端按 dt 分区写入，便于重跑时整分区覆盖。

-- 增量抽取示例（伪 SQL）
SELECT order_id, user_id, amount, status, updated_at
FROM orders
WHERE updated_at >= '2024-06-01 00:00:00'
  AND updated_at <  '2024-06-02 00:00:00'
ORDER BY updated_at;

批量抽取的优点是实现简单、对源库压力可控、易于回补；缺点是延迟高，且无法捕获物理删除。若业务需要感知删除，应改用 CDC 或在源端增加逻辑删除标记。

三、增量捕获 CDC：低延迟、可捕获删除

CDC 通过读取数据库日志（MySQL binlog、PostgreSQL logical replication、Oracle LogMiner）获取行级变更，包含 insert、update、delete 三种操作。相比时间戳增量，CDC 不依赖业务字段，能捕获删除，且对源库侵入小。关键配置点有三：

• 快照与增量衔接：先做一致性快照，再记录快照开始时的日志位点，之后从该位点消费，避免中间丢数或重复。
• 位点管理：binlog file + position 或 GTID 必须持久化，重启后从上次位点继续。
• 目标端合并：ODS 层通常保留变更流水（含 op 类型），再在 DWD 层按主键做 merge，保证最终一致。

CDC 的典型延迟在秒级到分钟级，适合订单、支付、库存等对时效和准确性要求较高的主题域。需要注意的是，大事务会产生日志洪峰，消费端要具备背压与批量提交能力。

四、实时流式写入：面向事件与高吞吐

日志、埋点、IoT 信号等天然是事件流，适合经 Kafka 缓冲后写入云数仓。流式写入的关键不在“快”，而在“可控”：Kafka 分区数决定并行度；消费位点提交策略决定是否重复；微批间隔（如 1 分钟）在延迟与文件数之间取平衡。云数仓侧通常提供流式写入接口或微批导入，需开启幂等写入以避免重试导致重复。

五、组合策略与落地检查

真实项目很少只用一种方法。常见组合是：业务库用 CDC 入 ODS 变更表，日志用流式入 ODS 实时表，API 用批量抽取入 ODS 快照表，再统一在 DWD 层做清洗与合并。落地时建议逐项检查：

最后强调一个原则：先保证可回补，再追求低延迟。无论选择哪种同步方式，都要确保原始数据可追溯、任务可重跑、结果可验证。入仓链路的价值不在于“跑起来”，而在于长期稳定地跑对。