[2025年10月] ベスト Google Cloud Certified 学習ガイドは Professional-Data-Engineer日本語 試験問題集 [Q143-Q166]

[2025年10月] ベストGoogle Cloud Certified学習ガイドはProfessional-Data-Engineer日本語試験問題集

Professional-Data-Engineer日本語認定ガイド問題と解答トレーニング

質問 # 143
Cloud Dataproc クラスタでスケジュールに従って実行される Spark ジョブがいくつかあります。ジョブの中には順番に実行されるものもあれば、同時に実行されるものもあります。このプロセスを自動化する必要があります。どうすればよいでしょうか。

• A. ジョブを実行するための初期化アクションを作成する
• B. Cloud SDK を使用してクラスタを作成し、ジョブを実行し、クラスタを破棄する Bash スクリプトを作成します。
• C. Cloud Dataproc ワークフロー テンプレートを作成する
• D. Cloud Composer で有向非巡回グラフを作成する

正解：D

質問 # 144
バッチ処理ジョブ用の Dataflow パイプラインを設計しています。ジョブの送信時に複数のゾーン障害を軽減したいと考えています。どうすればよいでしょうか。

• A. ジョブの送信時にゾーン障害が発生した場合にジョブを再送信するための Eventarc トリガーを作成します。
• B. -region フラグを使用してワーカー リージョンを指定します。
• C. -zone フラグを使用して、2 つの異なるゾーンに重複したパイプラインを送信します。
• D. パイプラインのステージング場所をリージョンの Cloud Storage バケットとして設定します。

正解：D

解説：
By specifying a worker region, you can run your Dataflow pipeline in a multi-zone or multi-region configuration, which provides higher availability and resilience in case ofzonal failures1. The -region flag allows you to specify the regional endpoint for your pipeline, which determines the location of the Dataflow service and the default location of the Compute Engine resources1. If you do not specify a zone by using the
-zone flag, Dataflow automatically selects a zone within the region for your job workers1. This option is recommended over submitting duplicate pipelines in two different zones, which would incur additional costs and complexity. Setting the pipeline staging location as a regional Cloud Storage bucket does not affect the availability of your pipeline, as the staging location only stores the pipeline code and dependencies2. Creating an Eventarc trigger to resubmit the job in case of zonal failure is not a reliable solution, as it depends on the availability of the Eventarc service and the zonal resources at the time of resubmission. References:
* 1: Pipeline troubleshooting and debugging | Cloud Dataflow | Google Cloud
* 3: Regional endpoints | Cloud Dataflow | Google Cloud

質問 # 145
数百万台のコンピューターの時系列のCPUとメモリの使用量を保存するデータベースを選択する必要があります。このデータを1秒間隔のサンプルに保存する必要があります。アナリストは、データベースに対してリアルタイムのアドホック分析を実行します。実行されたすべてのクエリに対して課金されることを避け、スキーマ設計がデータセットの将来の拡張を可能にすることを保証する必要があります。どのデータベースとデータモデルを選択する必要がありますか？

• A. BigQueryで幅の広いテーブルを作成し、毎秒のサンプル値の列を作成し、毎秒の間隔で行を更新します
• B. Cloud Bigtableで、コンピューター識別子と1分ごとのサンプル時間を組み合わせた行キーを使用して幅の広いテーブルを作成し、1秒ごとの値を列データとして組み合わせます。
• C. ComputerEngineのコンピューター識別子と毎秒のサンプル時間を組み合わせた行キーを使用してCloudBigtableに狭いテーブルを作成します
• D. BigQueryでテーブルを作成し、CPUとメモリの新しいサンプルをテーブルに追加します

正解：C

質問 # 146
Google StackdriverLoggingを使用してGoogleBigQueryの使用状況を監視するとします。挿入ジョブを使用して特定のテーブルに新しいデータが追加されたときに、監視ツールに即時通知を送信する必要がありますが、他のテーブルの通知を受信したくない場合。あなたは何をするべきか？

• A. Stackdriverロギング管理インターフェースで、Google Cloud Pub / Subへのログシンクのエクスポートを有効にし、モニタリングツールからトピックをサブスクライブします。
• B. Stackdriver APIを使用して、高度なログフィルターを備えたプロジェクトシンクを作成してPub / Subにエクスポートし、モニタリングツールからトピックをサブスクライブします。
• C. Stackdriverロギング管理インターフェースで、BigQueryへのログシンクのエクスポートを有効にします。
• D. Stackdriver APIを呼び出してすべてのログを一覧表示し、高度なフィルターを適用します。

正解：C

質問 # 147
Put/Sub フィードのサブスクライバーのコードを更新しています。デプロイメント時にサブスクライバーが誤ってメッセージを確認し、メッセージが失われる可能性があることを懸念しています。サブスクライバーは確認済みのメッセージを保持するように設定されていません。デプロイメント後にエラーから回復できるようにするには、何をする必要がありますか?

• A. Pub/Sub トピックでデッドレター処理を有効にして、正常に確認されなかったメッセージをキャプチャします。デプロイ後にエラーが発生した場合は、デッドレターキューによってキャプチャされたメッセージを再配信します。
• B. デプロイ後にエラーが発生した場合は、デプロイに Cloud Build を使用します。デプロイの開始時に Cloud Build によって記録されたタイムスタンプを Seek 操作で見つけます。
• C. ローカルマシンに Pub/Sub エミュレーターをセットアップし、本番環境にデプロイする前に新しいサブスクライバー トグの動作を検証します。
• D. 新しいサブスクライバー コードをデプロイする前に、Pub/Sub スナップショットを作成します。スナップショットの作成後に利用可能になったメッセージを再配信するには、Seek 操作を使用します。

正解：D

質問 # 148
CloudDataprocクラスター上でスケジュールに従って実行されるSparkジョブがいくつかあります。一部のジョブは順番に実行され、一部のジョブは同時に実行されます。このプロセスを自動化する必要があります。あなたは何をするべきか？

• A. Cloud SDKを使用してクラスターを作成し、ジョブを実行してから、クラスターを破棄するBashスクリプトを作成します
• B. CloudDataprocワークフローテンプレートを作成します
• C. ジョブを実行するための初期化アクションを作成します
• D. CloudComposerで有向非巡回グラフを作成する

正解：D

解説：
References:

質問 # 149
オンプレミスのデータ ウェアハウスを BigQuery に移行しています。移行の一環として、チーム間のコラボレーションを促進して、組織のデータから最大限の価値を引き出したいと考えています。組織内のチームが読み取り専用データをセルフサービス方式で安全に公開、検出、サブスクライブできるアーキテクチャを設計する必要があります。コストを最小限に抑えながら、データの鮮度を最大限に高める必要があります。どうすればよいでしょうか。

• A. 承認されたデータセットを作成して、サブスクライブ チームのプロジェクトで共有データを公開します。
• B. Analytics Hub を使用してデータ共有を容易にします。
• C. 各チームのプロジェクトで共有するための新しいデータセットを作成します。サブスクライブしているチームにデータセットに対する bigquery.dataViewer ロールを付与します。
• D. BigQuery Data Transfer Service を使用して、データセットを一元化された BigQuery プロジェクトにコピーし、共有します。

正解：D

解説：
To provide a cost-effective storage and processing solution that allows data scientists to explore data similarly to using the on-premises HDFS cluster with SQL on the Hive query engine, deploying a Dataproc cluster is the best choice. Here's why:
Compatibility with Hive:
Dataproc is a fully managed Apache Spark and Hadoop service that provides native support for Hive, making it easy for data scientists to run SQL queries on the data as they would in an on-premises Hadoop environment.
This ensures that the transition to Google Cloud is smooth, with minimal changes required in the workflow.
Cost-Effective Storage:
Storing the ORC files in Cloud Storage is cost-effective and scalable, providing a reliable and durable storage solution that integrates seamlessly with Dataproc.
Cloud Storage allows you to store large datasets at a lower cost compared to other storage options.
Hive Integration:
Dataproc supports running Hive directly, which is essential for data scientists familiar with SQL on the Hive query engine.
This setup enables the use of existing Hive queries and scripts without significant modifications.
Steps to Implement:
Copy ORC Files to Cloud Storage:
Transfer the ORC files from the on-premises HDFS cluster to Cloud Storage, ensuring they are organized in a similar directory structure.
Deploy Dataproc Cluster:
Set up a Dataproc cluster configured to run Hive. Ensure that the cluster has access to the ORC files stored in Cloud Storage.
Configure Hive:
Configure Hive on Dataproc to read from the ORC files in Cloud Storage. This can be done by setting up external tables in Hive that point to the Cloud Storage location.
Provide Access to Data Scientists:
Grant the data scientist team access to the Dataproc cluster and the necessary permissions to interact with the Hive tables.
Reference:
Dataproc Documentation
Hive on Dataproc
Google Cloud Storage Documentation

質問 # 150
BigQuery ジョブを実行するプロジェクトが 2 つあります。
* あるプロジェクトでは、完了時間の SLA が厳格に定められた運用ジョブを実行しています。これらは優先度の高いジョブであり、必要なときに必要なコンピューティング リソースを利用できる必要があります。これらのジョブの使用率は、通常 300 スロットを下回ることはありませんが、時折、さらに 500 スロットまで急上昇することがあります。
* もう 1 つのプロジェクトは、ユーザーがアドホック分析クエリを実行するためのものです。このプロジェクトでは通常、一度に 200 を超えるスロットが使用されることはありません。これらのアドホック クエリは、スロット容量ではなく、ユーザーがスキャンするデータの量に基づいて課金されるようにします。
両方のプロジェクトで適切なコンピューティング リソースが利用可能であることを確認する必要があります。どうすればよいでしょうか?

• A. プロジェクトごとに 1 つずつ、合計 2 つの予約を作成します。SLA プロジェクトでは、ベースラインが 300 スロットの Enterprise Edition を使用し、最大 500 スロットまでの自動スケーリングを有効にします。アドホック プロジェクトでは、オンデマンド課金を構成します。
• B. 両方のプロジェクトに対して単一の Enterprise Edition 予約を作成します。ベースラインを 300 スロットに設定します。最大 700 スロットまでの自動スケーリングを有効にします。
• C. プロジェクトごとに 1 つずつ、合計 2 つの Enterprise Edition 予約を作成します。SLA プロジェクトの場合は、ベースラインを 800 スロットに設定します。アドホック プロジェクトの場合は、最大 200 スロットの自動スケーリングを有効にします。
• D. プロジェクトごとに 1 つずつ、合計 2 つの Enterprise Edition 予約を作成します。SLA プロジェクトの場合は、ベースラインを 300 スロットに設定し、最大 500 スロットの自動スケーリングを有効にします。アドホック プロジェクトの場合は、予約ベースラインを 0 スロットに設定し、ignore_idle_slot3 フラグを False に設定します。

正解：A

解説：
To ensure that both production jobs with strict SLAs and ad-hoc queries have appropriate compute resources available while adhering to cost efficiency, setting up separate reservations and billing models for each project is the best approach. Here's why option B is the best choice:
* Separate Reservations for SLA and Ad-hoc Projects:
* Creating two separate reservations allows for dedicated resource management tailored to the needs of each project.
* The production project requires guaranteed slots with the ability to scale up as needed, while the ad-hoc project benefits from on-demand billing based on data scanned.
* Enterprise Edition Reservation for SLA Project:
* Setting a baseline of 300 slots ensures that the SLA project has the minimum required resources.
* Enabling autoscaling up to 500 additional slots allows the project to handle occasional spikes in workload without compromising on SLAs.
* On-Demand Billing for Ad-hoc Project:
* Using on-demand billing for the ad-hoc project ensures cost efficiency, as users are billed based on the amount of data scanned rather than reserved slot capacity.
* This model suits the less predictable and often lower-utilization nature of ad-hoc queries.
Steps to Implement:
* Set Up Enterprise Edition Reservation for SLA Project:
* Create a reservation with a baseline of 300 slots.
* Enable autoscaling to allow up to an additional 500 slots as needed.
* Configure On-Demand Billing for Ad-hoc Project:
* Ensure that the ad-hoc project is set up to use on-demand billing, which charges based on data scanned by the queries.
* Monitor and Adjust:
* Continuously monitor the usage and performance of both projects to ensure that the configurations meet the needs and make adjustments as necessary.
Reference Links:
* BigQuery Slot Reservations
* BigQuery On-Demand Pricing

質問 # 151
あなたのチームは二項分類の問題に取り組んでいます。デフォルトのパラメーターを使用してサポートベクターマシン（SVM）分類器をトレーニングし、検証セットで曲線（AUC）の下の領域0.87を受け取りました。
モデルのAUCを増やしたい。あなたは何をするべきか？

• A. 最高のAUCを取得するために、モデルから取得するスケール予測（スケーリング係数をハイパーパラメーターとして調整）
• B. モデルを展開し、実際のAUCを測定します。一般化のために常に高くなります
• C. ハイパーパラメータ調整を実行します
• D. ニューラルネットワークは常にSVMを打ち負かすため、ディープニューラルネットワークで分類器をトレーニングします

正解：A

質問 # 152
会社のデータ アナリスト チームは、2,000 スロットのスロット予約を持つ Google Cloud プロジェクトで、アドホック クエリとスケジュールされた SQL パイプラインに BigQuery を使用しています。しかし、最近、数百の新しい時間に依存しない SQL パイプラインが導入されたため、チームは頻繁に割り当てエラーに遭遇しています。ログを調べると、ピーク時に約 1,500 のクエリが同時にトリガーされていることに気付きました。同時実行の問題を解決する必要があります。どうすればよいでしょうか。

• A. プロジェクトのスロット容量をベースライン 2000、最大予約サイズを 3000 に増やします。
• B. ベースラインを 0、最大予約サイズを 3000 にして、プロジェクトのスロット容量を増やします。
• C. SQL パイプラインとアドホック クエリを更新して、対話型クエリ ジョブとして実行します。
• D. SOL パイプラインを更新してバッチ クエリとして実行し、アドホック クエリをインタラクティブ クエリ ジョブとして実行します。

正解：D

解説：
数百の時間に依存しない SQL パイプラインの導入によって発生する BigQuery の同時実行の問題を解決するには、緊急性とリソース要件に基づいてクエリの種類を区別することが最善のアプローチです。オプション C が最適な選択である理由は次のとおりです。
バッチクエリとしての SQL パイプライン:
BigQuery のバッチクエリは、時間に敏感でない操作向けに設計されています。優先度の低いキューで実行され、スロットをすぐに消費しないため、ピーク時の全体的なスロット消費量を削減できます。
時間に依存しない SQL パイプラインをバッチ クエリに変換することで、スロット予約の負担を大幅に軽減できます。
インタラクティブ クエリとしてのアドホック クエリ:
インタラクティブ クエリはすぐに実行されるように優先され、ユーザーが迅速な結果を期待するアドホック分析に適しています。
アドホック クエリをインタラクティブ ジョブとして実行すると、アナリストは遅延なく結果を取得できるため、生産性とユーザー満足度が向上します。
同時実行管理:
このアプローチは、BigQuery のさまざまな種類のクエリを効率的に処理する機能を活用してワークロードのバランスをとるのに役立ち、スロットの枯渇による割り当てエラーが発生する可能性を減らします。
実装手順:
時間的制約のないパイプラインを特定する:
時間的に重要ではなく、バッチ ジョブとして実行できる SQL パイプラインを確認して識別します。
パイプラインをバッチクエリに更新する:
これらのパイプラインを変更してバッチ クエリとして実行します。これは、クエリ ジョブの優先度を BATCH に設定することで実行できます。
アドホッククエリがインタラクティブであることを確認する:
すべてのアドホック クエリがインタラクティブ ジョブとして送信され、高い優先度で実行され、即時にスロットが割り当てられるようにします。
参照：
BigQuery バッチクエリ
BigQuery スロットの割り当てと管理

質問 # 153
世界中の倉庫の温度データを収集するために、10,000台の新しいモノのインターネットデバイスを導入しています。これらの非常に大きなデータセットをリアルタイムで処理、保存、分析する必要があります。あなたは何をするべきか？

• A. ログをバッチでGoogle Cloud Storageにエクスポートしてから、Google Cloud SQLインスタンスを起動し、Cloud Storageからデータをインポートして、必要に応じて分析を実行します。
• B. データをGoogle Cloud Datastoreに送信してから、BigQueryにエクスポートします。
• C. データをCloud Storageに送信し、分析が必要な場合はいつでも、Google CloudDataprocで必要に応じてApacheHadoopクラスターを起動します。
• D. データをGoogle Cloud Pub / Subに送信し、Cloud Pub / SubをGoogleCloud Dataflowにストリーミングして、データをGoogleBigQueryに保存します。

正解：D

質問 # 154
組織のマーケティングチームは、顧客データセットのセグメントの定期的な更新を提供します。マーケティングチームから、BigQueryで更新する必要のある100万件のレコードを含むCSVが提供されました。 BigQueryでUPDATEステートメントを使用すると、quotaExceededエラーが発生します。あなたは何をするべきか？

• A. BigQuery UPDATE DMLステートメントの制限内に収まるように、毎日更新されるレコードの数を減らします。
• B. Google Cloud PlatformConsoleの[Quotamanagement]セクションでBigQueryUPDATEDMLステートメントの制限を増やします。
• C. CSVファイルから新しいBigQueryテーブルに新しいレコードをインポートします。新しいレコードを既存のレコードとマージし、結果を新しいBigQueryテーブルに書き込むBigQueryジョブを作成します。
• D. ソースCSVファイルをCloud Storage内の小さなCSVファイルに分割して、BigQueryジョブごとのBigQuery UPDATEDMLステートメントの数を減らします。

正解：C

質問 # 155
あなたの会社では、ホリデー シーズン中にリアルタイム データを分析してさまざまなオファーを提供する、初めての動的キャンペーンを実施しています。データ サイエンティストは、30 日間のキャンペーン中に毎時間急増するテラバイト単位のデータを収集しています。彼らは Google Cloud Dataflow を使用してデータを前処理し、Google Cloud Bigtable の機械学習モデルに必要な特徴 (シグナル) データを収集しています。チームは、初期ロードの 10 TB のデータに対する読み取りと書き込みで、最適ではないパフォーマンスを確認しています。彼らはコストを最小限に抑えながらこのパフォーマンスを改善したいと考えています。彼らは何をすべきでしょうか。

• A. クラスター内で頻繁に更新する必要がある値を識別するために、単一の行キーを使用するようにスキーマを再設計します。
• B. テーブルの行スペース全体に読み取りと書き込みを均等に分散してスキーマを再定義します。
• C. BigDate クラスターのサイトが増加するにつれて、パフォーマンスの問題は時間の経過とともに解決されるはずです。
• D. オファーを閲覧するユーザーごとに順番に増加する数値 ID に基づく行キーを使用するようにスキーマを再設計します。

正解：B

質問 # 156
BigQuery テーブルに 100 GB のデータが格納されています。このデータは古く、SQL による分析のために年に 1 ～ 2 回しかアクセスされません。バックアップの目的で、このデータを 3 年間変更不可として保存したいと考えています。ストレージ コストを最小限に抑えたいと考えています。どうすればよいでしょうか。

• A. 1 BigQuery テーブルのスナップショットを作成します。
  2 分析を実行する必要がある場合は、スナップショットを復元します。
• B. 1 アーカイブ ストレージ クラスを使用して Cloud Storage バケットに BigQuery エクスポートを実行します。
  2 バケットにロックされた保持ポリシーを設定します。
  3. エクスポートされたファイルに BigQuery 外部テーブルを作成します。
• C. 1 BigQuery テーブルのクローンを作成します。
  2. 分析を実行する必要がある場合は、クローンに対してクエリを実行します。
• D. 1. アーカイブ ストレージ クラスを使用して Cloud Storage バケットに BigQuery エクスポートを実行します。
  2 バケットで versionmg を有効にします。
  3. エクスポートされたファイルに BigQuery 外部テーブルを作成します。

正解：B

解説：
This option will allow you to store the data in a low-cost storage option, as the archive storage class has the lowest price per GB among the Cloud Storage classes. It will also ensure that the data is immutable for 3 years, as the locked retention policy prevents the deletion or overwriting of the data until the retention period expires. You can still query the data using SQL by creating a BigQuery external table that references the exported files in the Cloud Storage bucket. Option A is incorrect because creating a BigQuery table clone will not reduce the storage costs, as the clone will have the same size and storage class as the original table.
Option B is incorrect because creating a BigQuery table snapshot will also not reduce the storage costs, as the snapshot will have the same size and storage class as the original table. Option C is incorrect because enabling versioning on the bucket will not make the data immutable, as the versions can still be deleted or overwritten by anyone with the appropriate permissions. It will also increase the storage costs, as each version of the file will be charged separately. References:
Exporting table data | BigQuery | Google Cloud
Storage classes | Cloud Storage | Google Cloud
Retention policies and retention periods | Cloud Storage | Google Cloud Federated queries | BigQuery | Google Cloud

質問 # 157
あなたは服の推奨をするためのモデルを構築しています。ユーザーのファッションの好みは時間の経過とともに変化する可能性が高いことがわかっているため、データパイプラインを構築して、新しいデータが利用可能になったときにモデルにストリーミングします。
このデータをどのように使用してモデルをトレーニングする必要がありますか？

• A. 新しいデータをテストセットとして使用しながら、既存のデータをトレーニングします。
• B. 新しいデータのみでモデルを継続的に再トレーニングします。
• C. 既存のデータをテストセットとして使用しながら、新しいデータをトレーニングします。
• D. 既存のデータと新しいデータの組み合わせでモデルを継続的に再トレーニングします。

正解：A

解説：
Explanation
https://cloud.google.com/automl-tables/docs/prepare

質問 # 158
Cloud Dataproc は、マネージド Apache Hadoop および Apache _____ サービスです。

• A. ブレイズ
• B. 火
• C. 点火
• D. スパーク

正解：D

解説：
Cloud Dataproc は、バッチ処理、クエリ、ストリーミング、機械学習にオープンソースのデータ ツールを使用できるマネージド Apache Spark および Apache Hadoop サービスです。

質問 # 159
あなたの会社にはハイブリッド クラウド イニシアチブがあります。クラウド プロバイダー サービス間でデータを移動し、各クラウド プロバイダーのサービスを活用する複雑なデータ パイプラインがあります。パイプライン全体をオーケストレーションするには、どのクラウド ネイティブ サービスを使用すればよいでしょうか。

• A. クラウドデータ準備
• B. クラウド データプロシージャ
• C. クラウドデータフロー
• D. クラウド コンポーザー

正解：B

質問 # 160
運用環境に Standard Tier Memorystore for Redis インスタンスをデプロイしています。最も正確な災害復旧状況で Redis インスタンスのフェイルオーバーをシミュレートし、フェイルオーバーが運用データに影響を与えないことを確認する必要があります。どうすればよいでしょうか。

• A. 実稼働環境の Redis インスタンスにレプリカを 1 つ増やします。force-data-loss データ保護モードを使用して手動フェイルオーバーを開始します。
• B. 実稼働環境の Memorystore for Redis インスタンスに対して、データ損失が制限されたデータ保護モードを使用して手動のテーラーオーバーを開始します。
• C. 開発環境で Standard Tier Memorystore for Redis インスタンスを作成します。データ損失が制限されたデータ保護モードを使用して手動フェイルオーバーを開始します。
• D. 開発環境で Standard Tier Memorystore for Redis インスタンスを作成します。force-data-loss データ保護モードを使用して手動フェイルオーバーを開始します。

正解：C

解説：
本番データに影響を与えずに本番に近い環境で Redis インスタンスのフェイルオーバーをシミュレートするには、開発環境を使用するのが最善のアプローチです。オプション D が最適な選択である理由は次のとおりです。
Redis の標準層メモリストア:
スタンダード ティアは、高可用性と自動フェイルオーバー機能を提供します。制御された環境でフェイルオーバー シナリオをテストするのに適しています。
開発環境:
開発環境を使用すると、フェイルオーバー シミュレーションによる潜在的なデータ損失や影響が実稼働データに影響を及ぼさず、実稼働システムの整合性と可用性が維持されます。
データ損失制限モード:
手動フェイルオーバーの限定データ損失モードにより、フェイルオーバー プロセス中のデータ損失が最小限に抑えられ、実稼働フェイルオーバー シナリオの現実的なシミュレーションが可能になります。
実装手順:
開発環境を作成する:
実稼働インスタンスの構成を反映する Standard Tier Memorystore for Redis インスタンスを使用して開発環境をセットアップします。
手動フェイルオーバーを開始する:
フェールオーバー シナリオをシミュレートするには、データ損失が制限されたデータ保護モードを使用して手動フェールオーバーを開始します。
gcloud redis インスタンス フェイルオーバー INSTANCE_ID --data-protection-mode=limited-data-loss フェイルオーバーを確認します。
フェイルオーバー プロセスを監視および検証し、災害復旧シナリオを正確にシミュレートして、期待どおりに動作することを確認します。
参照：
Memorystore for Redis ドキュメント
Memorystore での手動フェイルオーバー

質問 # 161
ソーシャルメディアの投稿をGoogleBigQueryに保存し、ほぼリアルタイムで1分あたり10,000メッセージの割合で分析する必要があります。最初に、個々の投稿にストリーミング挿入を使用するようにアプリケーションを設計します。アプリケーションは、ストリーミング挿入の直後にデータ集約も実行します。ストリーミング挿入後のクエリは強い一貫性を示さず、クエリからのレポートは処理中のデータを見逃す可能性があることがわかりました。アプリケーションの設計をどのように調整できますか？

• A. 蓄積されたデータを2分ごとにロードするようにアプリケーションを書き直します。
• B. ストリーミング挿入コードを個々のメッセージのバッチロードに変換します。
• C. 元のメッセージをGoogle Cloud SQLに読み込み、ストリーミング挿入を介して1時間ごとにテーブルをBigQueryにエクスポートします。
• D. ストリーミング挿入後のデータ可用性の平均レイテンシを見積もり、2倍の時間待機した後に常にクエリを実行します。

正解：D

解説：
Explanation
The data is first comes to buffer and then written to Storage. If we are running queries in buffer we will face above mentioned issues. If we wait for the bigquery to write the data to storage then we won't face the issue.
So We need to wait till it's written tio storage

質問 # 162
5年間のログデータをクラウドストレージにアップロードしましたユーザーから、ログデータの一部のデータポイントが予想範囲外であると報告されました。これはエラーを示しています。この問題に対処し、将来的にプロセスを再度実行できるようにする必要があります。コンプライアンス上の理由で元のデータを保持する何をすべきですか？

• A. Cloud Storageからデータを読み取り、期待される範囲外の値をチェックし、値を適切なデフォルトに設定し、更新されたレコードをCloudStorageの同じデータセットに書き込むCloudDataflowワークフローを作成します
• B. Cloud Storageからデータを読み取り、期待される範囲外の値をチェックし、値を適切なデフォルトに設定し、更新されたレコードをCloudStorageの新しいデータセットに書き込むCloudDataflowワークフローを作成します
• C. Compute Engineインスタンスを作成し、CloudStorageにデータの新しいコピーを作成しますエラーのある行をスキップします
• D. Cloud StorageからBigQueryにデータをインポートします。新しいBigQueryテーブルを作成し、エラーのある行をスキップします。

正解：A

質問 # 163
Dataprocクラスターには多くの構成ファイルが含まれています。これらのファイルを更新するには、-propertiesオプションを使用する必要があります。オプションの形式は、file_prefix：property = _____です。

• A. 詳細
• B. id
• C. null
• D. 値

正解：D

解説：
To make updating files and properties easy, the --properties command uses a special format to specify the configuration file and the property and value within the file that should be updated. The formatting is as follows: file_prefix:property=value.
Reference: https://cloud.google.com/dataproc/docs/concepts/cluster-properties#formatting

質問 # 164
Google Cloud でデータ パイプラインを構築しています。機械学習プロセス用に、カジュアルな方法でデータを準備する必要があります。ロジスティック回帰モデルをサポートしたいと考えています。また、null 値を監視して調整する必要もあります。null 値は実数値のままにする必要があり、削除することはできません。どうすればよいでしょうか。

• A. Cloud Dataflow を使用して、サンプル ソース データ内の null 値を検索します。Cloud Dataprep ジョブを使用して、すべての null を「none」に変換します。
• B. Cloud Dataprep を使用してサンプル ソース データ内の null 値を検索します。Cloud Dataprep ジョブを使用して、すべての null を 0 に変換します。
• C. Cloud Dataprep を使用して、サンプル ソース データ内の null 値を検索します。Cloud Dataproc ジョブを使用して、すべての null を「none」に変換します。
• D. Cloud Dataflow を使用して、サンプル ソース データ内の null 値を検索します。カスタム スクリプトを使用して、すべての null を に変換します。

正解：A

質問 # 165
彼らは、ユーザーレベルのデータへのアクセスを制御しながら、このデータの集計を他の Google Cloud プロジェクトに公開したいと考えています。
さらに、全体的なストレージ コストを最小限に抑え、他のプロジェクトの分析コストがそれらのプロジェクトに割り当てられるようにする必要があります。
彼らは何をすべきでしょうか?

• A. データセットに dataViewer Identity and Access Management (IAM) ロールを作成して、共有を有効にします。
• B. 集計結果を含む新しいデータセットとテーブルを作成して共有します。
• C. 集計結果を提供する新しいデータセットとビューを作成して共有します。
• D. 集計結果を提供する承認済みビューを作成して共有します。

正解：D

質問 # 166
......

ベストGoogle Professional-Data-Engineer日本語学習ガイドと問題集は2025年に更新されました：https://www.goshiken.com/Google/Professional-Data-Engineer-JPN-mondaishu.html