介绍 Flink 原生 S3 文件系统：专为性能打造，为生产环境设计

# 介绍 Flink 原生 S3 文件系统：专为性能而生，面向生产环境设计 来源：https://flink.apache.org/2026/06/26/announcing-native-s3-fs/ 2026 年 6 月 26 日 \- Gabor Somogyi, Samrat Deb Apache Flink 的许多工作都依赖底层文件系统：读写应用数据、物化流式 Sink，以及存储用于恢复的 Checkpoint 和 Savepoint。多年来，Flink 中的 S3 支持意味着要在两个基于 Hadoop 的插件之间做出选择，每个插件都有自己的权衡和配置问题。随着 Flink 2.3 的发布，现在有了更好的选择。今天，我们正式推出 `flink-s3-fs-native`，这是一个从零构建、无 Hadoop 依赖的 S3 文件系统，专为 Flink 打造。它在 Flink 2.3 中作为**实验性可选插件** (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#availability-and-roadmap) 提供，已经在多家大型科技公司的生产环境中大规模运行，并带来了可衡量、可复现的性能提升。 **概览** - **~2倍更快的 Checkpoint** (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#performance)：平均 48.8 秒 vs Presto 插件的 90.1 秒；小状态规模下最高可达 4.5 倍 - **即插即用替换**：替换 JAR 包，保留现有的 `flink-conf.yaml`，重启集群即可 - **无 Hadoop 依赖**：JAR 约 13 MB vs 30–93 MB；无需为 Hadoop 传递依赖进行 CVE 审查 - **AWS SDK v2** (https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html)：异步优先 I/O；AWS SDK v1 已于 2025 年 12 月 31 日结束支持 (https://aws.amazon.com/blogs/developer/the-aws-sdk-for-java-1-x-is-in-maintenance-mode-effective-july-31-2024/) - **一个插件搞定一切**：精确一次 Sink 和快速 Checkpoint —— 无需权衡，无需妥协 ## 两个插件，一个文件系统，没有完美的答案 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#two-plugins-one-filesystem-and-no-good-answer) 如果你之前为 Flink 配置过 S3，你可能知道 Flink 提供了两个 S3 文件系统插件，并且它们都注册在同一个 `s3://` 协议上。同一时间只能激活其中一个。多年来，如何在两者之间做出选择一直让人困惑。即使选定了一个，由于其名称相似但配置不同，许多最终用户仍然感到困惑 (https://rmoff.net/2024/08/06/troubleshooting-flink-sql-s3-problems/)。 - **Hadoop 插件**封装了 Hadoop 的 S3A 客户端。它支持 `RecoverableWriter`，从而实现精确一次 Sink。遗憾的是，它引入了完整的 `hadoop-common` 依赖树和 AWS SDK v1。配置使用 Hadoop 原生键（`fs.s3a.*`），并通过兼容层映射为 Flink 风格的键（`s3.*`）。 - **Presto 插件**过去因其更快的读取路径而被推荐用于 Checkpoint。但它不支持 `RecoverableWriter`，这意味着精确一次文件 Sink 无法与其配合使用。它带有已知的目录删除 bug (https://github.com/prestodb/presto/issues/17416)，需要 Flink 侧进行变通。它在底层也依赖于 `hadoop-common` 和 AWS SDK v1。 两者共享一个公共基础层，将 Hadoop `FileSystem` 适配为 Flink `FileSystem`。这个适配层增加了间接性，限制了 Flink 特定的优化，并将实现绑定到 Hadoop 的配置模型和 SDK 生命周期。结果就是，你或者拥有精确一次 Sink，或者拥有更轻量的读取路径，但无法同时拥有。此外，你还得承担 Hadoop 依赖带来的挑战。 **原生插件彻底消除了这个权衡。** --- ## 为什么这不仅仅是工程问题 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#why-this-matters-beyond-engineering) 决定替换 S3 插件不仅仅是性能选择，它直接带来运营和财务上的影响。 - **安全与合规团队**长期以来一直承担着对 `hadoop-common` 传递依赖树中的 CVE 进行分类的负担。这棵树很大，变化频繁，并且持续产生与 S3 或 Flink 无关的漏洞披露。移除它显著减少了这类繁琐工作。更少的依赖意味着更少的 CVE、更少的紧急补丁周期，以及新部署时更少的安全审查关卡。 - **平台与基础设施团队**运营多租户 Flink 集群，可以从干净、统一的 `s3.*` 配置命名空间中受益。原生插件的配置模型专为 Flink 设计。没有 Hadoop 风格的键映射，没有适配器转换层，也没有因设置未静默传播而导致的调试环节。 - **风险与合规团队**应注意，AWS SDK for Java 1.x 自 2024 年 7 月 31 日起进入维护模式 (https://aws.amazon.com/blogs/developer/the-aws-sdk-for-java-1-x-is-in-maintenance-mode-effective-july-31-2024/)，并于 **2025 年 12 月 31 日** 结束支持，此后不再接收任何更新或发布。两个现有插件所依赖的基础已经达到生命周期终点，这意味着没有新功能，且 bug 和安全修复的流将逐渐枯竭。继续使用 SDK v1 是一个不断累积的技术和合规负债。原生插件完全基于 **AWS SDK v2** (https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html) 构建。 - **运维团队**从更快的 Checkpoint 中获益于两个具体方面： - 更短的 Checkpoint 窗口意味着更少的 CPU 时间用于状态序列化，更多容量用于实际数据处理。 - 更紧凑的恢复窗口意味着故障后需要重放的数据更少。这直接提升大规模下的恢复 SLA。 好处并不限于运维团队。任何使用精确一次语义的应用在 Checkpoint 更快完成时都会看到更低的端到端延迟，因为下游记录可见性受限于 Checkpoint 完成。 ## 一站式解决方案：原生 S3 文件系统 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#one-stop-solution-native-s3-filesystem) | 特性 | flink-s3-fs-hadoop | flink-s3-fs-presto | flink-s3-fs-native | |------|-------------------|-------------------|-------------------| | 精确一次 FileSink | ✓ | ✗ | ✓ | | RecoverableWriter | ✓ | ✗ | ✓ | | Checkpoint | ✓ | ✓ | ✓ | | AWS SDK v2 | ✗ | ✗ | ✓ | | 无 Hadoop 依赖 | ✗ | ✗ | ✓ | | SSE-KMS 加密 | ✓ | ✓ | ✓ | | SSE-KMS 加密上下文 | ✗ | ✗ | ✓ | | 非阻塞 NIO 异步 I/O | ✗ | ✗ | ✓ | | JAR 大小 | ~30 MB | ~93 MB | ~13 MB | ### 特性亮点 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#feature-highlights) - **无 Hadoop 依赖树**。没有 `hadoop-common`，没有 `aws-java-sdk` v1，没有类遮蔽冲突。这也去掉了随 `hadoop-common` 一起传递的、与 S3 访问无关的包袱——例如 Jackson、Guava、protobuf、Jetty 以及 Kerberos/Zookeeper 栈——这些库都是 CVE 审查和版本冲突的常见来源。原生 shaded JAR 约 13 MB，比 Hadoop 插件（30 MB）小一半以上，比 Presto 插件（93 MB）轻 7 倍。 - **异步优先 I/O**。读写操作使用 AWS SDK v2 的 `S3TransferManager`，底层基于 Netty NIO 多路复用连接，避免了现有插件的每请求单线程瓶颈。批量状态恢复以并发批量传输的方式进行，并带有连接池感知的并发控制。这与替代 `s5cmd` 等外部工具所需的机制相同。 - **精确一次可恢复写入**。`NativeS3RecoverableWriter` 使用 S3 分段上传为 Flink 的 Sink 连接器和 Checkpoint 元数据提供精确一次语义。上传在失败时可恢复。写入器可以恢复进行中的分段上传，并从最后提交的部分继续。 - **每桶配置**。单个 Flink 集群将能够通过 `s3.bucket.<bucket>.*` 配置访问多个 S3 桶，支持不同的凭证、区域、端点和加密策略。该功能计划在 Flink 2.4 中推出。 - **服务端加密**。所有三个 S3 插件都支持 SSE-S3 和 SSE-KMS。原生插件新增的是 **加密上下文**：附加到 KMS 操作的自定义键值元数据，允许细粒度的 IAM 策略条件。 - **用于 Checkpoint 分片的熵注入**。Checkpoint 路径中的可配置子串在写入时被随机字符替换，将 Checkpoint 对象分布到 S3 的内部分区中，避免在高 Checkpoint 频率下出现热键限流。 - **生产级生命周期管理**。每个组件都遵循带可配置超时的异步关闭生命周期。 ## 性能 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#performance) 来自生产规模测试的基准测试显示了相对于 Presto 插件的明确、可衡量的提升。 ### 测试环境 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#test-environment) 基准测试运行在 Amazon EKS（ap-south-1）上，使用 Flink 2.1.1 集群，包含 1 个 JobManager（2 GB 内存，1 核）和 2 个 TaskManager（各 6 GB 内存，1.5 核，4 个任务槽），总并行度为 8。工作负载针对 20 GB RocksDB 状态，每 60 秒以 EXACTLY_ONCE 模式进行完整非增量 Checkpoint。测试运行约 77 分钟。除插件 JAR 本身外，两个插件的配置完全相同。这些结果反映了该特定环境和负载；您自己的数据将随对象大小分布、并行度、区域和集群大小而变化。完整的工作负载配置和方法记录在 **原生 S3 基准测试报告** (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406620396) 中，以便您在自己的环境中复现该基准测试。 ### 结果摘要 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#summary-results) | 指标 | flink-s3-fs-presto | flink-s3-fs-native | |------|-------------------|-------------------| | 平均吞吐量 | ~92 MB/s | ~200 MB/s (2.17x) | | 平均 Checkpoint 时长 | 90.1 s | 48.8 s (1.85x 更快) | | P90 Checkpoint 时长 | 155.0 s | 72.5 s (2.14x 更快) | | P99 Checkpoint 时长 | 165.3 s | 76.7 s (2.15x 更快) | | 同一窗口内完成的 Checkpoint | 40 | 78 (1.95x 更多) | | 每个 Checkpoint 平均存储 | 415 MB | 312 MB (缩小 25%) | ### 吞吐量 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#throughput) | 状态大小范围 | flink-s3-fs-presto | flink-s3-fs-native | 加速比 | |-------------|-------------------|-------------------|--------| | 0–2 GB | 79 MB/s | 362 MB/s | 4.58x | | 2–4 GB | 85 MB/s | 285 MB/s | 3.35x | | 4–6 GB | 84 MB/s | 173 MB/s | 2.06x | | 6–8 GB | 86 MB/s | 165 MB/s | 1.92x | | 8–10 GB | 91 MB/s | 180 MB/s | 1.98x | | 10–12 GB | 93 MB/s | 193 MB/s | 2.08x | | 12–14 GB | 93 MB/s | 198 MB/s | 2.13x | | 14–16 GB | 94 MB/s | 203 MB/s | 2.16x | 性能提升在所有状态大小下都保持一致，且随着状态增长仍保持 2 倍以上。 ### 更快的 Checkpoint 对运营意味着什么 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#what-faster-checkpoints-mean-for-your-operations) 1. **更低的 CPU 开销**。更短的 Checkpoint 窗口减少了状态序列化和 S3 I/O 占用的 CPU 时间，为实际数据处理释放了容量。 2. **更高的 Checkpoint 频率**。由于上传更快，您可以在不影响管道吞吐量的情况下更频繁地进行 Checkpoint。这直接减少了故障后需要重新处理的数据量。 3. **更严格的恢复 SLA**。状态恢复期间的异步批量下载路径与更快的 Checkpoint 写入路径是独立的增益。完整的基准测试方法和原始数据已发布在 **原生 S3 基准测试报告** (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406620396) 中。 ## 平滑迁移路径 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#smooth-migration-path) 无论您当前使用的是 Hadoop 还是 Presto 插件，切换到 `flink-s3-fs-native` **无需任何应用程序代码更改**。迁移是一个部署级别的操作： ``` # 1. 移除现有插件 rm -rf plugins/flink-s3-fs-hadoop/ # 或 plugins/flink-s3-fs-presto/ # 2. 添加原生插件 mkdir -p plugins/flink-s3-fs-native cp opt/flink-s3-fs-native-*.jar plugins/flink-s3-fs-native/ # 3. 检查 flink-conf.yaml # 原生插件使用简洁的 s3.* 键 # 无需再使用 Hadoop 特定键 (fs.s3a.*, presto.s3.*) # 4. 重启集群 ``` 存储在 S3 上的现有 Checkpoint 和 Savepoint 保持完全可读。原生文件系统与 Hadoop 或 Presto 插件写入的数据在读写上均兼容。 **配置简化示例：** ``` # 之前（Hadoop 插件） fs.s3a.access.key: ... fs.s3a.secret.key: ... fs.s3a.connection.maximum: 100 # 之后（原生插件）—— 相同的键，更简洁的命名空间 s3.access-key: ... s3.secret-key: ... s3.connection.maximum: 100 ``` **关于 s5cmd 的说明。** 使用 `s5cmd` 进行批量状态下载的用户应注意，原生插件不使用 `s5cmd`。它依赖 `S3TransferManager` 的异步并发传输引擎，该引擎在我们的基准测试中表现出更优的吞吐量。无需外部二进制依赖。 **同时运行两个插件。** 将旧版插件 JAR 和原生 JAR 同时放在 `plugins/` 中是完全受支持且安全的。当两者注册同一协议时，可通过可配置的 `priority` 选择获胜的工厂；默认情况下 Hadoop 插件优先，但您可以覆盖此设置以选择原生插件。Flink 不会崩溃，错误配置的迁移不会导致数据丢失风险。由于原生文件系统与 Hadoop 和 Presto 插件写入的数据在双向读写上均兼容，只需将优先级恢复即可完成回滚——这使得该机制成为分阶段迁移的审慎控制，而非简单安全网。 有关完整配置参考，请参阅 **S3 文件系统文档** (https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/filesystems/s3/)。 ## 可用性与路线图 (https://flink.apache.org/2026/06/26/announcing-native-s3-fs/#availability-and-roadmap) - **Flink 2.3**：`flink-s3-fs-native` 作为实验性可选插件提供。实验性意味着它功能完整且已在大型科技公司得到生产验证，但社区正在积极收集反馈并强化边缘场景，然后才会提升为默认插件。我们鼓励团队在预发布和生产环境中部署它，并分享体验。现有的 `flink-s3-fs-hadoop` 和 `flink-s3-fs-presto` 插件实际上已进入维护模式：它们将继续接收关键 bug 和安全修复，但不再规划新功能开发。 - **Flink 2.4**：计划包含更多功能和错误修复，包括： - **每桶配置**：单个 Flink 集群将能够通过 `s3.bucket.<bucket>.*` 访问多个 S3 桶，支持不同的凭证、区域、端点和加密策略，无需自定义凭证注入 hack。 - **AWS CRT 客户端支持**：启用 `S3CrtAsyncClient` 以实现额外的分段和 HTTP/2 优化。上述基准测试结果是在**未使用**此功能的情况下取得的；CRT 支持将进一步推动性能提升。 - **增强的可观测性**：通过 Flink 的度量系统暴露 S3 操作指标（延迟、重试次数、吞吐量），使平台团队能够洞察 S3 I/O 行为。 - **基于流的 S3 读写**：提高大对象操作的内存效率。 - **阶段 2：推荐默认**。提升为推荐默认设置是社区决策，将在 `dev@` 邮件列表 (https://flink.apache.org/community.html) 上进行。我们关注的信号包括：来自生产用户的持续采用反馈，以及至少一个完整发布周期内 JIRA 中针对原生插件未出现未解决的 Blocker 或 Critical 问题。一旦达到该标准，原生插件将成为新 Flink 安装的推荐默认设置，相关文档、快速入门和教程将相应更新。 - **阶段 3：正式弃用**。一旦原生插件成为推荐默认设置，将通过社区流程（FLIP 和 `dev@` 投票）正式弃用 Hadoop 和 Presto 插件，并给出明确的移除前支持窗口。