HBase记录（一）

国内其实挺多关于hbase的知识，都比较零散，所以借此来做个整理和试验记录

入门Hbase

特性

Hbase是一种NoSQL数据库（DB），这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库。从技术的角度来看，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待。Hbase都有什么特性呢？

• 强读写一致，并不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合
• 自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配
• 自动的故障转移
• Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接
• 丰富的 “简洁，高效” API，Thrift/REST API，Java API
• 块缓存，布隆过滤器，可以进行高效的列查询优化
• 操作管理，Hbase提供了内置的web界面来操作，还可以监控JMX指标

Hbase适用场景？

• 首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态
• 其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。
• 最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。

Hbase在单机环境也能运行，但是请在开发环境的时候使用。

内部应用

• 存储业务数据:GPS信息，点位信息，操作信息，访问信息等等
• 存储日志数据:架构监控数据（登录日志，中间件访问日志，推送日志，短信邮件发送记录诸如此类的操作日志信息），业务操作日志信息
• 存储业务附件：UDFS系统存储图像，视频，文档等附件信息

Hbase架构

• Zookeeper，作为分布式的协调。RegionServer也会将自己的数据写入到ZooKeeper中。
• HDFS是Hbase运行的底层文件系统
• RegionServer，理解为数据节点，存储数据的。
• Master RegionServer要实时的向Master报告信息。Master知道全局的RegionServer运行情况，可以控制RegionServer的故障转移和Region的切分。

架构细化

• HMaster是Master Server的实现，负责监控集群中的RegionServer实例，同时是所有metadata改变的接口，在集群中，通常运行在NameNode上面

  • HMasterInterface暴露的接口，Table(createTable, modifyTable, removeTable, enable, disable),ColumnFamily (addColumn, modifyColumn, removeColumn),Region (move, assign, unassign)

  • Master运行的后台线程：LoadBalancer线程，控制region来平衡集群的负载。CatalogJanitor线程，周期性的检查hbase:meta表。

• HRegionServer是RegionServer的实现，服务和管理Regions，集群中RegionServer运行在DataNode

  • HRegionRegionInterface暴露接口：Data (get, put, delete, next, etc.)，Region (splitRegion, compactRegion, etc.)

  • RegionServer后台线程：CompactSplitThread，MajorCompactionChecker，MemStoreFlusher，LogRoller

• Regions，代表table，Region有多个Store(列簇)，Store有一个Memstore和多个StoreFiles(HFiles)，StoreFiles的底层是Block。

存储设计

在Hbase中，表被分割成多个更小的块然后分散的存储在不同的服务器上，这些小块叫做Regions，存放Regions的地方叫做RegionServer。Master进程负责处理不同的RegionServer之间的Region的分发。在Hbase实现中HRegionServer和HRegion类代表RegionServer和Region。HRegionServer除了包含一些HRegions之外，还处理两种类型的文件用于数据存储

• HLog， 预写日志文件，也叫做WAL(write-ahead log)
• HFile 真实的数据存储文件

HLog

• MasterProcWAL：HMaster记录管理操作，比如解决冲突的服务器，表创建和其它DDLs等操作到它的WAL文件中，这个WALs存储在MasterProcWALs目录下，它不像RegionServer的WALs，HMaster的WAL也支持弹性操作，就是如果Master服务器挂了，其它的Master接管的时候继续操作这个文件。

• WAL记录所有的Hbase数据改变，如果一个RegionServer在MemStore进行FLush的时候挂掉了，WAL可以保证数据的改变被应用到。如果写WAL失败了，那么修改数据的完整操作就是失败的。

  • 通常情况，每个RegionServer只有一个WAL实例。在2.0之前，WAL的实现叫做HLog
  • WAL位于/hbase/WALs/目录下
  • MultiWAL: 如果每个RegionServer只有一个WAL，由于HDFS必须是连续的，导致必须写WAL连续的，然后出现性能问题。MultiWAL可以让RegionServer同时写多个WAL并行的，通过HDFS底层的多管道，最终提升总的吞吐量，但是不会提升单个Region的吞吐量。

HFile

HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer 1GB也是常见的。
探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。

Hfile生成方式

起初，HFile中并没有任何Block，数据还存在于MemStore中。

Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。

而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：

注：如果配置了Data Block Encoding，则会在Append KeyValue的时候进行同步编码，编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。

读写简单流程

Hbase数据模型

在Hbase中，有一些术语需要提前了解。如下：

• Table：Hbase的table由多个行组成
• Row：一个行在Hbase中由一个或多个有值的列组成。Row按照字母进行排序，因此行健的设计非常重要。这种设计方式可以让有关系的行非常的近，通常行健的设计是网站的域名反转，比如(org.apache.www, org.apache.mail, org.apache.jira)，这样的话所有的Apache的域名就很接近。
• Column：列由列簇加上列的标识组成，一般是“列簇：列标识”，创建表的时候不用指定列标识
• Column Family：列簇在物理上包含了许多的列与列的值，每个列簇都有一些存储的属性可配置。例如是否使用缓存，压缩类型，存储版本数等。在表中，每一行都有相同的列簇，尽管有些列簇什么东西也没有存。
• Column Qualifier：列簇的限定词，理解为列的唯一标识。但是列标识是可以改变的，因此每一行可能有不同的列标识
• Cell：Cell是由row，column family,column qualifier包含时间戳与值组成的，一般表达某个值的版本
• Timestamp：时间戳一般写在value的旁边，代表某个值的版本号，默认的时间戳是你写入数据的那一刻，但是你也可以在写入数据的时候指定不同的时间戳

HBase 是一个稀疏的、分布式、持久、多维、排序的映射，它以行键（row key），列键（column key）和时间戳（timestamp）为索引。

Hbase在存储数据的时候，有两个SortedMap，首先按照rowkey进行字典排序，然后再对Column进行字典排序。

Hbase和关系型数据库进行对比

属性	Hbase	RDBMS
数据类型	只有字符串	丰富的数据类型
数据操作	增删查改	各种各样的函数与表连接
存储模式	基于列式存储，不支持json	基于表结构和行式存储
数据保护	更新后仍然保留旧版本	替换
可伸缩性	轻易增加节点	需要中间层，牺牲性能

Hbase设计时要考虑的因素

Hbase关键概念：表，rowkey，列簇，时间戳

• 这个表应该有多少列簇
• 列簇使用什么数据
• 每个列簇有有多少列
• 列名是什么，尽管列名不必在建表时定义，但读写数据是要知道的
• 单元应该存放什么数据
• 每个单元存储多少时间版本
• 行健(rowKey)结构是什么，应该包含什么信息

设计要点

行键设计

关键部分，直接关系到后续服务的访问性能。如果行健设计不合理，后续查询服务效率会成倍的递减。

• 避免单调的递增行健，因为Hbase的行健是有序排列的，这样可能导致一段时间内大部分写入集中在某一个Region上进行操作，负载都在一台节点上。可以设计成： [metric_type][event_timestamp]，不同的metric_type可以将压力分散到不同的region上
• 行健短到可读即可，因为查询短键不必长键性能好多少，所以设计时要权衡长度。
• 行健不能改变，唯一可以改变的方式是先删除后插入

列簇设计

列簇是一些列的集合，一个列簇的成员有相同的前缀，以冒号（：）作为分隔符。

• 现在Hbase不能很好处理2~3个以上的列簇，所以尽可能让列簇少一些，如果表有多个列簇，列簇A有100万行数据，列簇B有10亿行，那么列簇A会分散到很多的Region导致扫描列簇A的时候效率底下。
• 列簇名的长度要尽量小，一个为了节省空间，另外加快效率，比如d表示data，v表示value

列簇属性配置

• HFile数据块，默认是64KB，数据库的大小影响数据块索引的大小。数据块大的话一次加载进内存的数据越多，扫描查询效果越好。但是数据块小的话，随机查询性能更好

> create 'mytable',{NAME => 'cf1', BLOCKSIZE => '65536'}

• 数据块缓存，数据块缓存默认是打开的，如果一些比较少访问的数据可以选择关闭缓存

> create 'mytable',{NAME => 'cf1', BLOCKCACHE => 'FALSE'}

• 数据压缩，压缩会提高磁盘利用率，但是会增加CPU的负载，看情况进行控制

> create 'mytable',{NAME => 'cf1', COMPRESSION => 'SNAPPY'}

Hbase表设计是和需求相关的，但是遵守表设计的一些硬性指标对性能的提升还是很有帮助的，这里整理了一些设计时用到的要点。

这里只写简介，具体的配置方案就不多提了