4、技术元数据详解：表结构、分区信息、文件格式、存储路径、数据大小、记录数、更新频率

技术元数据，说白了就是数据的「身份证」和「体检报告」。你想想看，一个 Lakehouse 里可能躺着几千张表，如果没有这些元数据，你根本不知道每张表长什么样、数据存在哪、质量怎么样。

我个人习惯把技术元数据分成两类：静态描述和动态指标。静态描述告诉你表是怎么定义的，动态指标告诉你表当前的状态。下面我们逐个拆解。

4.1 表结构（Schema）

表结构是最基础的技术元数据。它定义了表的列名、数据类型、是否允许为空、默认值等。我在项目中遇到过好几次因为表结构变更导致下游 ETL 任务崩溃的情况——嗯，从那以后我强制要求所有 Schema 变更必须记录在元数据系统中。

一个典型的表结构元数据包含以下字段：

字段	说明	示例
column_name	列名	user_id
data_type	数据类型	BIGINT, STRING, TIMESTAMP
nullable	是否允许空值	true / false
default_value	默认值	NULL, 0, 'unknown'
comment	字段注释	用户唯一标识
ordinal_position	列顺序	1, 2, 3

在 Apache Hive 或 Spark 中，我们可以通过 DESCRIBE TABLE 或 SHOW COLUMNS 获取这些信息。但在 Lakehouse 架构里，我更推荐把 Schema 信息持久化到元数据服务中，比如 Hive Metastore 或 AWS Glue Catalog。

-- 示例：获取表结构
DESCRIBE FORMATTED sales.orders;

-- 输出示例
-- col_name        data_type       comment
-- order_id        BIGINT          订单ID
-- user_id         BIGINT          用户ID
-- product_id      BIGINT          商品ID
-- amount          DECIMAL(10,2)   订单金额
-- created_at      TIMESTAMP       创建时间
-- dt              STRING          分区日期

4.2 分区信息（Partitioning）

分区是 Lakehouse 性能优化的核心手段。没有分区，你扫描一张 10TB 的表可能要跑几个小时；有了分区，可能几秒钟就搞定了。

分区信息元数据包括：

• 分区键：按哪个字段分区，比如 dt、region
• 分区数量：当前表有多少个分区
• 分区路径：每个分区对应的存储路径
• 分区大小：每个分区的数据量
• 分区记录数：每个分区包含多少行数据

我曾经接手过一个项目，某张表有 3000 多个分区，但 80% 的分区数据量不到 1MB。这种「小文件灾难」直接导致 NameNode 压力爆表。后来我们通过分区信息元数据发现了这个问题，强制设置了分区最小数据量阈值。

-- 示例：查看分区信息
SHOW PARTITIONS sales.orders;

-- 输出
-- dt=2024-01-01
-- dt=2024-01-02
-- dt=2024-01-03
-- ...

-- 更详细的分区信息
SHOW TABLE EXTENDED LIKE 'sales.orders' PARTITION (dt='2024-01-01');

4.3 文件格式（File Format）

Lakehouse 支持多种文件格式，每种格式都有其适用场景。常见的包括：

格式	特点	适用场景
Parquet	列式存储，压缩率高，支持谓词下推	分析型查询，OLAP
ORC	列式存储，Hive 生态优化	Hive 为主的场景
Avro	行式存储，Schema 可演化	数据写入、Kafka 消息
Delta Lake	Parquet + 事务日志	需要 ACID 事务的场景
Iceberg	Parquet + 快照隔离	大规模数据湖

我个人习惯在元数据中记录每个文件的格式和压缩算法。比如：

{
  "file_format": "parquet",
  "compression": "snappy",
  "row_group_size": 1024,
  "page_size": 8192
}

为什么这个重要？因为不同的查询引擎对不同格式的支持程度不一样。我记得有一次，Presto 查询 ORC 格式的表时性能很差，后来发现是 ORC 的 stripe 大小设置不合理。有了文件格式元数据，我们就能快速定位这类问题。

4.4 存储路径（Storage Path）

存储路径是技术元数据中最容易被忽视的一项。很多人觉得「路径不就是个字符串吗？」——其实不然。

在 Lakehouse 中，存储路径通常遵循这样的模式：

s3://data-lake-prod/table_name/dt=2024-01-01/part-00001.snappy.parquet

路径元数据需要记录：

• 基础路径：表数据的根目录
• 分区路径：每个分区的完整路径
• 文件路径：每个数据文件的路径
• 路径模式：路径的命名规则，比如 dt=yyyy-MM-dd

我在项目中遇到过最坑的事情是：有人手动修改了存储路径下的文件名，导致元数据系统里记录的路径和实际路径对不上。从那以后，我强制要求所有路径变更必须通过元数据 API 操作，不允许直接操作文件系统。

4.5 数据大小与记录数

这两个指标是技术元数据中的「体检指标」。它们告诉你表到底有多大、有多少行。

数据大小通常包括：

• 原始大小：未压缩的数据量
• 压缩后大小：实际存储占用的空间
• 文件数量：表包含多少个文件
• 平均文件大小：文件大小的平均值

记录数则直接反映表的行数。这两个指标结合起来，可以计算出一些很有价值的衍生指标：

衍生指标	计算公式	意义
压缩比	压缩后大小 / 原始大小	评估压缩效率
平均行大小	压缩后大小 / 记录数	评估数据密度
文件碎片率	文件数量 / 记录数	评估小文件问题

我建议在元数据系统中定期（比如每天）采集这些指标，并记录历史趋势。这样你可以回答「这张表最近一个月的数据量增长了多少？」这类问题。

-- 示例：获取表大小和记录数
ANALYZE TABLE sales.orders COMPUTE STATISTICS;

-- 查看统计信息
DESCRIBE FORMATTED sales.orders;

-- 输出片段
-- numFiles            128
-- totalSize           25678901234
-- numRows             50000000
-- rawDataSize         9876543210

4.6 更新频率（Update Frequency）

更新频率描述的是数据多久刷新一次。这个信息对下游消费者非常重要——他们需要知道「我看到的这份数据是不是最新的」。

更新频率通常包括：

• 更新策略：全量覆盖、增量追加、CDC 同步
• 更新周期：每小时、每天、每周、实时
• 最后更新时间：最近一次数据变更的时间戳
• 数据延迟：从业务发生到数据可用的时间差

举个例子：

{
  "update_strategy": "incremental_append",
  "update_frequency": "hourly",
  "last_updated": "2024-01-15 14:30:00",
  "data_latency": "15 minutes",
  "next_scheduled_update": "2024-01-15 15:00:00"
}

我曾经遇到过一个场景：业务方每天凌晨 2 点跑报表，但数据源是 T+1 更新的。结果报表跑出来总是少一天的数据。后来我们在元数据中明确标注了「数据延迟：24 小时」，业务方看到后就知道要调整报表的调度时间了。

4.7 知识体系总览

下面这张图总结了技术元数据的核心要素和它们之间的关系：

4.8 实践建议

最后，我总结几条实践中的经验：

1. 自动化采集：技术元数据不要靠人工维护，一定要通过自动化工具定期采集。我一般用 Apache Atlas 或自研的元数据采集器，每天凌晨跑一次。
2. 版本管理：所有技术元数据都要保留历史版本。这样当数据出问题时，你可以快速回滚到某个时间点的元数据状态。
3. 关联血缘：技术元数据要和数据血缘关联起来。比如，某张表的 Schema 变更了，要能自动通知到所有下游任务。
4. 设置告警：对关键指标设置告警阈值。比如，数据量突然下降 50%、分区数量异常增长、文件碎片率超过阈值等。