走进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'...
  • 2. 插入数据：插入数据时需要指定表名、行键、列族、列和值。
    • put 'tableName', 'rowKey', 'columnFamily:column', 'value'
  • 3. 查询数据:查询数据时可以使用scan命令来遍历整个表，也可以使用get命令来获取指定行键的数据。
    • scan 'tableName'
    • get 'tableName', 'rowKey'
  • 4. 删除数据：删除数据时需要指定表名、行键和列族。如果要删除整个表，要先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中的行键是需要进行设计的。