OCI Data Catalog

解決する課題

データが Object Storage、Autonomous Database、各種データベースなどに散在すると、「どこに・何のデータがあり・誰が所有し・どういう意味か」が分からなくなります。OCI Data Catalog は、これらのメタデータを一箇所に集めて横断的に検索・把握できるようにします。

• どこにどんなデータがあるか分からず、データ資産の所在を把握できない
• 同じ列名でも部署ごとに意味が違うなど、用語・定義が統一されていない
• 機密データの所在や分類が見えず、ガバナンス・コンプライアンスを効かせにくい
• 分析者がデータを探すたびに手作業で調査しており、再利用が進まない

主要概念と用語

• Data Catalog（データカタログ）: メタデータを集約・管理する論理的な入れ物。テナンシ／コンパートメント内に作成する
• Data Asset（データ資産）: カタログが接続する対象のデータソース（Object Storage、Autonomous Database、各種データベース、Hive など）。AWS の Glue における接続先データストアに相当
• Connection（接続）: データ資産へ実際にアクセスするための認証情報・接続定義
• Harvest（ハーベスト／収集）: データ資産を走査し、スキーマやテーブル・列などの技術メタデータを取り込む処理。AWS Glue のクローラに相当
• Entity / Attribute（エンティティ／属性）: 収集されたテーブル相当（エンティティ）とその列相当（属性）
• Glossary（用語集）と Term（用語）: ビジネス用語とその定義を体系化したもの。データにビジネス上の意味を与える
• Category（カテゴリ）: 用語を階層的に整理する分類の単位
• Tag（タグ）: エンティティや属性に付与する分類ラベル。検索やガバナンスに使う
• Custom Property（カスタムプロパティ）: 標準項目に加えて独自に定義できるメタデータ項目
• Search（検索）: 収集したメタデータ・用語・タグを横串で探す機能

仕様・制限・クォータ

• カタログはリージョン内のリソースであり、コンパートメントに属する。複数リージョンに展開する場合はリージョンごとに作成する
• ハーベストはメタデータのみを収集し、データ本体（実レコード）はカタログ内に複製しない
• 収集対象は接続可能なデータ資産に依存し、Object Storage / Autonomous Database / 各種データベース / Hive メタストアなどが代表的
• ハーベストは手動実行のほか、ジョブとしてスケジュール実行できる
• 1 テナンシ・リージョンあたりに作成できるカタログ数やデータ資産数などにサービス制限があり、必要に応じて引き上げ申請が可能
• 具体的な上限値はリージョンや時期で変動するため、最新値は公式ドキュメントとコンソールの制限画面で確認する

内部の仕組み

OCI Data Catalog は、データ資産への接続を定義し、そこからスキーマ情報をハーベストして、エンティティ・属性として保存します。保存されるのはメタデータであり、実データはソース側に残ったままです。収集した技術メタデータに対し、利用者が用語集・タグ・カスタムプロパティといったビジネスメタデータを紐付けることで、技術的な情報とビジネス的な意味を結び付けます。

• 接続情報のパスワード等の機密値は OCI Vault のシークレットとして安全に保持できる
• ハーベストはオンデマンドまたはスケジュールで実行され、ソースの変更を再収集して最新化する
• 収集されたメタデータと用語・タグは検索インデックスに取り込まれ、横断検索の対象になる
• 他サービス（例: Data Integration や分析ツール）から、カタログのメタデータを参照してデータの所在・スキーマを把握できる

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

• まずデータ資産と接続を整理し、命名規約とコンパートメント設計をそろえてからハーベストする
• ハーベストはスケジュール実行し、ソースのスキーマ変更に追従させてメタデータの陳腐化を防ぐ
• 用語集（Glossary）を先に整備し、部署をまたいだ用語の意味を統一してからエンティティへ紐付ける
• タグとカスタムプロパティで機密区分・オーナー・更新頻度などを表現し、ガバナンスと検索性を両立する
• Data Integration（ETL）や分析サービスと組み合わせ、カタログを起点にデータパイプラインを設計する
• 機密データを扱うソースは、Data Catalog で所在を可視化しつつ、実データ側の保護は Data Safe などと役割分担する

運用・監視

• カタログ・データ資産・用語集の作成／変更／削除などの操作は OCI Audit に記録され、ガバナンスの証跡になる
• ハーベストはジョブとして実行されるため、ジョブの成功／失敗を確認し、失敗時は接続情報やネットワーク到達性を点検する
• 接続先のスキーマが変わったら再ハーベストしてメタデータを最新化する
• 用語集・タグの**運用ルール（誰が登録・承認するか）**を決め、メタデータの品質を維持する

コスト

OCI Data Catalog のコストは、利用形態（カタログの稼働やハーベスト・メタデータ量など）に応じた従量的な考え方で発生します。実データを保持しないため、データ本体のストレージ費用とは別である点が特徴です。最新かつ正確な料金は公式の料金ページで確認してください。

セキュリティ

• アクセス制御は IAM ポリシーで行い、カタログ・データ資産・用語集ごとに最小権限を割り当てる
• 接続情報のパスワードなど機密値は OCI Vault のシークレットに格納し、平文での保持を避ける
• 操作の証跡は OCI Audit に残り、誰がいつメタデータを変更したかを追跡できる
• カタログには機密データの所在や分類が集まるため、カタログ自体への閲覧・編集権限を厳格に管理する
• VCN 内のプライベートなデータ資産に接続する場合は、ネットワーク到達性（プライベートエンドポイント等）を適切に設計する

Well-Architected の観点

• セキュリティ: メタデータと分類情報を一元管理することで、機密データの所在を可視化し、IAM と Vault でアクセスと接続情報を保護する。データガバナンスの基盤となる
• 運用性（Operational Excellence）: ハーベストの自動化と用語集・タグの運用ルールにより、データ資産の状態を継続的に把握できる。Audit による証跡で監査対応も容易になる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. データカタログを作成
oci data-catalog catalog create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name demo-catalog

# 2. カタログ一覧を確認（カタログIDを後続で利用）
oci data-catalog catalog list \
  --compartment-id ocid1.compartment.oc1..xxxx

# 3. 利用可能なデータ資産タイプ（接続先の種類）を確認
oci data-catalog type list \
  --catalog-id ocid1.datacatalog.oc1..xxxx \
  --type-category dataAsset

# 4. メタデータを横断検索（キーワードで検索）
oci data-catalog search query \
  --catalog-id ocid1.datacatalog.oc1..xxxx \
  --search-criteria-query "sales"