Google Cloud認定資格Professional Data Engineer100題 問題集全問解答＋全問解説付き
Google Cloud認定資格Professional Data Engineerの過去問100題を全問解答＋全問解説付き
Google Cloud Professional Data Engineerの最新の問題になります。
筆者が実際に受験して、問題を収集し解答とその解説を全問付けております。
問題数は合計100題。
実際に受験し、重複問題や類似問題を削除しています。
この100問の問題の解答を理解できれば、ほぼ間違いなく、合格すると思います。
ここから問題と解答/解説になります。
100題、全問解答＋全問解説付きになります。
1.
あなたは広告会社で働いており、広告ブロックでのクリック率を予測する Spark ML モデルを開発しました。オンプレミスのデータセンターですべてを開発してきましたが、現在、会社は Google Cloud に移行しています。データセンターが間もなく閉鎖されるため、迅速なリフト＆シフト移行が必要です。ただし、これまで使用していたデータは BigQuery に移行されます。Spark ML モデルを定期的に再トレーニングするため、既存のトレーニング パイプラインを Google Cloud に移行する必要があります。あなたは何をするべきか？
A. Cloud ML Engine を使用して既存の Spark ML モデルをトレーニングする
B. TensorFlow でモデルを書き換え、Cloud ML Engine を使い始める
C. 既存の Spark ML モデルのトレーニングには Cloud Dataproc を使用しますが、BigQuery から直接データの読み取りを開始します
D. Compute Engine で Spark クラスタを起動し、BigQuery からエクスポートされたデータで Spark ML モデルをトレーニングします。
正解：C
解説: A. Cloud ML EngineはGoogle Cloudで機械学習モデルをトレーニング、デプロイ、予測するためのサービスですが、Spark MLモデルは直接サポートされていません。Cloud ML Engineは主にTensorFlowなどの特定のフレームワーク用です。そのため、この選択肢は適切ではありません。
B. このオプションは、Spark MLモデルをTensorFlowに書き換えることを提案しています。これは理論的には可能ですが、モデルの書き換えは時間がかかる作業であり、リフト＆シフト移行の迅速なアプローチとは言えません。したがって、この選択は短期間での移行には適していません。
C. Cloud DataprocはGoogle Cloud上でのApache HadoopとApache Sparkの実行を簡単にするマネージドサービスです。BigQueryとの連携も可能で、Spark MLモデルを直接トレーニングすることができるため、この選択肢は既存のSpark MLモデルを迅速にGoogle Cloudに移行するのに適した方法です。
D. Compute Engineを使用して自分でSparkクラスタをセットアップすることは可能ですが、手動のセットアップと管理が必要になるため、移行を速やかに行う上では最適ではありません。また、BigQueryからデータをエクスポートして利用するよりは、直接BigQueryからデータを読み取る方が効率的です。
2.
データ ウェアハウスを BigQuery に移行しています。すべてのデータをデータセット内のテーブルに移行しました。組織の複数のユーザーがデータを使用します。チーム メンバーシップに基づいて特定のテーブルのみを表示する必要があります。ユーザー権限をどのように設定する必要がありますか?
A. 各テーブルのテーブル レベルでユーザー/グループ データ ビューアー アクセス権を割り当てます。
B. データが存在する同じデータセットで各チームの SQL ビューを作成し、SQL ビューへのデータ ビューアー アクセス権をユーザー/グループに割り当てます。
C. データが存在する同じデータセット内の各チームの承認済みビューを作成し、ユーザー/グループのデータ閲覧者アクセスを承認済みビューに割り当てます
D. チームごとに作成されたデータセットで、チームごとに承認されたビューを作成します。データが存在するデータセットへの承認されたビュー データ ビューアー アクセスを割り当てます。許可されたビューが存在するデータセットへのユーザー/グループのデータ閲覧者アクセス権を割り当てます
正解：D
解説:
A. テーブルレベルのアクセス権をユーザーまたはグループに直接割り当てることは可能ですが、このアプローチでは、どのユーザーがどのテーブルにアクセスできるかを細かく制御する必要があるため、管理が煩雑になる可能性があります。これは、特定のテーブルにのみアクセスを制限するという要件には適していますが、より複雑なアクセス管理やセキュリティ要件には柔軟性が欠ける場合があります。
B. SQLビューを作成し、それにアクセス権を割り当てることで、テーブルに格納されているデータへのアクセスを仲介することができます。これはビューを介してデータにアクセスする際のセキュリティ層を提供することになり、原則として適切な方法ですが、原テーブルに対してビューアー権限がなければ、ビューを通してデータを見ることはできません。
C. 承認済みビューは、ユーザーにビューを介してのみデータセットにアクセスさせる方法であり、データセットへの直接アクセスを避けることができます。これにより、どのユーザーがどのデータにアクセスできるかを細かく管理することができますが、このオプションだけでは、データセットへの直接アクセスがブロックされるため、ビューを介してのアクセスもできなくなります。
D. これは適切なセキュリティ設定を行うためのベストプラクティスです。チームごとに独自のデータセットを作成し、承認済みビューをそのデータセットに作成します。そして、元のデータセットへの承認済みビュー経由でのみアクセスを許可します。これにより、元のデータセットには直接アクセスせずに、ユーザーはビューを通じて必要なデータのみを見ることができるため、データアクセスを効果的に管理することができます。
3.
何百万ものコンピューターの CPU とメモリの使用状況を時系列で保存するデータベースを選択する必要があります。このデータを 1 秒間隔のサンプルに格納する必要があります。アナリストは、データベースに対してリアルタイムのアドホック分析を実行します。クエリを実行するたびに料金が発生することを避け、スキーマ設計がデータセットの将来の成長に対応できるようにする必要があります。どのデータベースとデータ モデルを選択する必要がありますか?
A. BigQuery でテーブルを作成し、CPU とメモリの新しいサンプルをテーブルに追加します。
B. BigQuery で幅の広いテーブルを作成し、1 秒ごとのサンプル値の列を作成し、1 秒ごとの間隔で行を更新します
C. Cloud Bigtable に狭いテーブルを作成し、Computer Engine のコンピューター ID と 1 秒ごとのサンプル時間を組み合わせた行キーを使用します。
D. Cloud Bigtable で、コンピューター識別子と 1 分ごとのサンプル時間を組み合わせた行キーを持つワイド テーブルを作成し、1 秒ごとの値を列データとして組み合わせます。
正解：C
解説:
A. BigQueryは、大規模なデータウェアハウス向けに最適化されており、大量のデータを迅速に分析するのに優れています。しかし、リアルタイムのアドホック分析には向いていません。また、クエリごとに料金が発生するため、頻繁なクエリを実行するとコストが高くなります。
B. BigQueryの幅の広いテーブルを使用して1秒ごとに行を更新するというアプローチは、BigQueryの最適な使用法ではありません。BigQueryは主にイミュータブルなデータの分析に適しており、1秒ごとに更新するという操作は、その設計には合致しません。
C. Cloud Bigtableは、大量の時系列データをリアルタイムで読み書きするのに適したNoSQLデータベースです。1秒間隔のサンプルデータを保持し、リアルタイムでのアドホック分析が可能です。また、データの読み書きに関しては固定料金（ノードの料金）であり、クエリごとの料金は発生しません。このため、コンピューターIDとサンプル時間を組み合わせた行キーを使った狭いテーブルを作成するというのは、このケースに適した選択です。
D. Cloud Bigtableはワイドカラムストアであり、ワイドテーブルの設計も可能ですが、1分ごとのサンプル時間を行キーとして使用すると、1秒ごとの詳細データを扱うという要件に合いません。このオプションは、より粗い粒度の時系列データに適しています。また、1秒ごとの値を列データとして扱うことは、潜在的にテーブルのスキーマを複雑化し、性能に影響を与える可能性があります。
4.
株式取引を格納するデータベースと、調整可能な時間枠で特定の会社の平均株価を取得するアプリケーションを操作します。データは Cloud Bigtable に保存され、株式取引の日時が行キーの先頭になります。アプリケーションには何千もの同時ユーザーがいて、株式が追加されるにつれてパフォーマンスが低下し始めていることに気付きました。アプリケーションのパフォーマンスを向上させるために何をすべきですか?
A. Cloud Bigtable テーブルの行キー構文を、株式記号で始まるように変更します。
B. Cloud Bigtable テーブルの行キー構文を変更して、1 秒あたりの乱数で開始します。
C. 株式取引の保存に BigQuery を使用するようにデータ パイプラインを変更し、アプリケーションを更新します。
D. Cloud Dataflow を使用して、毎日の株式取引の概要を Cloud Storage の Avro ファイルに書き込みます。
Cloud Storage と Cloud Bigtable から読み取って応答を計算するようにアプリケーションを更新します。
正解：B
解説:
A. 行キーの構造を株式記号で始めることは、特定の株式記号に対する読み込みリクエストが集中するため、ホットスポットを引き起こす可能性があります。これは特に、一部の株式が他の株式よりも取引が頻繁である場合に問題となります。ホットスポットは、データベースの特定のノードに過剰なトラフィックが集中し、パフォーマンスのボトルネックを作り出す状態です。
B. 行キーの先頭にランダムな要素を導入することで、書き込み操作がBigtableクラスタ全体に均等に分散され、ホットスポットを防ぐことができます。この方法は、特に書き込みの多いアプリケーションにとって、書き込みパフォーマンスを向上させる効果的な戦略です。
C. BigQueryはアナリティクスに適したデータウェアハウスソリューションであり、時系列データのバッチ処理には優れていますが、リアルタイムの書き込みと高頻度の小規模クエリには最適化されていません。そのため、リアルタイムで何千ものユーザーによる書き込みとクエリが必要なこのシナリオには適していない可能性があります。
D. Cloud Dataflowを使用してCloud Storageにデータを集約するというアプローチは、分析のためのデータのバッチ処理には有用ですが、リアルタイムでの株式取引データの読み書きに直接的なパフォーマンス向上をもたらすものではありません。また、この方法は追加のステップとコストがかかるため、パフォーマンスの問題を解決する最も直接的な手段ではないかもしれません。
5.
MJTelco は、過去 2 年間のレコードの履歴分析を可能にするスキーマを Google Bigtable で作成するように求めています。着信する各レコードは 15 分ごとに送信され、デバイスの一意の識別子とデータ レコードが含まれます。最も一般的なクエリは、特定の日の特定のデバイスのすべてのデータに対するものです。どのスキーマを使用する必要がありますか?
A. 行キー: data_point
列データ: device_id,date
B. 行キー: device_id
列データ: 日付、data_point
C. 行キー: date#device_id
列データ: data_point
D. 行キー: date#data_point
列データ: device_id
E. 行キー: 日付
列データ: device_id、data_point
正解：A
解説:
A. このオプションでは、行キーが 'data_point' であり、列データに 'device_id' と 'date' が含まれます。しかし、このスキーマは特定の日の特定のデバイスに対して効率的なクエリを実行することができません。'data_point' は特定のデバイスや日付についての情報を持っていないので、必要なデータを取得するためには大量の行をスキャンする必要があります。
B. 行キーが 'device_id' で、列データに 'date' と 'data_point' が含まれるスキーマでは、特定のデバイスに対するクエリは効率的ですが、特定の日に限定されたクエリのパフォーマンスは低いでしょう。特定のデバイスに対しては良いですが、日付範囲に対しては、すべてのデバイスのデータをスキャンする必要があります。
C. 行キーが 'date#device_id' で、列データが 'data_point' のスキーマは、特定の日の特定のデバイスのデータを取得する最も一般的なクエリにとって最適です。日付とデバイスIDの組み合わせが行キーになることで、関連するデータへのアクセスが非常に効率的になります。
D. 行キーが 'date#data_point' で、列データが 'device_id' のスキーマでは、特定の日付のデータポイントにはアクセスしやすいですが、特定のデバイスIDに基づいてフィルタリングすることはできません。これにより、特定のデバイスに関する情報を効率的に取得することができないため、最も一般的なクエリには不適切です。
E. 行キーが '日付' で、列データに 'device_id' と 'data_point' が含まれるスキーマは、特定の日付に対してはクエリを効率的に行うことができますが、特定のデバイスIDを持つレコードに迅速にアクセスすることはできません。これにより、大量のデータをスキャンする必要があり、非効率的です。
6.
時系列のトランザクション データをコピーするデータ パイプラインを作成して、データ サイエンス チームが分析のために BigQuery 内からクエリできるようにする必要があります。1 時間ごとに、何千ものトランザクションが新しいステータスで更新されます。初期データセットのサイズは 1.5 PB で、1 日あたり 3 TB ずつ増加します。データは高度に構造化されており、データ サイエンス チームはこのデータに基づいて機械学習モデルを構築します。データ サイエンス チームのパフォーマンスと使いやすさを最大化する必要があります。どの 2 つの戦略を採用する必要がありますか? （2つ選んでください。）
A. 可能な限りデータを非正規化します。
B. BigQuery UPDATE を使用して、データセットのサイズをさらに縮小します。
C. ステータスの更新が更新ではなく BigQuery に追加されるデータ パイプラインを開発します。
D. データの構造を可能な限り保持します。
E. トランザクション データの日次スナップショットを Cloud Storage にコピーし、Avro ファイルとして保存します。外部データ ソースに対する BigQuery のサポートを使用してクエリを実行します。
正解：C,E
解説:
A. 非正規化は、異なるデータ ソースからのデータを結合し、一つのテーブルにまとめるプロセスです。非正規化はクエリのパフォーマンスを向上させることができますが、データの重複を引き起こし、ストレージコストを増加させる可能性があります。BigQueryでは非正規化されたデータがクエリのパフォーマンス向上に貢献することが多いので、このオプションは考慮されるべきですが、正解には含まれていません。
B. BigQueryのUPDATE文は既存の行を更新するために使用されますが、BigQueryでは行の更新や削除はコストがかかり、効率が低下する可能性があります。特に大規模なデータセットに対して頻繁に行うとコストとパフォーマンスの観点から問題が発生するため、この戦略は推奨されません。
C. BigQueryは不変のデータセットに対して非常に効率的です。更新ではなく、新しいステータスレコードを追加するアプローチは、変更を追跡しやすくし、BigQueryのストレージとクエリの最適化に寄与します。これはBigQueryのデータモデルに適合するため、推奨される戦略です。
D. データの構造を保持することは、データの意味と関連性を維持するために重要ですが、パフォーマンスと使いやすさの観点では必ずしも最適ではありません。構造化データに対するクエリのパフォーマンスを最大化するためには、適切なスキーマ設計とデータの整理が求められます。
E. BigQueryは外部データソースからのデータのクエリに対応しています。大量のトランザクションデータを日次でスナップショットとしてCloud Storageに保存し、必要に応じてBigQueryからクエリすることは、ストレージコストの削減とパフォーマンスの向上に寄与します。AvroはBigQueryとの互換性が高く、圧縮率も良いため、この戦略はデータサイエンスチームのパフォーマンスと使いやすさを向上させるでしょう。
正解の C と E は、BigQueryの利用を最大化し、データサイエンスチームが効率的にアクセスしやすい環境を作るために推奨される戦略です。
7.
あなたの会社の顧客データベースと注文データベースは、多くの場合、大きな負荷がかかっています。これにより、運用に影響を与えずにそれらに対して分析を実行することが困難になります。データベースは MySQL クラスター内にあり、mysqldump を使用して毎晩バックアップが作成されます。運用への影響を最小限に抑えて分析を実行したい。あなたは何をするべきか？
A. MySQL クラスターにノードを追加し、そこに OLAP キューブを構築します。
B. ETL ツールを使用して、MySQL から Google BigQuery にデータを読み込みます。
C. オンプレミスの Apache Hadoop クラスターを MySQL に接続し、ETL を実行します。
D. バックアップを Google Cloud SQL にマウントし、Google Cloud Dataproc を使用してデータを処理します。
正解：C
解説:
A. MySQLクラスターにノードを追加してOLAPキューブを構築するアプローチは、分析のための専用リソースを提供することで運用の負荷を分散する可能性があります。しかし、これはMySQLの運用環境に直接影響を及ぼすため、分析作業による負荷の問題を完全に解決するものではありません。
B. ETLツールを使ってGoogle BigQueryにデータを読み込む方法は、運用データベースへの影響を最小限に抑えながら、強力な分析能力を備えたBigQueryを活用できる良い解決策です。BigQueryは大量のデータに対して高速な分析を実行できるフルマネージドなデータウェアハウスサービスです。
C. オンプレミスのApache Hadoopクラスターを使用してETLを実行することは、MySQLデータベースの運用に影響を与えずに分析処理を実行できる一つの方法です。しかし、Hadoopはセットアップと運用が複雑であり、またデータをオンプレミスのクラスターに移動させることになるため、処理の遅延が発生する可能性があります。
D. バックアップをGoogle Cloud SQLにマウントし、Google Cloud Dataprocを使用してデータを処理するという選択肢は、運用データベースへの影響を避けるためにバックアップデータを利用する点で有効です。Cloud SQLはMySQLとの互換性がありますが、mysqldumpバックアップファイルを直接マウントすることはできません。このため、データをCloud SQLにインポートするステップが必要です。また、DataprocはHadoopとSparkのためのマネージドサービスであり、データ分析をスケーラブルに実行できますが、このプロセスは複数のステップが必要であり、最も効率的な方法とは言えません。
8.
ユーザーが何を食べたいかを予測する機械学習ベースの食品注文サービスのデータベース スキーマを設計しています。保存する必要がある情報の一部を次に示します。
ユーザー プロファイル: ユーザーが好きなものと嫌いなもの
ユーザー アカウント情報: 名前、住所、希望の食事時間
注文情報：いつ、どこから、誰に注文するか
データベースは、製品のすべてのトランザクション データを保存するために使用されます。データ スキーマを最適化したい。どの Google Cloud Platform プロダクトを使用する必要がありますか?
A. クラウド Bigtable
B. クラウド データストア
C. BigQuery
D. クラウド SQL
正解：C
解説:
A. クラウド Bigtableは高性能のNoSQLデータベースサービスで、大量のデータに対する高速な読み書きが可能です。しかし、トランザクションデータの保存には適していますが、複雑なクエリや結合、分析的クエリを実行するのには向いていません。リアルタイムの分析やイベント駆動型のデータに適していますが、このシナリオで必要とされるデータベーススキーマの設計には最適ではありません。
B. クラウド データストアはNoSQLのドキュメント指向データベースで、ウェブやモバイルアプリケーションに適しています。トランザクションの一貫性を提供し、複雑なトランザクションやリレーショナルデータのモデリングにも適していますが、大規模な分析には適していないため、このシナリオには最適な選択とは言えません。
C. BigQueryは、大量のトランザクションデータを保存し、それを分析するためのフルマネージドなサーバーレスデータウェアハウスサービスです。SQLクエリを使用して迅速にデータを分析でき、マシンラーニング機能も組み込まれています。ユーザープロファイルや注文情報などの複雑なクエリが求められるこのシナリオでは最適な選択肢です。
D. クラウド SQLは、MySQL、PostgreSQL、SQL Serverなどのリレーショナルデータベースをフルマネージドで提供するサービスです。トランザクションデータの処理やリレーショナルデータベースの特性を活かしたい場合に適しています。ただし、大量のデータに対する高度な分析や、データウェアハウスとしての機能には限界があり、このシナリオではBigQueryの方が適しています。
9.
Cloud Pub/Sub から Cloud Dataflow を介して BigQuery に IoT データをストリーミングするために、Google Cloud で新しいパイプラインを作成しています。データのプレビュー中に、データの約 2% が破損しているように見えることに気付きました。この破損したデータを除外するには、Cloud Dataflow パイプラインを変更する必要があります
を。あなたは何をするべきか？
A. Cloud Dataflow にパーティション変換を追加して、有効なデータを破損したデータから分離します。
B. 要素が破損している場合にブール値を返す SideInput を追加します。
C. Cloud Dataflow に GroupByKey 変換を追加して、すべての有効なデータをまとめてグループ化し、残りを破棄します。
D. Cloud Dataflow に ParDo 変換を追加して、破損した要素を破棄します。
正解：D
解説:
A. Cloud Dataflow にパーティション変換を追加するという選択肢は、データを特定の条件に基づいて分割するために使用されます。しかし、これはデータが破損しているかどうかを特定し、それをフィルタリングするためのものではありません。
B. SideInput は、Cloud Dataflow で使用される、追加の入力データをパイプラインの主要なPCollectionに関連付けるための方法です。しかし、これは単一の要素が破損しているかどうかを決定し、それを除外するための機能ではありません。SideInput は、変換で使用するための追加情報や、他のソースからのデータを提供するのに役立ちますが、破損したデータを直接処理することはできません。
C. GroupByKey は、キーに基づいて値をグループ化するための変換です。この選択肢は、データをキーに基づいて集約する場合に使用されますが、破損した要素を識別して除外するための変換ではありません。
D. ParDo は、Cloud Dataflow において、各要素に対してカスタム処理を行う変換です。これにより、破損したデータを識別し、処理から除外するカスタムロジックを適用することができます。データのプレビュー中に破損したデータを検出した場合、ParDo を使用してそのデータをフィルタリングすることが推奨されます。このシナリオでは、破損した要素を破棄するためにParDo変換を追加するのが最適な解決策です。正解のDは、問題の要件を満たすための正しいアプローチを提供します。
10.
Bigtable クラスタ内の特定のノードで不均衡な数の読み取りや書き込みを引き起こす可能性が高い行キーはどれですか (2 つの回答を選択)。
A. 連続した数値 ID
B. タイムスタンプとそれに続く銘柄記号
C. 連続していない数値 ID
D. タイムスタンプが続く銘柄記号
正解：A,B
解説:
A. 連続した数値 IDを行キーとして使用すると、書き込みが連続するため、特定のノードにデータが集中するリスクがあります。これは特に、IDが順番に生成され、データが時系列で追加されるような場合に顕著です。このようなキーデザインはホットスポットを引き起こし、特定のノードに負荷がかかりやすくなります。
B. タイムスタンプとそれに続く銘柄記号を行キーとして使用すると、特定の時点での書き込みが集中し、同様にホットスポットを引き起こす可能性があります。これは金融市場データなど、特定のイベントが一斉に発生する場合によく見られます。
C. 連続していない数値 IDは、データの分散を促進するので、ホットスポットを引き起こす可能性が低いです。このようなIDは、ランダムまたはプリフィックスが追加されてバランスよく分散されるよう設計されている場合が多いです。
D. タイムスタンプが続く銘柄記号では、タイムスタンプが先にくることで、同じ銘柄に対する書き込みが時系列に並ぶことになりますが、これだけではノード間の読み書きの不均衡を引き起こすとは限りません。問題文では、どのようにタイムスタンプが使用されているか、またはタイムスタンプの粒度がどの程度かが明示されていないため、この選択肢だけでホットスポットが発生するとは限りません。
ここから先は
¥ 2,000
この記事が気に入ったらサポートをしてみませんか？