【Hive基础】01.数据模型、存储格式、排序方式

Hive基础知识

Hive是一个构建在Hadoop上的数据仓库框架。最初，Hive是由Facebook开发，后来移交由Apache软件基金会开发，并作为一个Apache开源项目。
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能。其本质是将SQL转换为MapReduce的任务进行运算，底层由HDFS来提供数据的存储，即一个将SQL转换为MapReduce的任务的工具。

1、五种数据模型

Hive的五种数据模型：内部表、外部表、分区表、分桶表、视图表

• 内部表 (Table) ：内部表是 Hive 中最基础的数据存储模式，当在 Hive 里创建一个内部表时，数据会被存放在 Hive 自身的数据仓库目录下，默认路径一般为/usr/hive/warehouse。
• 外部表 (External Table)： 外部表和内部表相对，它并不把数据存放在 Hive 的数据仓库目录中。在创建外部表时，只需指定数据在 Hadoop 文件系统（如 HDFS）中的实际存储路径，Hive 仅保存这些数据的元信息（如表结构、字段类型等）。
• 分区表 (Partition Table) ：分区表是为了提高数据查询效率而设计的。它将数据按照设定的条件（通常是某一列的值）进行划分，每个分区对应 HDFS 上的一个独立目录。
• 分桶表 (Bucket Table) ：分桶表本质上是一种特殊的分区表，它类似于哈希分区。 在创建分桶表时，需要指定分桶的列和桶的数量，Hive 会根据分桶列的值进行哈希运算，将数据分配到不同的桶中，每个桶对应 HDFS 上的一个文件。
• 视图表 (View Table) ：视图表是一个虚表，它本身并不存储实际的数据，而是基于一个或多个基表（可以是内部表、外部表等）的查询结果定义的。

注意: 内部表删除表后数据也会删除，外部表数据删除后不会从hdfs中删除

各数据模型之间的区别

	生命周期管理	使用场景	优势
内部表	内部表的生命周期和表的定义紧密相连。当使用DROP TABLE语句删除一个内部表时，不仅表的元数据会被删除，存储在 Hive 仓库目录下的实际数据文件也会被永久删除。	适用于数据由 Hive 管理，不需要与外部系统频繁共享，且数据的所有权和控制权完全属于 Hive 的场景。比如在一个数据仓库系统中，专门用于存储中间计算结果的表就可以采用内部表。
外部表	外部表的数据生命周期独立于表的定义。当使用DROP TABLE语句删除外部表时，仅仅会删除表的元数据，而实际存储在指定路径下的数据文件不会受到任何影响。	常用于需要和其他系统共享数据的场景。比如，数据由其他系统（如日志收集系统）生成并存储在 HDFS 上，Hive 需要对这些数据进行分析，此时使用外部表就可以在不移动数据的情况下对其进行查询和处理。
分区表		适用于数据量较大且数据具有明显的可划分维度（如时间、地域等）的场景。像电商的订单数据按日期分区、用户数据按地区分区等，都可以采用分区表来提高查询性能。	在查询时，如果只需要特定分区的数据，Hive 可以直接定位到相应的分区目录进行数据扫描，而无需扫描全量数据，从而显著提高查询效率。
分桶表		适用于数据量巨大且需要进行高效采样、关联查询等操作的场景。比如在大规模的用户行为数据分析中，对用户 ID 进行分桶可以提高数据处理效率。	数据均衡：可以保证数据在各个桶之间分布相对均匀，避免数据倾斜问题，提高数据处理的并行度。 高效采样：在进行数据采样时，分桶表可以更高效地实现均匀采样，方便进行数据的统计和分析。 关联查询优化：在进行关联查询时，如果关联列是分桶列，Hive 可以直接定位到对应的桶文件进行数据处理，减少数据的传输和比较量，提高查询性能。
视图表		适用于需要对数据进行不同角度的分析和展示，或者需要对复杂查询进行封装和复用的场景。例如为不同的业务部门提供特定的数据视图，方便他们进行数据分析。	简化查询：可以将复杂的查询逻辑封装在视图中，用户在查询时只需针对视图进行简单的操作，而无需关注底层复杂的查询细节。例如上述视图将年龄筛选的逻辑封装起来，用户后续查询年轻学生信息时，直接查询视图即可。 数据安全：可以通过视图限制用户对数据的访问权限，只允许用户查询视图中定义的字段和数据，而不能访问基表的所有数据，提高了数据的安全性。

1.1 分区表与分桶表的区别

2、五种常用存储格式

参考内容：Hive数据存储格式有哪些？TextFile、SequenceFile、RCFile、ORCFile、Parquet有什么区别？为什么绝大多数都使用ORCFile、Parquet格式？

Hive的五种常用存储格式： TextFile、SequenceFile、RCFile 、ORCFile和 Parquet

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

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

2.1 Hive 存储结构的比较

存储结构	定义	优点	缺点	适用场景
水平的行存储结构	把一整行数据存储在一起，包含该行的所有列，是最常见的存储模式	1. 适应动态查询：对于不同列数的查询，开销差异不大，如查询单列为select a from tableA和查询多列为select a, b, c, d, e, f, g from tableA，都只需读取整行数据再提取所需列。 2. 重建行成本低：同一行的数据通常存储在同一个HDFS块上，将一行数据的各列组合起来的成本较低，便于快速获取整行信息。	1. 查询效率低：当一行包含众多列，但仅需其中少数几列时，仍需读取整行数据，增加了不必要的数据读取量，降低了查询执行效率。 2. 压缩比不高：基于多个列进行压缩时，由于不同列的数据类型和取值范围差异较大，难以达到较高的压缩比，导致存储空间的利用效率不高。	适用于需要频繁查询整行数据的场景，如事务处理系统，这类系统经常需要获取一条记录的完整信息进行业务逻辑处理；或者数据列数较少，且每次查询涉及的列数较多的情况。
垂直的列存储结构	将每列单独存储，或者将某几个相关列作为列组进行存储	1. 避免不必要列读取：在执行查询时，可仅读取需要的列，减少了数据的读取量，提高了查询效率，尤其适用于需要对特定列进行分析的场景。 2. 高压缩比：同一列的数据类型通常一致，取值范围相对多列混合时更小，因此在压缩数据时能够达到较高的压缩比，有效节省存储空间。	1. 重建行开销大：重建行时比较困难，尤其是当一行的多个列分布在不同的HDFS块上时，需要从多个数据节点获取不同列的数据，然后进行组合，会产生较大的网络开销和运算开销。 2. 不适合整行查询：如果需要频繁查询整行数据，列存储的方式会因为需要从多个列中重建行而导致效率低下。	适用于数据分析场景，如数据仓库，这类场景通常需要对大量数据的特定列进行聚合、统计等操作；或者数据列数较多，且每次查询只涉及少数列的情况。
混合的PAX存储结构	将行存储和列存储混合使用，先按行存储，再按列存储，继承了传统数据库中提高CPU缓存利用率的思想	1. 结合两者优势：结合了行存储和列存储的优点，既可以在一定程度上避免读取不必要的列，提高查询效率，又能在重建行时相对较为高效，减少了单纯列存储在重建行时的开销。 2. 提高数据处理性能：在处理一些复杂查询时，能够更好地利用CPU缓存，提高数据处理的性能。	1. 实现复杂度高：由于结合了两种存储方式，其实现和管理相对复杂，需要更复杂的算法和机制来保证数据的存储和查询效率。 2. 不适合简单场景：对于一些简单的查询场景，可能会因为其复杂的结构而导致额外的开销，不如行存储或列存储直接高效。	适用于处理复杂查询和分析任务，如大型企业的数据仓库系统，这类系统需要处理各种类型的查询，既要保证对特定列的高效查询，又要兼顾整行数据的处理；或者数据量较大且查询模式多样的场景。

2.2 Hive 常用的存储格式

存储格式	基本原理或定义	优点	缺点
TextFile	Hive默认格式，建表不指定时即为该格式，导入数据时直接将数据文件拷贝到hdfs上不进行处理	加载速度最高，可直接使用load方式加载数据	使用Gzip压缩后文件不支持split，反序列化开销比SequenceFile高几十倍
SequenceFile	Hadoop API提供的一种二进制文件支持，内部格式取决于是否启用压缩，有记录压缩和块压缩等模式	1. 支持基于记录或块的数据压缩； 2. 支持splitable，可作为MapReduce的输入分片； 3.修改时主要负责修改业务逻辑，无需考虑具体存储格式	需要合并文件，合并后的文件不方便查看
RCFile	Facebook开源的Hive文件存储格式，先将表分为几个行组，对每个行组内的数据按列存储，每一列的数据分开存储	存储空间上，行划分、列存储，采用游程编码，相同的数据不会重复存储，节约存储空间，适用字段含大量重复数据的情况； 懒加载，针对特定查询可跳过不需要的列，省去无用列的解压缩	-
ORCFile	在RCFile基础上扩展优化，引入字典编码和Bit编码等，文件可切分，支持复杂数据类型和ACID事务	扩展了RCFile的压缩方式；每个task只输出单个文件，减少NameNode负载；支持复杂数据类型；文件可切分，节省HDFS存储资源，减少查询任务输入数据量和MapTask数量；借助索引可加快数据查找和读取效率；支持ACID事务	-
Parquet	一种高性能行列式存储结构，数据被分成多个行组，每个列块又被拆分成若干页，存储数据时记录多层元数据	适用多种计算框架，被多种查询引擎支持；借助元数据可过滤掉不需要读取的大部分文件数据，加快程序运行速度；在嵌套式结构支持上比较完美	查询时消耗的集群资源比ORC多；多层级嵌套表达时性能损失较大

3、四种主要排序方式

Hive 中的四种排序详解，再也不会混淆用法了 - 大数据技术派 - 博客园
hive四种排序Order By , Sort By ,Distribute By ,Cluster By_51CTO博客_hive四种排序

Hive的四种主要排序方式：ORDER BY全局排序、SORT BY局部排序、DISTRIBUTE BY分区排序（本身没有顺序）、CLUSTER BY分区并排序

• ORDER BY全局排序：只有一个Reducer(多个Reducer无法保证全局有序),会导致当输入规模较大时，消耗较长的计算时间，需要注意的是它受hive.mapred.mode的影响，在严格模式下，必须使用limit 对排序的数据量进行限制，因为数据量很大只有一个reducer的话，会出现OOM 或者运行时间超长的情况，所以严格模式下，不使用limit 则会报错
• SORT BY局部排序：多个Reducer。在数据进入reduce之前为每个reducer都产生一个排序后的文件。因此，如果用sort by进行排序，并且设置mapreduce.job.reduces>1，则sort by只保证每个reducer的输出有序，不保证全局有序。它不受Hive.mapred.mode属性的影响，sort by的数据只能保证在同一个reduce中的数据可以按指定字段排序。使用sort by你可以指定执行的reduce个数(通过set mapred.reduce.tasks=n来指定)，对输出的数据再执行归并排序，即可得到全部结果。
• DISTRIBUTE BY分区排序：distribute by是控制在map端如何拆分数据给reduce端的，它会将具有相同字段的 map 输出分发到一个 reduce 节点上做处理，类似于MapReduce中分区partationer对数据进行分区。
  • hive根据distribute by后面列，将数据分发给对应的reducer，默认采用hash算法+取余数的方式。
  • sort by为每个reduce产生一个排序文件，在有些情况下，你需要控制某写特定的行应该到哪个reducer，这通常是为了进行后续的聚集操作。distribute by刚好可以做这件事。因此，distribute by经常和sort by配合使用。
  • 注意，Hive要求DISTRIBUTE BY语句要写在SORT BY语句之前。
• CLUSTER BY分区并排序：当distribute by和sort by的字段一致时，可以使用cluster by方式。但是排序只能是升序排序ASC，不能指定排序规则为ASC或者DESC。以下两种方式等价。
  • select * from emp cluster by deptno;
  • select * from emp distribute by deptno sort by deptno;

学习笔记参考：

Hive学习笔记（by尚硅谷）_尚硅谷 hive-CSDN博客
Hive基础知识大全-CSDN博客
专栏：Hive_一个写湿的程序猿的博客-CSDN博客