实时ETL怎么做？四层架构设计与选型实践

做过数据工程的人，大概率都经历过这样的场景：业务方早上九点要看昨天的经营数据，而昨天的数据还压在凌晨的批处理任务队列里。传统离线ETL以定时批处理为核心，逻辑简单、运行稳定，但天然存在数小时的数据滞后。当业务从“看报表”走向“做决策”，对时效的要求就会从T+1逼近到秒级，这时就需要重新审视整条数据链路。本文从架构分层入手，把实时ETL的完整链路拆开讲清楚，并给出一套可复用的选型方法论。

一、ETL的本质与实时化的动因

ETL是Extract（提取）、Transform（转换）、Load（加载）三个单词的缩写，一句话概括：把数据从源头取出来，加工处理，再放到另一个地方去。这个定义几十年没有变过，真正变化的是业务对“延迟”的容忍度。

传统ETL是批处理模式：设定时任务，比如每天凌晨两点执行一次，把前一天的数据全量或增量处理完，写入数据仓库。这套逻辑简单、稳定、易于排查，但有一个致命短板，数据滞后。你早上九点看到的数据，反映的其实是昨天的世界。

实时ETL要解决的就是这个滞后问题，目标是把数据“从产生到可查询”的延迟压缩到秒级甚至毫秒级。典型的驱动场景包括：

• 实时风控与反欺诈：交易发生的同时完成规则判断与拦截；
• 监控大屏与运营预警：核心指标秒级刷新，异常即时触达；
• 供应链与库存联动：下单即刻触发库存扣减与补货决策；
• 推荐与营销：用户行为实时回流，特征即时更新。

但也要清醒：月度财务对账、T+1经营分析这类场景，批处理依然是性价比最高的方案。选型的第一原则是“按业务价值定时效”，而不是为实时而实时。

二、实时ETL的四层架构

做技术方案之前，先把架构图在脑子里画清楚。实时ETL全链路自上而下分为四层：数据源层、采集与传输层、计算处理层、存储与服务层。

[业务数据库]   [应用日志]   [第三方API]   [IoT设备]
     |              |             |             |
 CDC变更捕获   轻量日志Agent   定时拉取     标准协议接入
      \             |             |            /
       --------> [ 分布式消息队列 ] <---------
                        |
                   [ 流计算引擎 ]
           清洗 / 过滤 / 关联 / 补全 / 聚合
                        |
              [ 实时数仓 / 分析型存储 ]
                        |
          [ BI报表 / 监控大屏 / 数据服务API ]

2.1 数据源层：先盘点，不改造

数据从哪里来？最常见的是四类来源：

1. 业务关系型数据库：存放订单、用户、交易等核心结构化数据；
2. 应用日志：半结构化文本，是行为埋点数据的主要载体；
3. 第三方API接口：渠道、支付、物流等外部系统数据；
4. IoT设备上报的传感器数据：高频、小报文、时间序列特征明显。

这一层通常不需要改造，但你必须回答三个问题：数据是结构化、半结构化还是非结构化？变更频率多高、峰值吞吐多大？主键与业务键是什么？这三个答案直接决定下游每一层的技术选择。

2.2 采集与传输层：CDC与日志采集双通道

数据产生之后如何实时“吐”出来？主要有两条路径。

路径一：CDC（Change Data Capture，变更数据捕获）。 原理是监听数据库的事务变更日志，把每一条增删改操作实时捕获并转成有序的事件流。它对业务系统完全无侵入，不需要改一行业务代码，也避免了轮询查询给数据库带来的额外压力。评估CDC组件时重点考察四点：是否支持初始全量快照与增量日志的无缝衔接、断点续传能力、表结构变更（加字段、改类型）的兼容策略、捕获延迟水平。业界主流方案多以连接器形式部署，可运行在容器平台或独立集群上。

路径二：日志采集。 应用程序持续写日志文件，由部署在主机或容器内的轻量级采集器监听文件增量并实时推送下游。这条路径胜在简单可靠，适合行为埋点、审计追踪类数据。

采集到的数据需要一个高吞吐、可持久化的消息队列来承接。消息队列在这一层承担三个角色：

• 缓冲削峰：上游突发流量不直接冲击计算层；
• 解耦：数据源与消费方互不感知，可独立扩缩容；
• 可重放：为下游故障恢复和数据回溯提供基础。

工程上要注意两点：一是按业务主键（如订单ID）做分区，保证同一实体的变更顺序不乱；二是合理设置消息保留周期，为下游故障争取重放窗口。

2.3 计算处理层：流式加工的核心

数据从消息队列出来后，需要完成清洗、过滤、格式转换、字段补全、多表关联、聚合计算等一系列操作再写出去。批处理里这些是跑批任务，实时链路里则交给流计算引擎，核心差异在四个概念：

• 时间语义：必须区分事件时间（业务发生时间）与处理时间（数据被计算的时间），跨时钟同步、网络抖动都会造成乱序；
• 窗口机制：滚动窗口、滑动窗口、会话窗口支撑不同粒度的实时聚合；
• 状态管理：去重、多流关联都需要维护中间状态，状态要可容灾、可恢复；
• 语义保障：端到端“精确一次”依赖计算侧检查点与写入侧幂等共同实现。

一段典型的实时作业定义（示意）：

source: 订单变更流(来自CDC通道, 含操作类型: insert/update/delete)
transform:
  - 过滤: order_status != '测试单'
  - 补全: 关联用户维表, 补齐用户等级与渠道
  - 聚合: 按店铺ID开1分钟滚动窗口, 统计成交金额
sink: 实时汇总表(write_mode: upsert, 主键: 店铺ID+窗口起点)

2.4 存储与服务层：为查询而生

实时链路的终点不是“把数据写进去”，而是“让人和系统查得快”。常见做法是构建实时数仓分层：ODS贴源明细层、DWD明细宽表层、DWS汇总层、ADS应用层。分层逻辑与离线数仓一致，区别在于每一层都由流式作业持续刷新。底层存储按查询模式选择：高并发点查用KV型存储，多维分析用列式分析引擎，全文检索用搜索类引擎。写入方式上务必采用按主键的Upsert（存在则更新、不存在则插入），否则消息重放或任务重启必然产生重复数据。

三、绕不开的四个工程难点

1. 乱序与迟到数据。 解决思路是“按主键分区保序 + 事件时间窗口 + 设定允许迟到区间”，超期到达的数据单独落一张补偿表，由离线任务兜底合并。

2. 端到端一致性。 链路上任何一环重启都可能造成重复或丢失。方案是三件套配合：消息队列保留机制（可回溯）+ 计算引擎检查点（可恢复）+ 目标表幂等Upsert（可去重），三者叠加才能逼近精确一次。

3. 表结构演进。 上游加字段是常态而非例外。链路要具备“新增字段透传、旧格式兼容”的能力，最好在接入层统一做元数据管理，避免一处变更、全链路手工适配。

4. 延迟监控。 实时链路没有“跑完”的概念，必须持续监控采集延迟、队列积压、处理延迟三类指标，并配置分级告警。否则故障往往先被业务方在大屏上发现，数据团队陷入被动。

四、工具怎么选：一套方法论

回到大家最关心的问题：到底该选什么工具？我的建议是先把问题换掉——不问“哪个工具最好”，而问“我的场景需要什么能力”。可以从五个维度评估：

1. 数据源兼容性：能否直连你的数据库类型并支持CDC，决定对业务系统的侵入性高低；
2. 吞吐与延迟：峰值数据量与可接受的端到端延迟，决定引擎量级；
3. 开发维护成本：SQL化的配置方式降低了门槛，但复杂逻辑仍需代码能力，要匹配团队的技能储备；
4. 生态完备度：与消息队列、存储引擎、监控体系的连接能力是否齐全；
5. 演进路径：能否支持先批后流、批流一体的渐进式建设，避免重复投入。

部署路线上有自建与云上托管两类选择。自建灵活度高，但运维负担重：集群高可用、组件升级、故障恢复都要自己承担。云上方案把这些收敛为托管服务，以百度智能云为例，消息队列、流式计算、数据传输与集成、日志服务、监控告警等通用产品类目可以覆盖链路的各个环节，适合团队规模有限、希望聚焦业务逻辑的企业。一个务实的策略是：用托管服务把“管道与运行时”交给云，把开发精力留给数据模型与业务规则。

五、落地建议：渐进式演进，不要一步到位

1. 从一个高价值场景切入。 选一条延迟敏感的核心链路（如交易大屏或风控指标）做端到端打通，验证整条架构，再横向复制。全链路一步实时化，失败率极高。
2. 批流并行过渡。 过渡期保留离线链路做对账兜底，实时链路跑稳后再逐步下线；两条链路的指标口径要定期比对校验，避免“两个数对不上”的信任危机。
3. 把数据质量做进链路。 清洗规则、异常值告警、口径校验应该是流作业的一部分，而不是出问题后事后补数。
4. 为回放而设计。 所有实时作业都应支持“从某个时间点重跑”，这是实时体系与批处理体系最大的思维差异。

最后总结一句：实时ETL不是把批处理任务跑得更快，而是一次链路范式的重构，采集从轮询变为日志捕获，传输从文件搬运变为事件流，计算从定时跑批变为持续流式，存储从T+1分区变为可更新的实时表。先想清楚这四层各自的职责与边界，工具选型自然水到渠成。