APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > Databricks > DatabricksとSnowflakeの壁を壊す：T-Mobileが実現したIcebergとUnity Catalogによるデータ相互運用性

DatabricksとSnowflakeの壁を壊す：T-Mobileが実現したIcebergとUnity Catalogによるデータ相互運用性

Databricks DAIS2025
＜ techblogAPCについて（はじめにお読み下さい） ＞

DatabricksとSnowflakeの壁を壊す：T-Mobileが実現したIcebergとUnity Catalogによるデータ相互運用性

現代のデータドリブンな企業において、DatabricksとSnowflakeはそれぞれが強力なデータプラットフォームとして確固たる地位を築いています。しかし、多くの組織では両プラットフォームが併存し、結果としてデータのサイロ化という新たな課題が生まれています。データのコピーはコスト、鮮度、ガバナンスの観点から決して理想的ではありません。

最近のカンファレンスセッション「Breaking Silos: Enabling Databricks–Snowflake Interoperability With Iceberg and Unity Catalog」では、Geoffrey Freeman氏とMohit Kumar氏が、データコピーを一切行わずにDatabricksとSnowflake間でほぼリアルタイム（約30秒の遅延）のデータ共有を実現するアーキテクチャを紹介しました。

本記事では、この先進的な事例をもとに、オープンテーブルフォーマットとUnity Catalogを活用して、いかにしてプラットフォーム間の壁を乗り越えることができるのか、その技術的な背景と具体的な実装アプローチを解説します。

※本記事は、Data + AI Summit のセッションを現地で視聴したエンジニアが、内容をできる限り客観的に共有することを目的に、生成AIを活用して作成したものです。 ― エーピーコミュニケーションズ Lakehouse部

なぜデータはサイロ化し、リアルタイム共有が求められるのか


多くの企業では、データサイエンスや機械学習にはDatabricks、BIやデータウェアハウジングにはSnowflakeといったように、用途に応じて最適なツールを選択する「ベストオブブリード」のアプローチが採用されています。この戦略は各部門の生産性を最大化する一方で、データがプラットフォームごとに分断される「データサイロ」を生み出します。

サイロ化されたデータは、部門横断での分析を困難にし、同じデータを二重、三重にコピーする非効率なETLパイプラインを乱立させます。これにより、ストレージコストの増大、データ鮮度の劣化、そして一貫したガバナンスの欠如といった問題が深刻化します。セッションでは、データコピーを排除し、単一のデータソース（Single Source of Truth）を維持しつつ両プラットフォームの長所を活かすアーキテクチャが示されました。その鍵となったのが、オープンな技術標準の採用です。

技術的背景：オープン性が生み出す相互運用性

T-Mobileの事例を理解するには、いくつかの重要な技術要素を把握する必要があります。


まず中心にあるのが、オープンテーブルフォーマットです。これは、クラウドストレージ（Amazon S3, Azure ADLSなど）上のデータファイル群を、信頼性の高い単一のテーブルとして扱えるようにするメタデータ仕様です。代表的なものにApache IcebergとDelta Lakeがあります。これらのフォーマットは、ACIDトランザクション、スキーマの変更への柔軟な対応（スキーマエボリューション）、過去の特定時点のデータを参照できるタイムトラベルといった高度な機能を提供し、複数の分析エンジンが安全に同一データへアクセスすることを可能にします。

次に重要なのが、Databricksが提供するUnity Catalogです。これは単なるメタデータストアではなく、クラウド、ワークスペース、プラットフォームを横断して一元的なデータガバナンスを実現するソリューションです。テーブルやファイルへのきめ細やかなアクセス制御、データリネージの追跡、そしてREST APIを通じたプログラムによるカタログ操作を可能にします。

そして、この2つを繋ぐのがDelta UniformとIceberg REST APIです。Delta Uniformは、Delta LakeテーブルにIceberg互換のメタデータを自動生成する機能です。これにより、Delta Lakeで管理されているテーブルを、IcebergをネイティブにサポートするSnowflakeのような外部エンジンが直接読み取れるようになります。その際のメタデータ連携を担うのがIceberg REST APIであり、Unity Catalogはこの標準APIを通じて外部システムにテーブル情報を提供します。

提示された「最低限の要件」とアーキテクチャ


登壇者は、以下の3つの最低限の要件を提示しました。

  1. オープンテーブルフォーマットでのデータ保存: データはDelta LakeやIcebergといったオープンなフォーマットでクラウドストレージに保存する。
  2. プログラマティックなカタログ登録: 全てのデータは、API経由で操作可能なカタログ（Unity Catalog）に登録する。
  3. オープンなRESTインターフェースの活用: 外部システムとの連携は、Iceberg REST APIのようなオープンなインターフェースを介して行う。

このシンプルな原則に基づき、DatabricksのUnity Catalogをハブとした相互運用アーキテクチャが構築されました。データの実体はクラウドストレージ上に一元化され、DatabricksとSnowflakeはいずれもUnity Catalogを介してそのデータにアクセスします。これにより、物理的な移動やコピーを完全に排除し、ガバナンスを一元化できます。

2つの実装アプローチ：DatabricksからSnowflakeへ、SnowflakeからDatabricksへ

講演のデモでは、双方向のデータ共有を実現する具体的なシナリオが紹介されました。

1. Databricks管理のDelta UniformテーブルをSnowflakeで読む

これは、Databricksで生成・更新されるデータをSnowflakeユーザーが利用するケースです。

  • Databricks側: テーブルを以下SQLコマンドにてを指定したDelta Uniform形式で作成します。これにより、Deltaのトランザクションログと並行してIceberg互換のメタデータが生成されます。
CREATE TABLE my_table (c1 INT) TBLPROPERTIES(
  'delta.columnMapping.mode' = 'name',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
);
  • Snowflake側:
    1. カタログ統合（Catalog Integration）: Unity CatalogのIceberg REST APIエンドポイントを指定し、認証用のサービスプリンシパル情報を設定します。
    2. 外部ボリューム（External Volume）: データが格納されているクラウドストレージへのアクセスを設定します。
    3. Icebergテーブルの作成: 上記を参照してSnowflake上にIcebergテーブルを定義します。

デモでは初期状態の180,420件に対し、10,000件を追加した後、約30秒後にSnowflake側で190,420件として取得できることが示され、その同期プロセスが紹介されました。

2. Snowflake管理のIcebergテーブルをDatabricksで読む

逆に、Snowflakeで管理されているデータをDatabricksユーザーが利用するケースです。

  • Snowflake側: クラウドストレージ上の外部ストレージにデータを格納するIcebergテーブルを作成します。
  • Databricks側:
    1. 接続（Connection）: Snowflakeへの接続情報を定義します。
    2. 外部カタログ（Federated Catalog）: 上記の接続を利用して、SnowflakeのデータベースをDatabricksのカタログとしてマウントします。

この設定により、Databricksユーザーは、あたかもUnity Catalog内のネイティブテーブルであるかのように、Snowflake上のIcebergテーブルにシームレスにアクセスできます。

ガバナンスとセキュリティ：乗り越えるべき課題

このアーキテクチャを実現するには、ガバナンスとセキュリティに関するいくつかの重要な考慮点があります。

  • ネットワーク構成 多くの企業と同様に、DatabricksワークスペースはVNet（仮想ネットワーク）内に配置されます。SnowflakeがUnity CatalogのIceberg REST APIにアクセスできるようにするには、エンドポイントをSnowflakeのコンピュートIPレンジに対して公開し、適切なネットワーク設定を行う必要があります。

  • 認証情報の管理 カタログ統合設定ではサービスプリンシパルのシークレットを登録する必要があり、登壇者によれば、管理権限を持つチームを限定し、職務分掌でセキュリティを担保しているとのことでした。

  • データマスキング 従来はビューを用いて行レベル・列レベルのセキュリティを実装していましたが、このアーキテクチャではテーブル自体を共有するため、ビューによる抽象化が機能しません。対策として、テーブルを暗号化するか、個人情報などを事前にトークン化してから格納するといったアプローチが必要です。

主な課題と実践的な対策

実装過程で直面した課題と対策として、以下が共有されました。

  • 後方互換性 Delta Uniformを利用するには、Delta LakeのリーダーバージョンV2対応クライアントが必要です。古いシステムが混在する環境では、移行計画が求められます。

  • 外部テーブル vs 管理テーブル 管理テーブルは最適化機能の恩恵を受けられる一方、外部テーブルはパスを完全にコントロールでき、他のツールとの連携が容易です。将来的なエコシステムを踏まえた設計判断が必要です。

  • 命名規約とデータコントラクト 複数プラットフォームを跨いでデータを扱うため、一貫した命名規約やデータコントラクト（仕様・品質合意）の整備と、自動化・テンプレート化による運用の効率化が重要です。

まとめと今後の展望

本事例は、DatabricksとSnowflakeがオープンな技術標準を介して協調し、より強力なデータエコシステムを構築できることを示しています。オープンフォーマットと中央集権的なガバナンスの組み合わせにより、データプラットフォームの壁を乗り越え、柔軟で効率的、かつガバナンスを担保した未来のデータアーキテクチャを実現可能です。今後はさらに他のクラウドデータサービスへの展開も期待され、真の「コンポーザブルデータエコシステム」の形成が進むでしょう。