プレイブック

Fabricレイクハウス内の大規模な（5億行以上）Deltaテーブルを、最適なパフォーマンスとほぼリアルタイムのデータアクセスでクエリする。

→Direct Lakeモードでセマンティックモデルを使用する。

理由: Direct Lakeは、データインポートやクエリ変換をバイパスして、ParquetファイルをOneLakeから直接読み取ります。データ重複やリフレッシュの遅延なしに、インポートモードのようなパフォーマンスを提供します。DirectQueryは遅く、インポートモードは遅延を発生させます。

数百のDAXメジャーを作成せずに、数十のベースメジャー（売上、利益、数量）に一般的な時間インテリジェンス計算（YTD、QTD、MTD）を適用する。

→YTD、QTD、MTDの計算アイテムを持つ計算グループを実装する。

理由: 計算グループはメジャーの増殖を排除します。これらは、選択された任意のメジャーに動的に適用できる汎用的な計算のセットを定義し、モデルのメンテナンスを大幅に簡素化します。

ワークスペース内の複数のセマンティックモデルが共通のディメンションテーブル（例：日付、顧客）を共有して、一貫性を確保し、データ重複を削減する必要がある。

→共有ディメンションを含む「コア」セマンティックモデルを作成する。コアモデルにはDirectQueryを介して、ファクトテーブルにはDirect Lake/Importを介して接続する他の「コンポジット」モデルを構築する。

理由: この「ハブアンドスポーク」アーキテクチャは、ディメンションの単一の真実のソースを促進します。コンポジットモデルは、異なるソースとストレージモードからのデータを統合されたモデルに結合することを可能にします。

ファクトテーブルに複数の日付列（例：OrderDate、ShipDate）があり、これらすべてが単一の日付ディメンションテーブルに関連付けられる必要がある。

→ファクトテーブルと日付テーブルの間に1つのアクティブなリレーションシップと複数の非アクティブなリレーションシップを作成する。メジャーで`USERELATIONSHIP()` DAX関数を使用して、適切な非アクティブなリレーションシップをアクティブにする。

理由: Power BIは2つのテーブル間に1つのアクティブなリレーションシップのみを許可します。このパターンにより、ディメンションテーブルを複製することなく、異なる日付ロールによる分析が可能になります。

大規模なファクトテーブル（数十億行）を持つセマンティックモデルのリフレッシュに時間がかかりすぎる。データの変更頻度が高いのは過去30日分のみである。

→ファクトテーブルで増分リフレッシュを構成する。`RangeStart`と`RangeEnd`パラメーターを設定する。古いデータをアーカイブし（例：過去5年分を保存）、最近のデータをリフレッシュする（例：過去30日分をリフレッシュする）ポリシーを定義する。

理由: これにより、テーブル全体を再ロードするのではなく、新規または変更されたデータを含むパーティションのみを処理することで、リフレッシュ時間とリソース消費を劇的に削減します。

複雑なDAXメジャーが、その数式内で同じ中間値を繰り返し計算するため遅い。

→変数（`VAR`）を使用して中間計算の結果を一度保存し、`RETURN`ステートメントでその変数を複数回参照する。

理由: 変数は、単一のメジャー実行内でエンジンが同じロジックを複数回再評価するのを防ぎ、特に反復的なコンテキストでパフォーマンスを大幅に向上させます。

値（例：製品売上）がより大きな合計（例：全製品売上）に占める貢献度を計算するメジャーを作成する際、他のフィルター（日付など）を尊重する必要がある。

→カテゴリごとの割合には`DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))`を、総計に対する割合には`CALCULATE([Sales], ALL(Product))`を使用する。

理由: `CALCULATE`を`ALL`、`ALLEXCEPT`、または`REMOVEFILTERS`と組み合わせることで、フィルターコンテキストを変更して、パーセンテージ計算の正しい分母を取得できます。

レポートで、ユーザーが視覚化で表示するメトリック（例：「売上」、「コスト」、「利益」）を選択できるスライサーが必要である。

→メトリック名を持つ非接続テーブルを作成する。`SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)`のような単一のDAXメジャーを使用する。

理由: このパターンは、フィールドパラメーターをよく使用しますが、ブックマークや複数のビジュアルを必要とせずに計算を切り替える動的でユーザーフレンドリーな方法を提供し、レポートをよりインタラクティブかつ簡潔にします。

エンタープライズBIチームが、プロフェッショナルツール（Visual Studio、Tabular Editor、SQL Profilerなど）を使用してFabricセマンティックモデルを管理、デプロイ、トラブルシューティングする必要がある。

→ワークスペースのXMLA Read/Writeエンドポイントを有効にする。

理由: XMLAエンドポイントは、セマンティックモデルを標準のAnalysis Servicesインスタンスとして公開し、プログラムによるアクセスや複雑なモデリングタスクのために、幅広い高度なBIおよびALMツールのエコシステムからの接続を可能にします。

Direct Lakeモデルのパフォーマンスが遅い。調査の結果、DirectQueryモードにフォールバックしていることが判明した。

→DAX Studioまたはパフォーマンスアナライザーを使用して、フォールバックを引き起こしているクエリを特定する。一般的な原因には、サポートされていないDAX関数、複雑なRLS、または最適化されていない/古いレイクハウスが含まれる。

理由: Direct Lakeには制限があります。クエリがサポートされていない機能を使用すると、サイレントに低速なDirectQueryエンジンにフォールバックします。パフォーマンスを回復するには、根本原因を特定して修正する（例：DAXの最適化、DeltaテーブルでのOPTIMIZEの実行）ことが重要です。

モデルに多対多のリレーションシップ（例：ブリッジテーブルを介した売上とプロモーション）がある。メジャーが「多」側でフィルターすると、誤った合計を返す。

→リレーションシップのクロスフィルター方向（ディメンション -> ブリッジ -> ファクト）が正しく設定されていることを確認する（通常は単一方向）。必要に応じて、より複雑なM2M計算には`TREATAS`や`INTERSECT`などのDAX関数を使用する。

理由: 不正確なクロスフィルター方向は、M2Mモデルで誤った結果が生じる一般的な原因です。双方向フィルターが機能するように見えても、多くの場合、曖昧さや二重カウントにつながります。明確に定義されたモデルと明示的なDAXパターンは、より堅牢です。

大規模なファクトテーブルに対してDirectQueryを使用するコンポジットモデルが遅い。ほとんどのユーザークエリは集計レベル（例：カテゴリ別の月間売上）である。

→インポートモードでユーザー定義の集計テーブルを作成する。集計テーブルには、一般的なクエリの粒度（月、カテゴリ）で事前に集計されたデータを含める必要がある。

理由: クエリエンジンは、可能な場合、クエリをより小さなインメモリ集計テーブルに自動的にリダイレクトし、大幅なパフォーマンス向上をもたらします。より詳細なレベルが必要なクエリに対してのみ、DirectQueryソースにアクセスします。

従来のフィルターベースのアプローチではパフォーマンスが悪い、DAXでの複雑な累積合計または移動平均の計算。

→`WINDOW`や`OFFSET`などのDAXウィンドウ関数を使用する。

理由: これらの関数は、ソートされた行セットに対する位置計算のために特別に最適化されています。重いフィルタリングやコンテキスト遷移に依存する古いパターンよりも、多くの場合、パフォーマンスが優れており、構文も単純です。

7月1日に始まる会計年度を持つ会社の年度累計（YTD）合計を計算する。

→オプションの`YearEndDate`パラメーターを指定して`TOTALYTD`または`DATESYTD`関数を使用する。例：`TOTALYTD([Sales], 'Date'[Date], "6/30")`。

理由: 年度末日パラメーターを指定することは、DAX時間インテリジェンス関数にカスタム会計カレンダーを認識させるための、正しく最も簡単な方法です。

各ステージが異なるデータベース接続文字列を持つDev、Test、Prodステージ間でセマンティックモデルを昇格させる。

→デプロイメントルールを使用してFabricデプロイメントパイプラインを使用する。

理由: デプロイメントルールは、各環境のデータソース接続、パラメーター、その他の設定の変更を自動化します。これにより、デプロイ後の手動によるエラーが発生しやすい変更を回避します。

リファレンス↗

ビジネスドメインが独自のデータプロダクトを所有および管理する分散型データメッシュアーキテクチャを実装する。

→ドメイン固有のワークスペースを作成する。OneLakeショートカットを使用して、データ所有権を一元化することなく、ドメイン間でのデータ共有と消費を可能にする。

理由: このパターンは、ドメイン所有権とデータアズアプロダクトというデータメッシュの原則と一致します。ワークスペースは所有権の境界を提供し、ショートカットは相互運用性レイヤーを提供します。

開発者チームがソース管理とバージョン履歴を使用してFabricアイテム（セマンティックモデル、レポート、ノートブック）で共同作業する必要がある。

→FabricワークスペースのGit統合を構成し、Azure DevOpsまたはGitHubリポジトリに接続する。

理由: Git統合はFabricアイテム定義をテキストファイル（JSON、TMDL）として保存し、ブランチ、プルリクエスト、バージョン追跡などの標準的なDevOpsプラクティスを可能にします。これはエンタープライズグレードのApplication Lifecycle Management（ALM）に不可欠です。

レイクハウステーブルを変更する前に、エンジニアは影響を受けるすべてのダウンストリームレポートとセマンティックモデルを特定する必要がある。

→Lineage Viewを使用し、レイクハウスアイテムで「インパクト分析」を選択する。

理由: この機能は、すべての依存関係の完全な自動化されたビューを提供します。これは、複雑な分析環境で変更を管理し、予期しない破損を防ぐための重要なガバナンスツールです。

チームが、差分比較やマージが容易なテキストベースの人間が読める形式でセマンティックモデルをバージョン管理する必要がある。

→Power BIファイルをPower BI Project (.pbip) として保存する。これにより、モデル定義がTabular Model Definition Language (TMDL) 形式で保存される。

理由: TMDLは、テーブル、メジャーなどについて個別のテキストファイルを持つフォルダー構造としてモデルを表現する開発者フレンドリーな形式です。これは、GitベースのコラボレーションとCI/CDにとってバイナリの.bimファイルよりもはるかに優れています。

メダリオンアーキテクチャ（Bronze、Silver、Gold）を実装し、物理的なデータ重複なしにレイヤー間でデータにアクセスする必要がある。

→OneLakeショートカットを使用して、他のレイクハウスまたはレイヤーのデータを参照する。

理由: ショートカットはOneLakeのシンボリックリンクです。これらは統一された名前空間を提供し、データをコピーせずにアクセスできるため、論理的なデータメッシュまたはメダリオンアーキテクチャに最適です。

リファレンス↗

Azure SynapseからFabricへ、既存のT-SQL中心の分析ワークロードを移行する。

→Fabric Data Warehouseを使用する。

理由: Fabric Warehouseは完全なT-SQL互換性を提供するため、既存のSQLスクリプト、ストアドプロシージャ、アナリストクエリを最小限の変更で移行するための理想的なターゲットです。Lakehouse SQLエンドポイントは読み取り専用のT-SQLアクセスを持ち、書き込みにはSpark SQLを使用します。

大量かつ高速なストリーミングデータ（例：IoTテレメトリー）をサブ秒のレイテンシーで取り込み、クエリする。

→取り込みにはFabric Eventstreamを、ストレージと分析にはKQL Databaseを使用する。

理由: これはFabricに組み込まれた目的別のストリーミング分析スタックです。KQL（Kusto Query Language）は、ストリーミングデータ上での時系列分析に最適化されており、バッチ指向のレイクハウスやウェアハウスよりもはるかに低いレイテンシーを提供します。

レイクハウスでディメンション変更の完全な履歴を保持するために、SCD（Slowly Changing Dimension）タイプ2を実装する。

→Sparkノートブックまたはパイプラインで`MERGE INTO`ステートメントを使用する。ビジネスキーで一致させ、`WHEN MATCHED`で古いレコードを更新し（`IsCurrent`をfalse、`EndDate`を現在に設定）、`WHEN NOT MATCHED`で新しいレコードを挿入する。

理由: Delta Lakeの`MERGE`操作はアトミックな upsert 機能を提供するため、FabricレイクハウスでSCDロジックを実装する最も標準的で効率的な方法です。

オペレーショナルデータベース（例：Azure SQL DB）からFabricレイクハウスへ、ほぼリアルタイムでデータをレプリケートして分析する。

→Fabric Mirroringを使用する。

理由: Mirroringは、Fabricに組み込まれた低レイテンシー、低インパクトの変更データキャプチャ（CDC）ソリューションです。これにより、データとスキーマの変更がDeltaテーブルとしてOneLakeに自動的にレプリケートされ、複雑なETLパイプラインは不要になります。

APIから複雑でネストされたJSONデータを取り込み、フラット化された構造化されたDeltaテーブルに変換する。

→PySparkノートブックを使用する。`from_json`のような関数でスキーマを解析し、`explode`で配列を行にフラット化する。

理由: PySparkは、複雑で進化するJSON構造をプログラムで処理するための最も強力で柔軟なツールを提供し、標準のコピーアクティビティの機能をはるかに超えます。

企業ファイアウォールの内側にあるオンプレミスSQL ServerデータベースからFabricにデータを取り込む。

→ローカルネットワーク内のサーバーにオンプレミスデータゲートウェイをインストールして構成する。Fabricでゲートウェイをデータソースとして追加する。

理由: ゲートウェイは安全なブリッジとして機能し、インバウンドファイアウォールポートを開く必要なしに、Fabricクラウドサービスとオンプレミスデータソース間でクエリとデータを中継します。

大規模で頻繁に更新されるDeltaテーブルのクエリパフォーマンスが、多数の小さなデータファイルの蓄積により低下した。

→`OPTIMIZE`コマンドを実行して、小さなファイルを大きなファイルに圧縮する。必要に応じて、頻繁にフィルターされる列で`ZORDER BY`を使用して、関連データを共存させる。

理由: ファイル数が少なく、かつファイルが大きいほど、Sparkが読み取る効率は大幅に向上します。Z-orderingはデータスキッピングを改善し、クエリが読み取るデータ量をさらに削減します。これはDeltaテーブルの重要なメンテナンス作業です。

ストリーミング時系列データを固定された重複しない時間間隔（例：5分ごとのセンサーごとの平均温度）に集計する。

→`summarize`演算子と`bin()`関数を使用するKQLクエリを使用する。例：`SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`。

理由: `bin()`関数は、KQLにおいて、集計のためにイベントを固定時間バケット（タンブリングウィンドウ）にグループ化するための標準的で高度に最適化された方法です。

Dataflow Gen2のリフレッシュが遅い。データソースはAzure SQLのようなリレーショナルデータベースである。

→Power Queryエディターで変換ステップを確認し、クエリフォールディングがアクティブであることを確認する。フォールディングを最大化するようにステップの順序を変更または修正する。

理由: クエリフォールディングは、変換ロジックをソースデータベースにプッシュバックして、単一のネイティブクエリとして実行します。これは、すべての生データをデータフローエンジンにプルしてメモリ内で変換するよりもはるかに効率的です。

Sparkノートブックが、非常に大きなファクトテーブル（数十億行）と小さなディメンションテーブル（数千行）の間で遅い結合を実行している。

→ヒント（`spark.sql.functions.broadcast`）を提供するか、オプティマイザーに統計に基づいて選択させることで、ブロードキャスト結合を使用する。

理由: ブロードキャストは、小さなテーブル全体をすべてのエグゼキューターノードに送信します。これにより、大きなテーブルのデータを再パーティション分割してネットワーク経由で送信する必要があるコストのかかる「シャッフル」操作が回避され、パフォーマンスが劇的に向上します。

データパイプラインが複数のアクティビティをオーケストレートしている。1つのアクティビティが失敗する可能性があるが、その後の独立したアクティビティは引き続き実行され、全体的な失敗はログに記録される必要がある。

→アクティビティの依存関係を構成する。結果に関係なく実行されるべきアクティビティは、「完了」条件で前のアクティビティに依存させるべきである。

理由: これにより、堅牢な並列実行パスを構築できます。「成功」と「失敗」の条件に対して別々のブランチを作成し、カスタムのロギングまたは通知ロジックを実装できます。

`last_modified`タイムスタンプを持つソースからデータを増分的にロードするパイプライン。

→ウォーターマークパターンを実装する。前回の正常な実行からの`max(last_modified)`を保存する。次回の実行で、`last_modified`が保存されたウォーターマークよりも大きいレコードをソースにクエリする。

理由: これは、変更タイムスタンプを提供するソースからの増分ロードにとって最も効率的なパターンであり、新規または更新されたデータのみが処理されることを保証し、データ転送と計算を最小限に抑えます。

IoTデータのリアルタイムストリームを分析して、センサーの読み取りにおける異常なスパイクやディップを検出する。

→Eventhouse/KQL Database内のKQLクエリで`series_decompose_anomalies()`関数を使用する。

理由: この組み込みのKQL関数は、時系列異常検出のために特別に設計されています。季節性、トレンド、残差成分に系列を自動的に分解し、統計的に有意な外れ値を特定するため、手動での設定は最小限で済みます。

データを移動せずに、Warehouse、Lakehouse、およびミラーリングされたAzure SQL Databaseからのデータを単一のT-SQLクエリで結合する必要がある。

→WarehouseまたはLakehouse SQLエンドポイントから実行されるクエリで、3パート命名規則（`database.schema.table`）を使用する。ショートカットを使用してミラーリングされたデータベースを参照する。

理由: Fabricは、データ仮想化を可能にする、単一のSQLステートメントを使用して同じワークスペース内の異なるFabricアイテム間でデータにアクセスできる統合クエリエンジンを提供します。

データフローが、一部の行が無効である可能性のあるファイルを処理する必要がある。フロー全体が失敗してはならず、有効な行はロードされ、無効な行はログに記録されるべきである。

→Power Queryで、行を検証し「IsValid」列を作成するステップを追加する。次に、その時点から2つの参照クエリを作成する。1つは`IsValid = true`でフィルターして宛先にロードし、もう1つは`IsValid = false`でフィルターしてエラーログにロードする。

理由: このパターンは、データストリームを分割することで堅牢なエラー処理を提供します。数行の不良データによってプロセス全体が停止するのを防ぎ、データ品質の問題を監査するための明確なメカニズムを提供します。

ユーザーが自身のIDに対応するデータのみを表示するようにする行レベルセキュリティ（RLS）を実装する（例：営業マネージャーが自分の店舗のみを見る）。

→ユーザーをデータエンティティにマッピングするセキュリティテーブルを作成する。RLSロールで、`[ManagerEmail] = USERPRINCIPALNAME()`のようなDAXフィルター式を使用する。

理由: ダイナミックRLSはスケーラブルです。各人またはエンティティに対して静的なロールを作成する代わりに、データ駆動型のアプローチを使用します。`USERPRINCIPALNAME()`はAzure AD IDを正しく解決します。

特定のユーザーグループから機密性の高い列またはテーブル全体（例：Salary）を非表示にし、それ以外のセマンティックモデルへのアクセスは許可する。

→セキュリティロールを定義し、Tabular Editorなどの外部ツールを使用してオブジェクトレベルセキュリティ（OLS）を構成し、テーブル/列のアクセス許可を「None」に設定する。

理由: OLSは、モデルメタデータの可視性に対してきめ細かい制御を提供します。行をフィルターするRLSとは異なり、OLSはオブジェクト全体を非表示にします。XMLAエンドポイントを介して構成する必要があります。

ユーザーがFabricでパフォーマンスの低下とスロットリングを報告している。管理者は根本原因を特定する必要がある。

→Fabric Capacity Metricsアプリを使用する。

理由: このアプリは、キャパシティユニット（CU）消費量、スロットリングイベント、およびワークロードタイプ（例：セマンティックモデルクエリ、データフローリフレッシュ）ごとのリソース使用量に関する詳細な洞察を提供します。これは、パフォーマンス監視とキャパシティ計画のための主要なツールです。

レポートとダッシュボードが接続先のセマンティックモデルの機密ラベルを自動的に継承するデータ分類ポリシーを適用する。

→機密ラベルのダウンストリーム継承に関するテナント設定を有効にする。

理由: これにより、データガバナンスが自動化され、データソースに適用された保護（例：「機密性が非常に高い」）がすべてのダウンストリームコンテンツで一貫して適用され、データ漏洩のリスクが低減されます。

Fabric Warehouseで、一般ユーザーはマスキングされたPIIデータ（例：`XXX-XX-1234`）を表示し、特権ユーザーは完全なマスクされていないデータを表示する。

→Warehouseの機密列に動的データマスキング（DDM）を適用する。特権ユーザーロールに`UNMASK`権限を付与する。

理由: DDMは、ユーザー権限に基づいてデータをオンザフライで編集するデータベースレベルのセキュリティ機能です。データビューまたはデータの個別のコピーを必要とせずに、機密データをその場で保護します。