海量数据的存储技术方案和应用实践.docx
《海量数据的存储技术方案和应用实践.docx》由会员分享，可在线阅读，更多相关《海量数据的存储技术方案和应用实践.docx（11页珍藏版）》请在冰豆网上搜索。
海量数据的存储技术方案和应用实践
海量数据的存储技术方案和应用实践
NoSQL+集群流批+PG集群+内存缓存
【导读】某机构原采用的Oracle的RAC作为数据存储，随着业务量和数据量的增大，对于系统的稳定性和扩展性造成了极大的问题。
现在采用Postgres集群+Redis内存数据库+Druid实时分析数据库+Hbase列式数据库+HDFS+Kafka消息队列；辅以Minio分布式文件存储实现的，目前使用效果良好。
本文介绍了整合建设的初期存在的技术痛点和建设实践经验，希望可以为大家提供参考借鉴。
一、项目建设背景
随着大数据、云计算、移动互联迅速发展，快速交付与灵活扩展的强烈需求增长，传统竖井式的IT基础架构设施面临着新的挑战。
一方面快速增长的互联网业务需要灵活的、可自由伸缩、不限于规格容量的存储的IT软硬件资源提供坚实基础保障，另一方面高效的业务响应同传统的IT基础设施发展矛盾也日益突出。
例不可预估的互联网业务客户量、持续增长的日交易量、重要时期的高峰的运行压力、大量并发IO读写，系统响应缓慢，关键指标时效性不足，而这些性能痛点最先反映在数据存储IO上。
因此如何全面规划和整合当前IT基础架构中的数据存储体系，构建灵活、高效、先进的高可用存储架构，实现可满足生产系统的高并发、低延时的性能需求，是金融机构IDCIT信息化建设的迫切要求。
二、高性能高并发的数据存储建设痛点
随着信息大数据时代的来临，对信息收集的需求越来越高，在原来客户交易信息留存的基础上，增加了客户的行为及客户的属性等信息。
对于一个大型的应用系统，海量数据的存储和访问成为了系统设计的瓶颈问题。
我机构原先系统采用的是Oracle的RAC作为数据存储，随着业务量和数据量的增大，对于系统的稳定性和扩展性造成了极大的问题。
现在采用Postgres集群+Redis内存数据库+Druid实时分析数据库+Hbase列式数据库+HDFS+Kafka消息队列；辅以Minio分布式文件存储实现的，目前使用效果良好，但在整合建设的初期，是存在许多技术痛点的。
1、是否坚持所有数据一致性原则
传统的项目，几乎清一色的使用传统的关系型数据库（RDBMS）。
从早期的MySQL、SQLServer到后期的Informix、Db2、Oracle再到OracleRAC。
关系型数据库是强事物一致性（ACID），使用比较早，技术相对成熟。
ACID它的核心是“约束”，而这个“约束”由数据库的使用者告诉数据库，使用者要求数据一定是符合这样或者那样的约束条件。
当数据发生修改时，数据库会检查数据是否还符合约束条件，如果约束条件不再被满足，那么修改操作不会发生。
关系数据库最常见的两类约束是“唯一性约束”和“完整性约束”，表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复，表格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。
当数据库系统从批量处理进化到在线实时系统后，事务就可以并发地在数据库上进行操作，在给使用者带来便利的同时也给数据库系统开发人员带来了诸多困难。
严肃的数据库系统都会有一套复杂的并发控制机制来保证事务并行执行时数据的正确性。
而事务隔离性最大的烦恼来自并发控制对性能的影响，最严格的隔离性保证了所有的事务虽然是并发执行，但是最终执行的结果跟事务一个个串行着做是一样的，可串行化保证了一定不会因为并发进行的事务导致数据出错，但是这也会导致事务有更多等待或者失败。
在进入大数据时代后，超高的并发访问量以及海量的数据，注定使用ACID的原则将使得系统需要一个性能极高的计算器进行运算。
无疑这给系统带来了巨大开销浪费。
原本单位使用的是Oracle的RAC，但是在越来越多的数据存储和更多的访问并发，单点IO吞吐量的制约效果，越来越明显。
当关系型数据库越来越成为瓶颈时，为解决单点瓶颈，适当采取牺牲CAP属性中的C，也不失为一个可选的策略。
早期的系统调研中，有的场景对于实时性一致性要求高，但是每次操作的数据量不大。
而在其他的常见中，每次操作的数据量较大，但是对于数据的实时一致性没有过高的要求。
基于此，对于数据存储的选型，要区别对待。
对于前后数据需要一致性的，依旧采用关系型数据库，用数据库事务来保证数据的ACID一致性要求。
对于并发访问量高，但是数据的时效性和对比关联性不是很强的场景，我们采用分布式数据存储来应对。
经过多次选型调研，最终选择了Postgres数据库作为关系型数据库的载体，用于ACID的场景。
使用NoSQL的数据存储作为高并发访问的场景的数据存储。
2、非关系型数据库选型
市面常见的NoSQL包括Redis、Durid、Hbase、MongoDB、Hive等。
对于不同应用场景的选择是不同的。
MongoDB表结构灵活可变，字段类型可以随时修改。
记录以Json格式后存储，不需要定义表结构。
但是多表查询、复杂事务等高级操作效率低下。
所以其适合于写少读多的场景。
HBase列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是由于查询都必须要依赖rowKey，这就使得很多复杂查询难以进行。
例如，如果你的查询条件涉及多个列项，或者你无法获取要查询数据的key，那么查询效率将会非常低下。
Druid是基于MPP架构的OLAP，其预聚合算是Druid的一个非常大的亮点，通过预聚合可以减少数据的存储以及避免查询时很多不必要的计算。
适用于大量数据的下的实时聚合查询场景。
Redis牺牲了常规数据库中的数据表、复杂查询等功能，特别适合那些对读写性能要求极高，查询条件也同样简单的应用场景。
HIVE数据仓库，基于HDFS的结构，支持主流的SQL但是查询的速度较慢，适合于大批量场景的数据加工，存储的场景。
下面有个对比的表格：
支持情况
Redis
Durid
HBase
MongoDB
Hive
数据规模
小
中
大
中
大
批量查询性能
弱
中
中
强
强
批量写入性能
弱
中
强
中
强
支持表级关联
不支持
不支持
不支持
弱
强
聚合查询
不支持
强
不支持
中
中
亚秒级查询
强
强
中
强
弱
亚秒级写入
强
强
强
中
弱
3、数据灾备方式的选择
数据是科技公司最大的资产，每个公司都在数据灾备上面作为了大量的应用防止出现意外时候，数据丢失及访问异常。
为最大程度的降低风险。
早期考虑dump每天的数据快照，在异地数据库进行恢复，但是这样存在dump期间的数据丢失情况。
一旦出现数据服务器down机的情况，备库是无法承接使用的。
现在Postgres集群本地采用一主两从的流复制方式，保证主从节点之间数据一致性。
同时在一台从节点上使用级联复制为异步IDC提供数据同步服务。
HDFS采用跨IDC机架的方式，Redis、Durid、MongoDB采用集群模式、保证数据灾备时候，能够快速切换到备机使用，且数据不会丢失。
三、建设实践
1、关系型数据库应用
关系型中数据库切分存储
由于去IOM的要求及未来国产化、开源化的大趋势。
我们最终选择了Postgres作为关系型数据库的载体。
单库Postgres性能无法满足高并发访问的要求，采用了分库分表的数据逻辑切分。
由于是强职能管理型的系统特性。
客户关联的数据信息使用基于所在辖区水平分库切分，而管理公共信息、统计报表信息、数据概览信息、以垂直切分的方式切分。
对于常用的表，在各个数据库中冗余存储。
以此减少OLAP操作时网络传输的耗时，同时便于利用数据库本身的特性。
这样切分，虽然不同的数据库中数据相较于一致性hash分库原则会不一致，不同辖区对应的数据库中数据量可能不一样多，牺牲了一部分的存储。
但是较系统的性能，还是值得的。
同时对于数据库当日产生的操作信息及交易流水，按照一致性Hbase的原理，将流水信息存储在以流水号切分的数据库节点中存储。
·关系型中数据库HA
在众多的PostgreSQLHA方案中，流复制HA方案是性能，可靠性，部署成本等方面都比较好的，也是目前被普遍采用的方案。
而用于管理流复制集群的工具中，Pacemaker+Corosync又是比较成熟可靠的。
同时为了兼顾异地灾备，以一个从节点进行级联复制，将数据异地灾备到其他IDC机房节点。
系统基于Pacemaker+Corosync实现PG集群的Master-Slave模式，如图所示：
读写分离、高可用
使用pacemaker实现集群资源的管理，业务层通过write-vip实现数据向Master节点的写入，通过read-vip实现Slave节点数据的读取；主节点故障时，vip会自动漂移，从节点升为主库，实现PG的高可用。
数据、状态同步
Master与Slave节点基于流复制（SteamingReplication）通过1.X（eth1）网段实现数据的同步；通过2.X（eth2）网段，corosync实现Master与Slave节点状态同步。
主从切换策略
1.初始状态下，master数据库和write-vip在节点1上运行，slave数据库和read-vip在节点2上运行。
2.当master数据库或master数据库所在节点宕机时，节点2上的slave数据库提升为master数据库，同时write-vip飘移到节点2上。
3.当slave数据库所在节点2宕机时，slave数据库停止运行，read-vip飘移到node1。
2、Redis内存数据库存放热点数据以及公共参数和映射参数
·Redis数据存储内容
由于客户信息进行了切分。
为了快速的找到一个客户所在的信息。
我们将客户及客户所在数据库的映射关系、客户交易流水的hash键值的映射关系作为热点数据存放于Redis中。
同时系统中需要承载的公共参数也放入了Redis中。
同时将客户交易信息中，交易金额超过1万元的大额数据交易信息以及每天日终提取出最近一季度活跃的客户信息，将这部分活跃的客户关键标志信息和大额交易标志信息，也存放在Redis中，用于检索时候，直接在内存中进行检索，而非直接访问数据库，当Redis中没有的时候再访问对应的数据库。
·Redis的HA
映射关系、公共参数采用集群模式部署HA。
热点数据由于数据量较大，集群模式写入慢，采用了哨兵的模式部署HA。
其中哨兵3台节点集群6台节点。
3、Durid检索聚合重点信息
有时候存在在全单位维度的数据OLAP的数据加工和抽样。
如果在每个数据库中抽样结果聚合后，在通过程序二次筛选，一方面架构复杂，另外一方面开发成本较高。
为此我们引入了Druid，在其中存储了全机构的所有客户和客户的重点属性信息。
每次需要聚合查询的时候，从Druid中根据客户重点信息检索出目标集合。
如果目标集合的展示信息不够，在根据目标集合到对应的PG分库或者Hbase中查询出应的数据信息。
4、HBase应用历史交易明细信息
明细信息存放于HBase中注意基于以下几个情况：
PG分库分表存放：
（1）数据量较大，PG数据库压力过大，数据库内存数据的频繁交换
（2）分库分表，数据库维护成本的增加，例如数据库表清理维护，数据同步策略，路由策略。
采用Druid存储：
大量数据存入Druid，Druid集群压力大。
由于HBase适合于读少写多的情况，而历史明细一般查询较少。
所以放入HBase进行保存。
于是采用了将索引与数据存储隔离的原则，只把可能参与条件检索的字段索引到Druid中，这样整个Druid集群压力减少到原来的1/N，全量的客户历史交易明细根据检索出的主键，作为ROWKEY在HBase内查询。
实际应用中，用客户号+日期+交易流水号
升级会员 