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的功能。