概要
「Cross Data Platforms Meetup #1」にて、「DatabricksとSnowflakeをつなぐ最新データ相互利用術」というタイトルで発表しました。本記事では、その発表内容を整理してご紹介します。
発表資料
発表内容補足
manabian について
「データ分析基盤の構築方法論」や「関連テクノロジーの調査」、「エラー対応方法」など、データ分析の上流から下流まで幅広いテーマを扱った記事を投稿しています。
出所：最強のデータ分析基盤を目指して～汎用的なデータ分析基盤の選定方法の提案～ #AWS - Qiita
出所：データエンジニアリングの背景を踏まえてdbt（Data Build Tool）を少し深く理解してみる #Python - Qiita
出所：Snowflake における Apache Iceberg の機能の完全ガイド： Apache Iceberg on Snowflake 活用の第一歩 #Spark - Qiita
出所：Google Colab の Spark にて Hadoop Catalog の Apache Iceberg の動作検証 #iceberg - Qiita
データ統合と相互運用性
データ統合は、組織内に散在するデータを一貫した形式で集約するプロセスを指します。ただし、単に集約するだけではなく、システム間で連携できる“相互運用性”を確保することも重要です。また、システム面だけでなく運用体制にも配慮する必要があります。
「DMBOK（データマネジメント知識体系ガイド）」でも、データガバナンスを考える上で重要な領域の1つとしてデータ統合と相互運用性が挙げられています。
出所：『データマネジメント知識体系ガイド 第二版』 DAMA International編著、DAMA日本支部、Metafindコンサルティング株式会社 監訳、日経BP
最新版のDMBOKでは、データ統合と相互運用性について以下のように説明されています。
データ統合はデータストア、アプリケーション、組織の内部および相互間におけるデータの移動と統合を表している。データの相互運用性とは様々なシステムが情報を連携する能力を表す。
出所：『データマネジメント知識体系ガイド 第二版 改定新版 』 DAMA International編著、DAMA日本支部、Metafindコンサルティング株式会社 監訳、日経BP
これらについては、書籍内の第8章に詳しく解説されていますので、興味がある方はぜひご一読ください。
出所：データマネジメント知識体系ガイド 第二版 改定新版 | 日経BOOKプラス
物理と仮想によるデータ統合
データ統合は、大きく「物理データ統合」と「仮想データ統合」の2つに分類されます。前者はデータを事前に移動・集約する方法で、後者はデータを移動せず仮想的に統合する方法です。
物理データ統合と仮想データ統合では、それぞれ性能やコストなど異なる特性を持つため、目的や利用シーンに応じて使い分けが必要です。仮想データ統合はデータ移動が不要な点で理想的に見えますが、性能やコスト面の注意が欠かせません。
データ統合が必要なケース
データ統合が必要となる主なケースは以下の4つです。近年は特に、DWH同士の連携が注目を集めています。
- 業務系システム間でのデータ統合
- 業務系システムからデータ分析基盤（DWH等）へのデータ統合
- データ分析基盤（DWH等）間でのデータ統合
- データ分析基盤（DWH等）から他システムへのデータ統合
DatabricksとSnowflake間のデータ統合の実施に向けて
DatabricksとSnowflakeを連携させる場合、まずはどのようにデータをロードするかを明確にし、必要となる機能を洗い出すことが重要です。下表に示すように、全件連携や差分連携などさまざまなパターンがありますが、実務で最もよく使われるのはパターン1と2です。
| # | 連携方法 | データローディングパターン |
|---|---|---|
| 1 | 全件連携 | 最後に連携されたデータで上書きする処理 |
| 2 | 差分連携 | 差分データを用いてUpsertする処理 |
| 3 | 差分連携 | 特定のカラム値に基づき選択的に上書きする処理 |
| 4 | 差分連携 | 一定期間のデータを上書きする処理 |
| 5 | 差分連携 | 連携されたデータをAppendする処理 |
| 6 | 履歴連携 | タイムスタンプで管理するSCD Type 2の差分履歴データを連携する処理 |
| 7 | 履歴連携 | ソースシステムの主キー列とINGEST_TIMESTAMPに基づいたUPSERT処理 |
| 8 | OTFによる連携 | Open Table Format（OTF）でデータを相互利用する方法 |
実装するパターンに応じて、必要な機能を検討する必要があります。
| # | 機能名 | 概要 |
|---|---|---|
| 1 | テーブルの上書き機能 | テーブルデータをソースのデータで置き換える機能。CTASやOVERWRITEが典型的。 |
| 2 | 変更データ提供機能 | テーブルにおける変更内容を提供する機能。DELETEレコードの特定が重要。 |
| 3 | ファイル取り込み機能 | 指定ディレクトリ上のデータを取り込む機能。ファイルのメタデータ取得や冪等性の担保が理想。 |
| 4 | データ取得機能 | 他システムからデータを取得する機能。 |
| 5 | 書き込み時のスキーマ進化機能（スキーマ展開機能） | ソースデータに応じてカラムの追加やデータ型の変更を行う機能。 |
DatabricksとSnowflake間のデータ統合パターン
DatabricksとSnowflake間でデータ統合を行う場合、以下のような方法があります。
| データ統合方法 | Databricks -> Snowflake | Snowflake -> Databricks |
|---|---|---|
| 全件連携 | - SparkによるOverwrite | - IcebergテーブルをソースとしてCTAS - 外部サービスで書き込み後にCTAS |
| 差分連携 | - CDFデータをMerge | - STREAMデータをMerge |
| OTFによる連携 | - UniFormでIcebergテーブル化 - Delta LakeをIcebergテーブル化 |
（実施方法は未検証） |
| 仮想データ統合 | （実施方法は未検証） | - Lakehouse Federation機能を利用 |
Databricks -> Snowflakeの差分連携については、下記の記事で詳しく整理しています。
出所：Snowflake のテーブルデータを Databricks に統合する方法の実装案 #Databricks - Qiita
また、Delta LakeをSnowflakeでApache Icebergテーブル化してデータ共有する方法については、下記の記事で取り上げています。
出所：Databricks のデータを Snowflake の Secure Data Sharing 機能でデータ共有する際のベストプラクティス - Qiita
Databricks にてデータ統合を行う際の主要トピック
メダリオンアーキテクチャの採用
Databricksでデータエンジニアリングを行う場合、メダリオンアーキテクチャが推奨されています。
出所：メダリオンアーキテクチャ (medallion architecture) | Databricks
具体的な実装方法については下記の記事が参考になります。
出所：誰も教えてくれないメダリオンアーキテクチャの デザインメソッド：JEDA データエンジニア分科会 #1 #Python - Qiita
チェンジデータフィード（CDF）による変更データの特定
Deltaテーブルのプロパティを有効化すると、レコードごとの変更内容を取得できるチェンジデータフィード（CDF）を利用できます。
出所：DatabricksでDelta Lakeのチェンジデータフィードを使用する | Databricks Documentation
DEEP CLONEによる異なるストレージへのデータ同期
他システム連携用ストレージにデータを配置したい場合、DEEP CLONE機能を利用すると、シンプルな構文で増分連携が可能になります。
出所：Databricks上でテーブルをクローンする | Databricks Documentation
Snowflakeへの書き込みはSparkコネクター推奨
JDBCコネクターよりもSparkコネクターを利用することで、ストレージを経由した並列処理が実行され、高い性能が期待できます。
出所：Sparkコネクターの概要 | Snowflake Documentation
Auto Loaderによるファイル取り込み
DatabricksではAuto Loader機能を利用することで、クラウドストレージ上のファイルを効率的に取り込むことができます。詳細は公式ドキュメントを参照してください。
CTAS時のスキーマ進化（スキーマ展開）と型拡張
CTASなどの書き込み処理時にスキーマ進化や型拡張が可能です。詳細は公式ドキュメントを参照してください。
UniForm機能によるApache Icebergテーブルの提供
DatabricksのUniForm機能を使うと、DeltaテーブルをApache Icebergの形式で読み取り可能にできます。詳細は公式ドキュメントを参照してください。
Lakehouse Federation機能による他データストアとの論理データ統合
DatabricksにはLakehouse Federationという機能があり、他システム上のデータを論理的に統合できます。詳細は公式ドキュメントを参照してください。
Unity Catalog有効時のApache Iceberg参照について
2025/04/22時点で、Unity Catalogが有効なクラスター上でApache Icebergテーブルを直接参照する方法は確立できていません。詳細は下記記事を参照してください。
Snowflakeにてデータ統合を行う際の主要トピック
マイクロパーティションのファイルサイズが他DWHと異なる点
Snowflakeのマイクロパーティションは他のDWHとは推奨ファイルサイズが異なるため、設計上の注意が必要です。詳細は以下の記事を参照してください。
出所：Snowflake における Apache Iceberg の機能の完全ガイド： Apache Iceberg on Snowflake 活用の第一歩 #Spark - Qiita
STREAM機能による変更データの特定
標準テーブルおよびIcebergテーブルでの変更データ検出にはSTREAM機能が利用できます。詳細は下記の記事を参照してください。
- Snowflake の標準テーブルをソースとした標準 STREAM の仕様検証 #Snowflake - Qiita
- Snowflake-managed Apache Iceberg™ table における STREAM 機能を試してみた #iceberg - Qiita
STREAM をソースとした CTAS 時にカラム追加が可能
下記の記事にて検証結果を記述しています。
出所：Snowflake の標準テーブルをソースとした標準 STREAM の仕様検証 #Snowflake - Qiita
出所：Snowflake の標準テーブルをソースとした標準 STREAM の仕様検証 #Snowflake - Qiita
COPY INTOによるファイル取り込みとスキーマ進化
SnowflakeではCOPY INTOを用いてクラウドストレージ上のファイルを取り込み、その際にスキーマを自動で進化させることもできます。詳細は公式ドキュメントを参照してください。
クラウドストレージ上のApache Icebergをテーブルとして登録可能
Snowflakeではクラウドストレージ上のApache Icebergファイルを直接テーブル登録できます。詳細は公式ドキュメントを参照してください。
- CREATE ICEBERG TABLE (Iceberg REST カタログ) | Snowflake Documentation
- CREATE ICEBERG TABLE （オブジェクトストレージ内のIcebergファイル） | Snowflake Documentation
Delta Lake形式のディレクトリをApache Icebergテーブルとして登録可能
SnowflakeはDelta Lake形式のディレクトリをApache Icebergテーブルとして扱うことができます。詳細は下記の記事を参照してください。