实时ETL与Kettle替代方案

ETL是三个英文单词的缩写：Extract（提取）、Transform（转换）、Load（加载）。说白了，就是把数据从一个地方取出来，处理一下，再放到另一个地方去。这个定义看似简单，但在不同的业务场景下，实现方式的差异可能是天壤之别。

传统ETL的困境

传统ETL是批处理模式。你设一个定时任务，比如每天凌晨两点跑一次，把昨天的数据全量处理完，写进数据仓库。这套逻辑简单、稳定，运维成本低，但有一个致命问题：数据是滞后的。你早上九点看到的数据，反映的是昨天的情况。在报表分析场景下，这种滞后或许可以接受。但在风控、推荐、实时监控等场景下，T+1的延迟意味着你错过了最佳决策窗口。

有人可能会说，那把定时任务调频繁一点不就行了？改成每小时跑一次，甚至每十分钟跑一次。这确实能缓解问题，但无法根治。原因有三：第一，每次调度都有启动开销，频繁调度会造成资源浪费；第二，很多批处理作业需要扫描全表或大范围分区，对源库压力大；第三，即使你做到每分钟一次，延迟仍然以分钟计，而且随着数据量增长，单次处理时间会越来越长，最终还是会滞后。所以，实时ETL要解决的不是“跑得更勤”的问题，而是从架构层面重新设计数据链路，让数据从产生到可查询，延迟控制在秒级甚至毫秒级。

实时ETL的四层架构

做技术方案之前，先把架构图在脑子里画清楚。实时ETL的全链路，从上到下分四层：数据采集层、消息缓冲层、流式计算层、结果写出层。每一层各司其职，层与层之间通过标准化的接口解耦。

第一层：数据采集

数据从哪里来？最常见的是业务数据库，比如MySQL、PostgreSQL，还有应用日志、消息系统、第三方API接口，以及IoT设备上报的传感器数据。这一层你不需要改造数据源，但你需要知道数据是以什么形式产生的，是结构化的还是半结构化的，变化频率有多高。采集方式主要有两种。

CDC（变更数据捕获）

CDC的原理是监听数据库的操作日志，比如MySQL的Binlog，把每一条增删改操作实时捕获出来，转成事件流。这种方式对业务系统完全无侵入，不需要改一行业务代码。业界常用的实现思路有两类：一类是基于数据库原生复制协议，直接伪装成从库来消费日志；另一类是通过解析归档日志文件。无论哪种方式，核心都是将行级别的变更事件化，输出为结构化的消息。CDC的优势在于捕获的是增量变更，数据量小、延迟低、对源库压力可控。但需要注意，CDC工具通常需要一定的权限配置，且不同数据库的支持程度不同。对于不支持CDC的数据源，退而求其次的方案是轮询查询，每隔几秒查一次增量字段，但这会增加源库负担，且无法捕获删除操作。

日志采集

应用程序产生的日志文件，通过轻量级采集器实时传输到下游。日志采集的挑战在于格式多样、量级大、可能包含多行日志（如异常堆栈）。常见的做法是在采集端做初步的解析和结构化，比如将一行JSON日志拆解为多个字段，或者用正则表达式提取关键信息。采集器通常支持背压机制，在下游处理不过来时自动降低采集速率，避免数据丢失。

第二层：消息缓冲

采集到的数据，需要一个高吞吐的消息队列来承接。这一层的作用是缓冲和解耦：上游数据源和下游计算引擎之间不直接通信，都通过消息队列中转。为什么需要这个中间层？原因有三：第一，上游的写入速率和下游的处理速率往往不匹配，消息队列可以削峰填谷；第二，当下游计算引擎升级或重启时，上游数据不会丢失，消息队列可以保留一段时间的数据；第三，多个下游消费者可以独立消费同一份数据流，互不影响。

选择消息队列时，需要关注几个核心指标：吞吐量、延迟、持久化机制、分区模型、消费语义（至少一次、至多一次、精确一次）。对于实时ETL场景，通常要求高吞吐、低延迟、支持多分区并行消费。消息队列的Topic分区数决定了下游并行处理的上限，分区数太少会成为瓶颈，分区数太多则增加元数据管理开销。

第三层：流式计算

数据从消息队列里出来之后，需要做清洗、过滤、格式转换、字段补全、聚合计算等一系列操作，然后再写出去。这是实时ETL的核心计算层。

流式计算引擎需要具备以下能力：

事件时间处理。数据产生的时间和数据到达处理系统的时间往往不一致，网络抖动、上游积压都会导致乱序。流式计算引擎需要基于事件时间而非处理时间来做窗口计算，并配合水位线机制来处理迟到数据。

状态管理。聚合计算、去重、Join操作都需要维护状态。状态可以存在内存中，也可以持久化到外部存储。对于大规模状态，需要支持增量检查点和快速恢复。

Exactly-Once语义。在数据从消息队列到计算引擎再到输出端的全链路上，如何保证每条数据恰好被处理一次，不重不漏？这通常需要消息队列、计算引擎和输出端三方配合，通过两阶段提交或幂等写入来实现。

窗口与触发。实时计算不是无界的一直算下去，而是按窗口切分。滚动窗口、滑动窗口、会话窗口各有适用场景。窗口的触发策略可以是基于时间的，也可以是基于数据量的，还可以是自定义的。

以下是一个流式计算逻辑的示意性伪代码：

stream
  .filter(event -> event.getType() != null)
  .map(event -> enrich(event, dimensionTable))
  .keyBy(event -> event.getUserId())
  .window(TumblingEventTimeWindows.of(Time.seconds(60)))
  .aggregate(new CountAggregator())
  .sink(outputStorage)

这段逻辑的含义是：过滤掉类型为空的事件，用维度表补全字段，按用户ID分组，做60秒的滚动窗口聚合，最后写出到存储。在实际生产环境中，还需要考虑异常处理、死信队列、监控告警等。

第四层：结果写出

计算结果需要写入目标存储，供下游查询或进一步处理。目标存储的选择取决于查询模式：如果是点查场景，可以写入键值存储或关系型数据库；如果是分析场景，可以写入列式存储或数据仓库；如果是全文检索场景，可以写入搜索引擎。写出层同样需要保证幂等性和一致性。对于支持事务的存储，可以用事务保证原子写入；对于不支持事务的存储，可以通过版本号或去重键来实现幂等。

传统ETL工具的局限与替代思路

传统ETL工具在设计之初主要面向批处理场景，其核心抽象是“步骤”和“跳”，通过图形化界面配置数据流转。这类工具在批处理时代非常成功，但面对实时场景时存在几个根本性局限：

第一，执行模型是批式的。即使调度频率提高到每分钟一次，本质上仍是“启动-执行-结束”的短批，无法做到常驻内存的流式处理。每次启动都有JVM预热、连接建立等开销，难以支撑毫秒级延迟。

第二，状态管理能力弱。传统ETL工具的转换步骤通常是无状态的，做聚合时需要借助外部数据库或全量重算。而实时计算需要频繁的增量聚合、窗口计算，对状态管理有很高要求。

第三，扩展性受限。传统ETL工具多采用单机或主从架构，水平扩展能力有限。当数据量增长到一定规模，单节点处理能力会成为瓶颈。

第四，生态封闭。很多传统ETL工具的数据源接入、转换算子、输出插件都是内置的，扩展需要按特定接口开发，灵活性不足。

那么，替代思路是什么？核心是采用“消息队列 + 流式计算引擎 + 灵活写出”的组合。消息队列负责缓冲和解耦，流式计算引擎负责有状态的计算，写出层根据目标存储的特性选择适配方案。这套组合的每一层都可以独立扩展，算子可以自定义开发，数据源和输出端通过连接器生态来扩展。

对于从传统ETL迁移过来的团队，建议采取渐进式策略：先保留批处理链路作为兜底，同时搭建实时链路，在关键指标上做双跑比对，确认实时链路的数据准确性后，再逐步切换。迁移过程中，需要特别关注数据一致性问题，因为批处理和流处理在乱序数据处理、重复数据消除等方面的语义不同。

总结

实时ETL不是对传统ETL的简单加速，而是架构层面的重新设计。采集层要用CDC和日志采集实现低延迟捕获；缓冲层要用高吞吐消息队列实现解耦；计算层要用流式计算引擎实现有状态、事件时间驱动的处理；写出层要保证幂等和一致性。四层各司其职，才能构建出稳定可靠的实时数据链路。传统ETL工具在批处理场景下仍有其价值，但在实时性要求高的场景下，采用分层解耦的实时架构是更合理的选择。