Hive存储和读取文件的 5 种格式

Dear 丶 2024-04-18 11:36 109阅读 0赞

Hive文件存储的格式包括以下几类：

1.  TEXTFILE
2.  SEQUENCEFILE
3.  RCFILE
4.  ORCFILE
5.  Parquet

TEXTFILE为默认格式，建表时不指定的话，就会默认为这个格式，导入数据时会直接把数据文件拷贝到hdfs上不进行处理；

SEQUENCEFILE，RCFILE，ORCFILE格式的表不能直接从本地文件导入数据，数据要先导入到textfile格式的表中， 然后再从表中用insert导入SequenceFile,RCFile,ORCFile表中。

创建一张testfile\_table表，格式为textfile。

create table if not exists testfile_table( site string, url  string, pv   bigint, label string) row format delimited fields terminated by '\t' stored as textfile;
    
    load data local inpath '/app/weibo.txt' overwrite into table textfile_table;

## 一、TEXTFILE ##

默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合Gzip、Bzip2使用(系统自动检查，执行查询时自动解压)。

**但使用这种方式，Hive不会对数据进行块切分，从而无法对数据进行并行操作。**

示例：

set hive.exec.compress.output=true;  
    set mapred.output.compress=true;  
    set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;  
    set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;  
    insert overwrite table textfile_table select * from textfile_table;

## 二、SEQUENCEFILE ##

SequenceFile是Hadoop API提供的一种二进制文件支持，其具有使用方便、可分割、可压缩的特点。

SequenceFile支持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，一般建议使用BLOCK压缩。

示例：

set hive.exec.compress.output=true;  
    set mapred.output.compress=true;  
    set mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;  
    set io.compression.codecs=org.apache.hadoop.io.compress.GzipCodec;  
    SET mapred.output.compression.type=BLOCK;
    insert overwrite table seqfile_table select * from textfile_table;

## 三、RCFILE ##

RCFILE是Record Columnar的缩写，是Hadoop中第一个列文件格式。能够很好的压缩和快速的查询性能，但是不支持模式演进。通常写操作比较慢，比非列形式的文件格式需要更多的内存空间和计算量。

首先，其**将数据按行分块**，保证同一个record在一个块上，避免读一个记录需要读取多个block。其次，**块数据列式存储**，有利于数据压缩和快速的列存取。

每个行组的Metadata里维护了行组的纪录数和每个column及每个Column纪录的长度，除此之外就没有太多别的黑科技了。编码方面Metadata使用RLE编码，Column Data使用Gzip等压缩格式（取决于写入方，比如MR程序）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70][]

示例：

## 四、ORCFILE() ##

ORCFILE的效率比RCFILE高，是RCFILE的改良版本。数据按行分块，每块按照列存储。压缩快，能够实现快速列存取。

ORC文件格式的一些基础思想和Parquet很像，也是先按行水平切割，在按列垂直切割，针对不同的列，采用特定的编码格式，最后再进一步对编码后的数据进行压缩。支持的编码格式（游程，字典，增量，bit），压缩格式（zlib，snappy，LZO等等）也基本一致。

Parquet对嵌套型数据结构的打散和重构的算法，来源于Dremel，通过两种level信息(definition level, repetition level)来标识特定数据在数据结构中层次位置，这两种信息和具体的列数据直接绑定，仅依靠这些信息和对象整体的Schema就能重构出这一列信息原有的层次结构。

与Parquet不同的地方是，ORC的实现更加简单直白一些。类似元素是否为Null的信息，就是一组bit位图，而对于元素个数不定的结构，如List，Map等数据结构，则在虚拟的父结构中维护了一个所拥有的子元素数量的信息。这样的带来的问题是，由单纯的某一叶节点列元素的数据出发，是无法独立构建复原出该列数据的结构层次的，需要借助父元素的辅助元数据才能完整复原。

在实现中，ORC对于每个列（基本的或符合结构的）采用了多个Stream分别存储数据和上述各类元数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 1][]

比如String类型的列，如果使用字典编码，那么会生成4个stream，PRESENT Stream用来标识具体String元素是否为Null，DATA Stream，连续存储字符串自身，DICTIONARY\_DATA Stream存储字典信息，LENGTH Stream存储每个元素的长度（用来从DATA Stream中定位和拆分数据）。

![20190909110811240.png][]

再比如Map类型的列，使用一个PRESENT Stream来标识具体每个Map元素是否为Null，用LENGTH Stream来标识每个Map元素内部有几个对象。

![20190909110857907.png][]

这种处理方式对比Dremel，看起来的确老土很多，理论深度上被甩了不止一条街，不过如果对于嵌套层次不复杂的数据结构，也还是简单有效的。但是，ORC的风评最近感觉明显比Parquet要盛，这又是为什么呢？

个人感觉，主要还是工程实现上的问题。除了核心的数据结构的打散和重建逻辑，ORC的文件格式里，还包含了其它的一些工程优化手段。比如索引（并不是传统意义上的全量排序用索引，更接近统计信息，比如列组的min，max，avg，count等信息，可以用作粗过滤手段，也可以覆盖部分聚合计算的需求），比如Bloomfilter等。而Parquet在这些方面有规划，但是目前似乎基本都没有做。

另外，如果仅从Hive的角度来说，一方面ORC是亲儿子，有些工作开展得比较早；另一方面扁平的数据结构，让Parquet在支持嵌套数据结构方面的优势并不能很好的体现，大概也是原因之一吧。

## 五、Parquet ##

Parquet能够很好的压缩，有很好的查询性能，支持有限的模式演进。但是写速度通常比较慢。这种文件格式主要是用在Cloudera Impala上面的。

Parquet的设计方案，整体来看，基本照搬了Dremel中对嵌套数据结构的打平和重构算法，通过高效的数据打平和重建算法，实现**按列存储（列组）**，进而对列数据引入更具针对性的编码和压缩方案，来降低存储代价，提升计算性能。

基本上就是一个文件由多个列组组成，数据先按列组（rowgroup）分段（也就是先做行切割），然后在列组内部对每个列的数据分列连续存储（columnchunk）（也就第二步做列切割），每个列内部的数据，再细分成page（可以近似的认为是再做行切割），最后，在文件的尾部，存储所有列组的元数据信息。

从并发度的角度考虑，行切割的目的，主要做为任务的切分单元，比如一个Map任务处理一个列组里的数据。然后列切割的目的，除了按需读取数据，也是做为IO的并发单元。最后Page的拆分，主要是从编码和压缩的角度，进行拆分，以page为单位进行压缩编码，如果近似的理解，也可以认为一定程度上起到了内存和CPU上用量的控制，**从Parquet文件的层面来说，Page是数据最小的读写单元**。

最后，对列数据提供多种编码方式，比如：字典（Dictionary)，游程（RLE），增量（DELTA）等等。

综上，Parquet主要还是对Dremel的存储模型这部分的一个实现，在Dremel存储模型定义范围之外，自己额外做的工作，并不多。（这里指的文件格式底层技术实现方面，工程上和大数据生态系各个组件的打通结合方面，还是做了大量的工作的）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 2][]

## 总结 ##

相比TEXTFILE和SEQUENCEFILE，RCFILE由于列式存储方式，数据加载时性能消耗较大，但是具有较好的压缩比和查询响应。数据仓库的特点是一次写入、多次读取，因此，整体来看，RCFILE相比其余两种格式具有较明显的优势。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/255c0f7225a64a9fac907f57491c85e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/62cef3f4bad54a5c9ff6f4557991b87f.png
[20190909110811240.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/75d5c2bf42cd49359dd447fc4751f983.png
[20190909110857907.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/69843f7875d14c5fbb7cd93eaa61dced.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/d0c93652e4714271ac3035c0d3f5ab25.png