Databricks、Apache Iceberg v3 GA と Open Sharing、Unity Catalog の統合ガバナンスを発表

Databricks は 2026年5月28日、Apache Iceberg に関する公式ブログ記事を公開しました。記事では Iceberg v3、Managed Iceberg、Foreign Iceberg が GA になったこと、Unity Catalog を Iceberg catalog として使う際の open APIs、catalog federation、cross-engine access control、zero-copy secure sharing、AI-driven optimization が説明されています。

要点

• Iceberg v3、Managed Iceberg、Foreign Iceberg が GA として位置づけられた
• Unity Catalog を、interoperable かつ production-ready な Iceberg catalog として訴求している
• Open APIs、catalog federation、cross-engine access control、zero-copy secure sharing が主要テーマ
• Iceberg v4 と Delta 5.0 が unified metadata structure へ向かう見通しも示された
• Open table format を採用する data platform team は、governance と相互運用性をセットで確認したい

今回のブログ記事で語られていること

今回の記事は、Iceberg を単なる table format の選択肢としてではなく、enterprise data platform の governance boundary として扱っています。Iceberg は複数 engine から読み書きできることが強みですが、本番運用では「誰がどの engine からどの table に触れるのか」「policy をどこで統一するのか」「sharing と audit をどう扱うのか」が問題になります。

Databricks はこの論点に対して、Unity Catalog を中心に据えています。Managed Iceberg は Databricks 側で管理する Iceberg table の運用を進める方向、Foreign Iceberg は外部 catalog や既存 Iceberg 資産との接続を意識した方向です。どちらも、既存の data lake / lakehouse 資産を一気に置き換えるのではなく、相互運用しながら統制をそろえるための選択肢として読めます。

Zero-copy secure sharing も重要です。データをコピーして配るほど、鮮度、権限、削除、監査の問題が増えます。Iceberg と catalog governance を組み合わせて共有できるなら、data product や partner sharing の設計が変わります。一方で、cross-engine access control は便利な反面、各 engine の権限モデルや実行経路を理解しないと、期待と実際の enforcement がずれる可能性があります。

Iceberg v4 と Delta 5.0 が unified metadata structure に向かうという見通しは、長期的には「interoperability か performance / governance か」という二択を弱める方向です。ただし、将来計画として読むべき部分と、いま GA として評価できる部分は分けて扱う必要があります。

対象になりそうなユーザー・チーム

• Iceberg table を本番運用している data platform team
• Databricks と他 engine を併用する analytics / ML platform team
• Unity Catalog を enterprise governance の中心に置いている組織
• Delta / Iceberg / open table format の移行戦略を検討している architects

押さえておきたいポイント

Iceberg 採用で見るべきなのは format だけではありません。Catalog、access control、sharing、lineage、optimization、engine compatibility をまとめて評価する必要があります。特に複数 engine で同じ table を使う場合、write path、schema evolution、metadata refresh、permission enforcement を実データで検証してください。

また、GA と書かれた機能でも、自社の cloud、region、workspace configuration、既存 catalog との組み合わせで利用条件が変わることがあります。公式ブログの全体像を読んだ後は、docs 側で具体的な supported configuration を確認するのが安全です。

今すぐ対応が必要か

Iceberg をすでに採用しているチーム、または Delta と Iceberg の併用を検討しているチームは確認すべき発表です。特に、Unity Catalog を中心に cross-engine governance を設計している場合は、Managed Iceberg と Foreign Iceberg の違い、sharing model、権限の効き方を検証項目に入れる必要があります。

結局、このブログ記事をどう読むべきか

今回の記事は、Databricks が Iceberg を open interoperability と enterprise governance の両方から取り込もうとしていることを示します。Format のニュースとしてだけでなく、catalog と governance の設計判断に関わる発表として読むべき内容です。