Hadoop压缩形式和Hive存储格式之介绍以及对比分析案例

最新推荐文章于 2021-12-01 19:17:44 发布

liweihope

最新推荐文章于 2021-12-01 19:17:44 发布

阅读量743

点赞数 3

文章标签： Haoop 压缩形式存储格式存储结构

本文链接：https://blog.csdn.net/liweihope/article/details/89353379

版权

文章目录

前言

之前的离线处理，有讲到有个ETL的过程，它实际上是把数据拆开按照指定的格式输出出来。之前的离线处理项目是只有map，没有reduce的，没有reduce就没有shuffle。
上篇的离线处理，是通过MapReduce的ETL过程，把数据输出到HDFS之上。这个数据采用的格式还是普通的文本格式，就是简简单单的纯文本格式。但是在生产上这样做是不行的。
在生产上面，每天的数据量很大，比如说每天数据量是500T，副本数为3，那就是1500T的数据，这样的话要占用的block块的数量要多少？这样肯定不行。
所以要在ETL的过程中把压缩加进去。

1.Hadoop之MapReduce用到的压缩

1.1压缩的优点缺点之间的较量

压缩带来的第一个好处就是减少存储磁盘空间，提高磁盘空间的利用率；压缩带来的第二大好处就是加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度（比如在shuffle阶段），因为文件变小了，那么传输的肯定越快了。
但是压缩同时也会带来一个坏处，当你去使用数据时，需要先将数据解压，那么解压和压缩都会加重CPU的负荷。而且压缩的越狠，耗费的时间越多。
在大数据中，任何一种调优，都不是万能的。有些场景适合这种调优，但是换一种场景，这种调优方式适得其反。
不同的场景选择不同的压缩方式，肯定没有一个一劳永逸的方法，如果选择高压缩比，那么对于cpu的性能要求要高，同时压缩、解压时间耗费也多；选择压缩比低的，对于磁盘io、网络io的时间要多，空间占据要多；对于支持分割的，可以实现并行处理。
比如说公司的CPU负载已经非常高了，那么这个时候肯定不能用压缩的。如果CPU负载很小，强烈建议开启压缩。磁盘和CPU之间的一个取舍，是压缩的优点和缺点的一个较量。
压缩技术有两种：有损和无损。

1.2压缩使用的场景

压缩场景：
①input数据采集：用Flume 采集到 HDFS（后面交给MapReduce/spark进行处理）这个过程可以用到压缩。
②temp中间过程：map之后数据有落到磁盘的过程可以用到压缩。
③output: 用Spark/MapReduce处理的数据输出到Hadoop上，这个过程可以用到压缩。
这三种场景，是不是需要用到压缩？用到的话用什么压缩格式最合理？不同的压缩格式，速度、压缩比、是否支持split都不一样。该怎样选择？
做一下 hadoop源码编译让hadoop支持常用的压缩。

1.3压缩方式以及split分片

压缩方式:Bzip2、Gzip、Lzo、Lz4、Snappy、Zlip等
它们的压缩比、压缩速度以及是否支持split分片这三个点的比较在之前的博客已经写的很详细。
之前的博客：https://blog.csdn.net/liweihope/article/details/89672763
（非常重要）支持分片的只有BIZP2和LZO(LZO默认不支持，需要建index，才支持)。假如说，现在一个Snappy压缩的文件1T的大小，作为map的输入，但是它是不支持分片的，那么它就只能由一个map去处理，不能多个map并行处理了，那这1T的文件要处理猴年马月了。
之前的离线处理并没有采用压缩，所以它是默认的文本格式，它是支持分片的。
所以不同的场景选择不同的压缩方式，没有哪一个压缩方式是一劳永逸。

1.4解析MapReduce阶段的压缩解压以及压缩方式选择

下面用张图来解析一下MapReduce阶段的压缩解压：在这里插入图片描述
1.第一次传入压缩文件，应选用可以切片的压缩方式，否则整个文件将只有一个Map执行。Use Compressd Map Input:从HDFS中读取文件进行Mapreuce作业，如果数据很大，可以使用压缩并且选择支持分片的压缩方式（Bzip2,LZO），可以实现并行处理，提高效率，减少磁盘读取时间，同时选择合适的存储格式例如Sequence Files，RC,ORC等。
2.第二次压缩应选择压缩解压速度快的压缩方式，生产中，Map阶段数据落盘通常使用snappy压缩格式（快速压缩解压）。Compress Intermediate Data:Map输出作为Reducer的输入，需要经过shuffle这一过程，需要把数据读取到一个环形缓冲区，然后读取到本地磁盘，所以选择压缩可以减少了存储文件所占空间，提升了数据传输速率，建议使用压缩速度快的压缩方式，例如Snappy和LZO。
3.第三次压缩有两种场景分别是：一.当输出文件为下一个job的输入，选择可切分的压缩方式例如：BZip2。二.当输出文件直接存到HDFS，作为归档，选择压缩比高的压缩方式。reduce阶段数据落盘通常使用gzip或bzip2进行压缩（减少磁盘使用）。Compress Reducer Output:进行归档处理或者链接Mapreduce的工作（该作业的输出作为下个作业的输入），压缩可以减少了存储文件所占空间，提升了数据传输速率，如果作为归档处理，可以采用高的压缩比（Gzip,Bzip2），如果作为下个作业的输入，考虑是否要分片进行选择。

2.如何配置压缩方式

core-site.xml里面配置压缩

<property>
<name>io.compression.codecs</name>
<value>
org.apache.hadoop.io.compress.GzipCodec,
org.apache.hadoop.io.compress.DefaultCodec,
org.apache.hadoop.io.compress.BZip2Codec,
org.apache.hadoop.io.compress.SnappyCodec
</value>
</property>

用不同的压缩方式要配置不同的CodeC
可以去官网的core-default.xml的默认配置里看io.compression.codecs相关说明。
在这里只是配置了各种压缩方式的codec，还没有使用，真正使用是在mapred-site.xml配置。

<!-- 配置MapReduce段最终输出的压缩,BZip2，官方默认为false，不压缩-->	
<property>
    <name>mapreduce.output.fileoutputformat.compress</name>
    <value>true</value>
</property>
<property>
    <name>mapreduce.output.fileoutputformat.compress.codec</name>
    <value>org.apache.hadoop.io.compress.BZip2Codec</value>
</property>	

<!-- 配置 Map段输出的压缩,snappy,这里先配置上，为false，后面需要再改成true-->
  <property>
      <name>mapreduce.map.output.compress</name> 
      <value>false</value>
  </property>
              
  <property>
      <name>mapreduce.map.output.compress.codec</name> 
      <value>org.apache.hadoop.io.compress.SnappyCodec</value>
   </property>

可以去官网的mapred-default.xml的默认配置里看mapreduce.output.fileoutputformat.compress相关说明。
在这里插入图片描述

另外注意：<value>com.hadoop.compression.lzo.LzoCodec</value>如果value这样配置默认结尾是lzo_deflate，如果com.hadoop.compression.lzo.LzopCodec这样配置会生成.lzo结尾的文件。
LzoCodec和LzopCodec区别：

1.LzoCodec比LzopCodec更快， LzopCodec为了兼容LZOP程序添加了如 bytes signature, header等信息
2.如果使用 LzoCodec作为Reduce输出，则输出文件扩展名为”.lzo_deflate”，它无法被lzop读取；
3.如果使用LzopCodec作为Reduce输出，则扩展名为”.lzo”，它可以被lzop读取生成lzo index job的”DistributedLzoIndexer“无法为 LzoCodec即 “.lzo_deflate”扩展名的文件创建index
4.”.lzo_deflate“文件无法作为MapReduce输入，”.LZO”文件则可以。
综上所述得出最佳实践：map输出的中间数据使用 LzoCodec，reduce输出使用 LzopCodec

3.压缩方式的使用

上面配置的是MapReduce输出是Bzip2压缩，运行一个Wordcount案例：

[hadoop@hadoop001 mapreduce]$ hadoop jar hadoop-mapreduce-examples-2.6.0-cdh5.7.0.jar wordcount /tmp/input/hive_wc.txt /tmp/output/

[hadoop@hadoop001 mapreduce]$ hdfs dfs -ls /tmp/output
Found 2 items
-rw-r--r--   1 hadoop supergroup          0 2019-04-30 02:46 /tmp/output/_SUCCESS
-rw-r--r--   1 hadoop supergroup         61 2019-04-30 02:46 /tmp/output/part-r-00000.bz2
#注意这里查看压缩文件，它要用Bzip2工厂，加载数据并初始化bzip2本地库，然后看到数据
[hadoop@hadoop001 mapreduce]$ hdfs dfs -text /tmp/output/part-r-00000.bz2
19/04/30 02:49:24 INFO bzip2.Bzip2Factory: Successfully loaded & initialized native-bzip2 library system-native
19/04/30 02:49:24 INFO compress.CodecPool: Got brand-new decompressor [.bz2]
hello   4
welcome 1
world   2
[hadoop@hadoop001 mapreduce]$

从上面可以看出，压缩格式目前是BZip2格式了。而且从上面可以看出，对于压缩或者不压缩，对于用户来说，它是不感知的，没有感觉的。

4.压缩在Hive中的使用方法

4.1不用压缩的情况

现在在hive上创建一张表，然后把数据加载进去。

create table page_views(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
) row format delimited fields terminated by '\t';

hive (g6)> load data local inpath '/home/hadoop/data/page_views.dat' overwrite into table page_views;
Loading data to table g6.page_views
Table g6.page_views stats: [numFiles=1, numRows=0, totalSize=19014993, rawDataSize=0]
OK
Time taken: 0.9 seconds
hive (g6)> select * from page_views limit 1;
OK
track_time      url     session_id      referer ip      end_user_id     city_id
2013-05-19 13:00:00     http://www.taobao.com/17/?tracker_u=1624169&type=1      B58W48U4WKZCJ5D1T3Z9ZY88RU7QA7B1       http://hao.360.cn/       1.196.34.243    NULL    -1
Time taken: 0.483 seconds, Fetched: 1 row(s)
hive (g6)>

然后看一下没有用压缩的大小：

[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views
18.1 M  18.1 M  /user/hive/warehouse/g6.db/page_views
[hadoop@hadoop001 ~]$

4.2hive表中使用压缩的情况

在Hive中如何使用压缩呢？
官网上有相关说明：

#网址：https://cwiki.apache.org/confluence/display/Hive/CompressedStorage
#在Hive表中保持压缩，比不压缩存储具有更好的性能，无论是在磁盘使用率还是查询性能方面
Compressed Data Storage
Keeping data compressed in Hive tables has, in some cases, 
been known to give better performance than uncompressed storage; 
both in terms of disk usage and query performance.

You can import text files compressed with Gzip or Bzip2 directly into a table stored as TextFile. 
The compression will be detected automatically 
and the file will be decompressed on-the-fly during query execution.

在hive中用如下命令设置压缩：

#默认是不压缩的，你要自己去设置成true
hive (g6)> SET hive.exec.compress.output;
hive.exec.compress.output=false
hive (g6)> SET hive.exec.compress.output=true;

而且可以看一下使用的压缩方式：

hive (g6)> set io.compression.codecs;
io.compression.codecs=
            org.apache.hadoop.io.compress.GzipCodec,
            org.apache.hadoop.io.compress.DefaultCodec,
            org.apache.hadoop.io.compress.BZip2Codec,
            org.apache.hadoop.io.compress.SnappyCodec
         
hive (g6)> set mapreduce.output.fileoutputformat.compress.codec;
mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.BZip2Codec
hive (g6)>

如果你想修改成什么压缩，自己都可以去修改：

hive (g6)> set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec;
hive (g6)> set mapreduce.output.fileoutputformat.compress.codec;
mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec
hive (g6)> set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.BZip2Codec;
hive (g6)> set mapreduce.output.fileoutputformat.compress.codec;
mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.BZip2Codec
hive (g6)>

上面设置了hive压缩为Bzip2，现在再创建一张表，

hive (g6)> create table page_views_bzip2
         > as select * from page_views;

然后看一下大小：

#Hive未开启压缩之前是18.1M，开启Bzip2压缩后是3.6M
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_bzip2
3.6 M  3.6 M  /user/hive/warehouse/g6.db/page_views_bzip2
[hadoop@hadoop001 ~]$

在这里插入图片描述

5.Hive中数据文件的存储结构（或者说存储格式/文件格式）

5.1hive常见的存储结构

去官网可以看到hive里常用的文件格式：

#这里要知道SEQUENCEFILE、TEXTFILE、RCFILE、ORC、PARQUET这五个
file_format:
  : SEQUENCEFILE
  | TEXTFILE    -- (Default, depending on hive.default.fileformat configuration)
  | RCFILE      -- (Note: Available in Hive 0.6.0 and later)
  | ORC         -- (Note: Available in Hive 0.11.0 and later)
  | PARQUET     -- (Note: Available in Hive 0.13.0 and later)
  | AVRO        -- (Note: Available in Hive 0.14.0 and later)
  | JSONFILE    -- (Note: Available in Hive 4.0.0 and later)
  | INPUTFORMAT input_format_classname OUTPUTFORMAT output_format_classname

生产上如果采用列式存储（行业里面差不多99%都使用列式存储），用的最多的是：ORC和PARQUET。
另外

SEQUENCEFILE：生产中绝对不会用，key-vvalue格式，比源文本格式占用磁盘更多
TEXTFILE：生产中用的多，行式存储
RCFILE：生产中不会用，行列混合存储
ORC：生产中最常用，列式存储，基于ORC优化的
PARQUET：生产中最常用，列式存储
AVRO：生产中几乎不用，不用考虑
JSONFILE：生产中几乎不用，不用考虑
INPUTFORMAT：生产中几乎不用，不用考虑

5.2行式存储与列式存储

什么是行式存储？什么叫列式存储？各自的优缺点是什么？
在这里插入图片描述
从图上可以看出，
行式存储：一行数据一定是在同一个block块中，可能是多行存储在一个块中，任何的select 底层都是全字段查询。
列式存储：一行数据不同列可以在不同的block块中。
行式存储：
可以进行压缩。

优点：select *from xxx 所有数据都出来了，因为它所有的数据都在一个块里面。
缺点：select a,c from xxx 你仅仅只想要a、c两列，但是它也会把所有数据都加载进来，因为它是行式存储，它是一行一行的读的。

列式存储：
假如A、B存在一个块里面，C在一个块里面，D在一个块里面

优点：如果你去select a,c from xxx ，那么它只会前面两个块去读，跟第三个块之间不会发生IO
缺点：select *from xxx 你去查询所有列，那么现在它的列分别在三个块里面，会发生数据重组
行业里面差不多99%都使用列式存储

5.3各种存储结构的举例对比

5.3.1文本格式TEXTFILE

存储方式：行存储；
默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合Gzip、Bzip2使用(系统自动检查，执行查询时自动解压)，但使用这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。

5.3.2 SEQUENCEFILE

SEQUENCEFILE：它是以序列化的方式存储格式，一种<key,value>的格式。
简单了解一下即可。
现在创建一张存储格式为sequencefile 的表：

create table page_views_seq(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
) row format delimited fields terminated by '\t'
stored as sequencefile ;

然后把数据加载进来：

hive (g6)> load data local inpath '/home/hadoop/data/page_views.dat' into table page_views_seq;
Loading data to table g6.page_views_seq
Failed with exception Wrong file format. Please check the file's format.
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MoveTask
hive (g6)> 
#报错原因是：原始page_views.dat文件是textfile文本文件，直接导入到sequencefile，是导不进去的。
#这个时候需要借助一张临时表把它导进去
hive (g6)> load data local inpath '/home/hadoop/data/page_views.dat' into table page_views_seq;
#这样就可以了

然后看一下大小

#sequencefile 文件大小20.6 M 
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_seq
20.6 M  20.6 M  /user/hive/warehouse/g6.db/page_views_seq
#sequencefile 文件名
[hadoop@hadoop001 ~]$ hdfs dfs -ls /user/hive/warehouse/g6.db/page_views_seq
Found 1 items
-rwxr-xr-x   1 hadoop supergroup   21603675 2019-04-30 14:58 /user/hive/warehouse/g6.db/page_views_seq/000000_0
#原始文本文件大小18.1 M
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views/
18.1 M  18.1 M  /user/hive/warehouse/g6.db/page_views
[hadoop@hadoop001 ~]$

可以看出，用了sequencefile 存储格式之后，文件更大了，生产上面是绝对不会用的。
为什么用了之后文件更大了？
因为它存储的东西更多了，比如记录的长度、key的长度、key的值、value的值等。
简单了解一下即可。

5.3.3 RCFILE

不是严格意义的列式存储，它是行列混合的一个存储，这个架构是利用了先行式存储再列式存储的方式，它的性能很低。
对查询并没有什么大的提升，只是节省了10%的空间。
生产上绝对不会用的。
建一个存储为rcfile的表：

create table page_views_rc(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
) row format delimited fields terminated by '\t'
stored as rcfile ;
#插入数据：
hive (g6)> insert overwrite table page_views_rc select * from page_views ;
#看一下大小：
[hadoop@hadoop001 ~]$  hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_rc
17.9 M  17.9 M  /user/hive/warehouse/g6.db/page_views_rc
[hadoop@hadoop001 ~]$

5.3.4 ORC（重点掌握）

它是优化过后的列式存储，它是基于RC又做了更好的底层的优化。它提供了一种非常高效的方式去存储hive上的数据。

#官网
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC#LanguageManualORC-ORCFiles
#官网解释
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的表：

create table page_views_orc(
track_time string,
url string,
session_id string,
referer string,
ip string,
end_user_id string,
city_id string
) row format delimited fields terminated by '\t'
stored as orc ;

hive (g6)> insert overwrite table page_views_orc select * from page_views;

然后查看大小：

#原来18.1M，现在2.8M，压缩还是比较厉害的
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_orc
2.8 M  2.8 M  /user/hive/warehouse/g6.db/page_views_orc

原来18.1M，现在2.8M，压缩还是比较厉害的，因为看官网，它默认会自动使用ZLIB压缩。ZLIB压缩也可以手动去掉，或者手动指定其它压缩。
在这里插入图片描述
现在来手动指定不压缩，创建一张表：

create table page_views_orc_none
stored as orc tblproperties ("orc.compress"="NONE") 
as select * from page_views;

然后看一下大小：

#能看出来，原来18.1M，现在即使不压缩，也是7.7M，用zlib压缩的话是2.8M，这种压缩比是非常高的
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_orc_none
7.7 M  7.7 M  /user/hive/warehouse/g6.db/page_views_orc_none
[hadoop@hadoop001 ~]$

能看出来，采用ORC，原来18.1M，现在即使不压缩，也是7.7M，用zlib压缩的话是2.8M，这种压缩比是非常高的。

5.3.5 Parquet（重点掌握）

生产上ORC和Parquet半斤八两，都可以。但是从空间上来看，ORC可能会好一些。

#官网
https://cwiki.apache.org/confluence/display/Hive/Parquet

这些引擎都支持Parquet。
下面通过案例来演示一遍如何使用以及效果。
对于Parquet不同的版本用不同的语法。不过在这里，直接按照下面这样就可以了。
而且Parquet设置压缩和以上的存储形式也不一样。记住就行了。

hive (g6)> set parquet.compression=gzip;
hive (g6)> set parquet.compression;
parquet.compression=gzip

create table page_views_parquet_gzip
stored as parquet 
as select * from page_views;

然后看一下大小：

#可以看出原来18.1M，现在使用parquet后是3.9M
[hadoop@hadoop001 ~]$ hdfs dfs -du -s -h /user/hive/warehouse/g6.db/page_views_parquet_gzip
3.9 M  3.9 M  /user/hive/warehouse/g6.db/page_views_parquet_gzip
[hadoop@hadoop001 ~]$

5.3.6 总结

他们各自使用压缩，加上自己的存储格式，能够使磁盘空间减少非常多，效果非常好。
三个选择，进来的时候，是textfile文本格式，不用动，如果要是列式存储的话，就选择ORC和Parquet。

5.3.7 几种存储格式的查询性能举例比较

以上都是从存储的角度来考虑，那么查询的性能如何考虑？
下面通过一个案例来进行分析;
现在通过一个session_id来查询统计数据量

5.3.7.1查询普通格式的表（textfile格式）

先查一个普通的表：

hive (g6)> select count(*) from page_views where session_id='B58W48U4WKZCJ5D1T3Z9ZY88RU7QA7B1';
...此处省略100字
MapReduce Jobs Launched: 
Stage-Stage-1: Map: 1  Reduce: 1   Cumulative CPU: 3.54 sec   HDFS Read: 19022693 HDFS Write: 2 SUCCESS
Total MapReduce CPU Time Spent: 3 seconds 540 msec
OK
_c0
6
Time taken: 33.775 seconds, Fetched: 1 row(s)
hive (g6)>

从HDFS Read: 19022693（就是那个18.1M）这里可以看出，去查询普通的表，它会全表扫描。

5.3.7.2 查询存储为RC格式的表

然后现在查询一下RC的表：

hive (g6)> select count(*) from page_views_rc where session_id='B58W48U4WKZCJ5D1T3Z9ZY88RU7QA7B1';
...此处省略100字
MapReduce Jobs Launched: 
Stage-Stage-1: Map: 1  Reduce: 1   Cumulative CPU: 3.47 sec   HDFS Read: 3725349 HDFS Write: 2 SUCCESS
Total MapReduce CPU Time Spent: 3 seconds 470 msec
OK
_c0
6
Time taken: 33.473 seconds, Fetched: 1 row(s)
hive (g6)>

从HDFS Read: 3725349这里可以看出，它少了很多。

5.3.7.3 查询存储为ORC格式的表

然后现在查询一下ORC的表(带有zlib压缩的)：

hive (g6)> select count(*) from page_views_orc where session_id='B58W48U4WKZCJ5D1T3Z9ZY88RU7QA7B1';
...此处省略100字
MapReduce Jobs Launched: 
Stage-Stage-1: Map: 1  Reduce: 1   Cumulative CPU: 3.24 sec   HDFS Read: 1257469 HDFS Write: 2 SUCCESS
Total MapReduce CPU Time Spent: 3 seconds 240 msec
OK
_c0
6
Time taken: 33.933 seconds, Fetched: 1 row(s)
hive (g6)>

从HDFS Read: 1257469这里可以看出，它扫描的更少了，因为它里面是带了索引的。

5.3.7.4 查询存储为Parquet格式的表

然后现在查询一下parquet的表（带有gzip压缩的）：

hive (g6)> select count(*) from page_views_parquet_gzip where session_id='B58W48U4WKZCJ5D1T3Z9ZY88RU7QA7B1';
...此处省略100字
MapReduce Jobs Launched: 
Stage-Stage-1: Map: 1  Reduce: 1   Cumulative CPU: 4.32 sec   HDFS Read: 1624470 HDFS Write: 2 SUCCESS
Total MapReduce CPU Time Spent: 4 seconds 320 msec
OK
_c0
6
Time taken: 35.694 seconds, Fetched: 1 row(s)
hive (g6)>

从HDFS Read: 1624470这里可以看出，它扫描的比ORC的稍微多一些。
以后要测性能，要从两方面考虑，一个是存储一个查询。

总结

相同数据量的数据，列式存储（比如ORC、PARQUET）占的磁盘空间远低于行式存储（如textfile、Sequencefile），当查询部分字段是，列式存储的数据只需加载对应的列数据即可。存少读少，极大磁盘使用以及IO，相对减少资源（内存，cpu）不必要的浪费，故列式存储在大数据领域完爆行式存储，行业里面差不多99%都使用列式存储。

参考博客：
https://blog.csdn.net/yu0_zhang0/article/details/79538398
https://blog.csdn.net/qq_32641659/article/details/89339143
https://blog.csdn.net/qq_26442553/article/details/80300714

liweihope

关注

3
点赞
踩
12

收藏

觉得还不错? 一键收藏
2
评论
Hadoop压缩形式和Hive存储格式之介绍以及对比分析案例

之前的离线处理，有讲到有个ETL的过程，它实际上是把数据拆开按照指定的格式输出出来。之前的离线处理项目是只有map，没有reduce的，没有reduce就没有shuffle。...
复制链接

扫一扫