DISPLAY SETTINGS 各種設定
Q1.ある分析チームが Azure Data Factory を運用しており、次の3つのブランチを持つ Git リポジトリに接続しています。
mam：コラボレーション用ブランチ
abc：機能開発用ブランチ
xyz：機能開発用ブランチ
担当者が xyz ブランチでパイプラインの変更を保存しました。
この変更をライブ サービスへ公開する必要があります。
最初に何をすべきでしょうか。
解答を見る
Azure Data Factory の Git 連携では、ライブ環境へ発行する前に、変更をコラボレーション ブランチへ統合しておく必要があります。
機能ブランチ xyz の変更をそのまま公開することはできず、まず main ブランチへプル リクエストでマージしてチームの共有状態にします。
その後に発行（Publish）操作を行うと、ライブ環境へ反映されます。
したがって最初に行うべき操作は main へのマージであり、ブランチ戦略と公開フローを正しく理解することが重要です。
Azure Data Factory でのソース管理
Q2.ADF1 という名前の Azure Data Factory インスタンスと、WS1 および WS2 という2つの Azure Synapse Analytics ワークスペースがあります。
ADF1 には次のパイプラインが含まれています。
P1：コピー アクティビティを使い、WS1 の専用 SQL プール内のパーティション化されていないテーブルから Azure Data Lake Storage Gen2 アカウントへデータをコピーします。
P2：コピー アクティビティを使い、Azure Data Lake Storage Gen2 アカウント内のテキスト区切りファイルから WS2 の専用 SQL プール内のパーティション化されていないテーブルへデータをコピーします。
並列処理とパフォーマンスを最大化するために、P1 と P2 を構成する必要があります。
各パイプラインのコピー アクティビティに対して、どのデータセット設定を構成すべきでしょうか。
解答を見る
P1 は WS1 の専用 SQL プールから Azure Data Lake Storage Gen2 へデータを移動します。
この構成では PolyBase を使用することで大規模データを並列にロードでき、最も高い性能が得られます。
一方 P2 はテキスト区切りファイルを扱うため PolyBase は利用できず、Bulk insert を選択する必要があります。
データ形式とロード方式の適合性を理解し、コピー方法を正しく使い分けることが Synapse の性能最大化につながります。
Azure Synapse Analytics とは
Q3.Azure IoT ハブから届くデータを処理し、複雑な変換を行う C# アプリケーションを運用しています。
このアプリケーションをリアルタイム ソリューションへ置き換える必要があり、既存アプリケーションのコードをできるだけ多く再利用することが求められます。
既存コードの再利用を最大化するには、どのサービスを選択すべきでしょうか。
解答を見る
リアルタイム処理と既存 C# コードの再利用が要件であるため、Azure Stream Analytics が最適です。
特に IoT Edge 上で実行する場合、C# のユーザー定義関数（UDF）を通じて既存ロジックをそのまま再利用できます。
Databricks は Spark によるバッチ処理、Event Grid はイベント通知、Data Factory はバッチ統合が主目的であり、いずれも要件に合いません。
したがってリアルタイム分析と C# 再利用を両立できる Stream Analyticsが正解です。
IoT Edge での Azure Stream Analytics
Q4.1つのフォルダーを含む Azure Blob ストレージ アカウントがあります。
このフォルダーには 120,000 個のファイルが格納され、各ファイルには 62 列が含まれます。
毎日 1,500 個の新しいファイルがフォルダーへ追加されます。
新しいファイルごとに 5 つのデータ列を Azure Synapse Analytics ワークスペースへ段階的に読み込む予定です。
増分ロードの実行時間を最小限に抑える必要があります。
ファイルと形式の保存には何を使用すべきでしょうか。
解答を見る
毎日追加される大量ファイルを効率よく取り込むには、フォルダーを時間（タイムスライス）でパーティション分割することが重要です。
これにより新規データのみを対象に読み込め、スキャン範囲を最小化できます。
ファイル形式は列指向で圧縮効率の高い 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 をどのように完成させますか。
【①】 applications WITH ( LOCATION = ‘applications/’, DATA_SOURCE = applications_ds, FILE_FORMAT = applications_file_format ) AS SELECT id, [address_housenumber] AS addresshousenumber, [address_line] AS addressline1 FROM 【②】 (BULK ‘https://contoso1.dfs.core.windows.net/applications/year=*/*.parquet’, FORMAT=’PARQUET’) AS [r] GO
解答を見る
サーバーレス SQL プールで Data Lake Storage Gen2 上の Parquet を直接参照する場合、OPENROWSET を使って外部データを読み込みます。
設問の SQL は Parquet から id や住所列のみを取得しているため、②には OPENROWSET が入ります。
また物理テーブルを作る CREATE TABLE ではなく、データを移動せず必要な列だけを公開できる CREATE VIEW を使うのが一般的な構成です。
したがって①は CREATE VIEW、②は OPENROWSET が正解です。
外部テーブルの作成と使用
Q6.Parquet 形式のバッチ データセットを実装しています。
データ ファイルは Azure Data Factory で生成され、Azure Data Lake Storage Gen2 に保存されます。
これらのファイルは Azure Synapse Analytics のサーバーレス SQL プールから利用されます。
このソリューションのストレージ コストを最小限に抑える必要があります。
どのような対策を講じるべきでしょうか。
解答を見る
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 という名前のテーブルが作成される | |||
| https://mydatalake.blob.core.windows.net/data/file1 ファイルが読み取られる | |||
| https://mydatalake.blob.core.windows.net/data/folder1/file1.csv ファイルが読み取られる |
解答を見る
datarows はテーブル名ではなく OPENROWSET の結果セットに付けた別名であり、テーブルは作成されません。
そのため1つ目の記述は誤りです。
BULK パス末尾の /** はフォルダーを再帰的に走査し、サブフォルダー内のファイルを対象にします。
data 直下の file1 は読み取られず、data/folder1/file1.csv は読み取られます。
ワイルドカード指定と別名の意味を区別して理解することが重要です。
サーバーレス SQL プールを使用して、フォルダーと複数のファイルに対してクエリを実行する
Q8.Azure Synapse Analytics の専用 SQL プールにあるファクト テーブルのパーティション戦略を設計しています。
テーブルには次の仕様があります。
20,000 製品分の販売データを保持します。
ProductID という列でハッシュ分散を使用します。
2019 年と 2020 年のレコードが合計 24 億件含まれます。
クラスター化列ストア インデックスに対して、最適な圧縮とパフォーマンスを実現するパーティション範囲の数はいくつでしょうか。
解答を見る
専用 SQL プールでは内部的に60個のディストリビューションへ分割されるため、列ストアの最適な圧縮には各パーティションあたり約100万行が目安になります。
総行数24億件から、24億 ÷（100万 × 60）＝40 が求められます。
パーティションを増やしすぎると1区画あたりの行数が減り、列ストアの圧縮効率とクエリ性能が低下します。
適切な粒度で分割する設計が重要で、最適な範囲数は40です。
専用 SQL プールのベスト プラクティス – Azure Synapse Analytics
Q9.料金所を通過する車両からのストリーミング データを処理しています。
Azure Stream Analytics を使用して、10 分間隔ごとに最後に通過した車両のナンバープレート、車種、通過時刻を取得する必要があります。
次のクエリをどのように完成させればよいでしょうか。
WITH LastInWindow AS ( SELECT 【①】(Time) AS LastEventTime FROM Input TIMESTAMP BY Time GROUP BY 【②】(minute, 10) ) SELECT Input.License_plate, Input.Make, Input.Time FROM Input TIMESTAMP BY Time INNER JOIN LastInWindow ON 【③】(minute, Input, LastInWindow) BETWEEN 0 AND 10 AND Input.Time = LastInWindow.LastEventTime
解答を見る
10分ごとの最後のイベントを求めるには、まず10分単位でイベントを区切る必要があります。
重複しない固定長の時間枠を作るTumblingWindow を使用します（②）。
次に各ウィンドウ内の最新時刻を得るため、①ではMAX(Time) を使用します。
さらに元データと最新時刻を結合する際、時刻の差を判定するため③では DATEDIFF を用い、DATEDIFF(minute, Input, LastInWindow) BETWEEN 0 AND 10 のように対象イベントを関連付けます。
Azure Stream Analytics のウィンドウ関数
Q10.1つの Azure サブスクリプションがあります。
Azure Data Lake Storage Gen2 Premium アカウントをデプロイする必要があります。
ソリューションは次の要件を満たす必要があります。
365 日より古い BLOB は削除する必要があります。
管理者の作業負荷を最小限に抑える必要があります。
コストを最小限に抑える必要があります。
何を使用すべきでしょうか。
解答を見る
コストを最小化するには冗長性を抑える必要があり、ローカル冗長ストレージ（LRS）を選ぶと最も低コストになります。
365日を過ぎた BLOB の自動削除には、Azure Storage のライフサイクル管理ポリシーで自動削除する方法が最適です。
Automation Runbook は運用負荷が高く、Soft delete は削除を取り消すための機能で要件に合いません。
したがって LRS とライフサイクル管理の組み合わせが最適解です。
Azure Blob Storage のライフサイクル管理の概要