简介：传统ETL以批处理为主，数据延迟常达数小时甚至一天，难以支撑实时风控、实时推荐、实时运营等场景。本文从数据源、采集传输、计算转换、存储服务四个层面拆解实时ETL的完整架构，梳理CDC、日志采集、消息队列、流式计算等关键技术环节，并给出面向不同规模团队的选型思路与工程实践建议，帮助读者构建可落地、可扩展的秒级数据链路。
在很多数据团队的实际工作中，ETL仍然是数据平台最核心的链路之一。ETL代表三个基本动作：Extract，从业务系统或外部来源获取数据；Transform，对原始数据进行清洗、补齐、聚合等加工；Load，将处理后的结果写入目标存储，供分析或应用调用。
传统ETL通常采用批处理模式。工程上常见的做法是，在夜间业务低峰期启动定时任务，对前一天甚至更长时间窗口内的数据进行全量或增量抽取，再执行转换逻辑，最终写入数据仓库。这套方案的优势很明显：逻辑简单、运行稳定、资源消耗可控，也容易做失败重跑和血缘追踪。
但批处理模式存在一个无法回避的问题，就是数据延迟。假设一条用户订单在上午十点产生，而ETL任务要等到次日凌晨才执行，那么这条订单最早也要到第二天才能进入数据仓库。对于报表类场景，这个延迟或许可以接受；但对于实时风控、实时推荐、实时运营触达、实时库存预警等场景，分钟级甚至秒级的数据延迟已经成为硬性要求。一旦数据滞后，业务价值就会明显下降，甚至产生直接损失。
因此，实时ETL的核心目标并不是简单地把批处理跑得更快，而是从根本上将数据从产生到可查询的延迟压缩到秒级甚至毫秒级。这需要从架构设计、组件选型、容错机制、数据一致性等多个维度重新考虑整个链路。
一个完整的实时ETL链路，通常可以划分为四层：数据源层、采集与传输层、计算与转换层、存储与服务层。每一层的职责边界需要尽量清晰，否则后续扩展和运维会变得非常困难。
数据源层是实时ETL的起点。企业中最常见的数据来源包括业务数据库、应用日志、消息系统、第三方接口以及IoT设备上报数据等。
在设计实时链路之前，首先要回答几个问题：数据是结构化、半结构化还是非结构化的？数据变化的频率是每秒上千条还是每分钟几条？数据产生之后，是否有现成的接口或者日志可供读取？
对于业务数据库来说，MySQL、PostgreSQL等关系型数据库仍然是绝对主力。这类数据源天然具有明确的表结构，也具备事务保证，适合通过数据库日志进行变更捕获。对于应用日志，则通常表现为半结构化的JSON或者非结构化的文本，需要先经过解析和结构化处理。对于IoT场景，数据往往以高频、小包的形式持续上报，对传输链路的吞吐能力和边缘缓冲能力要求更高。
理解数据源的特征，是后续所有技术选型的前提。数据源层本身不需要做大规模改造，但必须明确：数据以什么形式存在，以什么频率产生，以什么方式可以被实时读取。
数据产生之后，需要被实时采集并传输到下游处理引擎。这一层需要同时解决两个问题：一是如何无侵入地获取数据变化，二是如何在高吞吐下保证传输的稳定性和可恢复性。
在数据库采集方向，CDC是最主流的方案。它的核心思路是监听数据库的增量日志。以MySQL为例，当一条数据发生插入、更新或删除时，数据库会将该操作写入二进制日志。CDC组件通过模拟从库的方式订阅这些日志，将其解析成结构化的变更事件，再投递到下游。由于读取的是数据库自身的日志，而不是通过SQL轮询业务表，这种方式对业务系统几乎没有侵入，也不会给源库带来过多的查询压力。
除了数据库变更日志之外，应用日志采集同样重要。很多业务系统会把关键行为写入日志文件，例如用户登录、下单、支付、接口调用等。通过轻量级采集组件，可以实时监控日志文件的新增内容，并将其发送到消息队列或日志中心。这种方式适用于没有数据库变更事件，或者业务语义只在应用层可见的场景。
无论是数据库变更还是日志采集，数据通常不会直接写入计算引擎，而是先进入消息队列。消息队列在实时ETL中扮演的是缓冲、削峰和解耦的角色。上游采集组件只负责把数据可靠地写入消息队列，下游计算组件则按照自己的消费能力从队列中拉取数据。这样即使下游出现短暂故障，数据也不会丢失，而是继续保留在队列中，待消费者恢复后继续处理。
主流做法是以高吞吐的分布式消息队列作为中枢，例如行业常见的Kafka类系统。这类系统具备分区存储、顺序写入、多消费者订阅等特性，能够很好地支撑实时链路的传输需求。需要注意的是，消息队列本身并不负责数据转换，它只负责“把数据送到该去的地方”。
数据进入消息队列之后，接下来的工作就是清洗、转换、过滤、补全、聚合以及关联计算。这也是实时ETL与传统ETL差异最明显的一层。
在批处理中，转换逻辑通常由SQL或者脚本在数据仓库中完成。一条数据可以反复读取、多次加工，处理过程相对从容。但在实时场景下，数据是一条一条连续到达的，计算引擎必须在内存中维持状态，同时保证低延迟和高吞吐。这意味着实时计算不仅要处理当前这一条数据，还要根据之前到达的数据更新结果。例如，实时统计某个商品过去一分钟的点击量，就必须维护一个时间窗口内的计数状态。
具体来说，实时转换层需要处理以下几类任务：
首先是过滤和清洗。无效数据、脏数据、格式异常的数据需要在进入下游之前被拦截或修复，否则会污染整个实时链路。其次是字段补全和格式标准化，例如将不同来源的字段名称统一，补充时间戳，补齐地区、渠道等维度信息。第三是关联计算，比如将订单事件与用户信息表进行实时关联，输出包含用户画像字段的宽表。第四是聚合计算，包括计数、求和、去重、TopN、窗口统计等。
工程实践上，计算层既可以采用SQL化的流处理方式，也可以采用编程接口构建自定义处理逻辑。前者更适合数据分析团队，能够以较低门槛完成大部分实时加工需求；后者则适合需要复杂状态管理、多流Join、自定义窗口逻辑的场景。无论哪种方式，计算层都需要具备容错和状态恢复能力。当任务重启时，程序应能从最近一次正确状态继续处理，而不是重新消费全部数据。
实时计算的结果需要写入合适的存储系统，才能被业务系统或分析平台查询。
这部分的选型与数据消费方式密切相关。如果下游是实时大屏、实时监控、实时报表，通常需要支持高并发点查和范围查询的存储。如果下游是事件驱动型应用，例如实时营销、实时风控，那么结果可能直接推送到下游服务，不一定要经过存储层。
在实时数仓架构中，常见的做法是分层存储。第一层是原始数据层，保存从消息队列接入的明细数据，用于回放、审计和后续批量校正。第二层是汇总层，存储经过实时计算后的维度指标，例如每分钟的订单量、每小时的活跃用户数等。第三层是应用层，直接面向业务查询，可以是内存型数据库、分析型数据库或者支持多维查询的引擎。
此外，实时链路还需要考虑数据延迟的量化监控。一条数据从产生到最终可查询，中间经过采集、传输、计算、写入四个环节，每一段的延迟都需要被度量和追踪。只有建立完整的端到端延迟监控，才能知道系统是否真正满足业务时效要求。
实时链路最大的挑战之一是数据一致性。与传统批处理相比，实时处理更容易出现数据重复、乱序、丢失和状态不一致等问题。
以常见的“至少一次”语义为例，采集或消费环节为了保证不丢数据，通常会采用重试机制。但重试可能导致同一事件被处理多次，从而造成计数偏高。工程上需要在关键链路中引入幂等设计，例如采用唯一事件ID去重，或者在写入端使用覆盖式更新来消除重复影响。
乱序问题同样不可忽视。在分布式环境中，同一业务实体的不同事件可能经过不同网络路径到达处理节点，到达顺序与发生顺序可能不一致。针对实时统计场景，通常需要设计水位线机制，允许在一定时间窗口内等待迟到数据，超过窗口则触发修正逻辑。
实时计算引擎通常需要在内存中维护大量状态。例如，计算过去一小时的用户行为序列，就需要保存一个小时内所有相关数据。如果任务发生故障，状态丢失将会导致计算结果不完整。
因此，实时计算框架普遍支持将状态定期写入后端存储，并在任务重启时从存储中恢复。这种机制保障了容错能力，但也对存储的写入性能和容量提出了更高要求。在工程实践中，需要根据状态大小、更新频率和恢复时间目标来设计合适的策略。
实时ETL链路的吞吐量往往随着业务波动而变化。例如促销活动期间，数据量可能是平时的数倍甚至数十倍。这就要求消息队列、计算引擎和存储系统都具备良好的横向扩展能力。
消息队列通过增加分区数量来实现吞吐扩展，计算引擎通过增加并行度和计算资源来加速处理，存储系统则通过分片和副本机制保证写入能力。与此同时，不同业务线的实时任务应当尽量做到资源隔离，避免一个高负载任务拖垮整个链路。
在工具选型上，不建议一开始就追求“最好”或“最全”的方案，而应该根据团队的工程能力、数据规模和业务时效要求来综合判断。
对于数据规模不大、团队人数较少、实时需求刚刚起步的场景，可以先采用“消息队列 + 流式处理”的轻量组合。通过标准化的数据接入方式，将核心业务数据接入消息平台，再用流式处理任务完成基础清洗和聚合，最后写入支持近实时查询的数据库即可。
对于数据规模大、业务复杂度高、需要同时支撑多套实时应用的团队，则需要构建平台化的实时数仓体系。在采集层，数据库变更捕获需要支持多源多活；在传输层，消息平台需要具备多集群管理、权限控制和容量规划能力；在计算层，需要统一的任务提交、状态监控、告警和恢复机制；在服务层，则需要向业务方提供标准化的数据查询接口。
值得注意的是，实时ETL并不是要完全替代批处理。更务实的设计是Lambda架构或Kappa架构的混合模式。核心业务链路走实时处理，保证时效；非关键链路继续保留批处理，用于全量校准和复杂分析。两条链路的结果可以在存储层或服务层进行合并，兼顾实时性与准确性。
实时ETL建设是一项系统性工程，它涉及数据采集、消息传输、流式计算、状态管理、数据治理等多个环节。做好实时ETL的关键，不在于选择某一个“最强”工具，而在于是否能够根据自身业务场景，设计出链路清晰、监控完善、可扩展可恢复的整体架构。
对于技术负责人来说，更重要的是先明确实时性要求到底有多高，数据量级有多大，哪些数据必须走实时链路，哪些可以继续保留批处理。只有把这些问题想清楚，后续的选型和建设才不会偏离方向。秒级数据链路的价值，最终要落到业务响应速度的提升上，而不是单纯追求某个环节的技术复杂度。