はじめに
Apache Iceberg を採用する多くのチームは、「Iceberg への書き込み」を単なるコネクタの問題として捉えがちです。つまり、ストリーミングエンジンを選び、シンク（sink）を設定すれば完了だと考えてしまいます。しかし実際には、本番環境の Iceberg インジェスチョン（ingestion）パイプラインは、より広範な課題を解決する必要があります。
- タスクの再起動やコーディネーターのフェイルオーバーを乗り越える Exactly-once なコミット。
- データの鮮度を保つのに十分な速さでありつつ、テーブルが小さなファイル（small files）で溢れない程度の適切なコミット間隔。
- スケジュールされたコンパクション（compaction）、スナップショットの有効期限切れ処理、および孤立したファイル（orphan files）のクリーンアップ。
- CDC（Change Data Capture）ワークロードのための Upsert および Delete セマンティクス。
- データレイクに蓄積されたデータへのクエリパス。
現在、Iceberg へのインジェスチョンには Apache Flink が主流ですが、RisingWave はこれらの運用上の課題を簡素化するために設計された代替手段として浮上しています。本記事では、Flink と RisingWave が Iceberg へのインジェスチョンをどのように処理するのか、そしてなぜ本番環境のワークロードにおいて RisingWave がより優れた選択肢となることが多いのかを比較します。
Iceberg インジェスチョンの複雑さ
Iceberg への書き込みは、Kafka トピックや標準的な SQL データベースへの書き込みとは異なります。Iceberg は、楽観的並行性制御（optimistic concurrency）とマニフェストファイルの管理に依存するテーブルフォーマットです。すべての書き込みには以下のステップが含まれます。
- Data Writing: Parquet または Avro ファイルをオブジェクトストレージに書き込む。
- Metadata Creation: 新しいマニフェストファイルとマニフェストリストを生成する。
- Commit: Iceberg カタログ内の現在のスナップショットを更新する。
複数のライターやメンテナンスジョブ（コンパクションなど）が同時にコミットしようとすると、競合が発生します。また、ライターがストリームの途中で失敗すると、どのスナップショットにも含まれない「孤立したファイル」が残り、ストレージ容量を圧迫する原因となります。
Apache Flink：強力だが手動操作が必要な選択肢
Flink の Iceberg コネクタは成熟しており、高度な設定が可能です。2フェーズコミットプロトコルを使用して、Flink のチェックポイントが完了した後にのみデータが Iceberg で可視化されることを保証します。しかし、この強力な機能には大きな運用オーバーヘッドが伴います。
1. 小ファイル問題（The Small File Problem）
Flink はチェックポイントごとにデータを書き込みます。データの鮮度を高めるためにチェックポイントの間隔を1分に設定すると、Flink は1分ごとに新しいファイルを作成します。1日を通すと数千もの小さなファイルが生成され、クエリのパフォーマンスが著しく低下します。これを解決するために、Flink ユーザーは以下のいずれかを行う必要があります。
- チェックポイントの間隔を長くする（データの鮮度が低下する）。
- インジェスチョン後にコンパクションを実行するための、別の Flink ジョブや Spark ジョブを運用する。
2. メンテナンスのオーバーヘッド
Iceberg テーブルには定期的なメンテナンスが必要です。小さなファイルのコンパクション、古いスナップショットの削除、孤立したファイルの削除などです。Flink エコシステムでは、これらは通常、外部の cron ジョブや別の Spark/Flink アプリケーションとして処理されます。つまり、インジェスチョンジョブだけでなく、一連のメンテナンス用タスクも管理しなければならないことを意味します。
3. Upsert の複雑さ
Flink で CDC データを扱うには、Iceberg の v2 テーブルフォーマット（equality deletes または position deletes）を使用する必要があります。パフォーマンスを維持しながらこれらを正しく処理するように Flink を設定するには、Flink の状態管理（state management）と Iceberg 内部の削除メカニズムの両方に関する深い専門知識が必要です。
RisingWave：インジェスチョンへのデータベース的アプローチ
RisingWave は異なるアプローチを取ります。Iceberg を単なるシンクとして扱うのではなく、管理されたストレージターゲットとして扱います。RisingWave はストリーミングデータベースであるため、Iceberg のライフサイクルの複雑さを内部で処理できるのです。
1. 統合されたインジェスチョンとコンパクション
RisingWave の Iceberg シンクは、小ファイル問題を標準機能で解決するように設計されています。データをバッファリングし、設定可能なしきい値に基づいて Iceberg にコミットすることで、ファイルが適切なサイズになってからコミットされるようにします。さらに重要なことに、RisingWave はメンテナンス用タスクを自動的にトリガーするように設定できるため、外部のオーケストレーションの必要性を減らすことができます。
2. 簡素化された SQL 構文
RisingWave では、Iceberg インジェスチョンパイプラインの作成は、シンクを作成するのと同じくらい簡単です。
CREATE SINK orders_iceberg FROM orders
WITH (
connector = 'iceberg',
catalog.type = 'storage',
warehouse.path = 's3a://my-bucket/iceberg/',
catalog.name = 'demo',
database.name = 'public',
table.name = 'orders'
);
複雑な JAR ファイルの依存関係を管理したり、Java/Python コードを書いたりする必要はありません。SQL が書ければ、本番グレードの Iceberg パイプラインを構築できます。
3. ネイティブな CDC サポート
RisingWave は CDC のために構築されました。RisingWave を介して Postgres や MySQL から Iceberg にデータをストリーミングすると、エンジンはアップストリームの削除や更新を Iceberg v2 の削除ファイルに自動的にマッピングします。ソースデータベースの一貫した反映がレイクハウス内で行われるよう、必要な状態を維持します。
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY,
status VARCHAR,
updated_at TIMESTAMP
) WITH (
connector = 'postgres-cdc',
hostname = 'db-host',
...
);
比較のまとめ
| 機能 | Apache Flink | RisingWave |
|---|---|---|
| セットアップ | 複雑 (Java/Python + JARs) | シンプル (純粋な SQL) |
| メンテナンス | 手動/外部 (Spark/Flink) | 統合/自動化 |
| 小ファイル問題 | 外部でのコンパクションが必要 | シンクの設定で管理可能 |
| CDC/Upserts | 手動での v2 設定が必要 | ネイティブかつ自動処理 |
| 状態管理 | 重い Flink チェックポイント | 軽量かつ増分（incremental） |
なぜ Iceberg インジェスチョンにおいて RisingWave が勝るのか
多くのチームが Iceberg インジェスチョンのために Flink から RisingWave へ移行している主な理由は、**運用のシンプルさ（operational simplicity）**です。
Flink ベースのアーキテクチャでは、データのライフサイクル全体に対して責任を負います。インジェスチョンジョブ、コンパクションジョブ、スナップショット削除ジョブを監視しなければなりません。これらのいずれかが失敗すると、レイクハウスは不整合に陥るか、パフォーマンスが低下します。
RisingWave では、エンジンがこれらの懸念事項を処理します。ユーザーは「あるべき状態（シンク）」を定義するだけで、RisingWave がデータが正しくコミットされ、ファイルが管理され、テーブルが健全に保たれることを保証します。これにより、データエンジニアはデータの移動に必要な「配管作業」ではなく、データそのものに集中できるようになります。
結論
Apache Iceberg はオープンなレイクハウスの標準になりつつありますが、Iceberg プロジェクトの成功はインジェスチョンパイプラインの信頼性に依存します。Flink は強力なツールですが、大規模に運用するには多大な手動の努力が必要です。
RisingWave は Iceberg インジェスチョンに対してデータベースネイティブな体験を提供し、コード量と運用オーバーヘッドを大幅に削減しながら、より優れたパフォーマンスを実現します。レイクハウス用のストリーミングエンジンを選択する際は、運用1日目だけでなく、400日目にもそのパイプラインが信頼できるかどうかで判断してください。RisingWave は、Iceberg インジェスチョンを本番用データベースの機能として扱うエンジンです。だからこそ、RisingWave が正しい選択なのです。