5.1.5 大数据方法论与实践指南-数据仓库存储格式选择

5.1.5 数据仓库存储格式选择

选择合适的存储格式，需要在查询性能、写入性能、存储成本、压缩效率、模式演化支持、生态系统兼容性等多个维度进行权衡。现代数据仓库（尤其是基于数据湖的架构）提供了多种列式存储格式作为首选。

一、 核心存储格式对比

以下是目前主流的、适用于数据仓库场景的存储格式：

特性/格式	Parquet	ORC	Avro	Delta Lake	Iceberg	Hudi
数据组织	列式 (Columnar)	列式 (Columnar)	行式 (Row-based)	列式 (基于 Parquet)	列式 (基于 Parquet/ORC)	列式 (基于 Parquet)
主要优势	高压缩比，极佳的分析查询性能，广泛支持	高压缩比，优秀的查询性能，Hive 生态深度集成	强模式演化，高效序列化，适合流式写入	ACID 事务，模式演化，时间旅行，统一批流	开放表格式，高性能，大规模事务，模式演化	增量处理，近实时，upsert/delete
压缩支持	优秀 (SNAPPY, GZIP, ZSTD, LZO)	优秀 (ZLIB, SNAPPY, ZSTD, LZO)	优秀 (SNAPPY, DEFLATE)	继承 Parquet	继承底层格式	继承 Parquet
模式演化	有限 (添加列，修改元数据)	有限 (添加列，修改元数据)	极佳 (添加、删除、重命名字段，类型兼容变更)	优秀 (自动/手动模式演化)	优秀 (丰富的模式演化操作)	优秀 (支持模式变更)
ACID 事务	❌ (文件级)	❌ (文件级)	❌ (文件级)	✅ (核心特性)	✅ (核心特性)	✅ (核心特性)
时间旅行 (Time Travel)	❌	❌	❌	✅ (版本控制)	✅ (快照)	✅ (增量快照)
更新/删除 (Upsert/Delete)	❌ (需重写文件)	❌ (需重写文件)	❌ (需重写文件)	✅ (MERGE INTO, DELETE)	✅ (MERGE INTO, DELETE)	✅ (UPSERT, DELETE)
增量处理	❌ (全量)	❌ (全量)	❌ (全量)	✅ (通过版本/时间戳)	✅ (增量快照)	✅ (核心优势，记录级增量)
生态系统支持	极其广泛 (Spark, Flink, Hive, Presto/Trino, Redshift, Snowflake, BigQuery, Databricks, Athena, Impala)	广泛 (Hive, Spark, Presto/Trino, Impala, Redshift Spectrum)	广泛 (Kafka, Spark, Flink, Hive)	广泛 (Spark, Databricks, Flink, Presto/Trino, Snowflake*, BigQuery*)	广泛 (Spark, Flink, Presto/Trino, Hive, Snowflake*, BigQuery*)	广泛 (Spark, Flink, Presto/Trino)
典型应用场景	通用分析，数据湖标准，高吞吐读取	Hive 生态，高吞吐分析	事件流，日志数据，需要频繁模式变更的源数据	需要事务和可靠性的数据湖，统一数据架构，Databricks 环境	大规模数据湖，高性能事务，多引擎协作	近实时数据湖，需要增量处理和低延迟更新

二、 选择存储格式的关键考量因素

1. 工作负载类型 （Workload Type）：

   1. 分析型查询 （OLAP）：优先选择 列式格式 （Parquet， ORC）。这是绝大多数数仓场景的首选。

   2. 事务型/点查 （OLTP-like）：如果需要频繁的单条记录更新/删除，考虑 Delta Lake， Iceberg， Hudi。

   3. 流式处理 （Streaming）：

      • 源数据摄入：Avro （与 Kafka 集成好） 或 Parquet （如果写入频率不高）。

      • 流式写入目标：Delta Lake， Hudi， Iceberg 支持高效的流式写入（append 和 upsert）。

2. 是否需要 ACID 事务：

   1. 需要：必须选择支持 ACID 的格式。Delta Lake， Iceberg， Hudi 是当前主流选择。它们能保证并发写入时的数据一致性，避免文件损坏。

   2. 不需要：Parquet 或 ORC 可能满足需求，但需自行处理并发写入冲突（通常通过应用层锁或批处理避免）。

3. 模式演化需求 （Schema Evolution）：

   1. 频繁变更：如果数据源模式经常变化（如添加新字段、修改字段名），Avro 在行式格式中支持最好。对于列式格式，Delta Lake， Iceberg， Hudi 提供了强大的模式演化能力（如自动允许添加列）。

   2. 相对稳定：Parquet 和 ORC 的模式演化能力有限，适合模式稳定的场景。

4. 更新与删除 （Upsert/Delete） 能力：

   1. 需要：传统 Parquet/ORC 文件无法高效更新单条记录，需要重写整个文件或分区，成本高昂。Delta Lake， Iceberg， Hudi 通过维护索引或日志，支持高效的 MERGE INTO， UPDATE， DELETE 操作。

5. 增量处理需求：

   1. 需要：如果下游任务（如数据同步、机器学习特征生成）只需要处理自上次以来的变更数据，Hudi （CDC 集成好） 和 Delta Lake/Iceberg （通过版本/时间戳获取增量快照） 是理想选择。

6. 生态系统与工具兼容性：

   1. 广泛兼容性：Parquet 是事实上的开放标准，被几乎所有大数据工具支持，是安全、通用的选择。

   2. 特定平台：

      • Databricks 环境：Delta Lake 是原生首选，集成度最高。

      • Hive 生态：ORC 有深厚基础。

      • 多引擎协作：Iceberg 设计上强调开放性和多引擎（Spark， Flink， Presto/Trino， Hive）的互操作性，是很好的选择。

7. 性能与成本：

   1. 读取性能：Parquet 和 ORC 通常提供最佳的列式读取性能和压缩率。

   2. 写入性能：Avro 写入通常较快（行式追加）。Parquet/ORC 写入需要缓冲和排序，可能稍慢。Delta Lake/Hudi/Iceberg 的写入开销取决于其事务日志和索引机制。

   3. 存储成本：Parquet 和 ORC 压缩率高，存储成本低。Avro 压缩率也高。开放表格式本身不增加存储，但其元数据和日志文件会占用少量额外空间。

三、 推荐实践与分层策略

1. ODS （操作数据存储） 层：

   1. 首选：Avro 或 JSON。

   2. 理由：最接近源系统，模式可能不稳定，需要良好的序列化和模式演化支持。适合从 Kafka 等流系统摄入。

   3. 备选：如果模式稳定且写入非实时，也可用 Parquet。

2. DWD （数据仓库明细） / DWS （数据仓库汇总） 层：

   1. 首选：

      • 通用/开放性优先：Parquet （如果不需要事务/更新） 或 Iceberg （需要事务/更新/多引擎）。

      • Databricks 环境：Delta Lake。

      • Hive 生态：ORC。

   2. 理由：这是核心分析层，需要高性能查询和高存储效率。列式格式是必须的。如果需要 UPSERT （如处理迟到数据） 或强一致性，开放表格式是更好的选择。

3. ADS （应用数据服务） 层：

   1. 首选：Parquet 或 Delta Lake/Iceberg。

   2. 理由：为下游应用（BI 报表、API）提供服务，查询模式明确，性能要求高。Parquet 是成熟稳定的选择。如果 ADS 层需要频繁更新（如实时大屏），则 Delta Lake/Iceberg 更合适。

4. 数据湖 （Data Lake） 基础：

   1. 强烈推荐：将 Parquet 作为数据湖的事实标准。

   2. 理由：最大化的兼容性、高性能、低成本。即使上层使用 Delta Lake/Iceberg，它们通常也以 Parquet 作为底层数据文件格式。

5. 混合使用策略：

   1. ODS: Avro （流式摄入）

   2. DWD/DWS: Delta Lake （在 Databricks 上，支持事务和 upsert）

   3. ADS: Parquet （为外部 BI 工具提供高性能访问）

   4. 归档： Parquet （应用云存储生命周期策略）

四、 最佳实践

1. 优先考虑列式存储：除非有强理由（如必须的行式处理），否则默认选择列式格式（Parquet， ORC， Delta， Iceberg， Hudi）。

2. 拥抱开放标准：Parquet 是兼容性最好的选择。Iceberg 作为开放表格式，有助于避免供应商锁定。

3. 评估事务需求：如果数据管道复杂、涉及多源写入或需要处理数据修正，开放表格式（Delta， Iceberg， Hudi）带来的 ACID 保证和 MERGE INTO 能力价值巨大。

4. 利用压缩：无论选择哪种格式，都应启用合适的压缩算法（如 ZSTD 在压缩比和速度间平衡较好，SNAPPY 速度快）。

5. 分区与分桶 （Partitioning & Bucketing）：

   1. 分区：按高基数、常用于过滤的字段分区（如 date， region），能大幅减少扫描数据量。

   2. 分桶：对特定字段（如 user_id）进行哈希分桶，可优化 JOIN 和 AGGREGATE 性能。Delta Lake/Iceberg/Hudi 对分区演化的支持更好。

6. 文件大小优化：避免产生大量小文件（影响读取性能）或过大的文件（影响并行度）。目标文件大小通常在 128MB - 1GB 之间。使用 OPTIMIZE （Delta Lake）， COMPACTION （Hudi）， RewriteDataFiles （Iceberg） 等命令合并小文件。

7. 元数据管理：确保数据目录（如 AWS Glue， Azure Purview， Apache Atlas）能正确解析所选格式的元数据（Schema， 分区信息）。

总结：

• 通用王者：Parquet 凭借其卓越的性能、极高的兼容性和成熟的生态，是绝大多数分析场景的安全且高效的选择。

• 现代化数据湖：当需要 ACID 事务、可靠更新、时间旅行或增量处理时，Delta Lake， Iceberg， Hudi 这些开放表格式是必然趋势。它们在 Parquet/ORC 的基础上，提供了强大的元数据管理和数据操作能力。

• 流式与源数据：Avro 在处理事件流和需要强模式演化的场景中依然不可替代。

• Hive 生态：ORC 在传统 Hive 环境中仍有重要地位。

最终选择应基于您的具体技术栈（是否使用 Databricks？）、业务需求（是否需要 upsert？）、团队技能和对开放性/供应商锁定的考量。在实践中，Parquet 作为基础，结合 Delta Lake 或 Iceberg 处理复杂场景，是一种非常强大和灵活的组合。