Microsoft Fabric 移行ポイントの所見や データ活用コラボレーションについて Microsoft MVP for Data Platform 永田 亮磨 Twitter: @ryomaru0825 Linkedin: ryoma-nagata-0825 Qiita: ryoma-nagata

自己紹介 永田 亮磨(Ryoma Nagata) • Microsoft MVP for Data Platform • Databricks Solutions Architect Champion • 株式会社ジール • Microsoft Data Analytics Solution の導入など • 主な活動場所 • Qiita : @ryoma-nagata • Twitter : @ryomaru0825 • connpass : • JSSUG (Japan SQL Server User Group) • JEDAI - The Data & AI Meetup MVP Profile 推しサービス(≒守備範囲） Synapse / Databricks / Power BI / Machine Learning Purview / Microsoft Fabric

• Fabric と Cloud Data Warehouse / Lakehouse 構成の比較とAzureからの移行のポイント • Microsoft Fabric 上でのコラボレーション、データドメインについて Agenda

Fabric と Cloud Data Warehouse / Lakehouse 構成の 比較とAzureからの移行のポイント

補足）データ分析の基本的流れ データ収集・整備 データ保管 クエリ、分析のためのDB化 活用 タイムライン

補足）データ分析の基本的流れ データレイク データ インテグレーション データ エンジニアリング データ収集・整備 データ保管 DWH/レイクハウス リアルタイム分析 クエリ、分析のためのDB化 BI データサイエンス 活用

補足） これまでの Azure データ基盤コンポーネントとなる基本製品 生データ 標準化 分析 サンドボックス Azure Data Lake Storage Gen2 データレイク データ インテグレーション データ エンジニアリング BI Azure Synapse Analytics Azure Databricks データサイエンス Azure Data Factory DWH/レイクハウス Azure Machine Learning リアルタイム分析 Azure Data Explorer

補足） Microsoft Fabric でのワークロードと製品マッピング 生データ 標準化 分析 サンドボックス OneLake データレイク データ インテグレーション データ エンジニアリング BI Synapse Data Engineering データサイエンス Data Factory DWH/レイクハウス Synapse Data Science Power BI リアルタイム分析 Real Time Analytics Synapse Data Warehousing

DWH + BI Azure Synapse Analytics Azure Data Factory (パイプライン) データフロー Gen1 よくある構成 Fabric による再現 SQL Data Factory （パイプライン、データフロー Gen2） Azure Data Factory (Mapping) データセット レポート Power BI Service Data Factory (データフローGen2) SQL Synapse Data Warehouse （ウェアハウス） モデルビュー （＝既定のデータセット） データビュー データセット レポート Power BI Service データフローGen1 は従来通り利用可能だが、Fabric 上ではGen2が 提供され、DWH/レイクハウス上で前処理をするように機能提供された

Data Lake + DWH + BI Azure Synapse Analytics Azure Data Factory (パイプライン) データフロー Gen1 Azure Storage Amazon S3 SQL SQL Data Factory （パイプライン、データフロー Gen2） Synapse Data Warehouse （ウェアハウス） Azure Data Factory (Mapping) Azure Data Factory (Mapping) Synapse Data Engineering （レイクハウス内のFiles） Data Factory (データフローGen2) Synapse Data Engineering (Spark ノートブック) Databricks (Spark ノートブック) データセット レポート Power BI Service データセット レポート Power BI Service モデルビュー （＝既定のデータセット） Data Factory (データフローGen2) データビュー よくある構成 Fabric による再現

Data Lakehouse + BI Azure Data Factory (パイプライン) データフロー Gen1 Data Factory （パイプライン、データフロー Gen2） Azure Data Factory (Mapping) データセット レポート Power BI Service Databricks (Spark ノートブック) Azure Storage Amazon S3 Databricks Synapse Data Engineering (Spark ノートブック) Synapse Data Engineering (レイクハウス) 表示：レイクハウス モデルビュー （＝既定のデータセット） 表示：SQLエンドポイント SQL Warehouse レイクハウスにはSparkを使用した処 理だけでなく、BIツールなどSQLで接 続するための機能が存在する Power BI Service データセット レポート Data Factory (データフローGen2) データビュー よくある構成 Fabric による再現

• 2023/9 時点で筆者が公開情報を確認した結果となります。 Fabric は一般提供前のプレビュー状態であり、 （特にAzure の同名製品からの移行については）一般提供時に大きな改善が予想されます。 • 本評価を実施した趣旨は以下であることご理解の上ご参照いただきますようお願いいたします。 • 今後のアップデート情報を楽しむための現状の状態を把握する • きたる一般提供にむけてどういった評価観点を持って備えておくべきか 移行ポイントの評価について免責事項

Data Factory / Synapse Pipeline の移行ポイント 2023/9 時点 • Fabric と Azure の Data Factory の違い - Microsoft Fabric | Microsoft Learn Data Factory 主要成果物 Fabric アイテム 移行性 移行に関する評価 パイプライン データパイプライン × • ほぼ同様のUI、仕組み、json表現など共通点は多いため機能の再現は可能ではあるが、コピーのシンク先の種類の差 異（レイクハウスなど）や、アクティビティの種類に差異があるため原則UIでの作り直し作業が必要なため移行負荷は高 い リンクサービス （接続） 移行不要 • Fabric の接続は現時点では個人レベルで管理されるため、リンクサービス同等の複数人で再利用可能な接続定義で はなく移行不要 データセット - 移行不要 • Fabricにはデータセット同等の再利用可能なスキーマ定義機能はないため移行不要 マッピングデータフロー データフロー Gen2 × • マッピングデータフローはPower Query に変換することは難しい。あらためて処理内容を整理し、再作成が必要な経路 となる Spark ノートブック △ • MS CSAの方が作成したツール(java)があるが、制限も多い GitHub - sethiaarun/mapping-data-flow-to-spark: Fast and Easy to convert Mapping data flows from Azure Data Factory to Microsoft Fabric Notebook and Spark Job. セルフホステッド統合ランタイム オンプレミスデータゲートウェイ 移行不要 • 以前はPower BI用のオンプレミスデータゲートウェイと別でセルフホステッド統合ランタイムが必要だったが、Fabric では 一本化されているため不要（現時点では） トリガー - 移行不要 • パイプラインのスケジュール設定で直接設定となるため不要 〇：軽微な修正か修正作業なしで簡単（インポートエクスポートなど）に移行可能 △：部分的には軽微修正で移行可能だが再現不可の箇所がある ×：互換性がなく設計しなおし、作り直しが必要

• サーバーレスSQL Pool同等の OpenRowset を主軸とした論理DWH機能はないため除外 Synapse 専用SQL Pool の移行ポイント 2023/9 時点 • Fabric と Azure の Data Factory の違い - Microsoft Fabric | Microsoft Learn 専用SQLPool 主要成果物 Fabric アイテム 移行性 移行に関する評価 データ ウェアハウス （Delta Parquet） 〇？ • 次スライドの Fabric リンクを利用することでレプリケーションが可能となる見込み（プレビューでの利用不可 SQLコマンド およびオブジェクト （テーブル、ビュー、ストアドプロ シージャなど） ウェアハウス （クエリ） △ • 基本的なSQLコマンドは動作するが、Truncate 構文が使えないなどの細かい構文のサポート範囲が異なる • 現在のところテーブル名に関して、Microsoft Fabric のウェアハウスの Delta Lake ログ の制約事項にもとづいて名称 の制約があるため、チェックが必要 • 専用SQL Poolのテーブルに固有のDistribution 設定は存在しない 〇：軽微な修正か修正作業なしで簡単（インポートエクスポートなど）に移行可能 △：部分的には軽微修正で移行可能だが再現不可の箇所がある ×：互換性がなく設計しなおし、作り直しが必要

• Microsoft Fabric - Next Generation Cloud Data Analytics Solution - Qiita

• 原則として、Fabric は Power BI サービスに機能が追加されているだけとも言えるので、基本的に大きな移行は発生せず、これまで通りと変わらない利用が可能 • Fabric 固有のDirect Lake モードなどの利点を生かすための変更を移行とみなして記載する • Direct Lake にはまだまだ固有の制限事項もあるため、インポートモードで利用する場合には移行は発生しないか、データソースの向き先を変えるのみとなる Power BI の移行ポイント 2023/9 時点 Power BI 主要成果物 Fabric アイテム 移行性 移行に関する評価 データセットとPower Query データセット （カスタム or 既定） △ • Direct Lake モードを利用するためには、現在のところ、3rd Party ツールか、Fabric 上でデータセットを生成する櫃由 生がある。 • Power BI Desktop上でデータの加工などを行っている場合その処理をデータフローに移行してSQL エンドポイントか ウェアハウスとして保持する必要がある。 レポート レポート 〇 （データセットと 分離されていない 場合：△） • レポートとデータセットが分離された状態であれば、データセットを変更すればOK • 分離されていない場合には手動でデータセットとは別のファイルでレポートを作り直すなどの対応が必要となる • あるいは、 3rd Party tool or Power BI developer モードでのコード編集により簡易化できる可能性あり データフロー Gen1 データフロー Gen2 〇 • Power Query テンプレートを使用して簡単に移行可能 データマート（プレビュー） ウェアハウス × • データマートの定義を出力することはできないため、再作成が必要 〇：軽微な修正か修正作業なしで簡単（インポートエクスポートなど）に移行可能 △：部分的には軽微修正で移行可能だが再現不可の箇所がある ×：互換性がなく設計しなおし、作り直しが必要

• Fabric上の Power BI データセットには新しいストレージモードである「Direct Lake」が利用可能です。 • 主なベネフィット： • Import モード並の性能ながら従来の更新処理が不要 • Direct Query モードと同等のリアルタイム性（データ鮮度） • 参考： • 旧来のストレージモードの解説：改めてPower BI データセットのストレージモードについて整理する - Qiita • Power BI と Microsoft Fabric での Direct Lake について説明する - Power BI | Microsoft Learn Power BI の新モード：Direct Lake について • Power BI と Microsoft Fabric での Direct Lake について説明する - Power BI | Microsoft Learn

• 現在、レイクハウス上のDelta Lake テーブルのみがDirect Lakeの対象となります。 • その他のテーブルが含まれるデータセットは利用不可 • ウェアハウスは現在対象外 • ショートカットであってもDelta Lakeであれば、Direct Lake の対象となります。 • ただし、S3ショートカットなどの外部ショートカットはパフォーマンス劣化の可能性があります • データの量などの条件に応じてDirect Query モードに自動選択される場合があります。 • 仕組み上、ユーザーの要求に応じてFabric内にキャッシュする仕組みのため、キャッシュに乗りきらないような量を取得す るDAXクエリが要求された場合にはDirect Lake はDirect Queryにフォールバックされます • 非常に詳解までカバーされた記事：Comprehensive Guide to Direct Lake Datasets in Microsoft Fabric Direct Lakeを利用するための条件

• モデルビューにて確認が可能だが・・・ • ウェアハウス上のテーブルやレイクハウスであってもSQLエンド ポイント上のViewはDirect Query モードにされます • 現在、SQL エンドポイントで作成したビューは本来対象外だ が、モデルビューではDirect Lakeとして認識されてしまう • 正確にはPower BI Desktop のパフォーマンスアナライザ などから確認が可能 • 関連記事： • Power BI DesktopでFabricのデータセットへ接続する - テ クテク日記 (hatenablog.com) • Direct Lake データセットのクエリ処理を分析する方法につい て説明する - Power BI | Microsoft Learn Direct Lakeの確認方法（実機説明あり）

• 原則移行不要 • ショートカットにより既存資産を活かすことが最も効率的となる • 注意点としては、Azure Data Lake Storage Gen 2で実現ができていたファイル、フォルダレベルの細かなアク セス制御(ACL)にあたるものは現在Fabric には存在しないため、運用方法の検討は要注意 データレイクの移行ポイント 2023/9 時点

• Databricks を利用している場合には移行ではなく、統合を考えることを推奨（次スライドで説明 • 以下の移行の評価は統合ではなく移行の前提で評価する Databricks の移行ポイント 2023/9 時点 Databricks 主要成果物 Fabric アイテム 移行性 移行に関する評価 ノートブック ノートブック 〇 • Spark を動作させるという意味ではどちらも同じフレームワークを利用しているため、コードの書き換えは比較的少なく済 む（場合によっては書き換え不要） • パスの置き換えはもちろんだが、Databricks固有の機能を利用している場合（OSS Delta Lake に存在しないような エッジ機能など）にはFabric では利用が不可となる メタストア （ユニティカタログを含む） レイクハウス △ • DDLコマンドについてはエッジ機能以外については動作するため、Fabric 上でDDLを再実行すれば移行は可能 • レイクハウステーブル上でのアクセス制御粒度も現時点では再現が難しい箇所がある • ユニティカタログに相当する高度なデータ管理機能（Lakehouseフェデレーションやボリューム）はFabric には存在しな い Delta Lake データ レイクハウス 〇 • データレイク上に存在するため、移行なしでショートカット利用か配置場所の調整のみで再利用可能 Mlflow 実験、モデル 実験、モデル × • 実験をエクスポート、インポートすることは難しいと判断 • モデルについてはモデルをエクスポートしてFabric に再登録するか、改めて学習させる方式となる SQL Warehouse SQLエンドポイント 不要 • 利用の目的は同じ位置づけとなるが、Fabric ではSQL Warehouseにあたる処理リソースを管理する必要がない クラスター Spark Pool △ • Databricksに比べて設定項目がかなり簡素化されているが、Spark 構成を利用している場合にも対応が可能 • ノードVMの指定はFabric では3パターンのサイジングとなるため、同レベルのスペックとなるSpark Pool を検討する必要 がある。 • 現在GPUのサポートは未確認（Azure Synapse Spark ではプレビュー 〇：軽微な修正か修正作業なしで簡単（インポートエクスポートなど）に移行可能 △：部分的には軽微修正で移行可能だが再現不可の箇所がある ×：互換性がなく設計しなおし、作り直しが必要

• ショートカットを利用することにより、Databricks Deltaテーブルをデータ転送なく、Fabric レイクハウス上で利用することができる • ただし Fabric におけるDelta テーブルはDeltaLakeのフォルダ名を元に自動決定するので、現在はUnity Catalog を利用している場合には難しい構成となる • また、 レイクハウスではDirect Lake が機能することは期待できるものの、Fabric 専用の DeltaLake パフォーマンス最適化機能（v-order ）を使用していない状態となる Databricks と Fabric の統合 • Integrating Microsoft Fabric with Azure Databricks Delta Tables - Microsoft Community Hub データフロー Gen1 データセット レポート OneLake ショートカット Azure Storage Amazon S3 Databricks SQL Warehouse 表示：レイクハウス モデルビュー （＝既定のデータセット） 表示：SQLエンドポイント データビュー Power BI Service Data Factory (データフローGen2) Azure Data Factory (Mapping) Synapse Data Engineering (Spark ノートブック) Synapse Data Engineering (レイクハウス)

• Azure Synapse でレイクハウス構成をとりSynapse Spark を使用している場合の評価 Synapse Spark の移行ポイント 2023/9 時点 Synapse Spark 主要成果物 Fabric アイテム 移行性 移行に関する評価 ノートブック ノートブック 〇 • Spark を動作させるという意味ではどちらも同じフレームワークを利用しているため、コードの書き換えは比較的少なく済 む（場合によっては書き換え不要） レイクデータベース レイクハウス 〇 • パスの置き換えなどは必要だが同じDDLを流しなおせば移行は可能 Delta Lake データ レイクハウス 〇 • データレイク上に存在するため、移行なしでショートカット利用か配置場所の調整のみで再利用可能 Spark Pool Spark Pool 〇 （GPU利用：△） • ほぼ同じような設定内容となり、同レベルのスペックを用意することが簡単。 • 現在GPUのサポートは未確認（Azure Synapse Spark ではプレビュー 〇：軽微な修正か修正作業なしで簡単（インポートエクスポートなど）に移行可能 △：部分的には軽微修正で移行可能だが再現不可の箇所がある ×：互換性がなく設計しなおし、作り直しが必要

Microsoft Fabric 上での コラボレーション、データドメインについて

• 引用：Data and Fabric_forShare | ドクセル (docswell.com)

Fabricにまつわるデータ活用人材のロール • データ活用人材とはどんな人々か - AIソリューションアーキテクトのおしゃべり (hatenablog.com) 生データ 標準化 分析 サンドボックス OneLake データレイク データ インテグレーション データ エンジニアリング BI Synapse Data Engineering データサイエンス Data Factory DWH/レイクハウス Synapse Data Science Power BI リアルタイム分析 Real Time Analytics Synapse Data Warehousing アナリスト • 分析モデルの構築 • 経営層への報告 データエンジニア • データパイプラインの開発 • 新規データの取得 データサイエンティスト • 統計、仮説検証 • 機械学習モデルの開発

これまでの適材適所なプラットフォームとデータ活用人材の連携 データの活用 データの整備 • データウェアハウス/レイクハウス の構築・運用 • バッチ/リアルタイム 処理の開発 SQL データの再取り込みなど、残るわずかな分断 複数のデータレイク アナリスト データサイエンティスト データエンジニア • 分析モデルの構築 • レポート作成 • 統計・仮説検証 • ML モデルの開発・管理 統合分析プラットフォーム

シームレスなデータ活用人材間の連携 データの活用 データの整備 • データウェアハウス/レイクハウス の構築・運用 • バッチ/リアルタイム 処理の開発 アナリスト データサイエンティスト データエンジニア 完全にシームレスな統合分析プラットフォーム • 分析モデルの構築 • レポート作成 • 統計・仮説検証 • ML モデルの開発・管理 常に1つのデータレイク OneLake Microsoft Fabric

エクスペリエンスごとに作成できるアイテムと対象ロール エクスペリエンス アイテム 説明 対象ロール Data Factory データフロー Gen2 • Power Queryの外観でデータの取得・変換・登録を行う※スケジュール実行が可能 • スケジュール設定が可能 • 市民開発者 • データエンジニア データパイプライン • 多様なコネクタによるコピー機能を使用したデータの取得 • 他のエクスペリエンスで作成したデータ変換処理（データフローGen2,ノートブック、ストアドプロシージャ）の実行 • コピー実行、データ変換処理実行、Teamsへの投稿や、条件分岐などのアクティビティをフローチャート的に接続して、 順序実行させ • スケジュール実行が可能 • 市民開発者 • データエンジニア Synapse Data Engineering レイクハウス および SQL エンドポイント • データレイクハウスを構成するために使用する • ショートカットにより組織内の既存データをコピーせずに利用可能 • Files, Table領域が基本となるが、Power BI や,SQL Server対応したクライアントからの読取にはSQLエンドポイ ントを利用する • SQLエンドポイントからはレイクハウス上のテーブルを対象に既定のPower BIデータセットが自動作成される • レイクハウスor SQLエンドポイント上でテーブルを選択することでPower BI データセットの別途作成が可能 • データエンジニア • データサイエンティスト ノートブック • ノートブック型のUIで、レイクハウス上でデータの分析・変換処理を行うためのSpark開発・実行機能 • スケジュール設定が可能 • データエンジニア Sparkジョブ定義 • Spark ジョブを定義したPython ファイルなどをアップロードすることで、レイクハウス上でデータの分析処理を行う • スケジュール設定が可能 • データエンジニア

エクスペリエンスごとに作成できるアイテムと詳細 エクスペリエンス アイテム 説明 対象ロール Synapse Data Warehouse ウェアハウス • データウェアハウスを構成するために使用する. • レイクハウスのSQL エンドポイントへのクエリが可能 • View,ストアドプロシージャの作成して、データの変換処理を行う • ウェアハウスのテーブル、ビューがそのまま既定のPower BI データセットが自動作成される • テーブルを選択することでPower BI データセットの別途作成が可能 • 市民開発者 • データエンジニア • アナリスト Power BI データセット • Power BI のBIモデル定義 • インポート/ダイレクトクエリ/ダイレクトレイク いずれかのモードで動作する • インポート：データセットにデータを保存するため高速だが、保存のための更新処理が必要であり、更新処理 をした時点でのデータとなるため、データ鮮度は低くなる • ダイレクトクエリ：レポートの動作にあわせて、データセットが参照しているデータベースに都度データを取得しに いくため、低速。インポートと比べて保存処理が不要かつ、現在のデータベースの状態を取得するため、リアル タイムなデータを確認可能 • ダイレクトレイク：Fabric 専用のモード。レポートの動作にあわせてデータレイクハウス/ウェアハウスにデータ取 得するが、オンデマンドなキャッシュの仕組みにより更新処理不要のままインポートと同じくらい高速に動作可 能 • 市民開発者 • アナリスト • ビジネスユーザー レポート • Power BIにおける可視化機能 • データセット上のテーブルを使用した様々な表現が可能 • 市民開発者 • アナリスト • ビジネスユーザー

エクスペリエンスごとに作成できるアイテムと詳細 エクスペリエンス アイテム 説明 対象ロール Synapse Data Science ノートブック • 実体はSynapse Data Engineeringと同じ • 機械学習の実験、モデル学習および推論コードを実行する • データサイエンティスト 実験 • MLflowと統合された機械学習の実験の管理機能 • MLflowを使用した機械学習コードの実行時のパラメータが記録され,各実行の精度×パラメータ×アルゴリズムなどの 設定を視覚化,比較、確認できる • GUIかMLflowの実行時に作成可能 • データサイエンティスト モデル • MLflowと統合された機械学習モデルの管理機能 • 実験で生成されたモデルを登録し、バージョン管理することが可能 • モデルに付随する情報が視覚化して、バージョン間のモデル比較が可能 • GUIかMLflowの実行時に作成可能 • データサイエンティスト Real Time Analytics KQLデータベース • Azure Data Explorer のテクノロジーが利用されたリアルタイム分析に最適化されたデータベース • KQL と呼ばれるクエリ言語を使用する。 • データエンジニア KQLクエリセット • KQL を記述する。 • クエリ結果を使用してPower BIレポートを作成可能 • データエンジニア イベントストリーム • リアルタイムデータの取得、処理、登録を行う • 取得（ソース）：Azure Event Hubs (IoT Hub含む)からデータを取得 or 開発されたアプリからのデータ の受信に対応 • 処理（イベントプロセッサ）：取得したデータに対して加工、構造化を行い、宛先に送信する • 登録（宛先）：KQL データベース、レイクハウス、カスタムアプリのいずれかを選択し、テーブルなどの送信先を 定義する • データエンジニア

• Power BI に精通しているメンバーで構築するようなケース 1. データの格納先としてウェアハウスを作成する 2. （必要に応じてデータパイプラインを作成し、コピーアクティビティを使用してウェアハウスにデータを連携) 3. データフロー Gen2でウェアハウス→ウェアハウスのデータ変換処理を作成する 4. データパイプラインでコピーアクティビティやデータフローGen 2の順番やスケジュールを設定 5. ウェアハウスからPower BI データセット、Power BI レポートを作成する Fabric環境におけるアイテム作成例：BIプロジェクト(市民開発者)

• SQL Server やSnowflake、Synapse Analytics などに精通しているメンバーで構築するようなケース 1. データの格納先としてウェアハウスを作成する 2. データパイプラインを作成し、コピーアクティビティを使用してウェアハウスにデータを連携（データフローでもOK） 3. ウェアハウスにストアドプロシージャを作成し、データ変換処理を作成する 4. データパイプラインでコピーアクティビティとストアド実行の順番やスケジュールを設定 5. ウェアハウスからPower BI データセット、Power BI レポートを作成する Fabric環境におけるアイテム作成例：BIプロジェクト(SQLエンジニア)

• Databricks などSparkに精通しているメンバーで構築するようなケース 1. データの格納先としてレイクハウスを作成する 2. データパイプラインを作成し、コピーアクティビティを使用してレイクハウスにデータを連携（データフローでもOK） 3. ノートブックを作成し、データ変換処理を作成する（Spark ジョブ定義でもOK） 4. データパイプラインでコピーアクティビティとノートブック実行の順番やスケジュールを設定 5. レイクハウス上のSQL エンドポイントからPower BI データセット、Power BI レポートを作成する Fabric環境におけるアイテム作成例：BIプロジェクト(Spark エンジニア)

• データ基盤プロジェクトなどで構築したデータレイクを活用するようなケース 1. プロジェクト用の領域としてレイクハウスを作成する 2. 既存のレイクハウスorウェアハウスにショートカットを作成してOneLake上のデータを取得する (必要に応じて、データパイプラインなどでデータを取得する) 3. ノートブックを作成し、レイクハウス上のデータを使用したMLモデル学習処理コードを作成する 4. ノートブック内の処理で実験とモデルを作成、登録、管理する 5. (必要に応じて、推論結果を生成し、レイクハウスにデータ登録する) Fabric環境におけるアイテム作成例：MLプロジェクト

• IoT 設備監視などセンサーデバイスなどのストリーミングデータをソースにする場合 1. Azure 上で、Event Hubs や IoTHub を作成し、デバイスからのデータを受信する 2. データの格納先としてKQLデータベースを作成する 3. イベントストリームを作成して、１で受信したデータを取得、変換する処理を構成し、あて先としてKQLデータベースを設定する 4. KQL クエリセットを作成して、KQL データベースに分析クエリを発行する 5. 分析クエリからレポートを作成する。この時レポートの更新間隔を短くすることでリアルタイムに近づけることが可能 （データセットはKQLクエリをソースにしたものが自動で作成される） Fabric環境におけるアイテム作成例：リアルタイム分析プロジェクト

• 常に一つのデータレイクとプラットフォームでは、環境/プロジェクトの分離は主にFabric ワークスペースで行われる • これまではAzureサブスクリプションやリソースグループ、あるいはオンプレミスであればサーバや、ネットワーク帯により分離し ていた • どのように環境＝ワークスペースを編成、分割していくのかが重要となる プロジェクト間のコラボレーションについて考える

• 以下の観点が考えられる 1. 開発/検証/本番 のようなランドスケープに合わせた編成 2. 生データ/標準化/特定テーマ のようなデータの品質、領域、テーマに合わせた編成 3. データの管理者（一次データの所有者ではなく、Fabric 上に生成された二次データ）による編成 • ワークスペースは以下をまとめる空間であるため、 2,3についての方針がそのままワークスペース編成の基本指針となると考えられる • 成果物（データ資産および処理） • 共同作業者 • また、機能的制約として共有の粒度についても考慮しておく必要がある • ワークスペース単位の共有：ワークスペースレベルで権限をもつと配下のアイテム全てに権限をもつ • アイテム単位の共有：アイテムのアクセス許可モデル に基づく • オブジェクト/行レベルのアクセス制御： • Power BI のような行レベルセキュリティ用のロール方式 • Warehoues/SQLエンドポイント上でのGRANT文による方式※プレビュー時点の動作未確認 • 細かく分けるほど、管理統制のコストが増える点は注意 ワークスペースの編成方針について • Workspaces - Microsoft Fabric | Microsoft Learn

• データの品質で層を形成し、整理する考え方 • ゾーン毎のデータの役割が明確化することにより、再利用性や活用の統制に好影響を与える • Bronze (Raw)データ： • 後続を再生成可能にする生データ • 構造化の欠如、重複などの品質不足を受け入れるため、公開されるべきではない状態となる • Silver(Enrich)データ： • データ構造を適用し、品質チェックを適用された、公開すべき状態の利用可能データ（Single Source of Truth） • Gold(Curate)データ： • データマートとも呼ばれる状態。シナリオに適合した変換を加えた調整済みデータ 補足）メダリオンアーキテクチャ Bronzeデータ （Raw） Goldデータ （ Curate ） Silverデータ （ Enrich ） データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ

• Bronze/Silver: 汎用的な高品質データを消費者に届けるために、データエンジニアリングチーム により生成される • Gold : データ活用が具体化されたデータとして、ビジネス知識をもつチームにより生成される 補足）メダリオンアーキテクチャにおける役割分担 Bronzeデータ （Raw） Goldデータ （ Curate ） Silverデータ （ Enrich ） データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ 消費 可視化 アナリスト • 分析モデルの構築 • 経営層への報告 データエンジニア • データパイプラインの開発 • 新規データの取得 機械学習 データサイエンティスト • 統計、仮説検証 • 機械学習モデルの開発 ビジネス主体 エンジニアリング主体

• いわゆるDWHにあたるSilver層は抽象的なデータであり、 一元管理され様々な分析に汎用的に利用可能であることが求められる→小数 • 一方でデータマートと呼ばれるようなGold層は分析のテーマに特化して生成される→多数 どのような単位で処理、関係者が生まれるか Bronzeデータ （Raw） Silverデータ （ Enrich ） 一 元 化 処 理 Goldデータ （ Curate ） 集約された汎用データ 様々な生データ 分析テーマ①用データ 分析テーマ②用データ 分析テーマ③用データ 特化処理 特化処理 特化処理 分析テーマ①部隊 分析テーマ②部隊 分析テーマ③部隊 データ標準化部隊

• 考え方 • データ整備ワークスペース：単一のワークスペースで集中管理 • データ活用ワークスペース：データ活用案件ごとに作成 • 注意点 • 事業領域が増える場合、巨大なワークスペース内で各事業領域データへのアクセス制御が困難になる • データ整備ワークスペース内のA事業担当者がB事業データを見れてしまう ワークスペース編成例①集中管理型 事業領域A 事業領域Z データ整備ワークスペース データ活用ワークスペース① A事業ウェアハウス/レイクハウス Z事業ウェアハウス/レイクハウス ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN ウェアハウス レポート デ ー タ 整 備 ETL デ ー タ 整 備 ETL 活 用 処 理 活 用 処 理 データソース Fabric ワークスペース

• 考え方 • データ整備ワークスペース：事業領域ごとに複数のワークスペースで分散管理 • データ活用ワークスペース：データ活用案件ごとに作成 • 注意点 • 各整備ワークスペースに対する統制、活用しやすい提供ルール作りが必要 ワークスペース編成例②分散管理型 事業領域A 事業領域Z Aデータ整備ワークスペース データ活用ワークスペース① A事業ウェアハウス/レイクハウス Z事業ウェアハウス/レイクハウス ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN ウェアハウス レポート デ ー タ 整 備 ETL デ ー タ 整 備 ETL 活 用 処 理 活 用 処 理 Zデータ整備ワークスペース データソース Fabric ワークスペース

• 考え方 • データ整備ワークスペース：事業領域ごとのワークスペースをデータソースごとにさらに分離する • 連携要件、関係者が異なることが多いソースシステムごとにワークスペースを分離し、データ活用への公開時にはショートカットのみで構成することでレイクハウスに集約する • データ活用ワークスペース：データ活用案件ごとに作成 • 注意点 • 各整備ワークスペースに対する統制、活用しやすい提供ルール作りが必要 ワークスペース編成例③ソースシステム分離型 事業領域A 事業領域Z データ活用ワークスペース① ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN ウェアハウス レポート 活 用 処 理 Aデータ整備ワークスペース（標準化） A事業レイクハウス Z事業レイクハウス ・・・ Zデータ整備ワークスペース（標準化） 活 用 処 理 データソース Fabric ワークスペース シ ョ ー ト カ ッ ト シ ョ ー ト カ ッ ト

• 考え方 • データ整備ワークスペース：事業領域ごとのワークスペースにおいて生データを分離した分散管理 • 生データ領域を分離し、一部のメンバー以外の作業で生データが加工されないように保護する • ソースシステム分離型と組み合わせた編成も考えられる • データ活用ワークスペース：データ活用案件ごとに作成 • 課題 • 各整備ワークスペースに対する統制、活用しやすい提供ルール作りが必要 ワークスペース編成例④メダリオン再現型 事業領域A 事業領域Z Aデータ整備ワークスペース(Bronze) データ活用ワークスペース① (Gold) A事業ウェアハウス/レイクハウス Z事業ウェアハウス/レイクハウス ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN (Gold) ウェアハウス レポート デ ー タ 整 備 ETL デ ー タ 整 備 ETL 活 用 処 理 Zデータ整備ワークスペース(Bronze) Aデータ整備ワークスペース(Silver) A事業ウェアハウス/レイクハウス Z事業ウェアハウス/レイクハウス ・・・ デ ー タ 整 備 ETL デ ー タ 整 備 ETL Zデータ整備ワークスペース(Silver) 活 用 処 理 データソース Fabric ワークスペース

• 中央での集中管理型データ基盤のスピードや規模の限界を克服するべく生まれたセルフサービスデータ活用中心の考え方 • 各事業領域＝ドメインによる分割を行い、それぞれの領域にセルフサービスデータプラットフォームを提供、運用、権限管理を委任する • メッシュの中央にはデータガバナンス部隊が存在する 補足）データメッシュ概略 • Microsoft Data Analytics trends : ”Lakehouse” , ”Data Mesh" - Speaker Deck データメッシュ • 生成元に近く、知識のあるドメインエキスパート自身がエンジニアリングを行う • データの所有権はその生成元であるドメインオーナーに委任され、ドメインは 製品としてデータを他ドメインに提供する モノリスデータ基盤 • データの準備は中央データ基盤チームが実行 • データのプライバシーや配信は中央基盤チームが制御する ドメインA ドメインB ドメインC ドメインD ドメインE ドメインG ドメインF データインフラ データガバナンス データ検出と説明（カタログ） 標準化による相互運用性 アクセス制御 ストレージ、パイプライン 品質保証

• 参照アーキテクチャではPurviewを中心に、 Synapse や DataLakeを据えた複数のドメイン用 のデータ活用環境が取り巻く形で構成 • それぞれのドメインが相互にデータを連携し、コラボレー ションを促す 補足）Azure 参照アーキテクチャにおけるデータメッシュ • Azure でのクラウド規模の分析用の複数のデータ ゾーン - Cloud Adoption Framework | Microsoft Learn ドメインA ドメインB データガバナンス

参考）Zhamak Dehghani氏Data Mesh の代表文献 48 How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (martinfowler.com)

• ドメイン (プレビュー) - Microsoft Fabric | Microsoft Learn により、ワークスペースをドメインに紐づけることができる • ワークスぺースに対してドメイン設定を行うことにより、データ管理の統制がとられ、活用者に対しても発見性における好影響が考えられる • 例：OneLakeデータハブ（Fabric におけるデータ資産の検索機能）にてドメインに紐づけられたワークスペースの資産が絞り込まれる • Purview にもドメイン管理機能 が存在し、こちらではビジネス上の意味やビジネスモデルの定義を行う。Fabric におけるドメインどの連動に今後注目 Fabric における「ドメイン」機能 • Establishing Data Mesh architectural pattern with Domains and OneLake on Microsoft Fabric - Microsoft Community Hub

• それぞれの事業ごとに活用までのワークスペースをドメインに紐づけるパターン ドメインの適用イメージ① 事業領域A 事業領域Z データ活用ワークスペース① ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN ウェアハウス レポート 活 用 処 理 Aデータ整備ワークスペース（標準化） A事業レイクハウス Z事業レイクハウス ・・・ Zデータ整備ワークスペース（標準化） 活 用 処 理 データソース Fabric ワークスペース シ ョ ー ト カ ッ ト シ ョ ー ト カ ッ ト A事業データの管理ドメイン B事業データの管理ドメイン

• 事業データ用ドメインとデータ活用用ドメインという二つの性質から少し粒度を変更することも可能 ドメインの適用イメージ② 事業領域A 事業領域Z データ活用ワークスペース① ・・・ ウェアハウス レポート ・・・ ・・・ データ活用ワークスペースN ウェアハウス レポート 活 用 処 理 Aデータ整備ワークスペース（標準化） A事業レイクハウス Z事業レイクハウス ・・・ Zデータ整備ワークスペース（標準化） 活 用 処 理 データソース Fabric ワークスペース シ ョ ー ト カ ッ ト シ ョ ー ト カ ッ ト A事業データの管理ドメイン B事業データの管理ドメイン データ活用ドメイン① データ活用ドメイン②

• MSLearn • Microsoft Fabric のドキュメント - Microsoft Fabric | Microsoft Learn • Microsoft Fabric の概要 - Training | Microsoft Learn • それぞれの内容がお手軽に実施できます • Microsoft Fabric のエンド ツー エンドのチュートリアル - Microsoft Fabric | Microsoft Learn • 新機能 - Microsoft Fabric | Microsoft Learn • サポート、コミュニティ • Ideas • Microsoft Fabric のサポートと状態 | Microsoft Fabric • Microsoft Fabric Community • Microsoft Fabric Blog • Learn about Microsoft Fabric from MVPs | Microsoft Fabric Blog | Microsoft Fabric • その他 • 私の記事： Ryoma Nagata (@ryomaru0825) on Speaker Deck • 料金： Announcing Microsoft Fabric capacities are available for purchase | Microsoft Fabric Blog | Microsoft Fabric • スイさん(Microsoft Fabric CAT)の記事： • テクテク日記 (hatenablog.com) • Data and Fabric_forShare | ドクセル (docswell.com) • やんさんの記事(Microsoft CSA)：Microsoft Fabric - Next Generation Cloud Data Analytics Solution – Qiita • 消費量レポート：https://appsource.microsoft.com/en-us/product/power-bi/pbi_pcmm.microsoftpremiumfabricpreviewreport?exp=ubp8 • Git : Introducing git integration in Microsoft Fabric for seamless sosurce control management | Microsoft Fabric Blog | Microsoft Fabric • Data Activator サインアップ：https://aka.ms/dataActivatorPreview • Direct Lake：Comprehensive Guide to Direct Lake Datasets in Microsoft Fabric • プロンプトエンジニアリング • Codex モデルを使用してコードを操作する方法 - Azure OpenAI Service | Microsoft Learn おわりに リソースいろいろ