4. 数据源读取成本分析：Kafka Partition 数、消费 Lag、反压对资源消耗的影响

聊到实时特征的数据源，Kafka 基本是绕不开的。很多同学觉得，不就是从 Kafka 读数据嘛，给个 Topic 就能跑。但实际跑起来，资源消耗的差距能差出好几倍。

我个人习惯，在评估一个实时任务的成本时，第一个看的就是数据源这一层。因为这里埋着三个最关键的变量：Partition 数、消费 Lag、反压。这三个东西互相影响，搞不好就是资源黑洞。

4.1 Partition 数：并行度的起点，也是成本的起点

Kafka 的 Partition 数，直接决定了你的任务能开多少个并行度。说白了，一个 Partition 最多被一个消费者线程消费。你 Partition 只有 10 个，那你的 Source 并行度开到 20 也没用，有 10 个线程是空转的。

我在项目中遇到过一种情况：业务方为了追求高吞吐，把 Topic 的 Partition 数设到了 200 个。结果实时任务为了匹配这个数，也开了 200 个并行度。但实际每秒就几千条数据，大部分线程都在空等。CPU 没怎么用，但内存和线程切换的开销却上去了。

那怎么评估这个成本？我一般会看两个指标：

• Partition 利用率：实际有数据流入的 Partition 占比。如果 200 个 Partition 只有 50 个有数据，那剩下的 150 个就是纯浪费。
• 单 Partition 吞吐：每个 Partition 每秒处理的消息数。如果单 Partition 吞吐很低，说明并行度开多了。

你看这个表，Partition 从 10 涨到 200，吞吐几乎没变，但 CPU 和内存消耗翻了 5-10 倍。这就是典型的成本失控。

4.2 消费 Lag：隐形的资源杀手

消费 Lag，就是消费者落后生产者的距离。很多人觉得 Lag 大只是延迟高，其实它对资源消耗的影响更隐蔽。

为什么会这样？你想想看，当 Lag 堆积时，Flink 的 Source 算子会拼命拉数据。这时候会发生两件事：

1. 网络带宽打满：Source 线程会持续从 Kafka Broker 拉取大量数据，网卡跑满。
2. 反压传导：下游处理不过来，反压信号传到 Source，Source 开始限速。但限速不是不拉，而是拉一批、等一等、再拉一批。这个过程中，线程并没有休息，而是在反复做「拉取-等待」的循环。

我曾经排查过一个任务，CPU 使用率 80%，但吞吐只有预期的 30%。一看 Lag，已经堆了 2 个小时的数据。Source 线程一直在做无效的拉取和重试，白白消耗 CPU。

我一般会用这个公式来评估 Lag 对成本的影响：

有效吞吐 = 实际处理条数 / (实际处理条数 + 拉取重试条数) × 100%

如果这个值低于 80%，说明有大量资源浪费在无效的拉取上。

4.3 反压：资源消耗的放大器

反压是 Flink 的自我保护机制，但它也是一把双刃剑。反压出现时，整个链路的资源消耗都会放大。

我举个例子。一个实时特征任务，链路是：Kafka Source → 特征计算 → Redis Sink。如果 Redis 写入变慢，反压会从 Sink 一直传到 Source。这时候：

• Source 端：虽然不拉新数据了，但之前的缓冲区还在，GC 压力增大。
• 计算端：算子状态被频繁快照，Checkpoint 变大变慢。
• Sink 端：重试次数增加，连接池被占满。

你看，一个点的瓶颈，会放大到整个链路的资源消耗。我在项目中见过最夸张的情况，反压导致 CPU 使用率从 30% 飙升到 90%，但有效吞吐反而下降了 50%。

4.4 三者联动：一张图看懂

为了让你更直观地理解这三者的关系，我画了一张图。这张图我每次做成本分析都会用，算是我的一个习惯。

这张图把三个要素串起来了。你看，Partition 数影响并行度，Lag 反映消费能力，反压暴露瓶颈。三者互相影响，最终都体现在资源消耗上。

4.5 实战：如何快速定位成本问题

最后，我分享一个我在项目中常用的排查思路。当你觉得一个实时任务资源消耗异常时，按这个顺序查：

1. 先看反压：打开 Flink Web UI，看 Source 算子有没有反压标记。如果有，说明下游是瓶颈。
2. 再看 Lag：用 Kafka 命令行或监控工具看消费 Lag。如果 Lag 在增长，说明消费能力不足。
3. 最后看 Partition：检查 Topic 的 Partition 数是否合理。如果 Partition 数远大于实际并行度，考虑合并。

嗯，数据源这一层，说白了就是三个变量在打架。你把它们的关系理清了，成本分析就成功了一半。下一层，我们聊聊特征计算本身的成本，那又是另一番天地了。