RisingWave vs. Apache Flink：如何进行选择？

在快速发展的大数据领域，流处理变得越来越重要。在这一过程中出现了许多辅助框架，包括 RisingWave 和 Apache Flink 这两个开源领域流行的分布式流处理系统。虽然这两个系统都能对连续摄取的流数据进行低延迟查询处理，但它们各有特点和优势。本文对 RisingWave 和 Apache Flink 进行了比较，帮助您决定哪个更符合需求。

我们会定期更新本文，以跟上快速迭代的开发进程。

概述

	Apache Flink	RisingWave
版本号	1.17	最新版本
授权许可	Apache License 2.0	Apache License 2.0
系统类别	流处理框架	流数据库
实时管道编排	复杂	简单
架构	MapReduce 风格	云原生
本地 API	Java、Scala、Python、SQL	SQL
客户端库	无	Java、Python、Node.js 等
状态管理	本地机器中的 RocksDB；定期检查点到 S3	存储在 S3 中的本地存储或等效存储
查询服务	数据集和表 API、Apache Flink 表存储、批处理模式执行	支持并发即时 SQL 查询服务
准确性	支持精确一次语义和失序处理	支持精确一次语义、失序处理和快照读取
集成和工具	大数据生态系统	大数据生态系统、云生态系统和 PostgreSQL 生态系统
学习曲线	陡峭	极为平缓
维护成本	高	低
性能成本	高	低
典型用例	流式 ETL、流式分析	流式 ETL、流式分析、在线查询

介绍

Apache Flink 是一个分布式流处理框架；RisingWave 是一个分布式 SQL 流数据库。

Apache Flink

Apache Flink 是流行的开源分布式流处理框架，于 2011 年推出。Flink 采用基于 Java 的分布式数据流引擎，支持批处理和流处理程序的并行、流水线和迭代执行。此外，Flink 支持精确一次语义的容错处理。用户可以在大型数据集群上用 Java、Scala、Python 和 SQL 编写程序。Flink 还提供了数十种流行系统的连接器，使用户可以轻松连接到现有的数据存储系统。

RisingWave

RisingWave 是专为流处理设计的开源分布式 SQL 数据库。RisingWave 项目于 2020 年底启动，致力于降低构建实时应用的复杂性和成本。RisingWave 使用 Rust 从零开始构建，经过精心优化，可支持云上高吞吐量和低延迟流处理。即使节点发生故障，它也能保证数据的一致性和完整性。作为一个数据库系统，RisingWave 具有自己的存储系统，用于持久化数据并执行用户发起的查询操作。它还提供数十个连接主流系统的连接器，允许用户自由连接到外部系统。

实时管道编排

使用 Apache Flink 开发应用时，开发人员需要管理多个系统并处理它们之间的一致性关系。使用 RisingWave 时，开发人员只需管理单个系统，无需考虑不同系统组件之间的关系。

使用 Apache Flink 开发应用时，用户需要连接多个流处理引擎实例与多个消息队列实例，以表达复杂的逻辑。要查询结果，用户必须将流处理结果导出到专用的下游数据库，并在那里执行查询。这种架构非常复杂，操作成本很高，而且要求用户对跨系统计算结果的一致性负责。

下图说明了使用 Apache Flink 等传统流处理引擎构建应用时的情况。开发人员需要管理多个系统并处理它们之间的一致性关系。

使用 RisingWave 时，用户只需专注于构建物化视图，并可将复杂逻辑拆分为多个级联物化视图，从而降低开发复杂性。RisingWave 可保证物化视图的一致性、持久性和高并发查询访问。用户只需管理一个 RisingWave 集群，因为 RisingWave 可确保不同物化视图之间的一致性。

下图说明了使用 RisingWave 流数据库开发应用时的情况。开发人员只需管理单个系统，无需考虑不同系统组件之间的关系。

架构

Apache Flink 采用大数据式耦合计算存储架构，针对可扩展性进行了优化；而 RisingWave 则实现了云原生的解耦计算存储架构，针对成本效率进行了优化。

作为一个诞生于以 Hadoop 为主导的大数据时代的开源项目，Flink 的架构深受 MapReduce 范式的影响。具体来说，Flink 通过将流式任务划分为多个并行实例来实现并行和分布式执行，每个实例处理任务输入数据的一个子集。虽然这种计算-存储耦合架构使 Flink 能够实现高并行性和可扩展性，但也会导致高执行成本。

RisingWave 诞生于云时代。通过采用现代的计算-存储解耦架构，RisingWave 可实现更好的可扩展性和灵活性。每个组件都可以进行不同的配置和独立扩展，从而提高成本效益和性能。新架构还允许对每个组件进行单独优化，从而减少资源浪费，避免任务过载。

本地 API

Apache Flink 提供底层 Java、Scala 和 Python API 以及高级 SQL 接口；而 RisingWave 则提供 PostgreSQL 风格的 SQL 作为用户接口。

Apache Flink 基于流和转换的概念实现了一种灵活而强大的编程模型。在 Flink 中，用户将数据处理管道定义为转换的有向无环图（DAG），这些转换可以串联在一起，形成复杂的数据处理工作流。本地 API 支持 Java、Scala 和 Python 中的这种编程模型，使开发人员能够用这些语言创建流式管道。Flink 的编程模型允许对数据处理进行细粒度控制，从而提高性能和资源利用效率。但缺点是，Flink 的编程模型可能难以学习和使用。此外，Flink 在其内核之上提供了一个 SQL 层，用户可用其处理流式数据。

RisingWave 是一个 SQL 流数据库，为用户提供 PostgreSQL 风格的 SQL。这意味着用户可以像使用 PostgreSQL 一样执行流处理。虽然 RisingWave 不提供底层 API，但它支持 Python 和 Java 的用户定义函数（UDF），用户可用其来表达复杂的逻辑。

客户端库

Apache Flink 是一个不支持任何语言客户端的编程框架。要使用 Apache Flink，用户必须编写 Java/Scala/Python 程序或使用 Flink 自带的 SQL 客户端。

RisingWave 与 PostgreSQL wire 协议兼容，可与 PostgreSQL 的大多数客户端库协同工作。这意味着 RisingWave 可以使用 PostgreSQL 驱动程序支持的任何编程语言进行通信，如 Java、Python 和 Node.js。此外，用户还可以使用官方 PostgreSQL 终端 psql 与 RisingWave 进行交互。

状态管理

Apache Flink 使用 RocksDB 来维护本地状态，这些状态会定期检查点到远程存储（如 S3）；RisingWave 在设计上是一个数据库，拥有自己的存储，可将内部状态和数据持久化到 S3 或同等的存储服务中。

状态管理是流处理系统的一个重要方面。它是指系统跟踪和管理内部计算状态的能力，以支持弹性扩展和故障恢复。

作为流处理框架，Apache Flink 并没有针对数据持久化进行优化。它使用 RocksDB 来管理每台机器的内部状态，并定期将内部状态发送到远程持久化存储，以便进行检查点。这种策略适用于状态规模较小的场景。然而，在支持大规模状态场景（如维护 7 天窗口或加入多个数据流）时，Flink 可能会直接崩溃或面临由于过度页面交换而导致性能下降的问题。

RisingWave 使用自己的云原生存储系统（称为 Hummock），将有状态流执行器中的物化视图和内部状态持久化到云存储服务（特别是所有兼容 S3 的服务）。与 LSM 树类似，Hummock 可在分层存储中持久化数据，并针对批量写入进行了优化。在 RisingWave 中，数据持久化由检查点式协调流程触发。每个执行器可从其上游执行器接收障碍信息，并将状态更新的 delta 值递增到 Hummock 中。这种机制使 RisingWave 能够支持需要超大规模状态管理的流处理。

查询服务

Apache Flink 并非设计用于提供即席查询；RisingWave 在设计上是一个数据库，可以提供并发的即席查询。

Flink 的批处理引擎与其流处理引擎有着相似的设计原则，因此可以利用许多相同的优化和功能。在 Flink 中运行批处理查询时，用户可以使用 DataSet API 或 Table API，两者都提供了用于编写批处理作业的高级接口。DataSet API 允许用户使用 Java 或 Scala 编写批处理作业，而 Table API 则提供了一种名为 FlinkSQL 的类 SQL 语言，用于查询和操作批处理数据。

2022 年，Flink 启动了 Table Store 项目（现已更名为 Apache Paimon），以增强其查询流式计算结果或中间状态的能力。Table Store 主要采用列式存储格式，旨在解决 Iceberg 等数据湖产品对流式系统支持不足的问题。Table Store 的设计反映了其主要用于离线分析场景，并不适合高并发在线查询。

RisingWave 使用户能够使用 PostgreSQL 风格的 SQL 查询物化视图和有状态流操作符的内部状态。该平台内置批量查询引擎，利用现代数据库技术优化性能。批处理引擎提供两种模式：本地模式和分布式模式。本地模式用于处理高并发的点查询，而分布式模式则用于并行处理大量数据。这样，用户就可以依靠 RisingWave 提供并发的 SQL 查询，从而最大限度地减少对额外外部系统的需求，降低成本。

正确性

Apache Flink 向下游系统提供一致和完整的结果；RisingWave 提供更高的正确性保证，因为它不仅能确保一致性和完整性，还能为任何数据访问提供一致的快照。

对于流处理系统来说，正确性的定义有两个方面：

• 一致性。即使系统发生故障，每个数据事件都将只被处理一次。这也被称为精确一次语义。
• 完整性。即使数据流不按顺序到达，最终结果也会按顺序排列。

RisingWave 和 Apache Flink 都是能够保证一致性和完整性的流处理系统。具体来说，这两个系统都通过一致的检查点算法来保证精确一次语义。它们还引入了水位线的概念，以推断无序数据的完整性。

RisingWave 不仅是一个流处理平台，也是一个流数据库。它能确保所有数据访问都能获得存储数据的一致快照。这意味着用户始终能够看到一致的结果，而不会产生任何混淆。

集成和工具

Apache Flink 提供了数十个连接器，可以连接到大数据系统；相比之下，RisingWave 不仅可以很好地集成到大数据和云生态系统中，还可以集成到 PostgreSQL 生态系统中。

RisingWave 和 Apache Flink 都是为大规模流处理而设计的，对大数据生态系统提供了全面的支持。二者都支持从 Kafka 和 Pulsar 等消息队列摄取流数据。此外，二者还能将处理后的数据传输到 MySQL、Redis、Redshift 和 Snowflake 等下游数据库或数据仓库。

RisingWave 与 Apache Flink 的不同之处在于，它是专为云生态系统设计的。这意味着 RisingWave 可以与 Confluent Cloud、DataStax 和 Grafana Cloud 等云服务轻松集成。此外，RisingWave 还支持与上游 source 的内置安全连接。用户可以使用任何 RisingWave 客户端直接创建跨 VPC 的 PrivateLink。

RisingWave 既可以作为流处理系统，也可以作为数据库系统。作为数据库系统，它与 PostgreSQL 客户端兼容，因此自然适合 PostgreSQL 生态系统。用户可以使用现有的库，用 Python、Java 和 Node.js 等不同语言进行编程。此外，用户还可以轻松找到与 RisingWave 配合使用的工具，如 DBeaver。

有关 RisingWave 集成的完整列表，请参阅 集成。

学习曲线

Apache Flink 的学习曲线非常陡峭，因为它提供了更多底层控制的细节；相比之下，RisingWave 的学习曲线较为平缓，简单易用。

Apache Flink 的学习曲线非常陡峭。Flink 的编程模型基于更复杂的概念，如数据流、数据集和转换，可能需要一些时间才能掌握。Flink 的架构也更为复杂，有许多不同的组件需要手动配置和管理。

RisingWave 允许用户使用 SQL 与其进行交互（就像与 PostgreSQL 进行交互一样），从而简化了流处理过程。该平台只引入了一系列最基本的流处理概念，如 source、sink 和窗口。因此，RisingWave 是流处理新手用户或需要快速创建和部署流处理应用的用户的绝佳选择。

维护成本

Apache Flink 配置复杂，维护成本较高；而 RisingWave 广泛利用托管云服务，维护成本要低得多。

Apache Flink 的维护成本较高。由于其固有的架构复杂性，搭建和配置 Flink 集群需要大量的时间和精力。此外，由于 Apache Flink 采用的是计算-存储耦合架构，每当单个组件耗尽资源时，就必须重新配置集群。这意味着开发人员必须不断投入精力，来应对在线波动的工作负载。

另一方面，RisingWave 的维护成本要低得多。它旨在最大限度地减少所需的搭建和配置过程。用户可以使用开箱即用的开发工具在本地环境中轻松部署 RisingWave。此外，RisingWave 还广泛利用托管云服务来降低维护成本。云服务的内置弹性使得 RisingWave 能够以较低的成本进行扩展。

性能成本

为了达到目标性能，Apache Flink 的重型架构设计导致成本较高；而 RisingWave 解耦的架构则使其更具成本效益。

Apache Flink 旨在实现大规模数据的实时高性能和低延迟处理。然而，其计算-存储耦合的架构可能需要大量计算资源。计算或存储容量不足都会导致系统瓶颈。此外，Apache Flink 使用的 JVM 运行时也会在内存消耗方面带来巨大的开销。

相比之下，RisingWave 专注于在云上进行低成本的流处理，并且在大多数情况下，其成本效益比 Apache Flink 更好。以下几个因素有助于提高 RisingWave 的成本效益。

1. RisingWave 采用计算-存储解耦架构，允许系统根据工作负载为不同组件动态调配资源。

2. 作为流数据库，RisingWave 实现了物化视图的概念，通过维护和共享中间计算结果，为用户提供了在不同流处理管道中重复使用计算资源的机会。

3. RisingWave 基于 Rust 的实现以最小的计算和内存使用开销实现了高性能。

典型用例

Apache Flink 适用于全面的流式 ETL 和流式分析应用；RisingWave 不仅支持流式 ETL 和分析应用，还能利用其内置功能进行在线查询。

Apache Flink 非常适合全面的流式 ETL 任务和流式分析。它提供了一套强大的 API 和库，用于连接数据源、执行转换、窗口、复杂事件处理、有状态流处理以及将数据导出到外部系统。

不过，要建立这样一个管道并使用转换后的数据，您需要同时部署 Apache Flink 和下游在线查询数据库。

RisingWave 不仅提供流式 ETL 和流式分析，还可通过其内置的批处理查询引擎提供在线查询能力。通过定义物化视图，可以在 RisingWave 中直接收集和提供输入流的分析结果。其分布式前端集群支持横向扩展的高并发查询。

与 Flink SQL 相比，RisingWave 对 SQL 功能的支持更加全面。例如，RisingWave 支持流式执行完整的 TPC-H 查询，并能确保结果的正确性。对于时间窗口查询，Flink SQL 限制时间列必须是数据源的水位线列，而 RisingWave 没有这种限制。

如何进行选择？

那么，应该如何进行选择呢？这个问题的答案取决于具体用例和需求。

这两种解决方案在跨集群执行复杂的大规模流处理数据管道方面都很出色。最终的决定取决于开发人员的专业知识和高效管理解决方案所需的操作技能。

要轻松实现实时处理，RisingWave 是一个极佳的选择。它提供了一个简单、经济、基于 SQL 的解决方案，可以快速部署。因此，它非常适合需要实时处理功能的任何规模的数据驱动型企业。

另外，如果您需要能无缝集成到基于 JVM 的技术栈中的底层 API 访问，Apache Flink 是您的首选。Flink 非常适合拥有大型团队的企业，这些企业更倾向于根据自身特定需求定制解决方案。