ログイン

Google Cloud Platform Professional Data Engineer 試験 - 練習セット #01-1
25問 • 5ヶ月前
  • YUSUKE
  • 通報

    問題一覧

  • 1

    質問01:シナリオ:オンデマンド課金モデルを使用してBigQueryプロジェクトを実行しており、データを取り込む変更データキャプチャ(CDC)プロセスを実行しています。CDCプロセスは、10分ごとに1GBのデータを一時テーブルに読み込み、10TBのターゲットテーブルにマージします。このプロセスはリソースを大量に消費し、大量のスキャンを伴います。予測可能なコストモデルを実装するためのオプションを検討したいと考えています。BigQuery Monitoringから収集された使用状況データに基づいてBigQuery予約を作成し、その予約をCDCプロセスに適用する必要があります。 質問:CDC プロセスに適用され、予測可能なコストを保証する BigQuery 予約を作成するにはどうすればよいでしょうか。

    プロジェクトの BigQuery 予約を作成します。

  • 2

    質問02:シナリオ:リージョン BigQuery データセットにデータを保存するためのフォールトトレラントなアーキテクチャを設計しています。目標は、過去 7 日以内に発生したテーブル破損イベントからアプリケーションを確実に復旧できるようにすることです。ソリューションのコスト効率を維持しながら、RPO(目標復旧時点)を最も低く抑えるマネージドサービスを利用したいと考えています。 質問:過去 7 日以内に発生した破損イベントから最もコスト効率の高い方法で回復するという要件を満たすには、何をすべきでしょうか。

    BigQuery のタイムトラベルを使用して履歴データにアクセスします。

  • 3

    質問03:シナリオ:都市の建設現場付近に設置された数百個のセンサーから得られる騒音レベルデータを処理するストリーミング Dataflow パイプラインを構築しています。センサーは10秒ごとに騒音レベルを測定し、レベルが70 dBAを超えた場合にのみパイプラインにデータを送信します。各センサーから30分以上データを受信した場合の平均騒音レベルを計算する必要がありますが、15分間データが受信されなかった場合はウィンドウを閉じる必要があります。 質問:提供された基準に基づいてセンサーからの平均ノイズ レベルを計算するには、どのウィンドウ戦略を使用する必要がありますか?

    15 分間のギャップ期間を持つセッション ウィンドウを使用します。

  • 4

    質問04:シナリオ:BigQuery で小売取引データを格納するデータモデルを設計しています。2 つのメインテーブル、sales_transaction_header と sales_transaction_line は、密結合された不変の関係にあります。これらのテーブルは、ロード後に変更されることはほとんどなく、クエリで頻繁に結合されます。データ分析クエリのパフォーマンスを向上させるには、sales_transaction_header テーブルと sales_transaction_line テーブルのモデルを最適化する必要があります。 質問:クエリ パフォーマンスを向上させるために、sales_transaction_header テーブルと sales_transaction_line テーブルをモデル化するには、どのようなアプローチを取る必要がありますか?

    sales_transaction_header 情報を行として保持し、sales_transaction_line 行をネストされた繰り返しフィールドとして保持する sales_transaction テーブルを作成します。

  • 5

    質問05:シナリオ:Pub/Sub から読み取り、BigQuery に書き込む Dataflow ストリーミング データ取り込みパイプラインの新バージョンを開発しました。現在本番環境で稼働している旧バージョンのパイプラインは、処理に 5 分間のウィンドウを使用しています。データの損失、不整合、処理レイテンシの 10 分以上の増加がないことを確認しながら、新バージョンのパイプラインをデプロイする必要があります。 質問:新しいパイプライン バージョンを展開するには、どのような手順を実行する必要がありますか?

    古いパイプラインをドレインしてから、新しいパイプラインを開始します。

  • 6

    質問06:シナリオ:組織では、BigQuery、Pub/Sub、そしてCompute Engine上で稼働するPostgreSQLインスタンスにデータを保存しています。複数のドメインと多様なチームがデータを使用しているため、既存のデータアセットの検出が困難になっています。開発と設定の手間を最小限に抑えながら、データの検出可能性を向上させるソリューションを構築する必要があります。 質問:これらのデータ資産全体でデータの検出可能性を向上させるには、何をすべきでしょうか?

    Data Catalog を使用すると、BigQuery データセットと Pub/Sub トピックを自動的にカタログ化できます。カスタムコネクタを使用すると、PostgreSQL テーブルを手動でカタログ化できます。

  • 7

    質問07:シナリオ:BigQueryテーブルに対して2時間ごとに集計SQL変換を実行し、その結果を別の既存のBigQueryテーブルに追加するSQLパイプラインを作成する必要があります。パイプラインは、エラーが発生した場合に再試行するように設定し、3回連続して失敗した場合はメール通知を送信する必要があります。 質問:これらの要件を満たすにはどうすればよいでしょうか?

    Cloud Composer で BigQueryInsertJobOperator を使用し、再試行パラメータを 3 に設定し、email_on_failure パラメータを true に設定します。

  • 8

    質問08:シナリオ:BigQuery でホストされている組織のデータレイクを監視しています。取り込みパイプラインは Pub/Sub からデータを読み取り、BigQuery 上のテーブルに書き込みます。取り込みパイプラインの新バージョンをデプロイした後、1 日あたりの保存データが 50% 増加しました。Pub/Sub のデータ量は変わらず、一部のテーブルでのみ 1 日あたりのパーティションデータサイズが 2 倍になりました。データ増加の原因を調査して解決する必要があります。 質問:データ増加の原因を調査して修正するにはどうすればよいでしょうか?

    1. BigQuery テーブルで、日次パーティション データ サイズが 2 倍になっている重複行がないか確認します。2. BigQuery 監査ログでジョブ ID を見つけます。3. Cloud Monitoring を使用して、特定された Dataflow ジョブの開始日時とパイプライン コードのバージョンを確認します。4. 複数のパイプラインがテーブルにデータを取り込む場合は、最新のバージョンを除くすべてのバージョンを停止します。

  • 9

    質問09:シナリオ:「customers」というBigQueryデータセットがあります。すべてのテーブルは、「gdpr」というData Catalogタグテンプレートを使用してタグ付けされます。このテンプレートには、ブール値を持つ必須フィールド「has_sensitive_data」が1つ含まれています。すべての従業員が簡単な検索を実行し、データセット内の「has_sensitive_data」フィールドがtrueまたはfalseであるテーブルを見つけることができる必要があります。ただし、「has_sensitive_data」がtrueであるテーブル内のデータは、人事(HR)グループのみが閲覧できるようにする必要があります。すべての従業員グループに、データセットに対するbigquery.metadataViewerロールとbigquery.connectionUserロールを付与します。 質問:構成のオーバーヘッドを最小限に抑えるには、次に何をすればよいでしょうか?

    公開設定で「gdpr」タグテンプレートを作成します。機密データを含むテーブルのHRグループにbigquery.dataViewerロールを割り当てます。

  • 10

    質問10:シナリオ:Cloud Composer で実行されている有向非巡回グラフ(DAG)のコードに対して CI/CD サイクルを設定しています。チームには 2 つの Cloud Composer インスタンスがあり、1 つは開発用、もう 1 つは本番環境用です。DAG のコードは Git リポジトリに保存されています。特定のタグが Git リポジトリにプッシュされたときに、DAG が Cloud Composer に自動的にデプロイされるようにしたいと考えています。 質問:タグが Git リポジトリにプッシュされたときに、DAG を Cloud Composer に自動的にデプロイするにはどうすればよいですか?

    1. Cloud Build を使用して、DAG のコードを開発インスタンスの Cloud Storage バケットにコピーし、DAG テストを実行します。2. テストに合格したら、Cloud Build を使用して、コードを本番環境インスタンスのバケットにコピーします。

  • 11

    質問11:シナリオ:Pub/Sub サブスクリプションから直接データを受信する BigQuery テーブルがあります。取り込まれたデータは現在、Google が管理する暗号鍵を使用して暗号化されています。新しい組織ポリシーでは、保存データの暗号化に一元管理された Cloud Key Management Service(Cloud KMS)プロジェクトの鍵を使用するよう義務付けられています。 質問:保存データの新しい暗号化要件を満たすには、何をすればよいですか?

    顧客管理の暗号鍵(CMEK)を使用して新しい BigQuery テーブルを作成し、古い BigQuery テーブルからデータを移行します。

  • 12

    質問12:シナリオ:Google Cloud 上に分析環境を構築し、データ サイエンティスト チームがオンプレミスの Apache Hadoop ソリューションに影響を与えずにデータを探索できるようにしました。オンプレミスの Hadoop 分散ファイル システム(HDFS)クラスタ内のデータは、Hive パーティション分割の複数列を含む、最適化された行列型(ORC)形式のファイルに保存されています。データ サイエンティスト チームは、オンプレミスの HDFS クラスタ上の Hive クエリエンジンを使用して SQL を使用したのと同様の方法でデータを探索する必要があります。そのため、最も費用対効果の高いストレージおよび処理ソリューションを選択する必要があります。 質問:データ サイエンティスト チームがコスト効率よくデータを探索できるようにするには、何をすべきでしょうか?

    ORC ファイルを Cloud Storage にコピーし、データ サイエンティスト チーム用の外部 BigQuery テーブルを作成します。

  • 13

    質問13:シナリオ:バッチ処理ジョブ用の Dataflow パイプラインを設計しています。ジョブの送信中に複数のゾーンで障害が発生した場合の影響を軽減したいと考えています。 質問:Dataflow パイプラインを送信するときに、ゾーン障害の影響を軽減するにはどうすればよいですか?

    --region フラグを使用してワーカー リージョンを指定します。

  • 14

    質問14:シナリオ:配車需要の高いエリアを特定する配車アプリ用のリアルタイムシステムを設計しています。このシステムは、複数のソースからPub/Subにデータを取り込み、処理して結果をリアルタイムダッシュボードに保存します。ドライバーの位置情報の更新は5秒ごとに行われ、乗客の予約イベントも処理されます。30秒間のウィンドウにわたってデータを集約し、2秒ごとに更新し、結果を低レイテンシのシステムに保存する必要があります。 質問:このリアルタイム システムでデータをグループ化し、集計結果を効果的に保存するにはどうすればよいでしょうか。

    Dataflow パイプラインのホッピング ウィンドウを使用してデータをグループ化し、集計されたデータを Memorystore に書き込みます。

  • 15

    質問15:シナリオ:自動車工場では、機械の測定値がGoogle CloudプロジェクトのPub/Subトピックにメッセージとして送信されています。Apache Beam SDKで作成されたDataflowストリーミングジョブは、これらのメッセージを処理し、確認応答し、DoFnインスタンスでカスタムビジネスロジックを適用し、結果をBigQueryに書き込みます。ビジネスロジックが何らかのメッセージで失敗した場合、そのメッセージがモニタリングとアラートのためにPub/Subトピックに送信されるようにします。 質問:ビジネス ロジックに失敗したメッセージが監視 Pub/Sub トピックにリダイレクトされるようにするにはどうすればよいですか?

    Dataflow の DoFn コード内の例外処理ブロックを使用して、変換に失敗したメッセージをサイド出力経由で新しい Pub/Sub トピックに push します。Cloud Monitoring を使用して、この新しいトピックの topic/num_unacked_messages_by_region 指標をモニタリングします。

  • 16

    質問16:シナリオ:チームの共有テーブルを単一のデータセットに保存し、様々なアナリストが簡単にデータにアクセスできるようにしたいと考えています。データはアナリストが読み取り可能でありながら、変更できないようにする必要があります。さらに、各アナリストが独自のテーブルを作成・保存できるワークスペースを各自に用意し、他のアナリストと共有しないようにする必要があります。 質問:アナリストのデータへのアクセスをどのように構成し、アナリストが個別のワークスペースを持つようにする必要がありますか?

    アナリストに共有データセットのBigQueryデータ閲覧者ロールを付与します。アナリストごとにデータセットを作成し、各アナリストに割り当てられたデータセットのデータセットレベルでBigQueryデータ編集者ロールを付与します。

  • 17

    質問17:シナリオ:Dataflow でストリーミング パイプラインを実行し、ホッピング ウィンドウを使用して到着データをグループ化しています。一部のデータは遅れて到着しているにもかかわらず、遅延データとしてマークされていないため、集計結果が不正確になっています。 質問:正確な集計のために、適切な期間内に遅延データを取得するにはどうすればよいでしょうか。

    ウォーターマークを使用して、予想されるデータ到着時間枠を定義します。遅れたデータは到着時に許可します。

  • 18

    質問18:シナリオ:顧客の注文データをBigtableに保存し、ガベージコレクションポリシーで30日後にデータを削除するように設定し、バージョン数を1に設定しています。データアナリストは、クエリ実行時に30日以上前の顧客データを参照することがあります。コストとオーバーヘッドを最小限に抑えながら、アナリストが30日以上前の顧客データを参照しないようにする必要があります。 質問:コストとオーバーヘッドを最小限に抑えながら、アナリストが 30 日間の期間内のデータのみを確認できるようにするには、どうすればよいでしょうか。

    クエリでタイムスタンプ範囲フィルターを使用して、特定の範囲の顧客データを取得します。

  • 19

    質問19:シナリオ:Dataflow ストリーミング ジョブを実行して、1 回限りの配信をサポートしていないメッセージバスからメッセージを読み取ります。変換を適用した後、結果は BigQuery に読み込まれます。データが 1 回限りの配信セマンティクスで BigQuery にストリーミングされるようにする必要があります。BigQuery への取り込みスループットは、1 秒あたり約 1.5 GB と想定しています。 質問:BigQuery にデータが確実に 1 回限りの配信セマンティクスでストリーミングされるようにするには、どうすればよいでしょうか?**質問には含まれていません**クォータ制限は時間とともに変更される可能性があります。クォータ制限の数値を気にする必要はありません。2024年11月現在、スループットクォータは、マルチリージョンでは3GB/秒、リージョンでは300MB/秒に更新されています。

    BigQuery ストレージ書き込み API を使用して、ターゲットの BigQuery テーブルがリージョン別であることを確認します。

  • 20

    質問20:シナリオ:Cloud Storage バケットに保存された Apache Hive パーティション分割データ用の外部テーブルを作成しました。このテーブルには多数のファイルが含まれています。このテーブルに対するクエリの実行速度が遅いため、クエリのパフォーマンスを改善したいと考えています。 質問:外部テーブルに対するクエリのパフォーマンスを向上させるには、何をすればよいですか?

    外部テーブルをBigLakeテーブルにアップグレードします。テーブルのメタデータキャッシュを有効にします。

  • 21

    質問21:シナリオ:時系列データを生成する1,000個のセンサーからなるネットワークを管理しています。各センサーは、1秒あたり1つのメトリックとタイムスタンプを生成します。現在、1TBのデータがあり、1日あたり1GBの増加が見込まれています。必要なデータアクセスは2種類あります。指定されたタイムスタンプで、特定のセンサーから特定のメトリックを、1 桁ミリ秒の平均レイテンシで取得します。結合を含む複雑な分析クエリを 1 日に 1 回データに対して実行します。 質問:両方のアクセス要件を満たすには、このデータをどのように保存すればよいですか?

    データをBigtableに保存します。センサーIDとタイムスタンプを連結し、行キーとして使用します。BigQueryへのエクスポートを毎日実行します。

  • 22

    質問22:シナリオ:BigQueryテーブルに100GBの古いデータが保存されています。このデータは、SQLを使用した分析のために年に1~2回しかアクセスされません。バックアップのため、ストレージコストを最小限に抑えながら、このデータを3年間不変状態で保存する必要があります。 質問:この目標を達成するには何をすべきでしょうか?

    1. アーカイブ ストレージ クラスを使用して、Cloud Storage バケットに BigQuery エクスポートを実行します。2. バケットにロックされた保持ポリシーを設定します。3. エクスポートされたファイルに BigQuery 外部テーブルを作成します。

  • 23

    質問23:シナリオ:オンプレミスのApache Hadoopクラスタで数千ものApache Sparkジョブを実行しています。これらのジョブをGoogle Cloudに移行したいと考えています。目標は、長期間稼働するHadoopクラスタを維持するのではなく、マネージドサービスを利用することです。スケジュールが厳しく、移行中のコード変更を最小限に抑えたいと考えています。 質問:Spark ジョブを効率的に、最小限のコード変更で移行するには、どうすればよいでしょうか?

    データを Cloud Storage に移動します。ジョブは Dataproc で実行します。

  • 24

    質問24:シナリオ:組織内の複数のチームが使用するビューを含む共有BigQueryデータセットを管理しています。マーケティングチームは、オンデマンド課金モデルを使用した場合の毎月のBigQuery分析費用の変動を懸念しています。マーケティングチームが毎月一貫したBigQuery分析費用を確保できるよう支援する必要があります。 質問: 毎月安定した BigQuery 分析費用を確保するために、マーケティング チームをどのように支援できますか?

    マーケティング チーム向けに、自動スケーリングなしで 500 スロットのベースラインを持つ BigQuery 予約を作成し、それに応じて請求します。

  • 25

    質問25:シナリオ:あなたは医療機関で働いています。この組織では、個々のデータ所有者が様々なストレージサービスを利用してデータを管理・整理しています。この分散型の体制では、データの効率的な発見と管理が困難になっています。そのため、以下の要件を満たす、費用対効果の高いソリューションを迅速に導入する必要があります。データ管理と発見、データ系統の追跡、データ品質検証。 質問:これらの要件に対応するには、どのソリューションを実装する必要がありますか?

    Dataplex を使用して、データを管理し、データ系統を追跡し、データ品質の検証を実行します。

  • Alibaba01

    Alibaba01

    YUSUKE · 60問 · 1年前

    Alibaba01

    Alibaba01

    60問 • 1年前
    YUSUKE

    Alibaba02

    Alibaba02

    YUSUKE · 60問 · 1年前

    Alibaba02

    Alibaba02

    60問 • 1年前
    YUSUKE

    Alibaba03

    Alibaba03

    YUSUKE · 60問 · 1年前

    Alibaba03

    Alibaba03

    60問 • 1年前
    YUSUKE

    Alibaba11

    Alibaba11

    YUSUKE · 60問 · 1年前

    Alibaba11

    Alibaba11

    60問 • 1年前
    YUSUKE

    Alibaba12

    Alibaba12

    YUSUKE · 60問 · 1年前

    Alibaba12

    Alibaba12

    60問 • 1年前
    YUSUKE

    2023年秋エンベデッド

    2023年秋エンベデッド

    YUSUKE · 25問 · 1年前

    2023年秋エンベデッド

    2023年秋エンベデッド

    25問 • 1年前
    YUSUKE

    2022年秋エンベデッド

    2022年秋エンベデッド

    YUSUKE · 25問 · 1年前

    2022年秋エンベデッド

    2022年秋エンベデッド

    25問 • 1年前
    YUSUKE

    2021年秋エンベデッド

    2021年秋エンベデッド

    YUSUKE · 25問 · 1年前

    2021年秋エンベデッド

    2021年秋エンベデッド

    25問 • 1年前
    YUSUKE

    2020年秋エンベデッド

    2020年秋エンベデッド

    YUSUKE · 25問 · 1年前

    2020年秋エンベデッド

    2020年秋エンベデッド

    25問 • 1年前
    YUSUKE

    2019年春エンベデッド

    2019年春エンベデッド

    YUSUKE · 25問 · 1年前

    2019年春エンベデッド

    2019年春エンベデッド

    25問 • 1年前
    YUSUKE

    2018年春エンベデッド

    2018年春エンベデッド

    YUSUKE · 25問 · 1年前

    2018年春エンベデッド

    2018年春エンベデッド

    25問 • 1年前
    YUSUKE

    2017年春エンベデッド

    2017年春エンベデッド

    YUSUKE · 25問 · 1年前

    2017年春エンベデッド

    2017年春エンベデッド

    25問 • 1年前
    YUSUKE

    2024年春システムアーキテクト

    2024年春システムアーキテクト

    YUSUKE · 25問 · 10ヶ月前

    2024年春システムアーキテクト

    2024年春システムアーキテクト

    25問 • 10ヶ月前
    YUSUKE

    2023年春システムアーキテクト

    2023年春システムアーキテクト

    YUSUKE · 25問 · 10ヶ月前

    2023年春システムアーキテクト

    2023年春システムアーキテクト

    25問 • 10ヶ月前
    YUSUKE

    2022年春システムアーキテクト

    2022年春システムアーキテクト

    YUSUKE · 25問 · 10ヶ月前

    2022年春システムアーキテクト

    2022年春システムアーキテクト

    25問 • 10ヶ月前
    YUSUKE

    2021年春システムアーキテクト

    2021年春システムアーキテクト

    YUSUKE · 25問 · 10ヶ月前

    2021年春システムアーキテクト

    2021年春システムアーキテクト

    25問 • 10ヶ月前
    YUSUKE

    2019年秋システムアーキテクト

    2019年秋システムアーキテクト

    YUSUKE · 25問 · 9ヶ月前

    2019年秋システムアーキテクト

    2019年秋システムアーキテクト

    25問 • 9ヶ月前
    YUSUKE

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #01-2

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #01-2

    YUSUKE · 25問 · 5ヶ月前

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #01-2

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #01-2

    25問 • 5ヶ月前
    YUSUKE

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #02-1

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #02-1

    YUSUKE · 25問 · 5ヶ月前

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #02-1

    Google Cloud Platform Professional Data Engineer 試験 - 練習セット #02-1

    25問 • 5ヶ月前
    YUSUKE

    問題一覧

  • 1

    質問01:シナリオ:オンデマンド課金モデルを使用してBigQueryプロジェクトを実行しており、データを取り込む変更データキャプチャ(CDC)プロセスを実行しています。CDCプロセスは、10分ごとに1GBのデータを一時テーブルに読み込み、10TBのターゲットテーブルにマージします。このプロセスはリソースを大量に消費し、大量のスキャンを伴います。予測可能なコストモデルを実装するためのオプションを検討したいと考えています。BigQuery Monitoringから収集された使用状況データに基づいてBigQuery予約を作成し、その予約をCDCプロセスに適用する必要があります。 質問:CDC プロセスに適用され、予測可能なコストを保証する BigQuery 予約を作成するにはどうすればよいでしょうか。

    プロジェクトの BigQuery 予約を作成します。

  • 2

    質問02:シナリオ:リージョン BigQuery データセットにデータを保存するためのフォールトトレラントなアーキテクチャを設計しています。目標は、過去 7 日以内に発生したテーブル破損イベントからアプリケーションを確実に復旧できるようにすることです。ソリューションのコスト効率を維持しながら、RPO(目標復旧時点)を最も低く抑えるマネージドサービスを利用したいと考えています。 質問:過去 7 日以内に発生した破損イベントから最もコスト効率の高い方法で回復するという要件を満たすには、何をすべきでしょうか。

    BigQuery のタイムトラベルを使用して履歴データにアクセスします。

  • 3

    質問03:シナリオ:都市の建設現場付近に設置された数百個のセンサーから得られる騒音レベルデータを処理するストリーミング Dataflow パイプラインを構築しています。センサーは10秒ごとに騒音レベルを測定し、レベルが70 dBAを超えた場合にのみパイプラインにデータを送信します。各センサーから30分以上データを受信した場合の平均騒音レベルを計算する必要がありますが、15分間データが受信されなかった場合はウィンドウを閉じる必要があります。 質問:提供された基準に基づいてセンサーからの平均ノイズ レベルを計算するには、どのウィンドウ戦略を使用する必要がありますか?

    15 分間のギャップ期間を持つセッション ウィンドウを使用します。

  • 4

    質問04:シナリオ:BigQuery で小売取引データを格納するデータモデルを設計しています。2 つのメインテーブル、sales_transaction_header と sales_transaction_line は、密結合された不変の関係にあります。これらのテーブルは、ロード後に変更されることはほとんどなく、クエリで頻繁に結合されます。データ分析クエリのパフォーマンスを向上させるには、sales_transaction_header テーブルと sales_transaction_line テーブルのモデルを最適化する必要があります。 質問:クエリ パフォーマンスを向上させるために、sales_transaction_header テーブルと sales_transaction_line テーブルをモデル化するには、どのようなアプローチを取る必要がありますか?

    sales_transaction_header 情報を行として保持し、sales_transaction_line 行をネストされた繰り返しフィールドとして保持する sales_transaction テーブルを作成します。

  • 5

    質問05:シナリオ:Pub/Sub から読み取り、BigQuery に書き込む Dataflow ストリーミング データ取り込みパイプラインの新バージョンを開発しました。現在本番環境で稼働している旧バージョンのパイプラインは、処理に 5 分間のウィンドウを使用しています。データの損失、不整合、処理レイテンシの 10 分以上の増加がないことを確認しながら、新バージョンのパイプラインをデプロイする必要があります。 質問:新しいパイプライン バージョンを展開するには、どのような手順を実行する必要がありますか?

    古いパイプラインをドレインしてから、新しいパイプラインを開始します。

  • 6

    質問06:シナリオ:組織では、BigQuery、Pub/Sub、そしてCompute Engine上で稼働するPostgreSQLインスタンスにデータを保存しています。複数のドメインと多様なチームがデータを使用しているため、既存のデータアセットの検出が困難になっています。開発と設定の手間を最小限に抑えながら、データの検出可能性を向上させるソリューションを構築する必要があります。 質問:これらのデータ資産全体でデータの検出可能性を向上させるには、何をすべきでしょうか?

    Data Catalog を使用すると、BigQuery データセットと Pub/Sub トピックを自動的にカタログ化できます。カスタムコネクタを使用すると、PostgreSQL テーブルを手動でカタログ化できます。

  • 7

    質問07:シナリオ:BigQueryテーブルに対して2時間ごとに集計SQL変換を実行し、その結果を別の既存のBigQueryテーブルに追加するSQLパイプラインを作成する必要があります。パイプラインは、エラーが発生した場合に再試行するように設定し、3回連続して失敗した場合はメール通知を送信する必要があります。 質問:これらの要件を満たすにはどうすればよいでしょうか?

    Cloud Composer で BigQueryInsertJobOperator を使用し、再試行パラメータを 3 に設定し、email_on_failure パラメータを true に設定します。

  • 8

    質問08:シナリオ:BigQuery でホストされている組織のデータレイクを監視しています。取り込みパイプラインは Pub/Sub からデータを読み取り、BigQuery 上のテーブルに書き込みます。取り込みパイプラインの新バージョンをデプロイした後、1 日あたりの保存データが 50% 増加しました。Pub/Sub のデータ量は変わらず、一部のテーブルでのみ 1 日あたりのパーティションデータサイズが 2 倍になりました。データ増加の原因を調査して解決する必要があります。 質問:データ増加の原因を調査して修正するにはどうすればよいでしょうか?

    1. BigQuery テーブルで、日次パーティション データ サイズが 2 倍になっている重複行がないか確認します。2. BigQuery 監査ログでジョブ ID を見つけます。3. Cloud Monitoring を使用して、特定された Dataflow ジョブの開始日時とパイプライン コードのバージョンを確認します。4. 複数のパイプラインがテーブルにデータを取り込む場合は、最新のバージョンを除くすべてのバージョンを停止します。

  • 9

    質問09:シナリオ:「customers」というBigQueryデータセットがあります。すべてのテーブルは、「gdpr」というData Catalogタグテンプレートを使用してタグ付けされます。このテンプレートには、ブール値を持つ必須フィールド「has_sensitive_data」が1つ含まれています。すべての従業員が簡単な検索を実行し、データセット内の「has_sensitive_data」フィールドがtrueまたはfalseであるテーブルを見つけることができる必要があります。ただし、「has_sensitive_data」がtrueであるテーブル内のデータは、人事(HR)グループのみが閲覧できるようにする必要があります。すべての従業員グループに、データセットに対するbigquery.metadataViewerロールとbigquery.connectionUserロールを付与します。 質問:構成のオーバーヘッドを最小限に抑えるには、次に何をすればよいでしょうか?

    公開設定で「gdpr」タグテンプレートを作成します。機密データを含むテーブルのHRグループにbigquery.dataViewerロールを割り当てます。

  • 10

    質問10:シナリオ:Cloud Composer で実行されている有向非巡回グラフ(DAG)のコードに対して CI/CD サイクルを設定しています。チームには 2 つの Cloud Composer インスタンスがあり、1 つは開発用、もう 1 つは本番環境用です。DAG のコードは Git リポジトリに保存されています。特定のタグが Git リポジトリにプッシュされたときに、DAG が Cloud Composer に自動的にデプロイされるようにしたいと考えています。 質問:タグが Git リポジトリにプッシュされたときに、DAG を Cloud Composer に自動的にデプロイするにはどうすればよいですか?

    1. Cloud Build を使用して、DAG のコードを開発インスタンスの Cloud Storage バケットにコピーし、DAG テストを実行します。2. テストに合格したら、Cloud Build を使用して、コードを本番環境インスタンスのバケットにコピーします。

  • 11

    質問11:シナリオ:Pub/Sub サブスクリプションから直接データを受信する BigQuery テーブルがあります。取り込まれたデータは現在、Google が管理する暗号鍵を使用して暗号化されています。新しい組織ポリシーでは、保存データの暗号化に一元管理された Cloud Key Management Service(Cloud KMS)プロジェクトの鍵を使用するよう義務付けられています。 質問:保存データの新しい暗号化要件を満たすには、何をすればよいですか?

    顧客管理の暗号鍵(CMEK)を使用して新しい BigQuery テーブルを作成し、古い BigQuery テーブルからデータを移行します。

  • 12

    質問12:シナリオ:Google Cloud 上に分析環境を構築し、データ サイエンティスト チームがオンプレミスの Apache Hadoop ソリューションに影響を与えずにデータを探索できるようにしました。オンプレミスの Hadoop 分散ファイル システム(HDFS)クラスタ内のデータは、Hive パーティション分割の複数列を含む、最適化された行列型(ORC)形式のファイルに保存されています。データ サイエンティスト チームは、オンプレミスの HDFS クラスタ上の Hive クエリエンジンを使用して SQL を使用したのと同様の方法でデータを探索する必要があります。そのため、最も費用対効果の高いストレージおよび処理ソリューションを選択する必要があります。 質問:データ サイエンティスト チームがコスト効率よくデータを探索できるようにするには、何をすべきでしょうか?

    ORC ファイルを Cloud Storage にコピーし、データ サイエンティスト チーム用の外部 BigQuery テーブルを作成します。

  • 13

    質問13:シナリオ:バッチ処理ジョブ用の Dataflow パイプラインを設計しています。ジョブの送信中に複数のゾーンで障害が発生した場合の影響を軽減したいと考えています。 質問:Dataflow パイプラインを送信するときに、ゾーン障害の影響を軽減するにはどうすればよいですか?

    --region フラグを使用してワーカー リージョンを指定します。

  • 14

    質問14:シナリオ:配車需要の高いエリアを特定する配車アプリ用のリアルタイムシステムを設計しています。このシステムは、複数のソースからPub/Subにデータを取り込み、処理して結果をリアルタイムダッシュボードに保存します。ドライバーの位置情報の更新は5秒ごとに行われ、乗客の予約イベントも処理されます。30秒間のウィンドウにわたってデータを集約し、2秒ごとに更新し、結果を低レイテンシのシステムに保存する必要があります。 質問:このリアルタイム システムでデータをグループ化し、集計結果を効果的に保存するにはどうすればよいでしょうか。

    Dataflow パイプラインのホッピング ウィンドウを使用してデータをグループ化し、集計されたデータを Memorystore に書き込みます。

  • 15

    質問15:シナリオ:自動車工場では、機械の測定値がGoogle CloudプロジェクトのPub/Subトピックにメッセージとして送信されています。Apache Beam SDKで作成されたDataflowストリーミングジョブは、これらのメッセージを処理し、確認応答し、DoFnインスタンスでカスタムビジネスロジックを適用し、結果をBigQueryに書き込みます。ビジネスロジックが何らかのメッセージで失敗した場合、そのメッセージがモニタリングとアラートのためにPub/Subトピックに送信されるようにします。 質問:ビジネス ロジックに失敗したメッセージが監視 Pub/Sub トピックにリダイレクトされるようにするにはどうすればよいですか?

    Dataflow の DoFn コード内の例外処理ブロックを使用して、変換に失敗したメッセージをサイド出力経由で新しい Pub/Sub トピックに push します。Cloud Monitoring を使用して、この新しいトピックの topic/num_unacked_messages_by_region 指標をモニタリングします。

  • 16

    質問16:シナリオ:チームの共有テーブルを単一のデータセットに保存し、様々なアナリストが簡単にデータにアクセスできるようにしたいと考えています。データはアナリストが読み取り可能でありながら、変更できないようにする必要があります。さらに、各アナリストが独自のテーブルを作成・保存できるワークスペースを各自に用意し、他のアナリストと共有しないようにする必要があります。 質問:アナリストのデータへのアクセスをどのように構成し、アナリストが個別のワークスペースを持つようにする必要がありますか?

    アナリストに共有データセットのBigQueryデータ閲覧者ロールを付与します。アナリストごとにデータセットを作成し、各アナリストに割り当てられたデータセットのデータセットレベルでBigQueryデータ編集者ロールを付与します。

  • 17

    質問17:シナリオ:Dataflow でストリーミング パイプラインを実行し、ホッピング ウィンドウを使用して到着データをグループ化しています。一部のデータは遅れて到着しているにもかかわらず、遅延データとしてマークされていないため、集計結果が不正確になっています。 質問:正確な集計のために、適切な期間内に遅延データを取得するにはどうすればよいでしょうか。

    ウォーターマークを使用して、予想されるデータ到着時間枠を定義します。遅れたデータは到着時に許可します。

  • 18

    質問18:シナリオ:顧客の注文データをBigtableに保存し、ガベージコレクションポリシーで30日後にデータを削除するように設定し、バージョン数を1に設定しています。データアナリストは、クエリ実行時に30日以上前の顧客データを参照することがあります。コストとオーバーヘッドを最小限に抑えながら、アナリストが30日以上前の顧客データを参照しないようにする必要があります。 質問:コストとオーバーヘッドを最小限に抑えながら、アナリストが 30 日間の期間内のデータのみを確認できるようにするには、どうすればよいでしょうか。

    クエリでタイムスタンプ範囲フィルターを使用して、特定の範囲の顧客データを取得します。

  • 19

    質問19:シナリオ:Dataflow ストリーミング ジョブを実行して、1 回限りの配信をサポートしていないメッセージバスからメッセージを読み取ります。変換を適用した後、結果は BigQuery に読み込まれます。データが 1 回限りの配信セマンティクスで BigQuery にストリーミングされるようにする必要があります。BigQuery への取り込みスループットは、1 秒あたり約 1.5 GB と想定しています。 質問:BigQuery にデータが確実に 1 回限りの配信セマンティクスでストリーミングされるようにするには、どうすればよいでしょうか?**質問には含まれていません**クォータ制限は時間とともに変更される可能性があります。クォータ制限の数値を気にする必要はありません。2024年11月現在、スループットクォータは、マルチリージョンでは3GB/秒、リージョンでは300MB/秒に更新されています。

    BigQuery ストレージ書き込み API を使用して、ターゲットの BigQuery テーブルがリージョン別であることを確認します。

  • 20

    質問20:シナリオ:Cloud Storage バケットに保存された Apache Hive パーティション分割データ用の外部テーブルを作成しました。このテーブルには多数のファイルが含まれています。このテーブルに対するクエリの実行速度が遅いため、クエリのパフォーマンスを改善したいと考えています。 質問:外部テーブルに対するクエリのパフォーマンスを向上させるには、何をすればよいですか?

    外部テーブルをBigLakeテーブルにアップグレードします。テーブルのメタデータキャッシュを有効にします。

  • 21

    質問21:シナリオ:時系列データを生成する1,000個のセンサーからなるネットワークを管理しています。各センサーは、1秒あたり1つのメトリックとタイムスタンプを生成します。現在、1TBのデータがあり、1日あたり1GBの増加が見込まれています。必要なデータアクセスは2種類あります。指定されたタイムスタンプで、特定のセンサーから特定のメトリックを、1 桁ミリ秒の平均レイテンシで取得します。結合を含む複雑な分析クエリを 1 日に 1 回データに対して実行します。 質問:両方のアクセス要件を満たすには、このデータをどのように保存すればよいですか?

    データをBigtableに保存します。センサーIDとタイムスタンプを連結し、行キーとして使用します。BigQueryへのエクスポートを毎日実行します。

  • 22

    質問22:シナリオ:BigQueryテーブルに100GBの古いデータが保存されています。このデータは、SQLを使用した分析のために年に1~2回しかアクセスされません。バックアップのため、ストレージコストを最小限に抑えながら、このデータを3年間不変状態で保存する必要があります。 質問:この目標を達成するには何をすべきでしょうか?

    1. アーカイブ ストレージ クラスを使用して、Cloud Storage バケットに BigQuery エクスポートを実行します。2. バケットにロックされた保持ポリシーを設定します。3. エクスポートされたファイルに BigQuery 外部テーブルを作成します。

  • 23

    質問23:シナリオ:オンプレミスのApache Hadoopクラスタで数千ものApache Sparkジョブを実行しています。これらのジョブをGoogle Cloudに移行したいと考えています。目標は、長期間稼働するHadoopクラスタを維持するのではなく、マネージドサービスを利用することです。スケジュールが厳しく、移行中のコード変更を最小限に抑えたいと考えています。 質問:Spark ジョブを効率的に、最小限のコード変更で移行するには、どうすればよいでしょうか?

    データを Cloud Storage に移動します。ジョブは Dataproc で実行します。

  • 24

    質問24:シナリオ:組織内の複数のチームが使用するビューを含む共有BigQueryデータセットを管理しています。マーケティングチームは、オンデマンド課金モデルを使用した場合の毎月のBigQuery分析費用の変動を懸念しています。マーケティングチームが毎月一貫したBigQuery分析費用を確保できるよう支援する必要があります。 質問: 毎月安定した BigQuery 分析費用を確保するために、マーケティング チームをどのように支援できますか?

    マーケティング チーム向けに、自動スケーリングなしで 500 スロットのベースラインを持つ BigQuery 予約を作成し、それに応じて請求します。

  • 25

    質問25:シナリオ:あなたは医療機関で働いています。この組織では、個々のデータ所有者が様々なストレージサービスを利用してデータを管理・整理しています。この分散型の体制では、データの効率的な発見と管理が困難になっています。そのため、以下の要件を満たす、費用対効果の高いソリューションを迅速に導入する必要があります。データ管理と発見、データ系統の追跡、データ品質検証。 質問:これらの要件に対応するには、どのソリューションを実装する必要がありますか?

    Dataplex を使用して、データを管理し、データ系統を追跡し、データ品質の検証を実行します。