Hive的存储格式和压缩算法的特点和选择

1、数据存储格式：

①TEXTFILE

HIVE 中默认的存储格式；

一般使用在数据贴源层(ODS 或 STG) ，针对需要使用脚本 LOAD 加载数据到 HIVE 数仓表中的情况；需要把表里数据导出或直接可以查看等场景，作为BI供数

易读性要比 ORC 高很多；

数据存储时不压缩，因此磁盘的开销和数据解析开销比较大；

TEXTFILE 可以结合 Gzip、Bzip2 等压缩算法使用(系统自动检查，执行查询时自动解压)，但使用这种方式，HIVE 不会对数据进行切分，从而无法对数据进行并行操作；

在反序列化过程中，必须逐个字符判断是不是分隔符和行结束符，因此反序列化开销会比 SequenceFile 高几十倍；

可以直接通过 LOAD 的方式从文件中加载数据到 HIVE 表中；

当用户的数据文件格式不能被当前 HIVE 所识别的时候，可以自定义文件格式

通过实现 inputformat 和 outputformat 来自定义输入输出格式

②SEQUENCE FILE

HADOOP API 提供的一种二进制文件，以 key-value 的形式序列化到文件中；

支持切片；

数据加载导入方式可以通过INSERT方式加载数据；

③PARQUET

面向列的二进制文件格式，所以是不可以直接读取的；

文件中包括该文件的数据和元数据，因此 Parquet 格式文件是自解析的；

使用场景在 Impala 和 Hive 共享数据和元数据的场景；

④ORCFILE

运用 ORC 可以提高 HIVE 的读、写、计算的性能，主要使用在 DWD、DWB、DWS 层

数据按行分块，每块按照列存储；

压缩快、快速列存取；

效率比 rcfile 高，是 rcfile 的改良版本；

不考虑 ORC 的场景：需要通过 LOAD 方式加载数据到表里；需要把表里数据导出或直接可以查看等场景，这两种场景更适合使用 TEXTFILE ，易读性要比 ORC 高很多；

ORC 文件格式可以使用 HIVE 自带的命令 concatenate 快速合并小文件

在 Hive 中使用 ORC 文件格式时，是自动实现文件的分割（splitting）。这是因为 ORC 文件格式是为优化大规模数据处理而设计的，其中包括了有效的数据分割机制以支持并行处理。以下是一些关于 ORC 文件分割的关键点：

1. 块与条带（Stripes）

ORC 文件将数据分成多个条带（Stripes），每个条带都是自包含的数据集合，包括其自己的索引、数据和行索引。这些条带是分割数据的物理单位，可以独立于其他条带处理，支持并行读取和查询。

2. 文件的索引

每个 ORC 文件包含一个轻量级的文件尾部索引，其中包含有关文件中数据的统计信息和条带位置的详细信息。这使得查询引擎能够有效地确定哪些条带需要读取以满足特定的查询条件，从而实现快速的数据访问。

3. 分割与并行处理

当 Hive 执行查询时，它会根据数据的存储位置和条带信息自动对 ORC 文件进行分割。每个数据分割可以分配给不同的处理节点进行并行处理。这种分割机制允许 Hive 在多个处理节点上有效地分配工作，从而优化查询性能和减少数据处理时间。

4. 设置条带大小和行索引间隔

虽然分割机制自动运作，但你可以通过设置条带大小和行索引间隔来优化性能。例如，可以在创建表时通过以下方式设置条带大小和行索引间隔：

sql 复制代码

CREATE TABLE my_table (
  column1 INT,
  column2 STRING
)
STORED AS ORC
TBLPROPERTIES (
  "orc.stripe.size"="67108864",       -- 设置条带大小为64MB
  "orc.row.index.stride"="10000",     -- 设置行索引间隔
  "orc.compress"="SNAPPY"             -- 设置压缩算法为SNAPPY
);

存储格式	是否默认	存储方式	支持压缩算法
TextFile	是	行式存储	Gzip、Bzip2
SequenceFile	否	行式存储	NONE、RECORD、BLOCK
Parquet	否	列式存储	Uncompress(默认)、Snappy、Gzip、Lzo
RCFile	否	数据按行分块，每块按列存储	-
(RCFile的优化)ORCFile	否	数据按行分块，每块按列存储	NONE、ZLIB(默认)、SNAPPY
[HIVE 中常用的存储格式对比]

2、压缩算法

文件存储格式不同对应不同的压缩算法，从而带来不同的性能，我们根据实际使用考虑压缩算法的性能，

主要通过以下 3 个指标：

① 压缩比

压缩比越高，压缩后文件越小，所以压缩比越高越好；

压缩比越高，存储磁盘空间占用越小，可以降低单节点的磁盘IO，同时可以减少占用的带宽；

② 压缩时间

越快越好，加快数据在Hadoop集群流动的速度和磁盘 IO 的速度

③ 压缩后的文件是否可以再分割

可以分割的格式允许单一文件由多个Mapper程序处理，可以更好的并行化

|--------|-------|----------|----------|----------|
| 压缩方式 | 压缩比 | 压缩速度 | 解压缩速度 | 是否可分割 |
| gzip | 13.4% | 21 MB/s | 118 MB/s | 否，无法并行处理 |
| bzip2 | 13.2% | 2.4MB/s | 9.5MB/s | 是，并行处理 |
| LZO | 20.5% | 135 MB/s | 410 MB/s | 是，并行处理 |
| snappy | 22.2% | 172 MB/s | 409 MB/s | 否，无法并行处理 |
[压缩算法对比]

3、使用场景

ODS 贴源层： TextFile + Gzip

DWD ： ORC + SNAPPY

DWS ： ORC + SNAPPY

① 数据量较大

如果单个文件比较大，可以使用 Parquet 存储，LZO压缩，可以避免由于读取不可分割大文件引发的数据倾斜。

Parquet 的特性：

更高效的压缩和编码策略：Parquet 对于数据的编码和压缩有着高度优化，特别是对于重复数据的处理。

它使用多种压缩技术和编码策略，如字典编码、RLE（Run-Length Encoding）和Delta 编码，这些都有助于减少数据存储量并提升读取性能。

这种优化使得即使是大文件，数据的物理存储尺寸也可能相对更小，且读取效率更高。

更细粒度的索引：Parquet 文件提供了详尽的元数据和索引，例如 min/max 索引，这可以极大地加速查询性能，因为它允许在读取数据前快速跳过不符合查询条件的数据块。

这对于大文件尤为重要，因为它减少了需要处理的数据量，从而提高了处理速度。

更灵活的列裁剪和数据访问：由于 Parquet 是列式存储，它允许只加载查询所需的列，这称为列裁剪。

这种能力在处理含有大量列的大文件时非常有用，因为它可以显著减少I/O负载和提升查询响应时间。

更好的集成和优化支持：Parquet 在现代数据处理框架中，如 Apache Spark 和 Databricks 等，获得了广泛的支持和优化。

这些框架针对 Parquet 进行了大量优化，使其在这些环境中处理大型数据文件时表现更佳。

效率与性能的平衡：虽然 Parquet 的写操作可能比 ORC 慢，它在读取操作上通常更高效，特别是在需要高度优化查询的分析型工作负载中。

这种读取性能上的优势在处理大数据文件时尤为重要，因为它可以显著减少查询时间和计算资源的消耗。

因此，尽管 ORC 和 Parquet 都有各自的优势和使用场景，但在处理单个大文件方面，Parquet 在很多情况下因其更精细的数据访问控制、更有效的数据压缩和编码，以及更好的读取性能而更受青睐。这使得它在数据分析和大规模数据处理中，尤其是在需要频繁读取的场景中，成为更合适的选择。

② 计算逻辑比较少

使用 ORC 存储 + ZLIB 压缩，可以尽量减少占用存储空间

③ 计算逻辑比较多

使用 ORC 存储 + SNAPPY 压缩，可以提高读写速度，从而提高整体计算性能

在 Hive 中，对于计算逻辑比较多且要求计算速度达到最佳状态的场景，选择 ORC 存储格式是明智的，因为 ORC 格式具备高效的列存储和强大的压缩功能，能够显著提高查询性能。

然而，在压缩算法的选择上，虽然 SNAPPY 和 LZO 各有优劣，但选择的依据需要综合考虑多个因素。

3.1 ORC + SNAPPY 的优势

快速压缩和解压缩：

SNAPPY 以其快速的压缩和解压缩速度著称。对于频繁的读写操作，快速的解压缩可以减少查询延迟，从而提高整体计算性能。

低 CPU 开销：

SNAPPY 的压缩和解压缩操作对 CPU 资源的消耗较低。对于计算密集型任务，低 CPU 开销有助于将更多的 CPU 资源用于计算本身，而不是浪费在压缩和解压缩过程中。

适合查询优化：

ORC 文件格式支持谓词下推（predicate pushdown）、列裁剪（column pruning）和其他查询优化技术。SNAPPY 的低延迟特性使得这些优化技术能够更快地生效，从而提高查询性能。

在 ORC 文件格式中使用 SNAPPY 压缩时，压缩是在分割（条带创建）之后进行的。

下面是 ORC 文件结构处理数据的一般流程：

数据组织与条带创建：首先，数据被组织成多个条带（Stripes）。每个条带包含一部分数据，通常是几千到几万行，具体取决于配置的条带大小和数据的实际特性。
列式存储：在 ORC 文件中，数据按列而非按行存储。这意味着每个条带中的数据会按列组织，这有助于提高数据访问的效率并优化查询性能。
压缩：数据在条带级别被组织好之后，每个条带的数据会根据配置的压缩算法进行压缩。如果选择了 SNAPPY 压缩，每个条带的数据会被 SNAPPY 压缩算法压缩。压缩是独立于每个条带进行的，这允许在读取数据时可以并行解压缩不同的条带。
索引和元数据写入：ORC 文件还会包含每个条带的索引信息和整个文件的元数据，包括每个列的统计信息，如最大值、最小值等。这些信息也存储在文件的尾部，并可以用来优化读取操作，因为它们可以帮助快速确定是否需要读取某个条带来满足查询条件。

因此，SNAPPY 压缩在 ORC 文件的条带创建之后执行，这样做的好处是可以保持压缩数据的独立性，支持高效的并行处理。每个条带压缩后仍可独立解压，这有利于分布式处理和快速数据访问。

3.2 ORC + LZO 的情况

并行处理：

LZO 支持并行处理和分片（splitting），这在写入大规模数据时是一个优势，因为它能够充分利用多核 CPU 进行并行压缩，缩短写入时间。

压缩率：

LZO 的压缩率可能会比 SNAPPY 高一些，这意味着在相同的数据量下，LZO 压缩后的文件会更小，可以节省存储空间和 I/O 开销。

综合考虑：

尽管 LZO 支持并行处理和分片，适合大规模数据的写入，但在大多数计算密集型场景下，查询性能的提升往往比写入性能更为重要。

SNAPPY 在读取时的快速解压缩和低 CPU 开销，使得它在读取和计算过程中表现更优。这些优势在以下方面尤为明显：

查询性能：SNAPPY 的快速解压缩速度有助于加快数据加载和处理，特别是对于复杂查询和计算逻辑多的场景。

CPU 利用率：低 CPU 开销意味着更多的计算资源可以用于执行实际的查询和分析任务，而不是消耗在解压缩过程中。

实际表现：实际测试和基准测试往往显示，对于计算密集型任务，SNAPPY 的整体表现（包括读取和计算阶段）优于 LZO。

因此，在大多数需要高计算性能的 Hive 使用场景中，推荐使用 ORC + SNAPPY 作为存储和压缩组合，尽管 SNAPPY 不支持并行处理，但当与 ORC 文件格式配合使用时，实际情况可能有所不同。

有几个关键因素说明为什么在某些情况下使用 ORC 存储格式配合 SNAPPY 压缩依然能实现高效的计算速度：

ORC 文件的结构特性

ORC 文件是一种高效的列式存储格式，它自带索引和分区数据的功能。即使在使用 SNAPPY 压缩时，ORC 文件格式还是可以支持有效的数据拆分（split）和并行处理。ORC 文件将数据存储在多个块中，每个块可以独立压缩和解压缩。这意味着在处理时，每个数据块可以被独立加载和解码，允许并行处理。

SNAPPY 压缩的性能优势

SNAPPY 压缩提供了快速的压缩和解压速度，这是其设计的主要目标。虽然它不支持压缩数据的拆分，但其快速的解压速度对于计算密集型任务来说非常重要，因为它可以快速地将数据送入处理流程。对于需要频繁读取的应用，这种快速的解压速度可以显著提高数据处理的效率。

计算和 I/O 开销的平衡

在使用 ORC 和 SNAPPY 的组合时，可以实现对计算资源和 I/O 开销的良好平衡。由于 SNAPPY 提供了快速的解压缩，它可以减少从磁盘读取数据所需的时间，从而允许更多的资源被用于执行计算逻辑。这种快速的数据流转对于计算密集型任务尤其重要。

总体系统性能

在选择压缩算法时，还需要考虑到整个数据平台的架构和性能。虽然 LZO 提供了并行压缩的能力，但其解压速度通常不如 SNAPPY 快。此外，如果大部分时间都在进行数据读取和计算而不是写入，那么解压缩性能将更为关键。

结论：

因此，尽管 SNAPPY 不支持拆分压缩数据，但由于 ORC 的结构使得数据可以在块级别进行并行处理，再加上 SNAPPY 的高解压速度，使得这种组合在很多场景下仍然可以实现非常高效的查询和计算性能。当然，这种选择也应基于具体的使用场景和性能测试来确定，以确保满足特定的性能和成本效益需求。