4、技术评审阶段：数据模型变更评审、接口兼容性检查、数据质量影响分析

技术评审，说白了就是给数据契约变更做一次「全身体检」。我见过太多团队，契约改完了直接上线，结果接口报错、数据对不上、下游任务全挂。嗯，这个阶段要是省了，后面就是连环坑。

我个人习惯把技术评审拆成三个维度：模型本身、接口层面、数据质量。三个维度都过了，我才会签字放行。

4.1 数据模型变更评审

模型变更评审，核心就一句话：改了什么，影响谁。

我在项目中遇到过一种情况——开发同学把字段类型从 int 改成了 string，理由是「业务需要存字母」。他没通知任何人，结果下游的聚合任务直接崩溃，因为那个字段是聚合键。所以，模型变更评审必须逐项核对。

4.1.1 评审清单

4.1.2 模型变更的兼容性矩阵

我习惯用一张兼容性矩阵来判断变更是否「安全」：

4.2 接口兼容性检查

接口兼容性，说白了就是「老代码能不能继续用」。你想想看，如果改了接口格式，下游几百个服务都要跟着改，那还叫变更吗？那叫灾难。

4.2.1 检查维度

• 协议兼容性：RESTful API 的 URL、HTTP 方法、请求头是否变化。gRPC 的 proto 文件版本是否匹配。
• 数据格式兼容性：JSON/Protobuf/Avro 的 schema 是否向前兼容。字段顺序变化在某些序列化框架下会出问题。
• 语义兼容性：同一个字段的含义是否改变。比如 status 字段原来只有 0/1，现在加了 2，下游的枚举映射会报错。

4.2.2 兼容性检查脚本示例

下面是一个简单的 Protobuf 向前兼容检查脚本，我经常用它做快速验证：

#!/bin/bash
# protobuf 向前兼容性检查
# 用法：./check_compat.sh old.proto new.proto

OLD_PROTO=$1
NEW_PROTO=$2

# 使用 protoc 检查
protoc --decode_raw < $OLD_PROTO > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "❌ 旧 proto 文件解析失败"
  exit 1
fi

# 检查字段删除
DELETED=$(diff <(grep -E '^\s+(optional|required|repeated)' $OLD_PROTO | sort) \
               <(grep -E '^\s+(optional|required|repeated)' $NEW_PROTO | sort) | \
               grep '^<' | wc -l)
if [ $DELETED -gt 0 ]; then
  echo "❌ 检测到 $DELETED 个字段被删除，不向前兼容"
  exit 1
fi

echo "✅ 向前兼容性检查通过"

4.3 数据质量影响分析

模型和接口都过了，不代表数据本身没问题。数据质量影响分析，是我最看重的一环。

我记得有一次，一个契约变更只是把日期格式从 yyyy-MM-dd 改成了 yyyy/MM/dd。看起来很小对吧？结果下游的报表系统解析失败，整张报表空了三天。所以，数据质量影响分析不能只看「有没有数据」，要看「数据对不对」。

4.3.1 分析维度

1. 完整性：变更后是否有字段缺失？非空约束是否被破坏？
2. 准确性：数值范围、枚举值、格式是否仍然符合预期？
3. 一致性：跨表、跨系统的数据是否还能关联？比如用户 ID 的编码规则变了，关联查询就废了。
4. 时效性：变更是否影响数据延迟？比如新增了计算字段，会不会拖慢写入速度？

4.3.2 影响分析流程

我建议按这个步骤来：

• 第一步：识别变更波及的数据集。列出所有直接和间接依赖该契约的表、视图、任务。
• 第二步：抽样对比。取变更前后的数据样本，逐字段对比。我一般取 1000 条，覆盖边界值。
• 第三步：跑回归测试。用历史数据回放，看下游任务是否报错。
• 第四步：评估影响等级。分 P0/P1/P2 三级，P0 必须回滚或修复后才能上线。

4.4 技术评审流程图

下面这张图是我在团队里推的技术评审流程，你可以参考：

4.5 避坑指南

最后，分享几个我踩过的坑：

• 别只看正向流程。我曾经只测了正常数据，没测边界值。结果上线后，空值字段导致下游聚合全乱了。边界测试一定要做。
• 别忽略元数据变更。字段注释、标签、分类改了，看起来不影响运行，但会影响数据目录和数据治理。我见过因为注释没更新，新来的同学理解错字段含义，写错了业务逻辑。
• 别跳过灰度验证。技术评审通过不代表生产环境没问题。我建议先灰度 10% 的流量，观察 24 小时，确认无误再全量发布。