需求: 将陌陌中聊天记录存储到hbase中, 并提供查询的方案

数据特点: 需要高并发写入操作, 读取操作较少 写多读少场景

hbase的名称空间, 可以将其理解为MySQL中数据库

思考: MySQL中为什么要有这个数据库概念, 有什么作用呢?

因为: 通过库将相关类型表放置在一起, 方便管理 可以基于库进行权限管理工作

同样, 对于hbase来讲, 也需要有类似这样功能, 这个时候, hbase推出 名称空间, 可以通过在hbase中构建多个名称空间, 将表放置在不同的名称空间下, 进行分别管理操作

注意:

如何操作hbase的名称空间:

1) 如何创建名称空间 格式: create_namespace '名称空间名称' 2) 如何查看名称空间 格式: 查看所有的名称空间: list_namespace 查看某一个名称空间: describe_namespace '名称空间名称' 3) 如何在指定的名称空间下, 创建表 格式: create '名称空间:表名' ,'列族1'... ​ 4) 如何删除名称空间 格式: drop_namespace '名称空间' 注意 如果对应空间下, 还有表, 是无法删除, 必须先删除表

能少则少, 能用一个解决的, 坚决不使用两个

官方建议: 一般列族的配置 不大于 5个 支持非常多

本次陌陌案例采用一个列族来解决: C1

版本设计: 是否需要存储历史变更记录, 或者说数据是否会有历史变更操作

思考: 陌陌案例聊天, 是否会存在变更呢? 不会发生变更, 所以版本设置为 1(默认即可)

由于数据 是写多 读少的场景, 基本上 90%以上都是写操作, 而且数据量非常的大, 希望能够在有限的空间下, 存储更多的数据, 此时可以选修压缩比最高的: GZIP(GZ)

如果 读的多, 而且数据量比较大, 可以采用 LZO 或者snappy

如何设置压缩方案

在创建表时指定压缩方案: create '表名' , {NAME='列族',COMPRESSION=>'压缩方案'} 给以及建好的表添加压缩方案: alter '表名' , {NAME='列族',COMPRESSION=>'压缩方案'} 案例: create 'MOMO_CHAT:MSG',{NAME=>'C1',COMPRESSION=>'GZ'}

默认情况下, 创建一个表 只有一个region,而一个region只能被一个regionServer所管理, 一个regionServer读写性能有限,而且hbase集群一般由一些廉价的服务器组建集群

如果此时需要对这个表进行大量的读写操作, 最终这些读写请求, 全部负载给某一个台regionServer上, 由于单台节点负载并不是特别高, 有可能会导致读写性能急剧下降, 甚至宕机的风险

请问如何解决呢? 如果这些并发请求, 能够负载到各个regionServer上, 问题就可以解决了,但是一个region依然无法办到

解决方案: 在建表的时候, 指定表的region的数量, 让其能够一次性预先的拥有多个region, 而多个region可以负载到各个regionServer上, 然后在进行读写操作的时候, 就可以将并发的请求落在各个regionServer上

而这种解决方案, 就是HBase的预分区 :

目的: 在建表直接产生多个region

hbase是通过对rowkey的范围, 对region进行划分, 每个region都会有起始的rowkey 和 结束rowkey表示这个region所存储数据范围, 在插入数据时候, 如果rowkey在某一个region的范围, 那么直接将数据插入到这个region中

默认情况下:   一个表只有一个region , name这个region的范围是什么呢? startkey: '' , endkey: '' ​ 如果我以 : 1, 2 ,3 ,4 5 划分一个个region, 请思考有几个region呢? 6 '' ~ 1 1 ~ 2 2 ~ 3 3 ~ 4 4 ~ 5 5 ~ ''

如何设置hbase的预分区呢?

方式一: 手动分区 格式: create '表名' ,'列族1'... , SPLITS=>['1','2','3','4','5'] 方式二: 通过读取一个外部的文件, 来划分region 格式: create '表名','列族1' ...., SPLITS_FILE => '文件路径' 方式三: hash 16进制 分区方案 create '表名' ,'列族名称1', .... , {NUMREGIONS=>N , SPLITALGO=>'HexStringSplit'}

本次陌陌案例, 将会采用 hash 16进制分区方案 : 分区的数量一般为regionServer数量的倍数 设置 6个

建表操作:

思考: 是否只需要设置预分区, 就一定可以保证让所有的数据都均匀落在不同region中呢? 不是的

官方rowkey的设置建议要求:

1) 避免使用递增行键/时序数据 当做rowkey的前缀 因为: 递增行键或者时序数据, 前面数字有可能是一成不变, 此时会出现数据热点问题(所有数据都跑到一个region中) 2) 避免rowkey和列的长度过大(长) 因为: 希望数据能够在内存中保留的越多, 读取的效率越高, 如果rowkey或者列设置比较长, 导致在有限内存中存储数据更小, 从而让数据提前的就flush磁盘上, 影响读取效率 建议: rowkey长度一般为 10~100字节左右 , 尽可能的越短越好 3) 使用Long类型比String类型更节省空间: 如果rowkey中都是数字, 建议使用Long获取其他数值类型 4) 保证rowkey的唯一性

如何避免热点问题:

1) 反转策略: 比如说可以将手机号 或者 时间戳等 这种前面一样但是后面会呈现随机的数据, 进行反转工作 就可以保证rowkey的前缀都不尽相同, 从而让数据能够落在不同的region中 2) 加盐策略: 给rowkey前缀添加固定长度的随机数 , 来保证让数据落在不同region中 3) hash取模: 给相同的数据加上同样的盐, 从而保证相关联的数据都在一起, 也可以保证数据落在笔筒region中

在陌陌案例中, 如何设计rowkey呢? 以查询作为参考点, 决定你的rowkey应该放什么数据

HASH(MD5加密)_发件人账户_收件人账户_时间戳 ​ 通过 HASH(MD5加密) 可以确保数据均匀落在不同region上, 同时也可以保证 同一对发件人和收件人都存储在一个region中

1) 在hbase中创建存储数据的表:

2) 创建maven项目,加载pom依赖:

3) 导入相关的配置文件 : log4j.properties 在 资料的 陌陌海量消息存储案例目录下

4) 创建相关的包结构:

5) 导入相关的工具类和实体类 : 在 资料的 陌陌海量消息存储案例目录下