変更要約: Professional Data Engineer 第3章を新規作成（ドメイン3「保存」: ストレージ選択と DWH＝BigQuery/BigLake/AlloyDB/Bigtable/Spanner/Cloud SQL/Cloud Storage/Firestore/Memorystore・正規化/非正規化・パーティション/クラスタリング、データレイクとデータプラットフォーム＝データレイク(Cloud Storage)の発見/アクセス/コスト・Dataplex/Dataplex Catalog・フェデレーテッドガバナンス）。
3.1ストレージシステムの選択とデータウェアハウス
アクセスパターンに応じたマネージドサービスの選択（BigQuery・BigLake・AlloyDB・Bigtable・Spanner・Cloud SQL・Cloud Storage・Firestore・Memorystore）、ストレージのコストと性能、ライフサイクル管理、そしてデータウェアハウスのデータモデル設計（正規化の度合い・アクセスパターンへの最適化）を理解します。
データをどこに置くかは、アクセスパターン・規模・コストで決まります。データエンジニアは、用途に最適なストレージを選び、データウェアハウスを設計します。
3.1.1ストレージの選択
アクセスパターンを分析して選びます：大規模 SQL 分析（DWH）は BigQuery、Cloud Storage 上のデータも BigQuery から扱う BigLake、高性能 PostgreSQL は AlloyDB、超大量・低遅延の NoSQL は Bigtable、グローバル強整合 RDB は Spanner、一般業務 RDB は Cloud SQL、非構造化オブジェクトは Cloud Storage、ドキュメントは Firestore、キャッシュは Memorystore。コストと性能、ライフサイクル管理（古いデータの移行/削除）も考慮します。「分析＝BigQuery」「低遅延大量＝Bigtable」「グローバル強整合＝Spanner」と結びます。
3.1.2データウェアハウスのモデル設計
BigQuery のような DWH では、データモデルを設計します。分析の DWH では、結合コストを抑えるため 非正規化（一部を冗長に持つ）を選ぶことが多く、OLTP の RDB では 正規化で重複を避けます。アクセスパターンに合わせ、パーティション（日付などで分割）や クラスタリング（よく絞る列で整列）で、スキャン量とコストを抑えます。「分析 DWH は非正規化寄り」「スキャン削減＝パーティション/クラスタリング」を押さえます。
「要件 → サービス/設計」が頻出。例：「ペタバイト級 SQL 分析」＝BigQuery、「Cloud Storage のデータを BigQuery から」＝BigLake、「超大量・低遅延」＝Bigtable、「グローバル強整合」＝Spanner、「BigQuery のスキャン量を減らす」＝パーティション＋クラスタリング、「分析の結合コストを抑える」＝非正規化。
混同に注意：
①分析の BigQuery と OLTP の Cloud SQL/Spannerは用途が違う。
②パーティション（分割）とクラスタリング（整列）は別概念で、両方でスキャンを削減。
③分析 DWH は OLTP と違い非正規化が有効なことが多い。
3.1.3この節のまとめ
- アクセスパターンで選ぶ：分析=BigQuery/BigLake、低遅延大量=Bigtable、強整合=Spanner ほか
- DWH は非正規化寄り、OLTP は正規化。パーティション/クラスタリングでスキャン削減
- コスト/性能とライフサイクル管理（移行/削除）も設計する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ペタバイト級のデータを SQL で高速に分析するデータウェアハウスはどれですか？
Q2. Cloud Storage 上のデータを移動せず BigQuery から分析したい。最適なのはどれですか？
Q3. 超大量・低遅延の時系列/IoT データを扱いたい。最適なのはどれですか？
Q4. BigQuery のクエリのスキャン量とコストを減らしたい。最も適した設計はどれですか？
Q5. 分析向けデータウェアハウスのモデル設計として一般に有効なのはどれですか？
Q6. グローバルに分散しつつ強整合のリレーショナル DB が必要です。最適なのはどれですか？