hive学习之一：认识hive

有些时候总感觉对某个概念，某项技术理解的不够深，理解的不到位，其实是自己站的高度不够高。抛开具体的技术细节不谈，

多想想设计的初衷，多想想为什么，收获颇丰。以下是我对hive的一些思考，在此做个记录，不对的地方，还请指正。

一.认识hive

hive一个数据仓库工具，不同于数据库。数据仓库注重于数据分析（OLAP）和历史数据存储，面向主题，而数据库则是面向事务(OLTP)，存储

在线交易数据,数据库设计尽量避免冗余，而数据仓库的设计有意引入冗余。

1.面向主题和面向事务

面向主题简单理解是面向某一类信息，面向事务偏重的数据的完整性。如：

商品id，商品名称，商品价格，交易时间，交易数量，交易金额。

在这样的一条交易数据中，面向事务侧重整条交易数据的完整性，而在面向主题的概览中，将信息按主题分类：

商品类：

商品id

商品名称

商品价格

交易类：

交易时间

交易数量

交易金额

2.关于冗余数据

如下的数据库设计是为了避免冗余：

有一个学生班主任表字段如下（班主任和学生的关系是1:N）

学生ＩＤ　　学生姓名　　班主任ＩＤ　班主任姓名　班主任家庭住址

那么这里，我们每插入一条学生记录，都必须要插入一次班主任的姓名和家庭住址信息，这就是典型的数据冗余。

这样的冗余带来的麻烦就是：

１。班主任姓名和住址要多次插入同样数据，存在插入错误的危险。

２。班主任搬家了。。。那么要更新班主任家庭住址Ｎ次～

为避免冗余：

表拆分为

学生班主任表

学生ＩＤ　学生姓名　班主任ＩＤ

班主任表

班主任ＩＤ　班主任姓名　班主任住址

但是在数据仓库中，设计冗余的目的是以空间换时间，减少关联的开销和提高数据读取的速度。

二.关于hive数据类型的思考

hive数据类型分两大类：一是基本数据类型，二是负载类型。

基本有如tinyint，smallint，int.....（不列举全部）,在大部分情况下，设计数据表的时候，都能够正常完成。但是却少有考虑数据类型

对查询性能的影响。比如在定义“员工信息”表时，将员工年龄定义为int类型，并没有任何语法语义错误。但是从查询性能上

来考量有瑕疵，这是因为采用int类型存储数据占用的数据表空间比用smallint或tinyint存储占用空间更大，查询时要消耗更

多的磁盘IO，在数据集很大的时候，会对查询性能有一定的影响。另外如果hive对某列建立索引，该列的值越短越好，这样可以

提高查询性能，对索引处理会更快。

三.hive三观

树立这些观念有助于更好的利用hive的特点和优势。

1.数据仓库观

hive是数据仓库工具，数据仓库与数据库密不可分，不关注细节。我们可以偏见地像对待数据库一样简单粗暴地对待hive。

在hive里我们可以像操作数据库一样来操作它。

1-1.常见的数据模型操作（SQL）：数据库，表，视图，索引，分区，桶

1-2.访问方式：Client（JAVA APT通过thrift server访问），cli（命令行），web ui（直观方便）。

1-3.内置的操作符和函数。

1-4.hive数据文件的存放及元数据信息的管理

2.MapReduce观

2-1.绝大多数hiveQL都是别转换成MR执行的，因此要树立的一种观念是HQL就是MR，在进行Hive调优的时候，很多时候其实都是

对MR调优。比如要考虑数据倾斜问题会对MR造成的影响。基于MR的特性，我们可以预见的是hive适合处理大数据量的离线分析，

而且是冷数据（只读不写）。具有高延迟的特点，不适合低延迟快速响应的场合。

2-2.hive的元数据是和很多hadoop组件共享的，比如和impala，Hbase共享元数据。对hive数据的操作同样会影响其他组件的数据。

3.高扩展性观

有些时候，hive自带的函数不能满足实际开发需求，我们可以通过自定义UDF来扩展hive的功能，还可以通过改动一些底层

源码来实现想要的功能。而这些改动都是基于Java，所以改动的成本低，易于编程。类似于ETL工具Sqoop。比如自定义输入输出格式化处理，自定义分隔符处理程序，自定义业务逻辑处理过程等等，这极大的丰富和扩展了hive的功能。