一种基于NoSQL的互联网大数据融合系统的研究与实现*

何海诣，贾 宇，沈 宜，张家亮，郝渝江

（成都三零凯天通信实业有限公司，四川 成都 610041）

0 引 言

在互联网信息爆炸的时代，数据系统面临的信息处理量呈几何级的增长，在动辄以TB、EB甚至更高量级范畴的数据量下，传统信息系统基于简单的网络通信协议和关系型数据库，并严格遵守ACID基本要素的设计思路已经远远无法满足形势的需要，在这个背景之下，近年来大量研究人员专注于研究以满足系统高吞吐量、良好的可伸缩性能及扩展性、优异的容错性和鲁棒性以及保证系统核心业务为主的系统框架设计，而NoSQL数据库的强势发展为此奠定了坚实的基础。

在互联网数据分析系统中，通常存在网络爬虫、文字识别、视图像识别等功能平台，而后将这些平台产生的数据用于检索、统计与展现等业务形态，因此如何将这些海量的数据高效且较低成本的进行交互与整合，是本文阐述的重点。

1 关键技术研究

1.1 NoSQL的设计理念

在互联网时代，信息需要的处理规模即便是在局部行业范畴至少都是在PB、EB或更高的量级范畴，包括了结构化、半结构化和非结构化的数据，在一个系统中，信息的交互与存储是系统实现业务目标的关键所在，当系统在大数据环境下进行工作时，如果采用传统的设计思路，利用简单的网络通信协议再辅助关系数据库管理系统来实现系统的业务逻辑，不仅成本高昂且不利于横向扩展。因此，在这互联网蓬勃发展、信息爆炸的时代，NoSQL这一概念的全新思维注入，为解决这一问题提供了革命性的方案。基于NoSQL设计的支持海量数据管理的系统应具有横纵向的扩展性满足系统的适用性、极高的数据吞吐量用于满足系统信息处理能力、良好的容错性和鲁棒性保证分布式系统保证核心业务的稳定、可伸缩性用于满足分布式系统的负载均衡和对部署环境的适配性以及相对较低的部署成本等。

NoSQL也称Not only SQL，是对不同于传统的关系型数据库的数据库系统的统称，它具有非关系型、分布式、不保证ACID的数据库设计模式等特征[1]。NoSQL主要用于超大规模数据的存储与交互，这些数据存储通常要求没有固定的数据结构，无需多余操作就可以横向扩展。

NoSQL典型遵守CAP理论和BASE原则[2]。CAP理论可简单概述为：一个分布式系统不能同时满足一致性、可用性和分区容错性这三个需求，最多只能同时满足两个[3]。BASE原则告诉了我们做为分布式系统的适用性和局限性，首先基于“基本可用”的定义明确了系统部分功能模块可能存在短时间处于不可用的状态，这将会导致部分正在处理的数据可能会在该过程中丢失，但由于分布式系统的冗余部署的特性，只要不是所有该功能模块的部署节点全部异常，则能保证系统核心业务的正常；其次在“软状态”的定义中明确指出了分布式系统的数据在一段时间内基本不会同步，以异步为主，因此系统业务不能依赖数据的瞬时同步来进行，也不能与信息的上下文逻辑关系进行强耦合；在“最终一致”的定义中我们知道，由于分布式系统“软状态”的存在，在某一随机时间点上系统中的数据不一定严格准确，但是在基于策略同步完成后，系统的数据最终可以完成一致[4]。基于上述理论和原则，基于NoSQL理念设计的系统通常应用于强调系统的吞吐量，存储的空间大小以及系统横纵向的可扩展性，同时在数据方面不要求严格同步，并能一定程度容忍数据丢失的风险。因此，基于NoSQL所设计的系统通常不会应用于与业务强耦合的场景，如企业OA系统、订单管理系统、BOSS系统等，但却非常适合针对大数据分析的功能系统，在这样的系统中，业务的严谨性不是最重要的考量对象，但是对性能、系统的扩展性与稳定性等却有非常严格的要求。

在性能上，由于NoSQL数据存储系统不需要保证ACID，且数据库结构简单，在面向大数据环境下可以取得非常优异的性能，读写效率基本都是在毫秒级。在设计上，NoSQL数据库面向的是分布式系统多客户端对数据的高并发存储吞吐处理以及基于大数据的存储，因此具有灵活的部署策略与读写性能[5]；通过自由的模式定义方式，实现在海量数据的数据中进行快速的访问，另外，灵活的分布式体系结构支持横向可伸缩性和可用性，且对硬件的需求较低[6]。因此，基于NoSQL所构建的系统对于信息的处理性能至少以万次/秒来进行统计，远远超过传统意义上的系统处理性能；同时基于该理念所构建的系统通常能够在逻辑上轻易的通过叠加硬件的方式无限扩展性能，一般只受限于部署环境中网络吞吐量的限制，因此系统的生命周期通常很长，能够极大的降低系统的平均成本；另外，由于基于NoSQL理念所构建的系统的各个功能节点的信息耦合均依赖NoSQL数据库的分发与存储，且信息的处理互相独立不耦合，因此可以非常简单的进行分布式冗余部署，极大的提高了系统核心业务的稳定性。

1.2 NoSQL数据库的研究

NoSQL数据库大致可以分为如下四类[7]：

键值型数据库：该类型数据库的存储方式是以Key-value的形式，使用HASH表进行存储，其映射方式是一对多的方式。由于其数据结构简单且不需要严格遵守ACID，因此该类型数据库读写速度在所有NoSQL数据库中是最快的，但缺点是仅能通过Key的完全匹配来进行查询，不能通过Value或其他组合方式来进行复合搜索。

列存储数据库：该类型数据库不同于传统数据库的存储方式，在使用上也有较大的不同，其主要以列为数据局操作的主要对象。列存储数据库与键值型数据库在部分概念上存在重叠，其主要区别在于列存储数据库可以基于列来进行局部更新，这对于在大数据环境下的很多业务形态的实现具有极高的价值。

文档型数据库：该类型数据库依赖文件来构建对应的数据结构，通常使用JSON、XML等不严格定义的数据组装方式来进行，由于文件结构自由化程度很高，因此文档型数据库几乎可以适用于任何数据结构，具有非常良好的适配性。

图形数据库：该类型数据库利用图论的三大基本要素（节点、关系、属性）来进行构建，基于这三大属性构建数据间的关联信息，是NoSQL数据库中最接近关系数据库的一种类型，但由于设计比较复杂，通常适用于大型社交网络系统的构建。

由于本系统是针对大数据环境下数据融合而进行构建的，由于功能相对单一，且不涉及复杂的业务控制逻辑，因此能够快速进行信息交互成为了本系统最主要的关注点，另外考虑到识别类型的横向扩展性，因此，NoSQL数据库中键值型数据库是本系统最优的选择，针对键值型数据库再进行细分，又大致可以分为key-document、key-colume以及key-value型数据库，现在主流的键值型数据库有BigTable、MongoDB、Redis、HBASE 等。

在本系统中，在大数据环境下我们需要构建庞大的指令分发体系，由于Redis中的数据全部存储在内存当中，因此读写速度奇快，官方测试数据显示，单机系统下能进行每秒约11万次的读操作，约8万次的写操作，同时，Redis支持发布-订阅模式，因此我们选择在系统中使用Redis作为高速消息队列，为分布式系统内部业务控制信令的传输提供支撑。

另外，由于系统主要目的在于数据动态关联性的需求，且要求检索速度非常快，因此需要选择一款检索速度快且按列进行局部动态更新的数据库。HBASE的表支持亿级行存储，并能支撑按列进行动态更新，通过Row key进行数据检索达到毫秒级。因此特别适合在系统中用于大数据的快速检索与匹配，且可对信息进行长时间的冗余备份存储，因此我们选择HBASE做为系统中快速检索匹配使用的数据库。

2 系统设计

2.1 Redis内存数据库的部署设计

本文所论述的系统需要在大数据环境下收集分发庞大的数据指令，这些数据指令是系统完成正常业务流程的基础，在前文中通过技术分析确定了使用Redis内存数据库做为系统各模块之间消息传递的基础，并从性能上确认了该类型数据库能够满足系统的设计需要，因此在本节中主要论述Redis内存数据库的部署方案以及使用策略以满足系统通信的稳定性及业务需求。

如图1所示，系统部署的是拥有6个节点的Redis集群，采用主从冗余部署的方案保证通信的稳定性。图1中虚线表示Gossip通信协议，M(X)表示主节点，S(Y)表示从节点，Redis集群利用该协议建立了各个节点之间的两两联系，并负责各个节点之间基于“最终一致性”原则实现数据的最终的同步，从而实现了一个全网状拓扑结构的集群架构。基于部署图我们可以看出，当任一节点出现异常下线时，系统通信不会受到任何的影响，当系统出现两个节点异常时，通信可用性可以通过计算1-(1/(2*6-1))得出其概率约为90%。在实际系统运维过程中，当Redis节点出现异常时通常会利用工程化机制使其自动恢复，同时辅助人工恢复的方式，因此在短时间出现1-2个节点异常时，基本不会影响到系统核心业务的运转，由此我们判断使用该部署方式基本可以满足系统使用需要[8]。

图1 Redis集群部署图

2.2 HBASE数据库的部署设计

在本系统中存在业务数据关联整合的需求，且要求检索速度非常快，同时由于视图像识别类型会随着系统的迭代更新而不断增长，因此需要选择一款检索速度快且按列进行局部动态更新的数据库。HBASE的表支持亿级行存储，并能支撑按列进行搜索，通过Row key进行数据检索达到毫秒级。因此特别适合在系统中用于大数据的快速检索与匹配，且可对信息进行长时间的冗余备份存储，因此我们选择HBASE做为系统中快速检索匹配使用的数据库。

系统中部署的HBASE结构图如图2所示，通过冗余部署等价HBASE业务层避免单节点访问故障。其中HMaster会为每个Region分配一个HRegionServer以供控制数据的I/O请求响应，HMaster和HRegion Server都会在Zookeeper当中进行注册，这样Zookeeper可以得知HBASE环境中有效的节点状态，当Client端发起数据I/O请求时，首先从Zookeeper中获得有效的HMaster的节点，并通过HMaster获得此次I/O请求所对应的有效HRegionServer节点地址，从而完成此次数据读写操作[9]。依赖于这个机制的实现，HBASE环境中只要有一个HMaster和HRegion Server存活，Client均可以顺利完成数据读写的核心业务，同时，Zookeeper中注册的各个节点会同步本节点数据吞吐量，使得HMaster可以方便的实现负载均衡的策略。

图2 HBASE架构

2.3 系统框架设计

系统框架图如图3所示，从图中可以看出互联网大数据融合系统面对的是多个第三方业务系统以及海量的业务数据信息，每个业务系统所需求的业务数据信息会根据产品形态的不同而有所区别，因此本系统不仅要支持对海量数据进行处理，还需要具体区分信息所归属的业务系统，同时不增加如数据识别引擎等功能子系统的运算负荷以及系统存储空间。

本系统主要由任务管理模块、Redis消息处理模块、HBASE数据管理模块以及业务数据汇聚模块组成。

任务管理模块主要负责处理系统任务数据的配置与管理。如上文中提到的本系统面对的是多个第三方业务系统，需要将数据基于业务系统进行区分反馈，因此本系统构建了一套任务体系用于关联数据与业务系统之间的联系，任务管理模块则是该流程中关键的一个环节。该模块通过从第三方业务系统中接收到任务的配置信息，将底层数据基于数据来源进行分系统映射，通过任务ID与业务系统进行关联，并存储在Mysql数据库中以供系统内部共享使用，由此确定了数据在进入Solr分布式搜索引擎时的分库依据，实现了业务数据的对应关系。

Redis消息处理模块主要负责接收功能子系统发送的业务数据消息，主要有互联网数据采集信息、文字及视图像识别信息等，同时，Redis消息处理模块还将依据系统任务配置信息确定接收到的互联网数据信息应当交付给哪一个功能子系统进行处理。由于功能子系统在互联网大数据环境下通过分布式部署而拥有极高的数据产生和处理能力，因此Redis数据库使用集群部署方案，以6个节点建立两两之间的冗余备份以支撑子系统间的数据交互需求。

HBASE数据管理模块主要负责建立以网页为基础的系统内数据汇聚管理，通过在HBASE中建立网页、网页附属信息、网页资源信息及识别结果的数据表，实现信息在系统内部的初次整合并与业务无关，该数据是之后业务数据汇聚的基础。

图3 大数据融合系统框架图

业务数据汇聚模块主要负责将HBASE中的数据基于业务需求写入到Solr分布式搜索引擎中，每个业务系统唯一对应一个Solr表，并依据业务形态形成独立的表结构，该表与数据的对应关系来源于系统任务配置信息。

3 系统实现途径

系统详细流程图如图4所示，系统首先进行初始化配置，主要是初始化通信接口及初始任务配置；当业务系统下发了任务配置时，需要将该配置写入任务映射数据库以供后续使用。

图4 大数据融合系统详细流程

当系统接收到互联网采集数据信息后，首先需要判断该数据所属的任务关系，不同的数据所需要进行的识别方案基于任务的关系可能会有区别，在确定数据的处理方案后，系统将采集到的数据信息规则化存储到HBASE数据库中，以网页为单位建立初始的表结构信息（如表1所示），等待后续识别信息的补充，同步的，分解的待识别网页资源信息将下发到识别服务引擎进行识别。

当识别服务引擎返回结果之后，系统将识别结果信息与之前HBASE缓存的数据进行关联，形成以网页为单位的全量数据仓库，再基于该数据所对应的任务信息将所需要的数据业务规则化，写入Solr搜索引擎。

表1 HBASE数据关联

最后，业务系统从Solr搜索引擎中读取出需要的数据，并依据产品业务形态提供给最终用户使用。

4 结 语

本文对一种基于NoSQL的互联网大数据融合系统进行了研究与实现，从整体上介绍了NoSQL数据库的设计理念，说明了Redis和HBASE在本系统中的使用方式，并对系统的框架和实现途径进行了详细说明。基于本文的研究结果，该系统已经实际在互联网大数据分析系统中做为数据调度中心来进行使用，该系统融合了爬虫集群、文字识别、视图像识别及业务展示等多个功能，并能为多个客户提供服务，互联网大数据融合系统主要为整个系统提供数据分发与整合的作用，是整个系统的数据流中心。