Microsoft Fabric 開発ガイド

Microsoft Fabric 開発ガイド 1.0版 2024.03.11 Microsoft MVP for Data Platform
永田亮磨 (ZEAL CORPORATION) X: @ryomaru0825 Linkedin: ryoma-nagata-0825 Qiita: ryoma-nagata

目次 1. はじめに 1. 本書の位置づけ 2. 本書の構成 2. データ活用基盤全体像 1.
システム構成図 2. Microsoft Fabric について 3. データ蓄積領域 1. データ配置 2. データモデリング 4. データ処理領域 1. データ統合 2. BI 3. データサイエンス 4. ワークフロー 5. サービス管理領域 1. ガバナンス 2. セキュリティ 3. コスト・パフォーマンス最適化 6. 学習リソース 1. MS Learn 2. Tech Blog

1. はじめに

1-1. 本書の位置づけ • 本書は、下記の全体構成図における Microsoft Fabric を対象に、データ分析のための機能について利用指針を記載するものとする本書の対象範囲

本書の対象読者 • 本書の主な読者は以下の赤字の担当者とする ※システム管理者に役立つ内容も含めているが、本書では特に開発タスクに関連する事項に焦点を当てるものとする担当者概要システム管理者データ活用基盤の全体を管理・統制するデータエンジニア
DWH/レイクハウス/ETL処理/データパイプラインなどを開発するデータサイエンティスト機械学習モデルを開発するアナリスト BIレポートやそのためのBIモデルを開発する成果物レビュアー開発されたコンテンツのレビューを行うビジネスユーザーレポートアプリを参照する

データ蓄積領域データ処理領域 1-2. 本書の構成全体像 • 以下の構成に基づき、データ活用基盤の各指針とゴールデンパターンを整理するデータモデリング BI データサイエンス
データソース打ち手・施策サービス管理領域ガバナンスセキュリティコスト・パフォーマンス最適化データ連携データ配置ワークフロー

本書の構成内容 # 名前説明備考 1 データ活用基盤 Microsoft Fabric
を中心に構成した分析システム環境を指す 2 ゴールデンパターン標準的な利用方法、または設計手法 3 データソース（データソースシステム）データ活用基盤外部から提供されるデータまたはその提供元となるシステム 4 データ蓄積領域データ蓄積機能を利用したデータの配置・整理方法に関するガイドライン領域 5 データ処理領域データ変換・分析機能を利用したデータ連携とモデリングの実装に関するガイドライン領域 6 サービス管理領域 Microsoft Fabric の管理・運用機能の利用方法やデータセキュリティの実装に関するガイドライン領域 7 打ち手・施策データ活用基盤による結果を受けて実施される業務上のアクション

2. データ活用基盤全体像

2-1. システム構成図社内ネットワーク上資産 Microsoft Fabric Microsoft Azure ワークスペースワークスペースワークスペース
サブスクリプション Fabric 容量仮想マシンオンプレミスデータゲートウェイ SQLServerなど Express Route 仮想ネットワーク上資産割当て OneLake Salesforceなど割当て Microsoft 管理ゲートウェイデータ連携データ連携 Copilot for Fabric Fabric インフラクラウド上資産開発担当者社内環境社内環境各種ファイル BIレポート参照 DWH/レイクハウス開発レポート開発 Internet Fabric アイテム（成果物） Internet BIレポート利用者 Microsoft Entra ID テナント Data Lake Storage Gen2 Dataverse データ仮想化

データ活用基盤を構成するコンポーネント概要 # 分類コンポーネント概要 1 Microsoft Azure サービス Microsoft
Entra ID テナントデータ活用基盤を構成するテナントテナントはAzure サービス、 Fabric サービスといったパブリッククラウドにおいて他社資産との境界線となる。IdPとしての機能をもつ (旧称Azure Active Directory) 2 Microsoft Azure サービスサブスクリプションデータ活用基盤に利用されるAzure サービスがホストされているるサブスクリプション 3 Microsoft Azure サービス Fabric 容量 Microsoft Fabric を利用するためのライセンス製品起動時間、サイズにより請求金額が決定する紐づけられた Microsoft Fabric 上のワークスペースは Microsoft Fabric の機能が利用可能となる 4 Microsoft Azure サービス仮想ネットワーク上資産仮想ネットワークを中心とした Azure IaaS 製品群 Express Route により社内ネットワークと接続される。 Microsoft Fabric に対して仮想マシンをオンプレミスデータゲートウェイとして登録することで、ネットワーク内の資産からデータ連携が可能となる 5 Microsoft Fabric サービスワークスペース Microsoft Fabric における成果物管理のためのフォルダ Microsoft Teams における Teamの単位のように作業場所として機能し、ユーザーはワークスペースにアクセスして機能を利用する 6 Microsoft Fabric サービス Fabric インフラ Microsoft Fabric 上で共通的に利用できる機能群

2-2. Microsoft Fabric について • データ活用基盤は Microsoft Fabric を中心に構成される •
Microsoft Fabric にはエクスペリエンスと呼ばれる機能のまとまりがあり、本章ではこれらについて記述する Microsoft Fabric

Microsoft Fabric エクスペリエンスとは • 「Data Factory」などの名称を指す各エクスペリエンスでは、作成できるものが関連づいており、分析作業の入り口となる。（ワークロード、プロダクトとも呼ばれる） Data
Factory Synapse Data Engineering Synapse Data Warehouse Synapse Real-Time Analytics Synapse Data Science Power BI Data Activator

Microsoft Fabric エクスペリエンスとアイテムの関係 • エクスペリエンスからは「アイテム」を作成することで実際の処理を定義するアイテムアイテムエクスペリエンスエクスペリエンス

Microsoft Fabric エクスペリエンスとアイテム概要検知条件とアクションを定義し、アラートや Power Automate ワークフローの開始などの適切なアクションを自動的に実行
Reflex Pyspark を使いながら再現性を確保するライブラリ管理により機械学習実験を開発する実験・モデル機械学習コードの実行時にパラメータ、メトリック、モデル評価結果などをログに記録。実験の管理とモデルの管理を実施する業界をリードするパフォーマンスをもつ T-SQL ベースのデータウェアハウスエンジンウェアハウス Fabric 内外の構造化データと非構造化データを 1 か所で格納および管理できるデータアーキテクチャと分散処理エンジンレイクハウスノートブック・環境 Spark を Jupyter ライクなノートブック形式でコーディングし、大規模にデータ準備する Data Factory Synapse Data Engineering Synapse Data Warehouse Synapse Real-Time Analytics Synapse Data Science Power BI Data Activator さまざまなタスクを大規模に実行できるデータ処理のためのワークフローを構築データパイプラインデータフロー Gen2 Power Query をベースとしたローコードなインターフェースでデータを変換する 5 秒から 10 秒以内のニアリアルタイム分析に使用できるデータベースエンジン KQL データべースイベントストリームローコードでストリームデータを変換・統合メジャー、リレーションシップ、ビジネスにわかりやすい用語でのデータモデル表現により、データ分析の再利用性を高めるセマンティックモデルレポート多彩なビジュアル表現とAIによるインサイトで意思決定を支援する対話型BIレポートエクスペリエンスアイテム（成果物）データ統合様々なロケーションにあるデータシステムからデータを収集するコネクタをもち、 ETLプロセス全体のワークフローをパイプラインとして定義・実行するデータエンジニアリングデータレイクハウスを構成し、Apache Spark を使用した分散処理により、組織内のデータを変換・準備するデータウェアハウスペタバイトスケールで最高のパフォーマンスを備え、T-SQL べースで分析が可能なリレーショナルDWH を構築するデータサイエンス MLflow が統合された jupyter ライクな UI 上で機械学習モデルの学習と推論を行うことで分析情報を強化するビジネスインテリジェンス豊富なビジュアルと分析機能を使用して、データ探索の実施や企業の意思決定を迅速化するダッシュボードを構築するデータドリブン Fabric 上で作成した分析結果を監視、通知し、データとビジネスアクションを連動させることでデジタルフィードバックループを促進するリアルタイム分析時系列データに最適化されたデータベースに任意の形式のデータを迅速に取り込み変換し、ニアリアルタイムで分析クエリの実行、可視化役割ノートブック・環境

Data Factory さまざまなタスクを大規模に実行できるデータ処理のためのワークフローを構築アイテム：データフロー Gen2 アイテム：データパイプライン Microsoft 製品にこれまで採用されてきた Power
Query をベースとしたローコードなインターフェースでデータを変換する 100以上のコネクタをもつデータ統合のためのエクスペリエンス

Synapse Data Engineering SQL 分析から、機械学習などの高度分析を実施可能なデータレイクハウスのためのエクスペリエンス構造化データと非構造化データを 1 か所で格納および管理できるデータアーキテクチャアイテム：レイクハウス
Spark を Jupyter ライクなノートブック形式でコーディングし、並列分散処理コンピューティングエンジンでデータを大規模に準備する ※データサイエンスエクスペリエンス用ノートブックと同一アイテム：ノートブック・環境

Synapse Data Warehouse T-SQL でトランザクションをサポートする完全なデータウェアハウスのためのエクスペリエンス業界をリードするパフォーマンスをもつ T-SQL コンピューティングエンジンアイテム：ウェアハウス

Synapse Real-Time Analytics ストリーミングと時系列データ向けに最適化されたフルマネージドのビッグデータ分析のためのエクスペリエンス 5 秒から 10 秒以内のニアリアルタイム分析に使用できる
コンピューティングエンジンアイテム：イベントストリームアイテム：KQL データベースローコードでストリームデータを変換・統合

Synapse Data Science データの強化とビジネス分析情報を目的とするエンドツーエンドのデータサイエンスのためのエクスペリエンス Pyspark を使いながら再現性を確保するライブラリ管理により機械学習実験を開発するアイテム：
実験・モデルアイテム：ノートブック・環境機械学習コードの実行時にパラメータ、メトリック、モデル評価結果などをログに記録。実験の管理とモデルの管理を実施する https://learn.microsoft.com/ja-jp/fabric/real-time- analytics/media/real-time-analytics-overview/product- view.png#lightbox ※データエンジニアリングエクスペリエンス用ノートブックと同一

Power BI 組織内にデータの”洞察”を共有し、意思決定を支援する、コラボレーティブ BI のためのエクスペリエンスメジャー（測定項目）、リレーションシップ、ビジネスにわかりやすい用語でのデータモデル表現により、データ分析の再利用性を高めるアイテム：レポートアイテム：セマンティックモデル
多彩なビジュアル表現とAIによるインサイトを提供する対話型BIレポート https://learn.microsoft.com/ja-jp/fabric/real-time- analytics/media/real-time-analytics-overview/product- view.png#lightbox

Data Activator（プレビュー）データのモニタリングにより、データドリブンアクションを開始するためのエクスペリエンス検知条件とアクションを定義し、アラートや Power Automate ワークフローの開始などの適切なアクションを自動的に実行アイテム：Reflex

OneLake について • OneLake は Microsoft Fabric のインフラとして存在し、構造化/非構造化データを保存可能なデータレイク機能 •
Microsoft Fabric 上で処理されたデータは自動的に OneLake 上に保管されるサーバーレスコンピューティングカスタマー 360 ファイナンスサービステレメトリービジネス KPI Delta – Parquet 形式 Delta – Parquet 形式 Delta – Parquet 形式 Delta – Parquet 形式 T-SQL Spark KQL Analysis Services データウェアハウス、データレイクハウスなど全てのワークロードのデータは OneLake に自動保存コンピューティングはストレージと分離され、別のエンジンで処理したデータを相互に処理可能非構造化、構造化問わずに保存可能なストレージ構造化データはDelta – Parquet と呼ばれる Openフォーマットで保管

Delta Parquet = Delta Lake について • Microsoft Fabric 上で”テーブル”として保管される際には
Delta Lake と呼ばれるフォーマットに変換されるオープンかつシンプル • ベンダーロックインなく、あらゆるツールからアクセス可能 • SQL/Python 双方での共通データアクセス • 統一されたバッチ、ストリーミング DWHとデータレイクのいいとこどり  高速なクエリ  タイムトラベル機能による過去データの遡り  スキーマの自動拡張 or 強制  構造化～非構造化データに対応しつつ高い圧縮率コンプライアンス対応監査履歴 UPDATE, DELETEによるデータ操作 Home | Delta Lake

OneLake ショートカットについて • OneLake ショートカットはストレージを仮想化する技術であり、Fabric 内外のデータを Fabric 上に存在するかのように扱うことができる機能であるカスタマー
360 ファイナンスサービステレメトリービジネス KPI Amazon Google Azure OneLake でのデータ共有は OneDrive でのファイル共有と同じくらい簡単でデータの重複が不要になるショートカットを利用することで OneLake 内のデータを移動することなく組み合わせられるショートカットを利用することでデータの重複や移動なしに Azure や他のクラウドに存在するデータを即座にリンクできるため、OneLake は初めてのマルチクラウドデータレイクになる業界標準の API のサポートにより OneLake データに任意のアプリケーションやサービスから直接アクセスできる

OneLake データハブ • OneLake 内で分散管理されたデータを効率的に見つけて、利用するためのハブ Microsoft OneLake in Fabric、データ向けOneDrive |Microsoft
ファブリックブログ |Microsoft ファブリック  Fabric に関連する各種ツールに組み込まれており、いつでもデータを検出・接続可能  ドメインおよび認定と連動し、特定のドメインにフィルタリングしたり、認定済みデータの一覧を表示可能

3. データ蓄積領域

データ蓄積領域についてデータ蓄積領域は以下のトピックについて記載する • データ配置：データストアとして利用する機能とメダリオンアーキテクチャに基づいた利用方針 • データモデリング：データ配置のレイヤーごとに指針となるデータモデリング内容データ蓄積領域データ処理領域データモデリング BI
データサイエンスデータソース打ち手・施策サービス管理領域セキュリティガバナンスコスト・パフォーマンス最適化データ連携データ配置ワークフロー

データ蓄積領域における Microsoft Fabric 機能について • Microsoft Fabric でデータ蓄積機能を持つ主要なアイテムは「ウェアハウス」、「レイクハウス」、「KQLデータベース」の３点 •
セマンティックモデルもデータ蓄積を行うが、本書では蓄積領域の対象外とする • それぞれの機能差を以下に記載する • 参考：Fabric 決定ガイド - データストアを選択する - Microsoft Fabric | Microsoft Learn # 観点ウェアハウスレイクハウス KQL データベース 1 主要なユースケース BI , SQL 分析 BI , SQL分析、データサイエンスニアリアルタイム分析 2 保存可能なデータ種構造化非構造化、半構造化、構造化非構造化、半構造化、構造化 3 主な開発者スキルセット SQL Spark(Scala、Pyspark, SparkSQL , R) KQL,SQL 4 データの編成データベース、スキーマ、テーブルフォルダーとファイル、データベース、テーブルデータベース、スキーマ、テーブル 5 複数テーブルトランザクション可能不可制限付きで可能 6 読取可能な言語・ツール T-SQL、Spark(ショートカット経由)、データパイプライン、データフロー Spark , T-SQL、データパイプライン、データフロー KQL、T-SQL、Spark、データパイプライン、データフロー、 Power BI レポート（KQLクエリから直接レポート生成が可能） 7 書き込み可能な言語・ツール T-SQL、データパイプライン、データフロー Spark、データパイプライン、データフロー、イベントストリーム KQL、Spark、データパイプライン、データフロー、イベントストリーム

レイクハウスとデータウェアハウスの関係性 • レイクハウスを作成すると「SQL分析エンドポイント」と呼ばれる読み取り専用モードのウェアハウスが自動的に作成される。 • ウェアハウスはMS SQL Server 互換の接続エンドポイントをもつため、対応した BI ツールなどからレイクハウスに接続が可能となる
• 参考：一緒に使えばより便利に - レイクハウスとウェアハウス - Microsoft Fabric | Microsoft Learn アイコンがウェアハウスであることに注目

3-1. データ配置の全体像 • メダリオンアーキテクチャをベースに三つのレイヤでデータ蓄積の領域を整理すると以下の図のようになる • Microsoft Fabric でメダリオンレイクハウスアーキテクチャを実装する
- Microsoft Fabric | Microsoft Learn • 本章では、データ蓄積におけるそれぞれのレイヤについて、レイヤーの役割と構成内容、Fabric 機能を使用したゴールデンパターンについて記載する生レイヤー（非公開で履歴保管）整備済みレイヤー（汎用的なデータを公開）消費レイヤー（特定用途向けに変換）データソース（構造化）データソース（非構造化）未加工 or 派生汎用データの公開データ探索エンタープライズBI用データセルフサービスBI用データ手持ちデータ BIレポート Upload領域生ファイルの保管生データの保管機械学習用データ機械学習モデル

データ配置の基本方針：メダリオンアーキテクチャ • ステージ毎のデータの状態を明確化することでデータを整理する考え方 • Bronze データ： • データレイクとも呼ばれる状態。後続を再生成可能にする生データ • Silver
データ： • DWHとも呼ばれる状態。データ構造を適用し、品質チェックを適用された、公開すべき状態の利用可能データ（Single Source of Truth） • Gold データ： • データマートとも呼ばれる状態。シナリオに適合した変換を加えた調整済みデータ Bronzeデータ Goldデータ Silverデータデータ品質を適用し、利用可能データへシナリオごとに調整されたデータへ

生レイヤーの設計方針 • 生レイヤーはデータソースからデータ基盤に連携されるデータがはじめに保存（仮想化）される場所となる。連携されたデータのチェックと、後続のデータを再生成するためのバックアップを目的とするため、非公開で運用する • 構造化/非構造化すべての種類のデータの収集～クレンジングに対応する • 生ファイル（ csv,Excelファイルなど） •
データソースがデータベースではなく非構造化データである場合に、Fabric が構造化処理を実施するために配置する。（データベースからファイル連携された場合も含む） • ユーザーによるアップロードする場合には専用の領域を設ける • 生データ（データベースなど） • データソースが構造化データであればファイル保管は行わずに連携 • 整備済みレイヤーに連携するためのクレンジング結果と不整合データを保管する

整備済みレイヤーの設計方針 • 整備済みレイヤーはデータソースから連携されたデータがクレンジングされ、重複なく最新の状態として公開される場所となる。あらゆるデータ分析のインプットとして扱われるため、データソースの形式そのままか、汎用的なデータを生成し格納する • 特定の用途ではなく、汎用的にあらゆるデータ活用の基礎として機能するデータを提供する • スタンダードデータ • データソースシステムで定義されたテーブル構造
• 派生・強化データ： • 同エンティティ異テーブル構造などの場合で平準化されたテーブル構造 • 連携タイミングごとに履歴化されたテーブル構造 • データソースはないが普遍的に利用可能な便利なテーブル構造 • 消費レイヤーから汎用性を認められ、リファクタリングされたテーブル構造

消費レイヤーの設計方針 • 消費レイヤーは、BIや機械学習向けの領域として開発され、分析結果が公開される場所となる • 特定の分析業務に使用されるデータを生成し、分析シナリオを実現する • 特化データ • BI向けの非正規化されたフラットワイドテーブル（大福帳）またはスタースキーマ ›
全社向けのレポートに使用されるエンタープライズ BI 用データ › 部署、チームや、PoCレポートに使用されるセルフサービス BI 用データ • セルフサービスBI用に利用される整備済みレイヤーに存在しない個別の手持ちデータ • 特徴量として準備された機械学習用データ

データ蓄積ゴールデンパターンイメージ図 • メダリオンアーキテクチャをベースに三つのレイヤでデータ蓄積の領域を整理し役割を分担する生レイヤー（非公開で履歴保管）整備済みレイヤー（汎用的なデータを公開）消費レイヤー（特定用途向けに変換）
データソース（構造化）データソース（非構造化）未加工 or 派生汎用データの公開データ探索エンタープライズBI用データセルフサービスBI用データ手持ちデータ BIレポート Upload領域生ファイルの保管生データの保管機械学習用データ機械学習モデル Raw レイクハウス Upload レイクハウス Enrich レイクハウス Curate ウェアハウス Curate ウェアハウス Curate レイクハウス

【生レイヤー】ゴールデンパターン • データストア選定（利用する Fabric アイテム）：レイクハウス • 非構造化ファイル、構造化データ双方の投入を要するため、後者のみが対象となるウェアハウスは不適となる※非構造化ファイルのLanding/Upload領域については、2024/2 現在、オンプレミス NWからのファイルtoファイルの連携に対応していないため過去データのLanding保管にのみ利用 •
データストアの粒度と公開範囲： • Uploadレイクハウス（オプション）：N個構成し、Upload領域は開放したいユーザーグループ単位でワークスペースをわけて公開する（現在詳細なアクセス制御が不可のため） • Rawレイクハウス：1つ構成し非公開で運用する • ディレクトリ・テーブルの構成(テーブルのデータモデル＝項目設計についてはデータモデリングの章を参照) • 生ファイル • Upload：ユーザー側からアップロードする場合に利用する。ユーザーにとって使いやすい構造でフォルダを検討する • Landing：landing/{データの種別（トランサクション系/ログ系など）}/{データソースシステム名}/{テーブル名}/{フォーマットバージョン}/{連携種別}/{ジョブ実行日}/{ジョブ実行タイムスタンプ} のようなフォルダ構造を検討する • 生データ • Input：データソースあるいはランディングから連携したレコードを格納する。 • Output：ステージング-inから対象のタイミングの連携データを抜き出し、重複排除、型変換したデータを格納する • Error：必須項目の欠如や、型変換などのクレンジング処理で異常とみなされたデータを格納する生レイヤーレイクハウス：LH_[事業部略称]_[PJコード]_Upload レイクハウス：LH_[事業部略称]_[PJコード]_Raw 任意の Upload用フォルダ・・・ landing/ {データの種別（トランサクション系/ログ系など）}/ {データソースシステム名}/{テーブル名}/ {フォーマットバージョン}/{連携種別}/ {ジョブ実行日}/{ジョブ実行タイムスタンプ} error_[データソースシステム名]_[テーブル名ローマ字表記] input_[データソースシステム名]_[テーブル名ローマ字表記] output_[データソースシステム名]_[テーブル名ローマ字表記] ・・・・・・

【整備済みレイヤー】ゴールデンパターン • データストア選定（利用する Fabric アイテム）：レイクハウス • この層では共通化できる処理が多くなることが想定されるため、処理を関数化しやすい Pyspark の実行ができるレイクハウスを選定 •
ショートカットにより別のレイクハウスやウェアハウスのハブとして利用できるメリットもあり • データストアの粒度と公開範囲： • 1つ以上のレイクハウスで構成し、可能な限り公開する • 機微なデータが存在する場合、別のワークスペース、レイクハウスで構成し、公開範囲を制御する • テーブルの構成(テーブルのデータモデル＝項目設計についてはデータモデリングの章を参照) • スタンダードデータ：連携されたデータをクレンジングなどの標準化処理以外は未加工で格納する • 派生・強化データ：スタンダードをベースに履歴化や、標準化した派生データを公開する整備済みレイヤーレイクハウス：LH_[事業部略称]_[PJコード]_Enrich standard_[データソースシステム名]_[テーブル名ローマ字表記] enrich_[データソースシステム名]_[テーブル名ローマ字表記] ・・・レイクハウス：LH_[事業部略称]_[PJコード]_Enrich_Sensitve standard_[データソースシステム名]_[テーブル名ローマ字表記] enrich_[データソースシステム名]_[テーブル名ローマ字表記] ・・・

【消費レイヤー】ゴールデンパターン • データストア選定（利用する Fabric アイテム）： • 特化データを生成するためのショートカット用のレイクハウス • BI向け：ウェアハウス •
データサイエンス向け：レイクハウス • データストアの粒度と公開範囲： • ショートカット用のレイクハウス×上記のデータストアを組わせて構成し、各プロジェクト内で公開範囲を検討する • テーブルの構成(テーブルのデータモデル＝項目設計についてはデータモデリングの章を参照) • ショートカットデータ • 特化データを生成するためのソーステーブル • 特化データ • 内容は各プロジェクトで検討する消費レイヤーレイクハウス：LH_[事業部略称]_[PJコード]_Shortcut [各プロジェクトで検討したショートカット名] ・・・ウェアハウスorレイクハウス：[WH or LH]_[事業部略称]_[PJコード]_Curate [各プロジェクトで検討したテーブル名] ・・・

生レイヤー（非公開で履歴保管）整備済みレイヤー（汎用的なデータを公開）アイデア) ショートカットによる整備済みレイヤーハブ • 事業領域に応じたチーム編成や、データの整理などの都合で、Enrich レイクハウスが分割されている場合、事業横断したレイクハウスを設けることで、消費レイヤーからの接続を一本化し、認知負荷を下げることができる
事業領域A 事業領域Z ・・・データソース Raw レイクハウス（A事業） Raw レイクハウス（Z事業） Enrich レイクハウス（A事業） Enrich レイクハウス（Z事業） Enrich レイクハウス（事業横断）・・・・・・ A事業データ群 Z事業データ群消費レイヤー（特定用途向けに変換）ショートカットショートカット

3-2. データモデリングの全体像 • データは連携後に利活用するにあたり、以下の図のようにそれぞれのレイヤーで必要なデータモデル（列定義）に段階的に変換されていく。 • 本章では、データモデリングにおける以下のポイントと Fabric の機能を使用したゴールデンパターンについて記載する
• 生レイヤー、整備済みレイヤー、消費レイヤーでのテーブルモデル生レイヤー（非公開で履歴保管）データソースデータ利活用生レイヤー用のデータモデル整備済みレイヤー（汎用的なデータを公開）消費レイヤー（特定用途向けに変換） Microsoft Fabric 整備済レイヤー用のデータモデル消費レイヤー用のデータモデル

データモデリング手法と用語の整理 • 用語 • 正規化：本書では、テーブル間の値の重複を無くし、エンティティが主キーで分離されている状態を指す • 非正規化：本書では、主キーで分離されていたエンティティがまとめられている状態を指す。 • データモデリング手法 •
3NF（第3正規化） • 業務システムなどで基本となる一般的なデータモデリング • キー情報以外が重複なく格納され、ストレージコストが低く、更新時の不整合を防ぐメリットがある。 • ディメンショナルモデリング（参考：スタースキーマと Power BI での重要性を理解する - Power BI | Microsoft Learn） • DWH （データマート）のモデリング手法として有名なデータモデリング • 集計対象の測定項目を持つ Fact と集計軸をもつ Dimension の2種類のテーブルを基本にして形成する。 • 分析粒度に合わせて非正規化をするため、難易度は高いが、パフォーマンスに利点があるとされ、Power BI では推奨 • フラットワイドテーブル（大福帳形式） • レポートツールのソースとしてよく利用されるデータモデリング • 主となるトランサクションテーブルにマスタ項目を付与していくことで非正規化を行い、1つのテーブルで分析対象を表現する。 • ストレージコストが肥大化しやすく、Power BI では複雑なメジャーを形成する際に誤った項目の導出につながる場合がある • Data Vault 2.0 (参考：Azure 上の Data Vault 2.0 (microsoft.com)) • DWH のモデリングとして新興した手法 • ハブ、サテライト、リンクという形にテーブルを分解し、すべてのデータを履歴保存可能にする • 一部のツールでフレームワーク化されているが、まだ難易度は高い

スタースキーマ • Power BI はスタースキーマによるディメンショナルモデリングを推奨している • 2種類のテーブルで構成 • Factテーブル
いわゆるトランザクション情報。明細などの出来事の発生を表現するレコードを保持 • 測定対象（メジャー）の項目を保持 • メジャーの例：受注金額… • データ量大 • Dimensionテーブルいわゆるマスタ情報。製品カテゴリなどの出来事の説明を表現するレコードを保持 • 集計軸を保持 • 集計軸の例：製品名、製品カテゴリ • データ量小

ディメンションテーブルとのリレーションシップによるフィルタの伝播 • Dimensionテーブルでフィルタする流れ(下図はスノーフレークスキーマと呼ばれる構成） • 1→多の方向に向かって、フィルタが伝播していく • フィルタされたレコードに基づいて、Factが集計結果を返す • 集計軸をFactに持たないことによりデータサイズも削減される •
100行×10列 + 10行×10列よりも、100行×20列のような大福帳形式の方がデータサイズが大きくなる

スタースキーマ vs 大福帳（フラットワイドテーブル） • 一般的にスタースキーマが推奨となる • 限定的なユースケース、探索的に分析したい場合のみ大福帳が有効観点スタースキーマ大福帳
ストレージサイズ小大パフォーマンス高低モデリング難易度高低相対的な比較

スタースキーマ vs 大福帳（フラットワイドテーブル） • 大福帳の問題点 • イベントの発生しなかった属性に対する分析が不可となるスタースキーマ大福帳顧客B001の売上が0だったことを可視化できない
売上年月顧客コード売上数量 2020/10/1 A001 10 2020/10/1 A002 20 2020/11/1 A001 20 顧客コード顧客地域 A001 東京 A002 東京 B001 大阪売上年月顧客コード売上数量顧客地域 2020/10/1 A001 10 東京 2020/10/1 A002 20 東京 2020/11/1 A001 20 東京 Fact Dimension

履歴化の方式 SCD(Slowly Changing Dimension) • 分析したい時点での状態を保持するために、SCDと呼ばれる履歴化手法が1～7までパターン化されている。主要は1と2である • SCD Type
1 ：変更があればレコードを新しい状態に上書き • SCD Type 2 ：変更があれば新しいレコードを追加して古いレコードの終了日を更新する • 例： 2020年11月から顧客A001の住所が変わった場合（東京→愛知） SCD 1 SCD 2 ～10/31の状態 11/1の状態～10/31の状態 11/1の状態顧客コード顧客地域 A001 東京 A002 東京 B001 大阪顧客代理キー顧客コード顧客地域開始日終了日 1 A001 東京 2020/1/1 2020/10/31 2 A002 東京 2020/1/1 9999/12/31 3 B001 大阪 2020/1/1 9999/12/31 4 A001 北海道 2020/11/1 9999/12/31 顧客代理キー顧客コード顧客地域開始日終了日 1 A001 東京 2020/1/1 9999/12/31 2 A002 東京 2020/1/1 9999/12/31 3 B001 大阪 2020/1/1 9999/12/31 顧客コード顧客地域 A001 大阪 A002 東京 B001 大阪更新更新追加

特徴量データについて • データサイエンスにおいて、機械学習モデルの入力となるのが「特徴量」 • 特徴量は機械学習モデルのタスクによって有効となるものが変わる • 「回帰」：住宅の築年数→住宅価格 • 「分類」：顧客利用年数→解約の有無 •
「時系列予測」：売上の7日間移動平均など→7日後の売上 • MLモデルの入力は基本的に大福帳形式となることが一般的 • 機械学習における特徴エンジニアリング - Azure Architecture Center | Microsoft Learn

データモデリングのゴールデンパターン • 生レイヤー： • Raw： • Input：ソースシステムのデータモデルを採用し、連携タイミングごとに断面を持つ（更新はしない）ただし、型変換時の失敗を追跡可能にするために、ファイル連携の場合には文字列型で格納する • Output：ソースシステムのデータモデルを採用し、連携タイミングごとに断面を持つ（更新はしない）
• （オプション）Error : Inputと同じデータモデルとする。ただし、Input->Output の過程でエラーデータのみを振り分けるか、連携データ全体で投入するかはプロジェクトごとに要検討 • 整備済みレイヤー • Standard：ソースシステムのデータモデルを採用し、最新状態を反映する(SCD Type1状態) • Enrich：統合エンティティ/履歴型(SCD Type 2 状態)/ディメンショナルモデリングを採用する • 消費レイヤー • ディメンショナルモデリング/フラットワイドテーブル/特徴量データを基本として、各プロジェクトにて内容を検討する ※必要に応じて、Enrich 相当の汎用テーブルの検討と実装を行い、整備済みレイヤーにてリファクタリング、再実装をすることも想定される

データ蓄積領域における参考リンク集 • データ配置 • What's Data Lake ? Azure Data
Lake best practice - Speaker Deck • Databricks ( Spark ) における Spark テーブル（データレイク）のディレクトリ構成の検討 #Python – Qiita • データレイクのゾーンとコンテナー - Cloud Adoption Framework | Microsoft Learn • データモデリング • SCD • dbt snapshot から学ぶ Slowly Changing Dimension - Gunosyデータ分析ブログ • Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3 - Kimball Group • デザインのヒント #152 緩やかに変化するディメンションタイプ 0、4、5、6、7 - Kimball Group

4. データ処理領域

データ蓄積領域データ処理領域データモデリング BI データサイエンスデータソース打ち手・施策サービス管理領域セキュリティガバナンス
コスト・パフォーマンス最適化データ連携データ配置ワークフローデータ処理領域についてデータ処理領域はデータ統合→データ分析の流れで開発される以下のトピックについて記載する • データ連携：データ連携に利用する機能と連携方式ごとの利用指針 • データ変換：データ変換に利用する機能と目的ごとの利用指針 • BI：BIの成果物と利用方針 • データサイエンス：データサイエンスの成果物と利用方針 • ワークフロー：データ処理領域全体の実行制御に関する指針

データ処理領域（データ統合）における Microsoft Fabric 機能について • Microsoft Fabric でデータ処理機能（データ統合）は主に • 「T-SQL(ウェアハウス)」、「Spark
(ノートブック)」、「データパイプライン」、「データフロー Gen2」、「イベントストリーム」の5点 • それぞれの機能差を以下に記載する • 参考：Fabric の決定ガイド - コピーアクティビティ、データフロー、または Spark - Microsoft Fabric | Microsoft Learn # 観点 T-SQL(ウェアハウス) Spark (ノートブック) データパイプラインデータフロー Gen2 イベントストリーム 1 主要なユースケースデータ探索、データ変換/更新データ探索、データの変換/更新、データ取込ファイルコピー、データ取込、データ変換（一部）、各変換の順序制御データ探索、データの変換/更新、データ取込リアルタイムデータ取得、データの変換/更新、データ取込 2 インターフェース SQL Spark GUI GUI GUI 3 データ探索〇〇 × 〇 × 4 データ変換の複雑さ低～高低～高低（ウェアハウスSQLをソースとして可能）低～高低 5 データ取込頻度バッチニアリアルタイム～バッチバッチバッチニアリアルタイム 6 ソース Fabric 内：〇 Fabric 外：×（Public なファイルは可能） Fabric 内：〇 Fabric 外：〇 (Spark 準拠) Fabric 内：〇 Fabric 外：〇 Fabric 内：〇 Fabric 外：〇 Fabric 内：〇 Fabric 外：〇（ストリームソースのみ） 7 あて先レイクハウス：× ウェアハウス：〇 KQLデータベース：× レイクハウス：〇ウェアハウス：× KQLデータベース：〇レイクハウス：〇ウェアハウス：〇 KQLデータベース：〇その他クラウドデータストアなどレイクハウス：〇ウェアハウス：〇 KQLデータベース：〇その他Azure SQLDBなどレイクハウス：〇ウェアハウス：× KQLデータベース：〇

データ処理領域（データ分析）における Microsoft Fabric 成果物について • Microsoft Fabric でデータ処理機能（データ分析）における成果物とそれぞれの役割を以下に記載する # 成果物
役割備考 1 レポート BIレポートによる可視化を行う 2 ダッシュボード複数のBIレポートや、主要なKPIなどを一画面で表示する 3 セマンティックモデルセマンティック層としてビジネスユーザ向けのデータを公開し、レポートやExcel Pivotのソースとする 4 アプリレポートとダッシュボードを一つのアプリとしてパッケージ化する 5 ノートブックデータ探索の実行および、機械学習コードを記述 6 実験機械学習タスクの実行履歴管理 7 モデル機械学習モデルのバージョン管理 8 環境 Python ライブラリ、コンピューティングの構成管理

4.1 データ連携の全体像 • データ連携をデータ活用基盤からみて外部と内部で分類すると以下の図のようになる • 本章では、データ連携における以下のポイントとFabric の機能を使用したゴールデンパターンについて記載する • 連携方式 •
取得・更新方式 • 変換(ELT/ETL)の適用生レイヤー（非公開で履歴保管）データソースデータ利活用データ連携データストア整備済みレイヤー（汎用的なデータを公開）データ連携データストア消費レイヤー（特定用途向けに変換）データ連携データストア Microsoft Fabric 取得更新取得更新取得更新変換(ETL) 変換(ELT) 変換(ETL) 変換(ELT) 変換(ETL) 変換(ELT)

連携における観点と分類 • 連携頻度 • バッチ：定期間隔でデータ収集ツールが起動し、移送処理を行う • マイクロバッチ：一般的に1時間未満の間隔でデータ収集ツールが起動し、移送処理を行う •
リアルタイム：常にデータ収集ツールが起動しており、随時移送処理を行う • データコピー方式 • バイナリ：ファイル内容を読み取らないで、単純コピーする • データのみ：ファイルまたはテーブル内容を読取り、レコードとしてコピーする • 連携主体 • Pull 型 : データソースシステムに保存されているデータに対してデータ利活用基盤の機能により取得しにいく • 例：ファイルサーバ上のファイルの取得/データベースからの取得 • Push 型：データ活用基盤上に直接アップロード • 例：ユーザーからの直接アップロード/センサーアプリからのデータ送信ソース連携実行命令あて先ソース常時連携あて先バッチリアルタイムコピー読取・コピーバイナリデータのみファイルファイルファイルテーブルテーブル Pull ソースあて先 Push ソースあて先送信アクセス取得

取得範囲と更新方法について • データ連携の具体的実装は「連携されるデータの範囲」とそのデータを用いた「更新方法」の組み合わせにより決まる。主要な例は以下 • 例①「マスタ情報を最新化する」：全件連携×全件更新 • 例②「連携されたデータを毎回履歴として残す」：全件連携×単純増加 • 例③「更新先の更新日付より後に更新のあったレコードのみ連携し、マスタ情報を最新化する」：更新の差分連携×差分更新 •
例④「直近2か月間のデータを洗い替える」：増分の差分連携×増分更新取得範囲 • 全件 • ソースシステム内のデータを取得する • データ量が日々増加するようなテーブルでは処理時間への影響が大きい • 差分 • 更新の差分 • ソースシステム内で更新（新規発生を含む）のあったデータのみを取得する。 • PKがあるデータにのみ適用可能 • すでに取得済みのデータの更新日より新しい更新日のみで抽出するなど › 例）更新されたマスタ情報を連携 • 増分の差分 • ソースシステム内で特定の期間内で発生したデータのみを取得する • PKがないデータにも適用可能 › どの日付がデータの発生した日を表すのかを特定する必要がある • 更新の差分が取得済みのデータの更新日と比較することに対して、増分では、連携を実施する日などに対して比較をし、特定の期間での取得をする › 例）前月と当月の売上データを連携更新方法 • 全件更新（Overwrite）：すべてを洗い替え • 利用シーン • マスタデータなど大きくないデータにおいて毎日の状態を反映するとき • データマートなど、粒度が変わりPKがなくなったり、スキーマの変更が頻繁な領域 • 単純増加（Append）：更新しない • 利用シーン • ログデータなど、PKや更新の必要性自体を持たないデータ向け • Raw領域などで、毎日連携した記録を残すためなど • 差分更新(Upsert)：PKで更新 • 利用シーン • 連携データのコピーとなる領域（Enrich）で最新の状態を反映するとき • 連携方式によって物理削除に対応できない点に注意 • 増分更新（Overwrite partition）：PKではなく期間で更新 • 利用シーン • PKがないが、データ量をおさえたいとき • データソースシステムで発生する物理削除を反映したい場合に検討する

例）全件連携×全件更新ソース（1日目）あて先（1日目）全件連携全件更新ソース（2日目）あて先（2日目） ID 伝票番号※PK 売上金額
売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/15 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/15 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 全件連携全件更新

例）全件連携×単純増加ソース（1日目）あて先（1日目）全件連携単純増加ソース（2日目）あて先（2日目） ID 伝票番号※PK 売上金額
売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/15 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/14 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 全件連携単純増加

例）増分連携×単純増加リアルタイムソースなどソース（1日目）あて先（1日目）即時連携単純増加ソース（2日目）あて先（2日目） ID 伝票番号※PK
売上金額売上日更新日 2 2002 200 7/12 7/12 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 即時連携単純増加

例）更新差分×差分更新ソース（1日目）あて先（1日目）初回は全件が連携差分更新ソース（2日目）あて先（2日目） ID 伝票番号※PK
売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/15 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4004 400 7/14 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 300 7/14 7/14 更新データのみ連携 (1日目のあて先は7/14が MAX更新日なのでそれ以降) 差分更新

例）増分差分×増分更新当月と前月を連携対象期間とする場合ソース（7/31）あて先（7/31） 7月と8月が対象増分更新ソース（8/1）あて先（8/1） ID
伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 5 5005 500 8/1 8/1 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4303 400 7/14 7/15 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 5 5005 500 8/1 8/1 ID 伝票番号※PK 売上金額売上日更新日 1 1001 100 6/10 6/10 2 2002 200 7/12 7/12 3 3003 400 7/14 7/15 4 4303 400 7/14 7/15 7月と8月が対象増分更新 7月8月のデータを洗い替えするため、4004データの物理削除が反映

データ更新におけるSpark コードの参考 • 全件更新(OVERWRITE) or 単純増加(Append) • Delta Lakeテーブルのバッチ読み込み・書き込み #Databricks
– Qiita • 増分更新 • spark.conf.set(‘spark.sql.sources.partitionOverwriteMode’,‘dynamic’)を有効にしたうえでパーティション化されたテーブルをOVERWRITEすると、投入データのパーティション範囲での上書きとなる • Sparkでパーティション単位で上書きする｜tkfjwr (note.com) • 差分更新 • マージを使用した Delta Lake テーブルへの upsert - Azure Databricks | Microsoft Learn

データ変換の目的 • データ変換は主に以下の目的のもと実行される • データフォーマット変換 • データの保持形式を変換して、Fabric 内で使用できる状態にする（ファイル→テーブル、DB→Delta Lake など）
• データクレンジング • データ品質（主キーの一意性や、必須項目のNULLチェック）の検査や、不整合データを取り除く • データプレパレーション • 分析などの利用目的に応じたデータを生成する • データ変換のタイミングと場所により、ETLとELTに分類可能(下図参照) 抽出、変換、読み込み (ETL) - Azure Architecture Center | Microsoft Learn ETL ELT 連携時に同時にデータ変換が行われる連携後のデータストア上でデータ変換が行われる

Microsoft Fabric のデータ連携機能の分類 • Microsoft Fabric で利用可能なデータ連携に関する機能について以下のように記載する # Fabric 機能名
説明ソース閉域NW内からの取得(Pullの場合のみ) あて先連携頻度コピー方式連携主体更新方式の対応 1 レイクハウスフォルダレイクハウスがもつファイル保存領域へのアップロード Fabric 外部 - レイクハウス - バイナリ Push型 - 2 Dataflow Gen2 ETL 機能を使用した連携 Fabric 外部 / 内部〇ウェアハウス/レイクハウス /KQL データベース/Azure SQL DB / Azure Data Explorer バッチデータのみ Pull型全件更新/単純増加 3 データパイプラインのコピーアクティビティコピー機能を使用した連携 Fabric 外部 / 内部 ×（対応予定あり）ウェアハウス/レイクハウス /KQL データベース/その他コネクタ準拠バッチバイナリ/ データのみ Pull型単純増加 4 ノートブックレイクハウスで動作するSpark を使用した連携 Fabric 外部 / 内部 △（Managed Vnet プレビュー中）レイクハウスバッチ/リアルタイムデータのみ Pull型全件更新/単純増加 /差分更新/増分更新 5 ウェアハウスによるクロスデータベースクエリウェアハウスで動作するT-SQLを使用した連携 Fabric 内部 × ウェアハウスバッチデータのみ Pull型全件更新/単純増加 /差分更新/増分更新 6 イベントストリームストリーム処理機能を使用した連携 Fabric 外部 - レイクハウス/KQLデータベース/Reflex/Event Hub対応ソースなどリアルタイムデータのみ Push型単純増加

【外部連携】OneLake への直接アップロード方法について • レイクハウスのWeb UI のほか、OneLake ファイルエクスプローラーをインストールすることで、OneDrive のようにローカルPCからアップロード、ダウンロードが可能※2024/2現在ではプレビュー中
• OneLake ファイルエクスプローラーを使用して Fabric データにローカルでアクセスする - Microsoft Fabric | Microsoft Learn レイクハウスのWeb UI OneLake ファイルエクスプローラー

【外部連携】オンプレミスデータゲートウェイによるデータ収集 • 閉域NW内のデータは、データにアクセスできるマシンにオンプレミスデータゲートウェイをインストールすることで対応する • オンプレミスデータゲートウェイ：Windows マシンにインストールするソフトウェアオンプレミスデータゲートウェイをインストールする |
Microsoft Learn  オンプレミスNW内のマシンにインストール（インターネット経由） ①命令確認 ③取得伝送エンジン：データフロー / データパイプラインあて先：ウェアハウス/レイクハウス ⑤伝送伝送エンジン：オンプレミスデータゲートウェイをインストールしたサーバー ②アクセス ④伝送ソース：オンプレシステムオンプレミスNW Microsoft Fabric ①命令確認 ③取得伝送エンジン：データフロー / データパイプラインあて先：ウェアハウス/レイクハウス ⑤伝送伝送エンジン：オンプレミスデータゲートウェイをインストールしたAzure VM ②アクセス ④伝送ソース：オンプレシステムオンプレミスNW Microsoft Fabric インターネット専用線 Azure 仮想ネットワーク Azure内公衆回線  クラウド仮想マシンにインストール  仮想マシンにプロキシ設定がある場合、プロキシ-インターネット経由となることに注意（Microsoft Peeringの設定にも依存）

【外部連携】仮想ネットワークデータゲートウェイによるデータ収集 • オンプレミスデータゲートウェイの代わりに仮想ネットワークデータゲートウェイを使用することが可能 • 仮想ネットワーク (VNet) データゲートウェイとは | Microsoft
Learn ①デプロイ ③取得伝送エンジン：データフロー / データパイプラインあて先：ウェアハウス/レイクハウス ⑤伝送伝送エンジン：仮想ネットワークデータゲートウェイ ②’アクセス ④伝送ソース：オンプレシステムオンプレミスNW Microsoft Fabric 専用線 Azure 仮想ネットワーク Azure内公衆回線  仮想ネットワークデータゲートウェイを構成  オンプレミスNWへの接続にあたり、DNSやルーティングを制御可能かは要検証プライベートエンドポイント ②アクセス ③取得 Azure リソース

【外部連携】マネージドVnetによる Azure プライベートエンドポイント接続 Microsoft 管理リソースコンピューティング・ネットワークマネージド仮想ネットワークファイアウォール設定自分の所有するリソースコントロール
データ PaaS DB（SQLPool、SQLDB) Blob Storage Fabric プライベートエンドポイントでアクセス Spark Notebook マネージドプライベートエンドポイント Azureサービス不許可 ※Storageは信頼されたリソースで許可可能管理通信 Azure クラウド接続 (Microsoft 管理コンピューティング)

【内部/外部連携】 Fabric の仮想化/レプリケーション機能を使用したデータ連携について • 仮想化 • 物理的にデータを移動せずに実態をもたない仮想的なテーブル or ディレクトリを作成する •
Fabric 機能：OneLakeショートカット • Fabric 内外のデータをレイクハウス上で仮想化 • レプリケーション • 元データと同期をとられたテーブルを物理的に作成する • Fabric 機能：ミラーリング ※プライベートプレビュー中につき詳細不明のため現状は利用方針検討対象外 • Fabric 外部のデータベース（Snowflake や Azure Cosmos DB など）をウェアハウスにレプリケーションする仮想化・レプリケーションを実行する場所元データの場所利用機能レイクハウス Fabric 内部 OneLake ショートカット（内部） Fabric 外部のクラウドストレージ OneLake ショートカット（外部）ウェアハウス Fabric 内部なし Fabric 外部のデータベースミラーリング

【外部連携】信頼されたワークスペースアクセスによるストレージショートカット • Trusted workspace access in
Microsoft Fabric (preview) - Microsoft Fabric | Microsoft Learn 他社のリソースコンピューティング・ネットワーク自分の所有するリソースコントロールデータ DataLake Storage Fabric ホワイトリスト外はブロックワークスペースA （ID:AAA）ワークスペースB （ID:BBB） Fabric ワークスペースC （ID:CCC）リソースインスタンスによる許可 - AAA - BBB

【内部連携】ノートブックまたはクロスデータベースクエリのソースについて • ノートブックとウェアハウスには内部データの再利用について以下の制約があるため、これを補記する • ノートブックのアタッチ：異なるワークスペース上のレイクハウスをアタッチして処理が可能 • ウェアハウスのクロスデータベースクエリ：同ワークスペースに限り、ウェアハウス、レイクハウスのデータを使用した処理が可能処理処理対象
処理可否イメージノートブック同じ or 異なるワークスペース上のレイクハウスアタッチすることにより Read/Write可能ノートブック同じ or 異なるワークスペース上のウェアハウス任意のレイクハウスにショートカットを作成することによりReadのみ可能ウェアハウスクエリ同じワークスペース上のレイクハウス or ウェアハウスクロスデータベースクエリにより Read/Write可能ウェアハウスクエリ異なるワークスペース上のレイクハウス or ウェアハウス同じワークスペース上のレイクハウスにショートカットを作成することで、クロスデータベースクエリによりReadのみ可能

補足）ワークスペースとは • Microsoft Fabric のサービス内で作成したアイテムを格納し、同僚と共同作業するための場所 (Teams における Teamの単位に近いイメージ) •
アクセス制御はワークスペースロールで編集アクセスを付与するか、アイテム個々の単位では閲覧アクセス権の付与が可能 • 個人利用専用のワークスペースとしてマイワークスペースがあるワークスペースワークスペースロールによるアクセス制御管理者メンバー共同作成者ビューアーワークスペース Microsoft Fabric Workspaces - Microsoft Fabric | Microsoft Learn

【内部/外部連携】データフロー Gen2 のTips • データフロー Gen2 を利用するにあたり特に重要なトピックを記載する • クエリフォールディング
• データソース側で可能な処理はデータフロー上にデータを取得する前に実行させる機能 • インジケータにより判断が可能 • Power Query のクエリ評価とクエリフォールディングについて理解する - Power Query | Microsoft Learn • ステージング • データフロー専用の領域に読み込んでから変換することで大量データの変換に対応する仕組み • レイクハウスにロードする場合と、コンピューティング/メモリを大量に消費する変換を実行していない場合には無効にすることで性能向上が見込まれる※ほとんどの場合はステージング無効が効果的とされる • Data Factory スポットライト: Dataflow Gen2 |Microsoft ファブリックブログ |Microsoft ファブリック Power Query でのクエリ折りたたみインジケーター - Power Query | Microsoft Learn 右クリックからステージング状態を確認できる

外部連携におけるゴールデンパターン • 外部データがinputテーブルに投入されるまでで推奨となる方式を主要なシナリオ別に以下に記載する • 単純な連携ではデータパイプラインの利用がパフォーマンス面とファイル管理面で優位だが、オンプレミスデータゲートウェイを使用できないためはDataflow Gen 2に統一 # シナリオ From
To Push/Pull 方式適用する変換内容備考 1 ユーザーからのアップロードクライアントPCなど Uploadレイクハウス（生ファイル Upload） Push OneLake ファイルエクスプローラーなし 2024/2時点ではフォルダアクセス制御が不可のため可能になるまではゴールデンパターン対象外 Uploadレイクハウス（生ファイルUpload） Rawレイクハウス (生ファイルlanding) Pull データパイプラインなし（ファイルの整列のみ） Rawレイクハウス (生ファイルlanding) Rawレイクハウス（生データinput） Pull Dataflow Gen 2 （ステージング無効）フォーマット変換 2 システムからの直接データ収集クラウドストレージ Rawレイクハウス (生ファイルlanding) - OneLake ショートカットなし Rawレイクハウス (生ファイルlanding) Rawレイクハウス（生データinput） Pull Dataflow Gen 2 （ステージング無効）フォーマット変換 3 社内環境上のファイルからのデータ収集（csv/json/Excel）ファイルサーバーなど Rawレイクハウス（生データinput） Pull Dataflow Gen 2 ＋オンプレミスデータゲートウェイフォーマット変換 4 社内システムからの直接データ収集データベースなどのシステム Rawレイクハウス（生データinput） Pull Dataflow Gen 2 ＋オンプレミスデータゲートウェイ(or Vnet データゲートウェイ) フォーマット変換 5 SaaS サービスなどからの直接データ収集 Web サービスなど Rawレイクハウス（生データinput） Pull Dataflow Gen 2 （ステージング無効）フォーマット変換 6 センサーデバイスなどからのデータ収集センサーアプリやクラウドのハブサービスなど Rawレイクハウス（生データinput） Push イベントストリームフォーマット変換可視化の際にリアルタイム性が重要な場合、KQLデータベースへの連携を推奨

ファイル連携時のフォーマットについて • ファイルによりデータを連携する場合、その種類により詳細な確認が必要となる # フォーマット対応可能な方式主要な確認事項推奨の構成注意点、備考 1
csv,tsv Dataflow Gen 2 および Spark での処理 - 区切り文字(delimiter) - 囲み文字（quote） - エスケープ文字 - エンコード - ヘッダー有無 - 区切り文字(delimiter) : , (カンマ) - 囲み文字（quote）: “ (ダブルクォート) - エスケープ文字: ¥ (バックスラッシュ) - エンコード : UTF-8 - ヘッダー有無 : あり - 区切り文字が値に含まれる場合、囲み文字が必要 - 囲み文字が値に含まれる場合、エスケープ文字が必要 2 json Dataflow Gen 2 および Spark での処理 - テーブル化対象のプロパティ特になし 3 Excel Dataflow Gen 2 での処理 - シート名×範囲 or テーブル - ヘッダー有無 - シート名×範囲 or テーブル: テーブル - ヘッダー有無: ありシートの場合、範囲外のレコードは読み取り対象外となる 4 その他のバイナリ Spark × AI モデルでの処理 - バイナリの種類により検討特になし ※Spark で処理する場合にはレイクハウス上に存在する必要あり

内部連携におけるゴールデンパターン • Raw_input以降の内部連携について主要なシナリオ別に推奨を記載する # シナリオ From To 方式適用する変換内容備考
1 生レイヤー内でのクレンジング Rawレイクハウス（生データinput） Rawレイクハウス（生データoutput） Spark ノートブックのアタッチクレンジング Rawレイクハウス（生データinput） Rawレイクハウス（生データError） Spark ノートブックのアタッチクレンジング（品質不良データのふりわけ） 2 整備済みレイヤー内での未加工テーブル、派生テーブルの生成 Rawレイクハウス（生データoutput） Enrichレイクハウス (スタンダードデータ) Spark ノートブックのアタッチなし Enrichレイクハウス (スタンダードデータ) Enrich レイクハウス (派生・強化データ) Spark ノートブックのアタッチプレパレーション 3 消費レイヤー内での BI用テーブル生成 Enrich レイクハウス (スタンダード・派生・強化データ) Curateレイクハウス (ショートカット) OneLakeショートカットなし ※Phase1のみ消費レイヤ用のウェアハウスと整備済みレイヤーのレイクハウスは同一ワークスペースであるため、ショートカットは使用していない Curateレイクハウス (ショートカット) Curateウェアハウス (BI用のテーブル) ウェアハウスのクロスデータベースクエリプレパレーション 4 消費レイヤー内でのデータサイエンス用テーブル生成 Enrich レイクハウス (スタンダード・派生・強化データ) Curateレイクハウス (ショートカットデータ) OneLakeショートカットなし Curateレイクハウス (ショートカットデータ) Curateウェアハウス (特化データデータサイエンス用) Spark ノートブックのアタッチプレパレーション 5 消費レイヤー内での GUIデータ生成 Enrich レイクハウス (スタンダード・派生・強化データ) Curateウェアハウス (特化データ BI用) Dataflow Gen2 プレパレーションコード記述が難しい場合に採用

連携範囲と更新方法のゴールデンパターン • 連携範囲と更新方法について主要なシナリオ別に推奨となる例を記載する # シナリオ From 連携範囲の取得方法 To 更新方法備考
1 更新日付をもつデータの連携データソースシステムスタンダードテーブル上のレコードがもつ更新日付より後のデータを取得（またはファイルとして提出） Rawレイクハウス（Input/Error/Output）単純増加この時点で連携タイミングを付与して後続に同じデータ量を渡す Rawレイクハウス（Output）対象の連携タイミングのデータを抽出 Enrichレイクハウス (Standard) 差分更新 2 物理削除のあるデータの差分連携データソースシステム対象期間のデータを抽出（またはファイルとして提出） Rawレイクハウス（Input/Error/Output）単純増加 Rawレイクハウス（Output）対象の連携タイミングのデータを抽出 Enrichレイクハウス (Standard) 増分更新 3 差分取得が難しいデータの連携データソースシステムその時点の全件を取得（またはファイルとして提出） Rawレイクハウス（Input/Error/Output）単純増加 Rawレイクハウス（Output）対象の連携タイミングのデータを抽出 Enrichレイクハウス (Standard) 全件更新 4 履歴化テーブルの生成 Rawレイクハウス（Output）派生・強化テーブル上のもつ更新日付より後の連携タイミングのデータを抽出 Enrichレイクハウス (Enrich) 差分更新履歴化テーブルの内容についてはデータモデリングの章で解説 5 BI用のテーブルの生成 Enrichレイクハウス (Standard or Enrich) 生成対象範囲を取得 Curateウェアハウス (BI用のテーブル) 全件更新全件更新に耐えられない場合、増分更新検討するが、BI要件は変更要求が多くなる傾向があるため、ロジック変更に対応しやすい全件更新から開始することを推奨する 6 派生テーブルや、消費レイヤー上のテーブル Enrichレイクハウス (Standard) 生成対象のテーブルの要件により決定

データ統合の関連リンク集 • Spark Notebook • ノートブックの使用方法 - Microsoft Fabric |
Microsoft Learn • Microsoft Spark Utilities (MSSparkUtils) for Fabric - Microsoft Fabric | Microsoft Learn • Apache Spark ライブラリを管理する - Microsoft Fabric | Microsoft Learn • Sparkを使ったデータ分析・処理の書き方 - 10のTips #Databricks – Qiita • PySpark 開発時に知っておくべき７つのテーマ #Python – Qiita • createOrReplaceTempViewの代わりにパラメータ化クエリを使う備忘録 #Databricks - Qiita • ウェアハウスクエリ • Transact-SQL リファレンス (データベースエンジン) - SQL Server | Microsoft Learn • 制限事項 - Microsoft Fabric | Microsoft Learn • Warehouse のパフォーマンスガイドライン - Microsoft Fabric | Microsoft Learn • Transact-SQL を使用してウェアハウスにデータを取り込む - Microsoft Fabric | Microsoft Learn • テーブルの複製 - Microsoft Fabric | Microsoft Learn • データフロー Gen 2 • Power Query を使用するときのベストプラクティス - Power Query | Microsoft Learn • PQ Tips 3 -小ネタ集（列・リスト操作） - テクテク日記 (hatenablog.com) • Microsoft Fabric の Dataflow Gen2 コネクタ - Microsoft Fabric | Microsoft Learn • データフローを保存して発行する方法 - Microsoft Fabric | Microsoft Learn • データパイプライン • Microsoft Fabric のデータパイプラインコネクタ - Microsoft Fabric | Microsoft Learn • テンプレート - Microsoft Fabric | Microsoft Learn • Microsoft Fabric の Data Factory: よく寄せられる質問 - Microsoft Fabric | Microsoft Learn

4-2. BIの全体像 • 分析基盤において、BIはセマンティック層と可視化層に分割される • 本章では、BIにおける以下のポイントとFabric の機能を使用したゴールデンパターンについて記載する
• セマンティック層 • 可視化を行うビジネスユーザーにわかりやすいモデルを定義し必要に応じてデータのキャッシュを行うことで可視化を効率化する層 • 可視化層 • 自由分析/対話型レポート/定型レポートと呼ばれるようなデータが可視化される成果物を作成する層可視化層セマンティック層データウェアハウス層データソース一般にBIツールがカバーする範囲データ統合意味づけラストワンマイル変換分析操作追記中

セマンティック層の役割 • 「セルフサービスBIツール」などのキーワードに対して統制がない状態下では混乱が生まれる • BIモデルの濫立：分析のたびに再発明をしてしまい非効率 • 整合性の欠如：異なるロジックが各所にちらばって正しいデータが得られなくなる • 全社的に参照すべきBIモデルの集約管理を行うことで、常にアクセスしやすい場所で正しいデータを得られる状態を作る •
誰もが同じ結果を導出できるようにビジネスロジック、コンテキスト（言語やビジネス用語など）、データを一か所に集約 • 測定項目やリレーションシップ、モデル特有の変換処理の定義 • 物理名からビジネス用語への読み替えや、多言語対応など • データモデルを認定し、使われるべきデータをガイドする 83 アナリストセマンティック層ロジックデータ信頼された共通のBIモデルコンテキスト追記中

Microsoft も陥っていたBIの課題（セルフサービスモデル濫立）  一貫性の欠如  国や、個社、部署ごとに独自の考え方で売上を計上する「税別？税込？年間契約は月次で按分？」 
再利用されないデータ  アナリストが分析ではなく整理・収集に時間を消費「各アナリストが個別で集約を行い、ロジックが組織全体で利用されない」 https://docs.microsoft.com/ja-jp/power-bi/guidance/center-of-excellence-microsoft- business-intelligence-transformation

Fabric におけるセマンティック層 = セマンティックモデル • Fabric Power BI において、セマンティックモデルはレポートのソースとして必ず必要なものである •
1つのセマンティックモデルからは複数のレポートなどの可視化用成果物が作成可能 • Fabric の Power BI セマンティックモデルは MS SQL Server Analysis Services の技術を継承、改良しており、外部ホストモデルとして従来の Analysis Services モデルを利用してレポートを作成することも可能 • Fabric でホストされるモデルには 2種類のセマンティックモデルが存在する • Power BI サービスのセマンティックモデル - Power BI | Microsoft Learn # 観点セマンティックモデルセマンティックモデル（デフォルト） 1 主要なユースケースレポートを作成するためのデータソースレイクハウス/ウェアハウスのデータ探索 2 ストレージモード Import / Direct Lake / Direct Lake 全てに対応 ※2024/2時点では Direct Lake は Power BI Desktopでは作成不可 Direct Lake のみ 3 開発、カスタマイズ Power BI Desktop や、3rd Party ツールで開発が可能 Fabric では Web 上からも作成可能レイクハウス/ウェアハウスと同時に自動作成される。 Web 上でのみカスタマイズ可能（一部） 4 作成できる数複数可能レイクハウス/ウェアハウスにつき一つのみ 5 備考 Fabric 上で実行したSQLクエリやKQLクエリの結果からレポートを作成する際にはレポートのソースとして自動作成される

セマンティックモデル（デフォルト）について • ウェアハウスとレイクハウスが作成されると、セマンティックモデル（デフォルト）が自動作成される。これにより、ウェアハウス/レイクハウス内のデータをクイックに探索することが可能になっている • ただし、ウェアハウス/レイクハウスにつき一つのモデルとなるため注意 • なお、現在はどのテーブルをセマンティックモデル（デフォルト）に含めるか、またデータの自動更新の有無を制御可能 • 参考：既定の
Power BI セマンティックモデル - Microsoft Fabric | Microsoft Learn セマンティックモデルセマンティックモデル（デフォルト）セマンティックモデル（デフォルト）

セマンティックモデルのストレージモードの比較 # 観点 Import Direct Query Direct Lake 1 説明
Power BI サービス（Fabric）上にデータをインメモリ保持するストレージモード Power BI サービス（Fabric）上にデータをもたず、常に外部データソースを参照するストレージモード Import の利点「インメモリ保持による高速応答」と、Direct Queryの利点「常にデータベースの最新データを表示できる」の二つの利点を併せ持つ Fabric 限定の新しいストレージモード 2 データソースレイクハウス SQL エンドポイント or ウェアハウスに加えて、Power BI Desktop のコネクタに準拠レイクハウス SQL エンドポイント or ウェアハウスに加えて、Power BI Desktop のコネクタに準拠レイクハウス SQL エンドポイント or ウェアハウスのみ 3 レポート操作時などのクエリ応答速度高速低速高速 4 表示可能なデータ鮮度モデル更新時点のデータ常にデータソースの最新情報常にレイクハウス SQL エンドポイント or ウェアハウス最新状態 5 制限 Direct Query への変更は不可メモリサイズに上限あり（メモリサイズは完全更新時に元のモデルの約2倍必要） Power BI Desktop上での変換や、利用できるDAXなどオンデマンドでメモリ上のデータを更新するが、メモリにキャッシュしきれない量のデータは Direct Query で動作する（既定の動作） 6 最適化のポイントセマンティックモデルのサイズ削減データソース側のモデリング、チューニングウェアハウスのモデリングおよびセマンティックモデルのサイズ削減 7 その他の利点データを腹落ちしないためデータの地理的な移動制限がある場合に有効 8 備考モデル内のテーブル単位でDirect Query と Import を設定された複合モデルを構成可能

Import モード • 操作時の待機時間が短く、多くのシーンで推奨される • データの保持場所はデータセット内 • データの鮮度は①のスケジュール次第（最大48回/day *API経由での更新は無制限） •
メモリへのキャッシュとなるため、サイズに上限があるデータソースレポートユーザー Power BI キャッシュ ①データソース～データセット間頻度：定期利用時の待機時間：なし操作クエリ（DAX） ②データセット～レポート間頻度：随時（操作時）利用時の待機時間：低 ③レポート～ユーザ間頻度：随時（操作時）利用時の待機時間： Power BI サービス→ユーザとクラウドの距離に依存 Power BI Desktop →低セマンティックモデル

Direct Queryモード • 操作時の待機時間が最も長く、機能にもいくつかの制限がある • データの保持場所はデータソースにとどまる • 常にデータソースの最新の状態を取得できる • データを持たないため、サイズの上限なし
データソースレポートユーザー Power BI クエリ（SQL） ①データソース～データセット間頻度：随時（操作時）利用時の待機時間：長 DB性能・データソースとの距離に依存操作クエリ（DAX） ②データセット～レポート間頻度：随時（操作時）利用時の待機時間：低 ③レポート～ユーザ間頻度：随時（操作時）利用時の待機時間： Power BI サービス→中ユーザとクラウドの距離に依存 Power BI Desktop →低セマンティックモデル

KQL クエリからレポートを生成する • Fabric 上で記述した KQL クエリセットからレポートを作成可能 •
この際、セマンティックモデルが自動的に Direct Query モードで作成される • リアルタイム分析で有効

Direct Lake モード • 操作時の待機時間が短く、Fabric を利用する場合にのみ利用でき、インポートとDirect Query の利点を併せ持つ • データの保持場所はデータセット内
• クエリに基づいてキャッシュを行うため、データの鮮度は常に最新 • メモリへのキャッシュとなるためサイズに上限があるが、上限を超える量が必要な場合はキャッシュではなくDirect Query に変更されるため、巨大なデータにも対応は可能（フォールバック動作設定により制御可能）データソースセマンティックモデルレポートユーザー Power BI クエリに応じてキャッシュ ①データソース～データセット間頻度：不定期利用時の待機時間： - キャッシュできる量の場合：初回のみ長 - キャッシュできない量の場合：長操作クエリ（DAX） ②データセット～レポート間頻度：随時（操作時）利用時の待機時間：低 ③レポート～ユーザ間頻度：随時（操作時）利用時の待機時間： Power BI サービス→ユーザとクラウドの距離に依存 Power BI Desktop →低 OneLake 上の Delta キャッシュしきれない場合は Direct Query 動作

ストレージモード検討の出発点リアルタイムに監視する必要のないデータである No:頻繁に更新されるデータを常にリアルタイムに確認する必要がある Yes : 日中を含めて日に何回かのバッチ処理で十分 Yes:全てのデータがインメモリに格納可能
モデルサイズが（更新時も含めて）最大メモリに収まり、地理的なデータ保存要件がないデータソースが Fabricにある Direct Lake で利用できない機能を使わずに作成できる No :複雑な集計を一般的DBで行う No : Azure SQL などのDBである Yes : Fabric がソースである集計が単純か、データソースがリアルタイム分析向けのエンジンである Yes: 速報レベルの単純な集計ストリームデータに対するニアリアルタイム分析が必要 No : 必要ではない Yes:必要 KQL クエリ用の Direct Query Direct Query （または複合モデル） Direct Lake BI要件の再検討 Import No: 利用したい機能がある Yes: Direct Lake で実現可能 No: 削減が難しそう

Direct Lake 利用時の認証周りの注意 • Direct Lake は既定ではSSOによる認証が行われるため、背後のレイクハウス/ウェアハウスへの権限がないとデータが読み込めないエラーが発生するため、以下の対応が必要になる場合がある • Microsoft
Fabric Power BI で「このビジュアルのデータを読み込むことができません」の対処例 #Microsoft - Qiita

カレンダーテーブルの生成について • 特に重要な項目としてカレンダーテーブルの存在があり、年月日での集計は必ずカレンダーテーブルを使用して行うことを推奨 • カレンダーテーブルはウェアハウスなどで事前に作成するほか、DAXにより計算テーブルとして作成が可能（データの期間は動的であることが多いのでDAXでの生成が対応とし
て楽） • Power BI Desktop で日付テーブルを設定し、使用する - Power BI | Microsoft Learn • Power BI開発ガイドライン素案カレンダーテーブル #PowerBI – Qiita • Power BI Desktop で日付テーブルを作成する - Power BI | Microsoft Learn

可視化の目的と分類 • 非定型の可視化 • データ探索：データの内容やパターン、異常値を可視化して理解を深める • アドホック分析：手元のツールを使ってデータを自由に探索し、特定の質問に答えるか新たな洞察を得る • 定型の可視化 •
分析レポート：定期的に更新されるデータが可視化された、BIにおける主要な成果物 › 定型帳票：定型的な構造となっており、帳票としての出力が目的となっている › 対話型レポート：ドリルダウンや、相互作用するフィルタなどにより、ユーザーがデータを動的に探索できるよう設計されている › スコアカード：組織のパフォーマンスをモニタリングするために、特定の指標（メトリック）が強調される • ダッシュボード：一目で状況を把握してアクションを起こすために分析レポートが集約される

Power BI における可視化作業と分析成果物のマッピング # 観点レポート改ページ対応レポートダッシュボードアプリ探索
スコアカード 1 可視化の分類対話型レポート定型帳票ダッシュボードなしデータ探索スコアカード 2 概要とリンク複数のビジュアル、ページにより分析のストーリーを表現するレポート (link) 複数ページにまたがり、正確にレイアウトが調整されたレポート(link) 複数のレポート、ビジュアルをピン止めし、一つの画面にまとめる(link) レポートやダッシュボードを組織内の他のユーザーと共有するためのパッケージ(link) Pivot 形式を中心にデータを動的に分析し、視覚的な形で結果を把握する(link) 特定の指標をメトリックとして設定、追跡し、目標管理を行う(link) 3 開発方法 Power BI Desktop や Power BI サービス Power BI Report Builder や、Power BI サービス Power BI サービス Power BI サービス Power BI サービス Power BI サービス 4 制約 1つのセマンティックモデルのデータのみ利用可能 Power BI サービス上での開発は簡易なものに限定されるフィルタなどの操作は基本不可１つのワークスペースでは1つのアプリとなる一部のビジュアルに制限あり 5 他の成果物との連動 - ダッシュボードにピン留め可能 - アプリに含めることが可能 - アプリに含めることが可能 - アプリに含めることが可能複数の成果物を含めることが可能不可 - アプリに含めることが可能 - レポートに含めることが可能 6 容量ライセンス要否不要不要不要不要要不要 7 備考フィルタリングやドリルダウンを行うことができる。印刷や PDF 生成に最適化されている一目で全体の状況を把握するために最適化されているオーディエンス設定により表示されるコンテンツを制御可能

任意のツールによるセマンティックモデルに接続した分析や出力について • セマンティックリンクを使用した Python分析のソースとして • セマンティックリンク (プレビュー) とは -
Microsoft Fabric | Microsoft Learn • Fabric Semantic Link and Use Cases • テーブルデータ（csv, Excel）として • レポートからはcsv,Excel形式での出力が可能（件数上限あり） • Power BI ビジュアルからデータをエクスポートする - Power BI | Microsoft Learn • Excel Pivotソースとして • Excel から直接接続してPivot 分析が可能 • Power BIの差別化要素4 -Excelで分析機能 - テクテク日記 (hatenablog.com) • Excel の Power BI セマンティックモデルエクスペリエンス - Power BI | Microsoft Learn • SQL Server Management Studio 等のツールからの接続先として • [DAX Studio] 各種データソースへの接続方法 #PowerBI – Qiita • Power BI での XMLA エンドポイントを使用したセマンティックモデルの接続と管理 - Power BI | Microsoft Learn

BI におけるゴールデンパターン • 代表的なシナリオにおけるパターンを記載する • ビジュアル化においては自由度が高いが、以下を参考にビジュアル（＝クエリ）の総量を減らすことや見易さを心掛けること • 「Power BIビジュアルデザインBest Practice
| ドクセル (docswell.com)」 • Power BI のデザイン効果の高いレポート - Training | Microsoft Learn # シナリオ想定されるモデリングストレージモード採用する分析成果物 1 前日または日中定期的に更新されたデータについてのレポートの全社展開スタースキーマを原則とする Import or Direct Lake レポート、ダッシュボード、スコアカードおよびそれらを含むアプリ 2 PoCまたは、一部のメンバーによるセルフサービス BI フラットワイドテーブルも含めて任意のモデルで迅速性を優先 Import レポート、ダッシュボード、スコアカード必要に応じてアプリ 3 データの探索任意。既定のセマンティックモデル利用から始めることを推奨 Direct Lake レポート、探索 4 Fabric 上で不定期に更新されるデータについてのレポートの展開スタースキーマを原則とする Direct Lake レポート、ダッシュボード、スコアカードおよびそれらを含むアプリ 5 リアルタイムレポートフラットワイドテーブル KQL クエリより生成されたDirect Query レポート、ダッシュボードおよびそれらを含むアプリ

Power BI 関連リンク集 • Power BI の最適化 • Power BI
の最適化ガイド - Power BI | Microsoft Learn • Power BIビジュアルデザインBest Practice | ドクセル (docswell.com) • セマンティックモデル • 既定の Power BI セマンティックモデル - Microsoft Fabric | Microsoft Learn • Power BI サービスのセマンティックモデル - Power BI | Microsoft Learn • Power BI 用 Copilot で適切に動作するようにデータモデルを更新する - Power BI | Microsoft Learn • ストレージモード • 「インポート」と「Direct Query」データセットの違い | Japan CSS Support Power BI Blog (jpbap- sqlbi.github.io) • Power BI と Microsoft Fabric での Direct Lake について説明する - Power BI | Microsoft Learn • Comprehensive Guide to Direct Lake Datasets in Microsoft Fabric • Pre-Warming The Direct Lake Dataset For Import-Like Performance (fabric.guru)

4-3. データサイエンスの全体像 • データサイエンスは一般に以下のプロセスで構成される • ビジネス要求の理解 • データの取得と理解 •
データストアの設置 • データパイプライン • データ探索 • モデリング • 特徴量エンジニアリング • 機械学習モデルの訓練 • 機械学習モデルの評価 • デプロイ • リアルタイム推論 • バッチ推論 • モデルパフォーマンスの監視 • Team Data Science Process ライフサイクル - Azure Architecture Center | Microsoft Learn

Fabric におけるデータサイエンスタスクと機能のマッピング • ビジネス要求の理解以外のデータサイエンスタスクと Fabric の機能を以下にマッピングする *デプロイに関してリアルタイム推論エンドポイントやモデル監視は現在Fabricの対応外 Fabric 機能データの取得と理
解モデリングデプロイ* 説明レイクハウス〇 - - レイクハウスを構成することで機械学習モデルのソースとなる非構造化～構造化データを扱うことができます。また、ショートカットを通して、組織内のデータへのアクセスポイントを作成可能ですイベントストリーム〇 - - ストリームデータをレイクハウスに転送することが可能です。 Spark ノートブック〇〇〇 Spark により、データ探索ならびに特徴量データの準備をはじめ、機械学習のモデルトレーニングやテスト、バッチ推論といったデータサイエンスの主要なタスクがカバーされます。また、データラングラーにより GUI ベースでデータ内容の確認とPandasコード生成することも可能です。データフロー Gen2 〇 - - GUIによるデータの取得と変換が可能です。データパイプライン〇〇 - データの転送や、各データサイエンス処理についての自動化されたワークフローを管理します Power BI レポート / 探索〇 - - 豊富なビジュアルでデータの傾向や異常値を容易に発見すること可能です。実験 - 〇 - Spark ノートブックと統合された MLflow により、モデルトレーニング時のアルゴリズムや、テストメトリックを詳細に記録管理することが可能です。モデル - 〇〇機械学習モデルを評価メトリックと共にバージョン管理したり、推論時にロードすることが可能です。

データサイエンス関連リンク • MLOps • Step-by-step MLOps v1.2 - Speaker Deck
• MLflowのご紹介：オープンソース機械学習プラットフォーム #Databricks - Qiita • MLOps 成熟度モデルと Azure Machine Learning での実現イメージ (zenn.dev) • Azure Databricks を使用したデータサイエンスと機械学習 - Azure Architecture Center | Microsoft Learn • ノートブックでモデル追跡用に MLflow を構成する - Training | Microsoft Learn 追記中

4-4. ワークフローの全体像 • 実装した各処理はワークフローから呼び出されることにより制御される • 主なワークフローの役割 • スケジューリングなどワークフロー実行契機の制御 • 前アクティビティの結果による条件分岐などの処理間の依存関係の制御
生レイヤー（非公開で履歴保管）データソースデータ利活用整備済みレイヤー（汎用的なデータを公開）消費レイヤー（特定用途向けに変換） Microsoft Fabric ワークフローアクティビティアクティビティアクティビティアクティビティ処理処理処理処理呼出呼出呼出呼出結果による条件分岐など

データパイプライン上の主要なアクティビティデータ統合系 # アクティビティ説明備考 1 データのコピー各データストア間のデータを移動する 2
データフローデータフロー Gen 2 を実行（更新）する 3 ノートブック Spark ノートブックを実行する 4 スクリプト Warehouse や、 Fabric 外部の RDBMS など、SQL 実行に対応した場所で SQL を実行する 5 ストアドプロシージャ Warehouse と MSSQL のデータベース上のストアドプロシージャを実行する 6 KQL KQL データベースと Azure Data Explorer 上で KQL を実行するアクティビティの概要 - Microsoft Fabric | Microsoft Learn

データパイプライン上の主要なアクティビティ制御系 # アクティビティ説明備考 1 If Condition 変数や、各アクティビティの戻り値に基づいて実行先を分岐する
2 切り替え変数や、各アクティビティの戻り値に基づいて実行先を分岐する 3 失敗パイプラインを失敗として終了させる 4 ForEach 配列についてループ処理を行う。GetMetadataと組み合わせてファイル毎のループ処理など 5 変数の設定変数を加工したり、上書きを行う 6 参照(Look up) テーブルやクエリの結果を取得して戻り値として扱う 7 Get Metadata ファイルであればファイル名やフォルダ内のファイルや種類、テーブルであれば列名などを取得して戻り値として扱う 8 パイプラインの呼び出し別のパイプラインを呼び出す。パラメータが設定されたパイプラインの場合はパラメータの引き渡しが可能アクティビティの概要 - Microsoft Fabric | Microsoft Learn

データパイプライン上の主要なアクティビティ通知系アクティビティの概要 - Microsoft Fabric | Microsoft Learn #
アクティビティ説明備考 1 Office 365 Outlook アクティビティ設定時にサインインしたアカウントからメールを送信する Outlook を利用できるライセンスをもったアカウントが必要 2 Teams アクティビティ設定時にサインインしたアカウントから Teams に投稿する Teams を利用できるライセンスをもったアカウントが必要

パイプライン構成のゴールデンパターン • パイプラインは役割で分類することを推奨する。 • 特にスケジュールパイプラインで得られるメリットが大きい • 同じスケジュール条件で実行される処理の集約 • 通知の実装の一本化（現在のところ通知にはアクティビティの設定が必要なため、ステップ数の多いメインパイプラインでは実装上のコストが大きい
スケジュールパイプラインメインパイプラインスケジュール設定メイン呼び出し通知失敗時サブ1呼び出しサブ2呼び出しサブ3呼び出しサブパイプライン処理エラーアクティビティ成功処理・・・サブパイプライン処理処理・・・サブパイプライン処理処理・・・成功成功 • スケジュールパイプラインの役割 • スケジュール実行条件の構成 • スケジュール実行結果の通知処理 • メインパイプラインの役割 • 各処理間の順序制御 • サブパイプラインの役割 • 実際の処理を実行するアクティビティの実行 • テストがしやすい機能単位で構成する

処理コストを下げるTips • Spark ノートブックからはほかのSpark ノートブックを実行できる機能があるため、これを活かすことでSpark クラスタの起動数=CU消費を最小限に抑えられる • パイプラインで実行されるアクティビティそれぞれで Spark クラスタが起動するため、並列実行では容量あたりのSpark
コア数の上限に抵触しやすく、無駄なコストがかかる • パイプライン同時実行時の上限は緩和の予定がある模様（Microsoft Fabric での Synapse Data Engineeringの新機能と計画内容 - Microsoft Fabric | Microsoft Learn） • Spark コア数の上限について参考：Microsoft Fabric Spark のジョブ同時実行数の考察と検証 #Microsoft – Qiita • ただし、起動できるノートブックは同じレイクハウスにアタッチされたもののみなので注意 • その他参考：Using runMultiple To Orchastrate Notebook Execution in Microsoft Fabric パイプラインノートブックA ノートブックB × 〇パイプラインオーケストレーションノートブックノートブックB ノートブックA オーケストレーションノートブックのクラスタ起動のみでOK ノードブックA、Bそれぞれでクラスタが起動 Microsoft Spark Utilities (MSSparkUtils) for Fabric - Microsoft Fabric | Microsoft Learn

5. サービス管理領域

サービス管理領域についてサービス管理領域は以下のトピックについて記載する • セキュリティ：Fabric 上のアクセス制御におけるガイダンス • ガバナンス：ワークスペースおよびアイテムの管理に関するガイダンス • コスト・パフォーマンス最適化：パフォーマンス問題の追跡方法、ライセンスのガイダンスデータ蓄積領域
データ処理領域データモデリング BI データサイエンスデータソース打ち手・施策サービス管理領域セキュリティガバナンスコスト・パフォーマンス最適化データ連携データ配置ワークフロー

5-1. セキュリティの全体像 • Microsoft Fabric のセキュリティのうち特に開発に関わるアクセス制御を中心に記載する • いくつかのスコープでロールとアクセス制御が存在する Microsoft Fabric
Microsoft Azure ワークスペースワークスペースワークスペースサブスクリプション Fabric 容量仮想マシンオンプレミスデータゲートウェイ仮想ネットワーク上資産割当て OneLake 割当て Copilot for Fabric Fabric インフラ Fabric アイテム（成果物） Microsoft Entra ID テナントディレクトリロール（すべてのロールについて特権あり）容量ロールワークスペースロールアイテムの共有アイテム内データ（エンジンレベル）のアクセス制御一部継承関係あり > > データ連携接続ロールゲートウェイロール一部継承関係あり > 管理者向け管理者と開発者双方に関連あり開発者向け一部継承関係あり

管理ロールの概要(管理者向け) # アクセス制御種別ロール名ロールの管理場所権限概要備考 1 ディレクトリロール Fabric
管理者 M365 管理センターや、 Azure Portal - テナント/容量/ワークスペースなど、Fabricに関するすべての設定 - 容量ロール/ゲートウェイロール/ワークスペースロールの割り当て - 成果物全体の分布状況の確認グローバル管理者ロールなどの上位での代用可能 2 容量ロール容量管理者管理ポータルまたは Azure SKUの場合:Azure Portal - Workspaceへの容量割当 - 容量ロールの割当 - 容量設定の変更 3 容量ロール容量共同作成者管理ポータル - Workspaceへの容量割当組織全体に割り当て可能 • 参考 • Microsoft Fabric 管理者ロールを理解する - Microsoft Fabric | Microsoft Learn • Power BI Premium で容量を構成および管理する - Power BI | Microsoft Learn

ゲートウェイ、接続ロールの概要(管理者、開発者双方向け) # アクセス制御種別ロール名ロールの管理場所権限概要備考 1 ゲートウェイロール管理者
接続とゲートウェイ管理画面 - ゲートウェイの設定変更 - 全てのデータソースへの接続の管理 - ゲートウェイロール/接続ロールの管理 2 ゲートウェイロール再共有による接続作成接続とゲートウェイ管理画面 - 接続の作成ロールの割当 - データソースへの接続の作成 3 ゲートウェイロール接続作成接続とゲートウェイ管理画面 - データソースへの接続の作成 4 接続ロール所有者接続とゲートウェイ管理画面 - データソースへの接続時の資格情報の更新 - データソースへの接続の削除 - 接続ロールの管理 - データソースの利用接続の作成者が所有者となる 5 接続ロール再共有可能ユーザー接続とゲートウェイ管理画面 - 接続ロールの割当 - データソースの利用 6 接続ロールユーザー接続とゲートウェイ管理画面 - データソースの利用 • オンプレミスデータゲートウェイを使用した接続は共有することで、複数のユーザーが同じ資格情報を使ってデータソースを利用できる • 参考 • セキュリティロールの管理 | Microsoft Learn

ワークスペースロールの概要(特に開発者向け) # アクセス制御種別ロール名ロールの管理場所権限概要備考 1 ワークスペースロール管理者
ワークスペース管理画面 - ワークスペース、アイテムの全ての管理 2 ワークスペースロールメンバーワークスペース管理画面 - メンバー以下のユーザーの追加 - アプリ、アイテムの共有設定の変更 - アプリ、アイテムの編集と削除などの操作 3 ワークスペースロール共同作成者ワークスペース管理画面 - アイテムの編集と削除などの操作 - T-SQL による詳細なアクセス許可の付与 ※ユーザーの追加は不可委任されている場合にはアプリの更新が可能 4 ワークスペースロールビューアーワークスペース管理画面 - ウェアハウス、SQL 分析エンドポイント、セマンティックモデルやレポートなどのアイテムへの読み取りアクセス ※レイクハウス内のデータファイルを参照するには追加の権限が必要 • ワークスペース単位でロールを付与することで、配下のアイテムへの権限をもつ • 参考 • Power BI のワークスペースのロール - Power BI | Microsoft Learn • ワークスペースのロール - Microsoft Fabric | Microsoft Learn • レイクハウスでのワークスペースロールとアクセス許可 - Microsoft Fabric | Microsoft Learn

Power BI アイテムの共有方法 • Power BI アイテム(レポート、セマンティックモデル、ダッシュボードなど)には4つの共有方法がある。一部を除き、ワークスペースロール付与以外での共有は読取アクセス専用の共有となる • 共有時には追加の権限設定が可能 •
再共有の許可：共有されたユーザーがさらに別のユーザーに共有する権限の追加 • ビルドアクセス許可（レポート、アプリのみ）基になったセマンティックモデルを使用した別のレポートの作成を許可する権限の追加 • 編集アクセス許可（セマンティックモデルのみ）：編集権限を追加 • ワークスペースロールから継承された権限の部分削除は不可であることに注意 • 参考 • セマンティックモデルのアクセス許可 - Power BI | Microsoft Learn • 同僚や他のユーザーと Power BI レポートやダッシュボードを共有する - Power BI | Microsoft Learn • Power BI でアプリを発行する - Power BI | Microsoft Learn # アクセス制御種別説明備考 1 アプリの発行による権限付与レポート、ダッシュボードをアプリとして発行し、対象ユーザーを選択することで読み取りアクセスを許可する。組織全体への共有が可能 2 ワークスペースロールの付与対象ユーザーにワークスペースロールを付与することで、編集を含む権限を付与する 3 直接アクセス権限の付与対象ユーザーに直接権限を付与する 4 共有リンクの発行(ダッシュボードorレポートのみ) 読取アクセス（および追加の権限が設定された）可能なリンクを作成する組織全体への共有が可能テナント設定で組織全体の共有リンクの作成を無効化可能エクスポートと共有のテナント設定 - Microsoft Fabric | Microsoft Learn

ウェアハウス、レイクハウスの共有方法 • ウェアハウス、レイクハウスの共有方法は二つ。ただし、それぞれに追加できるアクセス許可が異なるため、以下で整理する • ワークスペースロールの付与 • 直接アクセス権限の付与 • 参考 •
レイクハウスの共有とアクセス許可の管理 - Microsoft Fabric | Microsoft Learn • ウェアハウスを共有し、アクセス許可を管理する - Microsoft Fabric | Microsoft Learn # アクセス許可ワークスペースロール付与時の動作直接アクセス権限付与時の動作レイクハウスの場合ウェアハウスの場合 1 アイテムの書き込み共同作成者以上で自動付与付与不可テーブルやファイルの作成が可能テーブルなどのオブジェクトの作成が可能 2 アイテムの読み取りビューアー以上で自動付与共有時に自動的に付与 SQL分析エンドポイントを通して接続が可能（オブジェクトへの権限はなし）接続が可能（オブジェクトへの権限はなし） 3 ReadData ビューアー以上で自動付与追加が可能 SQL分析エンドポイントを通してすべてのテーブルおよびオブジェクトの参照が可能すべてのテーブル、オブジェクトの参照が可能 4 ReadAll 共同作成者以上で自動付与追加が可能テーブルの背後を含む、ファイルの表示が可能ショートカットの作成が可能ショートカットの作成が可能 5 ビルド許可共同作成者以上で自動付与追加が可能既定のセマンティックモデルを使用したレポート作成が可能既定のセマンティックモデルを使用したレポート作成が可能

エンジンレベルのアクセス制御 • 個々のオブジェクトや、列、行でのアクセス制御が必要な場合は、それぞれのエンジン内の設定で、アクセス制御を実施することで制御可能 • レイクハウス • ファイル、フォルダレベルのアクセス制御：不可 • SQL
分析エンドポイント上のアクセス制御：T-SQL による権限付与（後述） • ウェアハウス • T-SQL による権限付与（後述） • セマンティックモデル • 行レベルセキュリティ：ロールの管理設定（後述） • オブジェクト、列レベルセキュリティ：

SQL分析エンドポイントとウェアハウスのエンジンレベルアクセス制御について • 前提 • 編集許可を持つユーザーにはエンジンレベルのアクセス制御は不可 • 直接アクセス権限の付与により、SQL Server 接続可能なログインとして登録する必要がある •
設定方法： SQLコマンドにより制御 • オブジェクトレベル：SQL の詳細なアクセス許可 - Microsoft Fabric | Microsoft Learn • 行レベル： Fabric データウェアハウスでの行レベルのセキュリティ - Microsoft Fabric | Microsoft Learn • 列レベル： Fabric データウェアハウスでの列レベルのセキュリティ - Microsoft Fabric | Microsoft Learn

セマンティックモデルの行レベルセキュリティ設定方法概要 • 前提 • セマンティックモデル自体の編集許可を持つユーザーには行レベルセキュリティなどの制御は不可 • オブジェクト/列/行レベルセキュリティ • （共通）ロールの管理設定からロールを作成し、ユーザー、セキュリティグループをロールに割り当てる •
行レベルセキュリティの場合：ロールごとの表示範囲を制限するために、フィルタ式を適用する • Power BI での行レベルのセキュリティ (RLS) - Power BI | Microsoft Learn • 静的な行レベルセキュリティ（フィルタ条件を直接埋めこむ手法） • 動的な行レベルセキュリティ（フィルタ条件をテーブル化する手法） • オブジェクト/列レベルの場合：Power BI でのオブジェクトレベルのセキュリティ (OLS) - Power BI | Microsoft Learn ADユーザ Or セキュリティグループを割り当て可能 DAX式を適用するテーブルを指定固定値 or 関数username()を利用して、権限制御テーブル上のレコードを特定させる追記中

静的な行レベルセキュリティのイメージ Power BI Report セマンティックモデル MSEntraID 営業第二課部署ID 部署名 001
営業第一 002 営業第二営業第一課ロール設定 … … 組織マスタテーブルトランザクションテーブル部署ID 売上額 001 100 001 300 部署ID 売上額 002 200 部署ID 売上額 001 100 001 300 002 200 ロールセキュリティグループ部署ID 営業第一 UserID@Domain 001 営業第二 UserID@Domain 002 … … ユーザー接続閲覧制御課のセキュリティグループごとにデータモデルにロールを設定 …

動的な行レベルセキュリティのイメージ jiro.yamada UserName 閲覧部署ID taro.suzuki 002 Jiro.yamada 002 taro.suzuki
ロール設定 … … 権限コントロールテーブルトランザクションテーブル部署ID 売上額 002 200 部署ID 売上額 001 100 001 300 002 200 ロール DAX式を設定 user ‘権限コントロールテーブル名’[UserName ] = username() ※username()は、接続しているユーザー名を取得する関数ですユーザー接続閲覧制御部署ID 売上額 002 200 配属部署ID:001 配属部署ID:002 Power BI Report セマンティックモデル

アイテムの共有方法のゴールデンパターン • Power BI アイテムにはアプリによる権限管理の方法があるため、リンクや、直接アクセス権限の付与は限定的な利用法とすることを推奨する # シナリオ共有方法追加のアクセス権限
備考 1 Power BI アイテムのビジネスユーザーへの共有アプリによる配布（行レベルセキュリティが必要な場合にはロールを設定）ビルド許可、再共有の許可レポートの濫立に懸念がある場合は、追加のアクセス許可を削除する。信頼できるレポートには承認機能を利用することも推奨 2 レイクハウスやウェアハウスを利用して二次的なコンテンツを作成するユーザーへの共有直接アクセス権限の付与全てのデータを見せてよい場合：ReadData、ビルド許可ショートカットの作成も許可する場合： ReadAll 見せる範囲を制限したい場合は追加のアクセス権限を付与せずにT-SQLコマンドで追加の制御を行う ※ショートカットの作成も不可となる 3 同開発チーム内の共有共同作成者以上のワークスペースロールの付与により設定 4 成果物レビュアーへの共有ビューアーロールの付与アプリにする前の状態をクイックに見る場合にこのような使い方を行う

アイテムの承認 • 組織内で信頼できるデータ製品にラベリングをすることで、コラボレーションを促す承認の概要 - Microsoft Fabric | Microsoft Learn
 昇格→認定の順でラベル付け  認定されたグループのみが判定を行う設計となっている

補足）環境ごとのアクセス権の使い分け例 • 成果物のステータスにより、環境に対して必要なアクセス権は異なる点も考慮することを推奨 # ユーザー種別開発環境テスト環境本番環境理想的な状態 1
システム管理者ワークスペース管理者ワークスペース管理者ワークスペース管理者すべての環境について、フルアクセス権限を持つが、可能なら Just-in-time アクセスなどの特権管理措置を用いることが望ましい 2 リリース用のアカウントワークスペースメンバーワークスペースメンバーワークスペースメンバーすべての環境について、リリースができるための権限を持つが、自動化用の無人アカウントとして運用する 3 開発者（データエンジニア、データサイエンティスト、BIアナリスト）ワークスペースメンバーワークスペースメンバー (リリース用アカウントを構成できる場合はビューアー＋ReadAll のみ) ワークスペースメンバー (リリース用アカウントを構成できる場合はビューアー＋ReadAll のみ) 環境の認識ミスによる事故を防ぐため、可能であれば本番環境へは直接の編集権限を持たないことが望ましい 4 成果物レビュアービューアー Power BIアイテム：アプリによる配布 Fabric アイテム：直接アクセス権限 Power BIアイテム：アプリによる配布 Fabric アイテム：直接アクセス権限開発環境において、成果物のブラッシュアップをするための権限と、テスト環境でビジネスユーザーと同等のシナリオを実施するための権限構成を検討する 5 コンテンツ利用者（ビジネスユーザーが中心）アクセス権なしアクセス権なし Power BIアイテム：アプリによる配布 Fabric アイテム：直接アクセス権限本番環境において、コンテンツの配信方法に沿ったアクセス権をもつ開発者属性のユーザーであっても、別の開発者の配信するコンテンツに対してのコンテンツ利用者となる場合がある

参考リンク • Microsoft Fabric の OneLake を使用した Common Data Architecture
の構築 |Microsoft ファブリックブログ |Microsoft ファブリック

5-2. ガバナンスの全体像 • Microsoft Fabric においてガバナンスの検討項目は多岐にわたるため、開発を開始するうえで影響の大きい以下のトピックについて検討するものとする • 成果物の開発とライフサイクル管理
• ワークスペース編成 • 全体の利用状況の把握方法追記中 Microsoft Fabric 導入ロードマップ: ガバナンス - Power BI | Microsoft Learn

成果物の命名規則検討ポイント • Fabric アイテム • ワークスペースの編成方針によっては、アイテムの並びが煩雑になることから、アイテムごとに接頭語を定めることを推奨 • Fabric の提供するデータ検索機能(OneLakeデータハブ)ではアクセス可能なあらゆるウェアハウス/レイクハウス/セマンティックモデルなどが表示されるため、管理部署とPJを明確化する目的の命名規則とする
• 例：LH_[事業部略称]_[PJコード]_[ステージ名]_([データプライバシー分類]) -> LH_HC_KPIBI_Raw , LH_HC_KPIBI_Raw_Sensitiveなど • パイプラインなど、役割をもたせるものはその役割がわかることと、表示時の並びの影響をふまえた説頭語を検討する • メインパイプライン： PLM_[事業部略称]_[PJコード]_[取り組み内容] • サブパイプライン： PLS_[事業部略称]_[ステージ名]_[ステージ詳細]_([データソース名など付帯情報]) • データ • テーブル： • 生～整備済みレイヤー › 大文字と小文字が区別され、スペースなど利用不可のため、小文字英数字に統一する › 日本語はローマ字変換 - instant tools (m-bsys.com) により変換し、英語カタカナ表記などの場合は英語表記を使用 • 消費レイヤー › ウェアハウスを採用する BI シナリオのみ日本語での実装が可能 • メジャー、セマンティックモデル上の項目： • ビジネスユーザーにわかりやすいビジネス用語上の名称を使用する

Microsoft Fabric の開発ライフサイクル管理について • Git統合 • Azure DevOps とのGit統合を利用することで、変更履歴の管理などが可能 •
ただし、サポートされるアイテムに注意（Fabric Git 統合の概要 - Microsoft Fabric | Microsoft Learn） • デプロイパイプライン • Fabric では、デプロイパイプラインを使用することで、リリースプロセスを簡素化することが可能 • ただし、サポートされるアイテムに注意（Microsoft Fabric デプロイパイプラインプロセス - Microsoft Fabric | Microsoft Learn）

Fabric の Git 統合の基本イメージ • Web画面上で作業する場合、ローカルブランチ＝ワークスペースのような状態だが、Pushが省略されているような仕様であることに注意 • 参考：組織でとりあえず Git 利用の開始を実施したい方向けガイド
#Git - Qiita Microsoft Fabric Azure DevOps内のリポジトリワークスペースアイテム ①ワークスペースとブランチを接続接続ブランチ ②テキストファイルとして保存される接続 - ワークスペースとブランチを接続 Commit - ワークスペースで実施した作業をブランチに反映 Microsoft Fabric Azure DevOps内のリポジトリワークスペースアイテムブランチ ①Fabric 画面上で変更が発生ワークスペースの更新(Pullに相当) - DevOps上での変更をワークスペースに反映 ②コミットにより変更を反映 Microsoft Fabric Azure DevOps内のリポジトリワークスペースアイテムブランチ ①DevOps上で変更が発生 ②ワークスペースの更新をすることで変更を反映

Git 統合時の共同開発の例 • 作業用のブランチをmainから作成し、個人用のワークスペース（マイワークスペースなど）と接続することで、他者の作業と独立した環境で作業可能 • 精通している場合は、任意の開発ツールで作業用ブランチに変更を行う • mainブランチへマージをすることで複数のブランチの結果が統合・反映される • 同じファイルで、同行で異なる編集を行っている場合、競合が発生するので注意
main 開発ワークスペースアイテムマイワークスペース (jiro.tanaka用) アイテム users/jiro.tanaka users/taro.yamada マイワークスペース (taro.yamada用) アイテム ①独立した自分用の環境で開発 ③Pull Requestにより作業をマージ ②コミット ①独立した自分用の環境で開発 ②コミット ④更新により全員分の作業が反映 ③Pull Request により作業をマージ

Git統合のゴールデンパターン • 開発環境用または個人作業用のワークスペースのみ git 連携を行う。テスト環境、本番環境へは、基本的にデプロイパイプラインで反映をすることを推奨 • ブランチをどのように区分し、利用するかはブランチ戦略と呼ばれ、各組織で方針検討が必要なため、大抵のブランチ戦略において守られることの多い最低限のポイントを記載する •
mainブランチは削除しないように保護する。直接編集しない（ブランチを保護する） • Azure DevOpsではブランチポリシーの設定により削除不可となる：Azure DevOps アクセス許可を無効にする "分岐の削除" オプション - スタックオーバーフロー (stackoverflow.com) • 作業単位でブランチを作成する。ブランチA作成→ブランチA マージ→ブランチB作成→ブランチBマージと作業が進んだ場合、再度ブランチAを使うのではなく、新たにブランチCを作成する • ブランチの命名にスラッシュを使用してブランチを整理する • features/(作業名) • users/(名前)/(作業名) など

デプロイパイプラインの未サポートアイテムの対応について • デプロイパイプラインの未サポートアイテムはまだ多いため、主要なアイテムについてワークアラウンド案を記載する（2024/3時点） • また、レイクハウスについてはサポートされていても、テーブルなどが含まれないため、これらについても記載する # 未サポートアイテムワークアラウンド備考
1 Web上で作成したセマンティックモデルまたは Direct Lakeのセマンティックモデル XMLAでエクスポートして反映する XMLA で Direct Lake セマンティックモデルを別のワークスペースにコピーする #Microsoft – Qiita 2 レイクハウスのテーブル、フォルダテーブル：CREATE IF NOT EXISTS などを使用したDDLノートブックを使用する。フォルダ：python化するか手動作成ショートカット：手動作成が必要現時点でデータベース変更管理ツールについて未検証 3 ウェアハウス手動でデータベースのみ作成 4 ウェアハウスのテーブル DDL スクリプトを使用する。または、dacpacによりスキーマをデプロイする 5 データフロー初回：エクスポート機能を使用する差分反映：詳細エディタ（M言語）の内容を反映同期先の構成と取得元への認証設定が失われることに注意 6 データパイプラインパッケージ化が不可能なため、手動作業となる json表示を比較することは可能

デプロイパイプラインのゴールデンパターン • 未サポートアイテムが多いため、一部のサポート済みアイテムについてのTipsを記載する # アイテム Tips 備考 1 レポートレポートが同じワークスペースである場合は、同じワークスペースのセ
マンティックモデルを参照するため通常は、開発テスト本番と向き先も変わる（自動バインド）仕様があるが、異なるワークスペースに接続されたレポートはデプロイ時にセマンティックモデルを自動変更しないことに注意 2 セマンティックモデル（Direct Lake 以外）配置ルールを使用して、開発と本番でデータソースを切り替える 3 ノートブック配置ルールを使用して開発と本番で既定のレイクハウスを切り替えるノートブックのアタッチには既定ではないレイクハウスを設定可能だが、それらは対応していないため注意

Microsoft Fabric のコンテンツと配信 • ワークスペースの編成は成果物の開発者と、そのコンテンツ管理と深く関係する • コンテンツを「読み取り専用アクセスを用いて他者に配信される成果物」と位置付けたとき、主に以下のように整理される ※データエンジニアリングなどで使用されたコードやパイプラインは開発成果物としてコンテンツとは区別する #
コンテンツの分類該当するアイテム開発者主な配信方法主な配信先備考 1 BI Power BI アイテム（アプリ、レポート、セマンティックモデルなど）データアナリストアプリまたはワークスペース・アイテム権限の付与ビジネスユーザーアプリでの配信を推奨 2 データサイエンスモデルレイクハウスノートブック（モデルの出力プロット結果や解析結果など）データサイエンティストワークスペース・アイテム権限の付与データアナリスト推論のためのエンドポイントは2024/3現在Fabric での提供はない 3 データエンジニアリングレイクハウスウェアハウス KQL データベースデータエンジニアワークスペース・アイテム権限の付与データアナリストデータサイエンティスト

コンテンツスコープと開発者規模の特性 • 各スコープのコンテンツはその配下のスコープで再利用されるとともに、スコープ独自のデータを加えるか、ベースとして新たに生成される傾向がある • 一般に配信範囲と開発者の数は反比例の関係を持つ整備済みレイヤー（汎用的なデータを公開）消費レイヤー（特定用途向けに変換）
コンテンツスコープ個人用コンテンツ (開発サンドボックスなど多岐にわたる利用) 部門A用コンテンツ・・・全社で利用可能な汎用データ全社用コンテンツチームA～Z用チームA～Z用エンタープライズ（全社）配信範囲開発チームの数部門最大最小最大最小チーム個人再利用 +チーム独時のデータ +個人の手持ちデータ部門Z用コンテンツ・・・再利用再利用・・・ +部署独時のデータ

ワークスペース編成の検討ポイント • ワークスペースの編成については以下の流れで検討する • 基本的な編成方針により、成果物と開発チームの管理方法を定める • その他の分類により、ワークスペースを細分化する • データのプライバシーレベルの分類 •
ランドスケープ（開発/テスト/運用）の分類 • その他の注意事項 • 一つのID（ユーザーやアプリケーション）が参加できるワークスペースは最大1000 個まで • Power BI でのワークスペース - Power BI | Microsoft Learn • BIの主要なコンテンツであるアプリは、ワークスペースにつき一つであるため、複数の異なるテーマのBIコンテンツを一つのワークスペースで対応しすぎないようにする • ワークスペースの総数はコンテンツのスコープによって変動することが想定される • エンタープライズコンテンツの開発→全社、または事業につき一つ • 部門/チーム/個人コンテンツの開発→各スコープ（またはプロジェクト）につき発生 › ただし、個人的コンテンツはマイワークスペースによって対応される

ワークスペースの基本的な編成パターン①プロジェクト分離のみ • プロジェクトによる分離パターン • 成果物とコンテンツの集約管理のシンプルさ • 同一ワークスペースではメンバーごとに異なるアクセス制御をかけられない。 • ワークスペース名からコンテンツが予測しにくいエンタープライズプロジェクト用ワークスペース
データエンジニアリングコンテンツデータサイエンスコンテンツ個別プロジェクト用ワークスペース BIコンテンツ全社員関連社員 BIコンテンツ非公開の開発成果物配信非公開の開発成果物配信＆二次利用エンタープライズ開発チーム二次開発チーム配信

ワークスペースの基本的な編成パターン②コンテンツ分離 • コンテンツに基づいた分離パターン • ワークスペースの分類により、提供コンテンツが明確化 • 異なるアクセス設計、異なる開発ライフサイクル（git管理、デプロイパイプライン）で管理可能 • 管理負荷の増加データエンジニアリングワークスペース
データエンジニアエンタープライズプロジェクトデータサイエンスプロジェクト1 データサイエンスコンテンツデータエンジニアリングコンテンツ非公開の開発成果物全社員配信データサイエンティストデータサイエンスワークスペース BIプロジェクト1 BIアナリスト BIワークスペース BIコンテンツデータエンジニアリングコンテンツデータエンジニアデータエンジニアリングワークスペースデータサイエンスコンテンツデータサイエンティストデータサイエンスワークスペース BIアナリスト BIワークスペース BIコンテンツ配信配信配信配信配信関連社員配信

補足）データ統合とデータ分析の関係 • 一般にDWHなどのデータ統合コンテンツとデータ分析のコンテンツは1:Nのような関係になることが多い • 同様にワークスペースもデータ統合用のものは少数、データ分析用のものは多数となることが想定される Bronzeデータ（Raw） Silverデータ（ Enrich
）一元化処理 Goldデータ（ Curate ）集約された汎用データ様々な生データ分析テーマ①用データ分析テーマ②用データ分析テーマ③用データ特化処理特化処理特化処理分析テーマ①部隊分析テーマ②部隊分析テーマ③部隊データ標準化部隊

データプライバシーレベル • 以下のサンプル表のようにデータのプライバシーレベルを定めることを推奨する • データを保護するための既定のラベルとポリシーについて説明します | Microsoft Learn • Azure
でのクラウド規模の分析のデータプライバシー - Cloud Adoption Framework | Microsoft Learn # プライバシーレベル名共有範囲概要技術的対策利用される分類名 ISO 27001分類 1 一般公開社内外への制限なし公開社外公開のために準備された情報 - General 一般(Public) 2 社外秘 - 制限なし社内への制限なし公開社内全般で共有される情報コンテンツレベルのアクセス制御 General 社外秘 (Internal) 3 社外秘 – 限定社内外の制限されたチームのみ漏洩による損害度は低いが、共有先の制限された情報コンテンツレベルのアクセス制御に加えて、エンジンレベルのアクセス制御（行レベルセキュリティなど） General 社外秘 (Internal) 4 秘密社内の特に限定されたチームのみ個人情報など、漏洩が損害となる情報コンテンツレベルのアクセス制御に加えて、データベースの分離やマスキング General(無害化) Sensitive (personal data) 秘 (Confidential) 5 極秘社内の特に限定された個人のみ研究情報など、漏洩が重大な損害となる情報完全に隔離された専用領域と併せてマスキングなどのデータ保護 Restricted 極秘(Strictly Confidential)

ワークスペースの区分項目による細分化パターン • ランドスケープによる属性 • 開発/テスト/運用などの分離要件がある場合に備えて、環境名をワークスペースに付与する開発ワークスペーステストワークスペース運用ワークスペース
• データプライバシーによる属性 • プライバシーレベルにより、ワークスペースが分割される • 秘密ワークスペースからは無害化されたGeneral 属性のコンテンツを生成する、など秘密ワークスペース Sensitiveコンテンツ社外秘以下ワークスペース General コンテンツ General コンテンツ極秘ワークスペース Restricted コンテンツ

利用状況の把握 • 管理者ワークスペースにより全体の把握が可能 • 機能の使用状況と導入レポート - Microsoft Fabric | Microsoft
Learn 追記中 • Microsoft Fabric の Microsoft Purview ハブ - Microsoft Fabric | Microsoft Learn

参考リンク • Git関連 • Introduction to GitLab Flow | GitLab
• GitLab flowから学ぶワークフローの実践 | POSTD

5-3. コスト・パフォーマンスの全体像 • 以下について記載する • コスト最適化について • ライセンスガイド • Fabric
におけるリソース消費単位 = CUの仕様（バースティング、スムージング、スロットリング）について • パフォーマンスについて • 容量メトリックアプリの紹介と主要な利用方法 • その他の監視機能追記中

ライセンスガイド Microsoft Fabric 内での成果物はFabric アイテムと Power BI アイテムに分類され、それぞれで必要なライセンスが異なる

Microsoft Fabric を利用するうえでのライセンスとアイテム Microsoft Fabric の利用では「容量ライセンス」と「ユーザーライセンス」が必要となり、これらの内容により利用可能な操作が決定 • 容量ライセンス：ワークスペースに割り当てることで
Fabric アイテムを作成するためのライセンス SKUによりサイズが変動 • ユーザーライセンス：ユーザー個々が Fabric 環境（ワークスペース）で作業する際に必要となるライセンス。主にPower BI アイテムの作成に影響あり Microsoft Fabric の概念 - Microsoft Fabric | Microsoft Learn

容量ライセンス • ワークスペースに割り当てることで、ワークスペース内で Fabric アイテムの利用が有効化される。割り当てない場合、 Power BI アイテムのみ利用可能な共有容量となる • 購入方法は2種類
• Azure SKU：Azure Portal から Azure リソースとしてデプロイする。こちらが主流となる • 秒単位課金、一時停止・再開・サイズ変更が即時に可能 Azure SKU の購入 • M365 SKU：Power BI Premium Capacity として購入する • 月単位または年単位で課金され、月単位のコミットメントが設定 • 購入した容量は、1 つの容量を複数のワークスペースに割り当てて使用することが可能（以下のイメージ） ※容量ライセンスを共有しない場合、性能制限も独立する Fabric F64 SKU 容量ライセンス Fabric F32 SKU ワークスペース A ワークスペース B ワークスペース C ワークスペース D ワークスペースなし（共有容量）

ワークスペースへの容量ライセンス割当 • ワークスペースの作成時に選択するか後から変更が可能 • ライセンスモード = Pro は容量割当のない状態（共有容量）を指す

容量ライセンスの費用 • Azure SKU 価格は Microsoft Fabric - 価格 |
Microsoft Azure を参照二つの費用区分あり • One Lake（ストレージの費用）： • 完全従量課金モデル（保存されたデータ量と保持している期間に対して課金） • 費用の計算方法：保存されたデータ量の価格×時間 • Microsoft Fabric 容量（コンピューティング費用）： • 固定費型の従量課金モデル（利用がなくても起動状態時間により課金） • 費用の計算方法： SKUに設定された単価×容量が起動状態である時間（秒） • M365 SKU (Power BI Premium Capacity) 価格は価格と製品の比較 | Microsoft Power BI を参照 • Power BI Premium Capacity P1 = Azure SKU F64 の関係となる

ユーザーライセンス • ユーザーに割り当てることで、ワークスペース内でユーザーができるPower BI アイテムに対する操作が決定する ※どちらのライセンスもFabric 容量ライセンスが割り当てられたワークスペース内（マイワークスペースを含む）での Fabric アイテムの作成が可能 •
Fabric 利用の観点では無償版と有償版の2種で大別価格は価格と製品の比較 | Microsoft Power BIを参照 • 無償ライセンス： Fabric Free できること • マイワークスペースでのPower BI レポートや、セマンティックモデルの開発、アップロード • 有償ライセンス：Power BI Pro / Premium Per User できること • マイワークスペース以外でのPower BI レポートや、セマンティックモデルの開発、アップロード

上位容量ライセンスと下位容量ライセンス • Fabric 容量は上位のプランを購入した場合、Copilot や、 Power BI の共有可能範囲の拡大など、機能が拡張される •
上位容量の割り当てられたワークスペースでは・・・ • Copilot for Fabric が利用可能（試用版容量を除く） Fabric Change the Game: Microsoft Fabric での Copilot の使いやすさ |Microsoft Fabric ブログ |Microsoft ファブリック • 無償ライセンス（Fabric Free）ユーザーに対して、Power BI アイテムの閲覧のみ共有が可能 • 上位容量の対象 • M365 SKU ＝ Power BI Premium P1 以上 • Azure SKU = F64 以上

Microsoft Fabric の概念とライセンス - Microsoft Fabric | Microsoft Learn Microsoft
Fabric ライセンスチートシート非公式版

CUとは • Fabric が処理を実行する際に消費するコンピューティングリソースを通貨のように表現したもの • Fabric の SKUによって毎秒供給される量が異なる • F2->2CU/sec
、F64 -> 64CU/sec • 3つの特性により、ピーク時と待機時のスペックの調整を不要にしている • バースティング • 供給CU以上のジョブ実行を許可する機能。突発的な不可に対応する • スムージング • ジョブで消費されるCUを10分または24時間に平滑化する機能。将来の供給CUを含めた過不足が判断される • スロットリング • CUが不足した際に待機時間を調整する機能。対話型ジョブ/バックグランドジョブの種類により挙動が変わる

バースティングとスムージングのイメージ① • Fabric Capacities – Everything you need to know
about what’s new and what’s coming | Microsoft Fabric Blog | Microsoft Fabric より例を紹介購入しているSKU以上の対話型ジョブが発生（レポートの参照など）将来10分間までの区間にCU消費が平滑化されることでCU不足を回避

バースティングとスムージングのイメージ② • バックグラウンドジョブでは平滑化期間が24時間となり、より広い範囲でスムージングが実施されるあわせて巨大なバックグラウンドジョブ（ストアドプロシージャなど）が実行された場合将来24時間までの区間にCUが平滑化されることで対話型ジョブへの影響を回避

バースティングとスムージングのイメージ③ • 各スムージングの結果、超過が発生しても Fabric にただちに影響(スロットリング)が出るわけではない平滑化を実施した結果超過が発生しても、すぐにはスロットリングは発生せず、ジョブの追加実行が可能超過分が一定量を超えない限り、繰り返し訪れるCUの供給で超過分が返
済されていく超過分将来の供給により超過分を解決

スロットリングのイメージ • スロットリングは返済すべき超過が一定量超えた際に発生し、ジョブを遅延または拒否することで超過を返済させる • Fabric の容量スロットリングについて理解する - Microsoft Fabric
| Microsoft Learn • 対話型ジョブ • 超過分が10分間の供給を超えている場合：実行が20秒遅延される • 超過量が60分間の供給を超えている場合：実行が拒否される • バックグラウンドジョブ • 超過分が24時間の供給量を超えている場合に拒否される • バックグラウンド拒否はテーブル一覧の表示さえ不可となるため要注意超過分が 10分(64*60*10)以上で遅延 60分以上で拒否対話型ジョブ超過分が 24時間（64*60*60*24）以上で拒否バックグラウンドジョブ

パフォーマンス分析① • 容量メトリックアプリをインストールすることを推奨する • 基本的な使い方 • 日々のCU消費状況の確認アイテム種類ごとのCU消費量日ごとからドリルダウン可能全体のCU消費量
(30秒間隔で連続的に計測) アイテムごとのCU消費量や実行時間(Duration)の変化並び替えで最も大きくCUを消費しているアイテムを特定する

パフォーマンス分析② • 障害の発生状況の確認 • 特に概要レポートの右上チャートでCUの超過とその影響を確認できる点線を超えてスロットリングが発生していたことがわかる超過の増加から解消（バーンダウン）の確認使用量の多い時間を発見
実行された操作の詳細（スロットリングの対象となった操作など） ※表示される行はスムージングにより別の時間で実行されたジョブも加わるので注意

ノートブックの実行結果の確認方法について • パイプラインから実行されているノートブックの場合、以下の流れで当時のノートブック内容を確認可能

その他のパフォーマンス監視機能 • Power BI レポートの利用状況レポート(アクセス数など) • ワークスペースで使用状況メトリックを監視する (プレビュー) - Power
BI | Microsoft Learn • セマンティックモデルエンジンログの分析 • Power BI で Azure Log Analytics を使用する - Power BI | Microsoft Learn • ウェアハウスや、レイクハウスのエンジンログは現在未提供 • ウェアハウスのクエリインサイト • クエリの分析情報 - Microsoft Fabric | Microsoft Learn

参考リンク • バースティング、スムージング、スロットリング • Power BI Premium の CPU スムージング。
- Power BI | Microsoft Learn • バースト可能な容量 - Microsoft Fabric | Microsoft Learn • Fabric Spark の請求および活用レポート - Microsoft Fabric | Microsoft Learn • Fabric Spark のコンカレンシー制限とキューイング - Microsoft Fabric | Microsoft Learn」 • Microsoft Fabric イベントストリームの容量消費 - Microsoft Fabric | Microsoft Learn • KQL データベースの使用 - Microsoft Fabric | Microsoft Learn • 容量メトリックアプリの使い方 • Microsoft Fabric Capacity Metrics アプリとは? - Microsoft Fabric | Microsoft Learn • Synapse Data Warehouse の使用状況の傾向を観察する方法 - Microsoft Fabric | Microsoft Learn

6. 学習リソース

6-1. MS Learn • 公式ドキュメント • ホームページ：Microsoft Fabric のドキュメント -
Microsoft Fabric | Microsoft Learn • チュートリアルのまとめページ：Microsoft Fabric のエンドツーエンドのチュートリアル - Microsoft Fabric | Microsoft Learn • 試用版の開始方法： Fabric試用版 - Microsoft Fabric | Microsoft Learn • Microsoft Fabric 製品、エクスペリエンス、および項目のアイコン - Microsoft Fabric | Microsoft Learn • トレーニング • 座学、ハンズオンを含めた学習コンテンツ • すべてのコース、ラーニングパス、モジュールを参照する - Training | Microsoft Learn • 資格試験対策 • 試験 DP-600 の学習ガイド:Microsoft Fabric を使用した分析ソリューションの実装 | Microsoft Learn

6-2. ブログなど • 公式ブログ • Microsoft Fabric ブログ • Power
BI ブログ — 更新とニュース | Microsoft Power BI • Japan CSS Support Power BI Blog (jpbap-sqlbi.github.io) • 役立ちリンク • 障害状況とサポートリクエスト発行のホームページ：Microsoft Fabric のサポートと状態 | Microsoft Fabric • アイデアサイトによる機能リクエスト（希望が多い機能はいち早く追加される）：Home (microsoft.com) • Buildでのデジタルイベント動画 : https://aka.ms/build-with-analytics • eブック: Modernize Your Analytics | Microsoft Fabric • Fabric Notes (解説図集)：Fabric Notes - Simple drawings illustrating the main concepts of Microsoft Fabric • スライド集など：GitHub - microsoft/Fabric-Readiness: A collection of useful materials for presenters interested in topics related to Microsoft Fabric

その他情報収集に適したコミュニティ • コミュニティサイト • Home - Microsoft Fabric Community •
JSSUG (Japan SQL Server User Group) – connpass • Power BI 勉強会 - connpass • Microsoft 中の人や MVPなどのブログ • スイさん(Microsoft Fabric CAT)の記事：テクテク日記 (hatenablog.com) • ヤンさんの記事(Microsoft CSA)：Microsoft Fabric - Next Generation Cloud Data Analytics Solution – Qiita • Chris Webb's BI Blog (crossjoin.co.uk) • Sandeep Pawar | Microsoft Fabric • Power BI Checklists — DATA GOBLINS (data-goblins.com) • Small Data And self service – PowerBI & Fabric and Data in General (datamonkeysite.com) • 有志Qiita • PowerBIxyz - Qiita • akihiro_suto – Qiita • ishiayaya - Qiita • yugoes1021 - Qiita • manabian - Qiita • ryoma-nagata – Qiita

Microsoft Fabric 開発ガイド

Microsoft Fabric 開発ガイド

More Decks by Ryoma Nagata

Other Decks in Technology

Featured

Transcript