项目收获总结--大数据量存储架构设计方案
一、背景
公司的业务数据规模庞大,经过多年的业务积累和业务迭代,已经达到百亿级,各个业务线错综复杂,接口调用杂乱无章,而最近的项目是做智能营销推荐系统,需要海量数据计算画像和实时计算做智能产品推荐,但是数据分布和来源非常杂乱,出现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内部会处理。