很久很久以前,我们的世界分为:人族、矮人族、精灵、兽族…本来世界很和平。
突然有一天,有一个人,有一个想法,这个想法很可怕,打破了这样的平静,他想统治整个世界,怎么做呢?
他想了一个主意,他会魔法,他用他的魔法,打造出魔戒,然后他把这个魔戒分别送个各个种族的首领,方便各个首领更好的统治;
然后他又偷偷的制造了一个至尊魔戒,这个至尊魔戒可以统治普通的魔戒,以此实现他的统一世界的梦想。。。。。。
如果把世界上每一个生物当作一条记录,那么魔戒就好比数据库,而我们的至尊魔戒就是数据仓库。
数据仓库(Data WareHouse) 实际上是为了公司能够统一各种业务数据,将各个不同数据源中的数据融合,这些数据通常可以做数据分析、数据挖掘、报表,帮助公司做决策。
Hive是建立在Hadoop上的数据仓库基础架构。它提供了一系列的工具,可以用来进行数据提取转化加载( ETL ),这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL ,它允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。
数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。
Hive是SQL解析引擎,它将SQL语句转译成M/R Job然后在Hadoop执行。
Hive的表其实就是HDFS的目录,按表名把文件夹分开。如果是分区表,则分区值是子文件夹,可以直接在M/R Job里使用这些数据。
Hive相当于hadoop的客户端工具,部署时不一定放在集群管理节点中,可以放在某个节点上。
Hive的详细安装过程请点击下方靓仔原创博客链接:
Hive数据仓库——环境搭建及简单使用
自己使用的过程中一定严格按照这个版本去使用(版本兼容)
Hive的详细安装过程请点击下方靓仔原创博客链接:
Hive数据仓库——环境搭建及简单使用
查询语言 | HiveQL | SQL |
---|---|---|
数据存储位置 | HDFS | Raw Device or 本地 FS |
数据格式 | 用户定义 | 系统决定 |
数据更新 | 不支持(1.x以后版本支持) | 支持 |
索引 | 新版本有,但弱 | 有 |
执行 | MapReduce | Executor |
执行延迟 | 高 | 低 |
可扩展性 | 高 | 低 |
数据规模 | 大 | 小 |
TEXTFILE 即正常的文本格式,是Hive默认文件存储格式,因为大多数情况下源数据文件都是以text文件格式保存(便于查看验数和防止乱码)。此种格式的表文件在HDFS上是明文,可用hadoop fs -cat命令查看,从HDFS上get下来后也可以直接读取。
TEXTFILE 存储文件默认每一行就是一条记录,可以指定任意的分隔符进行字段间的分割。但这个格式无压缩,需要的存储空间很大。虽然可结合Gzip、Bzip2、Snappy等使用,使用这种方式,Hive不会对数据进行切分,从而无法对数据进行并行操作。
一般只有与其他系统由数据交互的接口表采用TEXTFILE 格式,其他事实表和维度表都不建议使用。
Record Columnar的缩写。是Hadoop中第一个列文件格式。能够很好的压缩和快速的查询性能。通常写操作比较慢,比非列形式的文件格式需要更多的内存空间和计算量。 RCFile是一种行列存储相结合的存储方式。首先,其将数据按行分块,保证同一个record在一个块上,避免读一个记录需要读取多个block。其次,块数据列式存储,有利于数据压缩和快速的列存取。
Hive从0.11版本开始提供了ORC的文件格式,ORC文件不仅仅是一种列式文件存储格式,最重要的是有着很高的压缩比,并且对于MapReduce来说是可切分 (Split) 的。因此,在Hive中使用ORC作为表的文件存储格式,不仅可以很大程度的节省HDFS存储资源,而且对数据的查询和处理性能有着非常大的提升,因为ORC较其他文件格式压缩比高,查询任务的输入数据量减少,使用的Task也就减少了。ORC能很大程度的节省存储和计算资源,但它在读写时候需要消耗额外的CPU资源来压缩和解压缩,当然这部分的CPU消耗是非常少的。
通常我们使用关系数据库存储结构化数据,而关系数据库中使用数据模型都是扁平式的,遇到诸如List、Map和自定义Struct的时候就需要用户在应用层解析。但是在大数据环境下,通常数据的来源是服务端的埋点数据,很可能需要把程序中的某些对象内容作为输出的一部分,而每一个对象都可能是嵌套的,所以如果能够原生的支持这种数据,这样在查询的时候就不需要额外的解析便能获得想要的结果。
Parquet的灵感来自于2010年Google发表的Dremel论文,文中介绍了一种支持嵌套结构的存储格式,并且使用了列式存储的方式提升查询性能。Parquet仅仅是一种存储格式,它是语言、平台无关的,并且不需要和任何一种数据处理框架绑定。这也是parquet相较于orc的仅有优势:支持嵌套结构。Parquet 没有太多其他可圈可点的地方,比如他不支持update操作(数据写成后不可修改),不支持ACID等。
SequenceFile是Hadoop API 提供的一种二进制文件,它将数据以
SequenceFile支持三种压缩选择:NONE, RECORD, BLOCK。 Record压缩率低,一般建议使用BLOCK压缩。 SequenceFile最重要的优点就是Hadoop原生支持较好,有API,但除此之外平平无奇,实际生产中不会使用。
Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑,若要读取大量数据时,Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的,所以它不需要开发者在API 级别实现自己的Writable对象。Avro提供的机制使动态语言可以方便地处理Avro数据。最近多个Hadoop 子项目都支持Avro 数据格式,如Pig 、Hive、Flume、Sqoop 和 Hcatalog。
存储格式 | 占用空间 | 压缩率%(压缩后:压缩前) | sql编号 | 执行时间(s) |
---|---|---|---|---|
TextFile | 15.1 | 100.0 | 1 | 118 |
2 | 217 | |||
ORC | 1.3 | 8.61 | 1 | 33 |
2 | 3 | |||
Parquet | 4.3 | 28.48 | 1 | 40 |
2 | 71 | |||
RCFile | 12.3 | 81.64 | 1 | 88 |
2 | 71 |
编号 | sql |
---|---|
1 | select count(*) from table_test; |
2 | select name,sum(table_test.price) as nums from table_test group by name; |
3 | benchmark 其它很多增删改的操作 |
结论:ORCFile存储文件读操作效率最高
耗时比较:ORC
结论:ORCFile存储文件占用空间少,压缩效率高
占用空间:ORC
常用的2个:CLI,JDBC/ODBC
该表比较简单,但很重要。
VER_ID | SCHEMA_VERSION | VERSION_COMMENT |
---|---|---|
ID主键 | Hive版本 | 版本说明 |
1 | 1.2.1 | Set by MetaStore |
如果该表出现问题,根本进入不了Hive-Cli。比如该表不存在,当启动Hive-Cli时候,就会报错”Table ‘hive.version’ doesn’t exist”。
DBS:该表存储Hive中所有数据库的基本信息,字段如下:
表字段 | 说明 | 示例数据 |
---|---|---|
DB_ID | 数据库ID | 1 |
DESC | 数据库描述 | Default Hive database |
DB_LOCATION_URI | 数据HDFS路径 | hdfs://193.168.100.100:9000/test-warehouse |
NAME | 数据库名 | default |
OWNER_NAME | 数据库所有者用户名 | public |
OWNER_TYPE | 所有者角色 | ROLE |
DATABASE_PARAMS:该表存储数据库的相关参数,在CREATE DATABASE时候用WITH
DBPROPERTIES(property_name=property_value, …)指定的参数。
表字段 | 说明 | 示例数据 |
---|---|---|
DB_ID | 数据库ID | 1 |
PARAM_KEY | 参数名 | createdby |
PARAM_VALUE | 参数值 | root |
DBS和DATABASE_PARAMS这两张表通过DB_ID字段关联。
主要有TBLS、TABLE_PARAMS、TBL_PRIVS,这三张表通过TBL_ID关联。
TBLS:该表中存储Hive表,视图,索引表的基本信息。
表字段 | 说明 | 示例数据 |
---|---|---|
TBL_ID | 表ID | 21 |
CREATE_TIME | 创建时间 | 1645194826 |
DB_ID | 数据库ID | 1 |
LAST_ACCESS_TIME | 上次访问时间 | 1645194826 |
OWNER | 所有者 | root |
RETENTION | 保留字段 | 0 |
SD_ID | 序列化配置信息 | 41,对应SDS表中的SD_ID |
TBL_NAME | 表名 | ex_detail_ufdr_30streaming |
TBL_TYPE | 表类型 | EXTERNAL_TABLE |
VIEW_EXPANDED_TEXT | 视图的详细HQL语句 | |
VIEW_ORIGINAL_TEXT | 视图的原始HQL语句 |
TABLE_PARAMS:该表存储表/视图的属性信息
表字段 | 说明 | 示例数据 |
---|---|---|
TBL_ID | 表ID | 1 |
PARAM_KEY | 属性名 | totalSize,numRows,EXTERNAL |
PARAM_VALUE | 属性值 | 970107336、21231028、TRUE |
TBL_PRIVS:该表存储表/视图的授权信息
表字段 | 说明 | 示例数据 |
---|---|---|
TBL_GRANT_ID | 授权ID | 1 |
CREATE_TIME | 授权时间 | 1645194826 |
GRANT_OPTION | 授与权限 | 0 |
GRANTOR | 授权执行用户 | root |
GRANTOR_TYPE | 授权者类型 | USER |
PRINCIPAL_NAME | 被授权用户 | username |
PRINCIPAL_TYPE | 被授权用户类型 | USER |
TBL_PRIV | 权限 | Select、Alter |
TBL_ID | 表ID | 21,对应TBLS表的TBL_ID |
主要涉及SDS、SD_PARAMS、SERDES、SERDE_PARAMS,由于HDFS支持的文件格式很多,而建Hive表时候也可以指定各种文件格式,Hive在将HQL解析成MapReduce时候,需要知道去哪里,使用哪种格式去读写HDFS文件,而这些信息就保存在这几张表中。
SDS:该表保存文件存储的基本信息,如INPUT_FORMAT、OUTPUT_FORMAT、是否压缩等。TBLS表中的SD_ID与该表关联,可以获取Hive表的存储信息。
表字段 | 说明 | 示例数据 |
---|---|---|
SD_ID | 存储信息ID | 41 |
CD_ID | 字段信息ID | 21,对应CDS表 |
INPUT_FORMAT | 文件输入格式 | org.apache.hadoop.mapred.TextInputFormat |
IS_COMPRESSED | 是否压缩 | 0 |
IS_STOREDASSUBDIRECTORIES | 是否以子目录存储 | 0 |
LOCATION | HDFS路径 | username |
PRINCIPAL_TYPE | 被授权用户类型 | hdfs://193.168.100.100:9000/detail_ufdr_streaming_test |
NUM_BUCKETS | 分桶数量 | 0 |
OUTPUT_FORMAT | 文件输出格式 | org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat |
SERDE_ID | 序列化类ID | 41,对应SERDES表 |
SD_PARAMS: 该表存储Hive存储的属性信息,在创建表时候使用STORED BY ‘storage.handler.class.name’ [WITH SERDEPROPERTIES (…)指定。
表字段 | 说明 | 示例数据 |
---|---|---|
SD_ID | 存储配置ID | 41 |
PARAM_KEY | 存储属性名 | |
PARAM_VALUE | 存储属性值 |
SERDES:该表存储序列化使用的类信息
表字段 | 说明 | 示例数据 |
---|---|---|
SERDE_ID | 序列化类配置ID | 41 |
NAME | 序列化类别名 | NULL |
SLIB | 序列化类 | org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe |
SERDE_PARAMS:该表存储序列化的一些属性、格式信息,比如:行、列分隔符
表字段 | 说明 | 示例数据 |
---|---|---|
SERDE_ID | 序列化类配置ID | 41 |
PARAM_KEY | 属性名 | field.delim |
PARAM_VALUE | 属性值 | I |
要涉及COLUMNS_V2
COLUMNS_V2:该表存储表对应的字段信息
表字段 | 说明 | 示例数据 |
---|---|---|
CD_ID | 字段信息ID | 21 |
COMMENT | 字段注释 | NULL |
COLUMN_NAME | 字段名 | air_port_duration |
TYPE_NAME | 字段类型 | bigint |
INTEGER_IDX | 字段顺序 | 119 |
主要涉及PARTITIONS、PARTITION_KEYS、PARTITION_KEY_VALS、PARTITION_PARAMS
PARTITIONS:该表存储表分区的基本信息
表字段 | 说明 | 示例数据 |
---|---|---|
PART_ID | 分区ID | 21 |
CREATE_TIME | 分区创建时间 | 1645194826 |
LAST_ACCESS_TIME | 最后一次访问时间 | 0 |
PART_NAME | 分区名 | hour=15/last_msisdn=0 |
SD_ID | 分区存储ID | 43 |
TBL_ID | 表ID | 22 |
LINK_TARGET_ID | 链接模板ID | NULL |
PARTITION_KEYS:该表存储分区的字段信息
表字段 | 说明 | 示例数据 |
---|---|---|
TBL_ID | 表ID | 22 |
PKEY_COMMENT | 分区字段说明 | NULL |
PKEY_NAME | 分区字段名 | hour |
PKEY_TYPE | 分区字段类型 | int |
INTEGER_IDX | 分区字段顺序ID | 0 |
PARTITION_KEY_VALS:该表存储分区字段值
表字段 | 说明 | 示例数据 |
---|---|---|
PART_ID | 分区ID | 21 |
PART_KEY_VAL | 分区字段值 | 0 |
INTEGER_IDX | 分区字段值顺序 | 1 |
PARTITION_PARAMS:该表存储分区的属性信息
表字段 | 说明 | 示例数据 |
---|---|---|
PART_ID | 分区ID | 21 |
PARAM_KEY | 分区属性名 | 0 |
INTEGER_IDX | 分区字段值顺序 | numFiles,numRows |
PARAM_VALUE | 分区属性值 | 1,502195 |
到底啦!关注靓仔学习更多的大数据知识 (❁´◡`❁)