【HBase——陌陌海量存储案例】1.案例介绍与HBase表结构设计（上）

前言

本系列接【HBase入门】系列文章后实战案例的学习。

学习目标

能够掌握HBase表结构设计（表设计、ROWKEY设计、预分区）
能够安装部署Apache Phoenix
能够掌握Phoenix的基本操作
能够掌握使用Phoenix建立二级索引提升性能
能够基于Phoenix JDBC API编写Java代码操作HBase

1. 案例介绍

在陌陌中，每天都有数千万的用户聊天消息需要存储。而且，这些消息都是需要进行大量地保存，而读取会少很多。想想：我们在使用微信的时候，大多数时候，我们都是在发消息，而不是每时每刻查询历史消息。要存储这样海量的数据，HBase就非常适合了，HBase本身也非常适合存储这种写多读少的应用场景。本案例，将结合陌陌聊天业务背景，以HBase来存储海量的数据。

通过本案例，我们能学习到以下知识点：

1. HBase表的设计——涵盖HBase表预分区、ROWKEY设计
2. HBase调优
3. 使用Apache Phoenix SQL查询引擎
4. 基于HBase的分页查询
5. 数据查询接口开发

2. 打招呼消息数据集介绍

字段名	说明
msg_time	消息时间
sender_nickyname	发件人昵称
sender_account	发件人账号
sender_sex	发件人性别
sender_ip	发件人IP
sender_os	发件人系统
sender_phone_type	发件人手机型号
sender_network	发件人网络制式
sender_gps	发件人GPS
receiver_nickyname	收件人昵称
receiver_ip	收件人IP
receiver_account	收件人账号
receiver_os	收件人系统
receiver_phone_type	收件人手机型号
receiver_network	收件人网络制式
receiver_gps	收件人GPS
receiver_sex	收件人性别
msg_type	消息类型
distance	双方距离
message	消息

3. 准备工作

创建IDEA Maven项目

groupId	cn.itcast
artifactId	momo_chat_app

在项目中创建存放hbase shell脚本目录
在项目下创建名为 hbase_shell 的目录，再创建一个 readme.md 文件。

readme.md中写入如下：

# 陌陌海量消息存储说明文档
## 1. 项目结构说明
* hbase_shell：用于存放hbase shell操作脚本
* momo_chat_app：Java API数据接口

创建脚本文件
在hbase_shell下创建名为 create_ns_table.rb 文件，用于编写Hbase相关脚本，并使用VSCode打开项目文件夹。

4. 陌陌消息HBase表结构设计

4.1 名称空间

说明

• 在一个项目中，需要使用HBase保存多张表，这些表会按照业务域来划分
• 为了方便管理，不同的业务域以名称空间（namespace)来划分，这样管理起来会更加容易
• 类似于Hive中的数据库，不同的数据库下可以放不同类型的表
• HBase默认的名称空间是「default」，默认情况下，创建表时表都将创建在 default 名称空间下
• HBase中还有一个命名空间「hbase」，用于存放系统的内建表（namespace、meta）
  语法
  1. 创建命名空间
     create_namespace 'MOMO_CHAT'
  2. 查看命名空间列表
     list_namespace
  3. 查看命名空间
     describe_namespace 'MOMO_CHAT'
  4. 命名空间创建表
     在命令MOMO_CHAT命名空间下创建名为：MSG的表，该表包含一个名为C1的列蔟。
     注意：带有命名空间的表，使用冒号将命名空间和表名连接到一起。
     create 'MOMO_CHAT:MSG','C1'
  5. 删除命名空间
     删除命名空间，命名空间中必须没有表，如果命名空间中有表，是无法删除的
     drop_namespace 'MOMO_CHAT'

4.2 列蔟设计

• HBase列蔟的数量应该越少越好
  • 两个及以上的列蔟HBase性能并不是很好
  • 一个列蔟所存储的数据达到flush的阈值时，表中所有列蔟将同时进行flush操作
  • 这将带来不必要的I/O开销，列蔟越多，对性能影响越大
• 本次项目中我们只设计一个列蔟：C1

4.3 版本设计

说明

此处，我们需要保存的历史聊天记录是不会更新的，一旦数据保存到HBase中，就不会再更新
无需考虑版本问题
本次项目中只保留一个版本即可，这样可以节省大量空间
HBase默认创建表的版本为1，故此处保持默认即可

查看表
通过以下输出可以看到：

版本是相对于列蔟而言
默认列蔟的版本数为1

hbase(main):015:0> describe "MOMO_CHAT:MSG"
Table MOMO_CHAT:MSG is ENABLED                                                                                                                                                                                                               
MOMO_CHAT:MSG                                                                                                                                                                                                                                
COLUMN FAMILIES DESCRIPTION                                                                                                                                                                                                                  
{NAME => 'C1', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLI
CATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}   

1 row(s)

4.4 数据压缩

压缩算法
在HBase可以使用多种压缩编码，包括LZO、SNAPPY、GZIP。只在硬盘压缩，内存中或者网络传输中没有压缩。

压缩算法	压缩后占比	压缩	解压缩
GZIP	13.4%	21 MB/s	118 MB/s
LZO	20.5%	135 MB/s	410 MB/s
Zippy/Snappy	22.2%	172 MB/s	409 MB/s

• GZIP的压缩率最高，但是其实CPU密集型的，对CPU的消耗比其他算法要多，压缩和解压速度也慢；
• LZO的压缩率居中，比GZIP要低一些，但是压缩和解压速度明显要比GZIP快很多，其中解压速度快的更多；
• Zippy/Snappy的压缩率最低，而压缩和解压速度要稍微比LZO要快一些

本案例采用GZ算法，这样可以确保的压缩比最大化，更加节省空间

查看表数据压缩方式
通过以下输出可以看出，HBase创建表默认是没有指定压缩算法的

hbase(main):015:0> describe "MOMO_CHAT:MSG"
Table MOMO_CHAT:MSG is ENABLED                                                                                                                                                                                                               
MOMO_CHAT:MSG                                                                                                                                                                                                                                
COLUMN FAMILIES DESCRIPTION                                                                                                                                                                                                                  
{NAME => 'C1', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLI
CATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}   

1 row(s)

设置数据压缩
本案例中，我们使用GZ压缩算法，语法如下：

• 创建新的表，并指定数据压缩算法
  create "MOMO_CHAT:MSG", {NAME => "C1", COMPRESSION => "GZ"}
• 修改已有的表，并指定数据压缩算法
  alter "MOMO_CHAT:MSG", {NAME => "C1", COMPRESSION => "GZ"}