はじめに
それぞれの特徴がありつつも、大枠ではできることが似ている
Microsoft FabricとDatabricks。
Azure Databricks Unity カタログのミラーリングを通してDatabricksの管理するデータについてFabricで参照できるようになりましたが、データの編集は依然としてできません。
そんな中以下のような悩みが浮かびあがってくると思います。
- 他部署がDatabricksを利用してるテーブルをうちの部署のFabricから利用できないのかな、
- 作成したテーブルをツールによらずオープンに変更、参照したい!
- 現在Databricksを使用中だけど、将来的にFabricに移行するかも、、常にベンダーフリーのスタンスでいきたい
- ビジネスサイドの社員はFabricを使っててエンジニアたちはDatabricksを使ってるけど、同じテーブルを参照することがあるんだよなぁ
そこで今回は
- Databricks で作成したテーブルをFabric で利用する
-
Fabric で作成したテーブルをDatabricksで利用する
というFabricとDatabricksをシームレスに活用するユースケースを紹介します
この記事は4部構成です
1.相互運用性の概要・目的(本記事)
2.hubストレージの具体的な設定方法
3.Fabricで作成したテーブルをDatabricksで利用する
4.Databricksで作成したテーブルをFabricで利用する
前提:FabricとDatabricksって機能が似たり寄ったり、、結局どっち使えばいいの?
FabricとDatabricksは、どちらもデータをEnd-to-Endで扱うLakehouseプラットフォームとして注目されています。
業界未経験の私が初めて触れた印象では、
「大体同じことができるのでは?」 という感想を持ちました。
ETLの処理も可能で、AIモデルの作成にも対応しています。
Fabricは初心者にも優しいGUIが充実しており、直感的に操作できる設計が魅力です。
一方で、Databricksはコードベースの作業が中心となるため、やや高度なスキルが求められる印象を受けました。
またコンピュータリソースをFabricよりも自由にカスタマイズできる点やこまめにクラスタを停止すればコストもFabricより抑えられる点ではDatabricksいいなという感じです。
使いやすさと柔軟性のどちらを重視するかで選択が変わるプラットフォームだと感じています。
▽参考
相互運用性の方法を考える
ここではどのような方法を使用すれば、FabricとDatabricksの相互運用性を実現できるか考えていきます。
①Unity カタログのミラーリング(FabricからDatabricksへのDMLが現状サポートされておらず)
Azure Databricks Unity カタログのミラーリング (プレビュー)を使用すれば、FabricからDatabricksのテーブルの参照(SELECT文)は可能ですが、編集(DML文) は現状サポートされていないようです。
よって相互運用性の方法としては不採用。
※認識違いましたらご指摘お願いします🙇
②Databricksから外部ロケーションでOneLakeを指定(現状サポートされておらず)
クラウドストレージをAzure Databricksに接続するための外部の場所を作成する を OneLake に対して構成してみましたが、現状はサポートされていませんでした。
この方式で作成できることを期待していましたが、残念ながらできず、、
よってこちらも相互運用性の方法としては不採用。
▽参考
③hubストレージという解決策
ミラーリングと外部ロケーションがダメだったので
テーブルの実態をAzure Data Lake Gen 2(ADLS2)に格納し、
FabricからはADLS2へのスキーマショートカット、
Databricksからはカタログのストレージの場所としてADLS2を指定してあげることで
Fabric、DatabricksからともにSELECT文もDML文も可能になります。
つまり、この方法だとFabricとDatabricksの相互運用性が可能になります!
またこれ以降、このADLS2のことをhubストレージと呼んでいきます。
▽具体的な設定方法については以下の記事を参照
hubストレージが成り立つのはDelta Lakeのおかげ
これまで解説したように、hubストレージならば、FabricとDatabricksの相互運用性が可能です。
ですが、なぜこのような相互運用性が可能になるのでしょうか?
その秘密は Delta Lake という仕組みにあります。
Delta Lakeの仕組み
Delta Lakeは、データレイク上にトランザクション管理とスキーマ管理のレイヤーを提供するオープンソースのストレージレイヤーです。その基盤となるデータ形式は Parquet と JSON の組み合わせです。Parquetは列指向の圧縮フォーマットで、高速なクエリとデータ圧縮を実現します。一方、JSONはトランザクションログとして使用され、データ変更履歴やバージョニングを記録します。
このように、Delta Lakeの仕組みを利用することで、hubストレージは高度なデータ共有と操作を実現しています。FabricやDatabricksを利用する際には、このDelta Lakeが提供する機能の恩恵を最大限に活用できるよう、基盤となる仕組みを理解することが重要です。
▽Delta Lakeの詳しい仕組みについては公式ドキュメントを参考ください。
おわりに
本記事で、FabricとDatabricksの相互運用性ための目的やその方法の概要をまとめました。
次の記事ではhubストレージの設定方法を具体的に紹介します。
▽次の記事へ