基于Hbase与Phoenix的联机实时大数据查询
一、基本概念
诸如历史消息查询、历史记录查询等，当数据量变得超过数百万数千万乃至上亿级别，关系型数据库必然要走向sharding，
但具体的sharding方案往往绑定着一些列的业务和产品设计，比如特定的用户查询方式，如何设计sharding键等等。
本文试图探讨从另一种技术栈也就是nosql来解决大数据量查询与存储的问题，并比较传统关系型数据库与nosql在实践中各自的优势。
Hbase底层存储基于hadoop的hdfs，使用zk作为分布式协调的分布式nosql数据库。facebook用hbase来作为其消息数据库。
Phoenix是针对Hbase的sql解析引擎，相对于hive，凤凰专用于hbase，拥有更好的优化性能。phoenix支持jdbc协议。
二、软件架构
用springboot做基本架构，HirakiCP连接池来封装phoenix jdbc connection来连接hbase
三、关于HBase表的设计
HBase的表的查询都是从一个Rowkey出发，只能做基于Rowkey的精准查询、范围查询和全表扫描。实践中一般是用Rowkey + 1、2个列族来设计表。
举个列子：比如要存储上亿的订单数据、以及十亿级别的订单明细数据（1个订单会有多个商品的购买）。
如果数据量级不大，比如百万或以下级别，真没必要用HBase了，MySQL足够用且查询功能更丰富一些。
MySQL表：
订单表：订单ID，金额，用户ID，订单时间，店铺ID等
订单明细表：订单明细ID，商品ID，金额，订单ID等
实际使用可能是1、根据订单ID查订单基本信息，2、根据订单ID查订单明细，3、根据用户ID查其订单等等
那么对应到HBase表，可以这么设计：
订单表
Rowkey: 订单ID , CF1：订单信息、里边包括订单基本信息的列（金额，用户ID，订单时间，店铺ID）， CF2：订单明细表的IDs
订单明细表
Rowkey:订单明细ID，CF1：订单明细表的信息，里边包括订单明细表的列（商品ID，金额，订单ID）
查询使用，根据Rowkey订单ID查订单表、可以获得订单信息以及该订单下的明细ID，根据Rowkey订单明细ID可以查询该明细的商品ID，金额，订单ID
如果要根据用户ID获得其订单数据和明细，那还需要再建立一张用户与订单的关联表：
Rowkey：用户ID + 订单ID + 时间, CF1：订单基本信息。对Rowkey做scan即可。
HBase的Rowkey是顺序排列的，然后为了使得Rowkey的分布具有离散性，能够比较均匀的分布在各个Region上，一般会对Rowkey加个hash，或者做Reverse反转，使得其具有无规则随机性。
参考：
NoSQL 的选择 -- Redis、MongoDB、Cassandra 与 HBase 的介绍与比较 : https://techlog.cn/article/list/10182729
入门HBase，看这一篇就够了： https://www.jianshu.com/p/b23800d9b227
Hbase Phoenix简介及其安装部署： https://www.cnblogs.com/Transkai/p/11241548.html
大数据查询——HBase读写设计与实践： https://cloud.tencent.com/developer/article/1032875
Spring Boot 整合Hive/Phoenix数据源： https://blog.csdn.net/weixin_44327656/article/details/89947411
分库分表技术演进暨最佳实践 - 简书 (jianshu.com)
