Microsoft Fabric におけるデータエンジニアリング

Microsoft Fabricにおけるデータエンジニアリング

目次

1. はじめに
2. 基盤となる「ワークスペース」の設計戦略
3. データエンジニアリングを支える主要コンポーネント
4. 実践的な開発フロー：データの取り込みから変換まで
5. Fabricならではの強み
6. 参考資料
7. おわりに

1. はじめに

iTOC事業部GDAI部の合田と申します。 今回はMicrosoft Fabricにおけるデータエンジニアリングについて、各機能やFabricならではの強みを紹介していきます。

従来のデータプラットフォーム構築では、ストレージ（ADLS Gen2）、計算リソース（Synapse/Databricks）、オーケストレーター（Data Factory）を個別にプロビジョニングし、それらを複雑に「配線」する作業に多大な工数がかかっていました。

Microsoft Fabric は、これら全ての機能を一つのSaaSプラットフォームに統合しました。データエンジニアにとっての最大の恩恵は、インフラのセットアップから解放され、「データの加工と活用」という本来の業務に即座に集中できるようになったことです。その核となるのが、全データが単一の論理湖に集約される OneLake という概念です。

2. 基盤となる「ワークスペース」の設計戦略

Fabricにおいて、ワークスペースは単なるフォルダではありません。これはガバナンス、計算リソースの管理、そしてコラボレーションの最小単位です。

ワークスペースの役割

• 計算リソース（Capacity）の割り当て: ワークスペースごとにF SKUなどのキャパシティを紐付けることで、プロジェクトごとのコスト管理や負荷分離が可能です。
• 権限管理（RBAC）: 「管理者」「メンバー」「投稿者」「閲覧者」の4つのロールを用いて、アイテムレベルではなく環境レベルでのセキュアな運用を実現します。
• 環境の分離: 開発（Dev）、テスト（Test）、本番（Prod）といったライフサイクルに合わせた分離が推奨されます。

推奨される構成パターン（メダリオンアーキテクチャ）

Fabricでは、データの精製度合いに応じてワークスペースを分ける設計が一般的です。

表１: ワークスペース例

項目	Bronze (Raw)	Silver (Stage)	Gold (Analytics)
ロール例	データエンジニア（収集担当）	データエンジニア / 分析エンジニア（加工担当）	データサイエンティスト / BI担当（活用担当）
役割	ソースデータの着地、生データ保持	クレンジング、標準化、スキーマ定義	ビジネスロジックの適用、集計
主要なアイテム	Shortcut, Data Factory, Lakehouse	Notebooks, Spark, Lakehouse	Lakehouse, Semantic Model, Power BI

表２: 権限管理例

機能	管理者	メンバー	共同作成者	ビューアー
ロール例	IT管理者・部門責任者	チームリーダー・上級開発者	データ分析官・開発担当者	意思決定者・一般閲覧ユーザー
ワークスペースを削除する	○	×	×	×
管理者を追加する	○	×	×	×
メンバーを追加する	○	○	×	×
データを書き込む	○	○	○	×
項目の作成	○	○	○	×
データの読み取り	○	○	○	○
ロール例	IT管理者・部門責任者	チームリーダー・上級開発者	データ分析官・開発担当者	意思決定者・一般閲覧ユーザー

3. データエンジニアリングを支える主要コンポーネント

Fabricのデータエンジニアリングは、単一のインターフェースから複数の強力なツールをシームレスに操作できる点が特徴です。データエンジニアリングを支える「Data Factory」「Data Engineering」のコンポーネントについて深掘りします。

引用: Microsoft Fabric とはより

■ Data Engineering

Spark の強力な計算能力と Lakehouse の柔軟な管理機能を統合したものです。単なるツールの集合体ではなく、データの取り込みから精製、さらには高度なバッチ処理までを一貫した UI で完結できる、モダンなデータプラットフォームの核となります。

• Lakehouse: データレイクの柔軟性とデータウェアハウスの管理機能を掛け合わせた、Fabricの心臓部です。

• Delta Lake 形式の標準化: すべてのテーブルはオープンソースの Delta Lake 形式で保持されます。これにより、ACIDトランザクション、タイムトラベル（履歴管理）、スキーマ強制が実現され、データの信頼性が担保されます。

• SQL エンドポイント: 特筆すべき点として、Lakehouseを作成すると自動的に「SQL分析エンドポイント」が提供されます。データエンジニアがSparkで加工したデータを、データアナリストは慣れ親しんだT-SQLを用いて即座にクエリできます。

• ファイルとテーブルの共存: CSVやParquet、画像、JSONなどの「ファイル」と、クエリ可能な「テーブル」を一元管理できるため、非構造化データの高度な分析にも対応可能です。

• Spark Job Definition: Notebookよりもさらに運用（本番）を意識したコンポーネントです。

  • コンパイル済みコードの実行: jarファイルやPythonファイルを直接アップロードしてスケジュール実行します。
  • CI/CDとの親和性: 定型化された大規模バッチ処理を、安定したリソース割り当ての下で実行するのに適しています。

• Notebooks: Sparkを用いたコードベースのデータ変換を行うメイン環境です。

  • インスタント・プール: 従来のSpark環境と異なり、クラスターの起動を待つ必要がほとんどありません。数秒でセッションが開始されるため、開発のイテレーションが劇的に速くなります。
  • マルチ言語サポート: 一つのNotebook内で PySpark, Spark SQL, Scala, R を使い分けることができ、エンジニアのスキルセットに合わせた最適な実装が可能です。
  • V-Order 最適化: Fabric NotebookがDeltaテーブルに書き込む際、独自の「V-Order」アルゴリズムが適用されます。これにより、データの圧縮率が向上し、後続のエンジン（特にPower BI）による読み取り速度が極限まで高められます。

■ Data Factory

Data Factory は、個別のデータ処理（Notebook や Spark Job）を一つの大きな「流れ」として統合するためのオーケストレーターです。単一の加工処理を超えて、データの取り込みから変換、後続処理への通知まで、エンドツーエンドのワークフローを自動化・視覚化する役割を担います。

• データパイプライン: GUI上で「Notebookの実行」「ストアドプロシージャの呼び出し」「条件分岐（If/Switch）」などを繋ぎ合わせ、エンドツーエンドのワークフローを構築します。
• Dataflows Gen2: Power Queryの直感的なUIでデータ加工を行い、その結果をLakehouseやAzure SQL Databaseなどの出力先に保存できます。
• 200以上のネイティブコネクタ: オンプレミスのSQL ServerからSaaSアプリケーションまで、広範なソースへの接続が統合されています。

4. 実践的な開発フロー：データの取り込みから変換まで

ここからは、具体的な開発ステップを通じて、Fabric を実務で使いこなすための実践的なアプローチを解説します。

Step 1: 「Shortcut」によるデータ仮想化

Fabric最大の強みの一つが Shortcut です。AWS S3、Google Cloud Storage、または他のAzureストレージにあるデータを「コピー（移動）」することなく、OneLake上のファイルとして直接参照できます。これにより、ETLの最初のボトルネックである「データ移動」を排除できます。

※実際にShortcutを作成したいレイクハウス内のエクスプローラー画面（左側）から作成できます（下図参照）。接続先ごとの詳細な方法はこちらのドキュメントを参照してください。

Step 2: Sparkによるクレンジングと変換

以下は、Lakehouse内の生データを取り込み、クレンジングしてDeltaテーブルとして保存するPySparkの例です。

# Raw層のCSVを読み込み
df = spark.read.format("csv").option("header","true").load("Files/raw/sales_data.csv")

# 重複排除とNULLフィルタリング
df_cleaned = df.filter(df["order_id"].isNotNull()).dropDuplicates()

# Silver層のDeltaテーブルとして書き出し（V-Orderが自動適用される）
df_cleaned.write.format("delta").mode("overwrite").saveAsTable("silver_sales")

Step 3: オーケストレーションの自動化

単発のデータ変換処理（Notebook）が完成した後は、それらを一連のワークフローとして統合し、無人運用を可能にする「オーケストレーション」の設定を行います。Fabric では Data Factory (Data Pipeline) を用いて、堅牢なパイプラインを構築します。

■ 柔軟な制御フローの構築

Fabric のパイプラインは、単なるジョブの直列実行に留まりません。

• 依存関係の制御: 「Notebook A が成功したら B を実行、失敗した場合は管理者へ通知しクリーンアップ用の処理 C を実行する」といった条件分岐（On Success / On Failure）を視覚的に定義できます。
• 動的なパイプライン: パイプライン内で「実行日付」や「対象フォルダ」を変数として保持し、Notebook の引数（Parameters）として渡すことで、一つのパイプラインで複数のデータソースを動的に処理することが可能です。
• 繰り返し処理 (For Each): 大量のテーブルやファイルをループ処理で順次変換するような、スケーラブルなワークフローも容易に実装できます。

■ エンタープライズレベルの運用管理

本番環境での運用に耐えうるエラーハンドリング機能が充実しています。

• 再試行（Retry）ポリシー: 一時的なネットワークエラーやリソースの競合に備え、アクティビティ単位で「5分間隔で最大3回リトライ」といった自動復旧設定が可能です。
• アラート通知: パイプラインが失敗した際、即座に担当者の Teams チャネルやメールへ、エラー内容を含む通知を送信するアクティビティを組み込めます。

■ トリガーによる実行制御

• スケジュール実行 : 「毎日 AM 2:00」といった定時実行はもちろん、分単位の実行スケジュールも設定可能です。
• イベントトリガー: OneLake 上の特定フォルダへのファイル着信を検知してパイプラインを自動起動する、イベント駆動型のデータパイプラインも構築できます。

■ CI/CD とリポジトリ連携

Fabric ワークスペースは Azure DevOps や GitHub とネイティブに連携します。パイプラインの定義を Git で管理することで、開発環境でテストした自動化フローを、検証・本番環境へと安全かつ迅速にデプロイする「モダンなデータエンジニアリング」の実装が可能になります。

5. Fabricならではの強み

データエンジニアリングの最終目的は、加工したデータをビジネスユーザーに届けることです。Fabric において、その橋渡しを劇的に進化させるのが Direct Lake モード です。

■ 「インポート」と「直接参照」のいいとこ取り

これまで Power BI で大規模データを扱うには、主に2つの選択肢しかありませんでした。

1. インポートモード: 高速だが、データの複製（更新処理）が必要。容量制限やデータ鮮度のタイムラグが課題。
2. DirectQuery モード: 常に最新だが、ソース DB へのクエリが発生するため、パフォーマンスが低下しやすい。

Direct Lake は、OneLake 上の Delta テーブル（Parquet ファイル）を Power BI エンジンが直接メモリにロードして読み取ります。これにより、インポートの「高速性」と DirectQuery の「最新性」を同時に実現しています。

■ データエンジニアにとってのパラダイムシフト

• 更新パイプラインの簡略化: これまで「データ加工完了 → Power BI セマンティックモデルの更新」という二段構えのジョブ管理が必要でしたが、Direct Lake では Gold 層のテーブルを書き換えた瞬間、レポートの準備が整います。
• Single Source of Truth（信頼できる唯一の情報源）: Power BI 用に別途データを保持する必要がないため、データの重複によるコスト増や、数値の不一致というリスクを根絶できます。
• 大規模データへの対応: インポートモードの制限を超えるような数億件のレコードであっても、メモリ効率の高い Parquet 形式を直接扱うため、ユーザーはストレスなく分析を行えます。

■ パフォーマンスを支える「V-Order」

Direct Lake がこれほどまでに高速なのは、前述した V-Order 最適化が効いているためです。Notebook で書き込む際にデータが再ソート・圧縮されることで、Power BI エンジンがスキャンするデータ量を最小限に抑え、大規模データセットでもミリ秒単位のレスポンスを可能にしています。

Microsoft Fabric V-order 実装例まとめ

V-orderは、Delta形式のデータをPower BIエンジン（VertiPaq）に最適化された形式で書き込む技術です。以下に主要な3つの実装パターンをまとめます。

Case 1: Spark Notebook (PySpark)

データ変換処理の最終ステップで適用するパターンです。

# セッション全体でV-orderを有効化
spark.conf.set("spark.sql.parquet.vorder.enabled", "true")

# 書き込みオプションで指定して保存
(df.write
    .format("delta")
    .option("vOrder", "true")
    .mode("overwrite")
    .saveAsTable("fact_sales_vorder")
)

Case 2: SQL (Lakehouse / Warehouse)

既存テーブルに対し、メンテナンスとして事後的に最適化をかけるパターンです。

-- OPTIMIZEを実行すると、ファイル結合と同時にV-orderが適用されます
OPTIMIZE fact_sales_vorder;

-- Z-Order（特定の列での並べ替え）と併用する場合
OPTIMIZE fact_sales_vorder 
ZORDER BY (ProductKey, TransactionDate);

Case 3: Data Factory (Pipeline / Copy Activity)

GUIのコピーアクティビティ設定（Sinkタブ）で有効化するパターンです。

{
    "type": "Copy",
    "sink": {
        "type": "LakehouseTableSink",
        "formatSettings": {
            "type": "DeltaFormatSettings",
            "enableVOrder": true
        }
    }
}

V-order 実装の判断基準

V-orderは「書き込みコストを払って、読み取り速度を買う」技術です。すべてのテーブルに適用するのではなく、以下の基準で判断することをお勧めします。

• メリットとデメリットの比較

項目	特徴	判断への影響
読み取り性能	Power BI（Direct Lake）やSQLでのスキャンが劇的に高速化	プラス： レポートの応答速度を改善したい場合に必須
圧縮率	データの並べ替えにより、ストレージ容量をさらに削減可能	プラス： ストレージコストを抑えたい場合に有効
書き込み時間	高度なソートを行うため、通常の書き込みより15%〜30%程度時間が延びる	マイナス： ETLの処理時間（バッチウィンドウ）が厳しい場合は注意
リソース消費	書き込み時のCPU・メモリ消費量が増加する	マイナス： コンピューティング容量（CU）の消費が増える

• 推奨されるケース（適用すべき）

  • Goldレイヤーのファクトテーブル: Power BIから頻繁に参照される大規模な集計用テーブル。
  • Direct Lakeモードを利用する場合: Direct Lakeの性能を最大限に引き出すための標準的なプラクティスです。
  • 履歴データ: 一度書き込んだ後は更新されず、参照のみが行われるアーカイブデータ。

• 非推奨・検討が必要なケース（適用を控える）

  • Bronzeレイヤー（生データ）: 取り込み速度が最優先されるため、ここでは最適化せず、後続のレイヤーで実施すべきです。
  • 頻繁に更新される小規模テーブル: 書き込み負荷のデメリットが、読み取り速度のメリットを上回ります。
  • リアルタイム性が極めて高いデータ: 数分おきに書き込みが発生する場合、V-orderによる遅延がボトルネックになる可能性があります。

• 判断フローチャート（簡易版）

  • そのテーブルは Power BI から参照されるか？
    • No → V-orderなし（通常のParquet/Deltaで十分）
    • Yes → 次へ
  • データサイズは十分に大きいか（例：1GB以上、数百万行以上）？
    • No → V-orderなし（オーバーヘッドの方が大きい）
    • Yes → V-order適用を推奨
  • ETLの実行時間に余裕はあるか？
    • No → クリティカルなテーブルにのみ限定して適用
    • Yes → V-order適用を推奨

6. 参考資料

本記事の執筆にあたり、以下の Microsoft 公式ドキュメントおよび技術リソースを参照しました。
より詳細な情報や最新のアップデートについては、以下の公式リソースを参照してください。

■ Microsoft Fabric 公式ドキュメント

• Microsoft Fabric でのデータ エンジニアリングとは?

  • Fabric における Spark や Lakehouse の基本的な役割とコンポーネントの解説。

• Microsoft Fabric ワークスペースのロール

  • 各ロール（管理者、メンバー、共同作成者、ビューアー）が実行可能な操作の詳細な比較表が記載されています。

• Microsoft Fabric の意思決定ガイド: ワークスペースの計画

  • 管理境界、セキュリティ、コストに基づいたワークスペースの分割基準。

• Microsoft Fabric でのメダリオン レイクハウス アーキテクチャのガイド

  • Bronze、Silver、Goldの各レイヤーの役割と、推奨されるデータ構造についての公式ガイドです。

• Microsoft Fabric でメダリオン Lakehouse アーキテクチャを実装する

  • Bronze/Silver/Gold レイヤーの設計指針と、ワークスペース分離の推奨事項。

• OneLake Shortcutの概念

  • データをコピーせずに統合する「Shortcut機能」の技術仕様と作成方法。

• Power BI と Microsoft Fabric の Direct Lake について学習する

  • インポート不要で超高速にデータを参照する Direct Lake モードの仕組み。

• Direct Lake モードの概要

  • V-orderがPower BIの読み取り（Direct Lake）にどのように寄与するかについての解説です。

• Delta Lake テーブルの最適化と V-Order

  • Fabric 独自の書き込み最適化技術（V-Order）が読み取りパフォーマンスに与える影響について。

• Data Factory でのパイプラインの監視とエラー制御

  • 失敗時（Upon Failure）の分岐ロジックや監視ハブの利用方法に関するリソースです。

7. おわりに

Microsoft Fabricにおけるデータエンジニアリングは、「OneLake」によるデータの物理的な統合と、「ワークスペース」による論理的な統制が鍵となります。 従来のアーキテクチャのような複雑なリソース管理に時間を溶かす必要はありません。まずは、既存の外部ストレージを「Shortcut」で繋ぎ、Notebookで一つテーブルを作ってみることから始めてみてください。
また、一緒に働いていただける仲間も募集中です！ エーピーコミュニケーションズやLakehouse部にご興味がある方は問い合わせいただければ幸いです。 hrmos.co