ストリーミングとバッチの統合エンジンがついに実現
RisingWave v2.8 は、DataFusion 搭載エンジンの追加により Spark や Trino なしで Iceberg への直接クエリを可能にし、ストリーミングとバッチを真に統合。アーキテクチャを劇的に簡素化します。
これは単なる利便性の向上ではありません。ストリーミングとバッチを一つのエンジンに統合することで、両方のワークロードで一貫した結果が得られ、アーキテクチャを大幅に簡素化できます。データのバックフィルやレイクハウスでのアドホックな分析など、RisingWave がこれらすべてをネイティブに処理できるようになりました。
DataFusion による Iceberg テーブルへの直接クエリ
RisingWave v2.8 では、バッチ処理用のネイティブな DataFusion ベース of クエリエンジンが導入されました。これにより、Apache Iceberg テーブルに保存されたデータを、標準的な SQL を使用して RisingWave から直接クエリできます。
主なメリットは以下の通りです：
- 統合エンジン: レイクハウスのデータをクエリするために外部のバッチエンジンを用意する必要がありません。
- 高いパフォーマンス: DataFusion のベクトル化実行（vectorized execution）を活用し、高速なバッチクエリを実現します。
- シームレスな統合: Iceberg テーブルを、あたかも RisingWave ネイティブのテーブルであるかのようにクエリできます。
Snapshot Backfill がデフォルトに
データのバックフィルは、あらゆるストリーミングワークフローにおいて重要な要素です。v2.8 では、すべての新しい materialized view に対して Snapshot Backfill がデフォルトのメカズムになりました。このアプローチは、特に大規模なデータセットにおいて、従来の方法よりも大幅に高速でリソース効率に優れています。
Snapshot backfill は、アップストリームテーブルの一貫したスナップショットを読み取った後、増分変更に追いつくことで動作します。これにより、ソースデータベースへの負荷が軽減され、materialized view が短時間で利用可能になります。
ジョブごとの個別設定：他のパイプラインに影響を与えずチューニング
パワーユーザーから最も要望の多かった機能の一つが、個々のストリーミングジョブをチューニングする機能です。v2.8 では、並列度（parallelism）、メモリ制限、ステートバックエンドの設定などの特定の構成を、ジョブごとに独立して設定できるようになりました。
以前は、多くの設定がグローバルまたはクラスター全体に適用されていました。今後は、より多くのリソースや特定のチューニングパラメータを必要とする優先度の高いパイプラインがある場合、クラスターの他の部分に影響を与えることなく適用できます。これにより、ストリーミングワークロードの分離と制御が大幅に向上します。
Iceberg v3 Delete Vectors と Schema Evolution への対応
Apache Iceberg エコシステムとの統合をさらに深めています。v2.8 では、Iceberg の 2 つの主要機能である Delete Vectors と Schema Evolution のサポートが追加されました。
パイプラインの再構築なしでの Schema Evolution
RisingWave は、Iceberg テーブルのスキーマ変更（カラムの追加や削除など）を、ストリーミングパイプラインを削除して再作成することなく処理できるようになりました。これにより、データモデルが進化しても、長期間実行されるジョブのメンテナンスが非常に容易になります。
Iceberg v3 Delete Vectors
Iceberg v3 Delete Vectors のサポートにより、更新や削除が頻繁に行われるテーブルでのリードヘビーなワークロードのパフォーマンスが向上します。Delete vectors を使用することで、RisingWave はスキャン中に削除された行をより効率的にスキップでき、クエリ時間の短縮につながります。
その他の Iceberg 関連の改善
- Partition Evolution: テーブルのパーティショニングスキームの変更に対する処理を改善しました。
- メタデータ管理: Iceberg メタデータファイルの追跡と管理の効率を向上させました。
FAQ
RisingWave v2.8 の DataFusion エンジンとは何ですか？
RisingWave に統合されたネイティブのバッチクエリエンジンで、Apache Iceberg などの外部データレイクに対して高性能な SQL クエリを実行できるようにするものです。
Snapshot backfill のために何か変更が必要ですか？
いいえ、すべての新しい materialized view でデフォルトになります。既存のビューは、再作成されない限り、現在の backfill 方法を引き続き使用します。
ダウンタイムなしで v2.7 から v2.8 にアップグレードできますか？
はい、RisingWave はローリングアップグレードをサポートしています。具体的な手順については、アップグレードガイドを参照してください。
ジョブごとの個別設定はどのように機能しますか？
materialized view や sink を作成する前に SET コマンドを使用するか、CREATE 文の中でジョブ固有のパラメータを指定することで設定できます。
結論
RisingWave v2.8 は、ストリーミングとバッチ処理の両方に対応する統合された高性能エンジンを提供するという私たちのミッションにおける大きな一歩です。DataFusion クエリエンジンの追加、高速なバックフィル、そしてジョブ構成のよりきめ細かな制御により、RisingWave はこれまで以上に要求の厳しいデータワークロードを処理できるようになりました。
また、AI やベクトル検索の可能性を広げ続け、より多くの embedding ワークロードをストリーミングエンジンに取り込んでいます。
本リリースには、RisingWave コミュニティからの 460 以上のコミットが含まれています。完全な変更履歴については、GitHub の v2.8.0 リリースノートをご覧ください。
v2.8 を試してみませんか？ RisingWave は 5 分で使い始めることができます。クイックスタート →
質問がある場合や、他の stream processing 開発者とつながりたい場合は、Slack コミュニティにご参加ください。