Dataplex Catalogについて

はじめに

こんにちは。クラウドエース データソリューション部所属の橘です。

データソリューション部では、Google Cloud が提供しているデータ領域のプロダクトについて、新規リリースをキャッチアップするための調査報告会を毎週実施しています。
新規リリースの中でも、特に重要と考えるリリースを記事としてまとめ、本ページのように公開しています。

今回紹介するのは、2024年7月8日にGAとなった「Dataplex Catalog」についてです。
また、今まで存在していた「Dataplex's Data Catalog」との違いや考慮点についても簡単に触れさせて頂きます。

Dataplex Catalog リリースノート

Dataplex Catalogとは

一言で言うと「組織内データを管理するためのカタログサービス」です。

ちょっと要約し過ぎかもしれませんので、公式のoverviewの拙訳も記載しておきます。

Dataplex Catalog overview

Dataplex Catalogとは、BigQueryなどのGoogle Cloudリソースや、オンプレミスリソースなどの統一されたインベントリを提供します。
Google Cloudリソースのメタデータは自動的に収集され、サードパーティリソースのメタデータも取り込むことができます。
Dataplex Catalogを使用すると、リソースに関するビジネスおよびテクニカルなメタデータを追加してインベントリを充実させ、リソースに関するコンテキストや知識をキャプチャすることができます。
Dataplex Catalogを利用することで、組織全体でデータの検索と発見が可能になり、データ資産に対するデータガバナンスを実現することができます。

仰々しい言い方になっていますが、端的に言えば「存在しているデータを簡単に管理するためのサービスであり、各種メタデータを簡単に（時には自動的に）取得・保存できるもの」です。
また、フルマネージドサービスであり、細かいインフラ設定などは不要となっています。

主要な概念

Dataplex Catalogでは、幾つか専用の概念が出てきます。それぞれがどのようなものかを把握することで、サービスの全容が把握しやすくなると思いますので、以下にそれぞれの概念について簡単に説明します。

まず最初に、全容をイメージしやすくするため、概念間関係図を示します。

Dataplex Catalogにおける概念間関係図

この図ではエントリグループG1に、エントリタイプAのエントリが3つ＆エントリタイプBのエントリが2つ登録されています。また、エントリタイプBのエントリは両方ともある1つのエントリタイプAのエントリの子エントリとなっています。

以下、この図に登場する用語・概念について説明していきます。

• エントリグループ(entry group)
  　管理対象であるエントリを束ねるコンテナ（箱）です^[1]。Googleが用意するシステムエントリグループと、ユーザが独自に定義するカスタムエントリグループに分類されます。原則としてすべてのエントリは常にちょうど１つのエントリグループに所属するようです。

  • システムエントリグループ(system entry groups)
    Google Cloudリソースのための、Dataplexが自動的に生成するエントリグループです。
  • カスタムエントリグループ(custom entry groups)
    カスタムエントリを格納するために、ユーザが自分で作成するエントリグループです^[2]。

• エントリ(entry)
  管理対象であるデータ資産1つ1つに対応する、Dataplex Catalogにおけるメタデータ管理の単位です。代表的な例として、BigQueryにおけるテーブルは1テーブルが1つのエントリになります。
  エントリは「システムエントリ」と「カスタムエントリ」の2つに分類されます。

  • システムエントリ(system entry)
    Google Cloudリソースに対し、Dataplexが自動的に作成するエントリです。「必須アスペクト」に対応するメタデータが登録・更新共に自動的に行われて便利ですが、ユーザが変更することはできません。追加でメタデータを付与したい場合は、作成されたシステムエントリに対し「オプションのアスペクト」を追加し、そこに値を付与する必要があります。
  • カスタムエントリ(custom entry)
    ユーザが独自に作成するエントリです。エントリを登録する際に選択した「エントリタイプ」に定義した「必須アスペクト」の必須フィールドには必ず値を設定する必要があります。また、システムエントリと同様に、エントリごとに「オプションのアスペクト」を追加し、値を付与することもできます。

  また、エントリには親子関係があり、親エントリの詳細画面における「エントリリスト」タブから確認できます（下記画像を参照）。典型的な例として、BigQueryにおけるデータセットも（テーブルと同様に）1データセットが1つのエントリになりますが、あるデータセットに含まれるテーブル達は、そのデータセットに対応するエントリの子エントリとして自動的に登録されます。
  
  子エントリの表示例

• エントリタイプ(entry types)
  　前述したエントリが、どのようなメタデータを持つべきかを定義する「型」です。
  　こちらの概念も「システムエントリタイプ」と「カスタムエントリタイプ」の２つに分類されます。

  • システムエントリタイプ(system entry types)
    Google Cloudが事前定義したエントリタイプです。システムエントリ作成時に自動的に使われますが、ユーザがシステムエントリタイプを編集したり、システムエントリタイプを使ってカスタムエントリを登録することはできないようです。「bigquery-dataset」や「bigqeury-table」などといったものが代表的です。
  • カスタムエントリタイプ(custom entry types)
    ユーザが定義するエントリタイプです。カスタムエントリを作成するために使用します。
    　カスタムエントリタイプを定義する際、その型を特徴づける要素として以下のものが定義できます。
    • タイプエイリアス(type aliases)：エントリを分類できるタグです。複数付与でき、後から検索するときに利用できます。現時点ではユーザが独自定義することはできず、Googleが用意したもの（Bucket, Cluster, Dataset, Table等）から選ぶだけです。
    • 必須アスペクトタイプ(required aspect types)^[3]：そのエントリタイプに属するエントリに必ず付与する必要があるメタデータ群を、アスペクトを介在して強制できます。たとえば「RDBテーブル」というエントリタイプを定義し、そこに「管理者情報」というアスペクトタイプを必須アスペクトタイプとして定義したとします。そうすると「RDBテーブル」エントリタイプに対応したエントリを作成する際は、必ず「管理者情報」というアスペクトタイプを埋める必要があります。もし「管理者情報」というアスペクトタイプに「氏名」と「メールアドレス」というフィールドが必須フィールドとして定義されていれば、これらの値をメタデータとして登録しないと「RDBテーブル」エントリとして登録できない、ということです。

• アスペクト(aspect)
  　実際にエントリが保持する、アスペクトタイプの「値」です。
  　「アスペクトはアスペクトタイプのインスタンス」なので、あるアスペクトに対し、それに対応するアスペクトタイプがちょうど１つ存在します。

• アスペクトタイプ(aspect types)
  　「エントリに持たせるメタデータの『組』」を定義する「型」です。
  　複数のフィールドを定義したものをひとまとまりの「アスペクトタイプ」として定義します。
  　たとえば「管理者情報」というアスペクトタイプを定義し、その中に必須テキストフィールドとして「氏名」「メールアドレス」を定義したとします。
  そうすると、この「管理者情報」アスペクトタイプが付与されたエントリには、必ず「管理者情報-氏名」と「管理者情報-メールアドレス」の値を定義することが強制されます。
  「アスペクトタイプ」も同様に「システムアスペクトタイプ」と「カスタムアスペクトタイプ」に分類されます。

  • システムアスペクトタイプ(system aspect types)
    Dataplexによって提供され、Google Cloudリソースのメタデータを記述するために用いられます。システムアスペクトタイプは編集・削除ができず、権限を変更することもできません。
    システムアスペクトタイプは、更に「再利用可能なシステムアスペクトタイプ」と「制限付きシステムアスペクトタイプ」に分かれます。
    • 再利用可能なシステムアスペクトタイプ(reusable system aspect type)
      ユーザがカスタムエントリタイプを定義する際に必須アスペクトタイプに指定したり、エントリにオプションのアスペクトとして追加することができます。しかし、前述した通りフィールドの追加・削除などはできません。
      現時点では「generic」「storage」の２つが利用可能なようです^[4]。
    • 制限付きシステムアスペクトタイプ(restricted system aspect type)
      Dataplexが使うためのアスペクトタイプであり、ユーザは直接利用できません。代表的なシステムアスペクトタイプとしては「bigquery-dataset」 「bigquery-table」^[5]などがあります。
  • カスタムアスペクトタイプ(custom aspect types)
    ユーザが独自に定義するアスペクトタイプです。カスタムエントリタイプの必須アスペクトタイプに指定したり、各種エントリの任意アスペクトとして追加指定することができます。
    カスタムアスペクトタイプにはフィールドを定義することができ、値の設定を要求することができます。また、フィールドごとに（値の設定が）必須か任意かを選択できます。
    フィールドには型が指定でき、現時点では以下のものが利用できるようです。

  型	概要	備考
  Text	テキスト	テキストタイプとして「リッチテキスト、URL、リソース」から指定できる（任意）。また、ヒントの文字列も登録可能。
  Integer	整数
  Boolean	ブール値
  Date and Time	日時
  Double	倍精度（実数）型
  Enum	列挙型	列挙子としてテキストのみが利用可能。
  Array	配列	１つ以上の配列アイテムを追加する必要がある。 配列アイテムには同様に型の指定が必要（※Arrayを介して階層構造の実現が可能）。
  Map	マップ	key-value形式の値を設定できる。valueの型も指定が必要。
  Record	記録	型定義を再帰的に再利用するために用いる[6]（詳細は省略）。

まとめ？

Dataplex Catalogは、組織内データを管理するためのカタログサービスであり、メタデータを柔軟に管理するために様々な概念・機能が用意されています。
特に、多くのGoogle Cloudリソースについて自動的にエントリが作成され、各種メタデータが登録されるのはデータマネジメントを行ううえで有用と思われます。
Google Cloud上でデータ分析を行う際には、ぜひ活用を検討してみてください。

ちょっと待って？？

…ですが、ちょっと待ってください。
少しGoogle Cloudの歴史に詳しい方であればご存じかと思いますが…
Google Cloudでは元々「Data Catalog」というサービスがあり(2019/06/27 Beta release, 2020/04/30 GA)、それがDataplexブランドに統合されてDataplex Data Catalogとなり(2022/07/20)現在に至ります。
それと、今回リリースされた「Dataplex Catalog」はいったいどんな関係にあるんでしょうか？

注釈

以下、識別を容易にするため、今まで使えていた「(Dataplex)Data Catalog」のことを「旧Catalog」、今回リリースされた「Dataplex Catalog」のことを「新Catalog」と記載します。

Google CloudのDocument上では「Dataplex Catalog」と「Data Catalog」と区別しているようなのですが、個人的にalphabetが苦手で目が滑るので、漢字を使って書き分けさせて頂きます。ご了承下さい。

公式ドキュメント曰く

公式ドキュメント上では、旧Catalogユーザに対して以下のように注意を促しています。

if you're already using Data Catalog, note the following:

• Custom entries, overview context, and entry groups that you created in Data Catalog are made available in Dataplex Catalog.
• Tags and tag templates created in Data Catalog aren't available in Dataplex Catalog.
• When you search for data assets in Dataplex Catalog, both the metadata that was created in Dataplex Catalog directly and the metadata that was brought from Data Catalog into Dataplex Catalog are included.
• When you search for data assets in Data Catalog, only the metadata that was created in Data Catalog is included.
• The entry group descriptions in Data Catalog that exceed 1024 characters are truncated to 1024 characters in Dataplex Catalog.

日本語に訳するとこんな感じでしょうか。

もし既に 旧Catalog を使用している場合、以下の点に注意してください:

• 旧Catalog で作成したカスタムエントリ、概要コンテキスト、およびエントリグループは 新Catalog で利用可能です。
• 旧Catalog で作成したタグおよびタグテンプレートは 新Catalog では利用できません。
• 新Catalog でデータアセットを検索する際には、直接 新Catalog で作成されたメタデータと、旧Catalog から 新Catalog に持ち込まれたメタデータの両方が含まれます。
• 旧Catalog でデータアセットを検索する際には、旧Catalog で作成されたメタデータのみが含まれます。
• 旧Catalog のエントリグループの説明が1024 文字を超える場合、新Catalog では1024文字に切り詰められます。

個別具体的な差が記述されているため一言で要約するのは難しいですが、「新旧間で完全な互換性はないが、限定的な互換性はある」といったところでしょうか。

また「新Catalog vs. 旧Catalog」という節では、以下のように記載されています。

Dataplex Catalog versus Data Catalog

Dataplex Catalog provides a capability for managing your metadata in Dataplex. It comes with a separate metadata storage and a new set of API methods which > are integrated into the Dataplex API.

The main features of Dataplex Catalog includes the following:

• More robust metamodel
  • Typed entries. You can enforce minimal metadata standards by defining the required metadata content for custom entries
  • User-configurable metamodel for custom entries, which helps to make custom ingestion more robust and improves custom metadata consistency and co> mprehensiveness.
  • Support for a wider variety and complexity of metadata, including support for nesting structures like lists, maps, and arrays.
• Improved scalability, including the ability to interact with all metadata that is associated with an entry through single atomic CRUD operations and the ability to fetch multiple metadata annotations associated in search or list responses.

こちらも日本語に訳すとこんな感じでしょうか。

新Catalog vs. 旧Catalog

新Catalog は、Dataplex 内でメタデータを管理するための機能を提供します。これは、独立したメタデータストレージと、Dataplex API に統合された新しい一連の API メソッドを備えています。

新Catalog の主な機能には以下が含まれます：

• より堅牢なメタモデル
  • 型付きエントリ。カスタムエントリの必須メタデータコンテンツを定義することで、最小限のメタデータ標準を強制できます。
  • カスタムエントリ用のユーザー構成可能なメタモデル。これにより、カスタムインジェストがより堅牢になり、カスタムメタデータの一貫性と包括性が向上します。
  • リスト、マップ、配列などのネスティング構造をサポートする、より多様で複雑なメタデータのサポート。
• 改善されたスケーラビリティ。これには、単一のアトミックな CRUD 操作を通じてエントリに関連付けられたすべてのメタデータと対話する能力や、検索またはリスト応答で関連付けられた複数のメタデータ注釈を取得する能力が含まれます。

ちょっと抽象度の高い説明が多くピンと来づらい説明になっているかもしれませんが、要約すると「必須メタデータの強制^[7]や新しい型が導入されたうえに性能向上もしているよ」ということのようです。

また、これに続いて比較表が２つ掲載されています。
１つ目は「新Catalogと旧Catalogの比較」です。そのままですね。

以下のような内容が記載されています。

Comparison between Dataplex Catalog and Data Catalog

Feature	Dataplex Catalog	Data Catalog
Supported Google Cloud sources	All sources as described in the Supported Google Cloud sources section of this document.	All sources described in Entries and entry groups.
Custom sources ingestion	Ingestion into custom entries with governed structure, defined by entry types. Data Catalog custom entries and entry groups are made available in Dataplex Catalog under the generic entry type.	Ingestion into generic custom entries.
Metadata enrichment	Metadata context for entries is captured using aspects and aspect types.	Metadata context for entries is captured using tags and tag templates.
Search	Search is performed over the following: All Google Cloud sources described in Supported Google Cloud sources Custom entries that are created in Dataplex Catalog Aspects that are created in Dataplex Catalog Custom entries that are created in Data Catalog and are brought into Dataplex Catalog The search results include only those resources that belong to the same VPC-SC perimeter as the project under which search is performed. When using the Google Cloud console, this is the project that is selected in the console. Note that, to search for entries, you need at least one of the Dataplex Catalog IAM roles on the project that is used for search. Permissions on search results are checked independently of the selected project.	Search is performed over the following: All Google Cloud sources described in Entries and entry groups Custom entries that are created in Data Catalog Tags that are created in Data Catalog

これも翻訳すると以下のようになります。

新Catalogと旧Catalog間の比較

機能	新Catalog	旧Catalog
サポートされるGoogle Cloudソース	このドキュメントの サポートされるGoogle Cloudソース セクションに記載されているすべてのソース。	エントリとエントリグループに記載されあているすべてのソース。
カスタムソースのインジェスト	エントリタイプによって定義された構造を持つカスタムエントリへのインジェスト。 旧Catalogのカスタムエントリとエントリグループは、一般的なエントリタイプの下で新カタログで利用可能です。	一般的なカスタムエントリへのインジェスト。
メタデータの強化	エントリのメタデータコンテキストは、アスペクトとアスペクトタイプを使用してキャプチャされます。	エントリのメタデータコンテキストは、タグとタグテンプレートを使用してキャプチャされます。
検索	以下の項目について検索が行われます： サポートされるGoogle Cloudソースに記載されているすべてのGoogle Cloudソース 新カタログで作成されたカスタムエントリ 新カタログで作成されたアスペクト 旧カタログで作成され、新カタログに持ち込まれたカスタムエントリ 検索結果には、検索が行われたプロジェクトと同じVPC-SC境界に属するリソースのみが含まれます。Google Cloudコンソールを使用する場合、これはコンソールで選択されたプロジェクトです。 エントリを検索するには、検索に使用されるプロジェクトで少なくとも１つのDataplex Catalog IAMロールが必要です。検索結果の権限は選択されたプロジェクトとしては独立してチェックされます。	以下の項目について検索が行われます： エントリとエントリグループに記載されているすべての Google Cloud ソース 旧カタログで作成されたカスタムエントリ 旧カタログで作成されたタグ

また、「新Catalogでサポートされない機能」という節があるのですが、内容としては「旧カタログにはあったが新カタログでは利用できない機能の一覧」になっています。

原文は以下の通りです。

Features that aren't supported in Dataplex Catalog

The following features that are available in Data Catalog are not supported in Dataplex Catalog:

• The notion of private aspects and aspect types isn't supported in Dataplex Catalog. Access to aspects is governed by permissions that are associated with the entry that contains the aspects. For more information, see Dataplex IAM roles.
• Search for policy tags isn't supported in Dataplex Catalog search; consequently, the predicates policytag and policytagid don't work in the Dataplex Catalog search.
• For Data Catalog custom entries that are brought into Dataplex Catalog, the existing IAM permissions for your current metadata aren't automatically propagated to copied metadata. You must explicitly configure IAM permissions for the copied metadata before using it.
• Sending Sensitive Data Protection job results to Dataplex Catalog isn't supported.
• You can't list entry types and aspect types across projects using the API. You can scope the list request to a project only.
• You can't attach business glossary terms to the columns of Dataplex entries.
• You can't modify the list of required aspect types in an entry type after you create the entry type.

こちらの日本語訳は以下の通りです。

新カタログでサポートされない機能

旧カタログで利用可能な以下の機能は、新カタログではサポートされていません：

• 非公開アスペクトおよび非公開アスペクトタイプの概念は、新Catalog ではサポートされていません。アスペクトへのアクセスは、アスペクトを含むエントリに関連付けられた権限によって管理されます。詳細については、Dataplex IAM ロールを参照してください。
• ポリシータグの検索は 新Catalog の検索ではサポートされていません。そのため、 policytag および policytagid の述語は 新Catalog の検索では機能しません。
• 新Catalog に持ち込まれた 旧Catalog のカスタムエントリについて、現在のメタデータに対する既存の IAM 権限はコピーされたメタデータに自動的には伝播されません。コピーされたメタデータを使用する前に、明示的に IAM 権限を設定する必要があります。
• 機密データ保護ジョブの結果を 新Catalog に送信することはサポートされていません。
• API を使用してプロジェクトを跨いでエントリタイプおよびアスペクトタイプを一覧表示することはできません。リストリクエストのスコープは単一のプロジェクトに限定されます。
• ビジネス用語集の用語を Dataplex エントリの列に添付することはできません。
• エントリタイプを作成した後に、そのエントリタイプに必要なアスペクトタイプのリストを変更することはできません。

この項目は直接的に新旧の差が記述されているので詳しくみてみます。
まず「非公開アスペクト＆非公開アスペクトタイプはサポートされていないよ」と突然宣言されていますが、これは１つ前の新旧比較表上の「メタデータの強化」機能において「新Catalogのアスペクト＆アスペクトタイプと旧Catalogのタグ＆タグテンプレートは対応しているよ」と示唆していること、および「旧Catalogには公開タグレンプレートと非公開タグテンプレートが存在した」ということから、自然に「新Catalogのアスペクト＆アスペクトタイプにも公開と非公開の種類があるのかな？」と予想するユーザに対する先回りした回答、ということのようです^[8]。
次に「ポリシータグ^[9]の検索は新Catalogではサポートされていません」とあります。これは純粋な機能差異のようです。
「機密データ保護ジョブの結果を新Catalogに送信することはサポートされていません」も同様で、新Catalogとの（自動的な）連携は未サポートということのようです^[10]。
「（APIを使用して）プロジェクトを跨いでエントリタイプおよびアスペクトタイプを一覧表示できません」というのは、旧Catalogでは（閲覧権限がある）タグテンプレートはプロジェクトを跨いで確認できていたものが、新Catalogではできません（いま注目しているプロジェクトのものしか確認できません）、ということのようです。
「ビジネス用語集の用語をDataplexエントリの列に添付することはできません」というのは、ビジネス用語集で定義した用語を旧Catalogの用語を列に付け加えるという機能が新Catalogではなくなっている、ということのようです。
「エントリタイプを作成した後に、そのエントリタイプに必要なアスペクトタイプのリストを変更することはできません」は言葉の通りで、一度定義したエントリタイプは互換性を保つために「何が必須か」という情報を変更することはできない（足すことも引くこともできない）ようです^[11]。

強引に要約

ここまで（新旧比較について）記載させて頂いたことから、現状かなり沢山の情報があり、かつ簡潔な要約が難しい状況であることはご理解頂けたかと思います。
最後に、分かりやすさのため、敢えて（正確性を犠牲にしつつ）独断と偏見を以って要約すると以下のようになります。

全体要約

• 旧カタログとは別に新カタログができた
• アップデートではなく別サービス
• 旧カタログで定義したタグやエントリは新カタログから検索できるなど、一定程度相互運用性(interoperability)がある
• 一部の機能は相互運用できない

旧カタログだけを使い続けるつもりのユーザが気にすること

• 現時点では特に気にすることはない（メニューやドキュメント、サービスの呼び名等には注意）
• 新カタログが出てきたことにより旧カタログの持続性に懸念を感じるのもやむを得ないが、現時点では公式アナウンスはないため持続性リスクは自己判断せざるを得ない^[12]

旧カタログを使っているが新カタログに興味があるユーザが気にすること

• 新カタログと旧カタログは排他的関係ではないため、旧カタログでデータを管理しつつ、新カタログの機能を試すという使い方が可能
• 一部の機能（ポリシータグや機密データ保護ジョブの結果反映など）は新カタログに対応していないため注意する

これから新規利用するユーザが気にすること

• 基本的に新カタログを中心に利用するのが無難と思われるが、新旧間で機能差異があるため要件に応じて判断する

改めてのまとめ

以上、旧カタログと新カタログの差も交えてまとめさせていただきました。
公式に新旧の使い分けであったり旧カタログの立ち位置についてのアナウンスが見当たらないため歯切れの悪い記事になってしまっていますが、ご容赦頂ければ幸いです…。

おそらく新カタログはこのあとも継続的に機能が追加されていくと思われますので、今後の推移も見守っていきたいと思います。

脚注

1. 原文では「エントリグループはエントリ達の権限管理やリージョンロケーション管理に利用できる （You can use entry groups to manage access control and regional location for the entries.） 」と書かれているのですが、現時点では具体的な使い方の手順がわかりませんでした。もしかしたら将来的にリリースされる機能に含まれるのかもしれません。これが出来るとかなり便利そうなので期待したいところです。

2. 「システムエントリは自動的にシステムエントリグループに登録される」＆「各エントリはちょうど１つのエントリグループにしか所属しない」＆「エントリグループ間のエントリ移動はできない」ことから「カスタムエントリグループに所属させられるのはカスタムエントリのみ」のようです。

3. ややこしい点なのですが「任意アスペクトタイプ」というのはありません（少なくとも執筆時点では）。アスペクトタイプの使い道は2つで「エントリタイプ定義時に必須アスペクトタイプとして使用する」か「既存エントリにオプションのアスペクトとして追加する際、型として指定する」のいずれかのようです。

4. 他にも「overview」「contacts」「schema」が再利用可能なシステムアスペクトタイプとして定義されていますが、これらは「使うな」と書かれている（Don't use the system aspect types overview, contacts, and schema.）ため使ってはならないようです（※UI上は指定できてしまいます）。

5. 「bigquery-dataset」「bigquery-table」どちらも、同じ名前でシステムエントリタイプとしてもシステムアスペクトタイプとしても登録されています（システムエントリタイプbigquery-tableの必須アスペクトタイプとして、システムアスペクトタイプのbigquery-tableが指定されている）。ややこしい…。

6. 試しにCloud ConsoleからRecord型を持つカスタムアスペクトをカスタムエントリに付与しようとしたら「Selected aspect type is not supported in the UI and should be managed through APIs.」というエラーが表示されました。現時点ではCloud ConsoleからのRecord型カスタムアスペクトの設定はサポートされていないようです。

7. ただ、元々旧Catalogでもタグテンプレートでフィールドの強制は出来ていたので、ここでいう「最小限のメタデータ標準を強制できます」という要素のどこが新しいのかは判然としないように思えます…。

8. なお、旧Catalogにおける「公開タグ」と「非公開タグ」には、以下のような違いがあります。
   公開タグ：データエントリ（そのメタデータに対応した実際のリソース）の表示権限を持つユーザであれば誰でも関連づけられたすべての公開タグを閲覧できる。また、シンプル検索と述語付き検索の両方をサポートする。
   非公開タグ：非公開タグテンプレートとデータエントリの両方に対する表示権限を持っているユーザのみがタグとそのタグが関連付けられているデータエントリを検索または表示できる。述語付き検索のみをサポートする。

9. 念のため補足すると、ここで出来ないといっているのは「旧Catalogのタグ」ではなく「BigQueryポリシータグ」の検索です。

10. これは機密データ保護ジョブの結果を旧Catalogに送信するの項目で説明されている内容（保護ジョブで検出された結果を自動的にタグテンプレートの形式で連携すること）が新Catalogではできない、ということのようです。

11. ただ、そもそもアスペクトの概念自体が新カタログのものなので「新旧の差」としてアスペクトに関する内容が記述されているのはイマイチ意図が読めないです…。

12. 念押しですが、新Catalogも既にpreviewではなくGA(Generally Available)となっているため、新Catalogが突然サービス停止される可能性はないと考えてよいかと思います（最低でも１年程度前に事前予告があると期待してよいかと思います）。