[Hive]-架构篇

1.Hive简述

  1.1 Hive是什么

    Hive是数据仓库.它是构建在Hadoop之上的,通过解析QL(Hive SQL),转换成MR任务(Tez,Spark......)去提交执行.

    RDBMS一般是写验证,而Hive是读验证,即数据进入不会验证数据是否符合要求,只在读取的时候检查,解析具体字段

  1.2 Hive的优缺点

    优点:

      可以直接访问HDFS,或者其它的标准分布式文件系统(s3,oss等),并将这些分布式文件数据组织成表的形式

      传统的MR任务编写,非常复杂,需要很高的学习成本.Hive的出现,可以将MR的任务编写转换成类SQL的形式,降低了学习和使用成本.

      Hadoop良好的容灾能力和可扩展能力,几乎不受限制的数据处理量.因为它实际存储使用的HDFS,实际计算使用的MR

      提供统一的元数据管理.

    缺点:

      执行的效率一般.因为它是转换为MR提交执行,受执行计划生产的影响,它最后执行的不一定是最优的解决方案.

      计算的及时性差.还是因为转换为MR提交执行,受MR执行效率影响(申请资源,走MR执行流程等等),Hive的计算,就算是小数据量,计算时间也是偏长的.

      相对于关系型数据库的SQL而言,Hive的类SQL表达能力一般

      不支持行级别的数据更新

    所以Hive不擅长使用在对计算及时性要求非常高的地方(实时计算),并且也不擅长使用在小数据量上,因为它哪怕就计算几条数据,也要耗费大量的资源(必然SQL解析,生成MR,提交到YARN,申请资源,MR执行等等流程)

    它比较擅长于用在能接受较长的延迟性,大数据量批处理作业.比如离线日志分析等,或者是不执行任何MR操作的查询使用,彻底转为分布式文件系统的一个查询媒介

2.Hive的架构

  2.1 元数据

    Hive是整体运行在Hadoop上,实际处理的是存在于分布式文件系统(HDFS)上的数据.对Hive而言,除了存储在HDFS上数据本身以为,还存有一份数据的元数据.

    元数据是标识数据的Scheme的东西,计算节点执行MR任务时依据元数据来标识如何具体的使用HDFS上的文件数据.

      (注意下元数据库是Hive最大的弱点,因为Hive本身的容灾能力非常强(Hadoop),但是元数据如果不能使用,Hive依然不能正常运行的,所以实际生产中,Hive的元数据库务必做好高可用)

  2.2 Hive的运行过程

    首先Hive收到一份SQL,会解析这份SQL成一个抽象语法树,生成多个逻辑执行计划并优化,再在其中比较最终选择一份生成物理执行计划(MR),然后提交到YARN上,然后走完MR On YARN的流程,获得执行结果再返回

3.Hive的存储

  3.1 元数据存储

    Hive的元数据是存储在关系型数据中的,默认是Derby(一般不用,本地化不适用与分布式场景),但一般使用的MySQL.

  3.2 数据的存储

    Hive的数据本身存储在HDFS中.由配置节 hive.metastore.warehouse.dir 控制,默认是存储在HDFS /usr/hive/warehouse 中.

    Hive本身的 数据库/表/分区/桶等概念,分别在HDFS上体现为文件夹

      所以 DataBase.Table的数据 实际体现为 /Database(文件夹)/Table(文件夹)/XXXX(文件,可以有多个)

    

原文地址:https://www.cnblogs.com/NightPxy/p/9127633.html