HBase数仓架构
1.整体架构
选型主要有两个，第一个是实时，实时采集利用 Maxwell，直接采集公司数据库 MySQL，将数据直接以 json 格式发送到 Kafka 集群，数仓存储选型是 HBase。
上图是实时数仓架构图，主要的存储层还是以 HBase 为主。第一层业务系统数据库在Mysql上。使用 Maxwell，其支持白名单和黑名单。业务平台的表可能有两三百个，大数据平台的计算可能只需要 100 多个，可以添加白名单，有些表的数据就可以不用过来了。这些数据通过 Json 发送到 Kafka，然后通过 Spark Streaming 去消费 Kafka，通过 JDBC 写入 HBase。(性能不低，现在我们生产上有反压机制控制，3S 一个批次可以写最大 6W 数据，批次不堆积，不会有雪崩效应。要考虑数据获取，处理，写出去，所以 3S 是一个经典经验值。)
表是通过 Phoenix SQL 语句创建，我们真正不关心底层 HBase。就像操作 MySQL 一样即可。同时会将计算结果存储到 Redis(公司实时大屏)，也会将数据写入 ES 里面。中间一层就是业务开发，如 SparkStreaming、SparkSQl(现在也有 Flink)，也用 Python 做分析挖掘。调度平台起先用的是 Azkaban，然后 Airflow。也用到 zeppelin，这是 Spark 交互式开发必须用到的。
接下来讲一下数据仓库，首先是模型建设，第一层是基础表，在 Phoenix 中建立与 MySQL 一样的表。在基础表的基础上构建事实表（业务事实发生的表）和维度表（如中国有多少省多少市等更新不是很大的表），依据事实表和维度表进行代开发，构建领域表，就是依据业务需求得出的结果存到领域表。
2.Maxwell
为什么选择 Maxwell 呢？
- 它能够使用“select * from Table”进行 bootstrapping 初始化数据，在大数据构建时可以利用 Maxwell 进行全表扫描，这句 SQL 会自动触发 Maxwell 某个线程进行数据拉取，将表的历史数据全部刷新过去。
- Maxwell 支持断点还原功能，大数据平台架构不光考虑到高可靠、高性能，也要保证数据零丢失，它支持 MySQL 的 binlog 文件的 pos 点记录进行数据还原，这是当初选择最重要的原因。
- Maxwell 将数据从 MySQL 发送到 Kafka，Kafka 是分区的，如何保证全局有序是个问题。
它能保证这个特性，参数支持 database, table, primary key, or column 选择，
将数据按照参数选择发送到某个分区。
比如一条业务数据在业务系统先做 insert 再做 update 再做 delete 记录，Kafka 会将这三条 binlog 数据发送到三个分区，key 值为空，在使用 SparkStreaming 消费时可能会以 delete、update、insert 顺序，会造成数据紊乱。我们希望将这些特征数据发送到 Kafka 一个分区，而 Kafka 每个分区本身就是支持有序的。生产上，我们选择 primary key。 - 当业务数据的表结构需要升级，如加索引、加字段，可以通过 Maxwell 捕获到 alert 语句进行解析，同步更新到 Phoenix 表 (HBase) 中。
基于这四点主要特性需求，选择了 Maxwell，没有选择当前其他开源产品。
3.HBase
接下来讲一下为什么选择 HBase 而不选择其他大数据组件？
- HBase 是分布式；
- 随机的读和写；
- HBase 支持百万列。
4.Phoenix
- HBase 进行 put 数据，scan 查询、代码开发比较吃力，不优雅，而 Phoenix 是支持 SQL。
- 我们构建的表是盐表，能够解决热点问题，避免一个节点很繁忙另一个节点很闲。
- Phoenix 支持二级索引，由于表是盐表（分区），索引也是分区的。
- 支持 Spark，有效的 ETL 敏捷开发。
基于这四点主要特性需求，选择了 Phoenix，而不用专注于底层 HBase，当成黑盒。(当然底层的 Linux、HDFS、HBase 也需要调优，稳定)
5.常规开发场景
接下来是一个经典开发案例 Kafka+Spark Streaming+Phoenix，Phoenix 可以理解为 MySQL 架包的 JDBC。我们并没有使用 Phoenix 的 Pool 池，官方也推荐使用正常 JDBC 文件，因为 JDBC 已经支持长连接，Kafka 接收过来数据是 Json 格式，将其转化为 Phoenix 的 upsert 语法和 delete 语法，完成后就将连接关闭。（这个场景是做数据实时同步。当然也可以在 foreachPartition 进行常规数据 ETL 处理，这里不过多叙述）
大数据平台是通过 bootstrapping 的全表扫描，其增量数据也是实时进入。业务代码开发首先将 client jar 包配置在 pom 文件。Phoenix+Spark 读取有好几种，选择以上写法原因有：首先其支持列裁剪，第二支持 where 条件，configuration 指的是 Spark 的 HDFS 的 conf。
业务开发是多张表，Spark+Phoenix 转成 df，接下来就和 Phoenix 和 HBase 无关。接下来就是对接 Spark 业务开发逻辑处理，最后结果集会回写到 HBase，还是通过 Phoenix 写入，使用 overwrite。HBase 没有很好地可视化工具，我们直接利用 DBeaver 工具，进行表及数据的各种建表、查询等操作来。
6.Hive数仓跟HBase数仓优劣
1.Hive
优势
- 操作接口采用类SQL语法也就是HQL，提供快速开发的能力(简单、容易上手)；
- 避免了去写MapReduce，减少开发人员的学习成本；
- 统一的元数据管理，可与impala/spark等共享元数据；
- 易扩展(HDFS+MapReduce：可以扩展集群规模；支持自定义函数)；
劣势
- 对update、delete这种操作的支持性不强，需要转换成别的方式进行
- 索引的支持性不高
2.HBase
优势
- 随机的读和写；
- HBase 支持百万列;
- 对索引 二级索引的支持性好；
- 数据的多版本；
- 天然的幂等性；
劣势
- 不支持SQL操作，需要借助Phoenix组件
- 热点问题，需要开发人员自己对RK进行设计，使用Phoenix的盐表可以忽略这个问题。
- HBase在连接时的调优跟GC的调优问题