模擬問題集一覧

GCP-PDE 模擬問題集(練習問題)

Professional Data Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

GCP-PDE(Professional Data Engineer)の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

GCP-PDE の出題範囲(カバーしている分野)

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はGCP-PDE の学習ガイドにまとめています。

GCP-PDE の無料練習問題(15 問・解説つき)

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1データの取り込みと処理データの取り込みと処理
問題
あなたは Dataflow を使用して、Pub/Sub から取得したユーザーのウェブサイト クリック アクティビティを分析するストリーミング データ パイプラインを構築しています。ユーザーのサイト訪問ごとのクリック数を計算する必要があります。サイト訪問は、特定のユーザーについて、一定期間のアクティビティとそれに続く 30 分間の非アクティブ期間として定義されます。どうすればよいですか?

選択肢と解説

  • 1
    30 分のウィンドウでタンブリング ウィンドウを使用する。
  • 2
    30 分のウィンドウと 1 分の期間でホッピング ウィンドウを使用する。
  • 3
    30 分のウィンドウと 30 分の期間でホッピング ウィンドウを使用する。
  • ✓
    30 分のギャップ期間でセッション ウィンドウを使用する。

解説

【正解】D

【0からの解説】
①前提知識:ストリーミング データは終わりがないため、集計(件数のカウントなど)をするには、データを時間で区切る「ウィンドウ」を定義します。Dataflow(Apache Beam)の代表的なウィンドウは次の 3 種類です。
・タンブリング ウィンドウ(Beam では固定ウィンドウ):例えば 30 分ごとに、重ならない固定の区間でデータを区切る。
・ホッピング ウィンドウ(Beam ではスライディング ウィンドウ):ウィンドウの長さ(例: 30 分)と開始間隔=期間(例: 1 分)を指定し、重なり合うウィンドウを一定間隔で作る。移動平均などに使う。
・セッション ウィンドウ:キー(ここではユーザー)ごとに、データの到着が途切れた時間(ギャップ期間)が指定値を超えたところでウィンドウを閉じる。ウィンドウの長さは活動の続き方によって動的に変わる。
②要件の整理:「サイト訪問」は「特定のユーザーについて、活動が続いた後に 30 分間活動がなければ終わる」と定義されています。つまり区切りは固定の時刻ではなく、ユーザーごとの「非アクティブな時間」で決まります。
③正解の理由:セッション ウィンドウをギャップ期間 30 分で設定し、ユーザー ID をキーとしてクリックを集計すれば、ユーザーごとに「30 分以上の空白で区切られた一連の活動」が 1 つのウィンドウになり、訪問ごとのクリック数をそのまま数えられます。訪問の定義そのものをウィンドウで表現できるのはセッション ウィンドウだけです。

【誤りの選択肢】
A:タンブリング ウィンドウは時計上の固定の区間(例: 10:00〜10:30)で区切るため、1 回の訪問が区間の境界をまたぐと 2 つに分割され、逆に 30 分以上空いた別々の訪問が同じ区間にまとめられることもあります。非アクティブ時間による区切りを表現できません。
B:長さ 30 分・期間 1 分のホッピング ウィンドウは 1 分ごとに重なり合うウィンドウを作るため、同じクリックが最大 30 個のウィンドウで重複して数えられます。移動集計には向きますが、訪問単位のクリック数にはなりません。
C:長さ 30 分・期間 30 分のホッピング ウィンドウは、重なりがないので実質的にタンブリング ウィンドウと同じです。A と同様に固定の区間で区切るだけで、ユーザーごとの非アクティブ時間に基づく訪問の区切りにはなりません。

【参考】
ストリーミング パイプライン | Cloud Dataflow
Apache Beam のプログラミング モデル | Cloud Dataflow
この問題のページを開く →
問題 2データ処理システムの設計データ処理システムの設計
問題
あなたは、医療データと財務データを含む新しい BigQuery テーブルのデータ ガバナンス戦略を定義しています。臨床研究者が財務情報を含まない患者の医療データにアクセスできるようにし、一方で経理チームには最小限の患者識別子とともに財務データのみにアクセスできるようにする、スケーラブルなソリューションが必要です。どうすればよいですか?

選択肢と解説

  • ✓
    IAM 権限を使用して、BigQuery テーブルに列レベルのセキュリティ ポリシーを実装する。
  • 2
    個人を特定できる情報(PII)、財務データ、匿名化された医療データ用に別々のテーブルを作成する。IAM 権限を使用して各テーブルへのアクセスを制御する。
  • 3
    IAM 権限を使用して、BigQuery テーブルに行レベルのセキュリティ ポリシーを実装する。
  • 4
    承認済みのデータのみを公開する承認済みビューを持つ、別々のデータセットを作成する。

解説

【正解】A

【0からの解説】
①前提知識:BigQuery では、テーブル単位・データセット単位の IAM に加えて、より細かいアクセス制御が用意されています。
・列レベルのセキュリティ:「ポリシータグ」を階層構造(タクソノミー)で定義し、テーブルの列に付けます。そのポリシータグに対して「きめ細かい読み取り(Fine-Grained Reader)」ロールを持つユーザーやグループだけが、その列の値を読み取れます。同じタグを多数のテーブルの列に付ければ、アクセス方針を一元的に適用できます(権限のないユーザーにマスクした値を返す動的データ マスキングも組み合わせられます)。
・行レベルのセキュリティ:行アクセス ポリシーにより、条件に合う「行」だけを特定のユーザーに見せる仕組みです。
②要件の整理:(1) 1 つのテーブルに医療データ列と財務データ列が同居する、(2) 臨床研究者には医療データの列のみ(財務列は不可)、(3) 経理チームには財務データの列と最小限の患者識別子の列のみ、(4) 「スケーラブル」=データ量や利用者、テーブルが増えても管理が破綻しない方法。どの患者の行も両チームが参照する前提なので、分けたいのは「行」ではなく「列(属性)」です。
③正解の理由:列レベルのセキュリティなら、例えば「医療」「財務」「患者識別子(機微)」といったポリシータグを列に付け、臨床研究者グループには医療タグ、経理グループには財務タグと必要最小限の識別子列のタグだけを許可する、という形で 1 つのテーブルのまま要件を満たせます。データを複製せず、新しいテーブルや列が増えてもタグを付けるだけで同じ方針が適用されるため、スケーラブルで管理しやすいガバナンスになります。

【誤りの選択肢】
B:用途別にテーブルを分割すると、同じデータを複数のテーブルに分けて持つための ETL と同期処理が必要になり、不整合のリスクや運用負荷が増えます。利用部門や組み合わせが増えるたびにテーブルが増えるため、スケーラブルではありません。
C:行レベルのセキュリティは「どの行を見せるか」を制御する機能です。今回の要件は同じ患者の行の中で医療の列と財務の列を出し分けることなので、行のフィルタでは実現できません。
D:承認済みビューでも、ビューごとに公開する列を選べば似たことは可能です。しかしチームごとにデータセットとビューを作成・維持する必要があり、テーブルのスキーマ変更や利用部門の追加のたびにビューを修正しなければなりません。列単位の制御はポリシータグによる列レベルのセキュリティで一元管理するほうがスケーラブルで、ビューの管理の手間が増える分だけ A に劣ります。

【参考】
安全な BigQuery データ ウェアハウスにデータをインポートする
列へのアクセスを制御する | Dataform
この問題のページを開く →
問題 3データの保存データの保存
問題
あなたは Google Cloud 上に、ウェブサイト、モバイルアプリ、ソーシャル メディアなどのさまざまなソースから得られる膨大な量の顧客とのやり取り(インタラクション)データを保存するデータレイクを設計しています。さまざまな形式で届くこのデータを一貫してカタログ化し、データ アナリストが簡単に検出して利用できるようにする必要があります。また、ダウンストリームのアプリケーションがデータを利用する前に、基本的なデータ品質チェックと変換を実行したいと考えています。自動化されたマネージドなデータ ガバナンス ソリューションが必要です。どうすればよいですか?

選択肢と解説

  • 1
    Cloud Storage を中央リポジトリとして使用する。Vertex AI を使用してデータを分類・処理し、データ品質チェックを実行する。
  • 2
    すべてのデータを BigQuery に直接ストリーミングし、そこで自動的にカタログ化とガバナンスが行われるようにする。
  • ✓
    Cloud Storage と BigQuery をリポジトリとして使用する。メタデータの検出、データ品質チェック、変換には Dataplex Universal Catalog を使用する。
  • 4
    Cloud Storage を中央リポジトリとして使用する。Cloud Run functions の関数を使用して、データのカタログ化と変換、データ品質チェックを実行する。

解説

【正解】C

【0からの解説】
①前提知識:データレイクでは、形式の異なる生データ(JSON、CSV、Parquet、画像など)を Cloud Storage に、分析用に整えたデータを BigQuery に置く構成が一般的です。ただしデータを置くだけでは「どこに何があるか」「信頼できるデータか」が分からず、使われないデータの山になりがちです。そこで必要になるのがデータ ガバナンスの仕組みです。Dataplex Universal Catalog(現 Knowledge Catalog)は、Google Cloud のマネージドなデータ ガバナンス サービスで、次の機能を備えます。
・Cloud Storage と BigQuery のデータの自動検出とカタログ化(Cloud Storage 上のファイルからスキーマを推定してテーブルとして登録し、メタデータを一元管理)
・検索、ビジネス用語集、メタデータの拡充によるデータの見つけやすさの向上
・データ プロファイリングと自動データ品質スキャン(ルールを定義して品質を継続的に検証)
・データリネージ(データの由来と変換の追跡)
・レイク/ゾーンにひも付くタスク(サーバーレスの Spark)によるデータ処理・変換
②要件の整理:(1) 多様なソース・形式のデータを一貫してカタログ化、(2) アナリストが簡単に検出・利用できる、(3) 下流で使う前に基本的な品質チェックと変換、(4) 「自動化されたマネージドな」ガバナンス ソリューション。
③正解の理由:Cloud Storage(生データ)と BigQuery(整形済みデータ)をリポジトリにし、Dataplex Universal Catalog(現 Knowledge Catalog)でメタデータの自動検出・カタログ化・品質チェック・変換までを担わせれば、自前のコードを書かずにマネージド サービスで要件をすべて満たせます。

【誤りの選択肢】
A:Vertex AI(現 Gemini Enterprise Agent Platform)は機械学習モデルの開発・運用のためのプラットフォームで、データのカタログ化やデータ品質管理のためのガバナンス サービスではありません。目的に合わない製品を使うことになり、結局ほぼ自前で作り込むことになります。
B:BigQuery にはテーブルのメタデータ管理機能がありますが、さまざまな形式のデータをすべて BigQuery にストリーミングすれば「自動的にカタログ化され、ガバナンスされる」わけではありません。データ品質チェックや変換の仕組みも別途必要です。また画像などの非構造化データを含むレイク全体をストリーミングで取り込むのは費用と手間がかかり、データレイクの設計としても不適切です。
D:Cloud Run functions で独自にカタログ化・変換・品質チェックを実装すると、コードの開発・保守、メタデータを保持する仕組み、検索 UI などをすべて自前で用意する必要があります。「自動化されたマネージドなデータ ガバナンス ソリューション」という要件に反し、運用負荷が大きくなります。

【参考】
Knowledge Catalog の概要
Cloud Storage データを検出してカタログ化する | Knowledge Catalog
データ品質のプロファイリングと検証 | Knowledge Catalog
この問題のページを開く →
問題 4データ ワークロードの保守と自動化データ ワークロードの保守と自動化
問題
Cloud Storage バケットからデータを読み取り、変換したデータを BigQuery テーブルに書き込む、ステートフルなデータ処理パイプラインを設計しています。このパイプラインは高可用性で、us-central1 リージョン内のゾーン障害に対して耐性がなければなりません。ゾーン障害の発生時に中断を最小限に抑えるように Dataflow パイプラインを構成する必要があります。どうすればよいですか?

選択肢と解説

  • ✓
    --region=us-central1 パラメータを指定して Dataflow ジョブを起動する。
  • 2
    Dataflow ジョブを us-central1 内の単一ゾーンにデプロイし、状態の保存にリージョン永続ディスクを使用するように構成する。
  • 3
    Dataflow ジョブを us-central1 内の単一ゾーンにデプロイし、状態の保存にマルチリージョンの Cloud Storage バケットを使用する。
  • 4
    --zone=us-central1a パラメータを指定して Dataflow ジョブを起動する。

解説

【正解】A

【0からの解説】
①前提知識
・Dataflow のジョブは「リージョン」を指定して実行します。リージョンはジョブのメタデータ管理やワーカーの配置先を決めるもので、ゾーンを指定しなければ Dataflow がワーカーの配置を自動で決めます。
・Dataflow Shuffle(バッチジョブの既定)や Streaming Engine を使うジョブには「リージョン配置」が適用され、ワーカー プールはリージョン内の利用可能なすべてのゾーンを使います。ゾーン障害が起きても、ワーカーが他のゾーンで再作成されるため、ジョブは処理を継続できます。シャッフルや状態(ステート)はワーカーのディスクではなく、Dataflow のマネージドなバックエンド サービス側で管理されます。

②問題文の要件の整理
・Cloud Storage → 変換 → BigQuery のステートフルなパイプライン
・高可用性、us-central1 内のゾーン障害への耐性
・ゾーン障害時の中断を最小限にする

③正解の理由
--region=us-central1 だけを指定してゾーンを固定しなければ、Dataflow がリージョン内の複数ゾーンにワーカーを配置・再配置でき、単一ゾーンの障害の影響を受けにくくなります。Dataflow のドキュメントでも、可用性の観点から --worker_zone / --workerZone で単一ゾーンに固定することは推奨されず、--region と Streaming Engine または Dataflow Shuffle を組み合わせて使うよう案内されています。状態の管理は Dataflow のバックエンドが担うため、利用者が状態の保存先を用意する必要もありません。

【誤りの選択肢】
B:単一ゾーンにデプロイすると、そのゾーンの障害でワーカーがすべて停止するため要件を満たしません。また Dataflow には、パイプラインの状態をリージョン永続ディスクに保存するような構成オプションはなく、状態は Dataflow Shuffle / Streaming Engine などのサービス側で管理されます。
C:同じく単一ゾーン配置が単一障害点になります。Cloud Storage バケットはステージングや一時ファイルの場所として指定するものであり、パイプラインの状態の保存先として構成するものではありません。ゾーン障害でワーカーが止まる問題も解決しません。
D:ゾーンを指定するとワーカーがそのゾーンに固定され、ゾーン障害時に処理が中断します。なお、正しいゾーン名の形式は us-central1-a であり、zone オプションは非推奨(Apache Beam SDK 2.17.0 以前向け)です。

【参考】
Dataflow のリージョン
バッチジョブの Dataflow Shuffle
この問題のページを開く →
問題 5分析のためのデータの準備と利用分析のためのデータの準備と利用
問題
あなたはチームの BigQuery インスタンスを監視し、最適化しています。大規模な JOIN 操作を使用する特定の日次レポートが、一貫して遅いことに気づきました。JOIN 内の潜在的なパフォーマンスのボトルネックを特定するために、クエリの実行計画をできるだけ迅速に調べたいと考えています。どうすればよいですか?

選択肢と解説

  • 1
    bq query --dry_run コマンドを使用して、読み取られる推定バイト数を確認し、クエリ構文を確認する。
  • 2
    INFORMATION_SCHEMA.JOBS_BY_PROJECT ビューに対して job_ID でフィルタするクエリを実行し、total_bytes_processed を分析する。
  • 3
    Cloud Logging で BigQuery の監査ログを確認する。
  • ✓
    BigQuery の Query History ビューを活用し、実行グラフを分析する。

解説

【正解】D

【0からの解説】
①前提知識:BigQuery はクエリを受け取ると、それを複数の「ステージ」(読み取り・集計・結合・シャッフルなど)から成る実行計画(クエリプラン)に分解し、多数のワーカー(スロット)で並列に処理します。各ステージにどれだけ時間がかかったか、どれだけの行が入出力されたか、待機・読み取り・計算・書き込みのどこに時間を使ったか、といった情報はジョブの統計情報として記録されます。Google Cloud コンソールでは、この情報を「クエリ実行グラフ」として図示でき、ジョブ履歴(個人の履歴/プロジェクトの履歴、元問題でいう Query History)から対象ジョブを開き「実行グラフ」タブを選ぶだけで、ステージ間のつながりと各ステージの詳細(ステップ、スロット時間、シャッフル量など)を確認できます。さらに、スロットの競合、シャッフル割り当て不足、データの偏り(スキュー)といった「パフォーマンス分析情報(クエリ インサイト)」も表示されます。
②要件と制約語の整理:(1) 大規模な JOIN を含むレポートが遅い、(2) 「実行計画」を調べて JOIN 内のボトルネックを特定したい、(3) 「できるだけ迅速に」=追加の仕組みやクエリを用意せず、すぐに見られる方法が望ましい。
③正解の理由:ジョブ履歴から実行グラフを開けば、既に実行済みの日次レポートのジョブについて、JOIN ステージでの入出力行数の急増(行の爆発)、特定ワーカーへの偏り、シャッフルの大きさなどを、追加の準備なしでその場で視覚的に確認できます。実行計画そのものを最短で確認できるのはこの方法です。

【誤りの選択肢】
A:--dry_run(ドライラン)はクエリを実際には実行せず、構文チェックと処理予定バイト数の見積もりを返すだけです。実行されないためステージごとの所要時間や JOIN での行の増減といった実行時の情報は得られず、JOIN のボトルネックは特定できません。
B:INFORMATION_SCHEMA.JOBS_BY_PROJECT はジョブのメタデータを SQL で調べられる便利なビューですが、選択肢の内容は total_bytes_processed(処理したバイト数の合計)を見るだけです。ジョブ全体の合計値ではどのステージ、どの JOIN が遅いのかは分からず、実行計画の分析にはなりません。クエリを書いて結果を解釈する手間もかかり、「できるだけ迅速に」という条件にも劣ります。
C:監査ログ(Cloud Audit Logs)は「誰が・いつ・何をしたか」を記録するためのもので、ログにジョブ統計の一部が含まれることはあっても、実行計画を見やすく分析する用途ではありません。ログを検索して読み解く手間がかかり、実行グラフを開くより明らかに遅く非効率です。

【参考】
クエリプランとタイムライン
クエリのパフォーマンス分析情報を取得する
この問題のページを開く →
問題 6データの取り込みと処理データの取り込みと処理
問題
あなたは、コンテンツのレコメンデーションをパーソナライズするために、ユーザーのクリックストリーム データを分析しています。データは継続的に到着し、セッション化(時間枠内でユーザーごとにクリックをグループ化すること)やユーザー アクティビティの集計などの変換を含めて、低レイテンシで処理する必要があります。毎秒数百万件のイベントを処理でき、遅れて到着するデータに対しても耐性のある、スケーラブルなソリューションを特定する必要があります。どうすればよいですか?

選択肢と解説

  • 1
    取り込みと保存に Firebase Realtime Database を使用し、処理と分析に Cloud Run functions を使用する。
  • 2
    取り込みと変換に Cloud Data Fusion を使用し、保存と分析に Cloud SQL を使用する。
  • ✓
    取り込みに Pub/Sub、処理に Apache Beam を使用した Dataflow、保存と分析に BigQuery を使用する。
  • 4
    取り込みに Cloud Storage、バッチ処理に Apache Spark を使用した Dataproc、保存と分析に BigQuery を使用する。

解説

【正解】C

【0からの解説】
①前提知識
・Pub/Sub:フルマネージドなメッセージング サービスです。送信側(パブリッシャー)と受信側(サブスクライバー)を疎結合にし、毎秒数百万メッセージ規模まで自動でスケールします。
・Dataflow:Apache Beam で書いたパイプラインを実行するフルマネージドなサービスです。ストリーミング処理では、ウィンドウ処理(固定・スライディング・セッション ウィンドウ)、ウォーターマーク(イベント時刻の観点で「どこまでデータが揃ったか」の推定)、トリガー、許容遅延(allowed lateness)といった仕組みで、遅れて到着したデータを正しい時間枠に反映できます。ワーカーは自動でスケールします。
・BigQuery:サーバーレスなデータ ウェアハウスです。ストリーミング書き込みしたデータを取り込み直後から SQL で分析できます。

②問題文の要件の整理
・データは継続的に到着し、低レイテンシで処理する(=ストリーミング処理)
・セッション化(ユーザーごとのクリックを時間枠でまとめる)と集計
・毎秒数百万件のイベントに対応できるスケーラビリティ
・遅延データへの耐性

③正解の理由
Pub/Sub → Dataflow → BigQuery は、Google Cloud におけるストリーミング分析の標準的な構成です。セッション化は Apache Beam の「セッション ウィンドウ」(ユーザーごとに、一定時間クリックが途切れるまでを 1 セッションとする)でそのまま実装でき、ウォーターマークと許容遅延・トリガーにより遅延データも正しいセッションや集計に反映されます。Pub/Sub と Dataflow はいずれも自動スケールするため毎秒数百万件にも対応でき、結果を BigQuery に書き込めばすぐに分析に使えます。

【誤りの選択肢】
A:Firebase Realtime Database は、モバイル / ウェブ アプリのクライアント間でデータをリアルタイムに同期するための JSON データベースで、大量イベントの取り込み基盤や分析用ストレージではありません(1 データベースあたりの同時接続数や書き込み数に上限があります)。Cloud Run functions(旧 Cloud Functions)はイベント単位のステートレスな処理で、ウィンドウやウォーターマーク、状態管理の仕組みがないため、セッション化や遅延データの扱いを自前で実装する必要があります。
B:Cloud Data Fusion は GUI でパイプラインを構築するマネージドなデータ統合サービスで、実行基盤は Dataproc(現 Managed Service for Apache Spark)のクラスタです。主にバッチ ETL 向けで、毎秒数百万件を低レイテンシで処理し遅延データを扱う用途では Dataflow に劣ります。また Cloud SQL はトランザクション処理(OLTP)向けのリレーショナル データベースで、毎秒数百万件の書き込みや大規模な分析にはスケールしません。
D:Cloud Storage にファイルを溜めてから Dataproc(現 Managed Service for Apache Spark)でバッチ処理する構成は、処理がファイル到着後の定期実行になるため「継続的に到着するデータを低レイテンシで処理する」要件を満たしません。クラスタ管理の運用負荷もあります。

【参考】
Pub/Sub とは
ストリーミング パイプライン | Cloud Dataflow
Dataflow の概要
この問題のページを開く →
問題 7データ処理システムの設計データ処理システムの設計
問題
あなたの会社では、大規模なオンプレミスのデータ ウェアハウスを BigQuery に移行することを計画しています。データは現在、独自のベンダー固有の形式で保存されています。このデータを BigQuery へバッチ移行する必要があります。どうすればよいですか?

選択肢と解説

  • 1
    bq コマンドライン ツールを使用して、オンプレミスのデータ ウェアハウスからデータを直接読み込む。
  • ✓
    データを CSV ファイルにエクスポートし、ファイルを Cloud Storage にアップロードしてから、BigQuery に読み込む。
  • 3
    BigQuery Data Transfer Service を使用する。
  • 4
    Datastream を使用してデータをリアルタイムで複製する。

解説

【正解】B

【0からの解説】
①前提知識
・BigQuery にデータを入れる最も基本的な方法は「バッチ読み込み(load ジョブ)」です。Cloud Storage(またはローカル)に置いたファイルを、BigQuery のテーブルに一括で取り込みます。読み込みに対応するファイル形式は CSV、改行区切り JSON、Avro、Parquet、ORC、Datastore / Firestore のエクスポートなど、オープンで汎用的な形式です。特定ベンダーのデータ ウェアハウス(DWH)が内部で使う独自形式のファイルは、そのままでは BigQuery が解釈できません。
・BigQuery Data Transfer Service(DTS)は、あらかじめ用意されたコネクタがあるソース(Teradata、Amazon Redshift、Snowflake などの特定の DWH / データベース、Cloud Storage、Amazon S3、SaaS など)から、マネージドにデータを転送するサービスです。
・Datastream は、データベースの変更データ キャプチャ(CDC)を使ってサーバーレスに継続レプリケーションを行うサービスです。

②問題文の要件の整理
・大規模なオンプレミス DWH を BigQuery へ移行する
・データは「独自のベンダー固有の形式」で保存されている(BigQuery が直接読めない、特定コネクタも前提にできない)
・「バッチ移行」である(一括移行。リアルタイム同期は求められていない)

③正解の理由
Google の移行ガイド「スキーマとデータ転送の概要」では、どのデータ ウェアハウスでもスキーマとデータをファイルとして抽出でき、多くのプラットフォームは Avro や CSV のようなベンダー非依存の形式にエクスポートするツールを備えている、と説明しています。そして、DTS で特定の DWH(Amazon Redshift / Teradata)から直接読み込む場合を除き、抽出したファイルを Cloud Storage のバケットにアップロードしてから BigQuery に読み込む、という流れを標準手順としています。
独自形式のままでは BigQuery が読めないため、①ソース DWH のエクスポート機能で汎用形式(CSV)に変換 → ②Cloud Storage にステージング → ③BigQuery の load ジョブで一括読み込み、という B がどのベンダーにも適用できるバッチ移行の基本パターンです。なお実務では、スキーマ(型情報)を保持できる Avro・Parquet・ORC が CSV よりも推奨されますが、選択肢の中で「独自形式 → 汎用形式への変換 → Cloud Storage 経由で読み込み」という正しい手順を示しているのは B だけです。

【誤りの選択肢】
A:bq コマンドライン ツールは BigQuery を操作する CLI で、bq load で読み込めるのは対応形式のファイルだけです。オンプレミスの DWH に接続してデータを引き出す機能はなく、ベンダー独自の形式を解釈することもできません。
C:DTS は、コネクタが用意された特定のソースからの転送を自動化するサービスで、任意のベンダー独自形式を読み取れるわけではありません。問題文のソースは特定されていない「独自形式」であり、DTS を指定するだけでは移行できません(DTS の Cloud Storage 転送を使う場合でも、まず対応形式のファイルにエクスポートする必要があり、それは B の手順そのものです)。
D:Datastream は CDC による継続的なリアルタイム レプリケーションのサービスで、対応ソースは主に Oracle・MySQL・PostgreSQL・SQL Server などの運用データベースです。要件は「バッチ移行」であり、独自形式の DWH はそもそも対応ソースではありません。

【参考】
スキーマとデータ転送の概要
データのバッチ読み込み
BigQuery Data Transfer Service とは
この問題のページを開く →
問題 8データの保存データの保存
問題
大量のクリックストリーム イベントデータを格納する BigQuery テーブルを設計しています。データ アナリスト チームは、特定のイベント日付の範囲でクエリを実行し、ユーザー ID(UUID)でフィルタすることが最も多くなります。クエリの費用とパフォーマンスのためにテーブル構造を最適化したいと考えています。どうすればよいですか?

選択肢と解説

  • 1
    ユーザー ID 列でテーブルをパーティション分割し、イベント日付列でテーブルをクラスタ化する。
  • 2
    取り込み時間パーティション分割テーブルを作成し、ユーザー ID 列でクラスタ化する。
  • 3
    イベント日付列とユーザー ID 列の両方でテーブルをクラスタ化する。
  • ✓
    イベント日付列でテーブルをパーティション分割し、ユーザー ID 列でテーブルをクラスタ化する。

解説

【正解】D

【0からの解説】
①前提知識
・パーティション分割:テーブルを日付・時刻列などでセグメント(パーティション)に分け、WHERE 句で絞り込んだパーティションだけを読み取る仕組みです(パーティション プルーニング)。オンデマンド料金はスキャンしたバイト数に課金されるため、読み取るパーティションが減れば費用が直接下がり、クエリ実行前に処理バイト数を正確に見積もることもできます。パーティション分割に使えるのは、時間単位列(DATE / TIMESTAMP / DATETIME)、取り込み時間、整数範囲(INTEGER)の 3 種類だけです。
・クラスタリング:指定した列(最大 4 列)の値でテーブル内(パーティション内)のデータを並べ替えて格納し、その列でフィルタしたときに不要なブロックを読み飛ばす仕組みです。値の種類が非常に多い(カーディナリティが高い)列に向いています。

②問題文の要件の整理
・最も多いクエリ:イベント日付の範囲での絞り込み + ユーザー ID(UUID)でのフィルタ
・目的:クエリの費用とパフォーマンスの最適化

③正解の理由
日付範囲の絞り込みはイベント日付列のパーティション分割で粗く(確実に)行い、各パーティションの中をユーザー ID でクラスタ化して細かく絞り込む、というのが BigQuery の定石です。「時間軸はパーティション、高カーディナリティ列はクラスタ」と覚えておきましょう。パーティションとクラスタを組み合わせることで、日付範囲外のパーティションはまったく読まず、範囲内でも該当ユーザーのブロックだけを読むため、費用と性能の両方が最適化されます。

【誤りの選択肢】
A:UUID は STRING 型で値の種類が膨大です。BigQuery のパーティション分割は時間単位列・取り込み時間・整数範囲にしか対応しておらず、UUID 列ではパーティション分割できません(仮にできたとしても、パーティション数の上限をすぐに超えます)。また、最も多い条件である日付範囲をクラスタ列にすると、パーティションのような確実なスキャン範囲の限定ができません。
B:取り込み時間パーティションは「BigQuery にデータが取り込まれた時刻」で分割されます。アナリストが絞り込むのはイベントの発生日付であり、遅延到着やバックフィルで取り込み日時とイベント日付がずれると、イベント日付の範囲でパーティション プルーニングが効きません。
C:クラスタリングだけでもブロックの読み飛ばしで性能は改善しますが、パーティション分割のような確実なスキャン範囲の限定やクエリ前の正確な費用見積もりができません。日付範囲で頻繁に絞り込む本ケースでは、日付でパーティション分割する D の方が費用削減効果が大きく、パーティション単位の有効期限設定などの管理もしやすくなります。

【参考】
パーティション分割テーブルの概要
クラスタ化テーブルの概要
この問題のページを開く →
問題 9データ ワークロードの保守と自動化データ ワークロードの保守と自動化
問題
あなたは BigQuery を使用しており、日次の売上数量を格納したテーブルを含むリージョン データセットがあります。このテーブルは 1 日に複数回更新されます。リージョン障害が発生した場合に備えて、目標復旧時点(RPO)を 24 時間未満にして売上テーブルを保護しつつ、コストを最小限に抑える必要があります。どうすればよいですか?

選択肢と解説

  • ✓
    Cloud Storage のデュアルリージョンまたはマルチリージョンのバケットへの、テーブルの日次エクスポートをスケジュールする。
  • 2
    バックアップ リージョンへのデータセットの日次コピーをスケジュールする。
  • 3
    テーブルの BigQuery スナップショットを日次でスケジュールする。
  • 4
    ETL ジョブを変更して、現在のリージョンと別のバックアップ リージョンの両方にデータを読み込む。

解説

【正解】A

【0からの解説】
① 前提知識
・リージョン データセット:特定のリージョン(例:asia-northeast1)にデータが保存されるデータセットです。リージョン内の複数ゾーンには冗長化されますが、BigQuery は別の地理的リージョンへのバックアップやレプリカを自動では作成しません。リージョン全体が物理的に失われるような障害に備えるには、利用者がデータを別の場所にバックアップする必要があります。
・目標復旧時点(RPO):障害時に「どの時点までのデータを失ってもよいか」を表す指標です。1 日 1 回バックアップする場合、最悪で直近約 24 時間分のデータが失われます。
・エクスポート(抽出ジョブ):BigQuery のテーブルを Cloud Storage にファイル(Avro、Parquet、CSV など)として書き出す機能です。既定では共有スロット プールで処理され、BigQuery 側の処理料金はかからず、主な費用は Cloud Storage の保存料金です。圧縮形式や安価なストレージ クラスを選ぶことで、保存料金をさらに抑えられます。
・Cloud Storage のデュアルリージョン/マルチリージョン バケットは、データを地理的に離れた複数のリージョンに冗長保存するため、1 つのリージョンが失われてもデータは残ります。

② 要件と制約語の整理
・守る対象は売上テーブル(データセット全体ではない)。
・リージョン障害からの保護が必要で、RPO は 24 時間以内でよい(リアルタイムの複製までは不要)。
・制約語:コストを最小限に抑える。

③ 正解が要件をどう満たすか
BigQuery の信頼性に関するドキュメントの障害計画の例でも、BigQuery のデータを抽出ジョブで毎晩 Cloud Storage にエクスポートしてバックアップとし、その場合の RPO は 24 時間(最悪で 24 時間前のバックアップ)になると説明されています。売上テーブルだけを毎日デュアルリージョン/マルチリージョンのバケットへエクスポートすれば、リージョン障害時にも別リージョンにデータが残り、RPO の要件を満たします。エクスポート処理は無料で、必要なテーブルだけを圧縮ファイルとして保存できるため、選択肢の中で最も低コストです(復旧時はファイルを BigQuery に読み込み直すため復旧時間は長めになりますが、問題文では RTO は求められていません)。

【誤りの選択肢】
B:データセットの日次コピーでもリージョン障害に備えられますが、必要な売上テーブル以外も含めたデータセット全体を複製するうえ、リージョン間のデータ転送料金と、バックアップ リージョンでの BigQuery ストレージ料金が発生します。必要なテーブルだけを圧縮して Cloud Storage に置く A より高コストです。
C:BigQuery のテーブル スナップショットは、元のテーブルと同じリージョン内に作られるメタデータ中心のバックアップで、誤削除やデータ破損からの復旧(タイムトラベル期間の 7 日を超える保持)には有効ですが、データの耐久性を高めるものではありません。リージョン自体が失われればスナップショットも失われるため、リージョン障害への対策になりません。
D:2 つのリージョンに同時に読み込めば RPO はほぼゼロにできますが、ETL の改修、読み込み処理の二重化、両リージョンでのストレージ料金、整合性の監視などコストと運用負荷が大きく増えます。「RPO 24 時間未満」という要件に対しては過剰で、「コストを最小限」に反します。

【参考】
信頼性について
テーブルデータを Cloud Storage にエクスポートする
テーブル スナップショットの概要
この問題のページを開く →
問題 10どのサービスを使用すべきですか?データの取り込みと処理
問題
複数の Google Cloud サービスを使用するパイプラインをオーケストレートする必要があります。バッチの Dataflow ジョブを実行し、次に BigQuery のクエリジョブ、続いて Vertex AI のバッチ予測を実行します。ロジックは順次実行です。運用のオーバーヘッドが最小限の、軽量でサーバーレスなオーケストレーション ソリューションを使用したいと考えています。どのサービスを使用すべきですか?

選択肢と解説

  • 1
    Cloud Composer を選択する。
  • 2
    Compute Engine と cron を選択する。
  • 3
    Dataproc と Apache Oozie を選択する。
  • ✓
    Cloud Workflows を選択する。

解説

【正解】D

【0からの解説】
①前提知識
・Workflows:YAML / JSON でステップを定義し、Google Cloud のサービスや HTTP API を順番に(または並列に)呼び出すサーバーレスなオーケストレーション サービスです。コネクタを使うと、Dataflow・BigQuery・Vertex AI(現 Gemini Enterprise Agent Platform)などのジョブを起動し、完了するまで待機する処理(長時間実行オペレーションのポーリング)を組み込みで扱えます。料金は実行したステップ数に応じた従量課金で、待機中のインフラ費用はかかりません。
・Cloud Composer(現 Managed Service for Apache Airflow):Apache Airflow のマネージド環境です。DAG による複雑な依存関係、リトライ、バックフィルなどに強い一方、環境(スケジューラ・ワーカー・Web サーバー・データベース)を常時プロビジョニングするため、パイプラインが動いていない間も費用がかかります。

②問題文の要件の整理
・Dataflow バッチ → BigQuery クエリ → Vertex AI バッチ予測 の順次実行
・軽量でサーバーレス
・運用のオーバーヘッドを最小限にする

③正解の理由
Google のドキュメント「サービス オーケストレーション用の Workflows または Managed Airflow を選択する」では、Workflows はサーバーレスでゼロまでスケールし、実行ステップ単位の課金、ミリ秒単位の低いレイテンシを持つ軽量な選択肢とされています。今回は 3 つのジョブを順番に実行するだけの単純なロジックで、Airflow の高度な DAG 機能は不要です。Workflows ならコネクタで各ジョブの起動と完了待ちを順に記述するだけで済み、Cloud Scheduler からの定期実行も簡単に設定できます。

【誤りの選択肢】
A:Cloud Composer(現 Managed Service for Apache Airflow)でも実現は可能ですが、環境を常時プロビジョニングするため費用と運用(環境のサイズ設定・アップグレード・DAG の管理)がかかります。単純な順次処理に対しては重く、「軽量でサーバーレス」という要件に合いません。
B:Compute Engine の VM を自分で管理(OS のパッチ適用・可用性・監視)する必要があり、サーバーレスではありません。cron は起動時刻を決めるだけなので、各ステップの完了待ち・エラー処理・リトライをすべて自作する必要があります。
C:Dataproc(現 Managed Service for Apache Spark)のクラスタ上で Hadoop 用のワークフロー スケジューラ Apache Oozie を動かす構成は、クラスタの運用が必要でサーバーレスではありません。Oozie は標準のオプション コンポーネントにも含まれておらず、自前で導入する必要があります。そもそも Hadoop ジョブ向けのツールで、Google Cloud の各サービスをまたぐオーケストレーションには不向きです。

【参考】
サービス オーケストレーション用の Workflows または Managed Airflow を選択する
コネクタを理解する | Workflows
ワークフローの概要 | Workflows
この問題のページを開く →
問題 11分析のためのデータの準備と利用分析のためのデータの準備と利用
問題
あなたの小売企業は、BigQuery の分析費用を懸念しています。同社では、店舗 ID とリアルタイムの売上高について同じ集計を必要とするクエリを複数実行しています。分析費用を最小限に抑え、より速く結果を返す最適なソリューションを実装する必要があります。どうすればよいですか?

選択肢と解説

  • 1
    繰り返し使われる集計を含む新しいテーブルを CSV ファイルから作成し、他のクエリがそれを参照して処理を高速化できるようにする。
  • ✓
    繰り返しの計算を最小限に抑えるために、マテリアライズド ビューを作成する。
  • 3
    主キーと外部キーによる結合の高速化を使用して、ライブデータに対するクエリの結合を高速化する。
  • 4
    パーティショニングを活用して、読み取るバイト数を最小限に抑える。

解説

【正解】B

【0からの解説】
①前提知識:BigQuery のマテリアライズド ビューは、集計などのクエリ結果をあらかじめ計算して保存しておく「事前計算済みのビュー」です。ベーステーブルが更新されると BigQuery がバックグラウンドで自動的に増分更新します。また、前回の更新以降にベーステーブルへ追加された変更(差分)があっても、保存済みの結果と差分を組み合わせて常に最新の結果を返します。さらに「スマート チューニング」により、ベーステーブルに対して書かれたクエリでも、マテリアライズド ビューで答えられる部分は自動的にビューを使うよう書き換えられます。事前計算済みの小さな結果を読むため、スキャン量(オンデマンド料金の課金対象)とスロット消費が減り、応答も速くなります。
②要件の整理:(1) 複数のクエリが「店舗 ID ごとのリアルタイムの売上高」という同じ集計を繰り返している、(2) 分析費用の最小化、(3) より速い結果、(4) 「リアルタイム」なので最新データを反映し続ける必要がある。
③正解の理由:同じ集計をマテリアライズド ビューにしておけば、毎回生データを全件スキャンして集計し直す必要がなくなり、費用と時間の両方を削減できます。自動更新と差分の組み合わせにより最新性も保たれるため、リアルタイムの売上高という要件にも合致します。繰り返し計算される集計の最適化として最も適した機能です。

【誤りの選択肢】
A:CSV ファイルから作った集計テーブルはその時点のスナップショットにすぎず、売上が変わるたびに手作業や独自のジョブで作り直す必要があります。リアルタイムの売上高を反映できず、更新の運用負荷もかかります。
C:BigQuery の主キー・外部キー制約(強制はされない制約)は、クエリ オプティマイザが不要な結合を省略したり結合順序を最適化したりするための情報として使われます。結合の効率化には役立ちますが、同じ集計を毎回計算し直すこと自体は避けられず、繰り返し計算による費用を抑える根本的な対策にはなりません。
D:パーティショニングは日付などで分割したテーブルの一部だけを読むことで読み取りバイト数を減らす有効な手法ですが、同じ集計の繰り返し計算はなくなりません。リアルタイムの集計では最新のパーティションを毎回集計し直すことになり、事前計算した結果を再利用できるマテリアライズド ビューほどの削減効果は得られません。

【参考】
マテリアライズド(実体化)ビューの概要
マテリアライズド ビューを使用する
主キーと外部キーを使用する
この問題のページを開く →
問題 12データ処理システムの設計データ処理システムの設計
問題
あなたの組織は、非常に機密性の高い個人データを BigQuery に保存しており、厳格なデータ プライバシー規制を遵守する必要があります。従業員が組織を離れるたびに、機密データの値が確実に読み取り不能になるようにする必要があります。どうすればよいですか?

選択肢と解説

  • 1
    ポリシータグを使用した列レベルのアクセス制御を使用し、従業員が組織を離れたときに閲覧者の権限を取り消す。
  • 2
    動的データ マスキングを使用し、従業員が組織を離れたときに閲覧者の権限を取り消す。
  • 3
    顧客管理の暗号鍵(CMEK)を使用し、従業員が組織を離れたときに鍵を削除する。
  • ✓
    AEAD 関数を使用し、従業員が組織を離れたときに鍵を削除する。

解説

【正解】D

【0からの解説】
①前提知識
・AEAD 暗号化関数:AEAD(Authenticated Encryption with Associated Data、認証付き暗号)は、データの機密性と改ざん検知を同時に提供する暗号方式です。BigQuery では SQL の中で値単位に暗号化・復号できる関数群が用意されています(KEYS.NEW_KEYSET / KEYS.NEW_WRAPPED_KEYSET で鍵のセット(キーセット)を作成し、AEAD.ENCRYPT で暗号化、AEAD.DECRYPT_STRING / AEAD.DECRYPT_BYTES で復号)。人(行)ごとに別々のキーセットを使い分けられるのが特徴です。
・暗号シュレッディング(crypto-deletion / crypto-shredding):暗号鍵を削除することで、その鍵で暗号化されたデータを読み取り不能にする手法です。データ本体を探して消さなくても、コピーやバックアップに残ったデータも含めて復号できなくなります。
・CMEK(顧客管理の暗号鍵):Cloud KMS の鍵で、テーブルやデータセット単位の保存時の暗号化を制御する仕組みです。
・ポリシータグによる列レベルのアクセス制御・動的データ マスキング:誰が列の平文を見られるかを IAM で制御する仕組みで、保存されているデータ自体は暗号化されないまま(BigQuery 標準の保存時暗号化のみ)です。

②問題文の要件の整理
・非常に機密性の高い個人データ、厳格なプライバシー規制
・従業員が離職したら、機密データの「値」を読み取り不能にする(=誰に権限があるかではなく、値そのものを復元できなくする)

③正解の理由
従業員ごとにキーセットを作成して鍵用のテーブルに保持し、その従業員の機密値を AEAD.ENCRYPT で暗号化して保存しておきます。従業員が離職したら、その従業員のキーセット(鍵テーブルの該当行)を削除するだけで、その従業員のデータはどのテーブルやコピーにあっても復号できなくなります(暗号シュレッディング)。他の従業員のデータには影響しません。Google のドキュメントでも、顧客ごとに異なる鍵で暗号化しておけば、複数のテーブルに散在するデータを暗号削除できる、という AEAD の代表的なユースケースが紹介されています。キーセットを Cloud KMS の鍵でラップ(エンベロープ暗号化)すれば、鍵そのものの保護も強化できます。

【誤りの選択肢】
A:ポリシータグによる列レベルのアクセス制御は「誰がその列を読めるか」を制御するだけで、データは読み取り可能な状態のまま残ります。離職者の権限を取り消しても、権限を持つ他のユーザーやエクスポート / コピー先では値をそのまま読めるため、「値を読み取り不能にする」要件を満たしません。
B:動的データ マスキングもポリシータグに基づいて、クエリ結果の表示をユーザーごとにマスクする機能で、保存されている値自体は変わりません。権限の取り消しはアクセス制御にすぎず、値を読み取り不能にはしません。
C:CMEK はテーブルやデータセット単位で保存データを保護する鍵です。鍵を破棄するとその鍵で保護されたテーブル全体が読めなくなり、在籍中の他の従業員のデータまで失われます。従業員ごとに別のテーブルと鍵を用意するのは現実的ではなく、粒度が粗すぎます(Cloud KMS の鍵バージョンの破棄には既定で 30 日の破棄予定期間もあります)。

【参考】
エンベロープ暗号化 | Cloud Key Management Service
顧客管理の暗号鍵(CMEK) | Cloud Key Management Service
鍵バージョンの破棄と復元 | Cloud Key Management Service
この問題のページを開く →
問題 13履歴データ用のバケットの費用をどのように管理すべきですか?データの保存
問題
あなたの Cloud Storage データレイクには、未加工データ、処理済みデータ、履歴データが別々のバケットに保存されています。2 年より古いデータはほとんどアクセスされず、すべてのデータは 7 年を超えて保持してはなりません。ストレージ費用の増加を懸念しています。履歴データ用のバケットの費用をどのように管理すべきですか?

選択肢と解説

  • 1
    Compute Engine インスタンス上でスクリプトを作成し、Cloud Scheduler で毎日トリガーして、すべてのオブジェクトをスキャンし、7 年より古いものを削除する。
  • ✓
    オブジェクトのライフサイクル管理ルールを構成して、2 年より古いオブジェクトを Archive ストレージ クラスに移行し、最終的に 7 年経過後に削除する。
  • 3
    Cloud Storage バケットで Autoclass 機能を有効にし、Coldline および Archive ストレージ クラスへのオブジェクト移行のオプトインを選択する。
  • 4
    ストレージ費用の低い別のリージョンにバケットを複製し、7 年経過後にオブジェクトを削除するオブジェクトのライフサイクル管理ルールを構成する。

解説

【正解】B

【0からの解説】
①前提知識
・ストレージ クラス:Cloud Storage には Standard / Nearline(最小保存期間 30 日)/ Coldline(90 日)/ Archive(365 日)があります。冷たいクラスほど保存料金は安く、取り出し料金は高くなります。Archive は年 1 回未満しかアクセスしないデータ向けで、保存料金が最も安いクラスです。
・オブジェクトのライフサイクル管理:バケットにルール(条件:作成からの日数を表す age など/アクション:SetStorageClass でクラス変更、Delete で削除)を設定すると、Cloud Storage が条件を満たしたオブジェクトに自動でアクションを実行します。サーバーやスクリプトは不要です。ライフサイクルによるクラス変更自体には取り出し料金や早期削除料金はかかりません。
・Autoclass:オブジェクトの「最後にアクセスされてからの日数」に基づいてクラスを自動調整する機能です(30 日アクセスなしで Nearline、終端クラスを Archive にすると 90 日で Coldline、365 日で Archive)。読み取られると Standard に戻ります。管理手数料がかかり、オブジェクトの削除は行いません。

②問題文の要件の整理
・2 年より古いデータはほとんどアクセスされない → 安価なクラスへ移したい
・7 年を超えて保持してはならない → 7 年経過したら確実に削除する
・ストレージ費用を抑えたい(運用の手間もかけたくない)

③正解の理由
ライフサイクル ルールを 2 つ設定するだけで要件をすべて満たせます(例:age 730 日で SetStorageClass → ARCHIVE、age 2555 日で Delete)。作成日からの経過日数で判定するため、「2 年で冷える」「7 年で削除」という年齢ベースの要件にそのまま対応します。Archive の最小保存期間 365 日に対し、2 年目から 7 年目まで約 5 年間保存されるため早期削除料金も発生しません。マネージド機能なので追加のコンピューティングやコードも不要です。

【誤りの選択肢】
A:自前のスクリプトでも削除はできますが、VM の運用・費用、全オブジェクトのスキャン(一覧取得操作の課金)、失敗時の取りこぼしへの対処など運用負荷が大きくなります。さらに削除しか行っておらず、2 年超のデータを安価なクラスへ移す費用最適化が抜けています。同じことはライフサイクル管理でノーコードで実現できます。
C:Autoclass はオブジェクトを削除しないため、「7 年を超えて保持しない」要件を満たしません。また判定基準は作成からの年齢ではなく最終アクセスからの日数で、アクセスされると Standard に戻り、管理手数料もかかります。アクセス パターンが予測できないデータ向けの機能であり、「2 年でほぼアクセスされなくなる」と分かっている今回は、年齢ベースのライフサイクル ルールの方が適切です(なお、Autoclass を有効にしたバケットでは SetStorageClass アクションのライフサイクル ルールを併用できません)。
D:別リージョンへの複製はデータを二重に保存することになり、ネットワーク転送料金も加わってかえって費用が増えます。さらにストレージ クラスの変更を行っていないため、2 年超のデータの保存費用は下がりません。

【参考】
オブジェクトのライフサイクル管理 | Cloud Storage
ストレージ クラス | Cloud Storage
Autoclass | Cloud Storage
この問題のページを開く →
問題 14データ ワークロードの保守と自動化データ ワークロードの保守と自動化
問題
BigQuery 上でホストされている組織のデータレイクを監視しています。取り込みパイプラインは Pub/Sub からデータを読み取り、BigQuery のテーブルに書き込みます。取り込みパイプラインの新しいバージョンがデプロイされた後、1 日あたりの保存データ量が 50% 増加しました。Pub/Sub のデータ量は変わっておらず、一部のテーブルのみ日次パーティションのデータサイズが 2 倍になっていました。データ増加の原因を調査して修正する必要があります。 どうすればよいですか?

選択肢と解説

  • 1
    1. 日次パーティションのデータサイズが 2 倍になった BigQuery テーブルで重複行を確認する。2. 影響を受けたテーブルの重複を排除する SQL ジョブを毎日実行するようスケジュールする。3. 他のテーブルで同じことが発生した場合に再利用できるよう、重複排除スクリプトを他の運用チームと共有する。
  • 2
    1. デプロイされたパイプラインのコードエラーを確認する。2. パイプラインの BigQuery シンクへの複数回の書き込みを確認する。3. 新しいパイプラインのリリース当日の Cloud Logging のエラーを確認する。4. エラーがなければ、タイムトラベルを使用して BigQuery テーブルを前回のリリース前の内容に復元する。
  • ✓
    1. 日次パーティションのデータサイズが 2 倍になった BigQuery テーブルで重複行を確認する。2. BigQuery 監査ログを確認してジョブ ID を特定する。3. Cloud Monitoring を使用して、特定した Dataflow ジョブがいつ開始されたかと、パイプラインのコード バージョンを確認する。4. 複数のパイプラインが 1 つのテーブルにデータを取り込んでいる場合は、最新のもの以外のすべてのバージョンを停止する。
  • 4
    1. 前回のデプロイをロールバックする。2. タイムトラベルを使用して BigQuery テーブルを前回のリリース前の内容に復元する。3. Dataflow ジョブを再起動し、サブスクリプションをリリース時のタイムスタンプにシークしてメッセージを再生する。

解説

【正解】C

【0からの解説】
①前提知識
・Dataflow の Pub/Sub 読み取り:Dataflow のパイプラインが Pub/Sub のトピックを指定して読み取る場合、コネクタはパイプラインごとに専用の一時サブスクリプションを作成します。そのため、旧バージョンと新バージョンのジョブが同時に動いていると、それぞれがすべてのメッセージを受け取り、同じデータを 2 回書き込むことになります。新バージョンを「更新(update)」ではなく別ジョブとして起動し、旧ジョブを停止(ドレイン)し忘れると、このような二重書き込みが起こります。
・Cloud Audit Logs(監査ログ):誰が・どのジョブが・いつ BigQuery のテーブルに書き込んだかなどの操作を記録します。テーブルへの書き込み元のジョブや呼び出し元を特定するのに使えます。
・Cloud Monitoring:Dataflow ジョブの指標(開始時刻、スループット、要素数など)を確認でき、どのジョブがいつから動いているかを把握できます。
・パイプラインの停止:ストリーミング ジョブは「ドレイン」で停止すると、取り込み済みのデータを処理し終えてから停止するため、データを失わずに止められます。

②要件と制約の整理
(1) 新しいパイプラインのデプロイ後に保存量が 50% 増えた。
(2) Pub/Sub の入力量は変わっていないのに、一部のテーブルだけ日次パーティションがちょうど 2 倍になった。
(3) 求められているのは原因の調査と修正。
→ 入力が同じで出力がちょうど 2 倍なので、同じメッセージがそのテーブルに 2 回書き込まれている、つまり旧バージョンと新バージョンのパイプラインが並行して同じテーブルに書き込んでいる可能性が高いと推測できます。

③正解(C)が要件を満たす理由
C は、まず影響テーブルの重複行を確認して「二重書き込み」という仮説を検証し、次に BigQuery の監査ログから書き込んでいるジョブ ID を特定し、Cloud Monitoring でそれらの Dataflow ジョブの開始時刻とコード バージョンを突き合わせて、同じテーブルに複数バージョンのパイプラインが書き込んでいることを確かめます。最後に最新バージョン以外を停止することで、原因そのもの(停止し忘れた旧パイプライン)を取り除きます。証拠に基づいて根本原因を特定し、再発しない形で修正する手順になっており、(3) の「調査して修正する」に最も合致します。

【誤りの選択肢】
A:重複行の確認は良いのですが、その後は毎日重複排除の SQL を実行するという対症療法に終わり、旧パイプラインが動き続けるため重複データは毎日発生し続けます。重複排除クエリの料金と運用の手間も増え、原因の修正になっていません。
B:二重稼働しているパイプラインはエラーを出さないため、コードエラーや Cloud Logging のエラーを探しても原因が見つからない可能性が高いです。そのうえ「エラーがなければ」タイムトラベルでリリース前の状態に戻すと、リリース後に取り込んだ正当なデータまで失われます。原因のパイプラインも止めていないため、重複は再び発生します。
D:原因を調査せずにロールバックしており、「調査して修正する」要件を満たしません。ロールバックしても並行して動いている旧ジョブが残っていれば問題は解決しません。また、タイムトラベルの期間は最大 7 日で、シークによる再生にはメッセージの保持設定が必要なため、確実に元に戻せるとは限らず、作業のリスクと手間が大きくなります。

【参考】
Pub/Sub から Dataflow に読み取る
Cloud Audit Logs の概要 | Cloud Logging
実行中の Dataflow パイプラインを停止する
この問題のページを開く →
問題 15データの取り込みと処理データの取り込みと処理
問題
あなたのデータ サイエンス チームは、Cloud Storage バケット内に Apache Parquet 形式で保存されている大規模なデータセットに対して、インタラクティブな SQL クエリを実行する必要があります。チームは Apache Hive に精通しており、既存の HiveQL クエリを活用したいと考えています。チームが Cloud Storage 内のデータに対してインタラクティブな HiveQL クエリを直接実行できる環境を提供する必要があります。運用のオーバーヘッドは最小限に抑えたいと考えています。どうすればよいですか?

選択肢と解説

  • 1
    Compute Engine インスタンスのグループに、Apache Hadoop と Hive のクラスタを手動でインストールして構成する。
  • 2
    Parquet データを BigQuery のネイティブ テーブルに読み込み、BigQuery Connector for Hive を使用してクエリを実行する。
  • 3
    Parquet ファイルを参照する外部テーブル定義を使用して BigQuery を構成する。
  • ✓
    Hive サービスを有効にした Dataproc クラスタをデプロイする。

解説

【正解】D

【0からの解説】
①前提知識
・Dataproc(現 Managed Service for Apache Spark):Apache Spark・Hadoop・Hive・Pig などのオープンソースのデータ処理エコシステムを実行するマネージド サービスです。クラスタの作成・スケーリング・削除は平均 90 秒以内で完了し、インストールや構成の手間はほとんどありません。Hive はクラスタ イメージに含まれる標準コンポーネントです。
・Cloud Storage コネクタ:Dataproc のクラスタには既定でインストールされており、Hadoop / Hive から gs:// のパスを HDFS と同じように読み書きできます。そのため Hive の外部テーブルの LOCATION に Cloud Storage のパスを指定すれば、Parquet ファイルを HDFS にコピーせずに直接クエリできます。
・BigQuery の外部テーブル:BigQuery から Cloud Storage 上のファイルを GoogleSQL でクエリする仕組みです。

②問題文の要件の整理
・Cloud Storage 上の Parquet データに対するインタラクティブな SQL クエリ
・既存の HiveQL クエリをそのまま活用したい
・Cloud Storage 内のデータを直接クエリする
・運用のオーバーヘッドを最小限にする

③正解の理由
Dataproc なら、Hive を含むマネージドな Hadoop 環境を短時間で用意でき、既存の HiveQL をそのまま Cloud Storage 上の Parquet に対して実行できます。ソフトウェアのインストールや構成は Google が管理するため運用負荷が小さく、使わないときはクラスタを削除したりオートスケーリングを使ったりして費用も抑えられます。要件(HiveQL・Cloud Storage を直接参照・運用負荷最小)をすべて満たすのは D です。

【誤りの選択肢】
A:Compute Engine 上への手動構築でも動作はしますが、Hadoop / Hive のインストール・構成・パッチ適用・スケーリング・障害対応をすべて自分で行う必要があり、「運用のオーバーヘッドを最小限に」という要件に反します。
B:データを BigQuery のネイティブ テーブルに読み込むと、「Cloud Storage 内のデータに直接クエリする」という要件に反し、余分なデータ移動と二重保存が発生します。さらに Hive-BigQuery コネクタは Hive(Hadoop クラスタ)上で動くコネクタなので、結局は Hive の実行環境が別途必要になります。
C:BigQuery の外部テーブルを使えば Cloud Storage 上の Parquet を直接クエリできますが、クエリ言語は GoogleSQL であり HiveQL ではありません。既存の HiveQL クエリを活用するという要件を満たさず、クエリの書き換えが必要になります。

【参考】
クラスタの Managed Service for Apache Spark の概要
Cloud Storage コネクタ | Managed Service for Apache Spark
Hive-BigQuery コネクタ | Managed Service for Apache Spark
この問題のページを開く →

GCP-PDE 模擬問題集についてよくある質問

GCP-PDE の練習問題は無料で試せますか?

はい。GCP-PDE は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

GCP-PDE は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。