hive学习之一:认识hive

  有些时候总感觉对某个概念,某项技术理解的不够深,理解的不到位,其实是自己站的高度不够高。抛开具体的技术细节不谈,
多想想设计的初衷,多想想为什么,收获颇丰。以下是我对hive的一些思考,在此做个记录,不对的地方,还请指正。
一.认识hive
hive一个数据仓库工具,不同于数据库。数据仓库注重于数据分析(OLAP)和历史数据存储,面向主题,而数据库则是面向事务(OLTP),存储
在线交易数据,数据库设计尽量避免冗余,而数据仓库的设计有意引入冗余。
1.面向主题和面向事务
  面向主题简单理解是面向某一类信息,面向事务偏重的数据的完整性。如:
  商品id,商品名称,商品价格,交易时间,交易数量,交易金额。
  在这样的一条交易数据中,面向事务侧重整条交易数据的完整性,而在面向主题的概览中,将信息按主题分类:
  商品类:
     商品id
     商品名称
     商品价格
  交易类:
     交易时间
     交易数量
     交易金额
2.关于冗余数据
  如下的数据库设计是为了避免冗余:
  有一个学生班主任表字段如下(班主任和学生的关系是1:N)
  学生ID  学生姓名  班主任ID 班主任姓名 班主任家庭住址
  那么这里,我们每插入一条学生记录,都必须要插入一次班主任的姓名和家庭住址信息,这就是典型的数据冗余。
  这样的冗余带来的麻烦就是:
  1。班主任姓名和住址要多次插入同样数据,存在插入错误的危险。
  2。班主任搬家了。。。那么要更新班主任家庭住址N次~
  为避免冗余:
  表拆分为
  学生班主任表
  学生ID 学生姓名 班主任ID
  班主任表
  班主任ID 班主任姓名 班主任住址
  但是在数据仓库中,设计冗余的目的是以空间换时间,减少关联的开销和提高数据读取的速度。
  
二.关于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的功能。
     
     

你可能感兴趣的:(hive学习之一:认识hive)