📚 课程目录第4章医疗数据湖仓表格式与元数据管理

4. 医疗数据湖仓表格式与元数据管理

在医疗数据湖仓中，存储层通常落在对象存储或 HDFS 上，而“表格式”决定了这些文件如何被组织成一张可查询、可演进、可回溯的表。没有表格式时，湖只是一堆 Parquet/ORC 文件；有了表格式，才有 ACID 事务、快照隔离、Schema 演进、时间旅行和增量读取。医疗场景对这几项能力尤其敏感：患者主索引、就诊、检验、影像、病历文本往往来自不同系统，既要支持批量入湖，又要支持近实时更新，还要满足审计追溯与历史版本回查。

三种主流表格式的定位差异

Apache Iceberg、Delta Lake、Apache Hudi 都提供事务与元数据管理，但设计重心不同。Iceberg 以“表元数据树 + 快照”为核心，强调开放、跨引擎、隐藏分区和 Schema 演进；Delta Lake 以事务日志 _delta_log 为核心，与 Spark 生态结合紧密，支持 MERGE、时间旅行和约束；Hudi 以“文件组 + 时间线”为核心，强调 Upsert、增量拉取和近实时写入，适合 CDC 入湖。

在医疗数据湖仓中，选型不能只看功能列表，而要看数据写入模式。例如，患者基本信息表以 CDC 更新为主，Hudi 的 MOR 表或 Iceberg 的 MERGE 都合适；检验结果表以批量追加为主，Iceberg 或 Delta Lake 的追加写更简单；影像索引表需要频繁按检查号更新状态，Hudi 的增量视图或 Iceberg 的 MoR 表更有优势。若平台需要多引擎查询（Spark、Trino、Flink、StarRocks），Iceberg 的开放元数据协议通常更省心。

元数据服务设计：把“表”管起来

表格式只解决单表元数据，医疗湖仓还需要统一的元数据服务。它至少承担四件事：技术元数据（库、表、字段、分区、文件、快照）、业务元数据（指标口径、数据字典、责任人）、操作元数据（任务、血缘、SLA、质量结果）和安全元数据（敏感级别、脱敏规则、访问策略）。

落地时，建议以 Catalog 为入口：Iceberg 使用 REST Catalog 或 Hive Metastore，Delta Lake 使用 Unity Catalog 或 Hive Metastore，Hudi 使用 Hive Metastore 同步。无论选哪种，都应把表元数据同步到统一元数据中心，例如用 DataHub 或 OpenMetadata 采集。采集频率可按小时级增量同步，关键表可缩短到分钟级。元数据服务对外提供 API，供查询引擎、调度系统、数据质量平台和权限系统调用。

一个可执行的元数据服务设计示例：

表：dwd_patient_visit
格式：Iceberg V2
Catalog：REST Catalog（生产）/ Hive Metastore（兼容）
分区：dt=yyyy-MM-dd, hospital_id
主键：visit_id
Schema 版本：v3
  v1: visit_id, patient_id, visit_time
  v2: + dept_id, doctor_id
  v3: + diagnosis_code, update_time
快照保留：最近 30 天，每月保留 1 个归档快照
质量规则：visit_id 非空唯一；patient_id 必须存在于 dim_patient
血缘：上游 ods_visit_cdc → dwd_patient_visit → dws_visit_summary

Schema 演进策略：医疗字段只增不减

医疗数据字段变化频繁：新增诊断编码、新增检验项目、新增院区标识。Schema 演进要遵循“向后兼容优先”的原则。Iceberg 支持按字段 ID 追踪，允许安全地加列、改类型、重命名；Delta Lake 支持加列和列映射，但改类型需谨慎；Hudi 支持加列，但复杂类型变更需要重写。实际策略可以分三档：

加列：默认允许，新字段写入 NULL，旧查询不受影响。
改类型：仅允许窄化到宽化，如 int → long、float → double；反向需新建列并回填。
重命名/删除：不物理删除，先标记 deprecated，保留至少两个版本周期，确认无下游引用后再清理。

在医疗场景中，建议把 Schema 变更纳入发布流程：变更前用元数据服务检查下游依赖，变更后写入变更日志，并触发数据质量抽检。例如新增 diagnosis_code 字段后，先对最近 7 天数据做非空率检查，若低于 95%，则暂停下游指标发布，回退到旧版本。

表格式选型建议

如果平台以 Spark 为主、需要强约束和批流一体，Delta Lake 是稳妥选择；如果平台需要多引擎查询、频繁 Schema 演进和隐藏分区，Iceberg 更合适；如果核心诉求是 CDC 近实时入湖、增量拉取和 Upsert，Hudi 更贴近。医疗湖仓常见做法是“分层选型”：ODS 层用 Hudi 承接 CDC，DWD/DWS 层用 Iceberg 做开放查询与快照回溯，ADS 层用 Delta Lake 做指标汇总与质量约束。选型不是一次性的，应结合数据量、更新频率、查询引擎和团队技能综合判断，并在元数据服务中统一登记每张表的格式、版本和演进记录。