WEB問題集
Contoso はワークスペース ws1 で Unity Catalog を有効にしています。ADLS Gen2 の abfss://data@stg1.dfs.core.windows.net/raw には外部システムが出力した CSV と PDF が蓄積されており、外部システムは今後も同じパスへ出力を続けます。
これらの非表形式ファイルを、出力先パスを変更せずに Unity Catalog のガバナンス下に置き、権限管理と監査の対象にする必要があります。カタログとスキーマは次のとおり作成済みです。
CREATE CATALOG IF NOT EXISTS cat1;
CREATE SCHEMA IF NOT EXISTS cat1.raw;次に実行すべきステートメントはどれですか。
解説
【正解: B】の理由
外部ボリュームは、既存のクラウド オブジェクト ストレージの場所に対して Unity Catalog のガバナンスを追加するためのオブジェクトです。LOCATION に既存の abfss:// パスを指定して登録するため、外部システムの出力先を変更せずにそのまま利用できます。登録後はカタログ、スキーマ、ボリュームの 3 階層の名前空間に載り、/Volumes/cat1/raw/vol1 の形式で参照でき、他のセキュラブル オブジェクトと同じ権限モデルと監査の対象になります。ボリュームは表形式でないデータを管理するためのオブジェクトなので、CSV と PDF が混在する本シナリオに適合します。
【他選択肢が違う理由】
- A: マネージド ボリュームはスキーマの Unity Catalog マネージド ストレージ内に作成されるため、既存の abfss:// パスをそのまま登録できません。
- C: DBFS ルートと DBFS マウントは非推奨で推奨されません。新しいアカウントは DBFS ルートへのアクセスなしで作成されます。
- D: レガシー Hive metastore はワークスペース単位で、Unity Catalog の権限管理や監査の対象になりません。
【参考】
Contoso は Azure Databricks のコンピューティングを見直しています。現在のワークロードは次のとおりです。
| ワークロード | 実行方法 | 現在のコンピューティング |
|---|---|---|
| 夜間 ETL（毎日 02:00 にスケジュール実行） | ノートブック タスク | 汎用コンピューティング |
| BI ダッシュボードのクエリ | SQL | SQL ウェアハウス |
| データ探索（日中の対話操作） | ノートブック | 汎用コンピューティング |
次の各ステートメントについて、正しい場合は「はい」、正しくない場合は「いいえ」を選択してください。
| ステートメント | はい | いいえ |
|---|---|---|
|
夜間 ETL のようにスケジュール実行されるワークロードは、汎用コンピューティングよりもジョブ コンピューティングに移すほうがコストを抑えられる。 ジョブ コンピューティングはジョブの実行時に作成されて終了時に破棄されるため、常時起動しがちな汎用コンピューティングよりスケジュール実行に適しています。 |
||
|
サーバーレス コンピューティングを選ぶ場合も、ノード タイプとワーカー数を明示的に指定する必要がある。 サーバーレス コンピューティングは計算資源が Databricks 側で管理されるため、ノード タイプやワーカー数を利用者が指定する必要はありません。 |
||
|
BI ダッシュボードのクエリを実行している SQL ウェアハウスは、ノートブックから Python の DataFrame API を実行する用途にも使える。 SQL ウェアハウスは SQL の実行に特化したコンピューティングです。ノートブックで Python を実行するには、ジョブ コンピューティングや汎用コンピューティングを使います。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| 夜間 ETL のようにスケジュール実行されるワークロードは、汎用コンピューティングよりもジョブ コンピューティングに移すほうがコストを抑えられる。 | はい |
| サーバーレス コンピューティングを選ぶ場合も、ノード タイプとワーカー数を明示的に指定する必要がある。 | いいえ |
| BI ダッシュボードのクエリを実行している SQL ウェアハウスは、ノートブックから Python の DataFrame API を実行する用途にも使える。 | いいえ |
【ポイント】
コンピューティングの種類は、ワークロードの実行形態で選び分けます。ジョブ コンピューティングはジョブの開始時に作成され終了時に破棄されるため、スケジュール実行の ETL に向きます。汎用コンピューティングは対話的な探索に向き、自動終了を設定してアイドル時間の課金を抑えます。SQL ウェアハウスは SQL の実行に特化し、BI ダッシュボードやアドホック クエリを担当します。サーバーレスはノード タイプやワーカー数の指定が不要で、起動待ちを短縮できます。Photon は SQL と DataFrame の処理を高速化するアクセラレーターで、コンピューティングの機能設定として Databricks Runtime のバージョンとあわせて構成します。
【参考】
Contoso はワークスペース ws1 で Azure Databricks を利用しています。現在のワークロードは次のとおりです。
| ワークロード | 利用者 | 実行内容 | 要件 |
|---|---|---|---|
| 売上ダッシュボード | 営業部門 60 名 | BI ツールからの SQL クエリ | 同時実行が多く、待ち時間を短くしたい |
| 日次の集計処理 | データ エンジニア 3 名 | ノートブック タスクの夜間実行 | 実行した時間だけ課金されるようにしたい |
| アドホック分析 | データ サイエンティスト 5 名 | ノートブックの対話実行 | 日中の時間帯だけ使用する |
売上ダッシュボードの要件を、最小の管理作業で満たす必要があります。どのコンピューティングを構成すべきですか。
解説
【正解: A】の理由
SQL ウェアハウスは、SQL クエリと分析、BI のワークロードのために最適化されたコンピューティングです。BI ツールは接続情報を 1 つ指定するだけで接続でき、ノード タイプやワーカー数といったクラスターの構成を運用担当者が個別に管理する必要がありません。ダッシュボードのように短いクエリが同時に多数届く場合でも、ウェアハウスがクエリの待ち行列に応じてスケールするため、待ち時間を抑えられます。SQL だけを実行する用途であれば、汎用コンピューティングを用意するより管理作業もコストも小さく済みます。
【他選択肢が違う理由】
- B: 汎用コンピューティングはノートブックの対話実行を想定したもので、常時起動すると利用のない時間帯まで課金が続き、BI の同時実行にも最適化されていません。
- C: ジョブ コンピューティングはジョブの実行時に作成され、完了すると終了するため、BI ツールが常時接続する先としては使えません。
- D: DBFS マウントは非推奨であり、BI ツールの接続先を用意するという要件の解決にもなりません。
【参考】
Contoso はワークスペース ws1 のコンピューティングの位置付けを整理しています。次の各説明に当てはまるものを選択してください。
| ステートメント | 選択 |
|---|---|
|
コンピューティング リソースを 1 人のユーザーまたは 1 つのグループに割り当て、割り当てられたプリンシパルだけがアタッチして使用する
|
|
|
CAN ATTACH TO 権限を持つ複数のユーザーが 1 つのコンピューティングにアタッチし、コードを分離したまま同時に実行する
|
|
|
SQL クエリと BI のワークロードに最適化されており、サーバーレスまたはクラシックとして構成する
|
解説
【正解マッチング】
| 説明 | 対象 |
|---|---|
| コンピューティング リソースを 1 人のユーザーまたは 1 つのグループに割り当て、割り当てられたプリンシパルだけがアタッチして使用する | 専用アクセス モード |
| CAN ATTACH TO 権限を持つ複数のユーザーが 1 つのコンピューティングにアタッチし、コードを分離したまま同時に実行する | 標準アクセス モード |
| SQL クエリと BI のワークロードに最適化されており、サーバーレスまたはクラシックとして構成する | SQL ウェアハウス |
【ポイント】
アクセス モードは、クラシック コンピューティングに誰がアタッチして使用できるかを決める設定です。専用アクセス モードは 1 人のユーザーまたは 1 つのグループにリソースを割り当て、割り当てられたプリンシパルだけが使用します。標準アクセス モードでサポートされない言語やランタイムが必要なワークロードは、こちらを選びます。標準アクセス モードは、CAN ATTACH TO 権限を持つ複数のユーザーが同じリソースを共有しながら、ユーザーのコードを分離した状態で同時に実行できるため、コストを抑えつつ管理を簡素にできます。SQL ウェアハウスはアクセス モードの設定を持たず、SQL クエリと BI のワークロードのための専用のコンピューティングとして、サーバーレスまたはクラシックの種類を選んで構成します。
【参考】
Contoso のデータ サイエンティストが、ノートブックで次のセルを対話的に実行しようとしています。
df = spark.read.table("cat1.bronze.orders")
df = df.filter(df.amount > 1000)
display(df.groupBy("region").count())このノートブックを SQL ウェアハウス wh1 にアタッチしようとしましたが、実行できません。ノード タイプやワーカー数を構成せずに、できるだけ短い待ち時間でこのセルを実行する必要があります。どうすべきですか。
解説
【正解: C】の理由
ノートブックのサーバーレス コンピューティングは、Python と SQL を対話的に実行するためのマネージド サービスで、クラウド アカウント側にリソースをプロビジョニングせずにワークロードを実行できます。必要な計算資源は Databricks が自動的に割り当てて管理するため、ノード タイプやワーカー数を指定する必要がなく、起動とスケーリングにかかる時間も短縮されます。提示されたセルは DataFrame API を使う Python のコードであり、SQL の実行に特化したコンピューティングでは動作しません。ノートブックのアタッチ先をサーバーレス コンピューティングに切り替えれば、構成作業をせずにそのまま実行できます。
【他選択肢が違う理由】
- A: SQL ウェアハウスは SQL の実行に特化しているため、サイズを大きくしても Python の DataFrame API は実行できません。
- B: DBFS マウントは非推奨で、読み込み方法を変えても SQL ウェアハウスで Python を実行できるようにはなりません。
- D: 汎用コンピューティングでも実行できますが、ノード タイプとワーカー数の構成が必要で起動待ちも長くなるため、要件に合いません。