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

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

メタデータの変更の自動モニタリング

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

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

Dataplex メタデータの変更が Pub/Sub にパブリッシュされ、サブスクライバーによって使用される仕組みを示す図。
図 1. メタデータ変更フィードの概要

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

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

ユースケース

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

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

用語

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

メタデータ変更フィードを構成するには、スコープ、フィルタ、宛先を定義します。メタデータ変更フィードのスコープとフィルタに一致するメタデータ変更が発生すると、Dataplex Universal 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）で通知が生成されます。

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

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

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

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

通知メッセージの形式

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

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

属性

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

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

  • timestamp: 変更が発生した時点のタイムスタンプ。
  • entry_name: エントリのリソース名（projects/PROJECT_ID/locations/LOCATION/entryGroups/ENTRY_GROUP_ID/entries/ENTRY_ID 形式）。
  • entry_fqn: エントリの完全修飾名。
  • 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",
  "full_qualified_name": "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 境界内に存在する必要があります。そうでない場合、メタデータ変更フィードの作成は失敗します。

割り当てと上限

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

メタデータ変更フィードには、次の制限事項があります。

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

  • 順序: Dataplex Universal Catalog は、メッセージ配信の順序を保証しません。

  • レイテンシ: ほぼリアルタイムですが、通知の目標レイテンシは 3 ～ 10 分です。

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

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

料金

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

次のステップ