hbase的一些要点

hbase特点及简介：
	hbase源自于谷歌的三大论文之一
		GFS -- hdfs
		MapReduce - MR
		BigTable - hbase
	hbase在以Hadoop为基础的生态圈中的地位
		hbase和Hadoop的hdfs结合使用，构建在hdfs上的数据库（hbase为hdfs上的海量的结构化或非结构数据构建了层层的索引）
		为存储在hdfs上的海量的数据提供存储及随机检索平台
		可以与MapReduce、hive、spark等分析框架集成，为数据分析框架提供数据源
	基于【列存储】的分布式数据库
		列存储和行存储的区别
			RDBMS都是基于行存储
				表的每行数据是一个连续的存储单元
				如果在select查询时只涉及到其中的几列，无关的列数据也会被加载读取，系统io较大
			hbase基于列存储的数据库
				表的每列数据是一个连续的存储单元
				如果在select查询时只涉及到其中的几列，只有相关的列数据才会被加载读取，大大降低系统的io流
				因为每列的数据类型都是一样的，更容易实现压缩存储
	hbase适合存储结构化或非结构化的数据
		mysql hive上的表都是二维表，每条数据的字段的个数和名称都是固定
		hbase表中存储的每行数据可以有不同的列数据及列种类
	有基于key-value形式数据存储的特点
		可以根据一个key快速获取对应的value值
		key：rowkey+列簇+列名 =》 唯一的cell单元格
		key：rowkey+列簇+列名+时间戳 =》 唯一的value值
				因为在一个单元格中可以存储多个基于时间戳区分的value值
	高可靠性、高性能、可伸缩的分布式数据库
		高可靠性、可伸缩 =》 hdfs
		高性能 =》对比RDBMS，hbase可以为海量数据提供的存储及随机实时检索平台
	hbase本身不支持sql查询标准
		可以借助其他框架或插件实现sql查询
			通过hive映射hbase表数据=》可以通过hql间接分析hbase表数据
			通过phoenix插件
				标准的sql语句-》phoenix插件转换 -》hbase 的查询 java api 

hive与hbase的区别！！ 

    hive
        面向分析的数据仓库工具（非数据库），使用hive sql分析
        查询数据时高延迟
        表中存储【映射】的是结构化的数据
        hive表数据默认是行存储
        hive上的表为逻辑表
        hive本身不能存储数据及查询数据，完全依赖Hadoop
            hdfs -- 数据存储
            MapReduce -- 分析
            本质将hql转换为MapReduce 

    hbase
        面向数据存储和检索的数据库
        查询延迟非常的低
        适合存储结构化和非结构化的数据
        hbase表数据默认是列存储
        hbase上的表为物理表
        hbase是一个构建在hdfs上的面向列存储的分布式数据库
            可以依靠自身的检索机制从海量表中进行随机实时的读写操作

RDBMS与hbase的区别  -- 简述     

RDBMS与hive的区别  -- 简述                  

--------------------------------------  

hbase架构角色
    （hbase框架是一个主从架构）
    master
        hbase的主节点
        master服务主要作为
            管理用户对hbase上的表的增删改查（对表整体而不是表数据）
            管理分配表的region给regionserver节点
            负责对regionserver集群上的region的个数进行负载均衡
            监控所有regionserver从节点的运行状态及regionserver节点宕机后的容灾处理
                master是借助zookeeper感知regionserver上线和下线  

    regionserver
        hbase集群的从节点
        负责当前服务器节点上master所分配的表的region
        真正响应客户端读写请求的节点
        master不参与表数据的读写流程 

    zookeeper
        hbase强依赖zookeeper
        持有hbase集群的节点信息（集群节点的元数据）及hbase上所有表的寻址入口信息（meta表的region所在的regionserver节点信息）
            持有hbase集群的节点信息
                hbase有几个master节点和regionserver节点及节点的详细
            hbase上所有表的寻址入口信息
                hive表的元数据 -- 存储了mysql中
                hbase表的元数据 -- 有hbase执行存储管理
                    hbase上所有用户表的元数据信息存储在hbase上的一张meta表中
                    通常meta表的数据量较少所以只有1个region
                    该region会被分配给某个regionserver节点进行管理
                    而zookeeper持有了meta表的region所在的regionserver节点信息
                寻址入口？
                    因为所有的用户或客户端在向hbase集群上读写数据时都需要先获取所有表的元数据信息（meta表数据）
                meta表中存有哪些用户表的元数据信息呢？
                    用户表有几个region
                    每个region的'rowkey'范围
                    每个region被分配给了哪个regionserver管理
        zookeeper基于第三方观察者模式监控master及regionserver的运行状态保证hbase的高可用性 

    hfds
        强依赖hdfs上
        hbase表的数据最终落地到hdfs上
        通常将hbase的regionserver服务与hdfs的datanode部署在同一台服务器上

hbase的数据存储模型及存储模型中的专业术语 

    rowkey ： 行健
        用来标记唯一的一行数据
        类似RDBMS中的主键   

    column family 【CF】：列簇 / 列族
        可以将一些列定义在一起形成一个家族
        列簇可以为列增加一层索引
        同一张表中列簇的数量一般 小于等于2个 ？？？
        建表时一张表至少要有一个列簇
    column ：列
        字段，列名
        一个列必须属于某个列簇
        在hbase表中不同的行可以有不同的列
    cell ： 单元格
        单元格是hbase中最小最基本的存储单元
        单元格是实际值的存储
        单元格内存储的值一般小于15M
        每个单元格包含的数据信息有
            rowkey+cf+c+时间戳+value
    单元格中的时间戳
        value值插入到单元格中的时间
        时间戳可以用来区分同一个单元格中的多个历史值
        hbase的表中的单元格支持多个历史版本值
            默认建表时只支持一个版本值
            可以指定支持多个历史版本值 

    region的内部结构
        每个region是由1个或多个store组成，每个store下存储了同一个类簇下的所有的数据（cell单元格），store的数量=表的列簇的数量 ，每个region还包含一个Hlog预写制日志文件

            store的组成
                每个store是由1个memstore和0到多个storeFile文件组成
                    memstore：
                        是一个数据写入缓存区
                        可以用来加快hbase表的写数据速度
                        默认阈值为128M =》  <name>hbase.hregion.memstore.flush.size</name>
                        $ vi hbase-common/src/main/resources/hbase-default.xml
                    storeFile:
                        hbase的表数据文件
                        最终落地在hdfs上形成Hfile文件
            Hlog预写制日志文件
                Hlog文件可以用来临时保持写入到memstore中的数据防止regionserver节点宕机造成数据丢失
                当数据写入memstore之前默认将数据写入到Hlog中一份
                假如memstore中数据丢失可以从HLog中将数据进行恢复 

    hbase表在hdfs上的目录路径情况
        /hbase/data/  表数据
        /hbase/data/default
            建表时不指定命名空间库默认存储在此目录下
            在表名命名的目录下会出现1个或多个以region编号命名的目录
            在region编号命名的目录下会出现1个或多个以列簇名命名的目录
            在以列簇名命名的目录下会出现0到多个storeFile文件              

    表的region的命名：
        表名,Start Key,时间戳.region编号
        emp,,1536047033109.3eee90200aa437fe7f60e476df533fd2.

hbase数据检索流程（架构流程）介绍 

    client
        读写hbase的框架（MapReduce、hive、spark、flume..）或hbase shell
    zookeeper
        基于观察者模式监控master及regionserver的运行状态
        存储了hbase集群的节点信息及meta表的位置信息
    master
        管理表的region的增删改查及分配
        master借助zookeeper监控regionserver运行状态
            regionserver启动后会在zookeeper上注册节点的服务器信息
        master主节点可以配置多个 备份 （Backup Masters）
        master节点不参与hbase表数据读写流程，通常io低
    regionserver
        管理当前节点上的region
        响应客户端读写请求的节点
        处理region的写数据过程的三大机制（flush、compaction、split）
    Hadoop
        hbase利用Hadoop的hdfs提高了一个数据存储平台
        在hdfs上的hbase的文件有两种
            storeFile（Hfile）
                storeFile文件为Hadoop的二进制格式文件
                在hbase上表的数据没有数据类型，在底层都是字节数组
            Hlog
                预写制日志文件（WAL） -- 借助 oracle
                Hlog文件为Hadoop的sequence格式的文件
                Hlog文件与regionserver节点的数量关系
                    在0.9x版本中 一个region对应的一个Hlog文件
                    在1.x版本中
                        可以配置一个regionserver节点对应一个Hlog文件
                        这样可以减少Hlog文件的寻址次数 

hbase表数据的读数据流程： --- 根据某个rowkey到emp表读取某行数据 

    1、client先去访问zookeeper,从zookeeper里面获取meta表所在位置信息
            0.96之前的版本除了meta表还有一个root表，root表存储meta表位置信息，先通过zookeeper获取root表位置
            在从root表中读取meta表位置
            现在直接将meta表位置存入zookeeper中，减少会话次数
    2、client向meta表的region所在regionserver发起访问,读取meta表数据，获取hbase集群上所有user表的元数据
    3、根据当前的rowkey判断meta表中emp表的对应的region的位置信息，client找到了当前需要访问的emp表对应的region及所在的regionserver服务器
    4、client向对应regionserver服务器发起读请求
    5、regionserver收到client访问请求并相应
    6、找到对应的region及store后，先扫描memstore，在扫描blockcache（读缓存），最后再读取storefile[HDFS]文件
    7、regionserver把数据响应给client                        

hbase表数据的写数据流程： --- 根据某个rowkey向emp表写入数据 

    1、client先去访问zookeeper,从zookeeper里面获取meta表所在位置信息
            0.96之前的版本除了meta表还有一个root表，root表存储meta表位置信息，先通过zookeeper获取root表位置
            在从root表中读取meta表位置
            现在直接将meta表位置存入zookeeper中，减少会话次数
    2、client向meta表的region所在regionserver发起访问,读取meta表数据，获取hbase集群上所有user表的元数据
    3、根据当前的rowkey判断meta表中emp表的对应的region的位置信息，client找到了当前需要访问的emp表对应的region及所在的regionserver服务器
    4、client向对应regionserver服务器发起写请求
    5、regionserver收到client请求,并响应，regionserver先把数据写入HLog,防止数据丢失
    6、再把数据写入memstore内存缓存区,默认128M
    7、当Hlog和memstore都写入成功,则这条数据写入成功
    8、当memstore达到阀值[128M],会把memstore里面的数据Flush成storefile
    9、当[128M]storefile越来越多,会触发compaction合并操作,把多storefile合并成一个大的storefile
        合并的期间会彻底删除过期的或之前打上删除表的cell
        对hbase表数据进行删除时数据并没有立即从Hfile文件中删除，而是打上了一个'删除标签'
        在大合并期间会对打上'删除标签'的cell及TTL到期的数据进行彻底删除
        对所有文件中的数据依据rowkey的字典顺序进行排序
    10、当单个storefiles越来越大,达到一定阀值（10G或其他动态阈值）时会触发split操作,region被一分为二被master分配管理        

hbase写数据过程的三个机制 

**flush机制
    当memstore中的数据达到一定阈值会将memstore中的数据flush为storeFile文件 

      <property>
        <name>hbase.hregion.memstore.flush.size</name>
        <value>134217728</value>
        <description>
        Memstore will be flushed to disk if size of the memstore
        exceeds this number of bytes.  Value is checked by a thread that runs
        every hbase.server.thread.wakefrequency.</description>
      </property>

    思考：
        一个regionserver节点上可能管理了100个region，假设每个region内有两个store，则当前的regionserver节点需要维护的memstore总个数为 100*2 = 200个
        假设某一时刻所有的memstore中的数据都在120M左右，则此此时当前regionserver节点上总的memstore占用的内存空间为 24G  

    如何避免这种情况出现 

  <property>
    <name>hbase.regionserver.global.memstore.size</name>
    <value></value>
    <description>Maximum size of all memstores in a region server before new
      updates are blocked and flushes are forced. Defaults to 40% of heap (0.4).
      Updates are blocked and flushes are forced until size of all memstores
      in a region server hits hbase.regionserver.global.memstore.size.lower.limit.
      The default value in this configuration has been intentionally left emtpy in order to
      honor the old hbase.regionserver.global.memstore.upperLimit property if present.</description>
  </property>
        属性的默认值为0.4（40%）
        当一个regionserver节点上全部的memstore空间被占用超过regionserver--jvm中的heap堆内存空间的40%时，会对此节点上所有的region进行更新（写或修改）阻塞，同时将memstore中的数据强制flush为storeFile

        region进行更新（写或修改）阻塞什么时候解除
            当占用的内存量小于40%
        memstore中的数据强制flush为storeFile 什么时候解除呢
            当占用的内存量小于38%  

        regionserver--jvm中的heap堆内存空间大小：
            export HBASE_HEAPSIZE=1G
            开发中需要对此属性进行修改： 4G-15G 

  <property>
    <name>hbase.regionserver.global.memstore.size.lower.limit</name>
    <value></value>
    <description>Maximum size of all memstores in a region server before flushes are forced.
      Defaults to 95% of hbase.regionserver.global.memstore.size (0.95).
      A 100% value for this value causes the minimum possible flushing to occur when updates are
      blocked due to memstore limiting.
      The default value in this configuration has been intentionally left emtpy in order to
      honor the old hbase.regionserver.global.memstore.lowerLimit property if present.</description>
  </property>
        属性的默认值为0.4*0.95=0.38
        当一个regionserver节点上全部的memstore空间被占用超过regionserver--jvm中的heap堆内存空间的38%时，开始进行将memstore中的数据强制flush为storeFile

** compaction机制
    当flush到hdfs上的storeFile文件逐步增多，小文件过程会影响到hbase后续的数据检索性能
    compaction过程分为两个过程
        minor compaction
            小合并
            hbase会启动一个专用的线程监控每个store下的storeFile文件的数量
            当数据量达到3个时会进行一次小合并
            小合并是一种归类合并（并没有排序及判断cell有无删除或过期）
        major compaction
            大合并
            每隔一段时间（3.5天-10.5天）自动进行一次大合并
            大合并期间会进行以下操作
                对store下所有的storeFile文件进行加载重写并按照rowkey的字典顺序进行排序
                将打上删除标签的cell或过期的cell进行彻底删除  

**split机制
    当某个region下的某个store下的storeFile文件合并后的达到到的一定的阈值（10G或小于10G值），会触发整个region的分割

    触发分割的阈值： 

        0.94版本之前：
            单纯使用以下属性进行控制
            当合并后的storeFile文件超过10G时就会触发split分割
              <property>
                <name>hbase.hregion.max.filesize</name>
                <value>10737418240</value>
                <description>
                Maximum HStoreFile size. If any one of a column families' HStoreFiles has
                grown to exceed this value, the hosting HRegion is split in two.</description>
              </property>
            结论：
                对于数据量较少的小表不友好
                数据量少分割的概率很低，不利于分布式的读写操作 

        0.96-0.98 

          <property>
            <name>hbase.regionserver.region.split.policy</name>
            <value>IncreasingToUpperBoundRegionSplitPolicy</value>
          </property>                

            IncreasingToUpperBoundRegionSplitPolicy类底层依据一个公式来判断表的region是否需要split分割
            公式：
                Min（R*R*hbase.hregion.memstore.flush.size ，hbase.hregion.max.filesize ）
                Min（R*R*128M ，10G ）
                    R表示某一台regionserver节点上某个表的region的个数 

                    假如emp表，region被散列分配在regionserver集群上
                    如果在regionserver01上持有了emp表的1个region，此时emp表的region在regionserver01上的分割阈值为：min ( 1*1*128M ,10G ) =》128M
                    如果在regionserver01上持有了emp表的2个region，此时emp表的region在regionserver01上的分割阈值为：min ( 2*2*128M ,10G ) =》512M
                    如果在regionserver01上持有了emp表的3个region，此时emp表的region在regionserver01上的分割阈值为：min ( 3*3*128M ,10G ) =》1152M
                    ……
                    如果在regionserver01上持有了emp表的9个region，此时emp表的region在regionserver01上的分割阈值为：min ( 9*9*128M=10.125G ,10G ) =》10G                     

            结论：
                当某个regionserver节点上持有某个表的region的个数达到9个时，分割阈值变为固定的10G
                此策略可以自动适应大表和小表                     

        1.x版本
            使用的是SteppingSplitPolicy控制region的分割阈值
          <property>
            <name>hbase.regionserver.region.split.policy</name>
            <value>org.apache.hadoop.hbase.regionserver.SteppingSplitPolicy</value>
            <description>
              A split policy determines when a region should be split. The various other split policies that
              are available currently are ConstantSizeRegionSplitPolicy, DisabledRegionSplitPolicy,
              DelimitedKeyPrefixRegionSplitPolicy, KeyPrefixRegionSplitPolicy etc.
            </description>
          </property>

        控制策略:
            某台regionserver节点上持有某个表的region个数为1个时=》分割阈值为hbase.hregion.memstore.flush.size*2=256M
            其他数量时=》分割阈值为固定的10G  

            可以避免0.96-0.98版本中 初期时表的region分割过于频繁的弊端  

        region在分割时不利因素
            对应的region短暂的offline
            消耗集群的资源