2026/5/26 クラスメソッド株式会社 安原 朋紀 基礎から解説！Icebergで紐解く Snowflake×Databricks連携の現在地 

⾃⼰紹介 所属：クラスメソッド株式会社 Modern Data Stack チーム 名前：安原朋紀 担当：Modern Data Stack に該当する製品の技術支援・プリセールス https://dev.classmethod.jp/author/yasuhara-tomoki/ 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks間の連携 ● その他の連携機能 ● まとめ 本日の内容は2026年5月時点のリリースをベースにしています。 アップデートが活発な分野のため最新情報は都度ご確認ください。 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks 間の連携 ● その他の連携機能 ● まとめ 

データ基盤の変遷 

データウェアハウス データを一元管理し、高速な BI・意思決定を支える 「構造化データ」の分析基盤 概要と強み： ● 構造化データの集約 ○ 業務システム等に分散したデータを ETL/ELT 処理で物理的に1カ所に集 約し、分析しやすいスキーマ（構造）に整理して管理する ● 優れた集計・分析パフォーマンス ○ 大量データの高速な集計（OLAP 性能）に最適化されており、組織のデータ に基づく意思決定を支援 直面した課題・限界： ● 非構造化データの扱いが困難 ○ 画像やテキスト、ログといった高度な AI/ML に不可欠なデータ（非構造化 データ）の保存・処理には適していない ● アーキテクチャの分断とデータの二重持ち ○ AI/ML 用とBI 用でシステムが分断される ○ DWH で分析を行うためには別途データのコピー（ETL 処理）が必須となる ため、運用コストが増加 

データレイク あらゆる種類の生データをそのままの形式で蓄積する「非構造化データ」の基盤 概要と強み： ● あらゆるデータの集約 ○ 構造化データだけでなく、画像、テキスト、ログ、IoT/アナログデータなど、 全ての未加工データをクラウド上の安価なオブジェクトストレージにそのま まの形式で保存できる ● AI/ML に最適な環境 ○ 実質無制限なスケーラビリティを持ち、高度な機械学習や AI 活用に強み を発揮 直面した課題・限界： ● データスワンプ化のリスク ○ DWHのようなトランザクション管理（ACID）やデータ品質の担保機能、細や かなガバナンス機能が欠如しており、放置すると信頼して使えない ● アーキテクチャの分断とデータの二重持ち ○ データレイクのままでは高性能な BI（SQL 分析）を行うことが難しく、結局 はダッシュボード用に DWH へデータをコピー（ETL）する必要があるため、 運用コストが増加 

データレイクハウス データレイクの「柔軟性・低コスト」と DWHの「高機能・信頼性」を融合したデータ基盤 概要と強み： ● 既存データレイクの直接活用 ○ 安価なクラウドストレージ（S3など）に保存されているあらゆるデータ（構造 化・テキスト・非構造化・ストリーミングなど）を、そのままの場所で活用 ● オープンテーブルフォーマット の導入 ○ ファイル群の上に Iceberg や Delta Lake といった技術を被せることで、 DWH と同等の「ACIDトランザクション」や「スキーマ管理」「ガバナンス」をオ ブジェクトストレージ上に直接実装 ● 「データの二重持ち・ETL」からの解放 ○ AI/ML 用と BI 用（DWH）でデータをコピーする分断を解消し、ストレージコ ストと ETL の運用負荷・タイムラグを削減 ● あらゆるワークロードの実行 ○ 1つのオープンなデータソースに対して、SQL による定型分析（BI）、 Python/R 等を用いた高度な機械学習や生成AIまで、ツールを使い分ける ことが可能に 

データレイクハウスの代表的な構成要素 1. オブジェクトストレージ（データ保存）： あらゆる形式のデータを、安価に保持するほぼ無制限で格納する物理的な土台（Amazon S3など） 2. テーブルフォーマット（データ管理仕様）： ストレージ上の単なるファイル群に、DWH と同等の管理機能を付与するオープンなデータ仕様 3. カタログ（メタデータ管理）： 分離されたストレージとエンジンの間で、「どのデータがどこにあるか」を解決する ４．クエリエンジン（計算・分析）： 目的に応じて最適なエンジンを自由に選び、データを直接処理する 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks 間の連携 ● その他の連携機能 ● まとめ 

オープンテーブルフォーマットと Apache Iceberg データレイクの「ファイル群」を、DWHの「テーブル」に変える次世代の仕様 データレイクの課題： ● ファイルを直接置いただけでは、「そもそもテーブルとして読めない（全体像が把握できない）」「同時書き 込みでデータが壊れる」「過去の状態を再現できない」など、DWH で当たり前だった安全な運用が不可 能 オープンテーブルフォーマット： ● テーブルフォーマットにより、ファイル群の上に「メタデータ」を追加。クエリエンジンはメタデータを介する ことで、裏側のファイルを意識せず「1つのテーブル」として安全にアクセスできるように Apache Iceberg： ● 2017年に Netflix が、自社の巨大なデータレイクを効率的に扱うための課題解決として開発し、オープン ソース化 ● 従来のデータレイク（Hive形式）のような「フォルダ（ディレクトリ）」による管理から、「メタデータ」で論理的 に管理するアーキテクチャ 

なぜ Iceberg か 従来のデータレイク（Hive形式）の限界を克服 比較ポイント 従来のデータレイク（ Hive形式） Apache Iceberg データの管理方式 ディレクトリ階層（物理配置＝パーティション） メタデータによるポインタ管理 ファイル増加時の性 能 LIST操作が遅い（一覧取得がボトルネック） メタデータ参照で高速（ファイル数に依存しない） スキーマの変更 壊れやすい（整合性が保てない） スキーマ進化（Schema Evolution）として仕様化 同時書き込み データ破損のリスク大（トランザクションなし） ACIDトランザクション（スナップショット隔離） 過去データの参照 不可 タイムトラベル（Time Travel）・ロールバックが可能 

Iceberg のアーキテクチャ メタデータのツリー構造によって論理的なテーブル管理を実現する仕組み 【Iceberg Catalog】 - テーブルを管理し、各テーブルの現在の最新状態を示す「Metadata file」がどこにあるか示す - テーブル変更時にクライアントは Metadata file のロケーションを更新 【Metadata レイヤー】 Metadata file： テーブルのスキーマ定義、スナップショット履歴、現在の Manifest List のパスを保持 Manifest List： 特定の時点のスナップショットを構成する Manifest file 群を まとめるリスト Manifest file： データへのパスと統計情報を保持 【Data レイヤー】 実際のデータ（または削除情報）そのものが格納されたファイル群 Spec - Apache Iceberg™ より引用 

基本的なライフサイクル 既存ファイルを上書きせず、新しい「メタデータ」を作成して変更を管理 ①データとメタデータの作成（Data / Manifest） ● テーブルが更新されると、新しい「データファイル」と、それを追跡する「マニフェストファイル」 「マニフェストリスト」が作成される ②新しいスナップショットの生成（Metadata） ● 更新トランザクションの度に、上記①を含んだ最新のテーブル状態を記録する「新しいメタデー タファイル」が作成される ③カタログの更新（Catalog層） ● 最後に、Iceberg カタログが保持する位置情報を「最新のメタデータファイル」へと安全に切り替 える（コミット） 

挙動を⾒てみる：①テーブル作成（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 スナップショット履歴も空 

挙動を⾒てみる：②レコードの追加（INSERT） Iceberg Catalog metadata file 0000….metadata .json metadata file 0001….metadata .json manifest list snap--0-.avro manifest file -m0.avro data file 00000-0-.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のパス を持つ 

主要機能 Time Travel： Iceberg テーブルは過去のバージョンをスナップショットとして追跡しているため、過去のデータを参 照できる スキーマ進化とパーティション進化 既存テーブルのスキーマを後から変更できる。列の追加、削除、リネーム、一部の型昇格なども可 能 パーティション設定 論理的なパーティション(Hidden Partitioning)により、テーブルの列を変換した値でパーティション設 定、後から追加・変更も可能 SELECT * FROM prod.sales.orders VERSION AS OF ; CREATE TABLE users ( id BIGINT NOT NULL, name STRING, created_at TIMESTAMP ) USING iceberg PARTITIONED BY (months(created_at)); 

テーブルフォーマットバージョン Iceberg のテーブルフォーマットにはバージョンが存在。2026年5月時点ではバージョン3までがあり、 バージョン4は開発中。 バージョン2 ● 既存ファイルを変更せずに行レベルの削除を反映する Merge on Read が導入 バージョン3 ● 新たなデータ型、列のデフォルト値、行レベルのリネージ、削除ベクトル、暗号化の改善 Format version changes Version 3 

カタログの役割と代表的な実装 カタログの役割： ● データベースと各データベースに属するテーブルを管理 ○ 各テーブルの最新の状態を示す Metadata file の位置情報を保 持 ● クエリエンジンは、まずカタログにアクセス ○ テーブル変更時にクライアントは Metadata file のロケーションを 更新 Iceberg 利用するには、この役割を担う基盤システム（カタログ）が必要。このた めのカタログ実装 が提供されている。 【カタログ実装の例】 カタログ 特徴 Apache Polaris OSS、Snowflake Open Catalog（マネージド版） Unity Catalog OSS版、マネージド版 AWS Glue マネージド、AWS 統合 Spec - Apache Iceberg™ より引用 

REST Catalog これまでのカタログ接続の課題： ● エンジン側の実装が複雑（密結合） ○ 各クエリエンジンの内部に、接続先のカタログと通信する ための固有の実装や依存ライブラリを組み込む必要が あった ● 相互運用性のハードル ○ 新しいカタログやクエリエンジンを導入する度に個別実装 が必要となり、複数のカタログへ柔軟にアクセスすることが 困難 REST Catalog のアプローチ： ● HTTP ベースの標準化（バックエンドの隠蔽） ○ Iceberg REST Open API 仕様に準拠し、カタログ機能への アクセスを標準化された HTTP のREST API 経由で提供 ● 共通規格によるシンプル化 ○ 各クエリエンジンは「REST APIを叩くクライアント」として機 能すればよく、カタログ側の実装を意識する必要がなくな り、ツール間の連携がシンプルに Apache Iceberg REST Catalog 仕様に準拠し、 Iceberg のカタログ操作を HTTP REST API 経由で 標準化する共通インターフェース 

Credential Vending 概要： ● クエリエンジンが REST Catalog にアクセスを要求した 際、カタログ側が対象テーブルのデータファイルにのみア クセス可能な、一時的なストレージ認証情報（トークン）を 発行してエンジンに渡す仕組み 特徴： ● セキュリティの強化 ○ 各クエリエンジン側で長期間有効な認証情報を保 持・設定する必要がなくなる ○ 一時キーは短時間で失効するため、漏洩時のリス クも最小化 ● 運用負荷削減 ○ アクセス制御をカタログに一元化でき、ツールごと に設定する手間が不要に ○ カタログ側で権限を設定すれば、ストレージへのア クセス権まで自動的に統制される 

コンテンツ １．データレイク、データウェアハウス、データレイクハウス ２．オープンテーブルフォーマットとしてのIceberg ３．Snowflake・Databricks とは ４．Snowflake・Databricks 間の連携 ５．その他の連携機能 ６．まとめ 

Snowflake とは クラウドのメリットを最大限活かした AI データクラウド ● シンプルさとニアゼロメンテナンス ○ インフラ管理・パフォーマンスチューニングの大半が自動化され、コンピューティングリ ソースの自動スケール・サスペンドも含めた運用負荷を大幅に削減 ● SQL 中心のマルチワークロード実行基盤 ○ データエンジニアリングや Snowpark（Python/Java/Scala）によるデータサイエンスまで、 SQL 互換の単一プラットフォームで実行可能。生成 AI 機能もSQL から直接呼び出せる ● Snowflake Native Apps ○ Snowflake Marketplace 上でデータだけでなくアプリケーションそのものを配布・販売も可 能 

Databricks とは データとAIを統合する データ・インテリジェンス・プラットフォーム ● レイクハウス・アーキテクチャ ○ データレイクの柔軟性とDWHの信頼性・性能を両立し、構造化・非構造化・ストリーミング データを単一基盤で管理 ● データ活用から BI/AI までを一気通貫でサポート ○ BI やデータエンジニアリングから、機械学習、生成AI・エージェント開発までを同一プラッ トフォーム上で実行可能 ● オープン性とベンダーロックインの抑制 ○ データは顧客管理下のクラウドストレージにオープンな形式（Delta Lake等）で保持 

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 

Snowflake-managed Iceberg Tables 概要： ● データの実体はすべて顧客管理下のクラウドストレージ（S3など）に Iceberg 形式で保存しつつ、メタデー タ管理やパフォーマンス最適化を Snowflake が自動で行う機能 特徴： ● データを Snowflake の独自ストレージに閉じ込める（ロックインする）ことなく、Snowflake の高いパフォー マンスや使い勝手（ニアゼロメンテナンス）をそのまま享受できる 引用元：Apache Iceberg™ テーブル | Snowflake Documentation 

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 

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） 

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'); 

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 

両製品で 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 テーブルを読み書きできる」ように 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks 間の連携 ● その他の連携機能 ● まとめ 

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 

既存 Delta 資産の活⽤（Databricks を Snowflake から参照） 

Iceberg のネイティブな双⽅向連携（Databricks ⇔ Snowflake） 

Snowflake データの⾼度な AI/ML 活⽤（Snowflake を Databricks から参照） 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks 間の連携 ● その他の連携機能 ● まとめ 

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 

BigQuery‧Snowflake の連携 Snowflake ⇔ BigQuery 間の Iceberg連携： ● メタデータパスの直接指定による相互参照（自動同期は 今後のアップデートに期待） 参考： Snowflake Iceberg テーブルデータを BigQuery Iceberg テーブルから参照してみた。 | DevelopersIO BigQuery tables for Apache Icebergで定義されたテーブルをSnowflakeのIceberg Tableとしてクエリできるようにしてみた | DevelopersIO　※画像の引用元 最新のメタデータファイルのパスを指定する これまでの連携との違い： ● 現状、両プラットフォーム間をシームレスに連携できる「REST Catalog等を介した自動統合」はサポートさ れていない ● そのため、両者間で Iceberg テーブルを共有するには「メタデータファイルの手動連携」が必要 ● 元データが更新されると、Iceberg のアーキテクチャ通り「新しいメタデータファイル」が生成されるが、自 動追随しないため、最新のメタデータパスを特定し、テーブル定義を再設定する処理（ストアドプロシー ジャ等）が必要 

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 カタログへの接続情報 

コンテンツ ● データレイク、データウェアハウス、データレイクハウス ● オープンテーブルフォーマットとしてのIceberg ● Snowflake・Databricks とは ● Snowflake・Databricks 間の連携 ● その他の連携機能 ● まとめ 

まとめ 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 環境で完結したシステムを構築したい場合 

No content