元数据管理与存储—Metastore
- 在Hive中,需要定义表结构信息与结构化的数据映射关系,映射指的是对应关系。在Hive中需要描述清楚表跟文件之间的映射关系、列和字段之间的关系等信息。这些描述映射关系的数据的称之为Hive的元数据
- 只有通过查询Hive元数据才可以确定用户编写sql和最终操作文件之间的关系。
- Metadata即元数据。元数据包含用Hive创建的database、table、表的字段等元信息。元数据存储在关系型数据库中。如hive内置的Derby、第三方如MySQL等。
- Metastore即元数据服务,是Hive用来管理库表元数据的一个服务。有了它上层的服务不用再跟裸的文件数据打交道,而是可以基于结构化的库表信息构建计算框架
- 通过metastore服务将Hive的元数据暴露出去,而不是需要通过对Hive元数据库mysql的访问才能拿到Hive的元数据信息;
- metastore服务实际上就是一种thrift服务,通过它用户可以获取到Hive元数据,并且通过thrift获取元数据的方式,屏蔽了数据库访问需要驱动,url,用户名,密码等细节。
Metastore的配置方式
内嵌模式
- 内嵌模式使用的是内嵌的Derby数据库来存储元数据,也不需要额外起Metastore服务。数据库和Metastore服务都嵌入在主Hive Server进程中。这个是默认的,配置简单,但是一次只能一个客户端连接
- 内嵌模式的优点:配置简单,解压hive安装包,启动就可以使用。
- 内嵌模式的缺点:不同路径启动hive,每一个hive拥有一套自己的元数据,无法共享。
本地模式
- 本地模式采用外部数据库来存储元数据,目前支持的数据库有:MySQL、Postgres、Oracle、MS SQL Server。
- 本地模式不需要单独起metastore服务,用的是跟Hive在同一个进程里的metastore服务。也就是说当启动一个hive 服务时,其内部会启动一个metastore服务。
- Hive根据 hive.metastore.uris 参数值来判断,如果为空,则为本地模式。
- 本地模式的优点:配置简单,本地模式下hive的配置中指定mysql的信息
- 本地模式的缺点:每启动一次hive服务,都内置启动了一个metastore;在hive-site.xml中暴露的数据库的连接信息;
远程模式
- 远程模式下,需要单独起metastore服务,然后每个客户端都在配置文件里配置连接到该metastore服务。远程模式的metastore服务和hive运行在不同的进程里。
- 在远程模式下,其他依赖Hive的软件都可以通过Metastore访问Hive。此时需要配置hive.metastore.uris 参数来指定 metastore 服务运行的机器ip和端口,并且需要单独手动启动metastore服务
- metastore服务可以配置多个节点上,避免单节点故障导致整个集群的hive client不可用。同时hive client配置多个metastore地址,会自动选择可用节点
服务端接口—HiveServer2
- HiveServer2是一个服务端接口,使远程客户端可以执行对Hive的查询并返回结果。
- 目前基于Thrift RPC的实现是HiveServer的改进版本,并支持多客户端并发和身份验证,启动hiveServer2服务后,就可以使用jdbc、odbc、thrift 的方式连接
- Thrift是一种接口描述语言和二进制通讯协议,它被用来定义和创建跨语言的服务。
- Thrift被当作一个远程过程调用(RPC)框架来使用,是由Facebook为“大规模跨语言服务开发”而开发的。
- HiveServer2作用:
- 为Hive提供了一种允许客户端远程访问的服务
- 基于thrift协议,支持跨平台,跨编程语言对Hive访问
- 允许远程访问Hive
元数据服务—HCatalog
- HCatalog 提供了一个统一的元数据服务,允许不同的工具如 Pig、MapReduce 等通过 HCatalog 直接访问存储在 HDFS 上的底层文件。
- HCatalog是用来访问Metastore的Hive子项目,HCatalog 使用了 Hive 的元数据存储,这样就使得像 MapReduce 这样的第三方应用可以直接从 Hive 的数据仓库中读写数据。
- HCatalog 还支持用户在MapReduce 程序中只读取需要的表分区和字段,而不需要读取整个表,即提供一种逻辑上的视图来读取数据,而不仅仅是从物理文件的维度。
- HCatalog 提供了一个称为 hcat 的命令行工具。这个工具和 Hive 的命令行工具类似,两者最大的不同就是 hcat 只接受不会产生 MapReduce 任务的命令。
数据存储格式
- Hive支持的存储数的格式主要有:TEXTFILE(默认格式) 、SEQUENCEFILE、RCFILE、ORCFILE、PARQUET。
- textfile为默认格式,建表时没有指定文件格式,则使用TEXTFILE,导入数据时会直接把数据文件拷贝到hdfs上不进行处理;
- sequencefile,rcfile,orcfile格式的表不能直接从本地文件导入数据,数据要先导入到textfile格式的表中, 然后再从表中用insert导入sequencefile、rcfile、orcfile表中。
- 行存储与列存储:使用行式存储一张表的数据都是放在一起的,但列式存储下数据被分开保存了。
- 行式存储的优点:数据被保存在一起,insert和update更加容易
- 行式存储的缺点:选择(selection)时即使只涉及某几列,所有数据也都会被读取
- 列式存储的优点:查询时只有涉及到的列会被读取,效率高
- 列式存储的缺点:选中的列要重新组装,insert/update比较麻烦
- TEXTFILE、SEQUENCEFILE 的存储格式是基于行存储的;
- ORC和PARQUET 是基于列式存储的。
数据存储格式—TextFile
- Hive默认的数据存储格式,数据不做压缩,磁盘开销大,数据解析开销大。
数据存储格式—RCFile
- RCFile全称Record Columnar File,列式记录文件,是一种类似于SequenceFile的键值对数据文件。
- RCFile结合列存储和行存储的优缺点,是基于行列混合存储的RCFile。
- RCFile遵循的“先水平划分,再垂直划分”的设计理念。先将数据按行水平划分为行组,这样一行的数据就可以保证存储在同一个集群节点;然后在对行进行垂直划分。
- 一张表可以包含多个HDFS block,在每个block中,RCFile以行组为单位存储其中的数据
- row group又由三个部分组成
- 用于在block中分隔两个row group的16字节的标志区
- 存储row group元数据信息的header
- 实际数据区,表中的实际数据以列为单位进行存储
数据存储格式—ORCFile
- ORC File,它的全名是Optimized Row Columnar (ORC) file,其实就是对RCFile做了一些优化
- ORC File文件格式可以高效的存储Hive数据。ORC File设计目标是来克服Hive其他格式的缺陷。运用ORC File可以提高Hive的读、写以及处理数据的性能。
- ORC文件结构由三部分组成:
- 文件脚注(file footer):包含了文件中 stripe 的列表,每个stripe行数,以及每个列的数据类型。还包括每个列的最大、最小值、行计数、求和等信息
- postscript:压缩参数和压缩大小相关信息
- 条带(stripe):ORC文件存储数据的地方。在默认情况下,一个stripe的大小为250MB
- Index Data:一个轻量级的index,默认是每隔1W行做一个索引。包括该条带的一些统计信息,以及数据在stripe中的位置索引信息
- Rows Data:存放实际的数据。先取部分行,然后对这些行按列进行存储。对每个列进行了编码,分成多个stream来存储
- Stripe Footer:存放stripe的元数据信息
- ORC在每个文件中提供了3个级别的索引:文件级、条带级、行组级。借助ORC提供的索引信息能加快数据查找和读取效率,规避大部分不满足条件的查询条件的文件和数据块。使用ORC可以避免磁盘和网络IO的浪费,提升程序效率,提升整个集群的工作负载。
数据存储格式—Parquet
- Apache Parquet是Hadoop生态圈中一种新型列式存储格式,它可以兼容Hadoop生态圈中大多数计算框架(Mapreduce、Spark等),被多种查询引擎支持(Hive、Impala、Drill等),与语言和平台无关的。
- Parquet文件是以二进制方式存储的,不能直接读取的,文件中包括实际数据和元数据,Parquet格式文件是自解析的。
- Parquet文件的Row group是写入数据时的最大缓存单元,MR任务的最小并发单元,一般大小在50MB-1GB之间