Dataplex

解決する課題

• Cloud Storage と BigQuery に散在するデータを、置き場所を意識せず論理的に一元管理したい
• 「どこに何があるか」を組織横断で検索・発見できるようにし、データのサイロ化を防ぎたい
• データに対するアクセス権・分類・ポリシーを、ストレージごとにバラバラに設定せず横串で統制したい
• データの**鮮度・品質・リネージ（来歴）**を継続的に把握し、信頼できるデータだけを使いたい
• データを移動・コピーせず、元の場所に置いたままガバナンスを効かせたい

主要概念と用語

• レイク (Lake): ガバナンスを適用する最上位の論理的な入れ物。プロジェクトをまたいだデータを一つのドメインとしてまとめる単位
• ゾーン (Zone): レイク内をデータの成熟度で区切る区画。生データ向けのローゾーンと、整形・正規化済みデータ向けのキュレーテッドゾーンに分けるのが基本
• アセット (Asset): ゾーンに紐づける実体。具体的には Cloud Storage バケットや BigQuery データセットを指す。データ自体は移動せず参照で結びつける
• データカタログ (Catalog): メタデータの索引。テーブル・ファイル・スキーマを横断検索でき、ビジネス用語や説明（アスペクト / タグ）を付与できる。旧来の Data Catalog 機能はこのカタログへ統合された
• メタデータの自動収集 (Discovery): ゾーン配下のデータを定期スキャンしてスキーマやパーティションを推定し、BigQuery の外部テーブルや BigLake テーブルとして利用可能にする仕組み
• データ品質スキャン (Data Quality): 列の充足率・一意性・許容値などのルールを定義し、テーブルに対して継続的に検証するジョブ
• データプロファイリング (Data Profiling): 列ごとの分布・最小最大・NULL 比率などの統計を自動算出し、データの性質を把握する機能
• データリネージ (Lineage): テーブルやジョブの間でデータがどう生成・変換されたかの来歴を、上流から下流へ追跡する機能
• アスペクト / アスペクトタイプ: カタログのエントリに付ける構造化メタデータと、そのスキーマ定義。ガバナンス情報を機械可読な形で付与する

仕様・制限・クォータ

• Dataplex はサーバーレスで、専用クラスタのプロビジョニングは不要。スキャンやプロファイリングは Google 側のマネージド基盤で実行される
• 管理対象は主に Cloud Storage と BigQuery。データを Dataplex の専用ストレージへコピーするのではなく、元の場所のままメタデータとポリシーで束ねるのが基本思想
• 自動収集されたメタデータは、BigQuery の外部テーブル / BigLake テーブルとして参照でき、構造化・半構造化データのスキーマを推定する
• レイク・ゾーン・アセットの数、スキャン頻度、カタログ検索のスループットなどには上限が存在する。具体的な上限値は変動するため、設計時は公式ドキュメントのクォータを確認する
• 品質・プロファイルスキャンは BigQuery のクエリ実行を伴うため、対象データ量に応じてバックエンドの計算リソースを消費する

内部の仕組み

Dataplex はデータを物理的に取り込まない点が中核です。レイク・ゾーン・アセットという論理階層を定義すると、Dataplex はその配下の Cloud Storage や BigQuery をメタデータのレイヤーとして束ねます。データ本体はあくまで元のストレージに残り、Dataplex はそこへ向けたガバナンスと索引を提供します。

自動収集（Discovery）はゾーン配下を定期的にスキャンし、ファイルのレイアウトやスキーマ、パーティション構造を推定します。推定結果は BigQuery の外部テーブルや BigLake テーブルとして登録され、利用者は置き場所を意識せず SQL で参照できます。カタログはこれらのエントリを横断検索可能な索引として保持し、アスペクトやタグでビジネス的な意味付けを重ねます。

品質スキャンとプロファイリングは、定義したルールや統計計算を BigQuery のジョブとして実行し、結果を時系列で蓄積します。リネージはテーブルとジョブの依存関係をグラフとして記録し、ある列やテーブルの変更がどこへ波及するかを追跡できるようにします。アクセス制御は IAM と連携し、レイクやゾーン単位で付与した権限を、配下の Cloud Storage・BigQuery のアクセスへ反映します。

設計パターン / ベストプラクティス

• レイクをビジネスドメイン単位（例: 販売、マーケティング）で切り、その中をローゾーンとキュレーテッドゾーンに分けてデータの成熟度を表現する
• 生データはローゾーンの Cloud Storage に置き、整形・検証済みデータをキュレーテッドゾーンの BigQuery に昇格させるメダリオン的な段階設計にする
• カタログにはアスペクトやタグで意味付けを行い、機密区分やオーナー、用途を機械可読に残して検索性とガバナンスを両立させる
• 重要テーブルには品質スキャンを定期実行し、合格したデータだけを下流が参照する運用にして「信頼できるデータ」を担保する
• アクセス制御はゾーン単位の付与を基本にし、最小権限でデータドメインごとに分離する

運用・監視

• 品質スキャンの合格 / 不合格の結果を監視し、不合格時には通知やパイプライン停止につなげて、汚れたデータの下流流入を防ぐ
• プロファイル結果のNULL 比率や分布の急変を、データ異常の早期検知シグナルとして扱う
• 自動収集ジョブのスキャン状況とエラーを確認し、スキーマ推定の失敗やパーティションの取りこぼしを検知する
• リネージで影響範囲を可視化し、上流テーブルの変更時に下流への波及を事前に把握する
• スキャン頻度はデータの更新頻度とコストのバランスで調整し、更新の少ないテーブルを過剰にスキャンしない

コスト

セキュリティ

• アクセス制御は IAM と連携し、レイク・ゾーン単位で付与した権限を配下の Cloud Storage・BigQuery へ反映する。AWS の Lake Formation が S3 と Glue 上のデータへ権限を効かせるのと同じ発想
• データ本体は Cloud Storage / BigQuery 側の暗号化（Google 管理鍵が既定、要件に応じ CMEK / Cloud KMS）に従う。Dataplex はそこへポリシーと分類を重ねる
• カタログに機密区分のタグを付け、どのデータが個人情報や機密かを横断的に識別できるようにする。**Sensitive Data Protection（旧 DLP）**と組み合わせると機密検出を自動化できる
• 外部流出対策として VPC Service Controls を併用し、サービス境界を越えたメタデータ・データの持ち出しを防ぐ

Well-Architected の観点

• セキュリティ: データを移動せずに分類・権限・機密検出を横串で適用でき、ガバナンスの抜け漏れを減らす。IAM と VPC Service Controls で境界と最小権限を担保する
• 運用上の優秀性: メタデータ収集・品質スキャン・リネージを自動化し、データの状態を継続的に観測できる。手作業のカタログ整備や品質チェックから解放され、信頼できるデータを安定供給する運用に寄せられる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) レイクを作成（ガバナンスを適用する最上位の論理ドメイン）
gcloud dataplex lakes create sales-lake \
  --location=asia-northeast1 \
  --display-name="Sales Domain"

# 2) ゾーンを作成（生データ向けのローゾーン）
gcloud dataplex zones create raw-zone \
  --location=asia-northeast1 \
  --lake=sales-lake \
  --type=RAW \
  --resource-location-type=SINGLE_REGION \
  --display-name="Raw Zone"

# 3) Cloud Storage バケットをアセットとしてゾーンに紐づける
gcloud dataplex assets create raw-bucket \
  --location=asia-northeast1 \
  --lake=sales-lake \
  --zone=raw-zone \
  --resource-type=STORAGE_BUCKET \
  --resource-name=projects/MY_PROJECT/buckets/sales-raw-bucket \
  --discovery-enabled

# 4) 作成したレイクとゾーンを一覧で確認
gcloud dataplex lakes list --location=asia-northeast1
gcloud dataplex zones list --location=asia-northeast1 --lake=sales-lake