📚 课程目录第3章流式数据血缘特点

3. 流式数据血缘特点：动态性、时间窗口与存储挑战

好，咱们进入第三章。前面两章我们把血缘追踪的基础概念和批处理场景讲透了。这一章，我重点聊聊流式数据。

说实话，流式数据的血缘追踪，比批处理要麻烦得多。我最早接触流式计算是在2018年，当时用Storm做实时ETL。那时候大家连血缘是什么都不太清楚，更别提追踪了。后来Flink兴起，大家才开始认真思考这个问题。

流式数据的血缘，有三个核心特点：动态性、时间窗口依赖、存储挑战。咱们一个一个拆开讲。

3.1 流式数据的动态性

批处理的数据集是静态的。你今天跑一次，明天跑一次，数据源是固定的文件或表。血缘关系在运行前就能确定。

流式数据不一样。数据源源不断地来，schema可能随时变化。你想想看，一个Kafka Topic里的JSON字段，今天多了一个字段，明天少了一个字段，后天某个字段类型变了。血缘关系怎么定义？

我在项目中遇到过这种情况：某天凌晨，上游系统升级，往Kafka消息里加了一个嵌套字段。我们的Flink任务直接报错，因为解析逻辑没跟上。事后查血缘，发现根本查不到这个字段的来源——因为血缘系统只记录了原始schema，没记录动态变化。

核心观点：流式血缘必须是动态的、运行时捕获的。不能像批处理那样，靠静态解析SQL就能搞定。

具体来说，动态性体现在三个方面：

Schema演化：字段增删改，类型变化，必须实时捕获
数据流拓扑变化：Flink作业的算子链可能动态调整，比如动态分流、动态Join
运行时上下文：同一个算子，处理不同数据时，血缘关系可能不同

举个例子：

// Flink SQL 动态分流示例
INSERT INTO high_risk_orders
SELECT * FROM orders WHERE amount > 10000;

INSERT INTO normal_orders
SELECT * FROM orders WHERE amount <= 10000;

这个SQL在编译期就能确定血缘吗？不能。因为amount字段的值是运行时才知道的。一条订单数据到底去了high_risk_orders还是normal_orders，取决于它的实际金额。血缘关系是数据驱动的。

我的建议：在流式血缘系统中，不要只记录静态的算子关系。要记录每条数据实际经过的路径。说白了，就是数据级血缘，而不是表级血缘。

3.2 时间窗口与血缘

流式计算的另一个核心概念是时间窗口。窗口让血缘追踪变得更复杂。

为什么会这样？因为窗口操作会改变数据的粒度。一条输入数据，可能参与多个窗口的计算。一个窗口的结果，又可能由多条输入数据聚合而成。

我举个例子，大家就明白了：

// Flink SQL 滚动窗口聚合
SELECT 
  TUMBLE_START(event_time, INTERVAL '5' MINUTE) AS window_start,
  TUMBLE_END(event_time, INTERVAL '5' MINUTE) AS window_end,
  user_id,
  COUNT(*) AS order_count,
  SUM(amount) AS total_amount
FROM orders
GROUP BY 
  TUMBLE(event_time, INTERVAL '5' MINUTE),
  user_id;

这个查询里，每条订单数据属于哪个窗口，取决于它的event_time。窗口边界是固定的：00:00-00:05, 00:05-00:10, 以此类推。

但问题来了：如果一条数据的event_time是00:03，它属于第一个窗口。如果因为网络延迟，这条数据在00:06才到达Flink，它应该算哪个窗口？

这就引出了事件时间 vs 处理时间的问题。血缘关系必须记录：

数据实际属于哪个窗口（事件时间决定）
数据在哪个窗口被处理（处理时间决定）
窗口的触发条件（是否允许迟到数据）

我曾经踩过的坑：有一次做实时大屏，用了滑动窗口，窗口长度1小时，滑动步长5分钟。结果血缘系统只记录了窗口ID，没记录窗口的起止时间。后来数据对不上，查了半天才发现，是因为窗口边界计算有偏差。从那以后，我要求所有窗口血缘必须包含window_start和window_end两个字段。

窗口血缘的存储结构，我建议这样设计：

字段	说明	示例
window_id	窗口唯一标识	win_20240101_0000_0005
window_type	窗口类型	TUMBLE / HOP / SESSION
window_start	窗口开始时间	2024-01-01 00:00:00
window_end	窗口结束时间	2024-01-01 00:05:00
input_records	参与计算的输入记录数	1523
late_records	迟到数据记录数	12
output_record	输出结果记录ID	rec_20240101_0005_agg_001

这个表结构，能让你清楚地知道：一个窗口结果是由哪些输入数据产生的，有多少数据是迟到的，窗口的边界是什么。

3.3 流式血缘的存储挑战

好，动态性和时间窗口讲完了。接下来是存储挑战。这个问题，说白了就是：流式数据量太大，血缘信息怎么存？

批处理的血缘，一天可能就几万条记录。流式处理呢？每秒可能产生几万条数据，每条数据都要记录血缘。一天下来，血缘数据量可能达到几十亿条。

我见过一个团队，直接用MySQL存流式血缘。结果呢？三天就把磁盘写满了。查询一次要等几分钟。这就是典型的存储选型失误。

流式血缘的存储，有三个关键挑战：

写入吞吐：每秒几万到几十万的写入，传统关系型数据库扛不住
存储成本：血缘数据是写多读少，但全量存储成本太高
查询效率：虽然写得多，但查询要求秒级响应，尤其是追溯数据问题时

怎么解决？我分享几个实践经验：

方案一：分层存储

热数据（最近1小时）：存Redis或内存，用于实时查询
温数据（最近7天）：存HBase或Cassandra，用于日常追溯
冷数据（7天以上）：存HDFS或对象存储，用于审计和离线分析

方案二：采样与聚合

不是每条数据都需要全量血缘。对于高吞吐的场景，可以按比例采样。比如每100条数据记录1条完整血缘，其余只记录聚合信息。我曾在某个日活千万的实时推荐系统里用过这个方案，血缘存储成本降低了80%。

方案三：血缘压缩

流式数据的血缘有很多重复信息。比如同一个算子处理的数据，血缘关系是一样的。可以只记录算子级别的血缘，数据级别的血缘用位图或布隆过滤器来压缩。嗯，这里要注意：压缩会损失精度，需要根据业务场景权衡。

下面这张图，是我在项目中实际使用的流式血缘存储架构：

这个架构的核心思路就是：不要试图用一个存储系统解决所有问题。热存储扛写入，温存储保查询，冷存储降成本。数据自动从热到温再到冷，逐级迁移。

最后，关于存储选型，我再说一个细节：流式血缘的写入模式是append-only，几乎不会更新。所以LSM-Tree结构的存储（HBase、Cassandra）天然适合。B+Tree结构的存储（MySQL、PostgreSQL）写入性能差，不建议用于流式血缘的主存储。