2. 实时数据管道基础：Kafka、Flink 在画像系统中的角色与架构

聊到实时画像系统，绕不开两个核心组件：Kafka 和 Flink。说白了，它们就是整个流式更新的「血管」和「心脏」。我刚开始接触实时画像时，也困惑过——为什么非要用这两兄弟？直接用数据库不行吗？

嗯，咱们一步步拆开看。

2.1 为什么需要实时数据管道？

先想一个问题：用户刚刚点击了一个商品，系统要在几百毫秒内更新他的兴趣标签，然后推荐下一波内容。如果走传统的批处理，等跑完定时任务，用户早走了。

实时数据管道要解决三个核心矛盾：

  • 低延迟：事件发生到画像更新，延迟控制在秒级甚至毫秒级
  • 高吞吐：百万级用户同时产生行为，管道不能成为瓶颈
  • 可回溯：万一程序挂了，重启后能从断点继续消费，不丢数据

我在项目中遇到过最头疼的情况：管道吞吐上去了，但延迟飙到几十秒。后来发现是 Kafka 分区数配少了，消费者组里某个节点成了瓶颈。你想想看，这种问题不踩一次坑，光看文档是记不住的。

2.2 Kafka：画像系统的「消息总线」

Kafka 在画像系统里扮演什么角色？我习惯把它看作一个「持久化的消息队列」。所有用户行为——点击、浏览、收藏、购买——都先打到 Kafka，再由下游的 Flink 消费。

核心价值：解耦与缓冲

行为采集端不需要关心画像系统怎么处理数据。它只管往 Kafka 里写。画像系统也不关心采集端的高峰流量。Kafka 像一个巨大的蓄水池，削峰填谷。

2.2.1 Topic 与分区设计

画像系统里，Topic 设计直接决定了后续的扩展性。我见过不少团队把所有行为塞进一个 Topic，结果后期想单独调整某个行为的处理逻辑，改起来非常痛苦。

Topic 名称 分区数 数据保留时间 说明
user-click 12 7天 用户点击行为
user-view 12 7天 用户浏览行为
user-purchase 8 30天 购买行为，保留更久用于离线分析
user-profile-update 6 3天 画像更新事件，供下游服务订阅

分区数怎么定？我个人的经验是：分区数 = 目标吞吐量 / 单个分区吞吐量。一般单个分区能扛 10MB/s 左右。但要注意，分区数不是越多越好——太多分区会增加 Kafka 集群的元数据管理开销。

避坑指南：我曾经把分区数设得特别大（比如 64 个），结果消费者组重平衡时花了十几分钟。后来改成 12 个分区，配合合理的消费者线程数，重平衡时间降到了 30 秒以内。

2.2.2 消息格式与序列化

画像系统里，消息格式建议用 Avro 或 Protobuf。为什么？因为画像字段会频繁变更——今天加一个「兴趣标签」，明天加一个「活跃度评分」。如果用 JSON，改字段时所有消费者都得跟着改。

// Avro Schema 示例
{
  "type": "record",
  "name": "UserClickEvent",
  "fields": [
    {"name": "user_id", "type": "string"},
    {"name": "item_id", "type": "string"},
    {"name": "timestamp", "type": "long"},
    {"name": "click_type", "type": "string"},
    {"name": "extra", "type": ["null", "string"], "default": null}
  ]
}

注意那个 extra 字段。我习惯在每个消息里预留一个可选的扩展字段。这样后续加新属性时，不需要改 Schema 就能兼容旧数据。

2.3 Flink：画像计算的「实时引擎」

Flink 在画像系统里负责什么？简单说：从 Kafka 消费数据，做实时计算，更新画像存储。它把「流式更新」这件事做到了极致。

我刚开始用 Flink 时，总觉得它跟 Spark Streaming 差不多。后来发现完全不是一回事。Flink 是真正的「逐条处理」，每条数据进来立刻触发计算，延迟在毫秒级。而 Spark Streaming 本质上是微批处理，延迟至少几百毫秒。

2.3.1 核心架构：Source → Transformation → Sink

Flink 作业的架构非常清晰，就三步：

  1. Source：从 Kafka 读取数据
  2. Transformation：做各种计算——过滤、聚合、关联画像
  3. Sink：把结果写回画像存储（Redis、HBase 等）

下面这张图展示了典型的实时画像管道架构：

实时画像数据管道架构 用户行为采集 Kafka 消息队列 Flink 实时计算 画像存储 (Redis/HBase) 推荐/搜索服务 关键说明 • 采集端只写 Kafka，不关心下游 • Flink 消费 Kafka，做实时计算 • 画像更新后，通知下游服务 端到端延迟：200ms ~ 1s

2.3.2 状态管理与 Checkpoint

Flink 最强大的地方在于状态管理。画像计算中，经常需要维护用户的「会话状态」——比如用户最近 30 分钟的浏览序列。如果 Flink 挂了，这些状态怎么恢复？

答案是 Checkpoint。Flink 定期把状态快照保存到外部存储（HDFS、S3）。重启时，从最近的 Checkpoint 恢复，然后从 Kafka 对应偏移量继续消费。这就实现了「精确一次」的语义。

注意：Checkpoint 间隔不能太短。我见过有人设成 1 秒一次，结果 Flink 集群一半资源都花在做快照上。建议设成 10~30 秒，根据状态大小调整。

2.3.3 时间语义与 Watermark

画像系统里，时间是个大问题。用户的行为事件到达 Flink 时，可能已经延迟了几秒甚至几分钟（比如手机离线后上传）。如果按处理时间算，画像更新就会乱掉。

Flink 支持事件时间（Event Time），也就是行为发生的时间，而不是 Flink 收到的时间。配合 Watermark 机制，可以处理乱序数据。

// 设置事件时间与 Watermark
DataStream<UserClickEvent> clickStream = env
    .addSource(kafkaConsumer)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<UserClickEvent>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getTimestamp())
    );

这里设了 5 秒的乱序容忍度。什么意思？如果一个事件比它前面的事件晚了 5 秒以内，Flink 还能正确处理。超过 5 秒，就会被当作迟到数据。

个人经验：乱序容忍度不要设太大。我曾经设了 30 秒，结果 Watermark 迟迟不推进，窗口计算延迟严重。后来改成 5 秒，配合侧输出（Side Output）处理迟到数据，效果好了很多。

2.4 Kafka + Flink 的典型协作模式

在实际项目中，Kafka 和 Flink 的协作有几个固定模式：

  • Kafka → Flink → Kafka：Flink 消费原始行为数据，计算后把更新后的画像写回另一个 Kafka Topic，供其他服务订阅
  • Kafka → Flink → Redis：Flink 直接更新 Redis 中的用户画像，推荐服务实时读取
  • Kafka → Flink → HBase：适合存储大规模画像数据，支持按用户 ID 快速查询

我个人最常用的是第一种模式。为什么？因为把画像更新事件写回 Kafka，可以解耦画像计算和画像存储。下游可以有多个消费者——推荐服务、搜索服务、运营分析——各自按需消费。

2.5 避坑总结

最后，把我这些年踩过的坑总结一下：

坑点 表现 解决方案
Kafka 分区数过多 消费者重平衡慢 分区数控制在 12~24 个
Flink Checkpoint 太频繁 集群吞吐下降 间隔设 10~30 秒
Watermark 容忍度太大 窗口延迟高 设 3~10 秒，配合侧输出
消息格式用 JSON 字段变更困难 改用 Avro 或 Protobuf
所有行为共用一个 Topic 扩展性差 按行为类型拆分 Topic

嗯，Kafka 和 Flink 的基础就讲到这里。记住一句话：管道设计决定了画像系统的天花板。前期多花点心思在架构上，后期能省很多麻烦。

← 上一章 📖 返回目录 下一章 →