Google PDE: データストレージ、データレイク、ファイル形式 — 学習ガイド

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

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

概要

Google Cloudでのデータストレージは、生のオブジェクトストレージ、キュレートされたデータレイク、分析に最適化されたフォーマットに及びます。信頼性、ガバナンス、パフォーマンスに優れたレイクを構築するには、ストレージクラス、バケット設定、ロケーション、ファイル形式、テーブルレイアウト、ライフサイクルを慎重に選択する必要があります。このセクションでは、設計上のトレードオフ、避けるべき障害モード、そして大規模なBigQuery、Spark、ストリーミングパイプラインと連携するパターンについて詳述します。

Cloud Storageの基礎：クラス、バケット、一貫性、ライフサイクル

Cloud Storageは、生ファイルおよびキュレート済みファイルのための、耐久性と可用性の高い基盤です。

• ストレージクラス

  • Standard (ホット): 頻繁なアクセス、最小のレイテンシ。最小ストレージ期間なし。
  • Nearline (クール): 低頻度のアクセス (月1回程度)。最小30日間。取得料金が適用されます。
  • Coldline (コールド): さらに低頻度のアクセス (四半期に1回程度)。最小90日間。より高い取得料金。
  • Archive (アーカイブ): 長期保存 (年1回程度)。最小365日間。最も高い取得料金。
  • Autoclassはクラス間を自動的に移行できます。早期削除料金とアクセスパターンが節約効果を損なわないことを確認してください。

• バケットのロケーションとレプリケーション

  • リージョン: 単一の地理的範囲内でのデータの局所性とコンプライアンスに最適。
  • デュアルリージョン: 自動レプリケーションを備えた2つのペアのリージョン。turbo replicationはレプリカを迅速にコミットし、RPOは分単位で測定されます。低RPOのDRに最適です。
  • マルチリージョン: 大陸内で地理的に分散され、広範な可用性、コンテンツ配信、広域にわたる分析に対応。
  • データレジデンシー法を満たし、コンピューティング (Dataproc, Dataflow, BigQuery外部テーブル) へのエグレス/レイテンシを最小化するためにロケーションを選択します。

• 一貫性とセマンティクス

  • Cloud Storageは、強力なグローバルなread-after-write、read-after-metadata-update、list-after-writeの一貫性を提供します。
  • オブジェクトの書き込みはアトミックかつイミュータブルです。「名前の変更」はコピー+削除のパターンです。べき等なコピーを設計し、チェックサムを検証して部分的な移行を防ぎます。

• アクセスパターンとパフォーマンス

  • 並列複合アップロードと再開可能アップロードは、大きなファイルのスループットを向上させます。
  • 範囲読み取りにより、列指向フォーマットのフッターや選択的な読み取りが効率的に行えます。
  • メタデータ/一覧表示のオーバーヘッドを増大させる多数の小さなファイル (<8 MB) は避け、バッチ処理またはより大きなオブジェクトに圧縮します。
  • GZIPは分散読み取りのために分割可能ではありません。スケーラブルな処理にはParquet/ORC/Avro+Snappyを推奨します。

• ライフサイクル、保持、バージョニング

  • バケットレベルの保持ポリシーとオブジェクトホールド (イベントベースまたは一時的) は、コンプライアンスのために不変性（イミュータビリティ）を強制し、偶発的な削除を減らします。
  • オブジェクトのバージョニングは以前の世代を保持します。上書き/削除からの回復に役立ちます。ストレージコストの増加を監視してください。
  • ライフサイクルルールは移行と削除を自動化します。例 (JSON) は、古いデータをよりコールドなクラスに移動し、1年後に削除します: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  • 障害モード: 移行が積極的すぎると早期削除料金が発生します。保持ロックは短縮できません。圧縮なしのバージョニングはコストを増大させる可能性があります。

• 転送と移行

  • オンプレミスや他のクラウドからの、並列化され、チェックポイントが設定された移動にはStorage Transfer Serviceを使用します。オフラインのペタバイト級データにはTransfer Applianceを使用します。
  • 競合状態を防ぐために、CRC32C/MD5で整合性を検証し、generation-match事前条件を使用します。
  • 大量のイングレスには、-m (並列) オプションとチェックサムを付けたgsutil/gcloud storageを優先的に使用し、SFTPのボトルネックを避けます。

BigLakeとDataplexによる統合されたレイクガバナンス

BigLakeとDataplexは、ファイルとテーブルにまたがるセキュリティとガバナンスを標準化します。

• BigLake

  • Cloud Storageのデータを、行レベルのアクセスポリシーや列レベルのポリシータグを含む、統一されたきめ細かなアクセス制御が可能なBigQuery管理テーブル (外部) として公開します。
  • Parquet/ORCに対して列のプルーニングと述語プッシュダウンを可能にし、BigQuery、Dataproc上のSpark、Dataflowなどのエンジンへのスキャンされるバイト数とエグレスを削減します。
  • Cloud Loggingを介して監査を集中管理し、中央でのポリシー適用を可能にします。レイクファイルとウェアハウスのテーブルのための単一のコントロールプレーンです。

• Dataplex

  • データをレイク、ゾーン (raw, curated, trusted)、アセット (バケット, データセット) に整理し、メタデータ、リネージ、データ品質ルールを管理します。
  • 機密性の高い列のポリシータグと統合し、レイク/ゾーン/アセットのスコープでIAMを介した最小権限をサポートします。
  • 複数チームの環境で「ジャンクドロワー（がらくた入れ）」を避けるために、標準化された命名規則、パーティショニング、スキーマ管理を推奨します。

• ガバナンスパターン

  • テナントごとのデータセット、ゾーンごとのバケットのパターンを実装し、テナント間のデータ漏洩を避けます。
  • PIIには行アクセスポリシーと列ポリシータグを使用します。承認されたアイデンティティにAPIアクセスを制限します。
  • Cloud Loggingでアクセスを監査し、フィルタリングされたログをPub/Subにルーティングしてリアルタイム監視を行います。

ファイルフォーマット、圧縮、クエリの動作

適切なフォーマットを選択することは、コストとパフォーマンスに直接的な影響を与えます。

• カラムナフォーマット (Parquet, ORC)

  • 長所: カラムプルーニング、プレディケートプッシュダウン、カラムごとのエンコーディングと圧縮、統計情報、分割可能なファイル。
  • トレードオフ: 書き込み時のCPU負荷が高い。スキーマエボリューションは慎重に管理する必要がある (例: カラムのADDは安全、型の変更はリスクが高い)。
  • 圧縮: 速度重視ならSnappy、サポートされていれば圧縮率の高いZSTD。相互運用性の制約で必要な場合を除き、カラムナフォーマットでのGZIPの使用は避ける。

• 行指向のAvro

  • 長所: 厳密な型付けによるスキーマエボリューション、ブロックレベルの圧縮、分割可能。ストリーミングのランディングゾーンやデータ交換に最適。
  • トレードオフ: 分析時のスキャン効率はカラムナフォーマットより低い。キュレートされたゾーンでParquet/ORCに変換する。

• CSVとJSON (半構造化)

  • CSV: 人間が読みやすく、値が単純な場合はオーバーヘッドが最小。スキーマ、型、エスケープの一貫性がない。大規模になるとパースにコストがかかる。
  • JSON: 自己記述的で柔軟。スケーラブルな分散読み取りには改行区切りのJSONが必要。冗長でパース時のCPU負荷が高い。
  • 可能な限り、生のCSV/JSONを配置し、その後バリデーションを行い、分析用にAvro/Parquetに変換する。

• BigQuery外部テーブルとBigLakeテーブル

  • Parquet/ORC外部テーブルはプッシュダウンとカラムプルーニングの恩恵を受けるが、CSV/JSONは通常受けられず、スキャンされるバイト数が多くなる。
  • 圧縮されたCSV (GZIP) 外部テーブルはワーカー間で分割できないため、読み取りが遅くなることが予想される。
  • 例: Hive形式のパーティションを持つParquet BigLakeテーブルの作成: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

レイアウト、パーティショニング、パフォーマンスエンジニアリング、レジデンシー、移行

• オブジェクトのレイアウトとパーティショニング

  • パーティションとクラスタリングキーには Hive スタイルのパスを採用する: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • 並列処理とタスクのオーバーヘッドのバランスを取るため、個々のファイルサイズを 128～1024 MB の範囲に保つ。パーティションごとに数百万のファイルが存在する状況は避ける。
  • 小規模ファイル問題は、以下の方法で軽減する:
    • クライアント側でアップロードをバッチ処理する。
    • Dataflow/Spark のコンパクションジョブを使用して、オフピーク時に小さなファイルを統合する。
    • 元の小さなファイルをアーカイブし、分析には統合されたデータのみを公開する。

• BigQuery のパーティショニングとクラスタリング

  • 取り込み時間、またはカーディナリティの高いフィルター列 (例: event_date) でパーティション分割する。メタデータを爆発的に増加させる過剰なパーティショニング (例: 分単位) は避ける。
  • 一般的にフィルタリング/ソートされるディメンション (最大 4 つ) でクラスタリングする。クラスタリングはデータの局所性を高め、スキャンされるバイト数を削減する。
  • 高負荷のインタラクティブな分析にはネイティブ BigQuery テーブルを優先する。ガバナンスの効いたレイクアクセス、エンジン間の共有、コストの分離には BigLake/外部テーブルを使用する。

• クエリパフォーマンスへの影響

  • 列指向フォーマットは外部スキャンコストを大幅に削減する。CSV/JSON 外部テーブルは、多くの場合、ファイル全体のスキャンが必要となる。
  • 整合性の保証により、Cloud Storage の読み取り時に人為的な遅延を設ける必要はなくなるが、ダウンストリームシステム (例: BigQuery のストリーミング挿入) では短いデータの可視性ラグが発生する可能性がある。必要に応じてウォーターマークや読み取り遅延を考慮して設計する。

• レジデンシー、耐久性、リカバリー

  • レジデンシー制約を満たすようにバケット/データセットのロケーションを選択する。エグレスとレイテンシーを削減するためにコンピュートを併置する。
  • 低い RPO (目標復旧時点) を実現するために、ターボレプリケーション付きのデュアルリージョンを使用する。人為的ミスやランサムウェアからの回復可能性を確保するために、バージョニングと保持ポリシーを併用する。
  • DR (災害復旧) のためには、バケットのレプリケーションを使用してバケットを別のプロジェクト/リージョンに複製し、別の IAM 境界で保護する。

• 安全な移行と検証

  • 複数フェーズで計画する: シード (一括転送)、増分同期 (mtime/ウィンドウコピー)、カットオーバー (読み取り専用ソース)、カットオーバー後の検証。
  • チェックサム、件数、合計バイト数、サンプルデコードで検証する。表形式データの場合、行数とハッシュ集計を比較する:

undefined

• 並列コピー中の上書きを防ぐために、事前条件 (ifGenerationMatch) を使用する。バージョニングまたはソースの保持により、ロールバックウィンドウを確保する。
• 移行後、新しいアクセスプロファイルに従ってライフサイクルと Autoclass を有効にする。検証が完了するまで保持ロックの有効化は避ける。

実践的な問題シナリオ

Acme Retail は、物流パートナーからリージョナル Cloud Storage バケットに毎日 CSV ファイルを受け取っています。ファイルには時折、不正な形式の行が含まれています。Acme は、データを配置、検証し、分析に適した形式に変換して BigQuery にロードし、ほぼリアルタイムのダッシュボードで利用できるようにする必要があります。同時に、不正な行は検査用に保持し、ガバナンスを強制しなければなりません。

アプローチ:

1. Dataplex で生データを配置し、ガバナンスを適用

   • gs://acme-raw/logistics/ にマッピングされた raw ゾーンアセットを持つ Dataplex lake を作成する。
   • 根拠: ガバナンス、メタデータ、リネージの一元管理。ゾーンレベルで IAM を強制し、機密フィールドにはダウンストリームでの強制適用のためのポリシー タグを付与する。

2. ライフサイクルと保持ポリシーを適用

   • acme-raw に 30 日間のバケット保持ポリシーを適用し、オブジェクトのバージョニングを有効にする。
   • 根拠: パートナーによる偶発的な上書き/削除から保護する。短い保持期間は、コストと回復可能性のバランスを取る。バージョニングにより、不適切な配信のロールバックが容易になる。

3. Dataflow バッチパイプラインで検証と取り込み

   • オブジェクトのファイナライズ通知をトリガーとして、毎日 Dataflow ジョブを実行する。スキーマとレコードごとの検証を用いて CSV を読み込む。有効なレコードは BigQuery のステージングテーブル (event_date でパーティション分割) に書き込み、パース/検証エラーはデッドレター用の BigQuery テーブルにルーティングする。
   • 根拠: Dataflow はスケーラブルな並列パースと堅牢なデッドレター処理を提供するため、アナリストは不正な行を検査できる。これは、品質が不均一な CSV に対するベストプラクティスを反映している。

4. curated ゾーンで Parquet に変換・圧縮

   • 同じパイプラインが、検証済みのデータを gs://acme-curated/logistics/date=YYYY-MM-DD/ に、約 256～512 MB のサイズの Parquet ファイルとして書き込む。
   • 根拠: Parquet は BigQuery と Spark での列プルーニングと述語プッシュダウンを可能にし、スキャンされるバイト数を削減してレイテンシーを改善する。コンパクションは、パートナーの配信パターンに起因する小規模ファイルのオーバーヘッドを軽減する。

5. BigLake を介してガバナンスの効いた分析を公開

   • curated Parquet パス上に、Hive の自動パーティショニングを使用した BigLake 外部テーブルを作成する。パートナー固有のフィルターのために、列レベルのポリシー タグと行アクセス ポリシーを適用する。
   • 根拠: BigQuery と Spark にわたる均一で詳細なアクセス制御と、一元化された監査を実現する。パーティションプルーニングにより、日付フィルターでのスキャンコストが削減される。

6. 重要な集計をネイティブ BigQuery にロード

   • アクセスの多いダッシュボード向けに、curated Parquet 外部テーブルから過去 N 日分のデータを取り込み、ネイティブのクラスタ化・パーティション化されたテーブルに格納する BigQuery ジョブをスケジュール実行する。
   • 根拠: ネイティブストレージは高い同時実行性が求められる BI を高速化する一方、外部 BigLake テーブルはより広範なアクセスのためのガバナンスが適用された正系のシステムとして存続する。

7. Cloud Logging と Pub/Sub で監視とアラート

   • Dataflow と BigQuery のロードジョブの結果をフィルタリングして Pub/Sub に送るログシンクを作成する。監視ツールと統合し、障害や不正な行の割合の上昇時に即時アラートを受け取る。
   • 根拠: ポーリングなしで、対象を絞ったテーブル固有の運用可視性を実現する。SRE プラクティスをサポートする。

8. ストレージクラスとレジデンシーの最適化

   • curated Parquet は 14 日間 Standard に保持し、ライフサイクルルールにより 30 日後に Coldline に移行する。エグレスを避けるため、raw と curated の両方のバケットを BigQuery データセットと同じリージョンに保存する。
   • 根拠: アクセスの多いデータの読み取りパフォーマンスとコストのバランスを取る。併置により、コンプライアンスを維持し、レイテンシーとエグレス料金を最小限に抑える。

9. エンドツーエンドの品質を検証

   • 各実行後、ステージング、curated 外部、ネイティブ BigQuery の各テーブル間で件数とハッシュ集計を比較し、異常があれば隔離する。
   • 根拠: スキーマのドリフトや取り込みのリグレッションを早期に検出する。暗号学的ハッシュまたはフィンガープリントハッシュは、完全な再スキャンなしで軽量な保証を提供する。

この設計は、デッドレター分析を備えた回復力のある取り込み、効率的なクエリのための分析対応 Parquet、Dataplex と BigLake による一元化されたガバナンス、そしてコスト最適化されたライフサイクルポリシーを提供します。これらすべては、最小権限アクセスと監査可能なオペレーションの原則を遵守しながら実現されます。

← データエンジニアリングのアーキテクチャと設計 · すべてのドメイン · BigQuery による分析とウェアハウスエンジニアリング →

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

Googleを閲覧 →