RisingWave v2.4 发布！

右滑查看英文版 >>>

我们很高兴地宣布，RisingWave v2.4 现已正式发布！此次更新在性能分析、数据存储与 Sink 连接器等方面进行了优化与扩展，并新增多项 SQL 命令，全面增强实时数据处理能力。

欢迎继续阅读以了解 v2.4 中的一些重点功能。如需查看全部更新内容，请访问完整的发布说明^[1]。

运行时性能分析

现新增 EXPLAIN ANALYZE 命令来分析流处理作业的实际运行时性能。

查看流处理作业执行方式

新增的 DESCRIBE FRAGMENTS 命令支持深入了解流处理作业的物理执行方式。该工具有助于将分布式执行片段（包括片段 ID、Actor 分配和算子拓扑）可视化，从而让调试、调整并行度和优化流处理应用变得更加容易。

DESCRIBE FRAGMENTS 命令作用于正在运行的作业，它提供的洞察信息类似于 EXPLAIN (DISTSQL)，但包含了实时作业的映射关系。

更多详细信息和示例，请参阅DESCRIBE FRAGMENTS^[3]。

RisingWave v2.4 增强了与 Apache Iceberg 的集成，支持仅追加（Append-only）表。这意味着，只有在数据成功提交到 Iceberg 表之后，下游的流处理作业才能使用这些数据，例如基于它构建的物化视图或 Sink。这些下游作业将通过 RisingWave 的 Iceberg source 来消费数据。

该功能尤其适用于以下情况：当 Iceberg 是主要的数据湖存储时，希望通过直接的提交机制进行集成，从而让流式处理与数据湖的提交周期保持高度一致。

更多信息，请参阅仅追加表^[4]。

为进一步扩展数据汇（Sink）连接器的能力，RisingWave 现已支持使用 Pub/Sub 模型向 Redis Channel 发布消息。该功能有助于使用 Redis 强大的 Pub/Sub 机制，轻松实现实时通知、事件驱动架构或服务间通信。

您可以灵活地使用 channel 参数将消息发布到预定义的静态 Redis Channel。如果需要更动态的路由，则可以使用 channel_column 参数。通过 channel_column，流数据中指定列的值可以动态决定每条消息的目标 Redis Channel，从而更灵活地控制消息分发。

更多信息，请参阅 Sink 数据至 Redis^[5]。

RisingWave v2.4 提供了一种强大的方法来实现行级安全（Row-Level Security, RLS）。借助 GRANT 和 REVOKE，该方法巧妙地结合了逻辑视图和 RisingWave 的访问控制机制。

您可以创建包含特定过滤逻辑的逻辑视图。这些视图会预先过滤数据，限制了通过该视图可见的数据行。接着为特定用户或角色授予访问这些精心设计的视图的权限，而不是直接访问底层基表。这一策略确保用户只能根据视图的定义查询和查看他们被明确授权的数据，为实现数据隔离提供了灵活的方式。

更多信息，请参阅在 RisingWave 中实现行级安全^[6]。

从 v2.4 版本开始，RisingWave 原生支持在 Azure Blob Storage (Azblob) 上使用 Apache Iceberg Source 和 Sink 连接器。这一增强功能实现了与 Azure 的可扩展、持久且安全的对象存储的无缝集成，允许用户直接在 Azblob 上读写 Iceberg 表。

要将 RisingWave 与 Azure Blob Storage 连接，需要进行特定的参数配置，如存储路径和身份验证凭据。

有关这些参数及其设置的详细信息，请参阅在 Azure Blob Storage 上配置 Iceberg Source^[7]和在 Azure Blob Storage 上配置 Iceberg Sink^[8]。

在写入 Apache Iceberg 时，RisingWave 现支持 Exactly-Once（精确一次）交付语义。这确保了即使在发生重试或故障的情况下，每条数据记录都能被精确处理一次，从而消除数据损坏，确保数据分析的准确性。

该功能基于两阶段提交协议和 Iceberg 的幂等提交机制，保证了数据完整性且无重复。只需简单配置项即可启用该功能，帮助构建可靠的实时管道，但同时需要注意可能带来的性能开销，具体请参阅 Exactly-once delivery^[9]。

有关 Exactly-once 的更多背景知识，可参阅 不同数据系统中的“一致性”含义的区别 。

以上只是 RisingWave 2.4 版本新增的部分功能，如果您想了解本次更新的完整列表，请查看更详细的发布说明。

如果您想提前了解下个月的版本及其新功能，请访问 RisingWave GitHub repository^[10]。

<<< 左滑查看中文版

We’re thrilled to unveil RisingWave v2.4, packed with enhancements designed to elevate your real-time data processing capabilities. This release brings enhanced performance analysis, expanded data storage and sinking capabilities, new SQL commands, and much more.

Runtime profiling with EXPLAIN ANALYZE

You can now inspect the actual runtime performance of a streaming job using the new EXPLAIN ANALYZE command.

Unlike the traditional EXPLAIN, which only shows the query plan before execution, EXPLAIN ANALYZE provides runtime statistics—including output rates and buffer metrics—for running jobs such as materialized views, sinks, or indexes. It is enabled by default and helps pinpoint performance bottlenecks in complex streaming pipelines. 

Physical plans with DESCRIBE FRAGMENTS

Understand how a streaming job is physically executed with the new DESCRIBE FRAGMENTS command. This tool helps you visualize distributed execution fragments—including fragment IDs, actor assignments, and operator topology—making it easier to debug, tune parallelism, and optimize streaming applications.

DESCRIBE FRAGMENTS command works on existing running jobs and offers insights similar to EXPLAIN (DISTSQL), but with live job mappings.

RisingWave v2.4 enhances its integration with Apache Iceberg by introducing support for append-only tables. The key implication is that data written to these append-only tables becomes available to downstream streaming jobs (such as materialized views or sinks built upon them) only after it has been successfully committed to the Iceberg table. These downstream jobs will then consume data via RisingWave's Iceberg streaming source capabilities.

This option is particularly beneficial for use cases where Iceberg serves as the primary data lake storage, and you prefer a direct, commit-based integration, aligning streaming operations closely with data lake commit cycles.

Enhanced Redis sink: Pub/Sub messaging

Expanding its sink connector capabilities, RisingWave now supports publishing messages to Redis channels using the Pub/Sub model. This feature facilitates real-time notifications, event-driven architectures, or inter-service communication using Redis's robust Pub/Sub mechanism.

You have the flexibility to publish messages to a predefined, static Redis channel using the channel parameter. Alternatively, for more dynamic routing, you can use the channel_column parameter. With channel_column, the value from a specified column in your streaming data dynamically determines the target Redis channel for each message, offering greater control over message distribution.

RisingWave v2.4 provides a robust method to implement row-level security (RLS). This approach involves a powerful combination of logical views and RisingWave's access control mechanisms (using GRANT and REVOKE).

You can create logical views that embed specific filtering logic. These views essentially pre-filter the data, restricting the rows visible through that view. Subsequently, you grant specific users or roles permissions to access these carefully crafted views, rather than the underlying base tables. This strategy ensures that users can only query and see the data they are explicitly authorized for, based on the view's definition, providing a flexible way to enforce data segregation.

Starting with v2.4, RisingWave introduces native support for Apache Iceberg source and sink connectors on Azure Blob Storage (Azblob). This enhancement enables seamless integration with Azure’s scalable, durable, and secure object storage, allowing users to read from and write Iceberg tables directly on Azblob.

To connect RisingWave with Azure Blob Storage, specific configuration parameters are required—such as storage paths and authentication credentials. 

RisingWave now supports exactly-once delivery semantics when writing to Apache Iceberg. This ensures that each data record is processed once and only once, even in the event of retries or failures. This eliminates data corruption and ensures accurate analytics when writing to Iceberg.

Powered by a two-phase commit protocol and Iceberg’s idempotent commits, this feature guarantees data integrity without duplicates. Enable it with a simple configuration option to build reliable, real-time pipelines—while staying aware of potential performance trade-offs.