🌊 数据湖测试策略

05-05数据湖Delta LakeIceberg测试策略

📌 数据湖测试的独特性

数据湖不同于传统数据仓库，它以原始格式存储海量结构化、半结构化和非结构化数据。测试数据湖需要覆盖 Schema 演化、ACID 事务、时间旅行、分区策略等独特能力，同时确保数据在批量与实时写入场景下的一致性。

与传统数仓测试的区别

维度	传统数仓	数据湖
Schema	Write Schema（先定义后写入）	Schema on Read + Schema 演化
数据格式	结构化表	Parquet/ORC/Avro + JSON/CSV/图片
更新方式	INSERT/UPDATE/DELETE	Upsert/Merge + 时间旅行回滚
一致性	事务保证	ACID 事务（依赖表格式）
规模	TB 级	PB 级

💡 核心测试场景

1. ACID 事务验证

并发写入：多客户端同时 Upsert 同一分区，验证无数据丢失与冲突
原子性：写入失败时，读操作不应看到部分提交的数据
隔离级别：验证 Snapshot Isolation 是否正确（读写不相互阻塞）
冲突解决：测试 Delta Lake / Iceberg 的乐观并发控制（OCC）机制

2. Schema 演化测试

添加列：新写入带额外字段的数据，验证下游读取不报错
删除列：移除字段后历史分区仍可正常读取（NULL 填充）
类型变更：int→long 的向上兼容变更，以及非兼容变更的错误处理
嵌套结构：Struct/Map/Array 字段的增删改测试

3. 时间旅行（Time Travel）测试

版本回滚：将表恢复到指定快照版本，验证数据完整恢复
历史查询：按时间戳查询历史数据，验证快照隔离性
Vacuum 清理：确认过期文件被正确清理，且时间旅行窗口外的查询返回预期错误

🔍 表格式对比：Delta Lake vs Iceberg vs Hudi

特性	Delta Lake	Apache Iceberg	Apache Hudi
ACID 事务	✅ 乐观并发控制	✅ Snapshot Isolation	✅ 多版本并发控制
时间旅行	✅ 版本号/时间戳	✅ Snapshot ID/时间戳	✅ 提交时间
Schema 演化	✅ 自动合并	✅ 完整的 DDL 支持	✅ Schema 版本控制
分区演进	⚠️ 需重写	✅ 隐藏分区+演进	✅ 支持分区变更
生态集成	Spark 深度集成	多引擎（Spark/Flink/Trino）	Spark/Flink/Hive
测试重点	Z-Order 优化验证	分区演进后查询正确性	索引（Bloom/HFile）有效性

⚠️ 常见坑点

小文件问题：频繁微批量写入产生海量小文件，需验证 Compaction 策略的有效性
分区倾斜：热点分区导致查询性能骤降，测试需模拟真实数据分布
Metadata 膨胀：Delta/Iceberg 元数据日志随提交次数线性增长，需测试 Checkpointing
跨格式兼容：Hive 外表读取湖表时需验证 Parquet 兼容性和谓词下推

📖 测试框架与实践

单元测试：使用 delta-rs、pyiceberg 等本地库编写纯 Python 测试
集成测试：Docker Compose 启动 MinIO + Spark，验证端到端读写流程
性能测试：使用 TPC-DS 数据集测试不同分区策略和文件大小的查询延迟
混沌测试：注入网络延迟、节点故障，验证湖表的事务恢复能力

← 数据血缘验证 ETL测试方法论 →