字段顺序为什么值得定规范
字段顺序不影响查询逻辑，但直接影响阅读效率与变更成本。定好顺序后，任何一张表都能被快速读懂：主键在哪、关联键在哪、度量在哪、审计字段在哪。尤其是分区列的位置，在 Hive 数仓里有硬性语法约束，写错直接建表失败。
基本信息
| 推荐顺序 | 业务主键 → 维度代理键 → 度量 → 审计字段 |
|---|---|
| 分区列 | 写在列定义之外，用 PARTITIONED BY 单独声明 |
| 审计字段 | 统一前缀如 etl_，包括入库时间与批次号 |
| 新增列 | 追加到末尾，避免影响按位置读取的脚本 |
| 适用平台 | Hive、Spark SQL、以及多数数仓建表规范 |
典型使用场景
- 新建表评审：字段顺序是否可读是评审的固定检查项
- 接手他人模型：靠固定顺序快速定位主键、外键与度量
- 生成建表语句：模板统一后不同人写出的表结构风格一致
- 排查数据问题：审计字段固定在末尾，方便快速扫到入库时间
- 结构变更：加列只追加末尾，降低对下游取数脚本的冲击
字段布局示例
字段布局示例
CREATE TABLE dwd_trade_order_di (
order_id STRING COMMENT '业务主键：订单号', -- 主键在最前
customer_sk BIGINT COMMENT '维度代理键：客户', -- 关联键居中
product_sk BIGINT COMMENT '维度代理键：商品',
pay_amt DECIMAL(18,2) COMMENT '度量：实付金额，含税', -- 度量集中摆放
create_time STRING COMMENT '业务时间：下单时间',
etl_time STRING COMMENT '审计：入库时间' -- 审计字段收尾
)
PARTITIONED BY (dt STRING) -- 分区列必须写在列定义之外
STORED AS ORC;位置与内容对照
| 位置 | 放什么 | 理由 |
|---|---|---|
| 首列 | 业务主键或明细标识 | 最常被用来定位与去重 |
| 中段 | 维度代理键与业务属性 | 关联逻辑集中，便于检查引用完整性 |
| 后段 | 度量字段 | 度量带单位与口径注释，集中便于对账 |
| 末尾 | 审计字段 | 与业务字段隔离，排查入库问题时快速找到 |
| 列定义之外 | 分区列 | Hive 语法要求，写在列里会报重复列 |
在 Hive 里把分区列同时写进列定义与 PARTITIONED BY，建表会因重复列直接失败。分区列只出现在分区声明中，查询时它仍可作为普通列使用。
新增字段追加在末尾是通用约定。使用按位置（position）解析的 ETL 脚本或外部程序，对列顺序变化极其敏感，中间插列会让它们静默读错字段。