Data CatalogからKnowledge Catalogへの移行

解決する課題

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

主要概念と用語

• 旧エントリ / タグ: 旧 Data Catalog の独自エントリ、エントリグループ、タグテンプレート、タグ。移行対象を棚卸しし、API 呼び出し元も含めて後継モデルへ対応させる
• エントリ (Entry): Knowledge Catalog が索引する1件のメタデータ。BigQuery テーブル、Cloud Storage のファイルセット、Pub/Sub トピックなど、データ資産1つに対応する
• エントリグループ (Entry Group): エントリをまとめる入れ物。プロジェクトやシステム単位でエントリを論理的に整理し、権限付与の単位にもなる
• エントリタイプ (Entry Type): エントリの種別を定義するテンプレート。どのアスペクトを持てるかなど、エントリの形を規定する
• アスペクト (Aspect): エントリに付与する構造化メタデータの実体。オーナー、機密区分、用途などをキーと値の形で機械可読に残す
• アスペクトタイプ (Aspect Type): アスペクトのスキーマ定義。どの項目をどの型で持つかを決め、組織で統一した語彙を強制する
• タグ / タグテンプレート: 旧 Data Catalog でのメタデータ付与の仕組み。後継のアスペクト/アスペクトタイプへ写像する。BigQuery の列レベルアクセス制御に使うポリシータグと分類体系は、このサービス終了の対象外
• 自動取り込み: 対応する Google Cloud 資源の技術メタデータを Knowledge Catalog へ取り込む仕組み。データ本体は元サービスに残る
• 横断検索 (Search): エントリ名・スキーマ・アスペクトの値などを対象に、組織内のデータ資産をまとめて検索する機能。IAM で参照可能なものだけが結果に出る
• データリネージ (Lineage): エントリ間でデータがどう生成・変換されたかの来歴。カタログから上流・下流をたどれる

仕様・制限・クォータ

• 旧 Data Catalog は 2026年6月1日から段階的停止中で、API の中断や完全に利用できない期間が起こり得る。Knowledge Catalog 自体はこの停止の影響を受けないため、新規設計に旧 API を使わない
• 準備段階では旧 Data Catalog が正本のまま、設定後に独自メタデータが Knowledge Catalog へ読み取り専用で現れる。この段階で型、IAM、リージョン、件数、クライアントを比較する
• Upgrade 段階で読み書きの正本が Knowledge Catalog へ移る。更新先を旧 API のまま残さないよう、API、クライアント、Terraform、gcloud を同じ切替計画で更新する
• 旧タグはアスペクトへ、タグテンプレートはアスペクトタイプへ対応させる。BigQuery の列レベルアクセス制御に使うポリシータグと分類体系は停止対象と分けて扱う
• 索引対象は BigQuery・Cloud Storage・Pub/Sub などの Google Cloud リソースに加え、コネクタ経由でオンプレや他システムのメタデータも取り込める
• 検索結果は呼び出し元の IAM 権限でフィルタされ、参照権限のないエントリは結果に現れない。カタログ自体がアクセス制御の抜け穴にならないよう設計されている
• エントリ・エントリグループ・アスペクトの数、検索のスループット、API のリクエストレートなどには上限がある。具体的な上限値は変動するため、設計時は公式のクォータを確認する

内部の仕組み

横にスクロール

旧 Data Catalog も Knowledge Catalog も、データ本体を持たず、メタデータの索引を管理する点は共通です。ただし管理モデルは異なり、旧サービスのタグテンプレートとタグを、後継のアスペクトタイプとアスペクトへ写像して移行します。データそのものは BigQuery や Cloud Storage などの元サービスに残ります。

移行は、対象の棚卸し、準備設定、読み取り専用コピーの比較、Upgrade、API と権限の検証という順で進めます。準備中は旧 Data Catalog が正本ですが、Upgrade 後は Knowledge Catalog が更新先です。旧 API を書く自動処理を残すと失敗するため、管理者だけでなく実利用者とサービスアカウントでも読み書きを確認します。

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

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

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

運用・監視

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

コスト

セキュリティ

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

関連サービス・比較

データの横断検索・発見と意味付けを担う現行サービスが Knowledge Catalog です。データの実体を分析・蓄積する BigQuery とは役割が異なり、カタログで見つけたテーブルを BigQuery で分析します。旧 Data Catalog は移行元としてだけ扱います。

ハンズオン / CLI例

# 1) 移行先APIを有効化
gcloud services enable dataplex.googleapis.com \
  --project=MY_PROJECT

# 2) 利用者と同じ範囲でKnowledge Catalogを検索
gcloud dataplex entries search 'sales' \
  --project=MY_PROJECT \
  --scope=projects/MY_PROJECT

# 3) 移行先の型を確認
gcloud dataplex aspect-types list \
  --location=asia-northeast1 \
  --project=MY_PROJECT

gcloud dataplex entry-types list \
  --location=asia-northeast1 \
  --project=MY_PROJECT