在Hadoop生态中，Parquet因其列式存储特性成为大数据分析的首选格式，而ORC则在Hive生态中表现优异，两者均比传统的TextFile格式在查询速度和存储压缩上具有显著优势。
随着数据量的爆炸式增长，传统的行式存储格式已无法满足海量数据的快速检索需求，Hadoop生态圈中的数据存储格式经历了从简单文本到复杂二进制格式的演变，选择合适的存储格式，直接决定了数据仓库的查询效率、存储成本以及计算资源的消耗，业内专家指出，格式的选择并非一成不变，而是需要根据具体的业务场景、查询模式以及使用的计算引擎来综合考量。
![26 [大数据] hive 4种文件存储格式](https://i1.hdslb.com/bfs/archive/9fa31f9196cb1edab8804923f3e091f02a1b5a8a.jpg)
主流Hadoop存储格式深度解析
在Hadoop生态中，主要有三种广泛使用的存储格式：TextFile、SequenceFile和列式存储格式（如Parquet和ORC），列式存储格式因其独特的设计,成为现代数据湖和数仓的主流选择。
列式存储 vs 行式存储：底层逻辑对比
行式存储（如TextFile）将一行数据的所有字段连续存储在一起，这种格式适合全表扫描或写入大量数据，但在进行聚合查询时，需要读取大量无关数据，造成I/O浪费，列式存储则将同一字段的所有数据连续存储，在查询“销售额”时，只需读取“销售额”这一列的数据，无需加载“客户ID”、“日期”等其他字段。
- I/O效率：列式存储能大幅减少磁盘I/O,因为只读取需要的列。
- 压缩比：同一列的数据类型相同，数值分布规律性强，压缩算法（如RLE、Delta Encoding）效果更佳，通常能节省50%-70%的存储空间。
- 查询速度：对于聚合查询（SUM, AVG, COUNT）和过滤查询，列式存储速度提升显著，通常比行式存储快
数倍至数十倍
。
Parquet：通用型列式存储的标杆
Parquet是Apache Hadoop生态中最流行的列式存储格式之一，最初由Twitter和Cloudera开发，它支持嵌套数据结构，与Hive、Spark、Presto等主流计算引擎兼容性极佳。
- 架构优势：Parquet文件包含元数据，记录了每一列的数据类型、编码方式等信息，这使得查询引擎能够快速定位数据,无需解析整个文件。
- 兼容性：支持多种编程语言（Java, Python, C++等）读写,适合多语言协作的数据平台。
- 适用场景：适用于需要频繁进行复杂查询、聚合分析的场景，尤其是使用Spark SQL或Presto进行即席查询（Ad-hoc Query）时。
ORC：Hive生态的优化利器
ORC（Optimized Row Columnar）是Apache Hive专用的列式存储格式，它在Parquet的基础上进行了进一步优化,特别是在Hive环境中表现卓越。
- 索引机制：ORC文件内置了行组（Row Group）、页（Page）级别的索引,支持更细粒度的数据裁剪。
- Predicate Pushdown：支持谓词下推，即在读取数据前，先在存储层过滤掉不满足条件的数据,进一步减少计算量。
- 适用场景：主要适用于基于Hive的数据仓库,特别是需要高并发查询和复杂ETL流程的场景。
如何根据业务场景选择最佳格式
选择存储格式不能盲目跟风，必须结合具体的业务需求，不同格式在写入性能、查询性能、压缩率和兼容性之间存在着权衡。
数据写入频率与查询频率的权衡
如果业务场景是高频写入、低频查询（如日志采集、实时数据接入）,则行式存储或列式存储的写入优化版本可能更合适。
- 高频写入场景：TextFile或SequenceFile写入速度快，但查询慢，若使用Parquet，需启用动态分区和批量写入,以避免小文件问题。
- 低频写入、高频查询场景：Parquet和ORC是首选，虽然写入时需要额外的编解码开销,但查询时的性能提升足以抵消这一成本。
计算引擎的兼容性考量
不同的计算引擎对存储格式的支持程度不同,这直接影响开发效率和系统稳定性。
- Spark生态：Parquet是Spark的默认推荐格式，支持良好的嵌套结构，适合处理JSON、Avro等复杂数据。
- Hive生态：ORC在Hive中表现更佳，尤其是当使用Hive作为主要查询引擎时,ORC的索引和谓词下推优势能显著提升查询速度。
- Presto/Trino：Parquet和ORC均支持良好,但Parquet在跨引擎兼容性上略占优势。
实操建议：格式转换策略
在实际生产中，数据格式转换是常见操作，以下是一个简单的Spark SQL转换示例,将TextFile转换为Parquet：
CREATE TABLE my_table_parquet STORED AS PARQUET AS SELECT FROM my_table_text;
此操作会将原有数据重新编码为列式存储，虽然耗时较长,但后续查询性能将大幅提升。
存储格式优化的关键实践
选择合适的格式只是第一步,合理的配置和优化才能发挥最大效能。
小文件问题的治理
Hadoop生态中，小文件是性能杀手，无论是Parquet还是ORC,都应避免生成大量小文件。
- 合并策略：在写入数据前,使用Coalesce或Repartition算子减少分区数。
- 动态分区：启用动态分区,避免手动管理分区目录。
- 定期优化：使用Hive的MSCK REPAIR TABLE或Spark的OPTIMIZE命令,定期合并小文件。
压缩算法的选择
压缩算法直接影响存储成本和CPU开销，常见的压缩算法包括Snappy、Gzip、LZO等。
- Snappy：速度快，压缩比适中,适合对延迟敏感的场景。
- Gzip：压缩比高，但CPU开销大,适合对存储成本敏感且查询频率不高的场景。
- 行业共识认为，在大多数大数据场景中，Snappy是平衡速度和存储的最佳选择，因为它支持切片（Splittable）,允许并行读取。
常见疑问解答
Parquet和ORC在Hadoop数据存储格式选择中哪个更好？
Parquet和ORC各有优劣，选择取决于技术栈，Parquet具有更好的跨引擎兼容性，适合Spark、Presto等多引擎混用的环境；ORC在Hive生态中表现更佳，支持更细粒度的索引和谓词下推，若主要使用Hive，建议优先选择ORC；若使用Spark或多引擎架构,Parquet是更稳妥的选择。
Hadoop数据存储格式转换会影响数据一致性吗？
在规范操作下，格式转换不会导致数据丢失或不一致，转换过程本质上是读取原始数据并重新编码为新格式，关键在于确保转换过程中的字符集、日期格式和精度设置一致，建议使用支持ACID事务的引擎（如Hive ACID或Delta Lake）进行转换,以确保数据完整性。
Parquet格式是否支持嵌套数据结构？
是的，Parquet原生支持嵌套数据结构（如Array、Map、Struct），这使得它能够直接存储JSON、Avro等复杂格式的数据，无需预先扁平化，这一特性使其在处理半结构化数据时具有显著优势，能够保留数据的原始层级关系,便于后续灵活查询。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/471702.html
