MENU
会員登録（無料）
  1. ホーム
  2. Google Cloud認定 Professional Data Engineer WEB問題集

Google Cloud認定 Professional Data Engineer WEB問題集

WEB問題集

Question#1(Professional Data Engineer)
あなたの会社のデータプラットフォームは、アップストリームソースから予約データとユーザープロファイルデータの CSV ファイルダンプを Cloud Storage に取り込んでいます。データアナリストチームは、分析を実行するために、両方のデータセットにあるメールフィールドでこれらのデータセットを結合したいと考えています。ただし、個人を特定できる情報（PII）はアナリストがアクセスできないようにする必要があります。あなたは、アナリストのために BigQuery にロードする前に、両方のデータセットのメールフィールドを非識別化する必要があります。あなたは何をすべきですか？
ディスカッション 0

正解：B

この問題の鍵は、以下の2つの要件を同時に満たすことです。

  1. 非識別化（De-identify）： メールフィールドを個人を特定できない形に変換すること。

  2. 結合可能性（Joinability）： 非識別化された後のメールフィールド（トークン）を使用して、予約データとユーザープロファイルデータという異なるデータセットを結合できること。

🔑 選択肢の評価

  • A. Cloud DLP + マスキング:

    • マスキングは、データを「X」などの定数やランダムな値に置き換える非識別化手法です。

    • 欠点： データが非識別化されますが、元のメールアドレスが異なっていても同じマスク値になってしまうため、異なるデータセット間で結合することが不可能になります。

  • B. Cloud DLP + FFX 形式保持暗号化 (FPE):

    • FFX は、形式保持暗号化の一種です。これは、元の値（メールアドレス）を、元の形式（メールアドレスの形式や文字数）を保持したまま、一意で一貫性のあるトークンに変換します。

    • 利点：

      1. 非識別化： トークンは元の PII に戻すことが難しいため、PII が保護されます。

      2. 結合可能性： **同じ元のメールアドレスは、常に同じ一意のトークンに変換されます。**これにより、予約テーブルのトークン化されたメールと、ユーザープロファイルテーブルのトークン化されたメールを、元の情報（メールアドレス）を公開せずに結合することが可能になります。

    • これが要件を完全に満たす最良のソリューションです。

  • C & D. BigQuery 動的データマスキング:

    • 動的データマスキングは、データ自体を物理的に変更するのではなく、クエリ実行時にユーザーの権限に基づいてデータにマスクをかける手法です。元の PII データは BigQuery テーブルにそのまま残っています。

    • 欠点：

      1. 物理的な非識別化ではない： この要件は BigQuery にロードする前に非識別化することを求めているため、データマスキングはデータを取り込む際の解決策としては不適切です。

      2. 結合への影響： マスキングされたデータ（例：xxxxx@xxxx.com）は、結合には使用できますが、アナリストがテーブルを結合できるのは、同じユーザーが同じマスキングルールを持っている場合のみであり、マスキングされた値自体は結合キーとして使用するには不確かです。また、問題の核心は「PII をアクセス不可にすること」であり、動的マスキングは元のデータが残るため、厳格なセキュリティ要件に適合しない可能性があります。また、特に「マスクされたメールアドレス」が結合キーとして機能する保証はありません（例: マスキングの種類によっては異なる値になってしまう）。FFX-FPEの方が、恒久的なトークンを生成するため、結合キーとして適しています。

FFX 形式保持暗号化は、データが永続的に非識別化され、かつ結合可能であるという、すべての要件を満たすため、正解は B となります。

Question#2(Professional Data Engineer)
Cloud Storage バケットに、法的な保持（Legal Hold）の対象となる重要なドキュメントがあります。これらのドキュメントが削除または変更されないようにする必要があります。あなたは何をすべきですか？
ディスカッション 0

正解：A

この問題の要件は、Cloud Storage バケット内のドキュメントに対して「削除または変更されない」という不変性を確保することです。これは、法的な保持（Legal Hold）の要件を確実に満たすために必要です。

🔑 選択肢の評価

  • A. リテンションポリシーを設定します。そのリテンションポリシーをロックします。

    • **リテンションポリシー（Retention Policy）**は、オブジェクトを指定された期間、保持することを強制します。この期間中は、オブジェクトは削除も上書きもできません。

    • ポリシーのロックは、設定されたリテンションポリシーを永久に削除または短縮できないようにします。

    • 結論： これは WORM (Write Once, Read Many: 一度書き込んだら、指定期間は読み取り専用) の状態を確立し、法的な保持要件（削除・変更の禁止）を直接満たすための、最も適切な方法です。

  • B. リテンションポリシーを設定します。長期的なデジタル保存のためにデフォルトのストレージクラスを Archive に設定します。

    • リテンションポリシーの設定は正しい方向性ですが、ポリシーをロックしない場合、リテンション期間が満了する前にポリシーを削除したり短縮したりできる可能性があります。

    • ストレージクラスの変更はコストとアクセス速度に影響しますが、「削除または変更されない」という不変性の要件には直接関係ありません。

  • C. オブジェクトバージョニング機能を有効にします。ライフサイクルルールを追加します。

    • オブジェクトバージョニングは、オブジェクトが上書きされても以前のバージョンを保持するため、誤って上書きされた場合の復元には役立ちますが、オブジェクトの削除を防ぐものではありません（現在のバージョンを削除できます）。

    • ライフサイクルルールは、オブジェクトを削除（またはストレージクラスを変更）するためのものであり、「削除を禁止する」という要件に反します。

  • D. オブジェクトバージョニング機能を有効にします。別のリージョンにあるバケットにコピーを作成します。

    • バージョニングは不変性を保証せず、別のリージョンへのコピーはディザスタリカバリには役立ちますが、元のドキュメントが削除・変更されることを防ぐ機能ではありません。コピー側のバケットにも同様の保護設定が必要です。

リテンションポリシーのロックは、Cloud Storage において、金融、医療、訴訟などの規制や法的な保持要件を満たすために、データが確実に不変であることを保証する標準的な方法です。

Question#3(Professional Data Engineer)
あなたは、通信サービスプロバイダーの販売データを分析するために BigQuery でデータウェアハウスを設計しています。顧客、製品、サブスクリプションのデータモデルを作成する必要があります。すべての顧客、製品、サブスクリプションは毎月更新される可能性がありますが、すべてのデータの履歴レコードを保持する必要があります。あなたは、現在および履歴のレポート作成のために、視覚化レイヤーを使用することを計画しています。データモデルがシンプルで使いやすく、コスト効率が高いことを保証する必要があります。あなたは何をすべきですか？
ディスカッション 0

正解：D

要件の分析

  1. データウェアハウスのプラットフォーム: BigQuery

  2. 履歴の保持: すべての更新について履歴レコードを保持する（SCD Type 2 またはそれに類似したアプローチが必要）。

  3. 使いやすさ/シンプルさ: アナリストが簡単にクエリできること。

  4. コスト効率: BigQuery はスキャンされたデータ量に基づいて課金されるため、これは重要な考慮事項です。

🔑 選択肢の評価

  • BigQuery と非正規化（Denormalization）

    • BigQuery は、従来のOLTPデータベースとは異なり、結合（JOIN）がコストとパフォーマンスのボトルネックになりやすいアーキテクチャです。

    • 非正規化し、STRUCT（ネストされたフィールド）と ARRAY（繰り返しフィールド）を使用して関連データを1つのテーブルにまとめることが、BigQuery のベストプラクティスです。これにより、結合が減り、クエリがシンプルで高速になり、スキャンするデータ量を減らせる場合があるため、シンプルさとコスト効率の要件に合致します。

    • したがって、AとBの正規化モデルは、BigQuery の設計としては最適ではありません。

  • 履歴の保持（SCD Type 2）と追記のみ（Append-Only）

    • データを毎月更新する必要があり、すべての履歴を保持する必要がある場合、これはSCD Type 2 (Slowly Changing Dimension Type 2) の要件です。

    • BigQuery で履歴を追跡する最もシンプルでコスト効率の高い方法は、既存の行を更新するのではなく、常に新しい行を挿入（追記）することです（Append-Only）。これにより、更新や削除のオーバーヘッドがなくなり、テーブル設計が簡素化されます。

    • 履歴は、行が BigQuery に取り込まれたときのタイムスタンプ（_PARTITIONTIME やカスタムの取り込みタイムスタンプフィールド）を使用して追跡できます。

  • C vs D:

    • C（非正規化 + テーブルの更新 + スナップショット）： BigQuery で頻繁にテーブル全体を更新（上書き）したり、スナップショットを使用したりするのは、複雑で管理コストがかかり、追記のみのアプローチよりもコスト効率が悪い可能性があります。

    • D（非正規化 + 追記のみ + ネスト/繰り返しフィールド）：

      1. 非正規化 + ネスト/繰り返し: BigQuery のベストプラクティスに合致し、クエリのシンプルさ、使いやすさ、パフォーマンスを最適化します。

      2. 追記のみ: データの不変性を保証し、テーブルの更新や管理の複雑さを排除します。

      3. 取り込みタイムスタンプ: 履歴データを追跡するためのシンプルなメカニズムを提供します。

結論として、BigQuery のアーキテクチャの特性、パフォーマンス、コスト、および履歴保持の要件を考慮すると、D のアプローチが最適です。

Question#4(Professional Data Engineer)
あなたは Dataflow でバッチパイプラインをデプロイしています。このパイプラインは Cloud Storage からデータを読み取り、データを変換し、その後 BigQuery に書き込みます。セキュリティチームは、すべての Compute Engine インスタンスが内部 IP アドレスのみを使用し、外部 IP アドレスを使用しないことを要求する組織の制約を Google Cloud で有効にしました。あなたは何をすべきですか？
ディスカッション 0

正解：D

🎯 要件の分析

  1. 環境: Dataflow バッチパイプライン（Compute Engine ワーカーを使用）。

  2. データソース/シンク: Cloud Storage および BigQuery。

  3. 制約: Compute Engine インスタンス（Dataflow ワーカー）は内部 IP アドレスのみを使用し、外部 IP アドレスを持たない。

  4. 課題: 外部 IP を持たないワーカーが、外部サービス（Cloud Storage や BigQuery は、技術的には Google のパブリックサービスエンドポイントを使用）に安全にアクセスできるようにする方法を見つけること。

🔑 選択肢の評価

  • Dataflow ワーカーと外部サービスのアクセス:

    • Dataflow ワーカーが外部 IP アドレスを持っていない場合、通常のインターネット経由で Google の API やサービス（Cloud Storage、BigQuery）にアクセスすることはできません。

  • Private Google Access (PGA):

    • Private Google Accessは、外部 IP アドレスを持たない Compute Engine インスタンスが、Google Cloud のサービス（Cloud Storage や BigQuery など）の外部 API にアクセスできるようにする VPC ネットワーク機能です。これは、トラフィックを VPC ネットワークから Google のネットワークエッジにルーティングし、そのトラフィックは Google のインフラストラクチャ内にとどまります。

    • 結論： 制約（内部 IP のみ）を満たしつつ、パイプラインの機能（Google サービスへのアクセス）を有効にするために、Private Google Access を有効にすることが必須かつ最も直接的な解決策です。

  • A. ネットワークタグ:

    • ネットワークタグはファイアウォールルールやルートの設定に使用されます。アクセス権限を付与するものではありませんし、外部 IP なしで外部サービスにアクセスする機能を提供するものでもありません。

  • B. ファイアウォールルール:

    • ファイアウォールルールは、VPC ネットワーク内のトラフィックを制御します。外部 IP を持たないインスタンスが外部サービスに到達する方法を変えるものではありません。また、Cloud Storage や BigQuery のエンドポイントは一般的に許可されている必要がありますが、問題の核心は IP アドレスの制約を克服することです。

  • C. VPC Service Controls (VPC SC):

    • VPC SC は、データ漏洩（データ流出）を防ぐためのセキュリティ境界（ペリメーター）を作成します。これは、データのアクセスを許可する方法ではなく、むしろアクセスを制限する方法です。

    • 外部 IP なしでサービスにアクセスするための基本的な接続メカニズム（PGA）を置き換えるものではありません。PGA は接続要件を満たすために必要であり、VPC SC は追加のセキュリティ層です。この問題の要求は、単に「アクセスできるようにする」ことであり、PGA で十分です。

したがって、組織の制約（外部 IP なし）を満たしつつ、必要な接続性（Google サービスへのアクセス）を確保するためには、サブネットワークで Private Google Access を有効にすることが唯一の解決策です。

Question#5(Professional Data Engineer)
あなたは、Streaming Engine と水平オートスケーリング（Horizontal Autoscaling）を有効にして Dataflow ストリーミングパイプラインを実行しています。最大ワーカー数を 1000 に設定しました。パイプラインの入力は Cloud Storage からの通知を含む Pub/Sub メッセージです。パイプラインの変換の 1 つが CSV ファイルを読み取り、CSV の行ごとに要素を出力します。ジョブのパフォーマンスは低く、パイプラインはわずか 10 のワーカーしか使用しておらず、オートスケーラーが追加のワーカーをスピンアップしていないことに気付きました。パフォーマンスを向上させるために何をすべきですか？
ディスカッション 0

正解：B

🎯 要件の分析

  1. 問題: Dataflow ストリーミングジョブのパフォーマンスが低い。

  2. 設定: 水平オートスケーリングが有効（最大 1000 ワーカー）。

  3. 現象: 実際にはわずか 10 ワーカーしか使用しておらず、オートスケーラーがスケールアウトしていない。

  4. ボトルネックの場所: CSV ファイルを読み取り、行ごとに要素を出力する変換。

🔑 現象の分析

Dataflow のオートスケーラーが設定された最大値（1000）までスケールアウトしない主な理由は、並列処理のボトルネックがあるためです。

このパイプラインでは、Cloud Storage の通知（Pub/Sub メッセージ）から処理が始まります。通知メッセージの数や、そのメッセージが処理される最初のステップが非常に少ない場合、パイプラインの初期段階で並列処理が制限されます。

問題文にある変換「CSV ファイルを読み取り、行ごとに要素を出力する」は、前のステップの出力（Cloud Storage 通知）に**結合（フュージョン）**されています。

フュージョンが発生すると、前のステップ（Pub/Sub からの読み取り）の並列処理の度合いが、次のステップ（CSV 読み取り）の並列処理の度合いを決定します。もし、Pub/Sub からの入力が少数のワーカー（この例では 10 ワーカー）によって処理されている場合、その後の処理も同じワーカーにフュージョンされ、ジョブ全体が 10 ワーカーに制限されてしまいます。

💡 解決策

  • B. パイプラインコードを変更し、フュージョンを防ぐために Reshuffle ステップを導入します。

    • Dataflow は、可能な限り多くの変換をフュージョン（結合）して、ワーカー間でのデータ転送のオーバーヘッドを削減しようとします。しかし、これにより並列処理が制限されることがあります。

    • Reshuffle 変換は、Dataflow にデータの再シャッフルを強制し、意図的にフュージョンを防ぎます。CSV ファイルを読み取った直後、またはそれ以前のステップで Reshuffle を挿入することで、大量の CSV 行データ（要素）の後にパイプラインが強制的にデータを再分配し、オートスケーラーが処理負荷に基づいて追加のワーカーをスピンアップできるようになります。これが、パフォーマンスを向上させるための適切なコーディング上の解決策です。

  • A & D. 垂直スケーリング / Dataflow Prime:

    • 垂直スケーリング（ワーカーを大きくする）は、ワーカー数が少なすぎるという根本的な並列処理のボトルネックを解決しません。ワーカーは 1000 個まで使えるはずです。

  • C. 最大ワーカー数を増やす:

    • 最大ワーカー数はすでに 1000 と非常に大きく設定されています。オートスケーラーが 10 個からスケールアップしないのは、最大値が低いためではなく、処理がボトルネックによって並列化できていないためです。

結論として、オートスケーラーを機能させるには、Reshuffle ステップを導入して、データがワーカー間で効果的に分散されるようにすることが必要です。

次のページ