Databricks認定データエンジニアアソシエイト公式練習問題 翻訳&解説 質問31以降
はじめに
これはDatabricks Certified Data Engineer Associate(Databricks DEA)の公式練習問題(リンク)の質問31からの翻訳&解説になります。
質問30まではデータブリックスの新井さんより記事が公開されております。私も大変お世話になりました。ありがとうございます。
本記事では、執筆時点(2024/10/08)で取り扱われてませんでした質問31以降について、学習とメモを兼ねて執筆します。
追記:無事合格しました。この公式練習問題は合格に大きく貢献した準備でした!
また、同様の記事もありましたのでご参考にリンクさせていただきます。間違えてしまった問題について別の方の解説も読むと学習が深まると思います。
試験の注意として、試験中の用語はまだ古い名称が使われています。気づいた範囲で記載しておきます。
旧名称(試験中記載名) ⇒ 現在の名称
データエクスプローラー ⇒ カタログエクスプローラー
SQLエンドポイント ⇒ SQLウェアハウス
Hive MetastoreのUSAGE権限 ⇒ Unity CatalogのUSE SCHEMA権限 (こちらは単なる名称変更以上のものですがおよそ対応しているのかなと)
同様に、例えば現在は CREATE OR REFRESH LIVE TABLE 構文は非推奨で、代わりに CREATE OR REFRESH MATERIALIZED VIEW を使用するようになっていますが、試験では CREATE OR REFRESH LIVE TABLE で記述されてます。
新しい知識に慣れており、見たことない用語・構文にも戸惑わないように気を付けましょう。
(試験内容が古いのは他のベンダー試験でもよくあることなのでこのあたりは割り切って乗り切りましょう!)
練習問題
質問31
以下の構造化ストリーミングクエリーのうち、どれがBronzeテーブルからSilverテーブルへデータ移動をしていますか?
- A. (spark.table("sales")
.groupBy("store")
.agg(sum("sales"))
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("complete")
.table("aggregatedSales")
) - B. (spark.table("sales")
.agg(sum("sales"),
sum("units"))
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("complete")
.table("aggregatedSales")
) - C. (spark.table("sales")
.withColumn("avgPrice", col("sales") / col("units"))
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("append")
.table("cleanedSales")
) - D. (spark.readStream.load(rawSalesLocation)
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("append")
.table("uncleanedSales")
) - E. (spark.read.load(rawSalesLocation)
.writeStream
.option("checkpointLocation", checkpointPath)
.outputMode("append")
.table("uncleanedSales")
)
答えを見る
正解は「C」です。Cのクエリは、spark.table("sales")を使用して既存のテーブル(Bronzeテーブル)からデータを読み込み、withColumnを使って新しい列を追加し、その後writeStreamを使ってデータをcleanedSalesという新しいテーブル(Silverテーブル)に書き出しています。
- A. このクエリは、データの集計を行っているため基本的にSilverテーブルに適しません。
- B. Aと同様に集計を行っているため適しません。
- D. このクエリは、生データを読み込み、uncleanedSalesとしてテーブルに書き出しているため、BronzeからSilverへの移動ではありません。
- E. Dと同様に生データを読み込み、uncleanedSalesとしてテーブルに書き出しているため適しません。
質問32
Delta Live Tablesは、Databricks上のSparkとDelta Lakeを利用する標準的なデータパイプラインと比較して、ELTパイプラインに提供する利点は以下のどれですか?
- A. データテーブルの依存関係を宣言し、維持する機能
- B. PythonやSQLでパイプラインを書く機能
- C. 以前のバージョンのデータテーブルにアクセスする機能
- D. コンピュートリソースを自動的にスケールする機能
答えを見る
正解は「A」です。パイプラインの管理が簡素化され、データの信頼性が向上します。
- B. DLTの機能ですが、標準的なデータパイプラインでも可能です。
- C. Delta Lake自体の機能であり、DLTに特有の利点ではありません。
- D. Databricksの一般的な機能であり、DLTに特有のものではありません。
- E. DLTの機能ですが、標準的なデータパイプラインでも実現可能です。
質問33
あるデータエンジニアがELTパイプラインに3つのノートブックを持っています。パイプラインが正常に完了するためには、ノートブックを特定の順序で実行する必要があります。データエンジニアは、このプロセスを管理するためにDelta Live Tablesを使用したいと考えています。 データエンジニアは、Delta Live Tablesを使用してこのパイプラインを実装するために、次のどの手順を実行する必要がありますか?
- A. データページから Delta Live Tablesパイプラインを作成する必要があります。
- B. ジョブページから Delta Live Tablesパイプラインを作成する必要があります。
- C. コンピュートページからDelta Live Tablesパイプラインを作成する必要があります。
- D. ノートブックをPythonとdltライブラリを使用するようにリファクタリングする必要があります。
- E. ノートブックをSQLとCREATE LIVE TABLEキーワードを使用するようにリファクタリングする必要があります。
答えを見る
正解は「B」です。
- A. Delta Live Tablesパイプラインはジョブページから作成します。
- C. A同様、Delta Live Tablesパイプラインはジョブページから作成します。
- D. Pythonとdltライブラリの使用は必須ではありません。
- E. SQLとCREATE LIVE TABLEキーワードの使用は必須ではありません。
質問34
あるデータエンジニアが次のようなクエリーを書きました。
SELECT *
FROM json.`/path/to/json/file.json`;
データエンジニアは同僚に、このクエリをDelta Live Tables (DLT)パイプラインで使用するために変換する方法を尋ねました。このクエリはDLTパイプラインで最初のテーブルを作成する必要があります。
次のうち、同僚がクエリに加える必要がある変更はどれですか?
- A. クエリの先頭に COMMENT 行を追加する必要があります。
- B. クエリの先頭に CREATE LIVE TABLE table_name AS 行を追加する必要があります。
- C. FROM行にjson.の前にlive.接頭辞を追加する必要があります。
- D. クエリの先頭に CREATE DELTA LIVE TABLE table_name AS 行を追加する必要があります。
行を追加する必要がある。 - E. JSONファイルのパスにcloud_files(...)ラッパーを追加する必要があります。
答えを見る
正解は「B」です。ただしテスト作成時点と異なり現在は、具体化されたビューを作成するための CREATE OR REFRESH LIVE TABLE 構文は非推奨です。 代わりに CREATE OR REFRESH MATERIALIZED VIEW を使用してください。
Delta Live Tables の具体化されたビューまたはストリーミング テーブルを作成する
- A. コメント行は説明を追加するためのもので、クエリの実行には影響しません。
- C. live.接頭辞は存在しないため、クエリが正しく実行されません。
- D. 正しい構文は CREATE LIVE TABLE であり、DELTA は不要です。
- E. cloud_filesはファイルの読み込み方法を指定するためのもので、DLTのテーブル作成には直接関係ありません。
質問35
Delta Live Tablesを使用して定義されたデータセットがあり、EXPECT句が含まれています:
CONSTRAINT valid_timestamp EXPECT (timestamp > '2020-01-01')
これらの制約に違反するデータを含むバッチが処理された場合、どのような動作が期待されますか?
- A. 制約に違反するレコードはターゲットデータセットに追加され、イベントログに無効として記録されます。
- B. 制約に違反するレコードはターゲットデータセットから削除され、イベントログに無効として記録されます。
- C. 制約に違反するレコードがあるとジョブが失敗します。
- D. 制約に違反するレコードはターゲットデータセットに追加され、ターゲットデータセットに追加されたフィールドで無効としてフラグが立てられます。
- E. 制約に違反するレコードはターゲットデータセットから削除され、隔離テーブルにロードされます。
答えを見る
正解は「A」です。制約に違反するレコードに適用できる3つのアクションのうち、warn (既定値)の動作はAです。
- B. 既定ではないdropアクション時の動作です。
- C. 既定ではないfailアクション時の動作です。
- D. warnアクションでは、制約違反のレコードに特定のフラグを立てる機能はありません。
- E. 既定ではない動作です。識別された無効なレコードを隔離するには、無効なレコードが別のテーブルに格納 (「隔離」) されるように、特定の方法で期待値ルールを定義できます。無効なデータの検疫を参照してください。
質問36
Delta Live Tableパイプラインには、STREAMING LIVE TABLEを使用して定義された2つのデータセットが含まれています。3つのデータセットは、LIVE TABLEを使用してDelta Lakeテーブルソースに対して定義されています。このテーブルは、トリガーパイプラインモードを使用して開発モードで実行するように構成されています。未処理のデータが存在し、すべての定義が有効であると仮定すると、パイプラインを更新するために「開始」をクリックした後の予想される結果は何ですか?
- A. すべてのデータセットが一度更新され、パイプラインは停止します。コンピューティングリソースは終了します。
- B. パイプラインが停止されるまで、すべてのデータセットが一定間隔で更新されます。
- C. すべてのデータセットが一定間隔で更新され、パイプラインが停止するまで続きます。コンピューティングリソースはパイプラインが停止した後も追加のテストのために持続します。
- D. すべてのデータセットが一度更新され、パイプラインは停止します。コンピューティングリソースは追加のテストのために持続します。
- E. すべてのデータセットが継続的に更新され、パイプラインは停止しません。コンピューティングリソースはパイプラインと共に持続します。
答えを見る
正解は「D」です。トリガーパイプラインモードと開発モードであることから判断できます。
- A. 開発モードでは、更新が成功または失敗した後、コンピュートリソースはすぐには終了しません。
- B. トリガーパイプラインモードでは一度の実行で停止します。
- C. B同様、トリガーパイプラインモードでは一度の実行で停止します。
- E. B同様、トリガーパイプラインモードでは一度の実行で停止します。
質問37
あるデータエンジニアが毎晩実行される複数のタスクを持つジョブを持っています。タスクの1つが予期せず10%の実行で失敗します。 ジョブが毎晩完了することを保証しながら、計算コストを最小限に抑えるためにデータエンジニアが実行できるアクションはどれですか?
- A. ジョブ全体の再試行ポリシーを設定する
- B. タスクの実行状況を観察し、失敗の原因を特定する
- C. ジョブを複数回実行するように設定し、少なくとも1回は完了するようにする
- D. 定期的に失敗するタスクに再試行ポリシーを設定する
- E. ジョブ内の各タスクにジョブクラスターを利用する
答えを見る
正解は「D」です。失敗する可能性のある特定のタスクに対してのみ再試行が行われ、計算コストを最小限に抑えつつ、ジョブ全体の完了を保証できます。
- A. ジョブ全体を再試行するのはコストが高く、効率的ではありません。
- B. 今回の場合、自動的に再試行できるDの方が適切です。
- C. A同様に、ジョブ全体を再試行するのはコストが高く、効率的ではありません。
- E. ジョブクラスターを各タスクに利用することは、特定のタスクが失敗する問題に対する直接的な解決策ではありません。
質問38
データエンジニアが毎晩実行される2つのジョブを設定しました。最初のジョブは午前0時に開始し、通常は約20分で完了します。2番目のジョブは最初のジョブに依存しており、午前0時30分に開始します。時々、最初のジョブが午前0時30分までに完了しないと、2番目のジョブが失敗します。 この問題を回避するために、データエンジニアが使用できるアプローチは次のうちどれですか?
- A. 直線的な依存関係を持つ1つのジョブで、複数のタスクを利用する
- B. クラスタプールを使用してジョブの効率的な実行を支援する
- C. 最初のジョブに再試行ポリシーを設定し、ジョブの実行速度を向上させる
- D. 二番目のジョブの出力サイズを制限して、失敗しにくくする
- E. 最初のジョブから2番目のジョブにデータをストリームするように設定する
答えを見る
正解は「A」です。直線的な依存関係を持つことで前段のタスクが完了してから次のタスクが実行されます。
- B. クラスタプールはジョブの実行速度を向上させるかもしれませんが、依存関係の問題を直接解決するわけではありません。
- C. 再試行ポリシーはジョブの失敗時に役立ちますが、ジョブが時間内に完了しない問題を根本的に解決するわけではありません。
- D. これは2番目のジョブの失敗を減らすかもしれませんが、最初のジョブの完了時間に依存する問題を解決しません。
- E. データのストリーミングはリアルタイム処理に役立ちますが、ジョブの依存関係の問題を解決するわけではありません。
質問39
データエンジニアがノートブックをジョブとして自動処理するように設定しました。データエンジニアのマネージャーは、その複雑さのためにスケジュールをバージョン管理したいと考えています。ジョブのスケジュールのバージョン管理可能な構成を取得するために、データエンジニアが使用できるアプローチは次のうちどれですか?
- A. Databricks Repoの一部であるノートブックにジョブをリンクする
- B. Jobクラスターでジョブを一度送信する
- C. ジョブのページからジョブのJSONをダウンロードする
- D. all-purposeクラスタ上でジョブを一度送信する
- E. ジョブのページからジョブのXMLをダウンロードする
答えを見る
正解は「C」です。ジョブのJSONをダウンロードすることで、ジョブの設定やスケジュールを含む構成をバージョン管理システムなどに保存し、変更履歴を追跡することができます。これにより、ジョブの設定が変更された場合でも、以前のバージョンに戻すことが容易になります。
- A. ジョブのスケジュール自体のバージョン管理には直接関係しません。
- B. A同様、ジョブのスケジュール自体のバージョン管理には直接関係しません。
- D. A同様、ジョブのスケジュール自体のバージョン管理には直接関係しません。
- E. Databricksではジョブの設定をJSON形式で提供しており、XML形式でのダウンロードはサポートされていません。
質問40
データアナリストが、Databricks SQLクエリの実行が非常に遅いことに気付きました。この問題は、順次実行されるすべてのクエリに影響を与えていると主張しています。データエンジニアリングチームに助けを求めたところ、各クエリが同じSQLエンドポイントを使用していることが判明しましたが、そのSQLエンドポイントは他のユーザーによって使用されていません。 データエンジニアリングチームは、データアナリストのクエリのレイテンシを改善するために、次のどのアプローチを使用できますか?
- A. SQLエンドポイントのサーバーレス機能をオンにする
- B. SQLエンドポイントのスケーリング範囲の最大値を増やす
- C. SQL エンドポイントのクラスタサイズを大きくする
- D. SQLエンドポイントの自動停止機能をオンにする
- E. SQLエンドポイントのサーバーレス機能をオンにし、スポットインスタンスポリシーを「信頼性最適化」に変更する。
答えを見る
正解は「C」です。クラスタサイズを大きくすることで、より多くのコンピューティングリソース(CPUやメモリ)が利用可能になります。これによりクエリの実行速度が向上し、全体的なパフォーマンスが改善されます。
- A. サーバーレス機能をオンにすることは、自動スケーリングによってリソースを動的に割り当てる助けになりますが、クラスタサイズの調整の方が直接的な効果があり回答としてはより適しているのかなと思います。
- B. スケーリング範囲を増やしても、スケールアップが遅れることがあります。クラスタサイズを直接増やすことで、即時にリソースが確保されます。Cのほうがより直接的な効果があり回答に適しています。
- D. 自動停止機能は、使用されていない場合にリソースを節約するための機能であり、クエリのパフォーマンスには直接影響しません。
- E. サーバーレス機能をオンについてはA同様で、スポットインスタンスポリシーを「信頼性最適化」に変更してもリソースが迅速に利用可能になるものですので、実行が遅いという課題解消にはつながりません。
質問41
エンジニアリングマネージャーが、Databricks SQLクエリを使用して、顧客から報告されたバグに関連する修正に関するチームの進捗を監視しています。マネージャーは毎日クエリの結果を確認していますが、毎日手動でクエリを再実行し、結果を待っています。クエリの結果が毎日更新されるようにするために、マネージャーが使用できるアプローチは次のうちどれですか?
- A. Jobs UIからクエリを毎日1回実行するようにスケジュールする。
- B. Databricks SQLのクエリのページからクエリを毎日1回更新するようにスケジュールする。
- C. Jobs UIからクエリを毎日12時間ごとに実行するようにスケジュールする。
- D. Databricks SQLのSQLエンドポイントのページからクエリを毎日1回更新するようにスケジュールする。
- E. Databricks SQLのSQLエンドポイントのページからクエリを毎日12時間ごとに更新するようにスケジュールする。
答えを見る
正解は「B」です。
- A. クエリを実行するスケジュールは可能ですが今回わざわざジョブ使う必要はありません。Databricks SQLのクエリページから直接行うBのほうが回答に適しています。
- C. A同様ジョブは不要です。また、頻度が必要以上に高いです。1日1回の更新で十分です。
- D. エンドポイントのページではスケジュールできません。
- E. D同様、エンドポイントのページではスケジュールできません。
質問42
データエンジニアリングチームが、ELTジョブのパフォーマンスを監視するためにDatabricks SQLクエリを使用しています。ELTジョブは、処理する準備ができた特定の数の入力レコードによってトリガーされます。Databricks SQLクエリは、ジョブの最新の実行時からの経過時間(分)を返します。 ELTジョブが1時間以内に実行されていない場合に通知を受け取るために、データエンジニアリングチームが使用できるアプローチは次のうちどれですか?
- A. 返された値が60より大きい場合に通知するアラートを付随するダッシュボードに設定
- B. ELTジョブが失敗したときに通知するアラートをクエリに設定
- C. ダッシュボードが60分間更新されていない場合に通知するアラートを付随するダッシュボードに設定
- D. 返された値が60より大きい場合に通知するアラートをクエリに設定
- E. Databricksではこのタイプのアラート設定は不可能
答えを見る
正解は「D」です。
- A. ダッシュボードはジョブの通知と関係ありません。
- B. ジョブの失敗ではなく、実行の有無を監視するのが目的ですので不適切です。
- C. A同様、ダッシュボードはジョブの通知と関係ありません。
- E. 可能です。
質問43
データエンジニアリングマネージャーが、Databricks SQLダッシュボードの各クエリが「更新」ボタンを手動でクリックすると、更新に数分かかることに気付きました。これがなぜ発生するのか興味があるため、チームメンバーがいくつかの理由を提供しています。 以下の理由のうち、ダッシュボードの更新に数分かかることを説明できないものはどれですか?
- A. 各クエリが使用しているSQLエンドポイントの起動に数分かかる可能性があります。
- B. 通常の状況下で、ダッシュボードに接続されているクエリの実行に数分かかる可能性があります。
- C. ダッシュボードに接続されているクエリは、まず新しいデータが利用可能かどうかを確認している可能性があります。
- D. ダッシュボードを更新するジョブが、プールされていないエンドポイントを使用している可能性があります。
- E. ダッシュボードに接続されているクエリが、それぞれ独自の起動されていないDatabricksクラスタに接続されている可能性があります。
答えを見る
正解は「D」です。更新ボタンを手動でクリックし更新をしていることからジョブは無関係です。
- A. SQLエンドポイントの起動に時間がかかることは、クエリの遅延を説明するのに適しています。
- B. クエリが複雑であれば、通常の状況でも実行に時間がかかることがあり得ます。
- C. クエリが新しいデータをチェックするプロセスに時間がかかることは、遅延の一因となります。
- E. クエリが未起動のDatabricksクラスタに接続されている場合、クラスタの起動に時間がかかる可能性があります。
質問44
新しいデータエンジニアが会社に入社しました。このデータエンジニアは、メールアドレス new.engineer@company.com で会社のDatabricksワークスペースに追加されました。データエンジニアは、データベース retail 内のテーブル sales をクエリできる必要があります。新しいデータエンジニアは既にデータベース retail に対するUSAGE権限を付与されています。 新しいデータエンジニアに適切な権限を付与するために使用するコマンドは次のうちどれですか?
- A. GRANT USAGE ON TABLE sales TO new.engineer@company.com;
- B. GRANT CREATE ON TABLE sales TO new.engineer@company.com;
- C. GRANT SELECT ON TABLE sales TO new.engineer@company.com;
- D. GRANT USAGE ON TABLE new.engineer@company.com TO sales;
- E. GRANT SELECT ON TABLE new.engineer@company.com TO sales;
答えを見る
正解は「C」です。個人的に混乱ポイントでしたのは、Snowflakeとは異なり、テーブルのUSAGE権限は存在せず、SELECT権限だけでテーブルにクエリが実行できることです。
また、これはHive MetastoreではUSAGE権限ですが、Unity CatalogではUSE SCHEMA権限に該当します。オブジェクトに対し付与できる権限の確認はこちらのページの方がわかりやすいです。- A. テーブルのUSAGE権限は存在しません。
- B. CREATE権限はテーブルの作成に関連するもので、salesテーブルをクエリできるようになるものではありません。
- D. そもそも構文が正しくありません。権限の対象と付与先が逆になっています。
- E. そもそも構文が正しくありません。権限の対象と付与先が逆になっています。
質問45
新しいデータエンジニア new.engineer@company.com がELTプロジェクトに割り当てられました。このデータエンジニアは、プロジェクトを完全に管理するためにテーブル sales に対する完全な権限が必要です。 新しいデータエンジニアにテーブルに対する完全な権限を付与するために使用できるコマンドは次のうちどれですか?
- A. GRANT ALL PRIVILEGES ON TABLE sales TO new.engineer@company.com;
- B. GRANT USAGE ON TABLE sales TO new.engineer@company.com;
- C. GRANT ALL PRIVILEGES ON TABLE new.engineer@company.com TO sales;
- D. GRANT SELECT ON TABLE sales TO new.engineer@company.com;
- E. GRANT SELECT CREATE MODIFY ON TABLE sales TO new.engineer@company.com;
答えを見る
正解は「A」です。
- B. USAGE 権限はデータベースやスキーマに対するものであり、テーブルに対する完全な管理権限を付与するものではありません。
- C. 構文が正しくありません。権限の対象と付与先が逆になっています。
- D. SELECT 権限のみを付与するものであり、完全な管理権限には不十分です。
- E. 完全な権限を付与するものではありません。ALL PRIVILEGES を使用する方が適切です。
Discussion