hbase

1.HBase的机群搭建过程(在原来的hadoop0上的HBase伪分布基础上进行搭建) 1.1 集群结构，主节点(hmaster)是hadoop0，从节点(region server)是hadoop1和hadoop2 1.2 修改hadoop0上的hbase的几个文件 　　(1)修改hbase-env.sh的最后一行export HBASE_MANAGES_ZK=false 　　(2)修改hbase-site.xml文件的hbase.zookeeper.quorum的值为hadoop0,hadoop1,hadoop2 　　(3)修改regionservers文件(存放的region server的hostname)，内容修改为hadoop1、hadoop2 1.3 复制hadoop0中的hbase文件夹到hadoop1、hadoop2中 　　复制hadoop0中的/etc/profile到hadoop1、hadoop2中，在hadoop1、hadoop2上执行source /etc/profile 1.4 首先启动hadoop，然后启动zookeeper集群。 　　最后 在hadoop0上启动hbase集群 。 来源： https://www.cnblogs.com/chamie/p/4736392.html

一、什么是HBase HBase是一个高可靠、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价的PC Server上搭建大规模结构化存储集群。 HBase是Google BigTable的开源实现，与Google BigTable利用GFS作为其文件存储系统类似，HBase利用Hadoop HDFS作为其文件存储系统； 　　 Google运行MapReduce来处理BigTable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据； Google BigTable利用Chubby作为协同服务，HBase利用Zookeeper作为协同服务。 二、HBase设计模型 HBase中的每一张表就是所谓的BigTable。BigTable会存储一系列的行记录，行记录有三个基本类型的定义： RowKey 是行在BigTable中的唯一标识。 TimeStamp： 是每一次数据操作对应关联的时间戳，可以看作SVN的版本。 Column： 定义为<family>:<label>，通过这两部分可以指定唯一的数据的存储列，family的定义和修改需要对HBase进行类似于DB的DDL操作， 而label，不需要定义直接可以使用，这也为动态定制列提供了一种手段。family另一个作用体现在物理存储优化读写操作上，同family

1、 进入Hbase shell sz280328:cloudera-scm@/home/cloudera-scm>hbase shell 2、 建表，插入一行数据 hbase(main):001:0> create 'hbase_stu', 'stu_info', 'score' hbase(main):002:0> list hbase(main):003:0> put 'hbase_stu', '001', 'stu_info:name','tom' hbase(main):004:0> put 'hbase_stu', '001', 'stu_info:age', 18 hbase(main):005:0> put 'hbase_stu', '001', 'stu_info:gender', 'man' hbase(main):006:0> put 'hbase_stu', '001', 'score:Chinese', 91 hbase(main):007:0> put 'hbase_stu', '001', 'score:Math', 90 hbase(main):008:0> put 'hbase_stu', '001', 'score:English', 89 hbase(main):009:0> desc 'hbase_stu' hbase(main):010:0

1、实在是在安装CDH的时候无法安装成功的话，只有重新启动了，下面给大家分享一个神器，按照这个脚本应该差不多就能卸载干净，然后重新安装，写一个脚本，内容如下，救命的神器呀： #!/bin/bash sudo /usr/share/cmf/uninstall-cloudera-manager.sh sudo service cloudera-scm-server stop sudo service cloudera-scm-server-db stop sudo service cloudera-scm-agent stop sudo yum remove cloudera-manager-agent sudo yum remove cloudera-manager-server sudo yum remove cloudera-manager-server-db-2 sudo yum remove 'cloudera-manager-*' bigtop-utils bigtop-jsvc bigtop-tomcat hadoop hadoop-hdfs hadoop-httpfs hadoop-mapreduce hadoop-yarn hadoop-client hadoop-0.20-mapreduce hue-plugins hbase hive oozie oozie

转自： https://yq.aliyun.com/articles/644139?spm=a2c4e.11155472.0.0.74bb68c6ROboVF 1.概述 HBase是一个实时的非关系型数据库，用来存储海量数据。但是，在实际使用场景中，在使用HBase API查询HBase中的数据时，有时会发现数据查询会很慢。本篇博客将从客户端优化和服务端优化两个方面来介绍，如何提高查询HBase的效率。 2.内容 这里，我们先给大家介绍如何从客户端优化查询速度。 2.1 客户端优化 客户端查询HBase，均通过HBase API的来获取数据，如果在实现代码逻辑时使用API不当，也会造成读取耗时严重的情况。 2.1.1 Scan优化 在使用HBase的Scan接口时，一次Scan会返回大量数据。客户端向HBase发送一次Scan请求，实际上并不会将所有数据加载到本地，而是通过多次RPC请求进行加载。这样设计的好处在于避免大量数据请求会导致网络带宽负载过高影响其他业务使用HBase，另外从客户端的角度来说可以避免数据量太大，从而本地机器发送OOM（内存溢出）。 默认情况下，HBase每次Scan会缓存100条，可以通过属性hbase.client.scanner.caching来设置。另外，最大值默认为-1，表示没有限制，具体实现见源代码： /** * @return the

环境：jdk 1.8 + hadoop2.7.6+zookeeper3.4.9+centos7 一.安装zookeeper（集群模式） 0.安装机器 ip hostname 192.168.100.9 ns1 192.168.100.10 dn1 1. 下载zookeeper 2.zookeeper tar包一栋至 ns1的 /usr/local,解压 tar -zxvf zookeeper-3.4.9.tar.gz 3.修改zk配置文件 cd /usr/local/zookeeper-3.4.9/conf cp zoo_sample.cfg zoo.cfg 修改配置文件zoo.cfg（所有节点的配置文件相同） #tickTime这个时间是作为zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是说每个tickTime时间就会发送一个心跳 tickTime=2000 #initLimit这个配置项是用来配置zookeeper接受客户端（这里所说的客户端不是用户连接zookeeper服务器的客户端,而是zookeeper服务器集群中连接到leader的follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数 initLimit=10 #syncLimit这个配置项标识leader与follower之间发送消息,请求和应答时间长度

HBase拥有出色的扩展性，其中最依赖的就是region的自动split机制。 1.split触发时机与策略 前面我们已经知道了，数据写入过程中，需要先写memstore，然后memstore满了以后，flush写入磁盘，形成新的HFile文件。 当HFile文件数量不断累积，Region server就会触发compaction机制，把小文件合并为大的HFIle。 当每次flush完成 或者 compaction完成后，regionSplitPolicy就会判断是否需要进行split。 split触发时机简单来说，就是看一个region里面的最大store是否超过阈值。 当然，hbase支持多种策略来设置这个阈值到底怎么计算，这就是触发策略。 0.94版本前默认的策略是ConstantSizeRegionSplitPolicy，这个阈值时一个固定值。 0.94-2.0版本的默认策略是IncreasingToUpperBoundRegionSplitPolicy。 2.0版本的默认策略是SteppingSplitPolicy。这两种策略设置的阈值不是一个固定值，而是会和region所属表在当前regionserver上的region个数有关。只是在计算公式上稍有差异。 另外，还有比如DisableSplitPolicy、KeyPrefixRegionSplitPolicy

基本概念 RegionServer HBase的RegionServer就是用来处理客户端读取和写入数据的，和kafka的broker，Elasticsearch的Node的功能相同。 Region Region和kafka的partition(分区)，Elasticsearch的shard(分片)差不多，是个物理概念。 一个表可以有多个Region，一个Region只属于一张表。 组件 逻辑存储 物理存储 Kafka topic partition Elasticsearch index shard HBase table region store store在HBase中对应的是列簇(Column Family,CF) 列簇在内存中的store是memstore，在磁盘中的是storefile，当内存中的memstore数据达到一定的阈值之后， 就会通过flashcache在磁盘上创建一个新的storefile，并且将memstore中的数据写入这个新创建的storefile。 当storefile文件的数量增长到一定阈值后会进行合并，在合并过程中会进行版本删除工作，从而形成更大的storefile。 当一个region所有storefile的大小和超过一定阈值后，会把当前的region分割为两个，并由master分配到相应的RegionServer服务器，实现负载均衡。

为什么要这样子做呢？ HBase本身的设计目标是 支持稀疏表 ，而 稀疏表通常会有很多列 ，但是每一行有值的列又比较少。 如果不使用Column Family的概念，那么有两种设计方案： 1.把所有列的数据放在一个文件中（也就是传统的按行存储）。那么当我们想要访问少数几个列的数据时，需要遍历每一行，读取整个表的数据，这样子是很低效的。 2.把每个列的数据单独分开存在一个文件中（按列存储）。那么当我们想要访问少数几个列的数据时，只需要读取对应的文件，不用读取整个表的数据，读取效率很高。然而，由于稀疏表通常会有很多列，这会导致文件数量特别多，这本身会影响文件系统的效率。 而Column Family的提出就是为了在上面两种方案中做一个折中。HBase中 将一个Column Family中的列存在一起，而不同Column Family的数据则分开 。 由于在HBase中Column Family的数量通常很小，同时HBase建议把经常一起访问的比较类似的列放在同一个Column Family中，这样就可以在访问少数几个列时，只读取尽量少的数据。 优化： 因为一直在做hbase的应用层面的开发，所以体会的比较深的一点是hbase的表结构设计会对系统的性能以及开销上造成很大的区别，本篇文章先按照hbase表中的rowkey、columnfamily、column

一：Hbase Memstore Flush Hbase中，Region时集群节点上最小的数据存储单元，用户数据表由一个或多个Region组成。 在Region中，每个ColumnFamily（列簇）的数据组成一个Store。每个Store由一个或多个StoreFile实例，StoreFile是对存储数据文件（HFile）的轻量级封装。 一个Store还有一个MemStore。每一个HRegionServer的所有东西会共享一个HLog。 1：MemStore级别：hbase.hregion.memstore.flush.size默认128MB，当Region中任意一个MemStore的大小达到了上限，触发memstore flush。 2：Region级别：hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默认是4 * 128MB=512MB。当Region中所有MemStore的大小总和达到了上限，触发memstore flush。 3：RegionServer级别：当一个RegionServer中所有Memstore大小总和达到上限，hfile.block.cache.size(默认值0.4) * hbase_regionserver_heapsize(默认值2GB)=819