2、核心概念：Catalog、Namespace、Table、Partition、Snapshot在容量管理中的角色

在多集群、多租户的湖仓一体架构中，容量巡检并非盲目扫描所有文件，而是围绕一套层次化的元数据命名体系展开。理解 Catalog → Namespace → Table → Partition → Snapshot 这五层对象的职责与容量属性，是设计巡检策略的前提。

2.1 五层命名体系总览

下表从容量管理视角，对比各层对象的定义、粒度与关键度量指标：

2.2 各层对象的容量职责详解

2.2.1 Catalog — 容量边界与配额锚点

Catalog 是元数据服务的顶层入口，通常对应一个独立的存储桶（Bucket）或存储目录。在容量管理中，Catalog 承担以下职责：

• 配额绑定： 为每个 Catalog 设置存储上限（如 10TB），防止单集群无限制增长。
• 跨集群映射： 同一 Catalog 可跨多个集群访问，巡检需汇总所有集群对该 Catalog 的写入量。
• 全局水位线： 通过 Catalog 级指标（总文件数、总存储量）快速判断集群健康状态。

2.2.2 Namespace — 租户级容量隔离

Namespace 是 Catalog 下的逻辑子空间，常用于隔离不同业务线或团队。容量巡检在 Namespace 层关注：

• 容量倾斜： 少数 Namespace 占用 80% 以上存储，需评估是否需要拆分或限流。
• 闲置识别： 连续 30 天无数据变更的 Namespace，标记为可归档或回收。
• 表密度： Namespace 内表数量与总存储量的比值，辅助判断是否存在过度建表。

2.2.3 Table — 容量巡检的核心对象

Table 是巡检脚本直接扫描的实体。每个 Table 的元数据中记录了数据文件列表、大小、分区信息等。容量巡检在 Table 层执行以下检查：

• 小文件检测： 统计表内文件数 > 10000 且平均文件大小 < 64MB 的表，触发小文件合并建议。
• 大表分区合理性： 单表分区数 > 5000 或单分区数据量 < 1GB，提示分区粒度过细。
• 孤儿文件扫描： 对比表元数据与实际存储路径，找出未被元数据引用的孤立文件。

2.2.4 Partition — 物理数据布局的最小单元

Partition 决定了数据在存储上的物理分布。在 Iceberg / Hudi / Delta Lake 等开放表格式中，Partition 是容量倾斜和查询性能的关键影响因素：

• 分区倾斜： 最大分区大小 / 最小分区大小 > 10，表明数据分布严重不均。
• 过期分区： 根据业务保留策略（如保留最近 90 天），标记可删除的历史分区。
• 分区数超限： 单表分区数超过集群建议阈值（如 10000），触发分区合并或重新设计分区键。

2.2.5 Snapshot — 版本堆积与存储放大

Snapshot 是表格式实现 ACID 和时间旅行的核心机制。每次写入、删除或合并操作都会生成新的 Snapshot。容量巡检需关注：

• Snapshot 堆积： 单表 Snapshot 数量 > 1000 且保留时间超过 7 天，触发快照清理。
• 过期 Snapshot 占比： 过期 Snapshot 占用的存储空间 / 表总存储 > 30%，建议执行过期快照过期策略。
• 孤儿文件关联： 未被任何活跃 Snapshot 引用的数据文件，需定期清理以释放空间。

2.3 五层对象容量关系图

下图展示了从 Catalog 到 Snapshot 的层次化容量数据流，以及各层之间的包含与引用关系：

2.4 容量巡检中的关键元数据字段

在实际巡检脚本中，以下元数据字段是获取各层容量信息的核心来源（以 Apache Iceberg 为例）：

-- 查询 Catalog 级存储总量（通过 AWS Glue / Hive Metastore 汇总）
SELECT catalog_name, SUM(total_file_size) AS total_storage_bytes
FROM catalog_metadata
GROUP BY catalog_name;

-- 查询 Table 级小文件统计
SELECT table_name, file_count, total_file_size,
       ROUND(total_file_size / file_count / 1024 / 1024, 2) AS avg_file_size_mb
FROM table_metadata
WHERE file_count > 10000
  AND (total_file_size / file_count) < 64 * 1024 * 1024;

-- 查询 Snapshot 堆积情况
SELECT table_name, snapshot_count,
       DATEDIFF('day', MIN(committed_at), CURRENT_TIMESTAMP) AS oldest_snapshot_age_days
FROM snapshot_metadata
GROUP BY table_name
HAVING snapshot_count > 1000;

2.5 各层容量巡检的典型阈值参考