Microsoft Fabricのdbtジョブは、Fabricデータプラットフォームの一部としてdbtプロジェクトを管理型で実行する方法を提供します。 チームがモジュール化されたSQLベースの変換、テスト、依存関係管理、ソース制御分析エンジニアリングを求める際に、Fabricが取り込み、ストレージ、オーケストレーション、監視、消費を提供する場合に利用してください。
正しいメダリオンデザインは一つもありません。 ブロンズ、シルバー、ゴールドはFabric Data Warehouse、レイクハウス、または両方を使えます。 最適な選択は、データの行き先、どのエンジンが変換を実行するか、キュレーションされたデータがどのように提供されるか、そしてdbtが独立して動作するのか、それともより大きなFabricパイプラインの一部として動作するのかによって異なります。
パターンを決めてから実行しましょう
ブロンズはソースに沿ったデータを保持し、シルバーはそれを標準化・検証し、ゴールドは分析のために整理します。 DBTはシルバー境界、ゴールド境界、またはその両方を所有することができます。 要件が許す限り実装はシンプルにし、各責任を明確にしてください。 Fabricパイプラインは、このガイドで説明されている任意のパターン間で、取り込み、DBT実行、検証、通知、下流の活動をオーケストレーションできます。
概要
| Pattern | 銅 | シルバー | 金 | 最適 |
|---|---|---|---|---|
| 1. 倉庫専用 | Warehouse | Warehouse | Warehouse | SQLファーストのウェアハウスワークロード |
| 2. レイクハウス着陸場+倉庫 | Lakehouse | Warehouse | Warehouse | オープンフォーマットのランディング、SQLサービング |
| 3. レイクハウスの洗練 + 倉庫 | Lakehouse | Lakehouse | Warehouse | レイクエンジニアリング、BIサービス |
| 4. レイクハウス専用 | Lakehouse | Lakehouse | Lakehouse | デルタ優先ワークロード |
パターン1:倉庫専用メダリオン
ブロンズ、シルバー、ゴールドは Fabric Data Warehouse に保持します。 レイヤーを分離するためにスキーマを使うか、倉庫アイテムを別々に使いましょう。
図 1. 倉庫限定のメダリオン。
このパターンは以下の時に使う: ソースは主にリレーショナルで、チームはSQLを優先し、ウェアハウスは自然な変換とサービスプラットフォームです。
DBTがどこに位置するか: DBTは変換、テスト、モデル依存関係、キュレーションされたマートを管理します。 ステージング、中間層、マーティアなどの論理的dbtレイヤーは、同一の概念として扱われることなくウェアハウススキーマにマッピングできます。
Fabric の位置付け: Warehouse はモデルを格納し、実行します。 Fabricパイプラインは取り込みと実行を調整できます。 Power BIはキュレーションされたGoldレイヤーを消費します。
なぜ選んだのか
- すべての層に対応するSQL中心のプラットフォームを一つに。
- 仕事量が不要なときにSparkを導入するのを避けています。
- 倉庫の移行や次元BIのワークロードに適合します。
Considerations
- Warehouse Bronzeはファイルネイティブではなくリレーショナルなランディングゾーンです。
- 半構造化やファイル処理型のワークロードはLakehouseの方が合っているかもしれません。
- 開発と生産のオブジェクトは意図的に分けています。
パターン2:レイクハウス着陸と倉庫変形
生データをLakehouseに置き、Warehouseでdbtを使ってシルバーとゴールドのモデルを構築します。
図 2. レイクハウスのランディングと倉庫変形。
このパターンは以下の時に使う:生データがOneLakeに届く場合はこのパターンを使いますが、SQL優先のチームはT-SQLを使ってシルバーモデルとゴールドモデルの両方をFabric Data Warehouseで構築したいと考えています。 このアプローチは、変革とサービスを一つの関係エンジンにまとめて行うことができます。
dbtが当てはまる点: dbtはT-SQLのデータベース間クエリと3段階の命名(例えば LakehouseName.dbo.TableName)を用いて、読み取り専用SQL分析エンドポイントを通じてLakehouseデータを読み込みます。 このアクセスパスは同じFabricワークスペース内のアイテムに限定されます。 クロスワークスペースのシナリオでは、OneLakeショートカットを使って必要なデルタテーブルを公開できます。
Fabric の位置付け: Lakehouse は生データを保持します。 倉庫店舗は関係型モデルを順応し、キュレーションしました。 パイプラインは取り込みとDBTの実行を調整します。
なぜ選んだのか
- オープンフォーマットの生ストレージとSQLファーストのサービングレイヤーを組み合わせています。
- 銀と金の変身をFabric Data Warehouseに抑え、複数の変身エンジンを同時に運用する必要が減ります。
- 生データから次元モデルへの明確な移行を生み出します。
Considerations
- クロスワークスペースアクセスには、OneLakeのショートカットを使って、消費ワークスペース内で必要なDeltaテーブルを利用可能にする必要があります。
- Lakehouse Tablesエリア内のDeltaテーブルのみがSQL分析エンドポイントを通じて利用可能です。
- メタデータ同期の挙動や、サポートされるDeltaデータ型とT-SQL型の違いを考慮してください。
- Lakehouse SQL分析エンドポイントは読み取り専用です。 dbtはターゲット倉庫にシルバーとゴールドのモデルを具現化します。
- LakehouseとWarehouseの両方を使うと、追加の運用境界が生まれます。
パターン3:レイクハウスの洗練と倉庫でのサービス
Lakehouseでブロンズとシルバーを使い、キュレーションされたゴールドモデルをWarehouseに公開します。
図 3。 LakehouseのリファインメントでWarehouseが提供されています。
このパターンは以下の時に使う:データエンジニアリングチームがDelta指向のツールを使ってLakehouseでブロンズおよびシルバーデータを洗練・保持し、分析やBIチームがFabric Data Warehouseにキュレーションされたゴールドモデルを公開する際には、このパターンを選びましょう。 このアプローチは、レイクハウスの洗練と倉庫サービスエリアの境界線を明確に示しています。
dbtの適用領域: dbtは、明確に分けたプロジェクトまたはジョブによって、レイクハウスの変換、データウェアハウスのゴールドモデル、またはその両方を担えます。 各プロジェクトはアダプター、ターゲット、所有権の境界に沿って調整してください。
Fabric の位置づけ: Lakehouse は、ファイルネイティブなストレージとデータ整備を提供します。 Warehouseは関係性のあるサービスを提供します。 パイプラインは変換段階間の依存関係を強制します。
なぜ選んだのか
- データエンジニアリングチームはDelta指向の洗練にLakehouseを使い、分析やBIチームはリレーショナルサービングにFabric Data Warehouseを使います。
- 寸法BI用のキュレーションされた倉庫面を提供します。
- 詳細なシルバーデータを保存し、より広範な利用に備えます。
Considerations
- LakehouseおよびWarehouseのトランスフォーメーション段階を運用するには、両エンジンにわたるスキルが必要であり、展開、テスト、監視の複雑さが増加します。
- LakehouseとWarehouseの両方で同じルールを導入するのは避けてください。
- 銀と金の間に明確な契約を定義してください。
パターン4:レイクハウス専用メダリオン
ブロンズ、シルバー、ゴールドはレイクハウスに置いておく。 Fabric Lakehouseアダプター(dbt-fabricspark)を使って、Fabric Livy APIを通じてDBTモデルをSpark SQLとして実行し、結果をOneLakeでDeltaテーブルとして書き込むことができます。
図 4. レイクハウス限定のメダリオン。
このパターンは以下の時に使う: プラットフォームはLakehouseを優先しており、データはDelta形式のままにしておくべきであり、チームはdbtのプロジェクトの構造とテストを求めています。
dbtがどこに位置するか: dbtは選ばれたLakehouse変換、テスト、依存関係、マテリアライゼーションを所有しています。 物理的分離にスキーマ、個別のレイクハウス、または別のガバナンス境界のいずれを使用するかを決定してください。
Fabricがどこに位置するか:OneLakeとLakehouseがデータを保存します。 パイプラインは取り込みと変換を指揮します。 Power BIは、レポーティングやガバナンスの要件に応じて、Direct Lake、DirectQuery、またはImportを通じてキュレーションされたLakehouseデータを利用可能です。
なぜ選んだのか
- アーキテクチャ全体でデータをデルタ形式で保持します。
- レイクハウスとウェアハウス間の移動を減らします。
- 湖を中心とした運営モデルやSpark志向の運用モデルに適合します。
Considerations
- Lakehouse SQL分析エンドポイントは読み取り専用で、DBTモデルの結果を書くためには使われていません。 変換にT-SQL実行が必要な場合は、代わりにFabric Data Warehouseアダプターを使いましょう。
- Fabric LakehouseとFabric Data Warehouseアダプターは異なる実行エンジンを使用し、異なる機能をサポートしています。
- 選択したアダプターがプロジェクトに必要なSQL方言、マテリアライゼーション、パッケージ、コマンドをサポートしているか確認してください。
- 倉庫中心のBIワークロードにはリレーショナルゴールドレイヤーを導入Fabric Data Warehouseを検討してみてください。
オーケストレーションモデルを選択する
ストレージと変換パターンを選んだら、DBTジョブのオーケストレーション方法を決めます。 ジョブを独立してスケジュールすることも、Fabricパイプライン内のアクティビティとして実行することも可能です。
図 5. 取り込み、検証、ダウンストリーム処理を含む dbt をオーケストレーションする Fabric パイプライン。
ネイティブスケジューリングを使う場合:
- DBTの仕事は独立して定期的に行われるスケジュールで運営されています。
- この仕事は上流や下流の Fabric 活動に依存しません。
- ジョブレベルの監視は運用要件を満たしています。
以下の場合にFabricパイプラインを活用してください:
- インジェスション、DBT実行、検証、通知、または下流処理は一つのワークフローとして実行されなければなりません。
- ワークフローには成功、失敗、完了の依存関係が必要です。
- ランタイム設定は動的なコンテンツでパラメータ化されなければなりません。
- チームはパイプラインの実行履歴を通じてエンドツーエンドのワークフローを監視したいと考えています。
Fabricパイプラインはワークフロー依存関係、パラメータ、障害経路、通知、統合監視を管理します。 DBTは変換ロジック、モデル選択、テスト、依存関係、マテリアライゼーションを引き続き担当しています。 パイプラインオーケストレーションはDBTのプロジェクトレベルのテストや依存関係管理に代わるものではありません。
実装原則
- インジェスト、シルバー精錬、ゴールドモデリング、オーケストレーション、セマンティックモデリングの明確な所有権を定義してください。
- dbtのステージング、中間、マートを論理モデル群として扱います。これらは自動的にブロンズ、シルバー、ゴールドの物理層と同じではありません。
- dbt、ノートブック、パイプライン、ストアドプロシージャ間での変換ロジックの重複は避けてください。
- 独立したジョブにはネイティブスケジューリングを、マルチアクティビティワークフローにはFabricパイプラインを使いましょう。
- 実行時の挙動を考慮してください。 dbt job runtime V1.0はビルドキャッシュやアーティファクト再利用をサポートしていません。 各実行はソースからプロジェクトをコンパイルし実行します。 大規模プロジェクトでは、スケジューリングウィンドウやSLAの見積もりに、コンパイルと実行の全時間を含めてください。