面向海量数据的在线流数据服务框架

杨　臻　杨志宏　肖　汉

1(郑州师范学院信息科学与技术学院　河南 郑州 450044)2(中州大学信息工程学院　河南 郑州 450044)



面向海量数据的在线流数据服务框架

杨臻1杨志宏2肖汉1

1(郑州师范学院信息科学与技术学院河南 郑州 450044)2(中州大学信息工程学院河南 郑州 450044)

针对多应用共享海量流数据的问题，提出一个在线流数据服务框架。通过对多应用共享流数据场景进行分析和抽象，设计具有数据层、管理层和接口层的在线流数据服务框架。框架将流数据管理划分为索引建立、注册器、匹配器和内存清理四个组成部分，并且通过一个专用的数据管理引擎对流数据进行管理。框架的提出为多应用流数据共享场景提供了一种统一管理流数据的方案。实验结果表明，相对与传统数据库，在线流数据服务框架在流数据写入速度能提高近5倍，在流数据的读取速度上提高4倍左右。

流数据在线服务海量数据管理数据服务框架数据管理引擎

0　引　言

进入21世纪，数据以令人惊讶的速度增长，我们的生活被海量数据所包围。根据IDC 的预测，在2005年到2015年这十年的时间内，全球数据总量将从2000 EB增长到近8000 EB[1]。如此庞大的数据规模为数据的分析和处理提出了更多的挑战。从实时采集、在线处理的角度来说，互联网数据可以视为一种典型的流数据。

在互联网应用中有一种多应用共享流数据的场景，多个应用需要在一定的时效期内访问该数据，对其进行在线分析和计算。这种场景广泛存在于目前比较流行的互联网搜索挖掘系统中，其难点主要体现在流数据处理的时效性和应用的高效性两方面。一方面，流数据源源不断地到来，随着时间的增长，累积的数据规模将会非常巨大，这会对数据存储造成很大的压力；另一方面，多个应用都需要访问数据。如果不能有效地组织多个应用对流数据的处理关系，提高数据访问的效率，则很难使应用的处理速度匹配上流数据处理的时效要求，因此必然导致部分数据需要先存储然后再重新加载处理，这将造成大量不必要的I/O开销和计算资源浪费。为了提高流数据处理的时效性和应用的高效性，迫切需要一种支持多应用共享的在线流数据处理方法。

针对流数据的处理，金澈清[2]等分析了流数据的产生根源以及流数据速度快、规模宏大等特点，并给出了流数据管理需要面对的主要问题；针对流数据的存储，刘云生[3]等提出了一种采用本体技术来解决语义互操作性的流数据存储框架；李子杰[4]等详细阐述了流数据和传统数据存储及管理方法比较研究，虽然上述对流数据的存储方面给出了很多的方法，但是对于流数据的处理，尤其是在多应用共享的在线流数据的处理，没有给出有效的解决方案。

针对多应用共享在线流数据的处理问题，本文首先对多应用流数据共享场景进行分析和抽象，提出一种通用的可应用于多流数据共享场景的在线流数据服务框架，为流数据的统一处理提供了整合数据管理模型，为数据传输与计算提供标准接口。

1　在线流数据处理场景及其主要问题

流数据是一组顺序、大量、快速、连续到达的数据序列，一般情况下，数据流可被视为一个随时间延续而无限增长的动态数据集合[5]。流数据具有实时性、未知性和不可逆性3个特点[6]。流数据处理[7]是对流数据进行传输、计算和存储的过程。流数据传输提供端到端的流数据传输服务。在多应用共享流数据的场景中，数据源将数据发布到一个消息总线上，多个应用通过消息总线对流数据进行访问。如图1所示，一个面向互联网的数据分析系统。分析程序会按照业务需求对数据进行访问，共享数据分析系统中的互联网流数据。

图1　互联网数据分析示意图

这种多个应用共享流数据的场景存在两个突出的特点。首先，互联网流数据随着时间的增长会累积很大的数据量，如果无法及时对这些数据进行在线处理的话，就需要将这些数据进行存储，由此造成存储的压力。其次，流数据很难进行存储或者从存储中获取需要花费巨大的代价。传统流数据如骨干网络中的数据包，无法进行保存，互联网流数据虽然可以存储，但如果完全依赖磁盘存储系统，则在多个应用共享处理数据时必然要涉及到大量的I/O操作，由此造成处理效率的低下。

在典型的互联网搜索挖掘业务场景中，应用数目会在几十个到几百个之间，这些应用需要对数据进行不同的分析和处理。一条数据在这个过程中会被不同的应用访问多次，因此数据访问的开销大小就成为整个流程的瓶颈。所以，多应用共享流数据时应具有高效性，减少不必要的存储浪费和I/O开销。

在多应用共享流数据时，每一个应用在逻辑上都可以访问到一份完整的数据集合。采用流数据的多个副本可以解决共享问题，但是随着应用数目的增加，流数据副本所占用的空间开销会随之呈线性增长，同时维护多个流数据副本需要大量的存储和计算资源。与此同时，流数据会随着时间动态增长，流数据的访问对于实时性有很高的要求。流数据多副本的时空开销和流数据访问的实时性要求之间的矛盾，是解决多应用流数据共享问题的难点所在。亟需找到一种方法构建应用和流数据之间的桥梁，以便能够高效便捷地对应用与流数据进行管理。本文设计的在线流数据服务框架采用内存作为主要存储介质，提高流数据的读写速度，采用索引结构记录应用可以访问的流数据范围，避免了多副本带来的空间开销。

2　设计原则

在线流数据服务框架的设计需要满足高效性和低耦合两个基本原则[9]。第一，高效性的需求来自于流数据的实时性的特点，这就要求所有的流数据处理都要在线进行。为了满足高效性，在线流数据服务框架的设计需要从硬件架构和软件算法两个方面进行考虑和设计。第二，低耦合是检验框架通用性的标准。在线流数据服务框架应该成为多应用共享流数据场景下的通用框架。在线流数据服务框架需要提供流数据的管理和服务两大功能。数据的管理包括数据收集、缓存、应用注册和数据查询等；数据服务包括流数据交付模式、数据访问规则以及数据访问接口等。

2.1数据管理要求

在线流数据服务框架所提供的数据管理包括了索引建立、应用注册、数据查询和内存清理。

1) 索引建立。为了提高数据查询和清理的效率，在对流数据进行管理时需要对流数据建立索引结构。

2) 应用注册。应用需要和流数据进行动态地绑定。在线流数据服务框架需要提供一种应用注册的机制，以有效地管理应用与流数据的动态绑定。

3) 数据查询。在线流数据服务框架需要向应用提供数据查询功能。应用在进行动态绑定之后按需查询流数据。

4) 内存数据清理。在线流数据服务框架采用内存作为主要存储介质。

2.2数据服务要求

在线流数据服务框架提供的流数据服务主要包括了流数据交付模式、流数据访问的规则和流数据的接口。

1) 流数据交付模式。为了提供异步的松耦合的在线流数据服务，需要提供一种采用“拉”(Pull)方式的数据服务。采用了“拉”的数据服务模式就是让应用主动发起数据请求，按照应用自身的行为逻辑进行数据的访问。

2) 流数据访问规则。在线流数据服务框架是针对多应用共享流数据的场景，所以在线流数据服务框架对于每个应用都提供一个逻辑上完整的流数据。每个应用只能对流数据中的数据进行一次访问，而不能反复访问同一个流数据段。如图2所示，应用1在t1时刻完成了流数据的使用注册，那么应用1从t1时刻起就可以使用流数据，但是在t1时刻之前的数据对于应用1来说是不可见的。应用2在t2时刻完成了流数据的使用注册，那么应用2从t2时刻起就可以开始使用流数据。如果应用1已经访问了从t1到t2时间段内的数据记录集合，那么它不能够再次访问其中的数据。

图2　数据访问规则示意图

3) 流数据接口。在线流数据服务框架的流数据接口规定了应用可以以何种条件对流数据进行查询访问。在流数据接口的设计上要保证其简洁性和松耦合。流数据接口应该提供简单的查询条件，让应用进行数据查询。流数据接口的操作不应涉及到流数据的具体内容，以保证接口的松耦合。

3　在线流数据服务框架总体设计

多应用共享数据流的场景可以归纳为一种典型的多对多异步数据访问模型。在解决这类多对多的异步访问问题时采用发布/订阅模型是一种通用的方法。本节按照在线流数据服务的设计原则，将发布/订阅模型作为框架的设计依据，提出在线流数据服务框架。

3.1发布/订阅模型

发布/订阅模型是一个重要数据访问范式[10]，可以用来解决多对多的数据生产和消费问题。该模型通过一个消息队列和数据访问控制机制将应用程序分为发布者和订阅者，发布者负责将产生的消息放在消息队列中，订阅者可以从中获取自己感兴趣的数据。这种发布者和订阅者的松散耦合允许更好的可扩展性和数据的访问控制。

如图3所示，发布/订阅模型有五个重要的组成部分：发布者、订阅者、数据容器、注册器和匹配器。发布者产生数据，将数据放入数据容器中。订阅者通过注册器向发布/订阅系统发起注册请求。注册成功后订阅者通过匹配器，访问查询数据容器中的数据。

图3　发布/订阅模型图

3.2框架组成

如图4所示，在线流数据服务框架，数据源将流数据写入到内存中；应用通过注册后使用数据管理引擎提供的服务。在线流数据服务框架包括了数据层、控制层和接口层。数据层负责数据的存储和组织，是框架提供服务的保障。控制层负责处理读写请求，是框架的逻辑处理部分。接口层负责提供网络接口，供应用使用服务。

图4　在线流数据服务框架架构图

1) 数据层数据层负责数据的存储和组织，是框架提供服务的保障。数据层分为数据高速通道和备份文件系统两个部分。由于内存读写的系统开销要远远小于对磁盘的操作，所以数据高速通道以内存作为主要存储介质。在线流数据服务框架的数据完全存在于数据高速通道中。在数据高速通道中存在着两种类型的数据，流数据存储和数据索引结构。流数据存储是将流数据按照顺序存放与数据高速通道中；数据索引结构是使用流数据的字段建立的，以提高流数据的查询效率。由于计算机内存不是一个稳定的存储介质，所以在线流数据服务框架设计了备份文件系统，对于内存中的数据进行备份，保证框架能够提供稳定的服务。

2) 控制层控制层负责处理读写请求，按照读写请求的语义进行数据存储、索引建立、应用注册、数据查询和内存清理等工作。控制层中设计了一个数据管理引擎，引擎中包括了索引建立、注册器、匹配器和内存清理四个部分。索引建立模块负责对流数据索引结构进行写入和更新。注册器负责处理应用的注册请求。应用只有在进行注册之后才可以使用在线流数据服务，注册后的应用由框架统一管理。匹配器处理应用发起的数据查询请求，匹配器对索引进行数据查询，然后将查询到的数据从数据高速通道中提取出来，返回给应用。计算机的内存空间是极度有限的，随着时间的增长，驻留在内存中的数据量会不断增加。内存清理模块对内存中的数据存储和索引结构进行监控和分析，及时对内存数据和索引结构进行更新，将已经过期的数据从存储和索引中清除。数据管理引擎中最重要的部分是数据管理算法，数据管理算法运行在数据引擎的四个组成部分之上，负责应用注册、数据查询和内存清理操作的相关逻辑。

3) 接口层接口层是在线流数据服务框架与客户端进行交互的中介。接口层定义统一的API接口供数据源和应用使用。在线流数据服务框架的接口层采用了远程过程调用的方式对客户端提供服务。接口层定义的接口类型主要包括了读接口、写接口和应用注册接口。

3.3流数据管理算法

流数据管理算法[11]运行在框架的数据管理引擎之上，主要解决了框架中的索引建立、应用注册、数据管理和内存数据清理四个问题。下面将给出流数据管理算法的形式化定义。

从流数据的定义可以看出，一条流数据记录同时包含了时间属性和数据属性。首先，一条流数据记录是包含了许多属性字段的数据。其次，在线流数据服务框架对每一条流数据记录提供一个全局唯一的数据记录编号，这样在在线流数据服务框架中一条流数据记录可以采用“数据记录编号—属性集合”形式的“键—值”对来表示。最后，每条流数据还附带着一个时间属性，这样一条流数据记录就可以使用“键—时间—值”这种形式唯一表示。所以，在线流数据服务的数据记录带有三个基本属性：数据记录id、写入时间t和数据属性集合vset。这三个基本属性中数据记录的时间属性t是由流数据特点决定的；数据的id属性是为了便于管理而增加的；数据的属性集合是由数据自带的信息和应用逻辑决定的。为了达到和应用最低的耦合度，在线流服务框架仅仅会对数据记录的时间属性和记录id进行操作，而不会对数据记录的属性集合做任何修改。

定义1数据记录键值。采用一个整数标示一条数据记录的键值，用符号id来表示。在在线流数据服务中，每条数据记录有唯一的键值，不会与其他数据记录产生重复。

定义2数据记录时间。在线流数据服务的时间取值范围为(t0,∞)，t0是在线流数据服务的开始运行时间。假设可以将在时间取值范围内的时间进行无限的细分，取出时间点{t0,t1,…,tn}，那么每个ti(t=0,1,…,n)都可以作为一条数据记录的时间值，用符号t表示。

定义3属性集合。采用符号vset来表示在线流数据服务中数据记录的属性集合，用v来表示属性。一个属性集合由固定个数的属性组成，即vset={v1,v2,…,vk}，每条数据记录的属性集合中的每个属性可以有不同的合法取值。

定义4流数据记录集合采用数据记录键值、数据记录时间和属性集合来唯一表示在线流数据服务中的流数据记录，记为三元组{id,t,vs}。由所有数据记录组成的集合，称之为在线流数据服务中的流数据记录集合。

应用与在线流数据服务进行交互主要有两种行为：应用注册和数据访问[12]。在应用注册时，应用首先向在线流数据服务发起注册请求，得到同意后，应用获得一个用于标示自己身份的唯一应用编号，用appid标示。在完成注册后，应用可以通过应用编号向在线流数据服务发起数据查询请求。由于希望构建一个松耦合的在线流数据服务框架让应用合理得使用数据，所以，在提供的数据服务中只会将流数据记录的高层属性作为数据服务的查询条件。这些属性包括了流数据记录的唯一编号和流数据的时间信息。在线流数据服务将不会对流数据的属性进行任何的操作，也不会将其作为数据查询的条件。

定义5应用查询。用q表示应用查询用。定义q={appid,bid,eid,bt,et}为一个五元组。其中appid表示发起查询的应用信息，bid表示应用需要查询的数据记录集合的开始id，eid表示应用需要查询的数据记录集合的终止id，bt表示应用需要查询的数据记录集合的开始时间，et表示应用需要查询的数据记录集合的终止时间。

框架中规定了如下三种具有合法语义的应用查询：

1) 已注册的应用按照数据记录的id区间进行数据查询。符合这种查询的应用查询形如q={appid,bid,eid,null,null}，其中appid是应用编号，bid是需要查询的数据集合的开始id，eid是需要查询的数据集合的终止id，数据记录的时间属性设置为空，这样在线流数据服务就会为应用编号为appid的应用查询数据记录id从bid到eid的数据记录。

2) 已注册的应用按照数据记录的时间区间进行数据查询。符合这种查询的应用查询形如q={appid,null,null,bt,et}，其中appid是应用编号，数据记录的id属性设置为空，bt是需要查询的数据集合的开始时间，et是需要查询的数据集合的终止时间，这样在线流数据服务就会为应用编号为appid的应用查询数据记录时间从bt到et的数据记录。

3) 已注册的应用按照数据记录的id和数据记录的时间两个条件同时进行查询。符合这种查询的应用查询形如q={appid,bid,eid,bt,et}，其中appid是应用编号，bid是需要查询的数据集合的开始id，eid是需要查询的数据集合的终止id，bt是需要查询的数据集合的开始时间，et是需要查询的数据集合的终止时间，在线流数据服务就会为应用编号为appid的应用查询，数据记录id从bid到eid，时间从bt到et的数据记录。

在线流数据服务框架能够提供高效的数据管理和数据服务的关键是流数据管理算法的设计。流数据管理算法需要完成三个主要任务：应用注册，数据查询和内存清理。

1) 应用注册问题。应用注册是应用能够使用流数据服务的先决条件，这样可以保证应用主动地和流数据进行动态绑定，能够保证流数据服务使用的安全。当一个应用向流数据服务提起注册申请时，流数据管理算法需要对应用进行验证，然后为其分配一个全局唯一的appid，在后续的操作中，应用就可以使用这个appid构造查询请求。

2) 数据查询问题。应用会按照自己的业务需求向在线流数据服务发起三种形式的数据查询。流数据管理算法在验证应用查询的合法性之后，需要按照应用查询的语言，快速高效地进行数据查询。

3) 内存清理问题。在线流数据服务的主要存储介质是计算机内存。但是计算机内存是昂贵的计算资源，不可能无限量使用。所以，内存的使用直接关系到在线流数据服务的质量。每个应用只能对流数据中的数据进行一次访问，而不能反复访问同一个流数据段[13]。而当一条数据记录被所有的应用使用后就无需再停留在在线流数据服务系统中。内存清理问题就是要设计一种合理的内存清理机制，保证在线流数据服务中内存空间的有效利用。

4　系统实现与性能分析

4.1系统设计与实现

本节以在线流数据服务框架为设计依据，实现了一个在线流数据服务系统。系统采用内存作为主要存储介质，实现了在线流数据管理框架的索引建立、注册器、匹配器和数据清理四个部分。系统采用C/S结构，通过网络接口对数据源和应用提供数据读写服务。系统分为流数据服务端和客户端两个部分，两者通过网络数据接口进行通信。

图5　系统实现架构图

根据在线服务框架的规范，系统有索引模块、注册模块、匹配模块和内存清理模块四个基本的功能模块。系统将数据高速通道在计算机内存中实现，四个功能模块会对数据高速通道中的数据进行操作和处理。下面将对服务端的各个模块的功能进行介绍。如图5所示，系统的服务器端包括：索引建立、注册、匹配和内存回收四个功能模块。

1) 索引模块索引模块的功能是对写入系统的数据建立索引结构，支持数据的高效管理和使用。索引模块的功能包括三个方面：(1) 对于写入到系统中的数据，索引模块要对其进行处理，抽取出建立索引所需要的属性，并增加到索引结构中；(2) 索引结构提供按照ID和时间两种条件进行数据查询。索引结构可以按照ID和时间对数据进行查询，并且将查询得到的数据区间返回给调用者；(3) 索引结构用于查找需要被删除的数据区间。当系统要进行内存数据清理操作时，需要通过索引结构查询出需要删除的数据区间。

2) 注册模块注册模块是系统对应用资格进行管理的模块。应用在访问系统之前需要先向注册模块发起注册请求。注册模块会对应用的注册请求进行处理，若应用已经出现在系统的注册表中，那么注册模块会将注册表项中的应用标识返回。如果应用不在系统的注册表中，那么系统会根据应用的名称为其分配一个唯一的应用标识号，并且返回。应用可以通过注册模块返回的应用标识号和系统进行交互。

3) 匹配模块匹配模块负责对应用查询请求进行解析并且在索引结构上进行数据查询。支持数据记录ID 和时间两种条件的组合数据查询。查询请求有三种：仅根据数据ID查询、仅根据数据时间查询和同时根据数据ID和数据时间查询。匹配模块会根据查询的不同语义，选择不同的查询方式，最后将查询的结果进行返回。

4) 内存清理模块内存清理模块的功能是对数据高速通道中的无用数据记录进行删除。在系统中，当一条数据记录被所有的应用访问过，这条数据就需要从数据高速通道中被删除，来保证内存有充足的空间。

4.2系统读写性能分析

在系统写性能实验中，我们采用ORACLE数据库作为本系统的比较对象，在实验环境中测试两者的数据读写性能。实验环境的系统部署方式如图6所示，整个实验环境由6架计算机组成，其中有4架作为客户端分别向本系统和ORACLE数据库写入数据，另外2架计算机分别部署本系统和ORACLE数据库。各台计算机之间采用千兆以太网进行互联。在实验环境中所采用的计算机都有相同的硬件配置。

图6　读写性能实验部署图

对比实验的具体操如下：1) 实验分别针对本系统和ORACLE数据库系统进行读写操作。2) 每次实验中，每个客户端一共读写1GB数据，每个系统在一次实验过程中一共需要接收或者发送4 GB数据。3) 每个客户端的1 GB数据分成16次读取或者写入。4) 4个客户端并发地对系统进行读写数据。

表1中显示的是4个客户端对本系统和ORACLE进行一次数据写入所花费的平均耗时。从表1中可以看到，客户端对ORACLE数据库进行写入，平均的耗时是9.75 s，而对本系统进行数据写入的平均耗时仅为1.69 s，写本系统的平均时间约占写ORACLE数据库的平均时间的17.3%(1.69 s/9.75 s≈0.173)。

表1　客户端写入(64MB数据)平均耗时对比表　　单位:s

下面测试4个客户端分别从ORACLE数据库和本系统写入数据的总体时间对比，对每个系统写入4 GB数据，从表2中可以看出，4个客户端从ORACLE数据库中写入4 GB数据，一共使用了158.56 s。而从本系统中写入4 GB的数据，一共花费了27.51 s。在写入等量数据时，ORACLE数据库所花费的时间约为本系统的6.6倍。本系统的写数据性能要明显优于ORACLE数据库。

表2　写本系统和读ORACLE花费时间表

对写入本系统和ORACLE系统的时间差异进行分析，主要有两个原因导致这种性能上的差异。首先，本系统通过对数据的高效组织使得所有操作可以完全在内存中完成。ORACLE数据库的数据操作采用的是缓存加磁盘的方式，需要进行磁盘I/O操作。其次，写入到本系统中的数据，系统仅仅对数据的ID 和时间字段进行处理，而不会去改变原有数据记录的组织结构。而ORACLE数据库则要求数据按照一定的规则映射到表中的每个属性字段上。因此，数据写入ORACLE数据库的速度相对于本系统就会慢的多。

表3中显示的是4个客户端对本系统和ORACLE进行一次数据读取所花费的平均耗时。从表3中可以看到，客户端对ORACLE数据进行读取，平均的耗时是4.5 s，而对本系统进行数据读取的耗时仅为1 s，读本系统的平均时间约占读ORACLE数据库的平均时间的22.2%(1 s/4.5 s≈0.22)。

表3　客户端读取(64MB数据)平均耗时对比表　　单位:s

下面测试4个客户端分别从ORACLE数据库和本系统中读取数据，对每个系统读取4 GB数据。从表4中可以看出，4个客户端从ORACLE数据库中读取4 GB数据，一共使用了68.75 s。而从本系统中读取4 GB的数据，一共花费了18.18 s。在读取等量数据时，ORACLE数据库所花费的时间约为本系统的3.8 倍。本系统的读取性能要明显优于ORACLE数据库。

表4　读系统和读ORACLE花费时间表

客户端对于本系统和ORACLE数据库的读取速度的巨大差距主要是由于本的数据完全存储于内存中，对本读取数据实际上是将大块的内存空间中的数据进行整体读取。而从ORACLE数据库中读取数据则需要经过磁盘的I/O。

5　结　语

本文分析了多应用流数据共享存在的流数据时空开销与实时性的矛盾，提出在线流数据的三层架构来解决这个问题。在三个层次中，数据层提供了数据的储存保障；控制层中的数据管理引擎负责流数据的管理；接口层负责提供网络调用接口。运行在控制层中的数据管理引擎上的数据管理算法是整个框架的核心部分，本文对算法进行了形式化的定义，阐述了完成的应用注册、数据查询和内存清理三个问题。在线流数据服务框架的提出，为多应用共享流数据问题提供了一种通用的解决方案，能够使流数据源，应用和流数据之间以一种低耦合的方式结合起来。在线流数据服务框架以内存作为主要存储，缩短了数据的读写开销；以数据标识、时间和数据三元组的数据模型来表示数据记录，提供了对数据标识和时间的查询操作，而不对原始数据进行操作，使得框架可以不依赖于具体数据类型而存在。

[1] Gantz J,Reinsel D.Extracting value from chaos[M].New York: IDC iView EMC,2011.

[2] 金澈清,钱卫宁,周傲英,等.流数据分析与管理综述[J].软件学报,2004,15(8):1172-1181.

[3] 刘云生,邓华锋,代一尘,等.存储特定流数据的通用框架[J].华中科技大学学报:自然科学版,2005,33(S1):253-256.

[4] 李子杰,郑诚.流数据和传统数据存储及管理方法比较研究[J].计算机技术与发展,2009,19(4):101-104.

[5] 胡彧,闫巧梅.基于滑动窗口的流数据聚类算法研究[J].计算机工程与设计,2008,29(21):5621-5623.

[6] Chang F,Dean J,Ghemawat S,et al.Bigtable:A distributed storage system for structured data[J].ACM Transactions on Computer Systems,2008,26(2):205-218.

[7] 杨菊华.社会统计分析与数据处理技术:STATA软件的应用[M].中国人民大学出版社,2008.

[8] Neumeyer L,Robbins B,Nair A,et al.S4:Distributed stream computing platform[C]//2010 IEEE International Conference on Data Mining Workshops.New York:IEEE,2010:170-177.

[9] Zhou Y,Ooi B,Tan K L.Disseminating streaming data in a dynamic environment: an adaptive and cost-based approach[J].Vldb Journal,2008,6(17):1465-1483.

[10] 周佳骏,马瑞兴,王峰,等.P2P网络下的可移动情报发布/订阅模型[J].情报杂志,2011,30(6):168-172.

[11] Mehmed Kantardzic,Joung Woo Ryu,Chamila Walgampaya.Building a new classifier in an ensemble using streaming unlabeled data[C]//Proceedings of the 23rd international conference on Industrial engineering and other applications of applied intelligent systems.Heidelberg:Springer-Verlag,2011:77-86.

[12] Xun Yi,Elisa Bertino.Private searching for single and conjunctive keywords on streaming data[C]//Proceedings of the 10th annual ACM workshop on Privacy in the electronic society (WPES’11).New York,NY,USA:ACM,2011:153-158.

[13]ThiagoLGomes,SallesVGMagalhães,MarcusVAAndrade,etal.Computingthedrainagenetworkonhugegridterrains[C]//Proceedingsofthe1stACMSIGSPATIALInternationalWorkshoponAnalyticsforBigGeospatialData(BigSpatial’12).NewYork,NY,USA:ACM,2012:53-60.

[14]JuanDu,NidhiShah,XiaohuiGu.Adaptivedata-drivenserviceintegrityattestationformulti-tenantcloudsystem[C]//ProceedingsoftheNineteenthInternationalWorkshoponQualityofService(IWQoS’11).Piscataway,NJ,USA:IEEEPress,2011:103-122.

MASSIVE DATA-ORIENTED ONLINE STREAMING DATA SERVICE FRAMEWORK

Yang Zhen1Yang Zhihong2Xiao Han1

1(SchoolofInformationScienceandTechnology,ZhengzhouNormalUniversity,Zhengzhou450044,Henan,China)2(SchoolofInformationEngineering,ZhongzhouUniversity,Zhengzhou450044,Henan,China)

To handle the problem of sharing massive streaming data between different applications, we proposed an online streaming data service framework. By analysing and abstracting the scene of sharing streaming data by multi-application, we designed a three-tier online streaming data service framework consisting of data tier, management tier and interface tier. The framework divides the streaming data management into four components including index building, registrar, matcher and memory cleaning, and manages the streaming data by a special data management engine. The presentation of the framework gave a solution of uniform streaming data management to the scene of streaming data sharing by multi-application. Experimental results showed that, relative to traditional database, the writing speed of the proposed service framework increased nearly 5 times, and the reading speed increased by 4 times.

Streaming dataOnline serviceMassive data managementData service frameworkData management engine

2014-08-06。河南省重点科技攻关项目(1321023100 03)；中国博士后科学基金项目(2012M510110)。杨臻，讲师，主研领域：数据挖掘，图像处理。杨志宏，副教授。肖汉，教授。

TP391

A

10.3969/j.issn.1000-386x.2016.03.012