Snowflake×Icebergを採用すべきか迷った時に読む記事

結論

以下の条件に当てはまれば、Icebergの採用を検討すべきです。

1. データ量がペタバイトを超える
2. 社内でSnowflake以外のデータ活用製品（Databricks、Redshiftなど）も多く利用している
3. 同一のデータを使う関連グループ・企業が多く存在する

Icebergの採用は、特に巨大企業においてメリットが大きいです。
逆に上記の条件に1つも当てはまらない場合は、採用を見送るのがよいでしょう。

Icebergとは何に代わるものなのか？

Icebergは、Snowflakeのテーブルを置き換えることができます。
Icebergは完全にSnowflakeから独立した技術であり、Snowflakeの機能ではないことに注意が必要です。

最近Snowflakeが別のツールで作成したIcebergテーブルを、読めるようになっただけと捉えるのが1番実態に近いと思います。（※特定の条件下では書き込みできたりもしますが）

なぜIcebergを採用すべきなのか？

ペタバイト級のデータ量がある場合に採用するのはなぜか？

Icebergを採用することで、将来的なデータ基盤の移行時に発生するコストを削減できます。
多くの巨大企業は長い歴史の中で、様々なデータ活用製品を採用してきました。
普通は企業の寿命より、データ製品の寿命の方が圧倒的に短いです。Snowflakeもその中の1つに過ぎません。10年後には別の製品に移行する可能性も十分にあります。そのような性質から特定のデータ製品に依存しすぎることは危険です。莫大な移行コストがかかり移行がなかなか完了しないということになりかねません。

なぜSnowflakeの標準的なテーブルを採用するとデータ基盤移行にコストがかかるのか？

Snowflakeの標準的なテーブルは、Snowflake独自のファイル形式で保存されているからです。他の製品との互換性がありません。SnowflakeにおけるUsersテーブルは、「users.csv」「users.xlsx」のようなイメージで例えると「users.snowflake」のような形式で保存されていると考えると理解しやすいかもしれません（※厳密には異なりますが）。
重要なのは、このテーブルはSnowflake以外では読み書きできないということです。つまり、CSVファイルをCOPY INTOでUSERSテーブルに取り込む処理は、「users.snowflake」というSnowflake独自の形式のファイルを作成する処理に相当します。

一度Snowflake独自の形式でデータを保存してしまうと、将来新しいデータ製品に移行する際に、その製品が要求する形式に変換する必要が生じます。この変換処理には非常に高いコストがかかります。特にデータ量がペタバイトを超える場合は、事実上移行が不可能になる可能性も高まります。

一方、Icebergのようなオープンソースのテーブルフォーマットを使えば、データ形式の変換は不要になります。そのため、ほぼコストをかけずに移行することが可能になります。これが、ペタバイト規模のデータ基盤においてIcebergを採用する大きなメリットです。

Snowflake以外のデータ活用製品を多く利用している場合に採用するのはなぜか？

組織内でDatabricks、Redshift、BigQueryなど複数のデータ活用製品を利用している場合、Icebergを採用することでデータの相互運用性を大幅に向上させることができます。

Snowflake独自の形式でデータを保存すると、他のシステムとデータを共有する際に形式変換が必要になります。これは、データの一貫性を維持する上で大きな課題となります。

一方、Icebergは多くのデータ活用製品と互換性のあるオープンテーブルフォーマットです。クラウドストレージ（S3、Azure Blob、Google Cloud Storage）に直接保存されたIcebergテーブルは、様々なツールから直接アクセスできます。これにより、データの移動やコピーを最小限に抑え、コストと時間を節約することができます。

同一のデータを使う関連グループ・企業が多く存在する場合に採用するのはなぜか？

大企業や企業グループでは、複数の部門や関連会社が同じデータセットを利用することが一般的です。このような場合、Icebergの採用は以下のメリットをもたらします。

データガバナンスの向上

中央で管理されたIcebergテーブルを使用することで、データの一貫性と品質を維持しやすくなります。全ての部門が同じデータソースを参照するため、データの不一致や重複を削減できます。

コラボレーションの促進

異なるツールや環境を使用する部門間でも、Icebergテーブルを介してスムーズにデータを共有できます。これにより、部門間の連携が強化され、データに基づいた意思決定を促進することができます。

コスト削減

データの重複保存や転送が削減されるため、ストレージとネットワークのコストを削減できます。また、各部門がデータを個別に管理する必要がなくなり、運用コストも削減できます。

よくある質問

Polarisカタログとは何か？

PolarisはSnowflakeが発表したIcebergカタログです。Snowflakeとは完全に独立した技術だと考えると理解しやすくなります。

Icebergでは、テーブルをS3などのクラウドストレージ上に作成し、SnowflakeやDatabricksなど様々な製品から読み取ることができます。しかし、各製品が自由にファイルを作成・更新できるようにしてしまうと、データの一貫性など様々な問題が発生します。これを防ぐために、Icebergカタログと呼ばれるシステムコンポーネントが必要になります。

Icebergカタログには様々な種類がありますが、多くのベンダーの合意を得て開発が進められているのがPolarisです。Polarisはオープンソースソフトウェアであり、自社で運用することも可能です。自社運用が難しい場合は、Snowflakeが提供するPolarisのマネージドサービスを利用することもできます。

Parquet形式で格納したSnowflakeの外部テーブルとは何が違うのか？

IcebergテーブルとParquet形式の外部テーブルは似ていますが、いくつかの違いがあります。

1. クエリ速度: Icebergはオブジェクトストレージ上のファイル/フォルダの階層構造に依存しないため、S3などのスキャンにかかる時間を短縮できます。また、パーティショニングを後から変更できるなど、柔軟性も高くなっています。
2. タイムトラベルなどの機能: Icebergでは、タイムトラベル機能を利用して過去のデータにアクセスすることができます。外部テーブルの場合は、元のファイルを削除してしまうと復元できません。
3. Snowflake以外の製品からのアクセス: Icebergテーブルは、Snowflake以外のデータ製品からもデータの再登録なしにアクセスできます。

当初の「特定のデータ製品にロックインされないようにする」という目的を達成するためには、Icebergテーブルの方が適していると言えるでしょう。

SnowflakeにおけるIcebergテーブル作成時に指定するカタログを変えるとどうなるか？

Icebergテーブルを作成する際に、カタログとしてSnowflakeを指定すると、「Snowflakeが管理するIcebergテーブル」が作成されます。Snowflake Open Catalogなど、Snowflake以外のカタログを指定すると、「Snowflakeに依存しないIcebergテーブル」が作成されます。

それぞれのIcebergテーブルの特徴を比較した表を以下に示します。

機能	Snowflakeが管理するIcebergテーブル	Snowflakeに依存しないIcebergテーブル
読み取りアクセス	✔	✔
書き込みアクセス	✔	❌
Snowflakeプラットフォームのサポート	✔	❌
Snowflake Open Catalogとの統合	✔（Snowflake管理テーブルをSnowflake Open Catalogと同期可能）	✔（PolarisのテーブルをSnowflakeで照会可能）
Snowflake Iceberg Catalog SDKとの互換性	✔	✔
ライフサイクル管理	Snowflakeが管理	ユーザーが管理
クロスクラウド/クロスリージョンサポート	❌	✔（一部制限あり）

Snowflakeが管理するIcebergテーブルは、COPY INTOなどでデータを追加できますが、Snowflakeに依存しないIcebergテーブルは読み取り専用となります。

最も重要な違いはPolarisとの統合です。Snowflakeが管理するIcebergテーブルの場合、SnowflakeはテーブルのメタデータをPolarisに自動的に同期します。これは、Snowflake上のテーブルをDatabricksやRedshiftからもアクセスできるようにするための仕組みです。Snowflakeが中心となり、他の製品がそれに従う形になります。

一方、Snowflakeに依存しないIcebergテーブルの場合は、外部で作成されたIcebergテーブルをSnowflake、Databricks、Redshiftなどからアクセスできるようにします。

どちらのタイプのIcebergテーブルを選択すべきなのか？

現状では、Snowflakeをメインのデータプラットフォームとして利用している場合は、まずはSnowflakeが管理するIcebergテーブルから試し、徐々にSnowflakeに依存しないIcebergテーブルに移行していくことをおすすめします。

最終的にSnowflakeに依存しないIcebergテーブルを目指す理由は、Icebergを利用する目的が特定のデータ製品への依存を減らすことにあるからです。

ただし、Snowflakeに依存しないIcebergテーブルでは、データの取り込みにCOPY INTOを使用できず、AWS GlueやSparkなどで処理を書き直す必要があります。既にSnowflakeをメインとして利用している場合は、COPY INTOを用いた既存のデータ取り込みスクリプトが多数存在する可能性が高いため、まずはSnowflakeが管理するIcebergテーブルから始める方がスムーズに移行できるでしょう。

まとめ

Icebergは、データの相互運用性向上、将来のデータ基盤移行コスト削減、データガバナンス強化といった多くのメリットをもたらす、次世代のテーブルフォーマットです。特に、ペタバイト規模のデータを扱う大企業や、複数のデータ活用製品を利用している組織にとって、Icebergは魅力的な選択肢となります。

Icebergはまだ発展途上の技術ですが、その可能性は非常に大きく、今後のデータ基盤において重要な役割を果たしていくことが期待されます。ぜひ、本記事を参考に、Icebergの導入を検討してみてください。

PR

自社のデータ基盤でSnowflake×Apache Icebergを使う可能性に興味をお持ちの場合は「世界で一番Snowflakeに詳しい会社」を目指す RAKUDEJI株式会社 まで、ぜひ一度お問い合わせください！

Snowflake専門ならではの圧倒的な知識で、SnowflakeでIcebergを採用すべきなのか？ 採用すべきならばどう採用していくか？ などの疑問にお答えします。