1. 数据管道概述：从传统ETL到实时流处理，数据架构的演进之路

大家好，我是你们这门课的老朋友。今天咱们聊聊数据管道的那些事儿。说白了，数据管道就是数据从产生到被用起来的整个流程。我做了十几年数据架构，亲眼看着它从“搬砖”变成了“自来水”。这中间的变化，其实挺有意思的。

1.1 传统ETL：那个“搬砖”的年代

早些年，数据量不大，业务也简单。那时候的数据处理，我习惯叫它“搬砖”。为什么？因为数据是静态的，我们得定时去“搬”。

典型的场景是这样的：每天晚上12点，业务系统不忙了，我们启动一个批处理任务。把今天的订单数据从数据库里读出来，经过清洗、转换，再加载到数据仓库里。第二天早上，老板看报表。

这个模式，就是经典的ETL（Extract, Transform, Load）。

我在项目中遇到过最典型的例子：某电商平台，每天凌晨2点跑ETL。结果有一次双十一，订单量暴增，ETL跑了6个小时还没跑完。早上8点，老板要看数据，报表还是空的。嗯，那场面，挺尴尬的。

为什么会这样？因为传统ETL有几个硬伤：

• 延迟高：最少也是小时级，通常是天级。你想看实时库存？对不起，等明天。
• 容错差：跑了一半挂了，得从头再来。我见过一个跑了4小时的ETL，最后5分钟报错，全白干。
• 扩展难：数据量翻倍，处理时间也翻倍。加机器？架构不支持。

1.2 实时流处理：数据像“自来水”一样流动

后来业务变了。用户下单后，希望立刻看到库存变化；风控系统需要秒级识别异常交易；推荐系统要根据你刚点的商品，马上更新推荐列表。

这时候，批处理就不够用了。你想想看，用户点了个“购买”，你告诉他“请等待24小时，我们明天处理你的订单”——这谁受得了？

于是，实时流处理登场了。数据不再是“搬砖”，而是像“自来水”一样，源源不断地流过来，随到随处理。

实时流处理的核心思想很简单：

• 事件驱动：每来一条数据，立刻处理，不等不靠
• 持续运行：管道是7x24小时开着的，不是定时启动
• 低延迟：从数据产生到处理完成，秒级甚至毫秒级

我个人的习惯是，把实时流处理想象成一条流水线。数据从源头（比如Kafka）流进来，经过一个个处理节点（比如Flink算子），最后流到目的地（比如数据库或数据湖）。每个节点只做一件事，但组合起来就能完成复杂的业务逻辑。

1.3 从ETL到流处理：架构演进的核心变化

说了这么多，咱们用一张图来总结一下这个演进过程。下面这张SVG图，展示了我眼中数据架构从传统ETL到实时流处理的变迁。

这张图其实挺直观的。左边是传统ETL，数据从源到仓，中间经过一个批处理的黑盒。右边是实时流处理，数据像流水一样，持续不断地流过处理引擎。

我总结了一下，核心变化有这么几点：

维度	传统ETL	实时流处理
处理模式	批量（Batch）	流式（Streaming）
延迟要求	小时级 ~ 天级	秒级 ~ 毫秒级
数据触发	定时调度	事件驱动
数据状态	静态快照	持续流动
典型工具	Sqoop, DataX, Kettle	Flink, Kafka Streams, Spark Streaming
容错机制	重跑整个批次	Checkpoint + 精确一次语义

1.4 为什么需要Lakehouse？

你可能会问：有了实时流处理，是不是就完美了？其实不是。我在实际项目中遇到过另一个问题：数据存哪？

传统数据仓库存结构化数据，但存不了日志、图片、视频这些非结构化数据。数据湖能存所有东西，但查询性能差，不支持事务。实时流处理引擎（比如Flink）处理能力强，但持久化能力弱，总不能把所有数据都放在内存里吧？

于是，Lakehouse架构出现了。它把数据湖的存储能力和数据仓库的查询能力结合了起来。说白了，就是既能存各种格式的数据，又能像用数据仓库一样高效查询。

举个例子。我之前帮一家金融公司做实时风控。数据源是Kafka，流处理用Flink，结果存数据的时候犯了难。存到HDFS？查询太慢。存到MySQL？存不下。后来用了Lakehouse方案，数据直接写到Delta Lake或Iceberg表里，Flink实时写，Spark离线读，同一份数据，两种用法，互不干扰。

1.5 本章小结

好了，咱们捋一下今天的内容：

• 传统ETL：定时搬砖，延迟高，适合离线报表
• 实时流处理：持续流水，延迟低，适合实时业务
• Lakehouse：统一存储 + 流批一体，是未来的方向

数据架构的演进，说白了就是业务在逼着技术往前走。用户等不了24小时，老板要看实时数据，风控要秒级响应——这些需求，最终催生了我们今天要讲的实时数据管道。