hive基础知识

内容提要

  1. hadoop概述
  2. hive概述

 

 

  • hadoop概述
  1. hadoop体系架构
  1. 基于apache基金会下的一个开源项目,致力于开发一个可靠的、大规模的分布式计算框架。
  2. 用户可采用简单的计算模型在计算机集群下对大规模的数据进行分布式处理。
  3. 设计理念之一是扩展单一的服务器为成千上万机器的集群,且集群中每一个机器同时提供本地计算力和存储力。
  4. hadoop框架是在应用层检测和处理硬件失效问题,而不是依赖于硬件自身来维持高可用性。
  5. 在hadoop框架集群中硬件失效被认为是一种常态,集群的高可用性服务是建立在整个集群之上的。

hadoop整体框架,如图1-1所示

hive基础知识_第1张图片

图1-1 hadoop整体框架

  1. 分布式文件系统(Hadoop Distributed File System,HDFS)
  2. 并行计算模型(Map/Reduce)
  3. 列式数据库(Hbase)
  4. 数据仓库(Hive)
  5. 数据分析语言(Pig)
  6. 数据格式转化工具(Sqoop)
  7. 协同工作系统(Zookeeper)
  8. 数据序列化系统(Avro)
  1. hadoop整体框架下特点
  1. hadoop主要在多节点集群环境下。
  2. 以数据存储为基础。
  3. 最大限度兼容结构化数据格式。
  4. 以数据处理为目的。
  5. 且其数据操作技术多样化。
  1. hdfs简介
  1. 基于商用硬件环境。
  2. Hdfs具有高容错性,并且被部署在廉价的硬件之上。
  3. Hdfs向应用程序提供高的数据吞吐访问,适合于需要处理大规模海量 数据集的应用。
  4. Hdfs遵循部分posix协议要求,可以确保应用程序以流的方式访问文 件系统数据。
  1. hdfs对现实应用环境的假设及其目标
  1. 硬件失效
  2. 流式数据访问
  3. 海量数据集
  4. 追加写入及文件同步
  5. “移动计算比移动数据的代价小”
  6. 跨异构硬件和软件平台的可移植性
  1. hdfs架构,如图1-2所示

hive基础知识_第2张图片

图1-2 hdfs架构

 

  1. 主从(Master/Slave)体系结构。
  2. 只含有一个Namenode主服务节点这个节点管理文件系统中的命名空间和调度客户端对文件的访问。
  3. 通常一个机器就是一个Datanode数据节点,Datanode管理本节点上数据的存储。
  4. 在hdfs内部,一个文件被分割为一个或多个数据块,并且这些数据块被存储在一批Datanode中。
  5. Namenode执行文件系统中命名空间的操作(打开、关闭、重命名文件和目录),Namenode需要执行数据块到Datanode映射的决策。
  6. Datanode负责响应来自客户端的文件读写要求,也要负责执行来自Namenode的关于数据块创建、删除和冗余存储的指令。

6、Map/Reduce简介

(1)一种用于在大型商用硬件集群中(成千上万的节点)对海量数据(多个兆兆字节数据集)实施可靠的、高容错的并行计算的软件系统。

(2)一个最先由Google提出的分布式计算软件架构

(3)基本原理:将一个复杂的问题,分成若干个简单的子问题进行解决。然后,对子问题的结果进行合并,得到原有问题的解。

7、Map/Reduce概念

(1)“Map”和“Reduce”是编程语言中的概念,都是处理数据集合的函数。

(2)Map在处理数据序列的过程中只处理当前的数据信息,不需要跟之前处理的状态信息交互。

(3)主节点读入输入数据,把它分成可以用相同方法解决的小数据块,然后把这些小数据块分发到不同的工作节点上,每一个工作节点循环做同样的事,这就形成了一个树形结构,而每一个叶子节点来处理每一个具体的小数据块,再把这些处理结果返回给父节点。

(4)Reduce在处理过程中却依赖之前处理的结果,同时生成的结果也被后续的处理使用。节点得到所有子节点的处理结果,然后把所有结果组合并且返回到输出。

(5)一个Map/Reduce任务会把一个输入数据集分割为独立的数据块,然后Map任务会以完全并行的方式处理这些数据块。Map/Reduce系统自动对Map任务的输出分类,再把这些分类结果作为Reduce任务的输入。无论是任务的输入还是输出都会被存储在文件系统中。Map/Reduce系统关注任务调度、任务监测和重新执行失败的任务。

(6)计算节点和存储节点的一致性。允许hadoop框架有效的调度任务在那些数据已经准备好了的节点上,好处是整个集群中总带宽非常的高。

(7)特点是可以用Map和Reduce方法来处理分布式计算问题时,尽可能的实现数据处理的本地化,降低由数据移动而产生的代价。每一个Map操作都是相对独立的,所有的Maps都是并行运行的,虽然实践中会受到数据源和CPU个数的影响。同样的,用一个Reduce集合来执行Reduce操作,所有带有相同Key的Map输出会聚集到同一个Reduce。能够处理一般服务器所不能处理的大数据量处理问题。

(8)Map/Reduce系统由单一的JobTracker主节点和若干个TaskTracker从节点组成,其中每一个集群节点对应一个TaskTracker节点。主节点负责调度任务的各个组成任务到从节点上,监控并且重新执行失败的组成任务;从节点执行主节点安排的组成任务。

(9)Map/Reduce的Map和Reduce过程都定义了键值对()的数据结构,即系统视任务的输入数据为键值对集合,并且产生键值对结合做为任务的输出。

8、Map/Reduce处理过程,如图1-3所示

hive基础知识_第3张图片

图1-3 Map/Reduce处理过程

一次Map/Reduce任务过程。用户提交任务给JobTracker,JobTracker把对应的用户程序中的Map操作和Reduce操作映射至TaskTracker节点中;输入模块负责把输入数据分成小数据块,然后把它们传给Map节点;Map节点得到每一个key/value对,处理后产生一个或多个key/value对,然后写入文件;Reduce节点获取临时文件中的数据,对带有相同key的数据进行迭代计算,然后把终结果写入文件。

 

  1. Map/Reduce优缺点

(1)Map/Reduce通过工作状态的返回有效处理了单点失效的问题

(2)Map/Reduce是隶属于大粒度的并行计算模式,并行节点间在Map阶段     中和Reduce阶段中无法通信,也并非是一种万能的数据处理模型。

 

  1. hbase简介
  1. 可提供随机的、实时的大数据读写访问
  2. 目标是在商用硬件上存储非常大的表--数十亿的行数百万的列
  3. 开源的、分布式的、版本化的、面向列的存储模型
  4. 对Google公司BigTable系统的开源模仿,建立在hadoop和hdfs之     上提供类BigTable的存储力

 

  1. hbase数据模型
  1. 按预先定义好的列族结构来存储数据,即每一条数据有一个key以及若干个列属性值组成,每列的数据都有自己的版本信息
  2. 数据是按列进行有序存储的,不同于关系型数据库中按行存储
  3. 两种方式的数据操作,通过对有序key值进行扫描查询,获取value值,或者借助强大的hadoop来进行Map/Reduce查询
  4. 采用了强一致性的读写保证,数据会在多个不同的域中进行保存。列族可以包含无限多个数据版本,每个版本可以有自己的TTL
  5. 通过行级锁来保证写操作的原子性,但是不支持多行写操作的事务性。数据扫描操作不保证一致性

 

  1. hbase下表的逻辑视图,如表1-1所示

hive基础知识_第4张图片

表1-1 hbase下表的逻辑视图

  1. 行键
  2. 时间戳
  3. 列族

 

  1. hbase下表的物理视图,如表1-2所示

hive基础知识_第5张图片表1-2 hbase下表的物理视图

在hbase中采用的稀疏存储,物理存储过程中细化到一个单元。在逻辑视图中,任意一行不会空的每一列都被称作为一个单元。单元联同行键、时间戳、列族名、列名作为完整的一行存储到文件系统中,并且这个存储过程中会自动排序,先在各行键间以字母升序排列,再在同行键间以时间戳降序排列。

 

  1. hbase物理存储过程,如图1-4所示

hive基础知识_第6张图片

图1-4 hbase物理存储过程

  1. 表创建的初始阶段其中只含有一个region,随着表中数据的量不断增多,一个region会分裂为两个region,然后不断重复上述过程,并且region会被存储到hdfs中不同的datanode上。Region包含有一个或多个的store,其数量增长过程同表中的region数量增长过程一致。
  2. Store中分为两个部分:第一个部分是Memstore,一个store中只包含一个Memstore,并且Memstore存储在内存空间中,storefile的数量也会增加,当文件个数增加到一定量时,系统会自动对storefile文件进行合并。
  3. 合并过程中主要完成以下几个工作:1、具有相同行键的行存放在一个文件中;2、扔掉被标志为删除的行;3、扔掉时间戳过期的行,完成更新操作。随着合并操作的频繁执行storefile会变得很大,达到一定文件大小时自动分裂文件,贴合hdfs中对一个块数据大小的定义。
  4. Hbase的一张表中的多个列族,在物理存储上一个列族对应一个文件夹,一个文件夹中可包含若干个hfile文件。Hfile是storefile的底层文件格式,storefile就是对hfile做了轻量级包装

 

  1. hfile文件结构,如表1-3所示

hive基础知识_第7张图片

表1-3 hfile文件结构

  1. 记录数据块中以键值对形式存放的用户数据,一条记录保存一个键值对或者说保存一个单元的数据
  2. 元数据块其主要作用是判断一个键值是都在当前hfile文件中
  3. 文件信息中保存了与该hfile相关的一些信息,其中有系统保留的一些固定的值,也可以保存用户自定义的一些值
  4. 数据块索引保存的是每一个数据块在hfile文件中的位置、大小信息以及每个块的第一个单元的键值
  5. 元数据索引的格式与数据库索引相同,元数据块索引保存的是每一个元数据在hfile文件中的位置、大小信息以及每个元数据的键值
  6. 文件尾主要保存了该hfile的一些基本信息,其大小固定,主要是可以根据它查找到fileinfo,block index的起始位置

 

  • hive概述

1、hive简单介绍

Hive是一个基于 hadoop 的开源数据仓库工具,用于存储和处理海量结构化数据。它把海量数据存储于 hadoop 文件系统,而不是数据库,但提供了一套类数据库的数据存储和处理机制,并采用 HQL (类 SQL )语言对这些数据进行自动化管理和处理。我们可以把 Hive中海量结构化数据看成一个个的表,而实际上这些数据是分布式存储在 HDFS 中的。 Hive经过对语句进行解析和转换,最终生成一系列基于 hadoop 的 map/reduce 任务,通过执行这些任务完成数据处理。

Hive诞生于 facebook 的日志分析需求,面对海量的结构化数据,Hive以较低的成本完成了以往需要大规模数据库才能完成的任务,并且学习门槛相对较低,应用开发灵活而高效。

Hive是基于Hadoop的数据仓库解决方案。由于Hadoop本身在数据存储和计算方面有很好的可扩展性和高容错性,因此使用Hive构建的数据仓库也秉承了这些特性。

这是来自官方的解释。

简单来说,Hive就是在Hadoop上架了一层SQL接口,可以将SQL翻译成MapReduce去Hadoop上执行,这样就使得数据开发和分析人员很方便的使用SQL来完成海量数据的统计和分析,而不必使用编程语言开发MapReduce那么麻烦。

先上一张经典的Hive架构图,如图1-5所示。

hive基础知识_第8张图片

图1-5 Hive架构图

如图中所示,Hive通过给用户提供的一系列交互接口,接收到用户的指令(SQL),使用自己的Driver,结合元数据(MetaStore),将这些指令翻译成MapReduce,提交到Hadoop中执行,最后,将执行返回的结果输出到用户交互接口。
在使用过程中,至需要将Hive看做是一个数据库就行,本身Hive也具备了数据库的很多特性和功能。

  1. hive擅长什么

Hive可以使用HQL(Hive SQL)很方便的完成对海量数据的统计汇总,即席查询和分析,除了很多内置的函数,还支持开发人员使用其他编程语言和脚本语言来自定义函数。但是,由于Hadoop本身是一个批处理,高延迟的计算框架,Hive使用Hadoop作为执行引擎,自然也就有了批处理,高延迟的特点,在数据量很小的时候,Hive执行也需要消耗较长时间来完成,这时候,就显示不出它与Oracle,Mysql等传统数据库的优势。

此外,Hive对事物的支持不够好,原因是HDFS本身就设计为一次写入,多次读取的分布式存储系统,因此,不能使用Hive来完成诸如DELETE、UPDATE等在线事务处理的需求。

因此,Hive擅长的是非实时的、离线的、对响应及时性要求不高的海量数据批量计算,即席查询,统计分析。

  1. hive的数据单元
  1. Databases:数据库。概念等同于关系型数据库的Schema,不多解释;    (2)Tables:表。概念等同于关系型数据库的表,不多解释;
  1. Partitions:分区。概念类似于关系型数据库的表分区,没有那么多分区类型,只支持固定分区,将同一组数据存放至一个固定的分区中。
  2. Buckets (or Clusters):分桶。同一个分区内的数据还可以细分,将相同的KEY再划分至一个桶中,这个有点类似于HASH分区,只不过这里是HASH分桶,也有点类似子分区吧。
  1. hive的数据类型

既然是被当做数据库来使用,除了数据单元,Hive当然也得有一些列的数据类型。

(1)4.1 原始数据类型

  • 整型

1)TINYINT — 微整型,只占用1个字节,只能存储0-255的整数。

2)SMALLINT– 小整型,占用2个字节,存储范围–32768 到 32767。

3)INT– 整型,占用4个字节,存储范围-2147483648到2147483647。

4)BIGINT– 长整型,占用8个字节,存储范围-2^63到2^63-1。

  • 布尔型

1)BOOLEAN — TRUE/FALSE

  • 浮点型

1)FLOAT– 单精度浮点数。

2)DOUBLE– 双精度浮点数。

  • 字符串型

1)STRING– 不设定长度。

(2)4.2 复合数据类型

1)Structs:一组由任意数据类型组成的结构。比如,定义一个字段C的类型为STRUCT {a INT; b STRING},则可以使用a和C.b来获取其中的元素值;

2)Maps:和Java中的Map没什么区别,就是存储K-V对的;

3)Arrays:就是数组而已;

5、hive的特性

(1)hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供完整的sql查询功能,可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。

  (2)Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具,可以用来进行数据提取转化加载(ETL),这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL,它允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

  要理解hive,必须先理解hadoop和mapreduce,如果有不熟悉的童鞋,可以百度一下。

  使用hive的命令行接口,感觉很像操作关系数据库,但是hive和关系数据库还是有很大的不同,下面我就比较下hive与关系数据库的区别,具体如下:

(1)hive和关系数据库存储文件的系统不同,hive使用的是hadoop的HDFS(hadoop的分布式文件系统),关系数据库则是服务器本地的文件系统;

(2)hive使用的计算模型是mapreduce,而关系数据库则是自己设计的计算模型;

(3)关系数据库都是为实时查询的业务进行设计的,而hive则是为海量数据做数据挖掘设计的,实时性很差;实时性的区别导致hive的应用场景和关系数据库有很大的不同;

(4)Hive很容易扩展自己的存储能力和计算能力,这个是继承hadoop的,而关系数据库在这个方面要比数据库差很多。

  以上都是从宏观的角度比较hive和关系数据库的区别,hive和关系数据库的异同还有很多,我在文章的后面会一一描述。

  1. hive服务端组件

(1)Driver组件:该组件包括Complier、Optimizer和Executor,它的作用是将我们写的HiveQL(类SQL)语句进行解析、编译优化,生成执行计划,然后调用底层的mapreduce计算框架。

(2)Metastore组件:元数据服务组件,这个组件存储hive的元数据,hive的元数据存储在关系数据库里,hive支持的关系数据库有derby、mysql。元数据对于hive十分重要,因此hive支持把metastore服务独立出来,安装到远程的服务器集群里,从而解耦hive服务和metastore服务,保证hive运行的健壮性,这个方面的知识,我会在后面的metastore小节里做详细的讲解。

(3)Thrift服务:thrift是facebook开发的一个软件框架,它用来进行可扩展且跨语言的服务的开发,hive集成了该服务,能让不同的编程语言调用hive的接口。

7hive客户端组件:

(1)CLI:command line interface,命令行接口。

(2)Thrift客户端:上面的架构图里没有写上Thrift客户端,但是hive架构的许多客户端接口是建立在thrift客户端之上,包括JDBC和ODBC接口。

(3)WEBGUI:hive客户端提供了一种通过网页的方式访问hive所提供的服务。这个接口对应hive的hwi组件(hive web interface),使用前要启动hwi服务。

  下面我着重讲讲metastore组件,具体如下:

  Hive的metastore组件是hive元数据集中存放地。Metastore组件包括两个部分:metastore服务和后台数据的存储。后台数据存储的介质就是关系数据库,例如hive默认的嵌入式磁盘数据库derby,还有mysql数据库。Metastore服务是建立在后台数据存储介质之上,并且可以和hive服务进行交互的服务组件,默认情况下,metastore服务和hive服务是安装在一起的,运行在同一个进程当中。我也可以把metastore服务从hive服务里剥离出来,metastore独立安装在一个集群里,hive远程调用metastore服务,这样我们可以把元数据这一层放到防火墙之后,客户端访问hive服务,就可以连接到元数据这一层,从而提供了更好的管理性和安全保障。使用远程的metastore服务,可以让metastore服务和hive服务运行在不同的进程里,这样也保证了hive的稳定性,提升了hive服务的效率。

下面我给大家展示一个简单的例子,看看hive是怎么操作的。

首先我们创建一个普通的文本文件,里面只有一行数据,该行也只存储一个字符串,命令如下:

echo  ‘sharpxiajun’ > /home/hadoop/test.txt

 然后我们建一张hive的表:

hive –e “create table test (value string);

 接下来加载数据:

Load data local inpath ‘home/hadoop/test.txt’ overwrite intotable test

 最后我们查询下表:

hive –e ‘select* fromtest’;

大家看到了吧,hive十分简单,很好入门,操作和sql很像,下面我就要深入分析下hive与关系数据库的区别,这部分可能有些人看的不是很明白,但是很有必要提前提出,以后我的文章里将进一步讲述hive,那时不太明白的童鞋在看看这部分,很多问题就会清晰很多,具体如下:

(1)关系数据库里,表的加载模式是在数据加载时候强制确定的(表的加载模式是指数据库存储数据的文件格式),如果加载数据时候发现加载的数据不符合模式,关系数据库则会拒绝加载数据,这个就叫“写时模式”,写时模式会在数据加载时候对数据模式进行检查校验的操作。Hive在加载数据时候和关系数据库不同,hive在加载数据时候不会对数据进行检查,也不会更改被加载的数据文件,而检查数据格式的操作是在查询操作时候执行,这种模式叫“读时模式”。在实际应用中,写时模式在加载数据时候会对列进行索引,对数据进行压缩,因此加载数据的速度很慢,但是当数据加载好了,我们去查询数据的时候,速度很快。但是当我们的数据是非结构化,存储模式也是未知时候,关系数据操作这种场景就麻烦多了,这时候hive就会发挥它的优势。

(2)关系数据库一个重要的特点是可以对某一行或某些行的数据进行更新、删 除操作,   hive不支持对某个具体行的操作,hive对数据的操作只支持覆盖原  数据和追加数据。Hive 也不支持事务和索引。更新、事务和索引都是关系数据 库的特征,这些hive都不支持,也 不打算支持,原因是hive的设计是海量数  据进行处理,全数据的扫描时常态,针对某些具    体数据进行操作的效率是   很差的,对于更新操作,hive是通过查询将原表的数据进行转化   最后存储   在新表里,这和传统数据库的更新操作有很大不同。

(3)Hive也可以在hadoop做实时查询上做一份自己的贡献,那就是和hbase  集成, hbase可以进行快速查询,但是hbase不支持类SQL的语句,那么此时  hive可以给hbase  提供sql语法解析的外壳,可以用类sql语句操作hbase数 据库。

今天的hive就写到这里,关于hive我打算一共写三篇文章,这是第一篇,下一篇主要讲hive支持的数据模型,例如:数据库(database)、表(table)、分区(partition)和桶(bucket),还有hive文件存储的格式,还有hive支持的数据类型。第三篇文章就会讲到hiveQL的使用、以及结合mapreduce查询优化的技术和自定义函数,以及我们现在在公司项目里运用hive的实例。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(大数据)