概述
DataBuddy 的数据目录（Catalog）采用统一元数据管理架构，将数据湖中所有可被消费的资产实体——表、视图、卷（Volume）、模型，以及来自外部数据源的元数据——集中注册到同一个目录服务中。数据工程师可以通过单一入口发现所有数据资产，并查看它们之间的上下游血缘关系。
本文介绍数据目录的整体架构、关键组件，以及它与传统数据源管理方式的差异。
架构总览
数据目录由三层组成：
层级 | 角色 | 说明 |
MetaLake（元数据湖） | 元数据存储 | 地域级元数据服务实例，每个租户在每个地域默认拥有一份 MetaLake，所有 Catalog 都注册在 MetaLake 之下 |
Catalog | 命名空间顶层 | MetaLake 下可创建多个 Catalog，每个 Catalog 拥有独立的存储路径与类型，跨工作空间可见 |
Schema / 资产 | 命名空间次层与对象 | Catalog 下按 Schema 组织数据库；Schema 下挂载表、视图、卷、模型等资产对象 |
存储路径默认遵循下述规则，存放在腾讯云 COS：
cos://<bucket>/root/workspaces/<catalogN>/...
关键组件
MetaLake（元数据湖） ：地域级、租户级的元数据中枢。它维护所有 Catalog 的注册信息、Schema 与资产的元数据、权限策略、血缘关系。同一租户在每个地域只有一份 MetaLake。
Catalog ：可创建的元数据命名空间。Catalog 拥有：
类型 ：决定 Catalog 下能创建哪些资产，目前支持
Table（含视图）、Volume、Model 三种。存储路径 ：Catalog 拥有的 COS 存储路径前缀，与计算资源解耦。
链接信息 ：Catalog 可与外部数据源连接（如基于 Connection 创建 Foreign Catalog）。
Schema ：Catalog 下的命名空间，相当于传统数据库中的 Database。每个 Catalog 创建后会自动包含
information_schema 与 default 两个 Schema。资产对象 ：Schema 下挂载的具体资源，包括表（Table）、视图（View）、卷（Volume）、模型（Model）、函数（Function）等。每个资产由 Catalog 类型决定可承载的对象种类。
内置 Catalog
DataBuddy 在用户首次进入数据目录时，自动创建1个内置 Catalog：
内置 Catalog | 用途 | 是否可改名 / 删除 |
default | 默认目录，供首次使用时存放测试与样例数据 | 不可改名、不可删除 |
设计原则
DataBuddy 数据目录在设计上遵循以下基本原则：
1. 一个 MetaLake 多 Catalog ：同一个 MetaLake 实例下可以创建多个 Catalog，Catalog 跨工作空间可见。
2. 每个地域一份 MetaLake ：每个租户在每个地域默认只有一份 MetaLake，作为元数据的唯一事实来源；MetaLake 跨地域之间完全隔离，同名 Catalog 在不同地域会被视为不同对象。
3. 按存储划分 Catalog ：MetaLake 按 COS 存储路径进行 Catalog 划分，每个 Catalog 拥有独立的存储前缀。
4. 每个 Catalog 有明确类型 ：Catalog 在创建时必须指定类型，决定其下可承载的资产种类（Table、Volume、Model）。
5. Catalog 自带链接信息 ：Catalog 可承载链接信息用于连接到外部资源（如 Connection、External Location）。
6. Catalog 与计算资源解耦 ：Catalog 仅描述元数据与存储，与计算资源无关。同一个 Catalog 可以被任意有权限的计算资源访问。
7. 统一存储路径规则 ：存储路径形如
cos://<bucket>/root/workspaces/<catalogN>/...，由系统自动维护。与计算引擎的关系
Catalog 仅描述元数据与存储，不绑定具体的计算资源 。当您在 Studio 中执行 SQL、运行 Notebook，或在 Workflow 任务中读写数据时，由计算资源（DLC SQL、Spark、Ray 等）通过统一的元数据接口直接访问 Catalog：
元数据操作（建表、改表、删表等）通过统一接口下发，所有引擎看到的元数据一致。
数据读写遵循 Catalog 上的权限策略；越权访问会被引擎层拦截。
同一个 Catalog 可以被多个计算资源、多个工作空间同时访问（受权限和工作空间策略控制）。
工作空间与 Catalog 的关系
Catalog 注册在 MetaLake 上，跨工作空间可见 ：在工作空间 A 中创建的 Catalog，在同一地域的其他工作空间中也能看到。
工作空间通过 权限策略 决定哪些用户在当前空间下可以访问哪些 Catalog 与资产。
跨工作空间的隔离主要由工作空间、用户、资源对象三元组的访问控制实现；同一 Catalog 在不同工作空间的可访问范围可独立配置。
使用限制
限制项 | 说明 |
存储后端 | 当前仅支持腾讯云 COS 作为底层存储 |
自定义 COS 桶 | Catalog 创建时使用平台默认存储空间，暂不支持用户自定义 COS Bucket（系统会按 default 存储空间分配） |
MetaLake 数量 | 每个租户在每个地域固定一份 MetaLake，不支持创建多份 |
Catalog 数量上限 | 每个 MetaLake 下 Catalog 数量上限为 100，您可以申请扩容 |
资产类型范围 | 当前支持表、视图、卷、模型；函数、API、应用类型计划在后续版本支持 |
常见问题
Q：为什么 Catalog 的列表跨工作空间可见，而表的访问还是受工作空间限制？
A：Catalog 在 MetaLake 上是全局可见的命名空间，便于跨空间共享元数据；但表的实际读写受 Catalog / Schema / 资产层的权限策略与工作空间策略双重控制。元数据可见 ≠ 数据可读。
Q：Catalog 与 数据源 是不是同一个概念？
A：不是。在 DataBuddy 中：
Catalog ：用于承载元数据与底层存储的目录，存储 DataBuddy 内部托管的数据（表、卷、模型）。
数据源（Connection） ：用于连接外部数据库（如 MySQL、PostgreSQL）以便接入或镜像数据。基于 Connection 创建的外部 Catalog 称为 Foreign Catalog，详见 外部数据管理。
Q：内置的
system Catalog 里能看到什么？A：
system Catalog 用于存放平台侧自动维护的系统级元数据，由平台统一管理；普通用户默认对其只有只读访问权限。
