Dataplex Data Catalog

解決する課題

• BigQuery・Cloud Storage・Pub/Sub などに散在するデータ資産を、置き場所を横断してひとつの索引から検索・発見したい
• 「このテーブルは何のデータか」「誰が所有し、どこまで機密か」をメタデータとして残し、属人化を防ぎたい
• 新しく入ったメンバーが既存のデータ資産を自力で見つけられるようにし、同じデータの重複作成を避けたい
• 機密区分やオーナー、用途といったビジネス的な意味付けを、各サービスにバラバラではなく一元的に管理したい
• データを移動・コピーせず、メタデータのレイヤーだけで発見性とガバナンスを高めたい

主要概念と用語

• エントリ (Entry): カタログが索引する1件のメタデータ。BigQuery テーブル、Cloud Storage のファイルセット、Pub/Sub トピックなど、データ資産1つに対応する
• エントリグループ (Entry Group): エントリをまとめる入れ物。プロジェクトやシステム単位でエントリを論理的に整理し、権限付与の単位にもなる
• エントリタイプ (Entry Type): エントリの種別を定義するテンプレート。どのアスペクトを持てるかなど、エントリの形を規定する
• アスペクト (Aspect): エントリに付与する構造化メタデータの実体。オーナー、機密区分、用途などをキーと値の形で機械可読に残す
• アスペクトタイプ (Aspect Type): アスペクトのスキーマ定義。どの項目をどの型で持つかを決め、組織で統一した語彙を強制する
• タグ / タグテンプレート: 旧 Data Catalog でのメタデータ付与の仕組み。現在のアスペクト/アスペクトタイプに相当する概念
• メタデータの自動収集 (Discovery): 対象ストレージを定期スキャンし、テーブルやスキーマを自動でエントリとして登録する仕組み
• 横断検索 (Search): エントリ名・スキーマ・アスペクトの値などを対象に、組織内のデータ資産をまとめて検索する機能。IAM で参照可能なものだけが結果に出る
• データリネージ (Lineage): エントリ間でデータがどう生成・変換されたかの来歴。カタログから上流・下流をたどれる

仕様・制限・クォータ

• Data Catalog はサーバーレスで、専用クラスタのプロビジョニングは不要。検索やメタデータ管理は Google 側のマネージド基盤で動く
• かつて独立サービスだった Data Catalog は Dataplex(Universal Catalog)へ統合され、現在はその一機能として提供される。API も Dataplex Catalog API へ移行が進んでいる
• 索引対象は BigQuery・Cloud Storage・Pub/Sub などの Google Cloud リソースに加え、コネクタ経由でオンプレや他システムのメタデータも取り込める
• 検索結果は呼び出し元の IAM 権限でフィルタされ、参照権限のないエントリは結果に現れない。カタログ自体がアクセス制御の抜け穴にならないよう設計されている
• エントリ・エントリグループ・アスペクトの数、検索のスループット、API のリクエストレートなどには上限がある。具体的な上限値は変動するため、設計時は公式のクォータを確認する

内部の仕組み

Data Catalog はデータ本体を持たず、メタデータの索引だけを管理する点が中核です。BigQuery テーブルや Cloud Storage のファイル、Pub/Sub トピックといった資産をエントリとして登録し、それらを横断検索できる索引に保持します。データそのものは元のサービスに残り、カタログはそこを指し示すメタデータのレイヤーとして機能します。

エントリにはアスペクトで構造化メタデータを重ねられます。アスペクトタイプでスキーマを定義しておくと、オーナーや機密区分、用途などを組織共通の語彙で機械可読に付与でき、検索やガバナンスの土台になります。自動収集（Discovery）は対象ストレージを定期スキャンし、新規テーブルやスキーマ変更を検知してエントリを最新に保ちます。

検索は名前・スキーマ・アスペクトの値などを対象にした全文検索的な索引で行われ、結果は呼び出し元の IAM 権限でフィルタされます。これにより、カタログ越しに権限外のデータが見えてしまうことを防ぎます。リネージと組み合わせると、見つけたエントリから上流・下流の依存をたどり、ある変更の影響範囲まで把握できます。

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

• アスペクトタイプで組織共通のメタデータ語彙（オーナー・機密区分・用途・更新頻度など）を定義し、付与のばらつきをなくす
• 機密区分のアスペクトをSensitive Data Protection(旧 DLP)の検出結果と連携させ、個人情報や機密データを横断的に識別できるようにする
• エントリグループをシステムやドメイン単位で切り、検索の整理と権限付与の単位を一致させる
• 重要なデータ資産には説明・オーナー・利用上の注意を必ず残し、検索でヒットした人が自己判断で正しく使えるようにする
• 自動収集とアスペクトの手動付与を役割分担し、機械的に取れる情報は Discovery に任せ、人手による意味付けに集中する

運用・監視

• 自動収集ジョブのスキャン状況とエラーを確認し、エントリの取りこぼしやスキーマ推定の失敗を検知する
• 重要データ資産のアスペクト充足率（オーナーや機密区分が埋まっているか）を定期的に棚卸しし、空欄を放置しない
• 検索のヒット状況から使われていない/重複したデータ資産を洗い出し、整理対象を見つける
• リネージで影響範囲を可視化し、上流テーブルの変更が下流のどのエントリへ波及するかを事前に把握する
• メタデータの変更を監査ログで追跡し、誰がいつ機密区分やオーナーを書き換えたかをたどれるようにする

コスト

セキュリティ

• 検索結果は呼び出し元の IAM 権限でフィルタされ、参照権限のないエントリは結果に出ない。カタログがアクセス制御を迂回する経路にならないよう設計されている
• カタログのメタデータ操作（エントリ作成・アスペクト付与・閲覧）にも IAM ロールを割り当て、最小権限で運用する
• 機密区分のアスペクトを付け、どのデータが個人情報や機密かを横断的に識別する。**Sensitive Data Protection(旧 DLP)**と組み合わせると機密検出を自動化できる
• 外部流出対策として VPC Service Controls を併用し、サービス境界を越えたメタデータの持ち出しを防ぐ

関連サービス・比較

データの横断検索・発見と意味付けを担うのが Data Catalog です。データの実体を分析・蓄積する BigQuery とは役割が異なり、BigQuery が「データを速く問い合わせる」のに対し、Data Catalog は「どこに何があるかを見つける」を担当します。両者は補完関係にあり、カタログで見つけたテーブルを BigQuery で分析する流れになります。

ハンズオン / CLI例

# 1) カタログを横断検索（プロジェクト配下のテーブルを名前で探す）
gcloud data-catalog search "type=table sales" \
  --include-project-ids=MY_PROJECT

# 2) タグテンプレート(意味付けの語彙)を作成する
gcloud data-catalog tag-templates create sensitivity_template \
  --location=asia-northeast1 \
  --display-name="Sensitivity" \
  --field=id=level,display-name=Level,type=string

# 3) 作成したタグテンプレートを確認する
gcloud data-catalog tag-templates describe sensitivity_template \
  --location=asia-northeast1

# 4) BigQuery のエントリを検索して見つける
gcloud data-catalog search "system=bigquery customer" \
  --include-project-ids=MY_PROJECT