走进HBase - 技术栈

什么是Hbase
- 建立在Hadoop之上HDFS分布式文件系统，面向列的存储系统
- 列式数据库是针对行数据库而言的，行式数据库是以一行数据作为一个存储单元，而列式数据库是以一列数据为一个存储单元，针对HBase来说，一行数据的某一个列值就是一个存储单元
- HBase表中的字段是可以动态增加的，因此HBase数据库是NoSQL数据库
优缺点
- 优点
  - HDFS有高容错，高扩展的特点，而Hbase基于HDFS实现数据的存储，因此Hbase拥有与生俱来的超强的扩展性和吞吐量。
  - HBase采用的是Key/Value的存储方式，这意味着，即便面临海量数据的增长，也几乎不会导致查询性能下降。
  - HBase是一个列式数据库，相对于于传统的行式数据库而言。当你的单张表字段很多的时候，可以将相同的列(以regin为单位)存在到不同的服务实例上，分散负载压力。
- 缺点
  - 架构设计复杂，且使用HDFS作为分布式存储，因此只是存储少量数据，它也不会很快。在大数据量时，它慢的不会很明显
  - Hbase不支持表的关联操作，因此数据分析是HBase的弱项
  - Hbase部分支持了ACID
HBaseACID性质
- 原子性：所有对于一个HBase行的操作都是原子的，也即在HBase的table中加入，更新一行要不成功要不失败，不会部分成功部分失败。特别说明的是，如果客户端（API）操作超时的话，该操作也是全部成功或全部失败，不会有部分成功的情况出现。这个是HBase在行上的原子操作的保证。但是跨多行的批量操作是不能保证原子性的。
- 一致性：HBase虽然是一个分布式数据库，但它的数据存储格式是按照Key-Value进行的，因此，它的数据存储的一致性也是Key-Value形式。
- 隔离性：HBase中的数据以列簇的形式进行存储，一个列簇可以跨多个行，因此，HBase的隔离级别是行级别。
- 持久性：一旦事务提交，则其结果永久保存在数据库中，即使系统崩溃也不应该丢失。
应用场景
- 海量数据存储：HBase可以处理PB级别（1024Tb）的数据量，适合于存储大规模的数据，例如日志数据、监控数据、交易数据等。
- 低延迟读写： HBase支持高效的随机读写操作，可以在毫秒级别内完成数据访问，适合于需要实时访问和查询数据的场景。
- 高并发读写： HBase可以支持大量的并发读写操作，可以处理数百万级别的并发访问请求，适合于需要处理高并发访问的场景。
系统架构组件
- HMaster：是HBase集群的主节点，负责整个集群的管理工作，主要工作职责如下：分配Region；负载均衡；维护集群的元数据信息和负载均衡。
- RegionServer：真正"干活"的节点。
- HBase Client：为用户提供了访问HBase的接口，可以通过元数据表来定位到目标数据的RegionServer，另外HBase Client还维护了对应的cache来加速HBase的访问，比如缓存元数据的信息。
- Zookeeper：保存HMaster的地址和backup-master地址，能保证集群中只有1个master在运行。监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master。
- HDFS：多副本底层数据存储服务
- 俗语：Hbase中的老大叫Hmaster，小弟叫RegionServer，客户端叫Client，Zookeepr为hbase提供集群协调。
HBase原理组件
- Region： HBase表中的数据按照行键的字典顺序排序，HBase表中的数据按照行的方向切分为多个Region，最开始只有一个Region，随着数据量的增加，产生分裂，这个过程不断进行，一个表可能对应一个或多个Region，一个表的多个Region可能分布在多台HRegionServer上
- Store:region是分布式存储的基本单元，但不是存储的基本单元，其内部还具有结构。一个region由多个Store来组成。有几个store取决于表的列族的数量，一个列族对应一个store。之所以这么设计，是因为一个列族中的数据往往数据很类似，方便进行压缩，节省存储空间。
- memStore:表的一个列族对应一个store，store的数量由表中列族的数量来决定。一个store由一个memstore和零个或多个storefile组成。memStore负责保存内存中的数据
- storefile:storefile其实就是hdfs中的hfile只能写入不能修改，所以hbase写入数据到hdfs的过程其实是不断追加hfile的过程。
基本概念
- 表（Table）：HBase在逻辑上是个二维的稀疏映射，这个映射的键（Key）是行健（Row Key），值（Value）是一个列族（Column Family）的映射。
- 行（Row）：在HBase中，表按照行进行数据的存储和管理，每个行由一个唯一的行健（Row Key）标识。
- 列族（Column Family）：列族是HBase中列的集合，每个列都属于一个特定的列族。
- 列（Column）：列由列族和列限定符（Qualifier）组成，用于标识表中的数据。
- 单元格（Cell）：单元格是HBase中存储数据的最小单位，每个单元格都保存了一个特定版本的数据。
- 版本（Version）：每个单元格保存了同一行、同一列、同一时间的数据，也就是所谓的同一数据的不同版本。
- 与nosql数据库一样，row key是用来表示唯一一行记录的主键，HBase的数据时按照RowKey的字典顺序进行全局排序的，所有的查询都只能依赖于这一个排序维度
常踩的坑
- HBase写操作尽量采用批量写入操作。由于HBase的存储是按照字典顺序排序的，某一时刻相似规则的数据会落入同一个region上，造成数据热点，所以HBase写操作尽量采用批量写入操作。
- 禁用预写日志。由于历史数据的消费过程是将数据写入HBase，但写入HBase过慢，容易造成消费不过来，产生数据堆积，影响Kafka拉取数据消费发送心跳的超时，所以禁用预写日志。
HFile
- 结构
  - Data Block段--保存表中的数据，这部分可以被压缩
  - Meta Block 段(可选的)--保存用户自定义的kv对，可以被压缩。
  - File Info段--Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
  - Data Block Index段--Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
  - Meta Block Index段(可选的)--Meta Block的索引。
  - Trailer--这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰
- 压缩方式
  - GZip
  - Lzo
语法
- 查看Hbase的版本：hbase version。
- 列出表的信息：list 'tableName'。
- 获取表中的一条数据：get 'tableName', 'rowkey'。
- 查询所有的表：list。
- 退出Hbase：quit。
- 进入Hbase：hbase shell。
- 停止Hb：.quit。
使用
- 1. 创建表：创建表时需要指定表名和列族名。HBase的表是由一个或多个列族组成的，每个列族包含一个或多个列。
  - create 'tableName', 'columnFamily1', 'columnFamily2'...
- 1. 插入数据：插入数据时需要指定表名、行键、列族、列和值。
  - put 'tableName', 'rowKey', 'columnFamily:column', 'value'
- 1. 查询数据:查询数据时可以使用scan命令来遍历整个表，也可以使用get命令来获取指定行键的数据。
  - scan 'tableName'
  - get 'tableName', 'rowKey'
- 1. 删除数据：删除数据时需要指定表名、行键和列族。如果要删除整个表，要先disable（禁用）和drop（删除）命令。
  - delete 'tableName', 'rowKey', 'columnFamily:column'
  - disable 'tableName'
  - drop 'tableName'
存储系统三种结构
- hash存储
  - 哈希存储引擎是哈希表的持久化实现，支持增、删、改以及随机读取操作，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作O(n)快，如果不需要有序的遍历数据，哈希表就是your Mr.Right。
- B树
  - B树存储引擎是B树的持久化实现，支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。
- LSM树
  - LSM树（Log-Structured Merge Tree）存储引擎和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。
总结
- HBase快的原因
  - 逻辑上
    - 表按照行键进行了排序，而且加了索引，所以查询时可以很快定位。
    - 数据按照行键切分为多个HRegion，分布在多个RegionServer中，查询大量数据时，多个RegionServer可以一起工作，从而提高速度。
  - 物理上
    - HRegion是存活在RegionServer的内存中的，读写会非常的高效。
    - 还有HFile的支持保证大量的数据可以持久化的保存。
    - 数据最终落地到HDFS中，分布式的存储，保证数据段可靠性和可扩展性。
- HBase存储很多数据
  - 基于hdfs，所以支持可扩展性，可以通过增加大量的廉价的硬件提高存储容量（不需要考虑性能的廉价硬件）
  - 按列存储，空的数据不占用空间，当存储稀疏数据时，不会浪费空间。
  - 按例存储，同一列的数据存放在一起，而同一列的数据一般都是同样的类型的内容相似的数据，可以实现非常高效的压缩，节省空间。
- Hbase的数据是可靠
  - 基于hdfs，由hdfs的可靠性保证了hbase的可靠性，即数据可以有多个备份。（即使HBase挂了，数据也还在，因为数据最终落到hadoop的HDFS文件系统中）
  - 利用zookeeper实现了HA（高可用集群），即使某一台机器挂掉另外的机器也可以很快的替换它。
- HBase的表设计
  - HBase表的设计会直接影响hbase使用的效率和使用的便利性。
  - HBase表的设计主要是列族的设计和行键的设计。
    - 列族
      - 1.列族不宜过多，越少越好，官方推荐hbase表的列族不宜超过3个。列族设计过多，会非常消耗内存。
      - 2.经常要在一起查询的数据最好放在一个列族中，尽量的减少跨列族的数据访问。
      - 3.如果有多个列族，多个列族中的数据应该设计的比较均匀。
    - 行键
      - hbase表中行键是唯一标识一个表中行的字段，所以行键设计的好不好将会直接影响未来对hbase的查询的性能和查询的便利性，所以hbase中的行键是需要进行设计的。