メタデータ変更フィードについて

このドキュメントでは、Knowledge Catalog（以前の Dataplex Universal Catalog）のメタデータ変更フィードの概要について説明します。これらのメタデータ変更フィードを使用すると、Knowledge Catalog インスタンスのメタデータの変更をほぼリアルタイムで追跡し、それらの変更に基づいてイベント ドリブン ワークフローを構築できます。

メタデータ変更フィードの仕組み

Knowledge Catalog では、エントリは BigQuery テーブルなどのデータアセットを表し、アスペクトはエントリにアタッチされた関連するメタデータ フィールドのセットで、エントリを記述します。エントリまたはアスペクトが作成、更新、削除されると、Knowledge Catalog は指定した Pub/Sub トピックに通知メッセージをパブリッシュします。これらの通知（メタデータ変更フィードとも呼ばれます）には、変更に関する情報が含まれます。これには、変更が発生した日時、変更されたリソース、変更のタイプが含まれます。エントリとアスペクトの詳細については、Knowledge Catalog でのメタデータ管理についてをご覧ください。

次のアーキテクチャ図は、Knowledge Catalog がメタデータの変更（作成、更新、削除）をキャプチャし、ダウンストリームのイベント ドリブン ワークフローのために Pub/Sub にプッシュする方法を示しています。

Dataplex メタデータの変更が Pub/Sub にパブリッシュされ、ダウンストリーム サブスクライバー ワークフローによって使用されます。
図 1.メタデータ変更フィードの概要

通知を生成する変更を制御するには、特定のモニタリング対象リソースをメタデータ変更フィードで構成します。これを行うには、組織全体、特定のプロジェクト、特定のエントリ グループなどのスコープを指定します。 スコープを使用すると、モニタリングするリソースを定義できますが、フィルタを使用して、 Knowledge Catalog が通知を送信するタイミングをさらに絞り込むことができます。たとえば、bigquery-table タイプのテーブルが更新された場合にのみ通知を受け取り、作成または削除された場合は通知を受け取らないようにすることができます。これを行うには、エントリタイプ、アスペクト タイプ、変更タイプ（CREATE、UPDATE、DELETE）に基づいて、1 つ以上のフィルタをメタデータ変更フィードに適用します。

たとえば、オンライン小売業者は BigQuery を使用して、専用プロジェクトで商品在庫を管理しています。在庫テーブルのスキーマ変更のみをモニタリングするには、プロジェクトをスコープとしてメタデータ変更フィードを作成し、entry_type=bigquery-table と change_type=UPDATE のフィルタを適用します。product_stock などの重要なテーブルのスキーマが更新されると、この変更により、メタデータ変更フィードのフィルタに一致する UPDATE 通知が生成されます。メタデータ変更フィードは、Pub/Sub トピックに通知を送信します。この Pub/Sub トピックに登録されている自動ワークフローは、ダウンストリームのレポート パイプラインを直ちに一時停止し、広告在庫管理チームにアラートを送信して、不整合なデータに基づく意思決定を防ぐことができます。

メタデータ変更フィードのユースケース

メタデータ変更フィードは、次のようなさまざまな目的で使用できます。

  • メタデータの同期: Knowledge Catalog のメタデータの変更を外部またはサードパーティのデータカタログまたは検索インデックスに継続的に同期します。
  • ポリシーの適用: エントリのデータ分類アスペクトが変更されたときに、セキュリティ ポリシーを自動的に適用または更新します。
  • データ品質の自動化: テーブルのスキーマが変更されたときに、データ品質スキャンをトリガーするか、データ所有者にアラートを送信します。
  • ETL/ELT のトリガー: 新しいテーブル エントリが作成または更新されたときに、データ変換ジョブを開始します。
  • 監査: コンプライアンスのために、すべてのメタデータの変更を監査テーブルに記録します。

コアコンセプトと構成

メタデータ変更フィードは、エントリとアスペクトのメタデータの変更（作成、更新、削除）をモニタリングし、Pub/Sub トピックに通知を送信する Knowledge Catalog リソースです。API では、このリソースは metadataFeeds（projects/PROJECT_ID/locations/LOCATION/metadataFeeds/FEED_ID）と呼ばれます。

メタデータ変更フィードを構成するには、スコープ、フィルタ、宛先を定義します。メタデータ変更フィードのスコープとフィルタに一致するメタデータの変更が発生すると、Knowledge Catalog は宛先の Pub/Sub トピックに通知メッセージをパブリッシュします。

メタデータ変更フィードの構成

メタデータ変更フィードを構成するには、次のものを定義します。

  • スコープ: 組織全体、特定のプロジェクト、特定のエントリ グループなど、変更をモニタリングするリソースのセット。API では、リソース名を指定します。次の例は、 エントリ グループのリソース名形式を示しています: projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID。

  • フィルタ: エントリタイプ、アスペクト タイプ、変更タイプ（CREATE、UPDATE、DELETE）に基づいて、通知を生成する変更をフィルタする条件。API では、リソース名を指定します。次の 例は、エントリタイプのリソース名形式を示しています: projects/PROJECT_ID/locations/global/entryTypes/ENTRY_TYPE。フィルタを指定しない場合、フィードのスコープ内のすべての変更タイプ（CREATE、UPDATE、DELETE）で通知が生成されます。

  • 宛先: Knowledge Catalog が通知メッセージをパブリッシュする Pub/Sub トピック。API では、トピック名を指定します。次の例は、Pub/Sub トピックのリソース名 形式を示しています: projects/PROJECT_ID/topics/TOPIC_ID。

次の例は、プロジェクト PROJECT_ID_1 と PROJECT_ID_2 の CREATE イベントをモニタリングし、TOPIC_ID に通知を送信するように構成されたメタデータ変更フィードを示しています。

{
  "scope": {
    "projects": [
      "projects/PROJECT_ID_1",
      "projects/PROJECT_ID_2"
    ]
  },
  "filter": {
    "changeTypes": [
      "CREATE"
    ]
  },
  "pubsubTopic": "projects/PROJECT_ID_PUBSUB/topics/TOPIC_ID"
}

メタデータ変更フィードの作成と管理の手順については、 メタデータ変更フィードで通知を受け取るをご覧ください。

通知メッセージの形式

メタデータの変更によって通知がトリガーされると、Knowledge Catalog は指定された Pub/Sub トピックにメッセージをパブリッシュします。変更 イベントの詳細は、Pub/Sub メッセージでキャプチャされます。メッセージは、フィルタリング用の属性と、変更の詳細を含むデータ ペイロードで構成されます。

これらのメッセージの使用方法の詳細については、通知メッセージ を使用するをご覧ください。

属性

属性を使用すると、トピック内のメッセージをフィルタできます。Pub/Sub サブスクリプション フィルタを使用して、サブスクリプションでメッセージ をフィルタできます。

属性には次のフィールドが用意されています。

  • timestamp: 変更が発生したときのタイムスタンプ。
  • entry_name: エントリのリソース名（ projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID/entries/ENTRY_ID の形式）。
  • feed_name: メタデータ変更フィードのリソース名（ projects/PROJECT_ID/locations/LOCATION/metadataChangeFeeds/FEED_ID の形式）。
  • entry_type: エントリタイプのリソース名（ projects/PROJECT_NUMBER/locations/LOCATION/entryTypes/ENTRY_TYPE_ID の形式）。 詳細については、エントリタイプをご覧ください。
  • entry_change_type: 変更のタイプ（CREATED、UPDATED、DELETED）。

次の例は、エントリ作成イベントの属性を示しています。

{
  "feed_name": "projects/PROJECT_ID/locations/LOCATION/metadataFeeds/FEED_ID",
  "entry_change_type": "CREATE",
  "timestamp": "2026-02-03T23:12:03.054469Z",
  "entry_type": "projects/PROJECT_NUMBER/locations/global/entryTypes/ENTRY_TYPE_ID"
}

データ ペイロード

Pub/Sub メッセージのデータ ペイロードは、変更の詳細を含む JSON 文字列です。

データ ペイロードの例を次に示します。

{
  "entryName": "projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID/entries/ENTRY_ID",
  "fullyQualifiedName": "bigquery:PROJECT_ID.DATASET_ID.TABLE_ID",
  "updatedAspects": [
    "projects/PROJECT_NUMBER/locations/global/aspectTypes/updated-aspect-type"
  ],
  "createdAspects": [
    "projects/PROJECT_NUMBER/locations/global/aspectTypes/created-aspect-type"
  ],
  "deletedAspects": [
    "projects/PROJECT_NUMBER/locations/global/aspectTypes/deleted-aspect-type"
  ]
}

VPC Service Controls の注意事項

メタデータ変更フィードは、VPC Service Controls（VPC-SC）に準拠しています。

  • メタデータ変更フィードが組織スコープの場合、メタデータ変更フィードの VPC Service Controls 境界内のプロジェクトのみが通知を生成します。

  • メタデータ変更フィードがプロジェクト スコープまたはエントリ グループ スコープの場合、指定されたすべてのプロジェクトまたはエントリ グループは、メタデータ変更フィードと同じ VPC Service Controls 境界内に存在する必要があります。そうでない場合、メタデータ変更フィードの作成は失敗します。

割り当てと上限

メタデータ変更フィードに関連する割り当てについては、 Knowledge Catalog の割り当てと上限をご覧ください。

メタデータ変更フィードの次の制限事項を確認してください。

  • 配信: メタデータ変更フィードは、「少なくとも 1 回」ベースで通知を配信します。サブスクライバーで重複する可能性のあるメッセージを処理する必要があります。

  • 順序: Knowledge Catalog では、メッセージ配信の順序は保証されません。

  • レイテンシ: メタデータ変更フィードの通知はほぼリアルタイムです。

  • 有効化の遅延: 新しく作成または更新されたメタデータ変更フィードの構成は、バックエンドでのキャッシュにより、有効になるまでに最大 10 分かかることがあります。

  • ペイロード: 最初の通知メッセージには、変更シグネチャのみが含まれます。たとえば、エントリ名、エントリタイプ、変更タイプ、変更されたアスペクト タイプまたはキーのリストが含まれますが、実際に変更されたデータ（アスペクト ペイロード）は含まれません。必要に応じて、 Dataplex API （GetEntry）を呼び出して、エントリまたはアスペクトの現在の状態を取得する必要があります。

  • 汎用ストレージ アスペクト: メタデータ変更フィードは、汎用ストレージ アスペクトをサポートしていません。

料金

Knowledge Catalog メタデータ変更フィードに直接料金はかかりません。 ただし、Pub/Sub メッセージの配信、ストレージ、データ エグレスなど、使用したリソースに対して料金が発生します。 Pub/Sub の料金をご覧ください。

次のステップ