software

在 AWS EKS 上使用 Apache Flink 的旅程

发布: (2025年12月16日 GMT+8 18:00)
6 min read
原文: Dev.to

Source: Dev.to

介绍

在构建流式管道时，最大挑战之一不仅是处理数据——更是要在数据持续流动的情况下保持作业可靠运行。Apache Flink 有效地解决了这一挑战。

Apache Flink 是一个分布式流处理框架，专为有状态的实时数据处理而构建。不同于以批处理为主的框架，Flink 将流视为核心抽象，批处理仅是其特例。

关键优势

  • 精确一次处理保证
  • 针对长期运行作业的原生状态管理
  • 基于水印的事件时间处理
  • 检查点机制，使故障可恢复

这些特性使得 Flink 更像是一个面向持续运行系统的平台，而不仅仅是一个工具。

基于检查点的执行模型

流式管道会随时间演进：逻辑会变化，模式会扩展，性能调优也变得必要。Flink 的基于检查点的执行模型使我们能够：

  • 在不破坏下游系统的情况下重新启动作业
  • 安全地推出逻辑或配置更改
  • 将流式作业视为持续运行的系统，而不是一次性部署

它将有状态处理、一次性语义和安全演进相结合，使 Flink 成为生产管道的明确选择。

一旦我们决定使用 Flink，就需要一个可靠的运行时。AWS EKS 提供：

  • 托管的 Kubernetes 控制平面
  • 与 AWS 服务的原生集成
  • 在开发、测试和生产环境中的一致性

为了让 Flink 真正实现 Kubernetes 原生化，我们采用了 Flink Kubernetes Operator。

Source: …

在通过 Helm 安装运算符后，它会引入一个 FlinkDeployment 自定义资源定义（CRD）。部署变得完全声明式：我们在 YAML 中定义期望的状态，运算符会持续进行调和。

运算符职责

  • 启动 JobManager Pod（承载 Flink UI）
  • 根据需要扩缩 TaskManager
  • 配置网络、卷和服务账户
  • 管理作业的重启、升级和恢复

这大幅降低了运维负担，使 Flink 成为云原生且可投入生产的系统。

部署模型

我们将集群管理与作业管理分离：

  • FlinkDeployment – 定义会话集群（镜像、资源、Flink 配置、EFS 挂载）
  • FlinkSessionJob – 定义实际的流式作业（入口、参数、并行度、升级模式）

大多数部署通过 Terraform 完成，渲染 YAML 模板并使用 kubernetes_manifest 应用。

FlinkSessionJob 的简化示例

apiVersion: flink.apache.org/v1beta1
kind: FlinkSessionJob
metadata:
  name: my-streaming-job
spec:
  job:
    jarURI: s3://my-bucket/jars/my-job.jar
    parallelism: 4
    args:
      - "--input"
      - "s3://my-bucket/input/"
      - "--output"
      - "s3://my-bucket/output/"
  upgradeMode: last-state   # 💡 提示：要从最近的检查点重新运行作业，请将 upgradeMode 设置为 `last-state`。

安全运行作业

对于首次运行，我们通常以无状态方式启动作业。对于重启、回填或升级，我们依赖使用 upgradeMode: last-state 的基于检查点的恢复。这可确保：

  • 作业从最新的成功检查点恢复
  • 下游系统保持稳定
  • 即使是 CDC 源，也能将间隙或重复降至最低

安全变更流程

  1. 更新作业或集群规格。
  2. 通过 Terraform 或 kubectl 应用更改。
  3. 操作员会自动恢复状态。

业务逻辑变更（Python、SQL、JAR）

  • 将更新后的代码推送到 S3。
  • 通过 AWS DataSync 同步至 EFS。
  • 在 Flink 容器中验证文件。
  • 执行滚动的有状态升级。

此流程可安全地对关键流式管道进行迭代。

虽然 Operator 是我们的默认选择，但它在配置上有一定限制。针对特殊情况，我们使用 Terraform 维护一个独立的 Flink 部署：

  • 为 JobManager 和 TaskManagers 分别部署。
  • 通过 Service 和 Ingress 暴露 Flink UI。

权衡

方法优点缺点
Operator更安全、简洁、自动化配置灵活性受限
独立部署完全控制 Pod 与设置运维开销更高

大多数工作负载都能完美适配 Operator，但拥有备用方案可以在边缘案例中提供灵活性。

Conclusion

从选择 Flink 作为其有状态流模型，到在 AWS EKS 上运行它，再到使用 Flink Kubernetes Operator 安全地操作作业，这段旅程塑造了我们构建和维护流式管道的方式。Flink 不仅仅是一个处理引擎——它是一个用于演进、长期运行的数据管道平台。在 AWS 上以 Kubernetes 原生方式运行它，使我们能够在运营安全、可扩展性和灵活性之间取得平衡。

我们很高兴继续与 AWS Community Builders 以及更广泛的流媒体社区分享我们的学习成果。

Back to Blog

相关文章

阅读更多 »