2. Schema生命周期管理：创建、审核、发布、废弃的全流程规范

Schema不是写出来就完事的。它跟代码一样，有出生、有评审、有上线，最后还得有体面的退役。很多团队把Schema当成DDL脚本，写完就往生产库一跑，结果就是线上事故不断。

我个人习惯把Schema的生命周期拆成四个阶段：创建 → 审核 → 发布 → 废弃。每个阶段都有明确的准入准出条件。下面我逐个阶段讲，顺便聊聊我在项目中踩过的坑。

2.1 创建阶段：从需求到草案

创建阶段的核心任务，是把业务需求翻译成Schema草案。说白了，就是回答三个问题：这个字段存什么？什么类型？谁在用？

我在项目中遇到过最典型的问题，就是开发同学直接照着前端页面字段建表。字段名叫col1、col2，类型全用VARCHAR(255)。嗯，这种Schema上线后，数据治理基本就废了。

创建阶段我建议至少包含以下步骤：

1. 需求确认：与业务方对齐字段含义、取值范围、更新频率
2. 命名规范检查：表名、字段名必须符合团队约定的命名规则
3. 类型选择：根据数据特征选择最合适的类型，避免"一刀切"用字符串
4. 默认值与约束：明确NOT NULL、DEFAULT、UNIQUE等约束
5. 元数据登记：在元数据平台中录入字段描述、业务域、负责人

2.2 审核阶段：把问题拦在上线前

审核阶段是Schema治理的"守门员"。我个人认为，这个阶段比发布更重要。为什么？因为Schema一旦发布，下游可能有几十个任务依赖它，改起来代价巨大。

我曾经见过一个团队，审核流形同虚设——开发自己建表、自己审批、自己发布。结果上线后才发现字段类型选错了，几千万行数据要重跑ETL。那次事故之后，我们硬性规定了审核的"三权分立"：

审核角色	审核内容	一票否决权
技术审核	命名规范、类型选择、索引设计、分区策略	是
数据治理审核	元数据完整性、数据分类分级、敏感字段标记	是
业务审核	字段含义、取值范围、业务规则一致性	是

审核不通过怎么办？退回创建阶段，修改后重新提交。这里要注意：不允许"带病上线"。我曾经遇到过业务方施压说"先上线再补审核"，结果一补就是半年，最后那个字段的元数据全是错的。

2.3 发布阶段：灰度与回滚

发布不是把DDL往生产库一跑就完事。你想想看，一个Schema变更可能影响几十个下游任务、几百个报表。直接全量发布，风险太大了。

我建议的发布策略是灰度发布：

• 第一阶段：在预发环境执行，验证语法和兼容性
• 第二阶段：在生产环境灰度1%的流量，观察24小时
• 第三阶段：逐步放量到10%、50%、100%
• 第四阶段：全量发布后，保留48小时观察期

每个阶段都要有回滚预案。我记得有一次发布新增字段，灰度阶段发现有个老任务写死了列数，新字段插入后直接报错。还好只灰度了1%，回滚后通知那个任务团队修改，避免了全量事故。

2.4 废弃阶段：体面地退出

废弃是最容易被忽视的阶段。很多团队的Schema只增不减，几年下来几万个表，一半以上没人用。但你又不敢删，因为不知道谁还在悄悄依赖。

我处理废弃的策略是三步走：

1. 标记废弃：在元数据中将Schema状态改为DEPRECATED，保留所有元数据
2. 设置宽限期：通常90天，期间允许读取但不允许写入
3. 物理清理：宽限期结束后，确认无依赖，执行物理删除或归档

这里有个坑：不要相信"没人用"。我曾经以为某个表废弃了半年肯定没人用了，结果一查，有个定时任务每个月跑一次，负责人早就离职了。所以废弃前一定要做全链路依赖分析，把血缘关系查清楚。

2.5 全流程规范总结

把四个阶段串起来，就是一套完整的Schema生命周期管理规范。我把它总结成一张表，方便你对照落地：

阶段	准入条件	核心活动	产出物	责任人
创建	业务需求已确认	需求分析、命名检查、类型选择、元数据登记	Schema草案、元数据记录	开发工程师
审核	Schema草案已提交	技术审核、治理审核、业务审核	审核通过/驳回意见	审核委员会
发布	审核通过	灰度发布、兼容性验证、回滚预案	发布记录、变更通知	运维/DBA
废弃	确认无业务依赖	标记废弃、设置宽限期、依赖分析、物理清理	废弃记录、清理报告	数据治理工程师

最后说一句：规范是死的，人是活的。这套流程不是让你僵化执行，而是给你一个框架。实际落地时，可以根据团队规模和业务特点做裁剪。小团队可以简化审核流程，但创建、发布、废弃这三个节点不能省——这是我用多次事故换来的教训。