数据分层架构下使用HUDI构建仅追加清洗层的可行性咨询

核心结论 #

将HUDI作为仅追加模式的Cleaned层存储是完全合理的方案，适配你当前的数仓分层设计，也能覆盖GDPR合规需求。

• 匹配Cleaned层定位：仅追加模式不会修改已落地的历史清洗数据，能给数据科学家提供稳定、可回溯的数据源，避免数据变更导致的分析结果不可复现问题
• 合规能力刚好适配：HUDI原生支持时间旅行、行级删除/更新，不需要额外开发工具链就能满足GDPR要求的「被遗忘权」等合规要求，比原生S3文本存储实现合规的成本低很多
• 架构扩展性强：如果后续Cleaned层需要新增轻量数据订正、重复数据删除等能力，不需要做存储架构迁移，直接调整HUDI写入配置即可落地

• 存储开销略高于原生文本存储：HUDI会额外存储索引、提交日志、元数据等信息，相同原始数据量下，存储占用会比纯Parquet/CSV存储高10%~30%
• 存在小文件风险：如果单次写入的批次太小，仅追加模式下也会生成大量小文件，拉高查询性能损耗
• 非HUDI生态工具访问有适配成本：如果数据科学家习惯直接用普通S3工具读取文件，需要额外做HUDI导出或者适配Hudi读工具，不能像读原生Parquet那样直接访问

• 配置层面开启hoodie.parquet.compression.codec参数，使用zstd/gzip压缩抵消额外存储开销；同时开启自动小文件合并功能，建议设置单次写入批次大小不低于128MB
• 给Cleaned层的HUDI表关闭不必要的特性，比如关闭增量查询索引、关闭UPSERT相关的预合并逻辑，只保留基础的提交日志和时间旅行能力，降低写入和存储开销
• 给数据科学家统一封装HUDI表的读取入口，比如通过SparkSQL、Presto等查询引擎直接访问，屏蔽底层存储细节，避免访问适配问题
• 如果有离线批量导出原生Parquet的需求，可以定时跑任务导出最新的全量快照到独立S3路径，供特殊场景使用

内容的提问来源于stack exchange，提问作者Amit Joshi