Snowflake、外部query engineからのIceberg tables書き込みをGA

Snowflake は 2026年5月26日付の Recent feature update として、Snowflake-managed Apache Iceberg tables を外部 query engine から書き込む機能が General availability になったと発表しました。Snowflake Horizon Catalog の単一 endpoint と Snowflake の既存 users / roles / policies / authentication を使い、Iceberg REST protocol をサポートする外部エンジンから Snowflake-managed Iceberg v2 / v3 tables を読み書きできるようになります。

要点

• Snowflake-managed Apache Iceberg tables への外部 query engine からの write support が GA になった
• Apache Spark など、Iceberg REST protocol をサポートする外部エンジンから read / write できる
• Snowflake Horizon Catalog の単一 endpoint と既存の Snowflake users、roles、policies、authentication を利用する
• 外部エンジン接続の認証 option として、OpenID Connect (OIDC) による Workload Identity Federation (WIF) も追加された
• Lakehouse / open table format を使うチームでは、Snowflake 管理 table と外部 compute の役割分担を再設計する候補になる

今回のリリースノートで語られていること

Snowflake の 2026年5月26日 feature update は、Snowflake-managed Apache Iceberg tables に対する外部 query engine からの write support が General availability になったことを案内しています。対象は Snowflake-managed Iceberg v2 / v3 tables で、外部 query engine が open Iceberg REST protocol をサポートしていれば、Snowflake Horizon Catalog 経由で読み書きできます。Snowflake は例として Apache Spark を挙げています。重要なのは、外部 engine から直接 table を扱う場合でも、単一の Horizon Catalog endpoint と Snowflake の users、roles、policies、authentication を使う構成として説明されている点です。

これは、Iceberg を「Snowflake の外にある open table format」としてだけ使うのではなく、Snowflake が管理する Iceberg table を、外部 compute と Snowflake governance の両方から扱う方向の更新です。Spark などの既存処理基盤を持つチームにとっては、重い変換や既存 job を外部 engine に残しながら、catalog、policy、authentication、table 管理を Snowflake 側へ寄せる選択肢になります。逆に、すべての処理を Snowflake compute に移す前提ではないため、lakehouse / data platform の設計に柔軟性が出ます。

同時に、write support が GA になると、運用上の確認点も増えます。外部 engine からの書き込みは、読み取り専用連携よりも table consistency、concurrency、schema evolution、partition / file layout、rollback、監査、権限境界に強く関わります。Snowflake-managed table である以上、Snowflake 側の governance と外部 compute 側の job control が矛盾しないようにする必要があります。たとえば Spark job がどの identity で Horizon Catalog に接続し、どの role / policy が適用され、失敗時にどのログを見るのかを運用手順として決める必要があります。

今回の update は、外部 engine 接続の authentication option として Workload Identity Federation (WIF) with OpenID Connect (OIDC) も追加しています。これは long-lived secret を置くより、workload identity に基づいて認証を組む方向に近い更新です。外部 compute から Snowflake-managed Iceberg tables に書き込む場合、credential 管理は大きなリスク点になるため、WIF / OIDC の選択肢は security / platform team にとって重要です。

Snowflake は 5月7日にも Apache Iceberg version 3 support GA を Recent feature updates に出していました。今回の 5月26日更新は、それに続いて「Iceberg table を外部 engine と Snowflake governance の間でどう使うか」をより実務寄りに進めるものです。Iceberg を採用するチームは、format の互換性だけでなく、catalog、access control、write path、observability を一体で設計する必要があります。

対象になりそうなチーム

• Spark などの外部 compute と Snowflake-managed Iceberg tables を併用したい data platform team
• Iceberg REST catalog、Horizon Catalog、Snowflake governance の役割分担を設計する architecture team
• OIDC / Workload Identity Federation を使った workload authentication を管理する security / platform operations team

実務で確認したいポイント

まず、どの external query engine から write するのか、その engine が Iceberg REST protocol をどの範囲でサポートしているのかを確認します。次に、Snowflake 側の role、policy、authentication と、外部 engine 側の job identity、deployment environment、retry / failure behavior を突き合わせる必要があります。

本番採用前には、schema evolution、concurrent writes、failed job の cleanup、file compaction、rollback、audit log、cost attribution を検証してください。特に複数 engine から同じ table に write する場合は、所有者と変更 window を明確にしないと、open table format の利点より運用複雑性が上回る可能性があります。

結局、この更新をどう見るべきか

Snowflake-managed Iceberg tables への外部 engine write support GA は、Snowflake と外部 lakehouse compute を組み合わせたい組織にとって重要な更新です。Snowflake を governance / catalog の中心に置きつつ、Spark などの既存 compute を使い続ける設計が取りやすくなります。ただし、write path を開く更新なので、権限、identity、失敗時の復旧、監査を設計してから段階的に広げるべきです。