Question#4(DP-600)
【ケーススタディ問題(4/5)】
概要 Contoso, Ltd. は、米国を拠点とする健康補助食品会社です。Contoso には、Sales（販売）と Research（研究）という 2 つの部門があります。Sales 部門には、Online Sales（オンライン販売）と Retail Sales（店舗販売）という 2 つの部署があります。Research 部門は、社内で開発された製品ラインを、研究者とアナリストの個別のチームに割り当てています。 既存の環境 アイデンティティ環境 Contoso は contoso.com という名前の Microsoft Entra テナントを所有しています。このテナントには、ResearchReviewersGroup1 と ResearchReviewersGroup2 という 2 つのグループが含まれています。 データ環境 Contoso のデータ環境は以下の通りです。- Sales 部門： Microsoft Power BI Premium 容量（キャパシティ）を使用しています。
- Online Sales 部署： セマンティックモデルに、インポートモードを使用した Orders という名前のファクトテーブルが含まれています。基底システムにおいて、OrderID の値は注文が作成された順序を表しています。
- Research 部門： オンプレミスのサードパーティ製データウェアハウス製品を使用しています。
- Fabric： contoso.com テナントで有効化されています。
- Azure Data Lake Storage Gen2： storage1 という名前のアカウントに、製品ライン Productline1 のデータが格納されています。データ形式は Delta 形式です。
- storage2 という名前のアカウントに、製品ライン Productline2 のデータが格納されています。データ形式は CSV 形式です。
- Sales 部門で使用されている Power BI Premium 容量で Fabric のサポートを有効にする。
- Sales 部門と Research 部門のすべてのデータを Fabric で利用可能にする。
- Research 部門用に、Productline1ws と Productline2ws という 2 つの Fabric ワークスペースを作成する。
- Productline1ws 内に Lakehouse1 という名前のレイクハウスを作成する。
- Lakehouse1 内に、storage1 へのショートカットとして ResearchProduct を作成する。
- Sales 部門と Research 部門のすべてのワークスペースは、すべての Fabric エクスペリエンスをサポートする必要がある。
- Research 部門のワークスペースは、分単位の課金が発生する専用のオンデマンド容量（Capacity）を使用する必要がある。
- Research 部門のワークスペースは、部門名に基づいた OneLake データハブのフィルタリングをサポートするために、論理的にグループ化される必要がある。
- Research 部門のワークスペースにおいて、ResearchReviewersGroup1 のメンバーは、SQL エンドポイントを使用してレイクハウス、ウェアハウス、およびショートカットのデータを読み取れる必要がある。
- Research 部門のワークスペースにおいて、ResearchReviewersGroup2 のメンバーは、レイクハウス・エクスプローラー（Lakehouse explorer）を使用してレイクハウスデータを読み取れる必要がある。
- Research 部門のすべてのセマンティックモデルとレポートは、ブランチ（分岐）をサポートするバージョン管理を使用する必要がある。
- Productline1 のデータは、Fabric ノートブックを使用して Lakehouse1 から取得する必要がある。
- レイクハウス内のすべての Research 部門のデータは、レイクハウス・エクスプローラーでマネージドテーブル（Managed tables）として表示される必要がある。
- 更新（リフレッシュ）中に Orders テーブルに追加される行数を最小限に抑える必要がある。
- Research 部門のワークスペース内のセマンティックモデルは、Direct Lake モードを使用する必要がある。
- 該当する場合は、最小権限の原則に従う。
- 可能な限り、実装とメンテナンスの手間を最小限に抑える。
正解：D
Fabric 公式ドキュメントの増分更新チュートリアルに準拠しており、データフロー（Dataflow Gen2）を使用してレイクハウス内の OrderID の最大値を取得し、それを元に新規行のみを抽出・追加する構成が、Fabric における標準的な実装パターンであるため。
1. 公式チュートリアルに全く同じ手順が存在する
Microsoft の公式ドキュメントには、「Dataflow Gen2 を使用して増分リフレッシュをセットアップする」というチュートリアルがあり、そこではまさに「レイクハウスから現在の最大 OrderID を取得し、それをフィルターとして使用する」というプロセスが、データフロー（Dataflow Gen2）を用いて解説されています。 公式ドキュメントの記述： 「レイクハウス内の最大 OrderID を返すクエリを作成します。このクエリを使用して、ソースからのデータをフィルタリングします。」 2. レイクハウス SQL エンドポイントの制限 選択肢 １ の「ストアドプロシージャ」は、レイクハウスの SQL エンドポイントに対して実行することになります。しかし、Fabric の現在の仕様（および試験作成時点の状況）では、以下の懸念があります。- 呼び出しの制限: レイクハウスの SQL エンドポイントでストアドプロシージャを作成できても、Fabric パイプラインの「Stored Procedure アクティビティ」から直接レイクハウスを対象として呼び出す際に、接続タイプや認証の面でデータフローよりも設定が複雑になる、あるいは一部制限がある場合があります。
- メンテナンスの最小化: 「実装とメンテナンスの手間を最小限に抑える」という全般的な要件において、ローコードツールであるデータフロー（Power Query ベース）で完結させる手法は、SQL コードを記述・管理するよりも Fabric の思想（シチズンデベロッパーへの配慮など）に近いとみなされます。
コメント