Snowflake Summit Deep Dive: Apache Iceberg

Snowflake Summit 2026 Recap!! - Making AI Real For BUSINESS - 2026.6.22 登壇資料になります。
https://techplay.jp/event/996200

1. Snowflake Summit Deep Dive: Apache Iceberg 2026.6.22 Snowflake Summit 2026 Recap!! - Making AI Real For BUSINESS -2026.6.22 是枝 達也
2. © 2026 Snowflake Inc. All Rights Reserved 自己紹介 名前 是枝 達也 / Tatsuya Koreeda 居住地 兵庫県 神戸市 趣味 バイオインフォマティクス研究 活動 ・Snowflake UG リーダー（WEST / HCLS） ・Snowflake Datasuperhero 2026
3. Snowflake Summit 2026 Iceberg 関連発表まとめ
4. ACT 3 : Open and InteroperableでIcebergが⼤きく紹介される
5. Iceberg 関連発表まとめ 発表 ステータス ポイント Iceberg v3 サポート GA variant / row lineage / deletion vectors 等の新機能 Snowflake Storage GA $23.3/TB/⽉のフルマネージド Iceberg ストレージ Horizon + Polaris GA / PrPr 外部エンジン Read GA、Write PrPr。Polaris が ASF TLP に Catalog-linked DB GA Glue / Unity Catalog / OneLake をネイティブ統合 Scan Plan / Sharing PrPr〜GA Open Sharing / pg_lake / SAP‧Salesforce 連携 参考: 20260604_Summit26JapanWrapUp_share.PDF など
6. Iceberg v3 が刺さるユースケース ユースケース v3 で何が変わるか CDC / 差分同期パイプライン 基幹や SaaS の変更データを DWH に反映したい Row Lineage で変更⾏を⾃動追跡。 フルスキャンによる差分検出が不要になる JSON / ログなど半構造化データの蓄積 API レスポンスやイベントログをそのまま貯めたい Variant 型でスキーマレス取込。 shredding により列指向と同等の読取性能 ⽇次バッチの洗い替え‧マスタ更新 MERGE / UPDATE が⼤量に⾛る ETL Deletion Vectors で既存ファイルの書換えが不要。 MERGE 処理が⼤幅に⾼速化 物件‧店舗など位置情報を使った空間分析 エリア検索やジオフェンスを掛けたい Geography / Geometry 型で空間クエリを Iceberg 上でネイティブ実⾏ => S3上の巨大テーブルに対して、更新・削除・差分更新を現実的にやるための進化
7. ポイント ‧Iceberg ファイルを Snowflake マネージドストレージに配置 ‧外部 Spark / Trino からは標準 Iceberg テーブルとして読取可能 ‧コンパクション‧スナップショット管理を⾃動化 ‧SnowpipeやSnowpipe Streaming利用可能 ・ストレージコストは通常のストレージプライシングに従う こんなとき ‧S3 / Azure の IAM‧暗号化を⾃前管理したくない ‧Icebergをフルマネージドで運⽤したい Snowflake Storage for Iceberg Tables CREATE ICEBERG TABLE my_iceberg_table_defaults (col1 int) CATALOG = SNOWFLAKE EXTERNAL_VOLUME = SNOWFLAKE_MANAGED; EXTERNAL_VOLUME に SNOWFLAKE_MANAGED を指定するだけ。 https://docs.snowflake.com/en/user-guide/tables-iceberg-internal-storage#storage-cost
8. ポイント ‧Horizon を Iceberg 含む全データの統⼀ガバナンス層に ‧Scan Plan API で外部エンジンにも列マスキング‧  ⾏フィルタ適⽤（PrPr） ‧AI ⾃動保護: 機密データ検出 → タグ付け → ポリシー適⽤ ‧Open Sharing: Iceberg REST 経由でコピーなし共有  SAP‧Salesforce‧Workday など こんなとき ‧マルチエンジン環境でガバナンスを統⼀したい ‧⾮ Snowflake ユーザーにもセキュアにデータ共有したい Horizon Catalog + Apache Polaris 外部エンジン Read GA | Write PrPr | Polaris → ASF TLP https://docs.snowflake.com/ja/user-guide/tables-iceberg-access-using-external-query-engine-snowflake-horizon
9. ポイント ‧外部カタログの namespace / table を⾃動検出‧同期 ‧Iceberg REST 仕様準拠のリモートカタログにアクセス ‧外部IcebergへSnowflakeからも双⽅向同期を実現 ‧2026年6⽉22⽇現在ではTerraform管理未サポート こんなとき ‧既存カタログのまま Snowflake から統合アクセスしたい ‧読み出し⽤外部Icebergを作る⼿間を省略したい Catalog-linked DB / 外部 REST Catalog 連携 GA | Glue‧Unity Catalog‧OneLake 対応 CREATE DATABASE my_linked_db LINKED_CATALOG = ( CATALOG = 'my_catalog_int' ); https://docs.snowflake.com/ja/sql-reference/sql/create-database-catalog-linked
10. Iceberg 関連発表を受けてアーキテク チャを考えてみる
11. Icebergと組織論的な話 Iceberg を採⽤すべきか「組織の形」と「データの性質」で検討してみる 組織形態 グループ会社‧事業部が多い組織 ‧Iceberg を SSoT の共通レイヤーとして配置 し、各社は既存の DWH をそのまま運⽤でき る。 ‧データの⼊出⼒だけを標準化することで ガバナンスを効かせつつ⾃律性を保つ。 データ特性 Append 中⼼のワークロードが多い環境 ‧ログ‧イベント‧CDC‧ML 特徴量など 追記主体のデータが中⼼なら Iceberg が最適。 ‧スキーマ進化やタイムトラベルにより 履歴管理可能。
12. アーキテクチャ全体感
13. 各チームのR&R 中央集権チームのデータエンジニアがRAW~STGまでのIcebergを管理
14. 各チームのR&R ‧他グループ会社にBronzeやSilverなど⽐較的RAWなデータをIcebergにて 使わせることが可能 ‧RAWやSTGを共有する際のグループ標準となるようなイメージで運⽤する
15. 各チームのR&R Snowflakeとはcatalog linked DBで外部iceberg同期 各ドメインのデータモデラーがデータモデリングを⾏う
16. 各チームのR&R モデリングされたGold / MART をグループ間共有したいときは Snowflake Managed Iceberg
17. アーキテクチャの利点 • 中央チーム→AWS, 各ドメインオーナー →Snowflake（など）という具合に責 務がクラウド単位で分けられる • Snowflakeをテンプレート的に各事業 部へ配置することで連邦型ガバナンス を実現 • 各ドメインオーナーの運⽤負荷軽減の ためOpen Catalogや Snowflake Storageの積極的な活⽤ AWS 中央チーム Snowflake 各ドメイン
18. 実現に向けての様々な障壁 • dltがSnowflake-Managed-icebergテーブルに書き込むには有償ライセンスが必要 ◦ => AWS側にIcebergを寄せる理由に • dltはiceberg のV2までしかサポートをしていない • dbt-snowflakeで外部icebergに対するincremental mergeが未サポート ◦ append-OnlyなBronzeからcurrent tableなSilverを作るときの難点となる • Iceberg on S3のデータをS3上でモデリングする際、dbt-Athenaやdbt-Glueぐらいしかない ◦ Spark baseなツールが⼀番柔軟性が⾼い • Catalog Linked DBを利⽤する際、Glue Data CatalogがDatabase.Tableという2層のネームスペースなので、 Database.Schema.Tableの3層ネームスペースであるSnowflakeと微妙に合わない ◦ 例: Glue → {Bronze_product}.{users}, Snowflake → {Bronze}.{Bronze_product}.{users} ◦ Viewでラップすることでカバーする
19. 総括 • Icebergを利⽤するのがだいぶ⼀般的になってきた ◦ 技術スタックトレンドが激しいデータ界隈で相互運⽤可能なアーキテクチャはメリット • 組織や運⽤チームのケイパによって最適なicebergのアーキテクチャが変わる。どこまで Snowflakeのマネージドを利⽤するかを検討しよう