プレイブック

メダリオンアーキテクチャで、未加工のソースデータをキャプチャするための初期データ取り込み層を設計する。

→最小限の変換と寛容なスキーマでデータを Bronze layer に取り込む。

理由: 再処理、監査、およびデータリネージのために、形式が不正なレコードを含む元のデータの忠実性を保持する。

Fabric のアーティファクト向けに、分離された環境とプロモーションプロセスを実装する。

→Fabric Deployment Pipelines を使用し、開発、テスト、本番のワークスペースステージを明確に区別する。

理由: 本番ワークロードに影響を与えることなく、変更をテストし、アーティファクトを昇格させるための構造化された安全なメカニズムを提供する。

本番の Fabric アイテムへの変更に対して、ソース管理と承認ワークフローを強制する。

→Fabric ワークスペースを Azure DevOps Git と統合する。ブランチポリシーを使用してプルリクエストレビューを強制する。

理由: バージョン管理、変更追跡、および必須のピアレビューを可能にし、データエンジニアリングを DevOps のベストプラクティスに合わせる。

パイプライン展開中に環境固有の接続文字列の変更を自動化する。

→展開パイプラインで展開ルールを構成し、各ステージのデータソース接続をパラメータ化する。

理由: 手動による展開後の構成を排除し、エラーを削減し、各環境が正しいデータソースに接続することを保証する。

分離と共有ガバナンスの両方を必要とする複数のビジネスユニットのためにワークスペースを整理する。

→ビジネスユニットごとに個別のワークスペースを作成し、それらを Fabric Domains の下にグループ化する。

理由: ワークスペースはコンテンツとセキュリティの分離を提供し、Domains は関連するワークスペース間での一元化されたガバナンスと検出を可能にする。

データの発見性を向上させ、ビジネスユーザーにデータセットの品質を伝える。

→lakehouse のテーブルに説明とタグを適用し、Endorsement ラベル（Promoted、Certified）を使用する。

理由: Endorsement レベルはユーザーの信頼を築き、レポート作成と分析のための高品質でキュレーションされたデータセットに導く。

すべての Fabric アイテムで一貫したデータ分類と保護を保証する。

→Microsoft Purview Information Protection と統合し、秘密度ラベルの下流継承を有効にする。

理由: データソースから semantic model やレポートなどの下流のアーティファクトへの秘密度ラベルの適用を自動化し、セキュリティポリシーを強制する。

Fabric capacity のサイジングにおける主要な要素を決定する。

→ワークロードの同時クエリ実行とコンピュート要件を分析する。

理由: Fabric capacity はデータストレージの量ではなく、コンピュート操作（Capacity Units）によって消費される。同時実行性とジョブの複雑さが主要なドライバーである。

Fabric のショートカットから外部の ADLS Gen2 アカウントへの安全な本番レベルのアクセスを提供する。

→Azure AD 認証を使用する Service Principal を使用し、ストレージアカウントに対して最小特権の RBAC ロールを付与する。

理由: Service Principal は最も安全で監査可能な方法であり、共有アカウントキーや SAS トークンのリスクを回避する。

ソースに影響を与えることなく、Fabric 内で Azure SQL Database のほぼリアルタイムの読み取り専用レプリカを作成する。

→Azure SQL Database に Fabric Mirroring を使用する。

理由: Mirroring は、データ変更を OneLake に Delta tables として低遅延で継続的にレプリケーションし、ETL 開発なしでのリアルタイム分析に理想的である。

データセットを別のワークスペースと共有するか、コピーを作成せずに外部データにアクセスする。

→ソース lakehouse テーブルまたは外部データ場所を指す Shortcut を作成する。

理由: Shortcut はシンボリックリンクとして機能し、OneLake 内のデータの統合ビューを提供しながら、データの重複、ストレージコスト、および同期の問題を回避する。

高速ストリーミングデータと履歴バッチデータを組み合わせて統合分析を行う。

→リアルタイム取り込みには Eventstream を使用し、統合ストレージには Delta Lake tables を備えた Lakehouse を使用する。

理由: Eventstream はストリーミングパスを処理し、Delta Lake の ACID プロパティにより、ストリーミングの追加とバッチ更新の両方のターゲットとして機能できる。

同じ lakehouse データに対して、T-SQL ベースの分析と Python ベースのデータサイエンスの両方を有効にする。

→Lakehouse のために自動生成される SQL analytics endpoint を活用する。

理由: Fabric は、同じ Delta tables に対してデュアルエンジンアクセスを提供する。T-SQL クエリ用の SQL endpoint と、ノートブック用の Spark engine であり、データの重複はない。

オンプレミスのデータソース（例: Oracle、SQL Server）から Fabric にデータを取り込む。

→オンプレミスデータゲートウェイをインストールし、構成する。

理由: ゲートウェイは安全なブリッジとして機能し、オンプレミスネットワークと Fabric クラウドサービス間でデータを中継し、ソースをインターネットに公開することはない。

新しいファイルが Azure Blob Storage に到着するとすぐに自動的に処理する。

→データパイプラインに Storage Event trigger を使用し、BLOB 作成イベントで発火するように構成する。

理由: イベント駆動型トリガーは、より低いレイテンシを提供し、スケジュールされたポーリングよりも効率的である。スケジュールされたポーリングはデータを見逃したり、不必要に実行されたりする可能性がある。

ページ単位でデータを返す REST API からすべてのレコードを抽出する。

→Copy activity で、REST コネクタの組み込みページネーションルールを構成する。あるいは、Until または ForEach ループと変数を使用してページトークンを管理する。

理由: 動的な次のページリンクやオフセットを処理し、すべてのデータが取得されるまですべての API ページを反復処理するプロセスを自動化する。

Slowly Changing Dimension Type 2 ロジックを実装するか、Change Data Capture（CDC）ストリームを処理する。

→`WHEN MATCHED` および `WHEN NOT MATCHED` 句を含む Delta Lake MERGE 操作を使用する。

理由: MERGE はアトミックな upsert（更新/挿入/削除）機能を提供し、SCD2 パターンで履歴レコードを維持するための基礎となる操作である。

ネストされたオブジェクトの配列を含む DataFrame 列を個別の行に変換する。

→PySpark ノートブックで配列列に `explode()` 関数を適用する。

理由: `explode()` は、配列を非ネスト化し、配列内の各要素に対して新しい行を作成するための標準 Spark 関数である。

ステートフルなストリーミング集計（例：ウィンドウ化されたカウント）で遅延到着データを処理する。

→Spark Structured Streaming クエリのイベントタイム列に watermark を構成する。

理由: Watermarking は、エンジンが遅延データを待つ期間の時間しきい値を定義し、状態が無期限に増加するのを防ぎながら正確性を保証する。

タイムスタンプ列はあるが CDC がないソースシステムから増分データロードを実行する。

→高watermark パターンを実装する。前回の実行からの最大タイムスタンプを保存し、次回の実行でソースをフィルタリングするために使用する。

理由: これは、フルテーブルスキャンのオーバーヘッドや正式な CDC の要件なしに、新規または更新されたレコードのみを抽出するための効率的で一般的なパターンである。

一時的なネットワークの問題やソースシステムの負荷により、パイプラインアクティビティが断続的に失敗する。

→アクティビティの再試行ポリシーを、指定された回数と指数バックオフ間隔で構成する。

理由: 失敗した操作を自動的に再試行することでパイプラインに回復力を持たせ、多くの場合、手動介入なしに一時的な問題を解決する。

リアルタイムの探索的分析のために、大容量、低レイテンシのテレメトリまたはログデータを取り込み、クエリを実行する。

→データを Eventhouse に取り込み、Kusto Query Language (KQL) を使用してクエリを実行する。

理由: Eventhouse（Azure Data Explorer 上に構築）と KQL は、高性能な時系列およびログ分析のために特別に構築されている。

同じ変換ロジックを共有する数十のテーブルをロードするための、単一の再利用可能なパイプラインを作成する。

→メタデータ駆動型アプローチを使用する。ソース/宛先情報をコントロールテーブルに保存し、ForEach アクティビティを使用して反復処理し、パラメータを汎用子パイプラインに渡す。

理由: このパターンは非常にスケーラブルで保守性が高く、テーブルごとに個別のパイプラインを作成することによる重複と管理オーバーヘッドを回避する。

SQL Server のようなリレーショナルデータベースからデータを取得する Dataflow Gen2 のパフォーマンスを最適化する。

→折りたたみ可能な変換を設計する。Power Query エディタでクエリ折りたたみステータスを確認する。

理由: クエリ折りたたみは変換ロジックをソースデータベースエンジンにプッシュし、すべてのデータを Spark engine にプルして変換するよりも大幅にパフォーマンスが向上する。

監査のために、または偶発的な更新から回復するために、過去の特定の時点に存在していたテーブルをクエリする。

→クエリで `VERSION AS OF` または `TIMESTAMP AS OF` を使用して、Delta Lake のタイムトラベル機能を使用する。

理由: Delta Lake はすべてのトランザクションをネイティブにバージョン管理するため、手動スナップショットやバックアップを必要とせずに特定時点のクエリを可能にする。

ユーザーが自身の地域または部署に対応するデータのみを参照できるように、行レベルセキュリティ（RLS）を適用する。

→semantic model 内で DAX 式を使用して RLS ルールを実装する。

理由: semantic model は、RLS のようなビジネスルールを適用するための集中管理された推奨レイヤーである。ロジックはユーザーの ID に基づいて動的に適用される。

ユーザーグループがテーブル内の機密性の高い列（例：給与、PII）を参照できないようにする。

→semantic model または warehouse で列レベルセキュリティ（CLS）を実装する。

理由: CLS は、指定されたユーザーロールに対して特定の列へのアクセスを制限する詳細な制御を提供し、共有テーブル内の機密データを保護する。

高いパフォーマンス要件を持つ非常に大規模な lakehouse データセット上で Power BI レポートを構築する。

→DirectLake モードを使用して semantic model を作成する。

理由: DirectLake は、データをメモリにロードすることで Import モードのパフォーマンスを提供するが、OneLake 内の Delta ファイルから直接読み取るため、データを重複させることはない。

高レベルの要約を含むレポートのクエリパフォーマンスを向上させ、容量消費を削減する。

→semantic model 内に集計テーブルを作成し、構成する。

理由: 事前集計されたデータにアクセスするクエリは、完全な詳細テーブルをスキャンするクエリよりも大幅に高速で、消費リソースも少ないため、ユーザーエクスペリエンスとコストを最適化する。

最近のデータのみが変更される大規模な semantic model の更新時間とリソース使用量を削減する。

→semantic model 内の大きなファクトテーブルに増分更新ポリシーを構成する。

理由: これによりデータがパーティション化され、最新のパーティションのみが更新されるため、変更されない履歴データのコストのかかる完全再ロードが回避される。

ストリーミング取り込みによる多数の小さなファイルのために、Delta table のクエリパフォーマンスが低下した。

→Delta table に対して `OPTIMIZE` コマンドを実行する。

理由: `OPTIMIZE` は小さなファイルをより少なく、より大きなファイルに圧縮する。これにより、クエリエンジンが開くファイルの数が減るため、読み取りパフォーマンスが大幅に向上する。

非パーティション化された高カーディナリティ列で頻繁にフィルタリングされる大規模な Delta table のクエリパフォーマンスを向上させる。

→頻繁にフィルタリングされる列に対して `ZORDER BY` 句を付けて `OPTIMIZE` を実行する。

理由: Z-Ordering は、関連データをファイル内に共存させることで、クエリエンジンがデータスキッピングを使用して読み取るデータを減らし、フィルタリングされたクエリを劇的に高速化する。

Fabric lakehouse 内の Delta tables をクエリする Power BI レポートの読み取りパフォーマンスを最適化する。

→Delta tables で V-Order 最適化が有効になっていることを確認する。

理由: V-Order は Fabric 固有の書き込み時最適化であり、圧縮とデータ順序付けを改善することで Power BI engine の読み取りパフォーマンスを向上させる。

更新や削除によって大量の履歴が蓄積された Delta table からストレージスペースを再利用する。

→テーブルに対して `VACUUM` コマンドを実行する。

理由: `VACUUM` は、テーブルによって参照されなくなり、保持期間よりも古いデータファイルを物理的に削除し、ストレージコストを削減する。

非常に大きなファクトテーブルと小さなディメンションテーブル間の Spark join を最適化する。

→ブロードキャストヒント（`broadcast()`）を提供して、小さなテーブルをすべての executor に送信するブロードキャストジョインを使用する。

理由: ブロードキャストは、大規模なテーブルのコストがかかりネットワーク負荷の高いシャッフル操作を回避する。これは大規模ジョインにおける主要なパフォーマンスボトルネックである。

Spark join 操作が、1つのキー値に不均衡に大量のデータがあるため（データスキュー）、遅いまたは失敗する。

→「サルティング」手法を実装する。スキューのある値にランダムキーを追加して、それらをより多くのパーティションに分散させ、その後結合および集計する。

理由: サルティングはスキューのあるパーティションを手動で分割し、ワークロードをすべての executor にバランスさせ、OOM エラーや長時間実行されるタスクを防ぐ。

Spark ノートブックジョブの実行が予想よりも遅く、原因が不明である。

→監視ハブからアクセスできる Spark UI を使用して、Directed Acyclic Graph (DAG)、ステージの期間、タスクの詳細を分析する。

理由: Spark UI はクエリ実行の詳細な物理ビューを提供し、データスキュー、ディスクへのスピル、非効率なシャッフルなどのボトルネックを特定できる。

大きな executor メモリがあっても、Spark ジョブがドライバーノードで OutOfMemoryError で失敗する。

→`.collect()` や `.toPandas()` のような、大量の分散データをドライバーノードのメモリにプルするアクションのコードを確認する。

理由: ドライバーには独自のメモリ制限がある。大規模な DataFrame をドライバーに収集することは、OOM エラーを引き起こす一般的なアンチパターンである。代わりに分散操作を使用する。

Fabric capacity で最も多くのコンピュートリソースを消費しているワークスペース、レポート、またはパイプラインを特定する。

→Fabric Capacity Metrics app をインストールし、分析する。

理由: このアプリは、ワークスペース、アイテムタイプ、特定の操作ごとの Capacity Unit (CU) 消費量の詳細な内訳を時系列で提供し、ターゲットを絞った最適化とコスト分析を可能にする。

Fabric ワークスペース内のすべての活動について、一元化された長期的な監査および監視を実装する。

→Fabric 管理設定で、ワークスペースの診断設定を構成し、ログを Azure Log Analytics ワークスペースにストリーミングする。

理由: すべての監査および運用ログに対して、堅牢でクエリ可能、かつ長期的なストアを提供し、高度な監視、アラート、コンプライアンスレポートを可能にする。

予測可能な非アクティブ期間（例：夜間、週末）がある Fabric capacity の運用コストを削減する。

→オフアワー中に capacity を一時停止し、営業時間前に再開するための自動化（例：API および Azure Automation 経由）を実装する。

理由: Capacity compute は主要なコスト要因である。capacity を一時停止すると CU の課金が停止し、アイドル期間中に大幅なコスト削減をもたらす。

重要なデータパイプラインを監視し、運用チームは失敗時に直ちに通知を受ける必要がある。

→Fabric Monitoring Hub でアラートを構成するか、Data Activator を使用してパイプラインの状態を監視し、通知をトリガーする。

理由: プロアクティブなアラートにより、障害が迅速に検出され対処されるため、データのダウンタイムとビジネスユーザーへの影響が最小限に抑えられる。