4、实时特征计算：Flink/Spark Streaming实现、状态后端选择

实时特征计算，说白了就是让特征值在数据产生的瞬间完成更新。你想想看，如果用户刚点击了商品，推荐系统要等五分钟才能拿到这个行为特征，那还有什么意义？

我这些年做实时特征工程，踩过最大的坑就是——计算引擎选型没问题，但状态后端选错了，整个作业三天两头挂。今天咱们就把这块掰开揉碎了讲清楚。

4.1 实时特征计算的两种主流引擎

目前业界做实时特征，基本就是 Flink 和 Spark Streaming 二选一。我个人习惯用 Flink 做纯实时场景，用 Spark Streaming 做微批处理场景。为什么？往下看。

对比维度 Apache Flink Spark Streaming
计算模型 真正的逐事件处理 微批处理（Micro-Batch）
延迟 毫秒级 秒级（取决于批次间隔）
状态管理 原生强一致性状态 依赖外部存储做状态
事件时间语义 原生支持，精确 需要额外处理
特征新鲜度 亚秒级新鲜度 秒级新鲜度

核心结论：如果你的特征要求新鲜度在 1 秒以内，选 Flink。如果容忍 3-5 秒的延迟，Spark Streaming 完全够用，而且生态更成熟。

4.2 Flink 实时特征计算实战

我在项目中做过一个用户实时行为特征的计算任务。需求很简单：统计用户最近 5 分钟的点击次数、加购次数和收藏次数。但实现起来，坑不少。

4.2.1 核心代码骨架

// 用户行为事件流
DataStream<UserEvent> eventStream = env
    .addSource(new KafkaSource<>())
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<UserEvent>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getEventTime())
    );

// 按用户分组，计算滑动窗口特征
DataStream<UserFeatures> featureStream = eventStream
    .keyBy(UserEvent::getUserId)
    .window(SlidingEventTimeWindows.of(Time.minutes(5), Time.seconds(10)))
    .aggregate(new UserFeatureAggregator())
    .name("user-feature-window");

// 输出到特征存储
featureStream.addSink(new FeatureStoreSink());

嗯，这里要注意：Watermark 的设置直接决定了特征的准确度。我曾经把乱序容忍时间设成 30 秒，结果特征值总是滞后，排查了半天才发现是 Watermark 太宽松了。

我的经验：对于用户行为数据，乱序容忍时间建议设为 3-5 秒。太短会导致丢数据，太长会导致特征延迟。

4.2.2 状态后端选择——成败关键

Flink 的状态后端，说白了就是存中间计算结果的地方。选错了，作业跑着跑着就 OOM 了。我见过太多人在这上面栽跟头。

状态后端 存储位置 适用场景 注意事项
MemoryStateBackend JVM 堆内存 小状态、调试用 生产环境千万别用，会丢状态
FsStateBackend 文件系统（HDFS/S3） 中等状态、高吞吐 Checkpoint 写入文件系统
RocksDBStateBackend 本地磁盘 + 文件系统 超大状态（GB/TB 级） 需要调优 RocksDB 参数

避坑指南：我曾经在一个用户画像特征作业中用了 MemoryStateBackend，状态量只有 500MB，但用户量一上来，GC 频繁导致作业频繁重启。后来换成 RocksDBStateBackend，问题立刻解决。记住：生产环境默认用 RocksDB，除非你确定状态很小。

4.3 Spark Streaming 实时特征计算

Spark Streaming 虽然延迟比 Flink 高，但它的生态优势很明显。如果你的团队已经用了 Spark 做离线特征，那实时特征也用 Spark Streaming，维护成本会低很多。

4.3.1 结构化流实现

// 读取 Kafka 数据流
Dataset<Row> eventDF = spark
    .readStream()
    .format("kafka")
    .option("kafka.bootstrap.servers", "localhost:9092")
    .option("subscribe", "user-events")
    .load();

// 解析并计算滑动窗口特征
Dataset<Row> featureDF = eventDF
    .selectExpr("CAST(value AS STRING) as json")
    .select(from_json(col("json"), eventSchema).as("event"))
    .select("event.user_id", "event.event_type", "event.event_time")
    .withWatermark("event_time", "10 seconds")
    .groupBy(
        window(col("event_time"), "5 minutes", "10 seconds"),
        col("user_id")
    )
    .agg(
        count(when(col("event_type").equalTo("click"), 1)).as("click_count"),
        count(when(col("event_type").equalTo("cart"), 1)).as("cart_count")
    );

// 输出到特征存储
featureDF.writeStream()
    .outputMode("update")
    .foreachBatch((batchDF, batchId) -> {
        batchDF.write().mode("append").jdbc(featureDbUrl, "user_features", props);
    })
    .start();

关键点：Spark Streaming 的 withWatermark 设置要比 Flink 更宽松一些。因为微批处理本身就有延迟，Watermark 太紧会导致大量数据被丢弃。我一般设成批次间隔的 2-3 倍。

4.4 状态后端选型决策树

为了让你更直观地做选择，我画了一张决策图。你可以根据状态大小和延迟要求，快速定位合适的方案。

状态后端选型决策树 状态大小评估 小状态 (<1GB) 大状态 (>1GB) 低延迟要求 MemoryStateBackend 高可靠要求 FsStateBackend 标准场景 RocksDBStateBackend 超大规模 RocksDB + 增量CP 选型建议 • 状态 < 1GB 且对延迟敏感：MemoryStateBackend（仅限调试） • 状态 < 1GB 且需要高可靠：FsStateBackend • 状态 > 1GB：RocksDBStateBackend（生产首选） • 状态 > 100GB：RocksDB + 增量 Checkpoint + 异步快照 • 注意：RocksDB 需要调优 block cache 和 write buffer 大小

4.5 状态后端调优实战

选好了状态后端，不等于万事大吉。调优才是真正的考验。我分享几个实战中总结的经验。

4.5.1 RocksDB 调优三板斧

  1. 调整 block cache 大小：默认 8MB 太小，建议设为状态大小的 10%-20%。我一般设 256MB 起步。
  2. 增大 write buffer：默认 64MB，对于写频繁的特征作业，建议调到 256MB 以上。
  3. 开启 Bloom Filter：可以显著减少读放大，特别是对于随机读取的场景。
// RocksDB 调优配置示例
RocksDBStateBackend rocksDBBackend = new RocksDBStateBackend("hdfs://namenode/flink-checkpoints", true);
rocksDBBackend.setPredefinedOptions(PredefinedOptions.SPINNING_DISK_OPTIMIZED_HIGH_MEM);

// 或者手动调优
RocksDBOptionsFactory optionsFactory = new MyRocksDBOptionsFactory();
rocksDBBackend.setRocksDBOptions(optionsFactory);

我的习惯：每次调整 RocksDB 参数后，先在小流量上跑 30 分钟，观察 GC 频率和状态访问延迟。没问题再全量上线。千万别直接在生产环境调优，我吃过这个亏。

4.5.2 Checkpoint 策略

Checkpoint 是 Flink 的保命机制。但 Checkpoint 太频繁会影响性能，太稀疏又会导致恢复时间过长。

场景 Checkpoint 间隔 Exactly-Once 语义 备注
高吞吐特征计算 30-60 秒 需要 配合增量 Checkpoint
低延迟特征计算 60-120 秒 需要 减少 Checkpoint 对性能的影响
非关键特征 5-10 分钟 At-Least-Once 允许少量重复

避坑指南：我曾经把 Checkpoint 间隔设成 10 秒，结果作业每 5 分钟就失败一次。原因是 Checkpoint 太频繁，导致状态后端 I/O 压力过大。后来改成 60 秒，配合增量 Checkpoint，问题解决。

4.6 实时特征计算的常见坑

最后，我总结几个实时特征计算中容易踩的坑。这些都是真金白银换来的教训。

  • 状态膨胀：用户特征状态会随着时间增长。一定要设置状态 TTL，否则内存会爆。我一般设 24 小时。
  • 数据倾斜：某些用户的行为量特别大，导致单个 Task 负载过高。解决方案是加盐或者使用自定义分区器。
  • 反压问题：特征存储写入慢，导致整个作业被拖慢。建议使用异步 Sink 或者增加写入缓冲。
  • 状态恢复慢：作业重启后，从 Checkpoint 恢复状态需要时间。对于大状态，建议使用增量 Checkpoint。

实时特征计算这块，说白了就是在延迟、吞吐和准确性之间找平衡。没有银弹，只有根据业务场景做取舍。我建议你从 Flink + RocksDB 这个组合开始，这是目前最成熟、踩坑最少的方案。

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