HBase和Hive

HBase

一、HBase是什么？

HBase是基于Hadoop适合存储非结构化数据的高可靠、高性能、列式存储、可伸缩的分布式非关系型数据库,可以充分利用HDFS提供分布式数据存储,利用MapReduce处理海量数据实现高性能计算,利用ZooKeeper实现协同服务达到稳定服务和失败恢复。在需要实时读写、随机访问超大规模数据集时可以使用HBase。

HBase良好的分布式架构设计为海量数据的快速存储、随机访问提供了可能,基于数据副本机制和分区机制可以轻松实现在线扩容、缩容和数据容灾,是大数据领域中Key-Value数据结构存储最常用的数据库方案。

二、HBase的优点或特点

特点：

1、易扩展。Hbase 的扩展性主要体现在两个方面,一个是基于运算能力(RegionServer) 的扩展,通过增加 RegionSever 节点的数量,提升 Hbase 上层的处理能力;另一个是基于存储能力的扩展(HDFS),通过增加 DataNode 节点数量对存储层的进行扩容,提升 HBase 的数据存储能力

2、海量存储。HBase 作为一个开源的分布式 Key-Value 数据库,其主要作用是面向 PB 级别数据的实时入库和快速随机访问。这主要源于上述易扩展的特点,使得 HBase 通过扩展来存储海量的数据。

3、列式存储。Hbase 是根据列族来存储数据的。列族下面可以有非常多的列。列式存储的最大好处就是,其数据在表中是按照某列存储的,这样在查询只需要少数几个字段时,能大大减少读取的数据量。

4、高可靠性。WAL 机制保证了数据写入时不会因集群异常而导致写入数据丢失,Replication 机制保证了在集群出现严重的问题时,数据不会发生丢失或损坏。而且 Hbase 底层使用 HDFS,HDFS 本身也有备份。

5、稀疏性。在 HBase 的列族中,可以指定任意多的列,为空的列不占用存储空间,表可以设计得非常稀疏

优点：

1、HDFS有高容错,高扩展的特点,而Hbase基于HDFS实现数据的存储,因此Hbase拥有与生俱来的超强的扩展性和吞吐量

2、HBase采用的是Key/Value的存储方式,这意味着,即便面临海量数据的增长,也几乎不会导致查询性能下降

3、HBase是一个列式数据库,相对于于传统的行式数据库而言。当你的单张表字段很多的时候,可以将相同的列(以regin为单位)存在到不同的服务实例上,分散负载压力

缺点：

1、架构设计复杂,且使用HDFS作为分布式存储,因此只是存储少量数据,它也不会很快。在大数据量时,它慢的不会很明显

2、Hbase不支持表的关联操作,因此数据分析是HBase的弱项。常见group by或order by只能通过编写MapReduce来实现

3、Hbase部分支持了ACID

三、HBase应用场景

1、半结构化或非结构化数据

对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。当业务发展需要存储author的email,phone,address信息时RDBMS需要停机维护,而HBase支持动态增加。

2、记录非常稀疏

RDBMS的行有多少列是固定的,为null的列浪费了存储空间。而如上文提到的,HBase为null的Column不会被存储,这样既节省了空间又提高了读性能。

3、多版本数据

根据Row key和Column key定位到的Value可以有任意数量的版本值,因此对于需要存储变动历史记录的数据,用HBase就非常方便了。比如author的Address是会变动的,业务上一般只需要最新的值,但有时可能需要查询到历史值。

4、超大数据量

当数据量越来越大,RDBMS数据库撑不住了,就出现了读写分离策略,通过一个Master专门负责写操作,多个Slave负责读操作,服务器成本倍增。随着压力增加,Master撑不住了,这时就要分库了,把关联不大的数据分开部署,一些join查询不能用了,需要借助中间层。随着数据量的进一步增加,一个表的记录越来越大,查询就变得很慢,于是又得搞分表,比如按ID取模分成多个表以减少单个表的记录数。采用HBase只需要加机器即可,HBase会自动水平切分扩展,跟Hadoop的无缝集成保障了其数据可靠性HDFS和海量数据分析的高性能MapReduce

适合场景:单表超千万,上亿,且高并发

不适合场景:主要需求是数据分析,比如做报表。数据量规模不大,对实时性要求高

四、HBase原理架构

1、HBase Client

HBase Client 为用户提供了访问 HBase 的接口,可以通过元数据表来定位到目标数据的RegionServer,另外 HBase Client 还维护了对应的 cache 来加速 Hbase 的访问,比如缓存元数据的信息。

2、HMaster

HMaster 是 HBase 集群的主节点,负责整个集群的管理工作,主要工作职责如下:

分配Region:负责启动的时候分配Region到具体的 RegionServer

负载均衡:一方面负责将用户的数据均衡地分布在各个 Region Server 上,防止Region Server数据倾斜过载。另一方面负责将用户的请求均衡地分布在各个 Region Server 上,防止Region Server 请求过热

维护数据:发现失效的 Region,并将失效的 Region 分配到正常的 RegionServer 上,并且在Region Sever 失效的时候,协调对应的HLog进行任务的拆分

3、Region Server

Region Server 直接对接用户的读写请求,是真正的干活的节点,主要工作职责:

管理 HMaster 为其分配的 Region

负责与底层的 HDFS 交互,存储数据到 HDFS

负责 Region 变大以后的拆分以及 StoreFile 的合并工作

与 HMaster 的协同:当某个 RegionServer 宕机之后,ZK 会通知 Master 进行失效备援。下线的RegionServer 所负责的 Region 暂时停止对外提供服务,Master 会将该 RegionServer 所负责的Region 转移到其他 RegionServer 上,并且会对所下线的 RegionServer 上存在 MemStore 中还未持久化到磁盘中的数据由 WAL 重播进行恢复

3.1 Region

每一个 Region 都有起始 RowKey 和结束 RowKey,代表了存储的Row的范围,保存着表中某段连续的数据。一开始每个表都只有一个 Region,随着数据量不断增加,当 Region 大小达到一个阈值时,Region 就会被Region Server 水平切分成两个新的 Region。当 Region 很多时,HMaster 会将 Region保存到其他 Region Server 上。

3.2 Store

一个 Region 由多个 Store 组成,每个 Store 都对应一个 Column Family, Store 包含 MemStore 和StoreFile。

3.3 MemStore

作为HBase的内存数据存储,数据的写操作会先写到 MemStore 中,当MemStore 中的数据增长到一个阈值(默认64M)后,Region Server 会启动 flasheatch 进程将 MemStore 中的数据写人 StoreFile 持久化存储,每次写入后都形成一个单独的 StoreFile。当客户端检索数据时,先在 MemStore中查找,如果MemStore 中不存在,则会在 StoreFile 中继续查找

3.4 StoreFile

MemStore 内存中的数据写到文件后就是StoreFile,StoreFile底层是以 HFile 的格式保存。HBase以Store的大小来判断是否需要切分Region。

当一个Region 中所有 StoreFile 的大小和数量都增长到超过一个阈值时,HMaster 会把当前Region分割为两个,并分配到其他 Region Server 上,实现负载均衡。

3.5 HFile

HFile 和 StoreFile 是同一个文件,只不过站在 HDFS 的角度称这个文件为HFile,站在HBase的角度就称这个文件为StoreFile。

3.6 HLog

负责记录着数据的操作日志,当HBase出现故障时可以进行日志重放、故障恢复。例如,磁盘掉电导致MemStore中的数据没有持久化存储到 StoreFile,这时就可以通过HLog日志重放来恢复数据。

4、ZooKeeper

HBase 通过 ZooKeeper 来完成选举 HMaster、监控 Region Server、维护元数据集群配置等工作。主要工作职责:

选举HMaster:通ooKeeper来保证集中有1HMaster在运行,如果 HMaster 异常,则会通过选举

机制产生新的 HMaster 来提供服务

监控Region Server: 通过 ZooKeeper 来监控 Region Server 的状态,当Region Server 有异常的时候,通过回调的形式通知 HMaster 有关Region Server 上下线的信息维护元数据和集群配置:通过ooKeeper储B信息并对外提供访问接口

5、HDFS

HDFS 为 HBase 提供底层数据存储服务,同时为 HBase提供高可用的支持, HBase 将 HLog 存储在HDFS 上,当服务器发生异常宕机时,可以重放 HLog 来恢复数据。

五、优化方法

1、减少调整

HBase中有几个内容会动态调整,如Region分区、HFile。通过一些方法可以减少这些会带来I/O开销的调整。Region:没有预建分区的话,随着Region中条数的增加,Region会进行分裂,这将增加I/O开销,所以解决方法就是根据你的RowKey设计来进行预建分区,减少Region的动态分裂。

HFile:MemStore执行flush会生成HFile,同时HFilewe年过多时候也会进行Merge, 为了减少这样的无谓的I/O开销,建议估计项目数据量大小,给HFile设定一个合适的值。

2、减少启停

数据库事务机制就是为了更好地实现批量写入,较少数据库的开启关闭带来的开销,那么HBase中也存在频繁开启关闭带来的问题。

关闭Compaction。HBase 中自动化的Minor Compaction和Major Compaction会带来极大的I/O开销,为了避免这种不受控制的意外发生,建议关闭自动Compaction,在闲时进行compaction。

3、减少数据量

开启过滤,提高查询速度

开启BloomFilter,BloomFilter是列族级别的过滤,在生成一个StoreFile同时会生成一个MetaBlock,用于查询时过滤数据

使用压缩。一般推荐使用Snappy和LZO压缩

4、合理设计

HBase 表格中 RowKey 和 ColumnFamily 的设计是非常重要,好的设计能够提高性能和保证数据的准确性。

RowKey设计

散列性:散列性能够保证相同相似的RowKey聚合,相异的RowKey分散,有利于查询

简短性:RowKey作为key的一部分存储在HFile中,如果为了可读性将rowKey设计得过长,那么将会增加存储压力

唯一性:rowKey必须具备明显的区别性

业务性:具体情况具体分析。

列族的设计

优势:HBase中数据是按列进行存储的,那么查询某一列族的某一列时就不需要全盘扫描,只需要扫描某一列族,减少了读I/O

劣势:多列族意味这一个Region有多个Store,一个Store就有一个MemStore,当MemStore进行flush时,属于同一个Region的Store中的MemStore都会进行flush,增加I/O开销。

Hive

一、什么是hive？

hive是一个建立在Hadoop上的开源数据仓库软件,可以将存储在Hadoop文件中的结构化、半结构化数据文件映射为一张数据库表,基于表提供了一种类似SQL的查询模型,称为hive查询语言HQL,用于访问和分析存储在Hadoop文件中的大型数据集。

Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射成为一张数据库表,并提供类SQL的查询功能。可以将sql语句转化为MapReduce任务进行运行。Hive提供了一系列的工具,可以用来进行数据提取转化加载ETL,这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制

二、hive的优点或特点

优点：

1、操作接口采用类SQL语法,提供快速开发的能力(简单、容易上手)

2、避免了去写MapReduce,减少开发人员的学习成本

3、Hive的执行延迟比较高,因此Hive常用于数据分析,对实时性要求不高的场合

4、Hive优势在于处理批量数据,对于处理小数据没有优势,因为Hive的执行延迟比较高

5、Hive支持用户自定义函数,用户可以根据自己的需求来实现自己的函数

缺点：

1、Hive的HQL表达能力有限

迭代式算法无法表达

数据挖掘方面不擅长,由于MapReduce数据处理流程的限制,效率更高的算法却无法实现

2、Hive的效率比较低

Hive自动生成的MapReduce作业,通常情况下不够智能化

Hive调优比较困难,粒度较粗

3、迭代式算法无法表示

三、hive的应用场景

1、数据源：要进行数据分析时，可以将数据存储到hive里

2、日志分析：统计网站一个时间段内的pv、uv或者多维度数据分析

3、海量结构化数据离线分析：hive的执行延迟比较高，因为hive优势在于处理大数据，常用于数据分析的，对实时性要求不高

四、hive的原理机构

hive的工作原理：

Hive通过给用户提供的一系列交互接口,接收到用户的指令SQL,使用自己的Driver, 结合元数据MetaStore,将这些指令翻译成MapReduce,提交到Hadoop中执行,最后将执行返回的结果输出到用户交互接口。

Hive的本质上就是MapReduce。在hive的执行语句当中的执行查询的顺序,例如sql语句: select... from ... where ... group by ... having ... order by ...,这里执行顺序:from ... where ... select ...group by ... having ... order by ... 其实总结hive的执行顺序也是总结mapreduce的执行顺序。

map阶段:

1、执行from加载,进行表的查找与加载

2、执行where过滤,进行条件过滤与筛选

3、执行select查询:进行输出项的筛选

4、map端文件合并:map端本地溢出写文件的合并操作,每个map最终形成一个临时文件,然后按列映射到对应的。

Reduce阶段:

1、group by对map端发送过来的数据进行分组并进行计算

2、select最后过滤列用于输出结果3、order by排序。在进行select后进行结果输出到HDFS文会形成一张表,在这张表当中做分组排序这些操作

Hive工作流程

简单来说Hive就是一个查询引擎。当Hive接受到一条SQL语句会执行如下操作:

1、词法分析和语法分析。使用antlr将SQL语句解析成抽象语法树

2、语义分析。从MetaStore中获取元数据信息,解释SQL语句中的表名、列名、数据类型

3、逻辑计划生成。生成逻辑计划得到算子树

4、逻辑计划优化。对算子树进行优化

5、物理计划生成。将逻辑计划生成出的MapReduce任务组成的DAG的物理计划

6、物理计划执行。将DAG发送到Hadoop集群进行执行

7、将查询结果返回

Hive架构

Hive的两大组件主要是HCatalog和WebHCat。其中HCatalog是Hadoop的表和存储管理层,允许使用不同数据处理工具,如MapReduc的用户更容易地在网格上进行数据的读写。而WebHCat提供了一个服务,用户可通过该服务来运行MapReduce任务、Pig查询、Hive作业,也可以使用HTTP的REST接口来执行一些Hive的元数据操作

五、hive的优化

1、Fetch抓取

Fetch抓取是指，Hive中对某些情况的查询可以不必使用MapReduce计算。例如：SELECT * FROM employees;在这种情况下，Hive可以简单地读取employee对应的存储目录下的文件，然后输出查询结果到控制台。

在hive-default.xml.template文件中hive.fetch.task.conversion默认是more，老版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit查找等都不走mapreduce。

2、本地模式

大多数的的Hadoop Job是需要Hadoop提供的完整的可扩展性来处理大数据集的。不过，有时Hive的输入数据量是非常小的。在这种情况下，为查询触发执行任务时消耗可能会比实际job的执行时间要多的多。对于大多数这种情况，Hive可以通过本地模式在单台机器上处理所有的任务。对于小数据集，执行时间可以明显被缩短。

用户可以通过设置hive.exec.mode.local.auto的值为true，来让Hive在适当的时候自动启动这个优化。

(1)set hive.exec.mode.local.auto=true; //开启本地mr

//设置local mr的最大输入数据量，当输入数据量小于这个值时采用local mr的方式，默认为134217728，即128M

  (2)set hive.exec.mode.local.auto.inputbytes.max=50000000;

  //设置local mr的最大输入文件个数，当输入文件个数小于这个值时采用local mr的方式，默认为4

  (3)set hive.exec.mode.local.auto.input.files.max=10;

3、过滤导致数据倾斜的Key、空Key转换(数据倾斜)

  有时join超时是因为某些key对应的数据太多，而相同key对应的数据都会发送到相同的reducer上，从而导致内存不够。此时我们应该仔细分析这些异常的key，很多情况下，这些key对应的数据是异常数据，我们需要在SQL语句中进行过滤。

  有时虽然某个key为空对应的数据很多，但是相应的数据不是异常数据，必须要包含在join的结果中，此时我们可以表a中key为空的字段赋一个随机的值，使得数据随机均匀地分不到不同的reducer上。

4、设置MapJoin(数据倾斜)

  如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成Common Join，即：在Reduce阶段完成join。容易发生数据倾斜。可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。

开启MapJoin参数设置：

  （1）设置自动选择Mapjoin

    set hive.auto.convert.join = true; 默认为true

  （2）大表小表的阀值设置（默认25M一下认为是小表）：

    set hive.mapjoin.smalltable.filesize=25000000;

5、针对Group By优化，开启Map端聚合

  默认情况下，Map阶段同一Key数据分发给一个reduce，当一个key数据过大时就倾斜了。并不是所有的聚合操作都需要在Reduce端完成，很多聚合操作都可以先在Map端进行部分聚合，最后在Reduce端得出最终结果。

   开启Map端聚合参数设置

  （1）是否在Map端进行聚合，默认为True

    hive.map.aggr = true

  （2）在Map端进行聚合操作的条目数目

     hive.groupby.mapaggr.checkinterval = 100000

  （3）有数据倾斜的时候进行负载均衡（默认是false）

hive.groupby.skewindata = true

6、Count(Distinct) 去重优化方案(数据倾斜)

数据量小的时候无所谓，数据量大的情况下，由于COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换，虽然会多用一个Job来完成，但在数据量大的情况下，这个绝对是值得的。

select count(distinct id) from bigtable;(优化前)

select count(id) from (select id from bigtable group by id) a;(优化后)

7、笛卡尔积

尽量避免笛卡尔积，join的时候不加on条件，或者无效的on条件，Hive只能使用1个reducer来完成笛卡尔积。