私のLinkedInやMediumをフォローしている方は、最近私がApache Icebergについて頻繁に発信していることにお気付きかもしれません。ストリーム処理および管理システムであるRisingWaveの創設者として、次のような質問をよく受けます。
「最近Icebergについて多く投稿していますね。ストリーム処理から方向転換するのですか？」
はっきりお答えしましょう：いいえ、方向転換はしていません。むしろ注力を倍増しています。
現在私たちが目の当たりにしているのは、一時的なトレンドではありません。これはデータインフラストラクチャの構造的変化なのです。Icebergは大規模な分析データの保存におけるデファクトスタンダードになりつつあります。これは流行しているからではなく、独自のストレージフォーマットという現在の方法ではシステム間の拡張性に限界があるためです。
私は、現代的なデータベース（OLTPであれOLAPであれ）がいずれ全てIcebergをサポートするようになると考えています。これは単に「あったら便利」だからではなく、相互運用性やデータの長期的な所有管理に必要になるからです。ベンダーロックインは既に持続不可能になっています。
理由を説明しましょう。
独自フォーマット vs オープンテーブルフォーマット
従来のデータベース（PostgreSQL、MySQLなど）は独自のフォーマットでデータを保存しています。このフォーマットは特定のエンジンに最適化されており、他のシステムから直接アクセスすることはできません。TrinoのようなものがPostgresに接続できたとしても、それはPostgres自身を介してクエリを実行しているに過ぎず、直接ストレージを読み取っているわけではありません。つまり単なるクライアントに過ぎないのです。
自己完結型のシステムなら問題ありません。しかし、複数のシステム間で分析を行ったり、異なるワークロードに異なるエンジンを使ったりしようとすると壁に突き当たります。システム間でデータを移動するということはデータのコピーが必要になり、新たな問題が生じます：スキーマの不一致、同期の問題、古いデータ、競合する更新、そして明確な真実のソースが失われることなどです。
そしてロックインの問題もあります。一部のベンダーは最初は大きな割引を提供し、データがそのシステムにロックインされると価格を大幅に引き上げます。その時点では移動するのが高額または困難になり、ビジネスは身動きが取れなくなります。
Icebergはその解決策を提供します。
Icebergがストレージと計算を分離する
Apache Icebergは、データの保存方法とデータのクエリ方法を分離するテーブルフォーマットを定義しています。Iceberg統合を実装するエンジンならば、Spark、Flink、Trino、DuckDB、Snowflake、RisingWaveなど、どれでも直接Icebergデータを読み書きできます。
これはアーキテクチャを変革します。システム間でデータを移動する必要がなくなり、再処理やフォーマットの変換も不要になります。あるエンジンでデータを処理し、別のエンジンでクエリできます。
これにより、ストレージを特定の実行エンジンに結びつける必要もなくなります。ベンダーが提供する垂直統合されたスタックに縛られず、各ジョブに最適なツールを自由に選べます。一つのフォーマットで複数のエンジンが使えるのです。それはシンプルに機能します。
未来はデュアルフォーマット
私は、長期的にはほとんどのデータベースがデュアルフォーマットを採用するようになると考えています：
- 内部の性能に最適化された独自フォーマット — 低レイテンシアクセス、インメモリワークロード、トランザクション処理など
- 相互運用性のためのIcebergのようなオープンフォーマット — 長期的な保存、外部アクセス、システム間の共有
全てのデータベースは2つのストレージを持つことになる。
これは仮想の話ではありません。すでに現実に起こっています。SnowflakeはIcebergの読み書きをサポートしています。DatabricksもUnity Catalog経由でIcebergとの相互運用性を追加しました。RedshiftやBigQueryも同様の方向性を目指しています。
プロプライエタリ形式 vs オープンテーブル形式
従来のデータベース（PostgreSQL、MySQLなど）は、データをプロプライエタリなフォーマットで保存しています。このフォーマットは、それぞれのエンジンに特化されており、他のシステムから直接アクセスすることはできません。例えばTrinoのようなシステムがPostgresに接続できたとしても、それはPostgres自体を通してクエリを実行しているだけで、ストレージに直接アクセスしているわけではありません。つまり、単にクライアントとして動作しているだけです。
これは自己完結型のシステムであれば問題ありません。しかし、複数のシステムを横断して分析したり、ワークロードごとに異なるエンジンを利用したりしたい場合には、すぐに限界に達します。データをシステム間で移動させるには、データをコピーする必要がありますが、これにより新たな問題が発生します。例えば、スキーマの不一致、同期の問題、データの陳腐化、競合する更新、そして「信頼できる唯一の情報源（Single Source of Truth）」が不明瞭になる、といったことです。
さらに、ベンダーロックインの問題もあります。一部のベンダーは、最初に大幅な割引を提供し、その後データがロックインされたタイミングで料金を大幅に引き上げます。その時点で、他のシステムへの移行は費用や手間がかかりすぎ、企業は身動きが取れなくなります。
Icebergはこうした問題に対する解決策を提供します。
Icebergがストレージと計算処理を分離
Apache Icebergは、データの保存方法とデータのクエリ方法を分離したテーブルフォーマットを定義しています。Icebergと統合されたエンジン（Spark、Flink、Trino、DuckDB、Snowflake、RisingWaveなど）は、Iceberg形式のデータを直接読み書きすることができます。
これはアーキテクチャを一変させます。もはやシステム間でデータを移動する必要はなく、データ形式の再処理や変換も不要です。あるエンジンでデータを処理し、別のエンジンでそれをクエリすることが可能になります。
これにより、ストレージを単一の実行エンジンに結びつける必要もなくなります。垂直統合されたスタックを購入し、そのベンダーが提供するエンジンに縛られるのではなく、用途に応じて最適なツールを自由に選べます。一つのフォーマットで、複数のエンジンが使用可能。シンプルに機能します。
デュアルフォーマットが今後のスタンダードに
長期的には、ほとんどのデータベースが以下のようなデュアルフォーマットアーキテクチャを採用すると考えています。
- 内部パフォーマンス向けに最適化されたプロプライエタリフォーマット（低レイテンシアクセス、インメモリワークロード、トランザクション処理などに特化）。
- 長期保存、外部アクセス、システム間共有を可能にするための、Icebergのようなオープンフォーマット。
全てのデータベースが2種類のストレージを持つようになる。
これは単なる仮説ではありません。すでに現実になっています。SnowflakeはIcebergの読み書きをサポートしており、DatabricksはUnity Catalog経由でIcebergの相互運用性を追加しました。RedshiftやBigQueryも、この方向に向かっています。
プロプライエタリフォーマットが完全に無くなるわけではありません。OLTPエンジンのパフォーマンスを極限まで引き出したい場合、密接に統合されたフォーマットが必要です。しかし、データが一つのエンジン内だけで完結している場合、そのデータは再利用できません。共有も移行もできず、システム間パイプラインの構築も困難です。つまり、ロックインされてしまいます。
そこでIcebergの出番です。高速な内部フォーマットを必要に応じて使用し、外部からアクセスが必要な場合にはIceberg形式でデータのコピーを書き込むことができます。今後、ますます多くのシステムがIcebergをデフォルトの外部データ表現として扱うようになるでしょう。
RisingWaveで構築しているもの
RisingWave はもともと、PostgreSQL互換インターフェースを備えた分散ストリーミングデータベースとしてスタートしました。我々は、標準的なSQLを使ってリアルタイムデータの処理を簡単にすることを目指していました。しかし、多くのチームが求めていたのはストリーミングデータを単に処理するだけではなく、下流のさまざまなツールで再利用可能な形でデータを「格納すること」であるとすぐに気付きました。
そこで、Icebergをネイティブな出力先としてサポートしました。
実際のところ、これは次のような意味を持ちます：
- Kafka、Pulsar、あるいはDebeziumを通じたPostgresやMySQLなどのCDCソースからのリアルタイムデータを取り込み。
- 結合、フィルタ、集約など、あるいはさらに複雑な演算子を使用したPostgresスタイルのSQLによるデータ変換。
- Icebergテーブルに直接結果を書き込み、スキーマ進化、パーティショニング、コンパクションを内部的に処理。
- Icebergがネイティブにはサポートしていないにもかかわらず、等値削除（Equality Deletes）を用いて主キー制約を強制。
- Icebergテーブル上にマテリアライズドビューを構築し、テーブルを差分的に読み取り、ほぼリアルタイムで最新の状態に維持。
最終的な目標はシンプルです。ストリーミング処理とバッチ処理を、同じオープンテーブルフォーマットに収束させることです。
オープンプロトコルが最終的に勝つ
私たちは以前にも、次のような類似のパターンを目にしています。
- リレーショナルデータベースアクセスを標準化した JDBC や ODBC。
- オブジェクトストレージのユニバーサルインターフェースとなった S3。
- 多くのオープンソースデータベースの標準プロトコルとなった PostgreSQLのワイヤプロトコル。
現在、Icebergがテーブルフォーマットに対して同じことを行っています。
オープンプロトコルが勝つ理由は、それが摩擦を低減するからです。オープンプロトコルはユーザーにコントロールを与え、ベンダーがロックインに依存することなく、性能や機能で競争することを促します。また、ストレージフォーマットがボトルネックになる心配をせずに、複数のコンポーネントからシステムを構成することも容易になります。
もしあなたのシステムがオープンフォーマットをサポートしていなければ、それは将来的に安全（Future-proof）とは言えません。
まとめ
冒頭の問いへの答えに戻りますが、私はストリーム処理から離れるつもりは全くありません。
私が目指しているのは、データが別々のサイロに閉じ込められることなく、自由にエンジンやシステム、ツールの間を移動できる未来です。
その未来は、Apache Icebergの上に築かれます。