4、流式计算引擎：Apache Flink核心概念（DataStream、Window、Time）、Flink部署模式

好，咱们进入第四章。这一章聊的是实时风险监控系统的核心引擎——Apache Flink。

说实话，Flink 这几年在实时计算领域几乎是统治级的。我最早接触它是在 2018 年，当时公司要重构一套风控系统，从 Storm 迁移到 Flink。嗯，那会儿 Flink 还没现在这么火，但它的设计理念确实超前。

4.1 DataStream：一切皆流

Flink 里最基础的概念就是 DataStream。说白了，它就是一条无限流动的数据管道。你往里面塞数据，它就在后面处理。

我个人习惯把 DataStream 想象成一条传送带。数据像零件一样源源不断过来，你在传送带旁边放各种处理工位——过滤、转换、聚合、关联。每个工位就是一个算子。

核心要点：DataStream 是 Flink 对实时数据流的抽象。它不关心数据从哪里来（Source），也不关心最终去哪里（Sink），只负责定义处理逻辑。

举个例子，风控场景里最常见的操作——解析交易事件：

DataStream<TransactionEvent> transactionStream = env
    .addSource(new KafkaSource<>())
    .map(json -> parseTransaction(json))
    .filter(event -> event.getAmount() > 0);

你看，这代码读起来就像在描述一个流程。先读 Kafka，然后解析 JSON，再过滤掉金额异常的数据。每一行都是一个算子，每个算子都产生一个新的 DataStream。

避坑指南：我曾经犯过一个低级错误——在 DataStream 上反复调用 map() 而不做任何状态管理。结果数据量一上来，内存直接爆了。记住，DataStream 是无状态的，你需要显式地使用 KeyedStream 或 RichFunction 来管理状态。

4.2 Window：把无限流切成有限块

流是无限的，但计算需要边界。这就是 Window 存在的意义。

你想想看，风控系统里要统计「过去5分钟内某用户的交易次数」。如果没有窗口，这个统计永远算不完。窗口就是那把刀，把无限的数据流切成一块一块的有限数据集。

Flink 提供了三种核心窗口类型：

窗口类型 说明 典型场景
Tumbling Window 固定大小，不重叠 每5分钟统计一次交易总额
Sliding Window 固定大小，可重叠 每1分钟统计过去5分钟的交易次数
Session Window 基于不活动间隔 用户连续操作，超过30秒无操作则结束会话

我项目中用得最多的是 Sliding Window。为什么？因为风控需要「实时感」。比如每10秒统计一次过去1分钟的高频交易，这种滑动窗口能让你看到数据的变化趋势，而不是等5分钟才出一个结果。

DataStream<TransactionEvent> keyedStream = transactionStream
    .keyBy(TransactionEvent::getUserId);

DataStream<WindowResult> windowedStream = keyedStream
    .window(SlidingProcessingTimeWindows.of(
        Time.minutes(1),   // 窗口大小
        Time.seconds(10)   // 滑动步长
    ))
    .aggregate(new CountAggregate());

注意：窗口大小和滑动步长的比例会影响性能。步长越小，窗口重叠越多，计算量越大。我曾经在线上把步长设成1秒，窗口大小5分钟，结果集群直接被打满。后来改成10秒步长，性能提升了5倍。

4.3 Time：流计算的灵魂

Flink 里时间是个绕不开的话题。它有三种时间语义，我刚开始学的时候也绕晕过。

  • Event Time：事件发生的时间。比如用户点击按钮那一刻的时间戳。
  • Ingestion Time：数据进入 Flink 的时间。
  • Processing Time：算子处理数据的时间。

做风控系统，我强烈建议用 Event Time。为什么？因为数据可能会延迟到达。比如用户凌晨1点发起交易，但网络抖动，数据3点才到 Flink。如果用 Processing Time，这个交易会被算到3点的窗口里，结果完全错了。

Event Time 配合 Watermark 机制，能优雅地处理乱序数据。Watermark 就像一个闹钟，告诉 Flink：「到这个时间点了，之前的数据应该都到齐了，可以触发计算了」。

DataStream<TransactionEvent> stream = env
    .addSource(kafkaSource)
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<TransactionEvent>forBoundedOutOfOrderness(
            Duration.ofSeconds(10)  // 允许10秒乱序
        )
        .withTimestampAssigner((event, timestamp) -> event.getEventTime())
    );

个人经验：Watermark 的延迟时间不要设太大。我见过有人设了5分钟，结果窗口要等5分钟才触发，实时性大打折扣。一般设10-30秒就够了，除非你的网络环境特别差。

4.4 Flink 部署模式：选对姿势很重要

Flink 的部署模式有三种，我挨个说说我的使用感受。

4.4.1 Standalone 模式

最简单，但我不推荐在生产环境用。它需要手动管理 JobManager 和 TaskManager 的进程，挂了还得自己重启。我早期做原型验证时用过，后来再也没碰过。

4.4.2 YARN 模式

这是我在大厂时最常用的模式。YARN 负责资源管理，Flink 负责计算。好处是资源可以动态分配，集群利用率高。而且 YARN 本身有容错机制，JobManager 挂了会自动重启。

# 提交 Flink 任务到 YARN
./bin/flink run -m yarn-cluster \
    -yjm 1024 \          # JobManager 内存
    -ytm 2048 \          # TaskManager 内存
    -ys 2 \              # 每个 TaskManager 的 Slot 数
    -yn 4 \              # TaskManager 数量
    ./my-flink-job.jar

4.4.3 Kubernetes 模式

现在越来越多的公司转向 K8s。Flink 在 K8s 上可以做到真正的弹性伸缩。我最近一个项目就是跑在 K8s 上，配合 HPA（Horizontal Pod Autoscaler），流量高峰时自动扩容，低谷时缩容，省了不少钱。

我的建议：如果公司已经有 K8s 集群，优先选 K8s 模式。如果没有，YARN 模式是稳妥的选择。Standalone 模式只适合本地开发和测试。

4.5 本章知识体系总览

下面这张图是我自己画的，把本章的核心概念串起来了。你看一遍应该就能理解 Flink 的整体工作流程。

Flink 实时风控处理流程 数据源 Kafka / Socket DataStream 无限数据流 算子链 map / filter / keyBy Window Tumbling/Sliding Event Time + Watermark 机制 Processing Time 当前机器时间 Standalone 本地/测试用 YARN 生产常用 Kubernetes 弹性伸缩 结果输出 风控告警 / 统计

这张图把 DataStream、Window、Time 和部署模式串在了一起。数据从 Kafka 进来，经过 DataStream 的算子链处理，进入 Window 做聚合计算，最终输出结果。而 Time 语义和部署模式则贯穿整个流程，决定了计算的准确性和系统的稳定性。

总结一下：Flink 的核心就三件事——怎么描述数据流（DataStream）、怎么切分数据（Window）、怎么定义时间（Time）。把这三点搞明白，Flink 就算入门了。部署模式嘛，选适合你团队基础设施的就行。

公众号:蓝海资料掘金营，微信deep3321

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