変更要約: Professional Data Engineer 第3章を新規作成（ドメイン3「保存」: ストレージ選択と DWH＝BigQuery/BigLake/AlloyDB/Bigtable/Spanner/Cloud SQL/Cloud Storage/Firestore/Memorystore・正規化/非正規化・パーティション/クラスタリング、データレイクとデータプラットフォーム＝データレイク(Cloud Storage)の発見/アクセス/コスト・Knowledge Catalog・フェデレーテッドガバナンス）。
3.2データレイクとデータプラットフォーム
データレイクの管理（データの発見・アクセス・コスト制御）、Knowledge Catalog によるデータプラットフォームの構築（ガバナンスとメタデータ発見を 1 製品で担う）、分散データシステムのためのフェデレーテッドガバナンスモデル、そしてレイクとウェアハウスの使い分けを理解します。
組織のデータは、構造化された データウェアハウスだけでなく、多様な生データを蓄える データレイクにも広がります。これらを横断して統制するのがデータプラットフォームです。
3.2.1データレイクの管理
データレイク（多くは Cloud Storage 上）は、多様な生データを安価に蓄えます。運用では、何があるかを見つける データの発見、誰が使えるかの アクセス制御、無駄を抑える コスト制御（ライフサイクル）を整えます。レイク上のデータも処理・分析でき、レイクとウェアハウスを組み合わせた構成（レイクハウス的）も取れます。「生データを安価に蓄える＝データレイク（Cloud Storage）」「発見/アクセス/コストを管理」と結びます。
3.2.2Knowledge Catalog とフェデレーテッドガバナンス
Knowledge Catalog は、分散したデータ（レイク/ウェアハウス）を横断して品質・ガバナンスを一元管理し、あわせてメタデータの発見・整理（検索・スキーマ・リネージ）まで担うデータプラットフォームです。ガバナンスとカタログは別製品ではなく 1 つの製品として提供されます（2026 年 4 月に Dataplex Universal Catalog から改称。旧 Data Catalog はここへの移行対象のレガシー製品）。組織が大きくなると、中央集権ではなく フェデレーテッドガバナンス（ドメインごとに責任を持ちつつ共通ルールで統制）が有効です。「分散データの横断統制もメタデータの発見も Knowledge Catalog」と押さえます。
「要件 → 手段」が頻出。例：「多様な生データを安価に蓄える」＝データレイク（Cloud Storage）、「分散データを横断して品質/ガバナンス管理」も「メタデータを発見/整理」も＝Knowledge Catalog（1 つの製品が両方を担う）、「大規模組織の分散統制」＝フェデレーテッドガバナンス。
混同に注意：
①データレイク（多様な生データ）とデータウェアハウス（構造化分析）は役割が違う（組み合わせ可）。
②Knowledge Catalog は横断ガバナンスとメタデータ発見を兼ねる 1 つの製品であり、別々の製品と取り違えない（旧 Data Catalog は移行対象のレガシー）。
③ガバナンスは規模で中央集権かフェデレーテッドかを選ぶ。
3.2.3この節のまとめ
- データレイク（Cloud Storage）は生データを安価に蓄え、発見/アクセス/コストを管理
- Knowledge Catalog が分散データの横断ガバナンスとメタデータ発見をまとめて担う
- 大規模組織はフェデレーテッドガバナンスで分散統制
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 多様な生データを安価に蓄えるデータレイクの基盤として一般的なのはどれですか？
Q2. 分散したデータ（レイク/ウェアハウス）を横断して品質・カタログ・ガバナンスを一元管理したい。最適なのはどれですか？
Q3. データのメタデータを発見・整理し、所在と意味を把握したい。使うのはどれですか？
Q4. 大規模組織で、ドメインごとに責任を持ちつつ共通ルールで統制したい。最適な考え方はどれですか？
Q5. データレイクとデータウェアハウスの違いとして正しいものはどれですか？
Q6. データレイクの運用で整えるべき要素として最も適切な組み合わせはどれですか？