セクション3 基礎：データの保存 📘
このファイルは 📘 基礎レベル。各ストレージサービスの「役割」と「特徴」を理解することがゴールです。 選定の意思決定ツリーや設計のベストプラクティスは 02_応用.md で扱います。
3.0 全体像：まず「軸」を頭に入れる
ストレージ選定は5つの軸で考えます。この軸が試験のあらゆる選択問題の土台になります。
① ワークロード : OLTP（更新中心・1行処理） vs OLAP（分析中心・大量集計）
② 構造化の度合い : 構造化（表）／半構造化（JSON等）／非構造化（画像・動画）
③ スケール規模 : GB級 〜 TB級 〜 PB級
④ 整合性要件 : 強整合（ACID） vs 結果整合（最終的に整合）
⑤ レイテンシ要件 : ミリ秒応答が必須か／秒〜分でよいか
- OLTP（Online Transaction Processing）＝在庫更新・決済など、1件ずつ確実に書き込む処理。
- OLAP（Online Analytical Processing）＝売上集計・BIなど、大量行をスキャンして集計する処理。
試験は「最適なものを1つ」選ばせる形式が大半。上の軸でふるい分けると、ほぼ一意に決まります。
3.1 ストレージシステムの選択：各サービスの役割
主要ストレージ早わかり
| サービス | 種別 | ワークロード | 整合性 | キーワード |
|---|---|---|---|---|
| Cloud Storage (GCS) | オブジェクトストレージ | — | 強整合（オブジェクト単位） | 非構造化・データレイク・バックアップ |
| BigQuery | DWH | OLAP | 強整合 | サーバーレス分析・PB級・SQL |
| Cloud SQL | リレーショナルDB | OLTP | 強整合(ACID) | MySQL/PostgreSQL/SQL Server・リージョナル |
| AlloyDB | リレーショナルDB | OLTP＋分析(HTAP) | 強整合(ACID) | PostgreSQL互換・高性能・分析も速い |
| Spanner | 分散リレーショナルDB | OLTP | 強整合(ACID)・グローバル | 水平スケール・無停止・TrueTime |
| Bigtable | NoSQL（ワイドカラム） | 大量書き込み/読み取り | 結果整合(単一行は強整合) | ミリ秒・時系列・IoT・PB級 |
| Firestore | NoSQL（ドキュメント） | OLTP（ドキュメント） | 強整合 | モバイル/Web・リアルタイム同期 |
| Memorystore | インメモリ | キャッシュ | — | Redis/Memcached・サブミリ秒 |
| BigLake | ストレージエンジン | OLAP（レイク上） | — | GCS/他クラウドをBQから統一管理 |
⚠️ 同じ「リレーショナル」でも Cloud SQL / AlloyDB / Spanner は別物。リージョナルか・グローバルか・分析併用かで分かれる（後述）。
① Cloud Storage（GCS）— 非構造化データの土台
オブジェクトストレージ。ファイル（オブジェクト）をバケットに格納する。スキーマを持たず、画像・動画・ログ・Parquet/Avro など何でも置ける。
- データレイクの実体として最も使われる（生データの貯蔵庫）
- 容量無制限・高耐久（イレブンナイン＝99.999999999%の年間耐久性）
- パイプラインのステージング領域やバックアップ先にも
ストレージクラス（アクセス頻度でコストが変わる。後述のライフサイクル管理と必ずセット）：
| クラス | 想定アクセス頻度 | 最低保存期間 | 主な用途 |
|---|---|---|---|
| Standard | 頻繁（ホット） | なし | 稼働中データ・配信 |
| Nearline | 月1回程度 | 30日 | バックアップ・たまに参照 |
| Coldline | 四半期に1回程度 | 90日 | アーカイブ（年数回） |
| Archive | 年1回未満（コールド） | 365日 | 長期保管・コンプライアンス保存 |
⚠️ 取り出し（読み取り）コストは Standard→Archive の順に高くなる。保存料は逆に安くなる。「めったに読まないが消せない」→ Coldline/Archive。
② BigQuery — サーバーレスなデータウェアハウス（OLAP）
フルマネージドのDWH。サーバー管理不要で、ペタバイト級のデータに対しSQLで高速集計できる。ストレージとコンピュート（スロット）が分離しているのが特徴。
- 分析・BI・レポーティングの中心
- BigQuery ML（BQML）：SQLだけでML
- ストリーミング挿入・連携（federated）クエリにも対応
- 課金は「オンデマンド（スキャン量）」または「容量ベース（Editions/スロット予約）」
BigQueryは「書き込みを大量に更新する用途には不向き」。1行ずつのUPDATE/DELETEを多用するならRDB（OLTP）を選ぶ。
③ Cloud SQL — マネージドな一般RDB（OLTP・リージョナル）
MySQL / PostgreSQL / SQL Server のマネージド版。ACIDトランザクションに対応したリージョナルなRDB。
- Webアプリのバックエンド・中小規模のトランザクション
- 高可用性(HA)構成・リードレプリカ・自動バックアップ
- ⚠️ リージョン単位。グローバル分散や無制限の水平スケールは不可 → それが必要なら Spanner
④ AlloyDB — 高性能なPostgreSQL互換（OLTP＋分析）
PostgreSQL互換で、Cloud SQLより高性能。トランザクション(OLTP)と分析クエリの両方が速いHTAP寄りのDB。
- 「PostgreSQLのまま、もっと速く、分析も同じDBで」というニーズ
- カラムナエンジンを内蔵し、分析クエリを高速化
- ⚠️ あくまでPostgreSQL互換。MySQL/SQL Serverは対象外（それは Cloud SQL）
⑤ Spanner — グローバル分散・強整合のRDB
水平スケールしながら強整合のACIDトランザクションをグローバルに提供する唯一のRDB。TrueTime（GPS＋原子時計による高精度な時刻同期）で世界規模の一貫性を実現。
- グローバル展開・無停止（99.999%）・大規模トランザクションが必要なミッションクリティカル系
- 例：グローバルな金融・在庫・ゲームのバックエンド
- ⚠️ 高機能ゆえコストは高め。「リージョナルで十分」なら Cloud SQL/AlloyDB
⑥ Bigtable — 低レイテンシ・高スループットのNoSQL
ワイドカラム型のNoSQL。ミリ秒のレイテンシで、毎秒数百万件規模の読み書きにスケールする。HBase API互換。
- 時系列・IoT・金融ティック・アドテク・モニタリングなど、大量・高速・単純キー参照
- 行キー（Row Key）で1次元にソートされて格納される（後述の行キー設計が超重要）
- ストレージは SSD（低レイテンシ）/ HDD（大容量・低コスト） を選択
- ⚠️ SQLは限定的で複雑なJOIN/集計は不向き。それは BigQuery。単一行は強整合だが、結合トランザクションのACIDは不可。
⑦ Firestore — ドキュメント型NoSQL（モバイル/Web向け）
ドキュメント（JSON的）指向のNoSQL。スケーラブルで、モバイル/Webクライアントとのリアルタイム同期・オフライン対応が強み。
- モバイルアプリ・チャット・リアルタイムコラボのバックエンド
- 強整合・自動スケール・SDKでクライアント直結
- ⚠️ 大量の時系列・分析用途ではない（それは Bigtable / BigQuery）
⑧ Memorystore — インメモリのキャッシュ
マネージドな Redis / Memcached。サブミリ秒の超低レイテンシ。
- キャッシュ・セッション管理・ランキング・レート制限
- ⚠️ 永続的なシステム・オブ・レコード（正本）ではない。あくまで前段のキャッシュ。
⑨ BigLake — レイクとウェアハウスを橋渡し
GCSや他クラウド上のデータを、BigQueryから**統一的に（細粒度アクセス制御付きで）**扱えるようにするストレージエンジン。
- データレイク（GCS/オープンフォーマット）に対し、BigQuery級のガバナンスを適用
- オープンフォーマット（Parquet/ORC/Avro/Iceberg）でロックインを回避
- ⚠️ 「データをコピーせずレイクのまま分析・統制」が狙い（後述の3.3/3.4で深掘り）
3.2 データウェアハウスの利用計画（BigQuery設計の基礎）
DWHは「分析しやすい形」にデータを整えて保管する。OLTPのRDBとは設計思想が逆になる点が重要です。
正規化 vs 非正規化
| 正規化 (Normalized) | 非正規化 (Denormalized) | |
|---|---|---|
| 狙い | 冗長排除・更新の整合性 | 読み取り（分析）の高速化 |
| JOIN | 多い | 少ない（事前に結合済み） |
| 向く処理 | OLTP（Cloud SQL等） | OLAP（BigQuery） |
- BigQueryは非正規化が基本。JOINを減らし、1テーブルにまとめる方がスキャン効率が良い。
- ただし無闇な平坦化ではなく、**ネスト/繰り返しフィールド（STRUCT/ARRAY）**で「繰り返す情報」を1行に畳み込むのがBigQuery流。
正規化（RDB流） BigQuery流（ネスト構造）
orders ── order_items orders
│ JOINが必要 ├─ order_id
└─ 1:N └─ items: ARRAY<STRUCT<sku, qty, price>>
（1行に注文明細を内包＝JOIN不要）
パーティションとクラスタリング（コスト・性能の要）
| 機能 | 何をする | 効果 |
|---|---|---|
| パーティション (Partitioning) | テーブルを日付/取り込み時刻/整数範囲で物理分割 | 不要な区画をスキャンせずスキャン量＝コスト削減（プルーニング） |
| クラスタリング (Clustering) | 指定列の値で並べ替えて格納 | フィルタ/集計対象を絞り込み、I/Oをさらに削減 |
- パーティション例：
WHERE date BETWEEN ...で、その日付の区画だけ読む。 - クラスタリング例：
customer_idでクラスタ化し、特定顧客の検索を高速化。 - 両方を併用するのが定石（まず日付でパーティション → よく絞る列でクラスタ）。
スロット（Slot）
BigQueryのクエリを実行する仮想CPUの計算単位。クエリは複数スロットで並列処理される。
- オンデマンド：スキャンしたバイト量で課金（スロットは自動割り当て）。
- 容量ベース（Editions/予約）：スロットを確保して定額化（大量・予測可能なワークロード向け）。詳細はセクション5。
試験ポイント：BigQueryでコストを下げる＝「スキャン量を減らす」＝パーティション＋クラスタリング＋必要な列だけSELECT（
SELECT *を避ける）。
3.3 データレイクの利用（GCSとレイク管理の基礎）
データレイク (Data Lake) ＝ 構造化・半構造化・非構造化を問わず、生データをそのまま大量に貯める場所。GCPでは主に Cloud Storage が実体。
データレイク vs データウェアハウス
| データレイク（GCS） | データウェアハウス（BigQuery） | |
|---|---|---|
| データ | 生データ・あらゆる形式 | 整形・統合済みの構造化データ |
| スキーマ | スキーマオンリード（読む時に解釈） | スキーマオンライト（入れる時に定義） |
| 主な利用者 | データエンジニア・データサイエンティスト | アナリスト・BI |
| コスト | 安価（保存中心） | クエリ性能・分析最適化 |
- スキーマオンリード：保存時はスキーマを強制せず、読み取り時に構造を当てはめる（柔軟）。
- スキーマオンライト：書き込み時にスキーマ検証（品質が担保しやすい）。
レイク管理の3観点（試験で問われる「管理」）
| 観点 | 内容 | 主な手段 |
|---|---|---|
| ディスカバリ | 「どこに何のデータがあるか」を見つけられる | Dataplex Catalog（メタデータ検索・タグ） |
| アクセス制御 | 誰がどのデータを読めるか | IAM・BigLake（細粒度）・Dataplex |
| コスト制御 | 安く・無駄なく保管 | ストレージクラス＋ライフサイクル管理 |
- レイクは放置すると**データスワンプ（沼）**化し、何があるか分からなくなる → カタログ化と監視が必須。
3.4 データプラットフォームの設計（統合ガバナンスの基礎）
複数のレイク・DWHを横断して、一貫したガバナンス（品質・セキュリティ・発見性）を効かせる。
Dataplex / Dataplex Catalog
- Dataplex：分散した GCS / BigQuery のデータを、物理的に動かさずに**論理的な「レイク」「ゾーン」「アセット」**として束ね、横断的にガバナンス・品質・セキュリティを適用する。
- Dataplex Catalog：組織全体のメタデータを集約したカタログ。データの検索・発見・タグ付け・系統（lineage）管理を担う。
Dataplex（論理的なデータ管理レイヤ）
└── レイク（例：販売ドメイン）
├── ゾーン: raw（生データゾーン / GCS）
└── ゾーン: curated（整形済みゾーン / BigQuery）
└── アセット（実体のバケット/データセット）
データメッシュとフェデレーテッドガバナンス
- データメッシュ (Data Mesh)：データを中央集権で持たず、各ドメイン（部門）がデータを「プロダクト」として所有・公開する分散型の考え方。
- フェデレーテッドガバナンス (Federated Governance)：分散所有でも共通のルール（命名・品質・セキュリティ・相互運用）を全体で守る統制モデル。Dataplex＋Catalogがこれを支える。
イメージ：各部門が自分のデータに責任を持ちつつ（自律）、組織共通のガバナンスは Dataplex で横串に効かせる（統制）。
📌 このセクションの基礎まとめ
- ストレージ選定は5軸（ワークロード／構造化度／スケール／整合性／レイテンシ）でふるい分ける
- RDBは3種：Cloud SQL（リージョナル）／AlloyDB（PostgreSQL高性能・分析併用）／Spanner（グローバル強整合）
- NoSQLは2種：Bigtable（大量・低レイテンシ・キー参照）／Firestore（ドキュメント・モバイル同期）
- BigQueryは非正規化＋ネスト構造、コスト削減はパーティション＋クラスタリング
- GCS＝レイク／BigQuery＝DWH、横断ガバナンスは Dataplex / BigLake、考え方としてデータメッシュ
次は 02_応用.md で選定の意思決定ツリーと設計のベストプラクティスを学びます。