3. 实验数据存储格式与表设计

实验数据湖仓一体平台里，存储格式与表设计决定了后续查询性能、写入成本、并发能力和数据可维护性。很多团队在平台初期只关注“能不能把数据写进去”，结果在数据量增长到 TB 级后，才发现小文件过多、分区倾斜、更新困难、Schema 漂移导致任务频繁失败。本节从文件格式与表格式两个层面展开，并给出实验数据表结构与分区策略的落地方法。

一、先分清“文件格式”与“表格式”

Parquet、ORC、Avro 属于文件格式，它们描述的是单个文件内部如何组织行、列、编码和压缩；Delta、Iceberg、Hudi 属于表格式，它们在文件之上维护元数据、事务日志和快照，解决 ACID、增量读、时间旅行、Schema 演进等问题。二者不是替代关系，而是叠加关系：Iceberg 表底层通常仍是 Parquet 文件，Hudi 也常以 Parquet 作为基础文件。

实验数据常见的写入模式有两类：一类是传感器、日志、埋点等追加型数据，几乎不更新；另一类是样本标签、实验结论、设备状态等可更新数据，需要按主键做 upsert 或 delete。前者对文件格式的压缩比和扫描效率更敏感，后者则强依赖表格式提供的事务与增量能力。

二、文件格式的关键差异与实验数据适配

Parquet 与 ORC 都是列式存储，按列独立编码和压缩，适合“读少数列、扫大量行”的分析场景。Parquet 在 Spark、Flink、Trino、Presto 生态中支持最广，嵌套结构（如实验参数 JSON）表达自然；ORC 在 Hive 体系内索引更细，对谓词过滤和统计信息利用更充分。若实验平台以 Spark 为主、且需要跨引擎访问，Parquet 通常是更稳妥的默认选择。

Avro 是行式格式，Schema 随数据一起写入，读写双方无需外部约定即可解析，非常适合 Kafka 消息和流式接入。但 Avro 不适合大范围列裁剪扫描，因此常见做法是：流式层用 Avro 保证 Schema 兼容与低延迟，落湖后再转成 Parquet 供分析使用。

压缩与编码直接影响存储成本和扫描速度。实验数据中，时间戳、设备 ID、实验批次号重复度高，适合字典编码和 RLE；浮点测量值随机性强，压缩收益有限。一个可参考的示例配置是：Parquet 使用 SNAPPY 压缩、按 128 MB 目标文件大小写入、对高基数列关闭字典编码。这些参数需结合实测调整，不能直接照搬。

三、表格式解决什么问题

Delta Lake 以事务日志（_delta_log）记录每次提交，支持 ACID、upsert、时间旅行和 Schema 强制。它的优势是与 Spark 集成紧密，运维相对简单，适合以 Spark 为主的批处理链路。

Iceberg 采用快照与清单文件组织元数据，分区可以隐藏（用户按列查询，无需知道分区字段），支持分区演进而不重写历史数据，多引擎（Spark、Flink、Trino）读写一致性较好。对于实验数据中“按实验批次、时间范围查询”的典型模式，Iceberg 的隐藏分区和分区裁剪能显著减少扫描量。

Hudi 提供 COW（写时复制）和 MOR（读时合并）两种表类型，内置主键索引，擅长按主键做近实时 upsert 和增量拉取。样本标签回填、设备状态修正这类场景，Hudi 的增量视图比全表重算更经济。

四、实验数据表结构设计

以“实验测量明细表”为例，字段可分为四组：

• 标识列：experiment_id（实验编号）、device_id（设备编号）、sample_id（样本编号）；
• 时间列：event_time（事件时间，毫秒精度）、ingest_time（入库时间）；
• 度量列：temperature、pressure、voltage 等浮点测量值；
• 维度列：batch_no、operator、site、status 等低基数属性。

设计要点：标识列与时间列放在前面，便于分区和排序；度量列使用 double 或 decimal，避免用字符串存数值；维度列基数低时适合做分区或分桶键。若实验参数是变长 JSON，可保留为 string 或 map 类型，但不要把它作为过滤主路径。

五、分区策略：从“能查”到“查得快”

分区不是越多越好。分区过细会产生大量小文件，拖慢元数据操作和查询规划；分区过粗则扫描量过大。实验数据常用的分区组合是“日期 + 实验批次”或“日期 + 站点”。

一个可执行的判断方法是：先统计单日数据量与单分区目标文件数。假设单日新增 20 GB，目标文件大小 128 MB，则单日约 160 个文件；若按“日期 + 批次”分区，且每天有 40 个批次，则每个分区约 4 个文件，属于合理范围。若某批次只有几 MB，就应考虑合并分区或改用分桶。

分区字段选择还要看查询模式。若 90% 的查询都带 event_time 范围条件，按日期分区收益最大；若查询经常按 device_id 过滤，可考虑在分区内按 device_id 分桶（bucket），利用桶裁剪减少扫描。Iceberg 的隐藏分区允许先按天分区、后期再按小时演进，不必重写历史数据，这对实验数据生命周期管理很实用。

六、写入与维护的配套动作

选好格式和分区后，还需配套小文件合并、快照过期和元数据清理。以 Iceberg 为例，可定期执行 rewrite_data_files 合并小文件、expire_snapshots 清理过期快照；Hudi 则通过 compaction 将 MOR 表的增量日志合并为列式文件。Delta 可用 OPTIMIZE 和 VACUUM 控制文件数量与历史版本保留。

-- 示例：Iceberg 小文件合并与快照清理（示意，非实测结果）
CALL catalog.system.rewrite_data_files(
  table => 'lakehouse.exp_measurement',
  options => map('target-file-size-bytes','134217728')
);

CALL catalog.system.expire_snapshots(
  table => 'lakehouse.exp_measurement',
  older_than => TIMESTAMP '2025-01-01 00:00:00',
  retain_last => 5
);

这些维护动作应纳入调度，而不是等查询变慢才处理。判断是否需要合并的观察指标包括：单分区平均文件大小、查询扫描文件数、元数据操作耗时。若单分区平均文件小于 32 MB，或查询规划阶段列出文件数超过数千，就应触发合并。

综上，实验数据存储格式与表设计没有唯一答案，关键是让文件格式、表格式、分区策略与真实访问模式对齐。先明确数据是追加还是更新、查询是扫描还是点查、下游是批还是流，再选择组合，并用文件大小、分区数量、扫描量等指标持续验证，才能让湖仓平台在数据增长后仍然稳定高效。