はじめに
現在、クラウドからAIを使用してコンピューターに統計的な処理をさせて、考えを導く流れが加速しています。今後もますます加速していくことでしょう。
その中で、インターネットによって情報というデータが民主化されて、人々にいきわたるようになりました。また、インターネットの基盤技術(クラウド技術)も革新的な発展を遂げて、IOT(インターネットに接続されたもの)に代表されるように、大量にデータが生成されるようになった。
大量に生成されるデータを裁くためにデータウェアハウスやデータレイク、最近ではレイクハウスといったデータ処理に特化したITインフラ技術が注目されている。
今回はGoogleが提供するクラウド技術であるGCPのデータエンジニアリングの知識体系を証明する「Professional Data Engineer」を取得したので、その備忘メモとして此方を残しておくものとする。
尚一度、この試験には惨敗していて2度目の挑戦なので、みっちりと復習をして骨の髄までエッセンスを飲み込んでいきたいと思っている。
BigQuery Omni
BigQuery Omniとは、Google BigQuery をマルチクラウド環境で利用できるサービスです。通常の BigQuery は Google Cloud 上で動作しますが、Omni を使うと AWS や Microsoft Azure 上のデータにも直接アクセスして分析できます。
データ移動不要
データを GCP にコピーせずに、そのまま AWS や Azure 上にあるデータをクエリできます。これにより、コスト削減やデータガバナンス上のメリットがあります。
同じSQLを利用可能
BigQuery の標準 SQL を使って、異なるクラウド環境のデータに対して一貫した分析が可能です。ユーザーはクラウドごとに異なるクエリ言語やツールを覚える必要がありません。
Anthos を基盤に構築
BigQuery の処理エンジンをコンテナ化し、Anthos（Googleのマルチクラウド/ハイブリッド基盤）を使って他クラウド上に展開しています。これにより BigQuery の実行環境をクラウド横断で提供できます。
利用シーン
マルチクラウド戦略を取っている企業が、各クラウドに分散したデータを一元的に分析したいとき。
データ移動のコストやセキュリティの制約で、クラウド間でのコピーを避けたい場合。
既存の BigQuery の知識を生かして AWS や Azure のデータを分析したいとき。
簡単にまとめると、BigQuery Omni = BigQuery のクエリエンジンを他のクラウドにも拡張したもので、マルチクラウド時代のデータ分析基盤を実現する仕組みです。
データメッシュと Dataplex / Analytics Hub
Dataplex
→ データメッシュの「実装基盤」に相当します。組織内のさまざまなストレージ（BigQuery、GCS など）に散らばったデータを一元的に管理し、ドメインごとにデータを整理・公開・ガバナンスできるサービス。
→ データメッシュの「ドメインごとのデータプロダクト」を整備するためのツール。
Analytics Hub
→ データメッシュそのものではなく、組織や外部とのデータ共有に使う仕組み。BigQuery 上のデータを「データエクスチェンジ（交換所）」として安全に共有できる。
→ データメッシュ内での「データプロダクトを他ドメインや外部に公開する窓口」と考えると整理しやすい。
👉 試験では データメッシュの基盤＝Dataplex、共有の仕組み＝Analytics Hub という棲み分けを意識。
VPC Service Controls とアクセス制御
GCP には VPC Service Controls という機能があり、これを使うと「サービス境界 (perimeter)」を設定し、特定のプロジェクトやサービスからのデータ流出を防止できる。
単に VPC ネットワークのルーティング制御ではなく、プロジェクト／サービスレベルでのデータアクセス制御が可能。
例：BigQuery や GCS のデータを「境界外のリソース」から直接アクセスさせないようにする。
👉 「プロジェクトごとに制御線を引けるか？」という問いには Yes：VPC Service Controls が回答。
GCS のレプリケーション機能
マルチリージョン / デュアルリージョン
→ 書き込み時に自動で複数リージョンへレプリケート。ゾーン障害やリージョン障害に耐えられる。
リージョン内ストレージ
→ 単一リージョンだが、内部的には複数ゾーンにレプリカを保持するので、ゾーン障害には耐えられる。
バケットレベルのレプリケーション (Bucket replication)
→ バケット間レプリケーションを設定可能（リージョンをまたいだレプリカ作成など）。
まとめると：
ゾーン障害 → 単リージョンストレージでも自動で対応。
リージョン障害 → デュアルリージョン / マルチリージョン / バケットレプリケーションを利用。
Dataplex の役割と AWS CloudFormation 的な位置づけ
CloudFormation は IaC（Infrastructure as Code）のプロビジョニングツール。
Dataplex は IaC ツールではなく、データガバナンス＋カタログ管理＋アクセス制御をまとめて提供するデータ管理基盤。
👉 似ているのは「ガバナンス」という点だけで、CloudFormation ＝ インフラ構成管理、Dataplex ＝ データガバナンス。
👉 データメッシュの「組織横断のガバナンスレイヤー」を担うのが Dataplex。
BigQuery のクエリ調査方法
INFORMATION_SCHEMA ビュー
→ region-us.INFORMATION_SCHEMA.JOBS などでクエリ実行状況、リソース使用量、エラーなどを確認できる。
Cloud Logging / Audit Logs
→ 監査ログやジョブログも利用可能。
Query Plan / Execution Details
→ コンソールや EXPLAIN で実行計画を確認。
👉 「基盤表を使って解析できるか？」 → INFORMATION_SCHEMA がその答え。試験でもよく出る。
Pub/Subで数日前のデータを再取得するには？
Pub/Sub トピック
→ データを長期保存する仕組みはない。メッセージ保持期間は最大 7 日間。
サブスクリプション側
→ Pull/PubSub Lite で保持期間を設定可能。未 ack のメッセージや保持期間内の履歴を再配信できる。
→ ただし「過去 2 日前の特定の時点に戻る」というより「保持期間内のメッセージを再取得」。
👉 実務で「数日前のデータを再処理」するには：
Pub/Sub → Dataflow / BigQuery / GCS に必ずシンクしておく
再処理したいときは シンク先のストレージからリロード がベストプラクティス。
ここまでをまとめてみると
- データメッシュ基盤＝Dataplex、共有＝Analytics Hub
- プロジェクト境界制御＝VPC Service Controls
- GCS はゾーン冗長性あり、リージョン障害対策はデュアル／マルチリージョン
- Dataplex は CloudFormation 的な IaC ではなく、データガバナンス基盤
- BigQuery クエリ調査＝INFORMATION_SCHEMA / Logging / Execution Plan
- Pub/Sub は保持 7 日まで、過去データ再処理はシンク先を利用
BigQuery から S3 / GCS をクエリする選択肢
1. BigLake を使う
BigLake は GCS だけでなく S3 や Azure Data Lake Storage (ADLS) 上のデータも扱える「マルチクラウド対応のストレージレイヤー」。
BigLake テーブルを作ることで、S3 上の Parquet/ORC/Avro/CSV/JSON などのファイルを BigQuery SQL でクエリできる。
Dataplex と組み合わせると、権限管理・ガバナンスも統一できる。
👉 マルチクラウドで公式に推奨されるやり方は BigLake。
BigQuery 外部テーブルを直接作成
以前は BigQuery Omni というサービスを使って、AWS/Azure 上で BigQuery のクエリエンジンを動かして S3 に直接アクセスする方法があった。
ただしこれは「別リージョンに BigQuery を動かす」形なので管理が複雑。
今は BigLake が登場したため、外部テーブル直結よりも BigLake を使うのが主流。
どう考えるべきか？
マルチクラウド前提で S3 / GCS 両方をクエリしたい → BigLake
シンプルに GCS 上のファイルだけクエリ → 外部テーブルでもよい（ただし BigLake に統一する方が推奨）
AWS 内で処理を閉じたい → Redshift Spectrum, Athena など AWS ネイティブを使うのも選択肢
まとめ（試験対策）
「マルチクラウドのデータ基盤を BigQuery で扱いたい」＝ BigLake
「GCS のファイルを直接扱う」＝ 外部テーブル or BigLake（推奨は BigLake）
「AWS の S3 を BigQuery から扱う」＝ BigLake 経由で可能
👉 Takuma さんの理解どおり「マルチクラウドなら BigLake」で正しいです。
Bigtable における縦長（Tall） vs 横長（Wide）
■ 縦長テーブル（Tall Schema）
イメージ：
行キーが device#timestamp のように増えていき、1 行に 1 イベント。
時系列データの場合、秒ごと・ミリ秒ごとなどの単位でレコードが増加。
メリット
クエリで「時間範囲のスキャン」がやりやすい。
データ量が増えても行キーで水平スケールしやすい。
柔軟性が高く、欠損値や可変スキーマでも対応できる。
デメリット
行数が膨大になりがち。
同一エンティティをまとめて読む場合、行スキャンのコストが高い。
👉 ログ、センサー、トランザクションなど「イベントドリブン」なデータに向く。
■ 横長テーブル（Wide Schema）
イメージ：
行キーが device#date で、1 行に 1 日分や 1 分分のデータをまとめる。
列に second01, second02, … second60 のように展開。
列数は無制限だが、実運用では数千列程度に抑えるのが一般的。
メリット
特定のキー範囲の全データを一気に読むのが速い。
「1 デバイスの全期間データをまとめて取得」みたいなアクセスパターンに最適。
デメリット
列設計が固定的で柔軟性がない。
欠損値が多いとスパースになり、ストレージ効率が悪化する。
列が増えすぎるとメタデータ負荷が高くなる。
👉 メトリクス、集計値、ユーザープロファイルなど「エンティティごとに属性が固定的」なデータに向く。
時系列データ（例：毎秒のセンサーデータ）
もし分析したい内容が「特定時間範囲のスキャン」なら → 縦長（Tall）
行キー：deviceID#timestamp
列：センサー属性（temperature, humidity…）
クエリ：「このデバイスの 1 分間データを取り出す」→ 時間範囲スキャンで高速。
もし分析したい内容が「1 分単位で全秒の値を一括取得」なら → 横長（Wide）
行キー：deviceID#minute
列：s1, s2, s3 … s60
クエリ：「このデバイスの 12:01 の全秒データ」→ 1 行読みで済む。
設計指針（まとめ）
縦長を基本とする
Bigtable は「時間範囲のスキャン」を強みにしているため、基本は Tall schema が推奨。
横長は特殊用途
アクセスパターンが「1 行にまとめて取得するのが常に効率的」な場合に採用。
列数が制御できる（例：秒単位で 60 固定など）なら適する。
混在設計も可能
元データは縦長で保持しつつ、集計やサマリを横長テーブルに変換して持つ。
「Raw（Tall）＋ Aggregated（Wide）」の二層構造。
パターンA：平常時 ≈300 slots、たまに 500 まで上がる
目標
平常時のコストを最適化しつつ、ピーク時に自動で追従。キュー滞留を最小化。
推奨プラン
キャパシティ課金（Reservations）＋ Autoscale
Baseline 300 を予約（年/3年コミットで単価↓）。
同じ予約に Autoscale 上限 +200（= 合計最大500） を付ける。使った分だけ秒課金。
300 を常備→日常は安定スループット、ピーク時のみ自動加算。
ワークロード分離（予約×割当）
ETL と Ad-hoc/BI を別予約に分け、フォルダ/プロジェクト/ワークロード識別子で Assignments を張る。
重要系（ETL）に 200–250、ユーザクエリに 100–150 をベース配分。両方に Autoscale をつける（例：ETL +100、BI +50）。
→ 重要系がユーザの突発に食われない。
実運用のチューニング
同時実行が過剰でスロットが薄まるなら、スケジューラ/キュー制御（優先度、リトライ、ジョブ分割）を整える。
JOBS_TIMELINE / INFORMATION_SCHEMA（組織/プロジェクト）で「待ち時間」「割り当てスロット」「吞み込み（consumed slots）」を継続観測。
スロット・リコメンダ（あれば）や実績値で上限/下限を微調整。
まとめ：Baseline 300 + Autoscale +200 が王道。費用はベースはコミット割引、ピークは秒課金で弾力化。
パターンB：平常は軽いが、まれに 200 slots 程度必要（できれば従量課金）
選択肢
選択肢1：オンデマンド（bytes スキャン従量）に留まる
スロットは Google 管理。設計不要で最も運用が軽い。
ただし大きなピーク時はキュー滞留が起きやすい（組織/プロジェクトの同時実行制限・フェアシェアに依存）。
選択肢2：Autoscale 専用予約（Baseline 0〜小さめ）
Baseline を 0 〜 最小限（例：50） にして、Autoscale 上限 200 を設定。
→ 平常はほぼ費用ゼロ（or 最小）で、必要な瞬間だけ秒課金で 200 まで伸びる。
ピークが読めるイベント（締め処理など）は、**Flex slots（短期コミット）**を併用して更に単価を抑える選択も可。
選択肢3：オンデマンド主体＋“保険”の小さな予約
通常はオンデマンド。**混雑時間帯だけ小さな予約（＋Autoscale）**に切替（Assignments の切替/スケジュール）。
オンデマンドの**最大スキャン上限（max_bytes_billed）**等で暴発を抑制。
まとめ：運用最小化ならオンデマンド、遅延を避けたいが平常コストを抑えたいなら Baseline 0〜少＋Autoscale 200。
共通の設計チェックリスト
SLO/遅延許容：キュー待ち許容秒数（例：P95 < 30s）を決め、Autoscale 上限を逆算。
ワークロード分離：重要系とユーザ系を予約で分離、Assignmentsで守る。
同時実行の整流化：スケジューラ、ジョブ粒度、クエリ優先度（Batch/Interactive）を整理。
監視：INFORMATION_SCHEMA.JOBS* / JOBS_TIMELINE の待ち時間・消費スロット・再試行・失敗率をダッシュボード化。
費用最適化：安定分は 長期コミット、突発分は Autoscale/Flex slots。読めないならオンデマンド維持。
すぐ使える設計プリセット（例）
A案（常時重い・ピーク500）
予約A（ETL）：Baseline 200 + Autoscale +100
予約B（BI）：Baseline 100 + Autoscale +100
合計：Baseline 300 / ピーク時 最大 500
B案（普段軽い・たまに200）
予約C：Baseline 0–50 + Autoscale +200
or オンデマンド継続、繁忙期のみ Flex 200 を時間予約
「どれを選ぶか」は、最終的に “遅延SLO” と “ピーク頻度×持続時間” と “コスト上限”の三点で決まります。
ざっくりでも、ピークの平均持続時間（例：30分/回 × 1日2回 × 月10日）を教えてもらえ