RisingWave v2.4 のハイライト｜イベントストリーム処理および管理プラットフォーム

私たちは、リアルタイムデータ処理の能力をさらに高める数々の機能強化を搭載した **RisingWave v2.4** を発表できることを大変嬉しく思います。このリリースでは、パフォーマンス分析機能の拡張、データストレージおよびシンクの強化、新しい SQL コマンドの追加など、多岐にわたる改善が含まれています。

本記事では、v2.4 における主要な新機能をいくつかご紹介します。全ての更新内容については、[リリースノート](https://docs.risingwave.com/changelog/release-notes)をご覧ください。

## `EXPLAIN ANALYZE` による実行時プロファイリング

新たに追加された `EXPLAIN ANALYZE` コマンドを用いることで、ストリーミングジョブの実行時パフォーマンスを可視化できるようになりました。

従来の `EXPLAIN` が実行前のクエリプランのみを表示するのに対し、`EXPLAIN ANALYZE` はマテリアライズドビュー、シンク、インデックスなどの実行中ジョブに対し、出力レートやバッファ使用量といった実行時統計を提供します。この機能はデフォルトで有効化されており、複雑なストリーミングパイプラインにおけるボトルネックの特定に役立ちます。

構文や取得できるパフォーマンス指標については、[EXPLAIN ANALYZE ドキュメント](https://docs.risingwave.com/sql/commands/sql-explain-analyze)をご参照ください。

## `DESCRIBE FRAGMENTS` による物理実行プランの可視化

`DESCRIBE FRAGMENTS` コマンドを使用すると、ストリーミングジョブがどのように物理的に分散実行されているかを詳細に確認できます。これにより、以下のような情報を把握可能です：

* フラグメント ID
* アクターの割り当て
* オペレーターのトポロジー

これらの情報により、並列処理のチューニング、ジョブのデバッグ、パフォーマンス最適化が容易になります。

このコマンドは実行中のジョブに対して使用でき、`EXPLAIN (DISTSQL)` に似たインサイトをライブ状態で提供します。

詳細は [DESCRIBE FRAGMENTS ドキュメント](https://docs.risingwave.com/sql/commands/sql-describe#describe-fragments) をご参照ください。

## Iceberg テーブルエンジンによる **append-only テーブル** のサポート

v2.4 では Apache Iceberg との連携がさらに強化され、**append-only テーブル** がサポートされました。

この機能により、append-only テーブルに書き込まれたデータは Iceberg テーブルへのコミット完了後にのみ、マテリアライズドビューやシンクなどの下流ストリーミングジョブから利用可能になります。これらのジョブは RisingWave の Iceberg ストリーミングソース機能を通じてデータを取り込みます。

Iceberg を主要なデータレイクストレージとして使用し、コミット単位での整合性を重視するユースケースに最適です。

詳細は [Append-only tables ドキュメント](https://docs.risingwave.com/store/iceberg-table-engine#append-only-tables) をご覧ください。

## Redis シンクの強化：**Pub/Sub メッセージング**

RisingWave は Redis との統合において、Pub/Sub モデルによるチャンネルへのメッセージパブリッシュをサポートしました。

この機能により、リアルタイム通知、イベント駆動アーキテクチャ、サービス間の非同期通信が容易に実現できます。2 種類のチャンネル指定方法が提供されています：

* `channel` パラメータ：静的な Redis チャンネルへ送信
* `channel_column` パラメータ：ストリーミングデータ中の列値によって送信先チャンネルを動的に決定

これにより、メッセージ配信の柔軟性と制御性が大きく向上します。

詳しくは [Redis 連携ガイド](https://docs.risingwave.com/integrations/destinations/redis#pub%2Fsub-messaging) を参照してください。

## **Row-Level Security（RLS）** の導入

RisingWave v2.4 は、**行レベルセキュリティ（RLS）** を実現するための強力な仕組みを提供します。これは、以下のような構成で実装されます：

1. 特定のフィルタ条件を組み込んだ **論理ビュー** を作成
2. ビュー単位で `GRANT` / `REVOKE` を使用しアクセス権を管理
3. ユーザーは許可されたビュー経由でのみデータにアクセス可能

この方法により、ユーザーごとに可視範囲を厳密に制御でき、柔軟かつ強固なデータ分離が可能になります。

実装手順については [Row-Level Security ガイド](https://docs.risingwave.com/operate/row-level-security) をご参照ください。

## Azure Blob Storage での Iceberg ソース / シンクのサポート

v2.4 では、**Azure Blob Storage（Azblob）上での Iceberg ソースおよびシンク接続** がネイティブにサポートされました。

これにより、Azure のスケーラブルかつセキュアなオブジェクトストレージとシームレスに統合でき、Iceberg テーブルの読み書きを直接 Azblob 上で行うことが可能になります。

設定には、ストレージパスや認証情報など、いくつかのパラメータが必要です。設定方法の詳細は以下のドキュメントをご参照ください：

* [Iceberg ソース設定（Azure 用）](https://docs.risingwave.com/ingestion/sources/iceberg-config#storage-configuration-azure-blob)
* [Iceberg シンク設定（Azure 用）](https://docs.risingwave.com/integrations/destinations/apache-iceberg#use-azure-blob-as-object-storage-for-iceberg)

## Iceberg シンクにおける **Exactly Once 配信**

RisingWave は Iceberg への書き込みに対し、**Exactly Once 配信セマンティクス** をサポートするようになりました。

これにより、リトライや障害発生時でも **重複なく、正確に一度だけ** データが処理されることが保証されます。データ破損のリスクがなくなり、分析結果の正確性も確保されます。

この機能は、2フェーズコミットプロトコルと Iceberg の冪等コミット機構によって実現されています。設定もシンプルで、リアルタイム性と信頼性を両立したパイプライン構築が可能です（※パフォーマンスとのトレードオフには注意が必要です）。

詳細は [Exactly-once delivery ドキュメント](https://docs.risingwave.com/integrations/destinations/apache-iceberg#exactly-once-delivery) をご覧ください。

## まとめ

以上が、RisingWave v2.4 における主要な新機能の概要です。その他、ソース・シンクコネクタに関する細かな改善なども含めたすべての更新内容は、[リリースノート](https://docs.risingwave.com/changelog/release-notes) にてご確認いただけます。

今後も新機能の追加・改善は継続される予定です。ぜひ来月のアップデートもお見逃しなく。

* 最新の開発状況は [RisingWave GitHub](https://github.com/risingwavelabs/risingwave) をチェック
* 月刊ニュースレターの購読は [こちら](https://www.risingwave.com/risingwave-cloud/)
* [Twitter](http://go.risingwave.com/twitter)、[LinkedIn](http://go.risingwave.com/linkedin) フォローもぜひ
* エンジニアや世界中のユーザーと交流したい方は [Slack コミュニティ](http://go.risingwave.com/slack) にご参加ください