Hive文件存储格式查询性能的比较

本文对比了Hive中TextFile、ORCFile及Parquet三种存储格式的特点与性能。通过实验发现ORCFile和Parquet在文件大小和查询速度方面优于TextFile,尤其适用于大数据处理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、Hive的文件存储格式

Hive总共支持以下几种文件存储格式:

  • Text File
  • SequenceFile
  • RCFile
  • Avro Files
  • ORC Files
  • Parquet
  • Custom INPUTFORMAT and OUTPUTFORMAT

    这里,我们主要比较Text File,ORC File,Parquet文件存储格式的查询性能,在比较之前,我们先简单介绍一下这三种文件存储格式。对于Text File就是我们默认的存储格式,行式存储,这里就不用讲解了。
    ORC File

1.ORC介绍

什么是ORC文件存储格式呢?先看看官网的介绍:

The Optimized Row Columnar (ORC) file format provides a highly efficient way to store Hive data. It was designed to overcome limitations of the other Hive file formats. Using ORC files improves performance when Hive is reading, writing, and processing data.

ORC全称(Optimized Row Columnar),是一种高效的存储数据的文件格式,克服了其他文件格式的一些限制,提高了Hive读写数据的性能。

ORC实际上是在RC文件存储格式做了一些优化,它的主要优点有:
  (1)、每个task只输出单个文件,这样可以减少NameNode的负载;
  (2)、支持各种复杂的数据类型,比如: datetime, decimal, 以及一些复杂类型(struct, list, map, and union);
  (3)、在文件中存储了一些轻量级的索引数据;
  (4)、基于数据类型的块模式压缩:a、integer类型的列用行程长度编码(run-length encoding);b、String类型的列用字典编码(dictionary encoding);
  (5)、用多个互相独立的RecordReaders并行读相同的文件;
  (6)、无需扫描markers就可以分割文件;
  (7)、绑定读写所需要的内存;
  (8)、metadata的存储是用 Protocol Buffers的,所以它支持添加和删除一些列。

2.ORC结构

下图是官网的ORC结构图:
这里写图片描述

在ORC格式存储的表中,它会将记录横向切分为多个stripes,每一个stripe以列为单位进行存储,所有列会保存在一个文件中,每个stripe的默认大小为256MB,相对于RCFile每个4MB的stripe而言,更大的stripe使ORC的数据读取更加高效。
关于更详细的介绍可查看官网【https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
hortonwork公司的介绍【https://zh.hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

PARQUET格式

Parquet仅仅是一种存储格式,它是语言、平台无关的,并且不需要和任何一种数据处理框架绑定,目前能够和Parquet适配的组件包括下面这些,可以看出基本上通常使用的查询引擎和计算框架都已适配,并且可以很方便的将其它序列化工具生成的数据转换成Parquet格式。

  • 查询引擎: Hive, Impala, Pig, Presto, Drill, Tajo, HAWQ, IBM Big SQL
  • 计算框架: MapReduce, Spark, Cascading, Crunch, Scalding, Kite
  • 数据模型: Avro, Thrift, Protocol Buffers, POJOs

二、性能比较

在进行测试之前,我们先看看HortonWork公司官网对这几种存储格式的比较分析:
这里写图片描述
从图中很明显看到ORC存储格式和Parquet存储格式对文件的存储比Text格式小很多,也就是说压缩比大很多。下面我们来实践测试一下。
为了进行比较测试三种存储格式,首先创建三张表,并且每一张表中插入100000表数据:

create table page_view(
user_ip string,
username string,
user_time string,
request_url string,
request_state string,
request_port string,
limited string,
des_url string,
brower string,
brower_limit string,
to_url string
)
row format delimited fields terminated by '\t'
stored as TEXTFILE;

load data local inpath '/opt/datas/page_view.log' into table page_view;

create table page_view_orc(
user_ip string,
username string,
user_time string,
request_url string,
request_state string,
request_port string,
limited string,
des_url string,
brower string,
brower_limit string,
to_url string
)
row format delimited fields terminated by '\t'
stored as ORC;

insert into table page_view_orc select * from page_view;

create table page_view_parquet(
user_ip string,
username string,
user_time string,
request_url string,
request_state string,
request_port string,
limited string,
des_url string,
brower string,
brower_limit string,
to_url string
)
row format delimited fields terminated by '\t'
stored as PARQUET;

insert into table page_view_parquet select * from page_view;

在创建好表之后,先来看看100000条数据在不同文件存储格式的存储下的大小:

#查看这三种格式的文件的大小:
dfs -du -h /user/hive/warehouse/db_hive.db/page_view;
34.0 M  /user/hive/warehouse/db_hive.db/page_view/page_view.log

dfs -du -h /user/hive/warehouse/db_hive.db/page_view_orc;
125.4 K  /user/hive/warehouse/db_hive.db/page_view_orc/000000_0

dfs -du -h /user/hive/warehouse/db_hive.db/page_view_parquet;
34.3 M  /user/hive/warehouse/db_hive.db/page_view_parquet/000000_0

很明显,在ORC格式存储的文件中,大小比Text小很多,也印证了上图。至于Parquet为什么和Text格式相差不多,可能是因为数据量不够大,但是通常情况下parquet存储相同的数据占用的大小会比TEXT格式要小。

接着,我们来编写查询语句,比较它们的查询速度:

#测试三种存储格式查询数据的速度
select user_time,count(*) cnt from page_view group by user_time order by cnt desc limit 20;
Time taken: 73.15 seconds, Fetched: 1 row(s)

select user_time,count(*) cnt from page_view_orc group by user_time order by cnt desc limit 20;
Time taken: 57.091 seconds, Fetched: 1 row(s)

select user_time,count(*) cnt from page_view_parquet group by user_time order by cnt desc limit 20;
Time taken: 55.526 seconds, Fetched: 1 row(s)

select count(*) from page_view;
Time taken: 25.124 seconds, Fetched: 1 row(s)

select count(*) from page_view_orc;
Time taken: 25.759 seconds, Fetched: 1 row(s)

select count(*) from page_view_parquet;
Time taken: 24.998 seconds, Fetched: 1 row(s)

从上面的查询耗时的结果上看,在执行比较复杂的查询语句时,ORC格式和Parquet格式要比Text格式快很多。

从上面的结果可以得出结论:ORC和Parquet存储格式要比Text格式读写数据的性能要好,在企业中一般大多情况下回采用这两种存储格式。
这时,我们可能要问为什么这两种存储格式的性能会好?什么时候用到这两种存储格式呢?这里简单说明一下,在很多时候,我们查询语句都会用到where语句对某一列进行筛选,如果采用行式存储格式(TEXT File),我们要在一行中找出对应的列,然后再进行筛选,而使用ORC和Parquet列式存储格式,会直接定位在某一列进行筛选,因此性能会提高很多。

最后,我们来讲一下ORC支持的压缩格式,ORC支持三种压缩:Lzip,Snappy,none。最后一种就是不压缩。

这里我们也可以实际测试一下lzip和snappy的压缩比:

#测试压缩:

create table page_view_orc_snappy(
user_ip string,
username string,
user_time string,
request_url string,
request_state string,
request_port string,
limited string,
des_url string,
brower string,
brower_limit string,
to_url string
)
row format delimited fields terminated by '\t'
stored as ORC tblproperties ("orc.compress"="SNAPPY");  #snappy大写

insert into table page_view_orc_snappy select * from page_view;     #会执行三个mapreduce程序,select,转换为orc格式,snappy压缩
Time taken: 17.879 seconds

select count(*) from page_view_orc_snappy;
Time taken: 26.956 seconds, Fetched: 1 row(s)

dfs -du -h /user/hive/warehouse/db_hive.db/page_view_orc_snappy;
329.4 K  /user/hive/warehouse/db_hive.db/page_view_orc_snappy/000000_0
#因为orc默认的是lzip,压缩比大于snappy

这里我们在采用snappy压缩格式来创建一张表后,相同的数据大小为329.4k,而在上面我们可以看到ORC格式采用默认的压缩格式大小为125.4 K,为什么压缩后反而会变大呢?有很多人敢打很奇怪,实际上ORC默认的压缩格式是lzip格式,这也说明lizp的压缩比大于snappy的压缩比。

综上,我们可以得出,在处理较大数据,进行复杂的查询时可以采用ORC或者Parquet存储格式以及压缩的方式来处理数据会提高很多性能。

<think>嗯,用户想了解Hive支持的存储格式以及如何选择合适的。首先我需要回忆Hive常见的存储格式有哪些。记得有TextFile、SequenceFile、RCFile、ORCFile、Parquet这些。然后每个格式的特点和适用场景需要理清楚。 比如TextFile是最基础的,纯文本,适合导入导出方便,但性能可能差。SequenceFile是二进制,支持压缩和分割,可能适合中间数据存储。RCFile是行列混合,而ORC和Parquet是更高效的行列式存储,适合查询性能要求高的场景。 然后用户可能关心如何选择,比如需要考虑压缩、查询速度、是否频繁更新、是否与外部系统交互等因素。比如ORC和Parquet在分析查询时表现好,但如果需要和Sqoop交互的话可能得用TextFile,像引用4提到的。 还要注意引用里的信息,比如引用2提到ORC和Parquet实际应用多,引用4提到Sqoop需要TextFile。所以回答里要结合这些引用,给出格式列表和使用建议,最后生成相关问题。需要确保LaTeX格式正确,行内用$,独立公式用$$,但问题里可能数学公式不多。可能涉及压缩类型如Snappy、Gzip,这些在引用1里提到,所以需要关联到存储格式的选择中。</think>### Hive支持的存储格式及使用场景 Hive支持多种存储格式,每种格式针对不同场景优化。以下是主要格式的特点和应用建议: #### 一、存储格式列表 1. **文本格式(TextFile)** - **特点**:默认格式,纯文本存储(如CSV、TSV),可读性强,但无压缩且查询效率低 - **适用场景**: - 数据导入/导出需求频繁的场景(如与Sqoop交互时需使用TextFile[^4]) - 临时数据或小规模数据集 - **示例建表语句**: ```sql CREATE TABLE logs (id INT, content STRING) STORED AS TEXTFILE; ``` 2. **二进制序列化文件(SequenceFile)** - **特点**:二进制键值对存储,支持压缩和分片,适合Hadoop生态链交互 - **适用场景**: - MapReduce作业中间结果存储 - 需兼容Hadoop其他组件的场景 3. **行列式文件(RCFile)** - **特点**:行组内列式存储,压缩比高于TextFile,但性能弱于ORC/Parquet - **适用场景**: - 历史遗留系统兼容 - 需平衡存储查询的场景(逐渐被ORC/Parquet替代) 4. **优化的行列式文件(ORCFile)** - **特点**: - 列式存储,支持高压缩比(如Zlib、Snappy[^1]) - 内置索引(如布隆过滤器)加速查询 - 支持ACID事务 - **适用场景**: - 大规模数据分析(如数仓核心表) - 高并发查询场景[^2] - **示例建表语句**: ```sql CREATE TABLE user_behavior (user_id STRING, action STRING) STORED AS ORC; ``` 5. **Apache Parquet** - **特点**: - 列式存储,支持嵌套数据结构 - 高效压缩(兼容Snappy、Gzip[^1]) - 适合Spark等生态工具 - **适用场景**: - 复杂嵌套结构数据处理(如JSON日志) - 跨计算引擎协作场景(如Hive+Spark) #### 二、选择依据 $$ \text{选择公式} = \max \left( \frac{\text{查询性能} \times \text{压缩比}}{\text{写入成本} + \text{兼容性约束}} \right) $$ 1. **优先ORC/Parquet**:99%的生产场景首选,例如: - ORC适合Hive专属高频分析 - Parquet适合跨平台数据湖 2. **强制使用TextFile**: - 与Sqoop交互时[^4] - 数据需直接人工查看 3. **特殊需求**: - 频繁更新数据 → 使用ORC(支持ACID) - 极致压缩 → ORC+Zlib压缩 #### 三、性能对比 | 格式 | 压缩比 | 查询速度 | 写入速度 | 适用操作类型 | |------------|--------|----------|----------|--------------------| | TextFile | 低 | 慢 | 快 | 全表扫描 | | ORC | 高 | 快 | 中 | 列裁剪/聚合 | | Parquet | 高 | 快 | 中 | 嵌套查询/跨平台 |
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值