项目收获总结--大数据量存储架构设计方案

一、背景

公司的业务数据规模庞大，经过多年的业务积累和业务迭代，已经达到百亿级，各个业务线错综复杂，接口调用杂乱无章，而最近的项目是做智能营销推荐系统，需要海量数据计算画像和实时计算做智能产品推荐，但是数据分布和来源非常杂乱，出现A向B要数据，B向C请求接口，C向A需求服务，各个业务线互相依赖的情况。由于项目需要设计一套数据中心来实现资源整合、数据的整合、形成统一的海量数据服务的效率提升方案。

二、数据存储层技术选型

解决大数据量的存储，并能实现大数据量秒级查询, 首先要进行数据存储层技术选型.，考虑四种方案。

2.1 MySQL

Mysql数据量到千万级别时，响应时间提高很多和吞吐量下降很多，需要分库分表或者分片。属于CA，同时满足一致性(C，Consistency)、可用性（A， Availability）。
不推荐MySQL。

2.2 MongoDB

MongoDB用于存储非结构化数据，极其擅长存储json格式的数据或一些很难建索引的文本数据。
MongoDB存储量约10亿级，数据量再大就需要另外分库，否则性能快速下降。
即是：MongoDB更擅长存储需要在线访问的NOSQL文档，并且通过索引，更善于做查询，更像传统的关系型数据库，存储能力弱。MongoDB属于CP，同时满足一致性(C，Consistency)、分区容错性(P，Partition Tolerance)。
而很多公司都不选用MongoDB因为一旦数据量过大，再去改结构很复杂。比如京东架构就把MongoDB用MySQL+Redis替代

2.3 HBase

构建在HDFS之上的分布式、面向列的NOSQL存储系统，可进行实时大规模数据集的读写操作，存储量可达百亿及以上，且对写入效率，hbase由于只维护一个主键，写入效率要比MongoDB这种要维护所有索引的数据库快得多；再考虑服务器的数量上，HBase占用两台机器能完成的事情，MongoDB要占用更多机器。总之现在很多公司都选用HBASE，更偏向非关系型数据库，扩展储存能力强。

但HBase的语法非常固化，擅长rowkey的快速查询，但不擅长模糊匹配查询（前模糊或全模糊），即便在HBase上装载phoneix，在处理复杂查询时，依旧改观不大。

2.4 HBase+ElasticSearch

考虑到若最开始数据存储在HBase上，当业务越来越复杂，数据量越来越大时，使用HBase构建复杂的查询很难实现，甚至导致很多指标无法完成，决定使用ElasticSearch架构在HBase之上。
海量的数据存储使用HBase，数据的即席查询（快速检索）使用ElasticSearch。架构如图：

三、HBase+ElasticSearch基本原理

将Elasticsearch的DOC ID和Hbase的rowkey相关联。
写数流程：数据接入时，创建统一且全局唯一的ID， 既当Elasticsearch的DOC ID， 也当Hbase的rowkey，数据先写入 HBase，再发送Kafka 消息， 异步写入ES。
取数流程：ES先根据条件查询到分页数据，或者是list里面封装的是那个所有实体类、然后遍历得到id（即拿到rowkey），再去查HBase抽取数据，然后封装Entity，最后返回List。

3.1 前置考虑

一批数据在ElasticSearch中构建索引的时候，针对每一个字段要分析是否存储和是否构建索引。这个需要根据元数据进行考虑和控制

3.2 HBase+ElasticSearch优点

将两个组件各自的优势组合起来：

• 发挥Elasticsearch全文检索的优势，能快速根据关键字检索出相关度最高的结果；
• 减少Elasticsearch的存储压力，这种场景下不需要存储检索无关的内容，甚至可以禁用_source，节约一半的存储空间，同时提升最少30%的写入速度；
• 避免Elasticsearch大数据量下查询返回慢的问题，大数据量下HBase的抽取速度明显优于Elasticsearch；
• HBase支持动态列，ES也支持动态列，ES可以做HBase的外置索引，整合很融洽。

3.3 HBase+ElasticSearch缺点

（1）组件间存在时效不一致问题

ElasticSearch的入库速度肯相对而言要快于HBase，这需要业务容忍一定的时效性，对业务的要求会比较高。

（2）增加两个组件管理成本

四、HBase+ElasticSearch数据一致性架构

HBase 和 ES 的数据一致性，有两种方案：

HBase + WAL + ES
HBase + Kafka + ES

4.1 HBase + WAL + ES 实现数据一致性

WAL(Write-Ahead Log)预写日志是一个保险机制。在HBase 将数据写入Memstore前就先写入WAL，若发生故障，Memstore内存存储得数据丢失后，也可通过WAL将丢失的数据恢复。

4.1.1 实现方案

设置 HBase 的 WAL 日志位置： 在 HBase 的配置文件 hbase-site.xml 中配置 WAL 日志路径。

<property>
  <name>hbase.regionserver.hlog.dir</name>
  <value>/hbase/wal</value>
</property>

编写 WAL 日志解析服务： 编写一个独立的服务，定期读取 WAL 日志文件，解析其中的写操作，并同步到 Elasticsearch。
同步到 Elasticsearch：在解析服务中，将提取的数据变更信息写入到 Elasticsearch。

4.1.2 缺陷

WAL层不太好控制和监控，
ES消费WAL的存在效率问题

4.2 HBase + kafka+ ES 实现数据一致性

在数据写完HBase之后，即对外响应Success，并异步将数据推至Kafak队列中等待ES去二次消费；写入ES失败则对外抛出异常，要保证写入HBase要么成功，要么失败。
在ES消费层，可以动态指定消费线程数量。当Kafka Lag堆积超过一定阈值（阈值可进行Group级调节和监控），会进行警报，并动态调整消费线程数。只保证数据最终一致性。
当数据写入HBase成功之后，会对写Kafka和写ES进行链路追踪，任何一个环节出现写入失败，就将Failed Key存入Redis，对于失败的数据，开启定时调度线程去扫描这些Key并进行自动回补索引。
回补方式是：到HBase中拿最新的数据再次写入队列中去。
若再次失败，再把这些Key存入Redis，再通过定时调度线程去扫描这些再次失败得数据，若有数据就认为清理。流程图如下：

五、HBase集群间数据同步replication

正常而言，中小型公司一个HBase应当够用，若HBase需要集群，则有数据同步得需要。
HBase 的复制机制基于 WAL（Write-Ahead Log）。当数据写入到主集群（Master Cluster）时，写操作首先被记录到 WAL 中，然后这些 WAL 日志被传输到从集群（Slave Cluster），从集群再根据这些日志进行数据重放，从而实现数据同步。
HBase中的Replication指的是主备集群间的复制，用于将主集群的写入记录复制到备集群。HBase目前共支持3种Replication：

异步Replication
串行Replication
同步Replication

我采用的是第一种：异步Replication
架构图：

HBase的replication是以Column Family（列族）为单位的，每个Column Family都可以设置是否进行replication。
一个Master对应3个Slave，Master上每个RegionServer都有一份HLog，在开启Replication的情况下，每个RegionServer都会开启一个线程用于读取该RegionServer上的HLog，并且发送到各个Slave，Zookeeper用于保存当前已经发送的HLog的位置。
Master与Slave之间采用异步通信的方式，保障Master上的性能不会受到Slave的影响。
用Zookeeper保存已经发送HLog的位置，主要考虑在Slave复制过程中如果出现问题后重新建立复制，可以找到上次复制的位置。

HBase Replication步骤：

1. HBase Client向Master写入数据
2. 对应RegionServer写完HLog后返回Client请求
3. 同时replication线程轮询HLog发现有新的数据，发送给Slave
4. Slave处理完数据后返回给Master
5. Master收到Slave的返回信息，在Zookeeper中标记已经发送到Slave的HLog位置

PS：在进行replication时，Master与Slave的配置并不一定相同，比如Master上可以有3台RegionServer，Slave上并不一定是3台，Slave上的RegionServer数量可以不一样，数据如何分布这个HBase内部会处理。