基礎から解説！Icebergで紐解くSnowflake×Databricks連携の現在地

Transcript

1. 2026/5/26 クラスメソッド株式会社 安原 朋紀 基礎から解説！Icebergで紐解く Snowflake×Databricks連携の現在地
2. ⾃⼰紹介 所属：クラスメソッド株式会社 Modern Data Stack チーム 名前：安原朋紀 担当：Modern Data Stack に該当する製品の技術支援・プリセールス https://dev.classmethod.jp/author/yasuhara-tomoki/
3. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks間の連携 • その他の連携機能 • まとめ 本日の内容は2026年5月時点のリリースをベースにしています。 アップデートが活発な分野のため最新情報は都度ご確認ください。
4. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks 間の連携 • その他の連携機能 • まとめ
5. データ基盤の変遷
6. データウェアハウス データを一元管理し、高速な BI・意思決定を支える 「構造化データ」の分析基盤 概要と強み： • 構造化データの集約 ◦ 業務システム等に分散したデータを ETL/ELT 処理で物理的に1カ所に集 約し、分析しやすいスキーマ（構造）に整理して管理する • 優れた集計・分析パフォーマンス ◦ 大量データの高速な集計（OLAP 性能）に最適化されており、組織のデータ に基づく意思決定を支援 直面した課題・限界： • 非構造化データの扱いが困難 ◦ 画像やテキスト、ログといった高度な AI/ML に不可欠なデータ（非構造化 データ）の保存・処理には適していない • アーキテクチャの分断とデータの二重持ち ◦ AI/ML 用とBI 用でシステムが分断される ◦ DWH で分析を行うためには別途データのコピー（ETL 処理）が必須となる ため、運用コストが増加
7. データレイク あらゆる種類の生データをそのままの形式で蓄積する「非構造化データ」の基盤 概要と強み： • あらゆるデータの集約 ◦ 構造化データだけでなく、画像、テキスト、ログ、IoT/アナログデータなど、 全ての未加工データをクラウド上の安価なオブジェクトストレージにそのま まの形式で保存できる • AI/ML に最適な環境 ◦ 実質無制限なスケーラビリティを持ち、高度な機械学習や AI 活用に強み を発揮 直面した課題・限界： • データスワンプ化のリスク ◦ DWHのようなトランザクション管理（ACID）やデータ品質の担保機能、細や かなガバナンス機能が欠如しており、放置すると信頼して使えない • アーキテクチャの分断とデータの二重持ち ◦ データレイクのままでは高性能な BI（SQL 分析）を行うことが難しく、結局 はダッシュボード用に DWH へデータをコピー（ETL）する必要があるため、 運用コストが増加
8. データレイクハウス データレイクの「柔軟性・低コスト」と DWHの「高機能・信頼性」を融合したデータ基盤 概要と強み： • 既存データレイクの直接活用 ◦ 安価なクラウドストレージ（S3など）に保存されているあらゆるデータ（構造 化・テキスト・非構造化・ストリーミングなど）を、そのままの場所で活用 • オープンテーブルフォーマット の導入 ◦ ファイル群の上に Iceberg や Delta Lake といった技術を被せることで、 DWH と同等の「ACIDトランザクション」や「スキーマ管理」「ガバナンス」をオ ブジェクトストレージ上に直接実装 • 「データの二重持ち・ETL」からの解放 ◦ AI/ML 用と BI 用（DWH）でデータをコピーする分断を解消し、ストレージコ ストと ETL の運用負荷・タイムラグを削減 • あらゆるワークロードの実行 ◦ 1つのオープンなデータソースに対して、SQL による定型分析（BI）、 Python/R 等を用いた高度な機械学習や生成AIまで、ツールを使い分ける ことが可能に
9. データレイクハウスの代表的な構成要素 1. オブジェクトストレージ（データ保存）： あらゆる形式のデータを、安価に保持するほぼ無制限で格納する物理的な土台（Amazon S3など） 2. テーブルフォーマット（データ管理仕様）： ストレージ上の単なるファイル群に、DWH と同等の管理機能を付与するオープンなデータ仕様 3. カタログ（メタデータ管理）： 分離されたストレージとエンジンの間で、「どのデータがどこにあるか」を解決する ４．クエリエンジン（計算・分析）： 目的に応じて最適なエンジンを自由に選び、データを直接処理する
10. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks 間の連携 • その他の連携機能 • まとめ
11. オープンテーブルフォーマットと Apache Iceberg データレイクの「ファイル群」を、DWHの「テーブル」に変える次世代の仕様 データレイクの課題： • ファイルを直接置いただけでは、「そもそもテーブルとして読めない（全体像が把握できない）」「同時書き 込みでデータが壊れる」「過去の状態を再現できない」など、DWH で当たり前だった安全な運用が不可 能 オープンテーブルフォーマット： • テーブルフォーマットにより、ファイル群の上に「メタデータ」を追加。クエリエンジンはメタデータを介する ことで、裏側のファイルを意識せず「1つのテーブル」として安全にアクセスできるように Apache Iceberg： • 2017年に Netflix が、自社の巨大なデータレイクを効率的に扱うための課題解決として開発し、オープン ソース化 • 従来のデータレイク（Hive形式）のような「フォルダ（ディレクトリ）」による管理から、「メタデータ」で論理的 に管理するアーキテクチャ
12. なぜ Iceberg か 従来のデータレイク（Hive形式）の限界を克服 比較ポイント 従来のデータレイク（ Hive形式） Apache Iceberg データの管理方式 ディレクトリ階層（物理配置＝パーティション） メタデータによるポインタ管理 ファイル増加時の性 能 LIST操作が遅い（一覧取得がボトルネック） メタデータ参照で高速（ファイル数に依存しない） スキーマの変更 壊れやすい（整合性が保てない） スキーマ進化（Schema Evolution）として仕様化 同時書き込み データ破損のリスク大（トランザクションなし） ACIDトランザクション（スナップショット隔離） 過去データの参照 不可 タイムトラベル（Time Travel）・ロールバックが可能
13. Iceberg のアーキテクチャ メタデータのツリー構造によって論理的なテーブル管理を実現する仕組み 【Iceberg Catalog】 - テーブルを管理し、各テーブルの現在の最新状態を示す「Metadata file」がどこにあるか示す - テーブル変更時にクライアントは Metadata file のロケーションを更新 【Metadata レイヤー】 Metadata file： テーブルのスキーマ定義、スナップショット履歴、現在の Manifest List のパスを保持 Manifest List： 特定の時点のスナップショットを構成する Manifest file 群を まとめるリスト Manifest file： データへのパスと統計情報を保持 【Data レイヤー】 実際のデータ（または削除情報）そのものが格納されたファイル群 Spec - Apache Iceberg™ より引用
14. 基本的なライフサイクル 既存ファイルを上書きせず、新しい「メタデータ」を作成して変更を管理 ①データとメタデータの作成（Data / Manifest） • テーブルが更新されると、新しい「データファイル」と、それを追跡する「マニフェストファイル」 「マニフェストリスト」が作成される ②新しいスナップショットの生成（Metadata） • 更新トランザクションの度に、上記①を含んだ最新のテーブル状態を記録する「新しいメタデー タファイル」が作成される ③カタログの更新（Catalog層） • 最後に、Iceberg カタログが保持する位置情報を「最新のメタデータファイル」へと安全に切り替 える（コミット）
15. 挙動を⾒てみる：①テーブル作成（CREATE TABLE） Iceberg Catalog metadata file 00000-9fc7a397-….metad ata.json { "format-version" : 2, "location": "s3://…/lifecycle/users" , "current-snapshot-id" : null, // データなし "snapshots": [], // 空 "schemas": [{ "schema-id": 0, "fields": [ {"id":1,"name":"id","type":"long","required": true}, {"id":2,"name":"name","type":"string"}, {"id":3,"name":"age","type":"int"}, {"id":4,"name":"dept","type":"string"} ] }]} 【新規テーブルを作成】 ①Metadata file の生成: S3上に、テーブルの構造（ス キーマ）だけを定義した最初 のメタデータファイル（.json）が 新規作成される ②Catalogへの登録: カタログが、そのメタデータファイ ルの場所をポインタとして記憶 【Metadata file】 まだデータがないため null スナップショット履歴も空
16. 挙動を⾒てみる：②レコードの追加（INSERT） Iceberg Catalog metadata file 0000….metadata .json metadata file 0001….metadata .json manifest list snap-<id>-0-<uui d>.avro manifest file <uuid>-m0.avro data file 00000-0-<uuid>.p arquet INSERT INTO lifecycle .users (id, name, age, dept) VALUES ・・・; "current-snapshot-id" : 8000341387126275967 , // 現在のsnapshot "snapshots" : [ { "snapshot-id" : 8000341387126275967 , 　　　　・・・ "manifest-list" : "s3://warehouse/…/metadata/snap-800….avro" // ← 次の層 (manifest-list) の S3 パス { "manifest_path" : "s3://warehouse/lifecycle/users/metadata/fe01024e-9fc0-….-m0.avro ", // ← 次の層 (manifest) の S3 パ data_file" : { "file_path" : "s3://warehouse/lifecycle/users/data/00000-0-fe01024e-….parquet" , // ← 最終層 (parquet) の S3 パス "file_format" : "PARQUET" , "record_count" : 3, ③Catalogの更新: カタログが最新 のJSONを向く ①Data/Manifest： 実データと、その統 計情報を持つ Manifest file、さら にそれを束ねる Manifest ListがS3 上に新規作成 ②Metadata：追加 された Manifest Listのパスを記録 した新しい Metadata file が 作成 【レコードを追加】 新しいスナップ ショット スナップショット を構成する Manifest Listの パス スナップショット を構成する Manifest fileの パス Parquetのパス を持つ
17. 主要機能 Time Travel： Iceberg テーブルは過去のバージョンをスナップショットとして追跡しているため、過去のデータを参 照できる スキーマ進化とパーティション進化 既存テーブルのスキーマを後から変更できる。列の追加、削除、リネーム、一部の型昇格なども可 能 パーティション設定 論理的なパーティション(Hidden Partitioning)により、テーブルの列を変換した値でパーティション設 定、後から追加・変更も可能 SELECT * FROM prod.sales.orders VERSION AS OF <snapshot id>; CREATE TABLE users ( id BIGINT NOT NULL, name STRING, created_at TIMESTAMP ) USING iceberg PARTITIONED BY (months(created_at));
18. テーブルフォーマットバージョン Iceberg のテーブルフォーマットにはバージョンが存在。2026年5月時点ではバージョン3までがあり、 バージョン4は開発中。 バージョン2 • 既存ファイルを変更せずに行レベルの削除を反映する Merge on Read が導入 バージョン3 • 新たなデータ型、列のデフォルト値、行レベルのリネージ、削除ベクトル、暗号化の改善 Format version changes Version 3
19. カタログの役割と代表的な実装 カタログの役割： • データベースと各データベースに属するテーブルを管理 ◦ 各テーブルの最新の状態を示す Metadata file の位置情報を保 持 • クエリエンジンは、まずカタログにアクセス ◦ テーブル変更時にクライアントは Metadata file のロケーションを 更新 Iceberg 利用するには、この役割を担う基盤システム（カタログ）が必要。このた めのカタログ実装 が提供されている。 【カタログ実装の例】 カタログ 特徴 Apache Polaris OSS、Snowflake Open Catalog（マネージド版） Unity Catalog OSS版、マネージド版 AWS Glue マネージド、AWS 統合 Spec - Apache Iceberg™ より引用
20. REST Catalog これまでのカタログ接続の課題： • エンジン側の実装が複雑（密結合） ◦ 各クエリエンジンの内部に、接続先のカタログと通信する ための固有の実装や依存ライブラリを組み込む必要が あった • 相互運用性のハードル ◦ 新しいカタログやクエリエンジンを導入する度に個別実装 が必要となり、複数のカタログへ柔軟にアクセスすることが 困難 REST Catalog のアプローチ： • HTTP ベースの標準化（バックエンドの隠蔽） ◦ Iceberg REST Open API 仕様に準拠し、カタログ機能への アクセスを標準化された HTTP のREST API 経由で提供 • 共通規格によるシンプル化 ◦ 各クエリエンジンは「REST APIを叩くクライアント」として機 能すればよく、カタログ側の実装を意識する必要がなくな り、ツール間の連携がシンプルに Apache Iceberg REST Catalog 仕様に準拠し、 Iceberg のカタログ操作を HTTP REST API 経由で 標準化する共通インターフェース
21. Credential Vending 概要： • クエリエンジンが REST Catalog にアクセスを要求した 際、カタログ側が対象テーブルのデータファイルにのみア クセス可能な、一時的なストレージ認証情報（トークン）を 発行してエンジンに渡す仕組み 特徴： • セキュリティの強化 ◦ 各クエリエンジン側で長期間有効な認証情報を保 持・設定する必要がなくなる ◦ 一時キーは短時間で失効するため、漏洩時のリス クも最小化 • 運用負荷削減 ◦ アクセス制御をカタログに一元化でき、ツールごと に設定する手間が不要に ◦ カタログ側で権限を設定すれば、ストレージへのア クセス権まで自動的に統制される
22. コンテンツ １．データレイク、データウェアハウス、データレイクハウス ２．オープンテーブルフォーマットとしてのIceberg ３．Snowflake・Databricks とは ４．Snowflake・Databricks 間の連携 ５．その他の連携機能 ６．まとめ
23. Snowflake とは クラウドのメリットを最大限活かした AI データクラウド • シンプルさとニアゼロメンテナンス ◦ インフラ管理・パフォーマンスチューニングの大半が自動化され、コンピューティングリ ソースの自動スケール・サスペンドも含めた運用負荷を大幅に削減 • SQL 中心のマルチワークロード実行基盤 ◦ データエンジニアリングや Snowpark（Python/Java/Scala）によるデータサイエンスまで、 SQL 互換の単一プラットフォームで実行可能。生成 AI 機能もSQL から直接呼び出せる • Snowflake Native Apps ◦ Snowflake Marketplace 上でデータだけでなくアプリケーションそのものを配布・販売も可 能
24. Databricks とは データとAIを統合する データ・インテリジェンス・プラットフォーム • レイクハウス・アーキテクチャ ◦ データレイクの柔軟性とDWHの信頼性・性能を両立し、構造化・非構造化・ストリーミング データを単一基盤で管理 • データ活用から BI/AI までを一気通貫でサポート ◦ BI やデータエンジニアリングから、機械学習、生成AI・エージェント開発までを同一プラッ トフォーム上で実行可能 • オープン性とベンダーロックインの抑制 ◦ データは顧客管理下のクラウドストレージにオープンな形式（Delta Lake等）で保持
25. Snowflake の Iceberg 対応 Iceberg 対応を段階的に強化し、自社プラットフォームからオープンエコシステムの中核へと位置づ けを変えつつある • 2026年5月 ◦ 外部エンジンからの Read/Write が GA ◦ Iceberg v3 対応 GA • 2026年4月 ◦ Snowflakeストレージ上の Iceberg テーブルが PuPr ◦ Databricks Unity Catalog (Azure) への書き込みサポート GA • 2026年2月 ◦ Horizon カタログでの外部クエリエンジンからの読み取りが GA • 2025年11月 ◦ Apache Polaris が Horizonカタログに統合 • 2025年10月 ◦ 外部管理Icebergテーブル + Catalog-linked Database への書き込み GA • 2024年6月 ◦ SnowflakeでのApache Icebergテーブル機能そのものが GA
26. Snowflake-managed Iceberg Tables 概要： • データの実体はすべて顧客管理下のクラウドストレージ（S3など）に Iceberg 形式で保存しつつ、メタデー タ管理やパフォーマンス最適化を Snowflake が自動で行う機能 特徴： • データを Snowflake の独自ストレージに閉じ込める（ロックインする）ことなく、Snowflake の高いパフォー マンスや使い勝手（ニアゼロメンテナンス）をそのまま享受できる 引用元：Apache Iceberg™ テーブル | Snowflake Documentation
27. Apache Polaris (Snowflake Open Catalog) 概要： • Snowflake が OSS として提供（Apache Software Foundation へ寄贈）した、 Iceberg REST Catalog 実装 特徴： • OSS として公開されているため、特定のクエリエンジンやインフラに縛られず、自社環境で自由にセルフホストするこ とも可能 • Iceberg REST API をサポートしているため、外部のクエリエンジンから直接アクセスできる ◦ Snowflake Horizon Catalog に統合されており、外部エンジンからの Snowflake の Iceberg テーブルへのアク セスも可能 引用元：Unifying Iceberg Tables on Snowflake
28. Databricks の Iceberg 対応 UniForm で既存 Delta 資産を Iceberg に開放し、オープンソース資産（Delta Lake・Unity Catalog）を 軸に Iceberg を取り込む形で並走している • 2026年4月 ◦ Databricks 上の Apache Iceberg v3 が PuPr ◦ Foreign Iceberg テーブルを Delta Sharing で共有が PuPr • 2025年6月 ◦ Iceberg RESTカタログAPIを完全にサポート ◦ Managed Apache Iceberg テーブルが PuPr ◦ Foreign Apache Iceberg テーブルが PuPr • 2024年6月 ◦ Databricks が Tabular 社を買収 ▪ Tabular：Apache Iceberg のオリジナル開発者らによって設立されたデータレイク／レイクハウス 向けのデータ管理プラットフォーム • 2023年10月 ◦ Delta UniForm（Delta Lake Universal Format）
29. Delta UniForm（Delta Lake Universal Format） Universal Format (UniForm) ： • Delta テーブルを、データのコピーなしで Iceberg や Hudi として読み取れるようにする機能 • Delta テーブルにデータが書き込まれると、裏側（非同期）で自動的に Iceberg 用のメタデータも生成 ◦ これにより、データの実体（Parquet ファイル）は1つのまま、Iceberg クライアントからは「Iceberg テーブル」として読み取ることが可能に ◦ フォーマット統合を目指す現実的な動きとして、Iceberg との間で相互運用性を提供し、REST カタ ログインターフェースもサポート -- 新規テーブル作成時 CREATE TABLE T(c1 INT) TBLPROPERTIES( -- カラムを内部IDで管理。カラム名変更後も Icebergクライアントとの互換性を維持できる（新規作成時の推奨） 'delta.columnMapping.mode' = 'id', 'delta.enableIcebergCompatV2' = 'true', 'delta.universalFormat.enabledFormats' = 'iceberg'); -- 既存のDeltaテーブルに後付けで有効化 ALTER TABLE table_name SET TBLPROPERTIES( -- カラムをカラム名で管理。データの再書き込みなしに有効化できるため既存テーブルへの適用に使用 'delta.columnMapping.mode' = 'name', 'delta.enableIcebergCompatV2' = 'true', 'delta.universalFormat.enabledFormats' = 'iceberg');
30. Unity Catalog の Iceberg ネイティブ対応（Managed / Foreign） 概要： • Unity Catalog において、Databricks がスキーマとストレージを管理する「Managed Iceberg」と、外部カタログを参照す る「Foreign Iceberg」をサポート。同時に「Iceberg REST API」を提供開始 特徴： • Unity Catalog が「REST Catalog」として振る舞うため、外部のエンジンから Databricks のデータに対して直接アクセ ス（読み書き）が可能に • Foreign 機能により、逆に Databricks 側からも Snowflake Horizon 等の Iceberg データを直接参照できるように 引用元：What’s new with Databricks Unity Catalog at Data + AI Summit 2025
31. 両製品で REST Catalog 仕様を実装したカタログをサポート Databricks (Unity Catalog): • Unity Catalog において Iceberg REST API をサポート • これにより、Databricks 以外の外部エンジンからでも、REST API を叩くだけでUnity Catalog 内 の Iceberg テーブルを操作できる Snowflake (Polaris Catalog / Horizon Catalog): • 自社が OSS として Apache に寄贈した Polaris Catalog は、Iceberg REST Catalog仕様で実装 • OSS としてセルフホストできるほか、Snowflake Open Catalog などのマネージドとしても提供 • Apache Polaris は Snowflake Horizon カタログに統合 されている REST Catalog の普及・サポートにより 「Snowflake と Databricks で同じ Iceberg テーブルを読み書きできる」ように
32. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks 間の連携 • その他の連携機能 • まとめ
33. Snowflake‧Databricks 間連携の全体像 既存 Delta 資産の活用（Databricks を Snowflake から参照）： • Delta UniForm ◦ Databricks の既存 Delta テーブルに対して、裏側で Iceberg メタデータを自動生成（UniForm）し、Snowflake のカタログリンク DBが、ストレージ上のデータファイルに直接アクセス ◦ これまで蓄積した Delta テーブルを一切変換・複製することなく、そのまま Snowflake から参照できる Iceberg のネイティブな双方向連携（Databricks ⇔ Snowflake）： • Unity Catalog REST API ◦ Snowflake のカタログリンクDBが、Databricks（Unity Catalog）のIceberg REST API エンドポイントに直接接続し、認証とアク セス制御を統合 ◦ Snowflake から Databricks 管理の Iceberg テーブルの参照のみならず書き込み操作も可能 Snowflake データの高度な AI/ML 活用（Snowflake を Databricks から参照）： • カタログフェデレーション ◦ Databricks から Snowflake のデータベースをマッピングし、Snowflake 管理の Iceberg ファイルに対して直接アクセス ◦ Native テーブルはクエリフェデレーション（JDBC）にフォールバック ◦ Databricks のエンジンを用いて高速なデータ処理や AI活用が行える 参考： Databricks 管理の Iceberg テーブルに対する Snowflake からの読み書きを試してみる | DevelopersIO Iceberg 読み取りを有効化した Delta テーブルの Snowflake からの参照とカタログフェデレーションによる Snowflake 管理の Iceberg テーブルの Databricks からの参照を試してみた | DevelopersIO
34. 既存 Delta 資産の活⽤（Databricks を Snowflake から参照）
35. Iceberg のネイティブな双⽅向連携（Databricks ⇔ Snowflake）
36. Snowflake データの⾼度な AI/ML 活⽤（Snowflake を Databricks から参照）
37. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks 間の連携 • その他の連携機能 • まとめ
38. BigQuery‧Databricks の連携 Google Cloud Lakehouse（旧 BigLake）： • Google Cloud 上でオープンなレイクハウスを実現するためのプラットフォーム全体 • Lakehouse ランタイム カタログ（メタデータサービスに相当。旧 BigLake metastore）は Apache Iceberg REST カタロ グ エンドポイントを提供 Cross-Cloud Lakehouse： ※2026年4月にプレビュー • 他クラウドプロバイダーに存在する Iceberg テーブルを Google Cloud から直接クエリできる機能 • 2026年4月時点では、AWS の外部ロケーションまたは の Google Cloud 外部ロケーションを使用する Databricks Unity Catalog サポート ◦ Unity Catalog 管理の Iceberg テーブル・Delta テーブル（UniForm）を直接参照できる Databricks 側： • Google Cloud の Lakehouse フェデレーションがプライベートプレビュー段階 ◦ Google Cloud Lakehouse で管理されているテーブルを Databricks から直接参照できる 参考： Interoperability between Unity Catalog and Google BigQuery via catalog federation | Databricks Blog Cross-cloud Lakehouse で Databricks Unity Catalog の Iceberg テーブルを BigQuery から参照してみた | DevelopersIO
39. BigQuery‧Snowflake の連携 Snowflake ⇔ BigQuery 間の Iceberg連携： • メタデータパスの直接指定による相互参照（自動同期は 今後のアップデートに期待） 参考： Snowflake Iceberg テーブルデータを BigQuery Iceberg テーブルから参照してみた。 | DevelopersIO BigQuery tables for Apache Icebergで定義されたテーブルをSnowflakeのIceberg Tableとしてクエリできるようにしてみた | DevelopersIO　※画像の引用元 最新のメタデータファイルのパスを指定する これまでの連携との違い： • 現状、両プラットフォーム間をシームレスに連携できる「REST Catalog等を介した自動統合」はサポートさ れていない • そのため、両者間で Iceberg テーブルを共有するには「メタデータファイルの手動連携」が必要 • 元データが更新されると、Iceberg のアーキテクチャ通り「新しいメタデータファイル」が生成されるが、自 動追随しないため、最新のメタデータパスを特定し、テーブル定義を再設定する処理（ストアドプロシー ジャ等）が必要
40. Fivetran のマネージドデータレイク Fivetran： • 多数のコネクタを提供する EL / リバース ETL に特化した SaaS • S3 などのオブジェクトストレージを連携先とできる マネージドデータレイク： • カタログ実装 ◦ Apache Polaris(Iceberg REST) を選択でき、Fivetran 側でホスト • データ ◦ 実体は Parquet 形式で保存され、 Iceberg と Delta Lake の両方のメタデータが同期して維持 される ◦ テーブルの操作・管理は Fivetran が担う ◦ 外部のクエリエンジンに対して読み取り専用として 提供される 引用元：A modern data lake with Fivetran Managed Data Lake Service and Databricks Unity Catalog 参考： Fivetran Managed Data Lake Service で構築した S3 データレイクを DuckDB / Snowflake / Databricks から参照してみた | DevelopersIO Polaris カタログへの接続情報
41. コンテンツ • データレイク、データウェアハウス、データレイクハウス • オープンテーブルフォーマットとしてのIceberg • Snowflake・Databricks とは • Snowflake・Databricks 間の連携 • その他の連携機能 • まとめ
42. まとめ Iceberg は「新しいツール」ではなく、製品同士を繋ぐ「共通言語」 1つのデータを共有： • ツールごとにデータを複製・移動する必要がなくなり、S3 などのストレージにデータを置いたまま、あらゆるエンジンから直接読み 書きできるようになります 各製品の「いいとこ取り」： • 「高度な AI 開発には Databricks」「全社の BI 分析にはSnowflake」など、それぞれの強みを活かした連携が、現実のものとなりつ つあります カタログ実装の選択： • Iceberg のデータファイル自体はストレージにありますが、「どのメタデータが最新か」を解決するのはカタログです • 「どのカタログをマスターに据えるか」 は設計ポイントになります ◦ 現時点では特定のエンジンに縛られないオープンな通信規格である「Iceberg REST Catalog」をサポートするカタログを選ぶ ことが、拡張性の担保に求められます • 例： ◦ Unity Catalog (Databricks)：AI/MLモデルなどを含め、全社的なデータガバナンスを Databricks で統合・一元管理したい場 合 ◦ Apache Polaris (Snowflake)：ベンダーロックインを極力排除したい（Snowflake Open Catalog）、または Snowflake を中心に 外部連携したい場合（Snowflake Horizon Catalog） ◦ AWS Glue：AWS 環境で完結したシステムを構築したい場合