Q1.Azure データ要素があり、次のブランチを含む Git リポジトリに接続されています。
◆mam：コラボブランチ
◆abc: 機能ブランチ
◆xyz: 機能ブランチ
xyz ブランチのパイプラインへの料金を保存します。
変更をライブサービスに公開する必要があります
まず何をすべきでしょうか?
A. データ ファクトリを公開する
B. プル リクエストを作成して変更を main ブランチにマージする
C. コードをリモート オリジンにプッシュする
D. プル リクエストを作成して変更を abc ブランチにマージする
回答
- B. プル リクエストを作成して変更を main ブランチにマージする
-
Azure Data Factory の Git 連携では、ライブ環境へ公開する前にコラボレーション ブランチへ変更を統合する必要がある。
機能ブランチ xyz の変更は直接公開できず、まず main ブランチへプル リクエストでマージ することでチーム共有状態となる。
その後に Publish 操作を実行するとライブ環境へ反映される。
したがって最初に行うべき操作は main へのマージであり、ブランチ戦略と公開フローの理解が重要である。
Azure Data Factory でのソース管理
Q2.ADF1という名前のAzureData Factoryインスタンスと、WS1およびWS2という名前の2つのAzure SynapseAnalyticsワークスペースがあります。
ADF1には、次のパイプラインが含まれています。
P1：コピーアクティビティを使用して、WS1の専用SQLプール内のパーティション化されていないテーブルからAzure Data Lake Storage Gen2アカウントにデータをコピーします。P2：コピーアクティビティを使用して、Azure Data Lake StorageGen2アカウント内のテキスト区切りファイルからデータをコピーします。 WS2の専用SQLプール内のパーティション化されていないテーブルへ並列処理とパフォーマンスを最大化するには、P1とP2を構成する必要があります。
各パイプラインの場合、コピーアクティビティに対してどのデータセット設定を構成する必要がありますか？
回答
- (下記画像参照)
-
WS1 からのコピーでは PolyBase を使用することで大規模データの並列ロードが可能 となり、最も高いパフォーマンスを実現できます。
一方で、P2 はテキスト形式のファイルを扱うため PolyBase は利用できず Bulk insert を使用する必要があります。
この違いを理解することが重要であり、データ形式とロード方式の適合性が試験の重要ポイントです。
適切なコピー方式を選択することで Synapse の性能を最大化できます。
Azure Synapse Analytics とは
Q3.Azure IoT ハブからのデータを処理し、複雑な変換を実行する C# アプリケーションがあります。
アプリケーションをリアルタイム ソリューションに置き換える必要があります。ソリューションでは、既存のアプリケーションからできるだけ多くのコードを再利用する必要があります。
既存のコードをできるだけ再利用するには、どのサービスを選択する必要がありますか。
A. Azure Databricks
B. Azure Event Grid
C. Azure Stream Analytics
D. Azure Data Factory
回答
- C. Azure Stream Analytics
-
リアルタイム処理と既存 C# コードの再利用が要件であるため、Azure Stream Analytics が最適です。
特に IoT Edge 上で実行する場合、C# のユーザー定義関数（UDF）を利用して既存ロジックを再利用できる点が重要です。
Databricks は主にバッチ・Spark 処理、Event Grid はイベント通知、Data Factory はバッチ統合向けであり要件に適合しません。
したがって、リアルタイム分析と C# 再利用の両立が可能な Stream Analytics が正解です。
IoT Edge での Azure Stream Analytics
Q4.フォルダーを含む Azure Blob ストレージ アカウントがあります。フォルダーには 120,000 個のファイルが含まれています。各ファイルには 62 列が含まれます。
毎日、1,500 個の新しいファイルがフォルダーに追加されます。
新しいファイルごとに 5 つのデータ列を Azure Synapse Analytics ワークスペースに段階的に読み込むことを計画しています。
増分ロードの実行にかかる時間を最小限に抑える必要があります。
ファイルとフォーマットを保存するために何を使用する必要がありますか?
回答
- (下記画像参照)
-
大量ファイルを効率的に処理するには、フォルダーでの時間ベースのパーティション分割（Timeslice partitioning）が重要です。
これにより新規データのみを対象に読み込みでき、スキャン量を削減できます。
また形式は列指向で圧縮効率の高い Apache Parquetを使用することで、I/O とクエリ性能が向上します。
CSV や JSON は行指向のため非効率です。
したがって、時間パーティション＋Parquet形式の組み合わせが最適解となります。
外部テーブルの作成と使用
Q5.Azure Synapse Analytics サーバーレス SQL プールにデータベースを構築しています。
Azure Data Lake Storage Gen2 コンテナー内の Parquet ファイルにデータが格納されています。
レコードは、次のサンプルに示すように構造化されています。
{
“id”: 123,
“address_housenumber”: “19c”,
“address_line”: “Memory Lane”,
“applicant1_name”: “Jane”,
“applicant2_name”: “Dev”
}
レコードには最大 2 人の応募者が含まれます。
住所フィールドのみを含むテーブルを作成する必要があります。
Transact-SQL ステートメントをどのように完成させる必要がありますか?
回答
- (下記画像参照)
-
Azure Synapse Analytics のサーバーレス SQL プールでは、Azure Data Lake Storage Gen2 上の Parquet ファイルを直接参照する場合、OPENROWSET を使用して外部データを読み込みます。
設問の SQL では、Parquet ファイルから id、address_housenumber、address_line を取得しているため、まず OPENROWSET でデータソースを参照する必要があります。
また、サーバーレス SQL プールでは、Parquet ファイルに対して通常の CREATE TABLE を使って物理テーブルを作成するのではなく、参照用として CREATE VIEW を利用する構成が一般的です。ビューを利用することで、データを移動せずに必要な列のみを抽出できます。
外部テーブルの作成と使用
Q6.Parquet形式のバッチデータセットを実装しています。
データファイルはAzure Data Factoryを使用して生成され、Azure Data Lake Storage Gen2に保存されます。これらのファイルは、Azure Synapse AnalyticsのサーバーレスSQLプールによって利用されます。
このソリューションのストレージコストを最小限に抑える必要があります。
どのような対策を講じるべきでしょうか？
A. すべてのデータを文字列として Parquet ファイルに保存する
B. OPENROWSET を使用して Parquet ファイルをクエリする
C. Parquet ファイルの列のサブセットを含む外部テーブルを作成する
D. ファイルに Snappy 圧縮を使用する
回答
- C. Parquet ファイルの列のサブセットを含む外部テーブルを作成する
-
Parquet は列指向形式のため、必要な列だけを参照できる構成がコスト最適化に有効です。
外部テーブルで必要列のみに絞ることで、不要な列の読み取りや処理を減らし、サーバーレス SQL プールのスキャン量を抑制できます。
OPENROWSET は参照方法であり、保存コストそのものの最小化策ではありません。
試験では列指向形式の特性を活かした設計が重要です。
Synapse SQL で外部テーブルを使用する – Azure
Q7.Azure Synapse Analytics サーバーレス SQL プールを含む Azure サブスクリプションがあります。プールで次のクエリを実行します。
SELECT * FROM OPENROWSET(BULK ‘https://mydatalake.blob.core.windows.net/data/**’, FORMAT = ‘CSV’) AS datarows;
次の記述について、正しい場合は「はい」、そうでない場合は「いいえ」を選択してください。
回答
- (下記画像参照)
-
このクエリの datarows はテーブル名ではなく OPENROWSET の結果セットに付ける別名 なので、テーブルは作成されません。
また、BULK パスの末尾にある /** はフォルダーを再帰的に走査してサブフォルダー内のファイルを対象 とします。
そのため、data 直下の file1 は対象外で、data/folder1/file1.csv は読み取られます。
試験では ワイルドカード指定と別名の意味 を区別して理解することが重要です。
サーバーレス SQL プールを使用して、フォルダーと複数のファイルに対してクエリを実行する – Azure Synapse Analytics | Microsoft Learn
Q8.Azure Synapse Analytics 専用 SQL プール内のファクト テーブルのパーティション戦略を設計しています。テーブルには以下の仕様があります。
◆20,000 製品の販売データが含まれています。
ProductID という名前の列にハッシュ分散を使用します。
◆2019 年と 2020 年のレコードが 24 億件含まれています。
クラスター化カラムストア インデックスに対して、最適な圧縮とパフォーマンスを実現するパーティション範囲の数はいくつでしょうか？
A. 40
B. 240
C. 400
D. 2,400
回答
- A. 40
-
専用 SQL プールでは 内部的に60分散（Distribution）に分割されるため、列ストアの最適圧縮には各パーティションあたり約100万行が推奨されます。
総レコード数24億件より、24億 ÷（100万 × 60）＝40 となります。
パーティションが多すぎると1パーティションあたりの行数が減少し、列ストア圧縮効率とクエリ性能が低下します。
したがって、適切な粒度で分割する設計が重要であり、最適なパーティション数は40です。
専用 SQL プールのベスト プラクティス – Azure Synapse Analytics
Q9.料金所を通過する車両からのストリーミングデータを処理しています。
Azure Stream Analytics を使用して、10 分間隔で最後に通過した車両のナンバープレート、車種、および時刻を取得する必要があります。
クエリをどのように作成すればよいでしょうか？
回答
- (下記画像参照)
-
Azure Stream Analytics で「10 分ごとの最後のイベント」を取得する場合は、まず 10 分単位でイベントを区切る必要があります。この用途には、重複しない固定時間枠を作成する TumblingWindow を使用します。
次に、各ウィンドウ内で最も新しい時刻を取得するため、MAX(Time) を使用して最新イベント時刻を求めます。
さらに、元データと最新時刻を結合する際には、イベント時刻の差分判定が必要になるため、DATEDIFF を使用します。設問の条件では、
DATEDIFF(minute, Input, LastInWindow) BETWEEN 0 AND 10
のように時間差を判定して、対象ウィンドウ内のイベントを関連付けます。
Azure Stream Analytics のウィンドウ関数
Q10.Azureサブスクリプションがあります。
Azure Data Lake Storage Gen2Premiumアカウントをデプロイする必要があります。ソリューションは、次の要件を満たしている必要があります。
◆365日より古いブロブは削除する必要があります。
◆管理者の労力を最小限に抑える必要があります。
◆コストを最小限に抑える必要があります
何を使うべきですか？
回答
- (下記画像参照)
-
コスト最小化には冗長性を抑える必要があり、Locally-redundant storage（LRS）を選択することで最も低コストとなります。
また、365日経過後の自動削除には Azure Storage ライフサイクル管理を使用してポリシーで自動削除するのが最適です。
Automation Runbook は運用負荷が高く、Soft delete は削除防止機能のため要件に不適合です。
したがって、LRS＋ライフサイクル管理の組み合わせが最適解です。
Azure Blob Storage のライフサイクル管理の概要
