Google PDE: データエンジニアリングのアーキテクチャと設計 — 学習ガイド

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

こちらの一部です： Google Professional Data Engineer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudにおけるデータエンジニアリングのアーキテクチャと設計は、ドメイン境界、処理パターン、およびサービス能力のバランスを取り、信頼性、拡張性、コスト効率に優れたデータプラットフォームを提供します。効果的な設計では、ストレージ、コンピューティング、オーケストレーション、サービングを独立して拡張可能にし、ドメインが相互運用できるようにコントラクトをコード化し、測定可能なサービスレベル目標（SLO）を用いてリスクを早期に検証します。このセクションでは、代表的なアーキテクチャスタイル（データメッシュ、レイク、ウェアハウス、レイクハウス、オペレーショナルストア）、処理モード（バッチ、マイクロバッチ、ストリーミング、イベントドリブン、ラムダ）、およびスケーラビリティ、レイテンシ、可用性、一貫性、コスト間のトレードオフを要約します。また、リージョンおよびマルチクラウドへの配置、スキーマの進化、エンドツーエンドのデータライフサイクル、ワークロードベースのサービス選択、Google Cloudに合わせたリスク駆動型の検証プラクティスについても説明します。

アーキテクチャパラダイムと処理パターン

• データメッシュ、ドメイン、データプロダクト:
  • ドメインチームが、明確な所有権、SLO、アクセスポリシー、ドキュメントを持つ「データプロダクト」を公開できるようにします。Dataplexを使用してドメインを定義し、メタデータを管理し、BigQueryとCloud Storageにわたって一貫したポリシーを適用します。プロダクトは、Pub/SubスキーマやBigQueryテーブルスキーマを介して強制されるコントラクトを持つBigQueryデータセット、Pub/Subトピック、またはCloud Storageパスを公開することがあります。
• データレイク:
  • ライフサイクルとバージョニングを備えたCloud Storage内の生データ、オープンフォーマットストレージ（Parquet/Avro）。異種混合のワークロード（Dataproc上のSpark、Dataflow、Presto/Trino）やマルチクラウドのポータビリティに適しています。トレードオフ: オブジェクトストアにおける結果整合性のセマンティクス。冪等性とメタデータ駆動の重複排除を考慮して設計します。
• データウェアハウス:
  • BigQueryにおけるキュレーションされ、統制された分析。ANSI SQL、ストレージ/コンピューティングの分離、およびきめ細かなセキュリティに最適化されています。トレードオフ: ストリーミング挿入ではクエリ時に一時的なデータの古さが発生します。厳格な鮮度SLAのためには、バッチロードまたはバッファ付きクエリでの挿入が望ましいです。
• レイクハウス:
  • オープンなデータレイクストレージとウェアハウスの機能を融合させます。Google Cloudでは、Parquet/AvroをCloud Storageに保存し、経済性のためにBigQuery外部テーブルを、パフォーマンスとガバナンスのためにBigQueryマネージドテーブルを使用します。DataflowまたはDataprocは、パーティショニング/クラスタリング戦略を用いて、ACIDライクなマージセマンティクスを維持します。
• オペレーショナルストアアーキテクチャ:
  • アプリケーションを支える低レイテンシのトランザクションストアまたはキーバリューストア。従来のOLTPにはCloud SQLを、水平スケールを備えたグローバルに一貫性のあるSQLにはCloud Spannerを、非常に高いスループットのワイドカラムアクセスパターンにはBigtableを選択します。オペレーショナルストアを分析系から分離し、CDC（Datastream）を使用して変更をキャプチャし、Pub/Sub、Cloud Storage、またはBigQueryに取り込みます。

処理パターンとその使用場面:

• バッチ: 定期的で大規模な変換（例: 夜間の特徴量生成）。ツール: Dataflowバッチ、Dataproc。障害モード: 長時間実行ジョブのタイムアウト、スキュー。オートスケーリングと再パーティショニングで緩和します。
• マイクロバッチ: 鮮度と安定性、コストのバランスを取るための、小規模で頻繁なバッチ（例: 1分ごと）。BigQueryでは、スケジュールされたクエリまたは固定ウィンドウを持つDataflowを使用します。
• ストリーミング: 非境界データに対するミリ秒から秒単位のレイテンシ。Pub/Sub + Dataflowを使用します。イベントタイムウィンドウとウォーターマークで遅延/順序外イベントを処理し、冪等性を確保して重複を防ぎます。
• イベントドリブン: 変更（GCSのファイナライズ、Pub/Subメッセージ）によってトリガーされます。ステートレスなリアクションにはCloud FunctionsまたはCloud Runを、ステートフルな処理にはDataflowを使用します。トレードオフ: イベントごとのコスト 対 スループット。
• ラムダパターン: 正確性と再処理のために、ストリーミングとバッチの両方のパスを維持します。複雑さが2倍になります。すべてが不変ログ（Pub/SubからCloud Storageへのアーカイブ）から再生可能な、カッパのような単純化を検討してください。

遅延データに対するDataflowストリーミング設定の短い例:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

ドメインの所有権、データプロダクト、コントラクト

• 所有権とSLO:
  • 各ドメインチームは、可用性、レイテンシ、データ品質に関するSLOを持つデータプロダクトを定義し、運用します。Dataplexカタログを介してSLOを公開し、Cloud MonitoringのSLI（例: 定時パーティションの完全性）で監視します。
• コントラクトと相互運用性:
  • Pub/Sub Schema Registry（Avro/Proto）とBigQueryテーブルスキーマでスキーマを強制します。CSVの取り込みでは、Dataflowで検証し、不正な形式の行をデッドレターテーブルにルーティングしてトリアージします。複数のエンジンが同じデータを読み取る必要がある場合は、Cloud StorageのオープンフォーマットやBigQuery外部テーブルと相互運用します。
• スキーマの進化:
  • 後方互換性のある変更を優先します: null許容列の追加、Avro/Protoでのオプショナルフィールドの追加、非推奨期間なしでの名前変更/削除の回避。バージョン管理されたコントラクトと非推奨スケジュールを介して変更を伝達します。
  • BigQueryの例（後方互換性のある列の追加）:

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• コンシューマーへの影響:
  • スキーマのセマンティックバージョニングを維持し、移行中はv1とv2の両方を公開します。ストリーミングの場合、バージョン管理されたトピックにルーティングするか、スキーマバージョンフィールドを含めます。BigQueryで承認済みビューを提供し、コンシューマーを物理的な変更から分離します。
• ガバナンスとリネージ:
  • メタデータ、タグ（例: PII）、リネージにはDataplexとData Catalogを使用します。BigQueryで行レベルおよび列レベルのセキュリティを適用します。データ損失防止のために、取り込み時（例: Cloud RunまたはDataflowの変換）にCloud DLPを統合し、保存前に機密フィールドをトークン化または墨消しします。

非機能要件のトレードオフとデプロイメントトポロジー

• スケーラビリティ:
  • BigQueryは分析用途で弾力的にスケールします。Bigtableはノード数に応じて線形にスケールしますが、ホットスポットを避けるためには慎重な行キー設計（例：ハッシュ化またはローテーションされたプレフィックス）が必要です。Dataflowの自動スケーリングはバックログに応じて動作します。Pub/Subのフロー制御を活用して、バックプレッシャーを考慮した設計を行ってください。
• レイテンシー:
  • BigQueryへのストリーミングは低レイテンシーでの挿入を提供しますが、クエリにはわずかな遅延が生じることがあります。鮮度バッファやウォーターマークベースのウィンドウを用いてクエリを設計してください。大規模で100ミリ秒未満の読み取りを実現するには、事前計算してBigtableまたはMemorystoreからデータを提供します。
• 可用性と一貫性:
  • Cloud Spannerは、強整合性を持つグローバル分散SQLを提供します。Bigtableは、クラスター間で結果整合性を備えた高可用性を提供します。BigQueryの可用性はリージョンまたはマルチリージョンです。回復性のために、重要なデータセットはマルチリージョンにマテリアライズしてください。
• コスト:
  • パーティショニングとクラスタリングでBigQueryを最適化し、スキャンされるバイト数を削減します。ネットワークが制限されたリンク経由で小さなファイルを扱う場合は、バッチ処理またはバンドル化してRPCオーバーヘッドを削減します。適切な場合には、キャッシュされたインタラクティブなダッシュボードのためにBigQuery BI Engineを使用します。
• リージョン、マルチリージョン、ハイブリッド、マルチクラウド:
  • リージョン設計はレイテンシーとコストを削減します。マルチリージョンストレージ（例：BigQueryのUS/EUマルチリージョン、Cloud Storageのデュアル/マルチリージョン）は、耐久性とロケーションの選択肢を増やします。DR（災害復旧）のためには、RPO/RTOを定義し、重要なデータセットを複製します。ハイブリッドシナリオでは、CDC（変更データキャプチャ）にDatastreamを、一括移行にTransfer AppliancesまたはStorage Transfer Serviceを使用します。マルチクラウドの場合は、Cloud Storageでオープンフォーマットに標準化し、エグレスコストと運用オーバーヘッドを認識しつつ、ポータブルなコンピューティング（Apache Beam/Dataflow、Dataproc上のSpark）を使用します。

階層化、ライフサイクル、およびサービス選択

• レイヤーの分離:
  • ストレージ: 生/ブロンズデータおよびアーカイブにはCloud Storage、キュレート済み/サービング分析にはBigQuery、低レイテンシのキーアクセスにはBigtable、OLTPにはSpanner/Cloud SQL。
  • コンピューティング: サーバーレスのストリーミング/バッチにはDataflow、Spark/HadoopエコシステムにはDataproc、ウェアハウス内ELTにはBigQuery、イベント駆動のマイクロサービスにはCloud Run/Functions。
  • オーケストレーション: DAGとAPIのコレオグラフィにはCloud Composer (Airflow) またはWorkflows、cronのようなトリガーにはScheduler。
  • サービング: オンライン読み取りにはBigtableまたはSpanner、BIにはBigQuery、ダッシュボードにはLooker/BI Engine、キャッシングにはMemorystore。
• データライフサイクル:
  • 取り込み: ストリームにはPub/Sub、ファイルにはStorage Transferまたはgsutil、SaaSにはData Transfer Service。検証、重複排除を行い、不変の生データをオブジェクトのバージョニングを有効にしたCloud Storageに配置する。
  • 処理: DataflowまたはBigQueryを使用して、生データをシルバー（クレンジング、整形済み）、そしてゴールド（ビジネス利用可能なマート）へ変換する。
  • 提供: 分析用にBigQueryのビュー/テーブルを公開する。API用に特徴量や予測を事前計算してBigtableに格納する。
  • 保持とアーカイブ: Cloud Storageのライフサイクルルールを適用してColdline/Archive階層に移行する。保持期間にはBigQueryのパーティション有効期限付きの時間パーティショニングを使用する。必要に応じてCMEKを有効にし、データ漏洩防止のためにVPC Service Controlsを使用する。
• ワークロードの特性に基づくサービス選択:
  • 高スループットの時系列データ、ワイドな行、低レイテンシ: Bigtable。
  • ANSI SQLを使用する、強整合性を持つグローバルなOLTP: Cloud Spanner。
  • 中程度のスケールの従来のリレーショナル トランザクション: Cloud SQL。
  • ペタバイト規模の分析、ANSI SQL、ストレージ/コンピューティングの分離: BigQuery。
  • リアルタイムの取り込みと処理: Pub/Sub + Dataflow。
  • バッチのSpark/Hadoopまたはライブラリ固有のツール: Dataproc。

BigQueryパーティショニングの簡単な例:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

実践的な問題シナリオ

Contoso Mobilityは、グローバルな電動スクーターフリートを運営しており、乗車テレメトリと請求のためにリアルタイムの取り込み、処理、ストレージ、および分析を必要としています。彼らは、毎分数百万のイベント、サブ秒単位の不正検知ルール、最新のダッシュボード、プライバシー管理、そして回復力のあるマルチリージョン運用をサポートしなければなりません。

アプローチ:

1. Cloud Pub/Subでイベント取り込みを確立する。

• 理由: Pub/Subは、単一のグローバルエンドポイント、永続的なバッファリング、およびバースト的なデバイストラフィックに対する水平スケールを提供します。1時間のウィンドウでデバイス内の順序性を維持するために、スクーターごとに順序付きキーを使用します。

2. Cloud Dataflow (Apache Beam)でストリーミング処理を実装する。

• 理由: Dataflowの自動スケーリングはスパイクに対応し、べき等のキーと組み合わせることでexactly-once（厳密に1回）のシンクを提供します。イベントタイムウィンドウとウォーターマークを使用して、遅延/順序が乱れたテレメトリを処理します。キュレート済みストリームへのメイン出力と、デッドレターレコード用のサイド出力を生成します。
• 構成:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. 生データとキュレート済みデータをそれぞれCloud StorageとBigQueryに永続化する。

• 理由: リプレイと監査のために、生（ブロンズ）のAvroファイルをデュアルリージョンのCloud Storageバケットに配置します。キュレート済み（シルバー）のストリームを分析用にBigQueryのパーティション分割テーブルに書き込み、効率的なポイントルックアップのためにscooter_idでクラスタリングします。一時的なストリーミングの陳腐化を避けるため、ダッシュボードのクエリに小さな鮮度バッファを適用します。

4. Cloud Bigtableからオペレーショナルなルックアップと不正検知を提供する。

• 理由: 100ミリ秒未満のルール評価には、低レイテンシのランダムアクセスが必要です。Dataflowで集計（例: 5分ウィンドウごとのデバイスあたりの乗車回数）を事前計算し、ホットスポットを回避しタブレット間で読み取りを並列化するために、ハッシュ化されたプレフィックスの行キー（例: h(prefix)+device_id+window_start）を使用してBigtableに書き込みます。

5. Cloud Spannerでトランザクションを伴う請求を管理する。

• 理由: 請求には、グローバルに整合性のあるSQL、強整合性、および高可用性が必要です。プライマリ地域にリーダーを、セカンダリ地域に読み取り専用レプリカを配置して、カスタマーポータルの読み取りレイテンシを削減します。

6. Dataplex、Data Catalog、およびCloud DLPでガバナンスを強制する。

• 理由: PIIフィールドを分類し、データセットにタグ付けし、BigQueryで列レベルのセキュリティを適用します。DataflowパイプラインにCloud DLPを統合し、ストレージに保存する前に機密属性をトークン化します。Dataplexのドメインは組織の所有権を反映し、各ドメインはSLO付きで文書化されたデータプロダクトを公開します。

7. Cloud ComposerとCloud Monitoringでオーケストレーションと運用を行う。

• 理由: Composerは、バッチのバックフィル、コンパクション、ML特徴量のマテリアライゼーションを調整します。Monitoringは、Pub/Subのバックログ、Dataflowのウォーターマークの遅延、BigQueryパーティションの完全性、BigtableのテールレイテンシといったエンドツーエンドのSLIを監視します。SLO違反時にアラートを発し、バックログの増加に基づいてDataflowを自動スケーリングします。

8. パーティショニングと階層化でコストとライフサイクルを最適化する。

• 理由: BigQueryテーブルはevent_tsでパーティション分割し90日間保持し、scooter_idでクラスタリングします。Cloud Storageはライフサイクルルールを使用して、生データを30日後にColdline、180日後にArchiveに移行します。スケジュールされたBigQueryジョブが、小さなマイクロバッチファイルをより大きなParquetオブジェクトにコンパクションし、後続のSparkジョブのファイル数オーバーヘッドを削減します。

9. リスクと回復性を検証する。

• 理由: 予想されるピークの2倍で負荷テストを実施し、Pub/Subの割り当てとDataflowの自動スケーリングを検証します。リージョンフェイルオーバー演習を実施します。BigQueryのマルチリージョンデータセットとデュアルリージョンバケットが可用性を維持し、Spannerのマルチリージョンインスタンスは自動フェイルオーバーによりRPO=0と設定されたRTOを維持します。ポリシー検証を伴うInfrastructure as Code (Terraform)を使用して、CMEKとVPC Service Controlsを強制します。

このアーキテクチャは、関心事を明確に分離しています。Pub/Subが取り込みをバッファリングし、Dataflowが計算し、Cloud StorageとBigQueryが分析データを保存・提供し、Bigtableがオペレーショナルな読み取りを高速化し、Spannerが整合性のあるトランザクションを保証します。パーティショニング、クラスタリング、ライフサイクルポリシー、自動スケーリングを通じてコストを制御しながら、スケーラビリティとレイテンシのバランスを取ります。そして、文書化されたデータプロダクト、コントラクト、継続的な検証を通じて、ガバナンスと信頼性を組み込んでいます。

すべてのドメイン · データストレージ、データレイク、ファイル形式 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →