Hive建立索引是一项比较消耗集群资源的工作，并且需要时刻关注是否更新。数据如有更新，就需要对索引进行重建。数据有更新却没有及时重建或者忘了重建，则会引发使用过程的异常。正是建立Hive索引成本高，又极容易引发异常，所以在实际生产中，Hive索引很少被用到。这时候有些人就想到使用列式存储。

相比于行式存储，列式存储的数据则是按列进行存储，每一列存储一个字段的数据，在进行数据查询时就好比走索引查询，效率较高。但是如果需要读取所有的列，例如一个数据平台刚接入数据，需要对所有的字段进行校验过滤，在这种场景下列式存储需要花费比行式存储更多的资源，因为行式存储读取一条数据只需要一次I/O操作，而列式存储则需要花费多次，列数越多消耗的I/O资源越多。

ORC的行列式存储结构结合了行式和列式存储的优点，在有大数据量扫描读取时，可以按行组进行数据读取。如果要读取某个列的数据，则可以在读取行组的基础上，读取指定的列，而不需要读取行组内所有行的数据及一行内所有字段的数据。

ORC文件结构由三部分组成：

1、条带（stripe）：ORC文件存储数据的地方，结构同样可以分为三部分：

        1）index data：保存了所在条带的一些统计信息，以及数据在stripe中的位置索引信息。

        2）rows data：数据存储的地方，由多个行组构成，数据以流（stream）的形式进行存储。存储两部分的数据，即metadata stream和data stream。

                a、metadata stream：用于描述每个行组的元数据信息。

                b、data stream：存储数据的地方。

        3）stripe footer：保存数据所在的文件目录。

2、文件脚注（file footer）：包含了文件中stripe的列表，每个stripe的行数，以及每个列的数据类型。它还包含每个列的最小值、最大值、行计数、求和等聚合信息。

3、postscript：含有压缩参数和压缩大小相关的信息。

简要了解完ORC的结构可以得知，ORC在每个文件中提供了3个级别的索引。

1、文件级：这一级的索引信息记录文件中所有stripe的位置信息，以及文件中所存储的每列数据的统计信息。

2、条带级别：该级别索引记录每个stripe所存储数据的统计信息。

3、行组级别：在stripe中，每10 000行构成一个行组，该级别的索引信息就是记录这个行组中存储的数据的统计信息。

程序可以借助ORC提供的索引加快数据查找和读取效率。程序在查询ORC文件类型的表时，会先读取每一列的索引信息，将查找数据的条件和索引信息进行对比，找到满足查找条件的文件。接着根据文件中的索引信息，找到存储对应的查询条件数据stripe，再借助stripe的索引信息读文件中满足查询条件的所有stripe块。之后再根据stripe中每个行组的索引信息和查询条件比对的结果，找到满足要求的行组。

2.2.2、ORC的数据类型

Hive在使用ORC文件进行存储数据时，描述这些数据的字段信息、字段类型信息及编码等相关信息都是和ORC中存储的数据放在一起的。ORC中每个块中的数据都是自描述的，不依赖外部的数据，也不存储在Hive的元数据库中。ORC提供的数据数据类型包含如下内容：

1、整型：包含boolean（1bit）、tinyint（8bit）、smallint（16bit）、int（32bit）、bigint（64bit）。

2、浮点型：包含float、double、decimal。

3、字符串类型：包含string、char、varchar。

4、二进制类型：包含binary。

5、日期和时间类型：包含timestamp和date。

6、复杂类型：包含struct、list、map和union类型。

目前ORC基本已经兼容了日常所能用到的绝大部分的字段类型。另外，ORC中所有的类型都可以接受NULL值。

Hive在创建ORC类型的表时，表中的列是按照struct形式组织，struct是按照树的方式来组织并描述字段的。例如：

create table test(
a int
b map<string,struct<myString : string,myDouble: double>>,
c string
)

2.2.3、ORC的压缩格式

ORC存储格式支持的压缩格式有限：None（不压缩），Zlib和Snappy三种压缩格式。默认为Zlib压缩，不支持切分。

1、Zlib

无损压缩算法，提供了较高的压缩比。它通常用于需要较高压缩率的场景，但压缩和解压缩速度相对较慢。适用于对压缩率有较高要求且可以容忍一定延迟的场景。

2、Snappy

以较快的压缩和解压缩速度著称，但压缩比通常低于ZLIB。适用于需要频繁读写操作的数据处理任务，特别是在读取性能至关重要的分析型工作负载中。

2.2.3、ORC存储格式建表

CREATE TABLE IF NOT EXISTS orc_table (id INT,name STRING,value DOUBLE
)
STORED AS ORC;

2.3、Apache Parquet

Parquet是另外的一种高性能行列式的存储结构，可以适用多种计算框架，被多种查询引擎所支持，包括Hive、Impala、Drill等。

2.3.1、Parquet基本结构

在一个Parquet类型的Hive表文件中，数据被分成多个行组，每个列块又被拆分成若干的页（Page），如图下图所示。

程序可以借助Parquet的这些元数据，在读取数据时过滤掉不需要读取的大部分文件数据，加快程序的运行速度。同ORC的元数据一样，Parquet 的这些元数据信息能够帮助提升程序的运行速度，但是ORC在读取数据时又做了一定的优化，增强了数据的读取效率。下面用两个例子来看看程序在读取Parquet和ORC文件时的差别。

2.3.2、Parquet的压缩格式

Parquet存储格式支持的压缩格式：Uncompress（不压缩）、Zlib、LZO、Snappy、Gzip。默认为不压缩。

1、Snappy

以较快的压缩和解压缩速度著称，但压缩比通常低于ZLIB。适用于需要频繁读写操作的数据处理任务，特别是在读取性能至关重要的分析型工作负载中。

2、Zlib

无损压缩算法，提供了较高的压缩比。它通常用于需要较高压缩率的场景，但压缩和解压缩速度相对较慢。适用于对压缩率有较高要求且可以容忍一定延迟的场景。

3、LZO

通常用于需要快速读取和写入数据的场景。LZO提供了适中的压缩比和速度，但可能需要额外的解压缩库支持。适用于需要处理大文件且希望避免数据倾斜的场景，因为LZO压缩的文件可以更容易地进行分割和并行处理。

4、Gzip

一种广泛使用的无损压缩算法，提供了较高的压缩比。然而，其压缩和解压缩速度相对较慢，可能会在处理大量数据时引入延迟。适用于存储空间有限且对压缩率有较高要求的场景，但需要注意其可能对查询性能产生的影响。

2.3.3、Parquet存储格式建表

CREATE TABLE my_parquet_table (id INT,name STRING,value DOUBLE
)
STORED AS PARQUET;

三、ORC与Parquet的使用

在Hive的性能比较中，同样的数据进行sql查询，使用ORC读取的行远小于Parquet，ORC的效率比较高。

实际生产中，使用Parquet存储格式，LZO压缩的方式更为常见，这种情况可以避免由于读取不可切分大文件导致的数据倾斜。如果数据并不是特别大的情况系啊，使用ORC存储格式，Snappy压缩效率还是非常好的。

PS：有问题，欢迎大家指正讨论