Deliveroo 引入 Apache Flink 并选择 AWS KDA 进行管理

Deliveroo 在其技术栈中引入了 Apache Flink，用于丰富和合并从 Apache Kafka 或 Kinesis Streams 消费的事件。公司选择使用 AWS Kinesis Data Analytics (KDA) 服务来管理 AWS 上的 Apache Flink 集群，并分享了在 AWS KDA 上运行 Flink 应用的经验和观察。

Apache Flink 的应用背景

Deliveroo 使用 Apache Kafka 进行服务间消息传递和分析工作负载。然而，在许多情况下，从 Kafka 消费的消息需要从其他来源获取数据进行补充，或基于共同属性进行聚合（例如计算用户交互会话）。团队选择 Apache Flink 来解决这些用例，因为 Flink 是一个成熟的解决方案，适合处理无界和有界数据流的状态计算。

AWS KDA 的优势

AWS KDA 是另一个用于管理 Apache Flink 的集群管理服务，支持 Apache Beam 和 Apache Zeppelin。它提供了 Java、Scala、Python 和 SQL 的 API，以及与 AWS 服务（如 S3、MSK、Kinesis、DynamoDB、OpenSearch 等）集成的 SDK。Deliveroo 选择 AWS KDA 的原因包括：

• 抽象和简化了 Apache Flink 集群的管理和操作。
• 应用仅限于使用流模式、RocksDB 作为状态后端，集群资源（如 CPU 和内存）被抽象为 KPU。
• 由于公司内部对 Apache Flink 的采用率较低，选择 AWS KDA 是一个低风险的决策。

构建和部署流程

团队使用 CirceCI 和 Terraform 创建了构建和部署管道，并采用了多阶段 Docker 镜像构建。KDA 部署类似于 Lambda 函数，要求应用工件（Java 和 Scala 的 jar 文件或 Python 的 zip 文件）上传到 S3 桶。KDA 通过 AWS CloudWatch 和应用特定仪表板提供了对运行应用的监控，有助于故障排除。

挑战与问题

在使用 Flink 应用时，团队遇到了一些挑战，特别是在 AWS KDA 上运行 Python 应用时：

• 需要使用较旧版本（1.13）的 PyFlink 库作为 Python 应用和 Flink 内部 Java API 之间的适配层。
• 依赖 JVM 增加了应用打包的复杂性，且某些功能领域需要 Python 库依赖 Java 代码以提高性能。
• 发出自定义指标需要特定的方法以避免 Python/Java 集成问题。
• 由于应用容器需要同时运行 JVM 和 Python 运行时，这需要更多资源，可能导致需要更多应用实例来支持工作负载。

AWS KDA 的改进空间

开发者指出 AWS KDA 仍有一些需要改进的地方，包括：

• 安排和清理快照（保存点）的能力。
• 自动清理 S3 中的旧部署工件。
• 更改 Flink 任务管理器的低级配置（目前需要支持票）。
• 更友好的资源分配（KPU 和并行性设置可能难以处理）。

总结

尽管存在这些挑战和不足，团队观察到自使用 KDA 以来的一些显著改进，包括更新的文档和教程、Flink 1.15 版本的可用性以及许多错误修复。他们对选择 AWS KDA 感到满意，但也承认 KDA 并不适合所有人。对于大型应用，KDA 的资源定制可能较为复杂；对于小型应用，共享 Apache Flink 集群（会话模式）可能更具成本效益和灵活性。

更多关于 Apache Flink 部署选项的信息，可参考 Instacart 在 Kubernetes 上创建自服务 Apache Flink 平台。