大数据 - Hbase
Hbase介绍
Hbase是一种分布式NoSql数据库，不支持sql作为查询语言。
- 强读写一致，但是不是最终一致性的数据存储，非常适合高速计算聚合。
- 自动分片，通过Region分散在集群中，当行数增长的时候Region也会自动切分和再分配。
- 支持自动故障转移。
- 底层基于HDFS实现存储层。
- 支持块缓存，布隆过滤器，可以高效的列查询优化。
Hbase架构
image.png
- Zookeeper作为分布式的协调，RegionServer会把自己的信息写入到zookeeper;
- Hdfs是hbase运行的底层文件系统；
- RegionServer 是数据节点，存储数据的；
- RegionServer要实时向Master报告信息，Master实时监控全局RegionServer运行情况，可以控制故障转移和Region的切分。
存储设计
在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的吞吐量。
-
WAL的配置
// 启用multiwal <property> <name>hbase.wal.provider</name> <value>multiwal</value> </property>
HFile
HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer 1GB也是常见的。
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数据模型设计
Hbase与关系型数据库对比
image.png
行健设计
关键部分，直接关系到后续服务的访问性能。如果行健设计不合理，后续查询服务效率会成倍的递减。
- 避免单调的递增行健，因为Hbase的行健是有序排列的，这样可能导致一段时间内大部分写入集中在某一个Region上进行操作，负载都在一台节点上。可以设计成： [metric_type][event_timestamp]，不同的metric_type可以将压力分散到不同的region上
- 行健短到可读即可，因为查询短键不必长键性能好多少，所以设计时要权衡长度。
行健不能改变，唯一可以改变的方式是先删除后插
列簇设计
列簇是一些列的集合，一个列簇的成员有相同的前缀，以冒号(:)作为分隔符。
- 现在Hbase不能很好处理2~3个以上的列簇，所以尽可能让列簇少一些，如果表有多个列簇，列簇A有100万行数据，列簇B有10亿行，那么列簇A会分散到很多的Region导致扫描列簇A的时候效率底下。
- 列簇名的长度要尽量小，一个为了节省空间，另外加快效率，比如d表示data，v表示value
网友评论