Hive历史

最新推荐文章于 2023-06-01 13:05:41 发布

weixin_33788244

最新推荐文章于 2023-06-01 13:05:41 发布

阅读量1k

点赞数

文章标签：大数据数据库运维

原文链接：https://my.oschina.net/gordonnemo/blog/1830128

版权

2019独角兽企业重金招聘Python工程师标准>>>

Hive产生背景： “云化”过程

1) MapReduce编程十分非常特别的不方便

2) 传统RDBMS人员的需求： SQL来处理大数据

<== Hive诞生了！！！！！！！！！

Hive存储结构：

假设数据存放在HDFS： /ruozedata/hadoop/a.txt

1 zhangsan 30

2 ruoze 31

3 jepson 18

rdbms：meta/schema

person

id:int

name:string

age:int

select id,name from person;

总结：

HDFS上面的文件就是普通的文件，它并没有schema的概念

schema：RDBMS中的表结构

people.txt <== id name age address

sql ===> 搞定海量数据的统计分析

Hive: SQL on Hadoop

官网: hive.apache.org

Hive 是一个使用SQL来操作分布式存储系统上面的大数据集的读写和管理操作的一个客户端，Hive它不是一个集群。
用JDBC去连接Server的话，不应该是走查询统计分析，而是去拿到统计结果，只拿结果，不做计算。

data warehouse: 离线、实时

Structure：半非

分布式系统：HDFS/S3

问题：HDFS存的是近期的数据

1min：几百G

冷数据：定期的移走S3 table的location指向S3

FaceBook开源目的是解决海量结构化日志数据的统计文件

Hive构建在Hadoop之上的数据仓库

Hive的数据就是存在 HDFS之上

计算时使用MR

弹性：线性扩展

Hive底层的执行三个引擎：

MapReduce（在Hive1.x的时代MapReduce是默认引擎，在Hive2.x标记MapReduce为过期版本）

Tez

Spark （生产环境正在使用的引擎）

Hive定义一种类似SQL的查询语言：HQL 类SQL

问题：HQL和SQL的关系？

什么关系都没有，只是语法类似，Hive抄的MySQL的语法

很多的SQL on Hadoop的语法都是和RDBMS非常类似的

Hive常用于：离线批处理

SQL ===> MR：我们输入一个SQL通过我们的HIVE工具把SQL语句翻译成MapReduce/Spark/Tez 作业，并提交到YARN上运行

问题：是否智能、执行计划（sql是如何翻译成mr作业）

高级：UDF

Hive的重点

存储格式：

1.textfile

textfile为默认格式

存储方式：行存储

磁盘开销大数据解析开销大

压缩的text文件 hive无法进行合并和拆分

2.sequencefile

二进制文件,以<key,value>的形式序列化到文件中

存储方式：行存储

可分割压缩

一般选择block压缩

优势是文件和Hadoop api中的mapfile是相互兼容的。

3.rcfile

存储方式：数据按行分块每块按照列存储

压缩快快速列存取

读记录尽量涉及到的block最少

读取需要的列只需要读取每个row group 的头部定义。

读取全量数据的操作性能可能比sequencefile没有明显的优势

4.orc

存储方式：数据按行分块每块按照列存储

压缩快快速列存取

效率比rcfile高,是rcfile的改良版本

5.自定义格式

用户可以通过实现inputformat和 outputformat来自定义输入输出格式。

总结：

相比传统的行式存储引擎，列式存储引擎具有更高的压缩比，更少的IO操作而备受青睐（注：列式存储不是万能高效的，

很多场景下行式存储仍更加高效），尤其是在数据列（column）数很多，但每次操作仅针对若干列的情景，

列式存储引擎的性价比更高。在互联网大数据应用场景下，大部分情况下，数据量很大且数据字段数目很多，

但每次查询数据只针对其中的少数几行，这时候列式存储是极佳的选择

压缩格式：

可使用Gzip,Bzip2等压缩算法压缩,压缩后的文件不支持split

Hive发展历程

Stinger plan：（阶段版本）
       08/2007: facebook        05/2013: 0.11.0 Stinger Phase1 ORC HiveServer2
        10/2013: 0.12.0 Stinger Phase2 ORC improvement
        04/2014: 0.13.0 Stinger Phase3 Vectorized query engine Tez（0.13版本后才能用）
        11/2014: 0.14.0 Stinger.next Phase 1 Cost-based optimizer(CBO基于成本的优化，代价的优化)
        01/2015: 1.0.0 （里程碑点）

Stinger：不是一个项目或产品，而是一种提议，旨在将Hive性能提升100倍（仅仅是个参考），包括Hive的改进和Tez项目两个部分。

为什么要使用Hive?
    1)、简单易用
    2)、扩展性好：hdfs空间不够加磁盘加机器，存储不是问题。底层MapReduce或者Spark计算处理不过来就加CPU加内存就行。
    3)、统一的元数据管理如果存放在hdfs上就仅仅就是一个文件而已，如果要进行计算，肯定要告诉这个文件meta信息，哪个文件哪个列，列的数据类型是什么。Hive不是集群，Hadoop是集群，Hive仅仅是一个客户端，没有进程，不会挂掉，提交在YARN上执行，hive挂了没有影响。

元数据信息： database、table、column:name type、hdfs存储位置:location元数据存放在哪里呢？
元数据信息，全部配置在MySQL（自带Derby）里面元数据统一管理的好处： /ruozedata/hadoop/a.txt 将hdfs上的数据用 Hive可以处理，Spark也可以计算处理，不需要做任何的改进。
Hive/Pig【现在不用】/Impala/Spark SQL/Presto：共享元数据的信息是非常好。如：Hive里面创建了一张表，可以直接用Spark SQL进行访问

问题：Hive的数据存放在哪里？
HDFS + metadata

Vectorized query engine（向量化查询引擎）：
传统方式中，对数据的处理是以行为单位，依次处理的。Hive也采用了这种方案。这种方案带来的问题是，针对每一行数据，都要进行数据解析，条件判断，方法调用等操作，从而导致了低效的CPU利用。
向量化特性，通过每次处理1024行数据，列方式处理，从而减少了方法调用，降低了CPU消耗，提高了CPU利用率。结合JDK1.8对SIMD的支持，获得了极高的性能提升。通过以下参数启用向量化查询引擎：
相关参考：
https://cwiki.apache.org/confluence/display/Hive/Vectorized+Query+Execution