tencent cloud

Tencent Cloud DataBuddy

DocumentaçãoTencent Cloud DataBuddyData GovernanceData Catalog OverviewThree-Level Namespace (Catalog / Schema / Object)

Three-Level Namespace (Catalog / Schema / Object)

Baixar
Modo Foco
Tamanho da Fonte
Última atualização: 2026-10-09 16:15:11
Traduzido por IA

Overview

The DataBuddy data catalog uses a three-level namespace to organize and locate all data assets. Any table, view, volume, or model is uniquely identified by a three-part path in the form of catalog.schema.object. The three-level namespace provides a unified reference for cross-workspace sharing, fine-grained authorization, and asset search.
This document describes the hierarchy, naming rules, reference methods, and usage in SQL and Notebook of the three-level namespace.

Namespace Structure

MetaLake (region + tenant level, metadata lake)
└── Catalog (top-level namespace, whose type determines the assets it can host)
└── Schema (middle-level namespace, similar to a Database)

    └── Asset objects (Table / View / Volume / Model)

        └── Field / File (only specific asset types have a four-level hierarchy)


Responsibilities of Each Level

Layer
Analogy
Responsibilities
Catalog
Database instance / data warehouse
Top-level namespace that determines the underlying storage location and asset type
Schema
Database
Divides objects by business subject, project, or environment; equivalent to DATABASE in SQL.
Object
Tables, views, volumes, and models
Assets that actually carry data or metadata

Path and Reference Format

Three-Part Reference in SQL

In SQL files in Studio, Spark SQL cells in Notebook, and Workflow SQL tasks, you can use a three-part path to reference objects under any Catalog:

Volume Path Reference

A Volume is a container for unstructured data, and access to files under it uses a path prefixed with /Volumes/:
/Volumes/<catalog>/<schema>/<volume>/<directory>/<file>
For example:
/Volumes/ops_catalog/raw_logs/access_log/2026-06-06/access.log

Model URI Reference

A model has two additional levels of identification above the three-level namespace: version and alias. A complete model URI is in the following format:
models:/<catalog>.<schema>.<model_name>/<version>
models:/<catalog>.<schema>.<model_name>@<alias>
For example:
models:/ml_catalog.recsys.deepfm_model/3
models:/ml_catalog.recsys.deepfm_model@champion

Naming Rules

Naming Constraints

Element
Rule
Catalog name
Globally unique within the same MetaLake; default is a system reserved name and cannot be created or modified.
Schema name
Unique within the same Catalog; information_schema and default are Schemas automatically created by the system when the Catalog is created.
Object name (table / view / volume / model)
Unique within the same Schema
Character Set
Detailed naming constraints (length, valid characters, and case sensitivity) are determined by the underlying engine.
Note:
default is a system-reserved Catalog name, so you cannot create a Catalog with the same name. information_schema and default are Schema names automatically generated after Catalog creation, and you cannot manually create or rename them.

Auto-Initialized Objects

When you enter the data Catalog for the first time: the system automatically creates two built-in Catalogs, default and system.
After a Catalog is created: the system automatically creates two Schemas, information_schema and default. The content of the default Schema is initially empty.

Browsing the Three-Level Namespace in Studio

DataBuddy Studio provides a Data Catalog entry in the left navigation, and you can expand Catalog → Schema → Object → Field level by level in a tree structure:
1. Go to Studio and select Data Catalog in the left navigation.
2. Click a Catalog or Schema in the tree to expand it downward. When you hover over a field or table name, you can use the insert button to insert the name into the IDE editor on the right.
3. You can perform a global fuzzy search for Catalog / Schema / asset names through the top search box, with up to 200 results returned. After a match is found, the Catalog tree automatically expands to the corresponding node.
4. You can use filters to display only assets of a specified type (Table, Model / Volume / All).
For detailed operations, see Data Catalog Navigation.

Full Names and Cross-Workspace References

Every object has a Fully Qualified Name in the format catalog.schema.object. A fully qualified name is the standard way to reference an object across workspaces:
Reference scenario
Recommended syntax
Cross-workspace query
<catalog>.<schema>.<table>
Single workspace with context specified
<table> or <schema>.<table>
Describing asset location in alarms / documents
Use the three-level full name for easier search.
API / SDK call
Use the three-level full name as the identifier parameter.

Use Limits

Limit
Description
System Reserved Name
information_schema / default cannot be used as Schema names.
Cross-Catalog Join
Cross-Catalog join query capability depends on the underlying compute engine. DLC Spark already supports basic cross-Catalog join queries.
Model Object Hierarchy
A model has two additional layers above the three-level namespace: version and alias. For details, see Model Catalog.

FAQs

Q: Why is a three-level namespace needed? Is a two-level namespace (Schema.Table) not enough?
A: The three-level namespace provides a top-level division for asset isolation and cross-workspace sharing in multi-business-line and multi-project scenarios. For example, you can create separate Catalogs for different business lines (marketing_catalog, finance_catalog), and then divide Schemas by subject within each business line to avoid naming conflicts. This also facilitates batch authorization by Catalog.
Q: Is a Catalog with the same name the same one across different workspaces?
A: Yes. A Catalog is registered on MetaLake and is visible across workspaces. A Catalog created in Workspace A can be seen under the same name in other workspaces in the same region, and it is actually the same object. Whether its internal data can be accessed depends on the permission policies and the workspace access scope.
Q: Is the syntax for cross-Catalog references consistent between Spark and SQL tasks?
A: They are basically the same. The three-part syntax catalog.schema.object is already supported in DLC Spark SQL. Before execution, make sure that the current compute resource has the use catalog and use schema permissions on the target Catalog.

References

Unified Metadata Management Architecture
Structured Data Catalog
Unstructured Data Catalog
Model Catalog
Data Catalog Navigation
Anterior: Unified Metadata Management ArchitecturePróximo: Structured Data Catalog (Table, View, and Schema Management)

Ajuda e Suporte

Esta página foi útil?

comentários

Search
    Enter keywords to search documentation