Hive优化篇-Hive数据存储格式

原创

已于 2023-02-16 09:42:16 修改 · 1.9k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#hive #大数据 #hadoop

于 2023-02-16 09:40:57 首次发布

本文详细介绍了Hive中的数据存储格式，包括行式存储的TextFile，二进制序列化的SequenceFile，列式存储的RCFile和ORCFile，以及ApacheParquet。强调了列式存储在查询效率和压缩方面的优势，特别是ORCFile的优化特性，如字典编码和Bit编码，以及其对ACID事务的支持。Parquet则因其在处理嵌套结构和多计算框架支持上的优势被提及。

前言

本文讲解 Hive 的数据存储，是 Hive 操作数据的基础。选择一个合适的底层数据存储文件格式，即使在不改变当前 Hive SQL 的情况下，性能也能得到数量级的提升。这种优化方式对学过 MySQL 等关系型数据库的小伙伴并不陌生，选择不同的数据存储引擎，代表着不同的数据组织方式，对于数据库的表现会有不同的影响。

Hive 数据存储常用的格式如下：

行式存储
文本格式（TextFile）
二进制序列化文件（SequenceFile）
列式存储
行列式文件（RCFile）
优化的行列式文件（ORCFile）
Apache Parquet

注：RCFile 和 ORCFile 并不是纯粹的列式存储，它是先基于行对数据表进行分组(行组)，然后对行组进行列式存储。

我们看下这几种存储结构的优缺点：

以下表格为例:

水平的行存储结构:

采用行式存储时，数据在磁盘上的组织结构为：

行存储模式就是把一整行存在一起，包含所有的列，这是最常见的模式。这种结构能很好的适应动态的查询。

比如：
select a from tableA 和 select a, b, c, d, e, f, g from tableA

这样两个查询其实查询的开销差不多，都需要把所有的行读进来过一遍，拿出需要的列。
而且这种情况下，属于同一行的数据都在同一个 HDFS 块上，重建一行数据的成本比较低。

但是这样做有两个主要的弱点：

当一行中有很多列，而我们只需要其中很少的几列时，我们也不得不把一行中所有的列读进来，然后从中取出一些列。这样大大降低了查询执行的效率。
基于多个列做压缩时，由于不同的列数据类型和取值范围不同，压缩比不会太高。

垂直的列存储结构:

采用列式存储时，数据在磁盘上的组织结构为：

列存储是将每列单独存储或者将某几个列作为列组存在一起。

好处：

列存储在执行查询时可以避免读取不必要的列。
而且一般同列的数据类型一致，取值范围相对多列混合更小，在这种情况下压缩数据能达到比较高的压缩比。

弱点：

这种结构在重建行时比较费劲，尤其当一行的多个列不在一个 HDFS 块上的时候。比如我们从第一个 DataNode 上拿到 column A，从第二个 DataNode 上拿到了 column B，又从第三个 DataNode 上拿到了 column C，当要把 A，B，C 拼成一行时，就需要把这三个列放到一起重建出行，需要比较大的网络开销和运算开销。

混合的 PAX 存储结构:

PAX 结构是将行存储和列存储混合使用的一种结构，主要是传统数据库中提高 CPU 缓存利用率的一种方法，并不能直接用到 HDFS 中。但是 RCFile 和 ORC 是继承自它的思想，先按行存再按列存。

本文重点讲解最后两种：Apache ORC 和 Apache Parquet，因为它们以其高效的数据存储和数据处理性能得以在实际的生产环境中大量运用。

TextFile

TextFile 为 Hive 默认格式，建表时不指定则默认为这个格式，导入数据时会直接把数据文件拷贝到 hdfs 上不进行处理。

stored as textfile;  -- 可不指定（默认格式）

TextFile 优缺点：

TextFile 格式因为不对导入的数据文件做处理，所以可以直接使用 load 方式加载数据，其他存储格式则不能使用 load 直接导入数据文件。所以 TextFile 的加载速度是最高的。
TextFile 格式虽然可以使用 Gzip 压缩算法，但压缩后的文件不支持 split。在反序列化过程中，必须逐个字符