3、Schema基础：定义、数据类型、嵌套结构、分区列与主键

3.1 Schema的本质：表结构与数据契约

在Delta Lake中，Schema（模式）定义了表的结构，它决定了哪些列被允许写入、每列的数据类型是什么、列是否允许为空，以及列之间的组织关系。你可以将Schema理解为一张表的“蓝图”或“数据契约”——所有写入Delta表的数据都必须符合这个契约，否则写入操作将被拒绝。

与传统的Hive表或Parquet文件不同，Delta Lake将Schema作为表元数据的一部分，存储在_delta_log目录的事务日志中。这意味着Schema不仅是一个物理文件的结构描述，更是一个版本化的、可演进的逻辑实体。每次Schema变更（如新增列、修改数据类型）都会记录为一个新的协议版本，从而支持时间旅行和审计追溯。

3.2 数据类型详解：从基础到嵌套

Delta Lake基于Spark SQL的数据类型系统，支持丰富的数据类型。理解这些类型是设计Schema的前提，因为类型决定了数据的存储方式、比较规则和可用的操作函数。

类别	数据类型	说明	典型场景
基本类型	STRING	UTF-8字符串	用户名、地址、描述
	INTEGER / LONG	32位/64位整数	ID、数量、计数
	DOUBLE / FLOAT	浮点数	价格、评分、度量值
	TIMESTAMP	时间戳（微秒精度）	事件时间、日志时间
复杂类型	ARRAY<T>	有序元素集合	标签列表、历史记录
	MAP<K,V>	键值对集合	属性字典、配置项
	STRUCT<...>	命名字段集合	地址、坐标、复合实体

嵌套结构是Delta Lake Schema中极具表达力的特性。通过STRUCT和ARRAY的组合，可以建模高度复杂的业务对象，而无需进行多表关联。例如，一个订单表可以包含嵌套的items数组，每个元素又是一个包含product_id、quantity和price的STRUCT。

-- 创建包含嵌套结构的Delta表
CREATE TABLE orders (
  order_id STRING,
  customer STRUCT<name: STRING, email: STRING, address: STRUCT<city: STRING, zip: STRING>>,
  items ARRAY<STRUCT<product_id: STRING, quantity: INT, price: DOUBLE>>,
  total_amount DOUBLE,
  created_at TIMESTAMP
) USING DELTA;

3.3 分区列与主键：物理组织与逻辑标识

分区列决定了Delta表数据在存储层的物理分布。分区列的值被用于创建目录层级，例如按date分区会生成date=2024-01-01/这样的目录。合理选择分区列可以极大提升查询性能——当查询条件包含分区列时，Spark可以执行分区裁剪（Partition Pruning），只读取相关目录下的数据文件。

分区列的选择需要遵循以下原则：

• 基数适中：分区列的不同取值数量不宜过多（避免产生大量小文件）也不宜过少（无法有效裁剪）。通常选择日期、地区、业务线等。
• 查询频繁：选择经常出现在WHERE条件中的列作为分区列。
• 值稳定：分区列的值不应频繁变化，否则会导致数据重写。

主键（Primary Key）在Delta Lake中是一个逻辑概念，用于唯一标识表中的每一行。与分区列不同，主键不决定物理存储布局，而是用于数据一致性保障。Delta Lake支持声明主键约束，并配合MERGE操作实现upsert（更新或插入）语义。

-- 声明主键并利用主键执行MERGE
CREATE TABLE users (
  user_id STRING PRIMARY KEY,
  name STRING,
  email STRING,
  updated_at TIMESTAMP
) USING DELTA;

-- 使用MERGE基于主键进行数据同步
MERGE INTO users AS target
USING updates AS source
ON target.user_id = source.user_id
WHEN MATCHED THEN UPDATE SET
  name = source.name,
  email = source.email,
  updated_at = current_timestamp()
WHEN NOT MATCHED THEN INSERT *;

3.4 案例：电商订单表Schema设计

下面通过一个完整的案例，展示如何综合运用Schema的各个要素设计一张电商订单表。该表需要支持按日期分析订单趋势、按用户查询历史订单、以及通过主键进行订单状态更新。

-- 电商订单表Schema设计
CREATE TABLE ecommerce.orders (
  -- 主键：订单ID
  order_id STRING PRIMARY KEY,
  
  -- 用户信息（嵌套结构）
  user_info STRUCT<
    user_id: STRING,
    user_name: STRING,
    member_level: STRING
  >,
  
  -- 订单明细（数组嵌套结构）
  order_items ARRAY<STRUCT<
    sku_id: STRING,
    product_name: STRING,
    quantity: INT,
    unit_price: DOUBLE,
    discount: DOUBLE
  >>,
  
  -- 金额汇总
  subtotal DOUBLE,
  shipping_fee DOUBLE,
  total_amount DOUBLE,
  
  -- 状态与时间
  order_status STRING COMMENT 'PENDING/PAID/SHIPPED/COMPLETED/CANCELLED',
  created_at TIMESTAMP,
  paid_at TIMESTAMP,
  shipped_at TIMESTAMP,
  
  -- 分区列：按日期分区
  order_date DATE
)
USING DELTA
PARTITIONED BY (order_date)
COMMENT '电商订单主表，按订单日期分区';

该Schema的设计体现了以下考量：

1. 主键选择：order_id天然唯一，适合作为主键用于后续的MERGE更新。
2. 嵌套建模：用户信息和订单明细直接嵌入订单表，避免查询时需要多次关联。
3. 分区策略：按order_date分区，既支持按日/月粒度的聚合分析，又不会产生过多分区目录。
4. 注释与可读性：为状态字段添加注释，便于团队协作理解。

3.5 常见误区与复盘

在实际项目中，Schema设计存在一些高频误区，值得特别警惕：