CN104216899A - 面向带有描述信息的海量非结构化数据分布式处理架构 - Google Patents

Abstract

本发明公开了一种面向带有描述信息的海量非结构化数据分布式处理架构，包括数据采集模块，收集非结构化数据并发送至数据缓冲队列中；数据缓冲及预处理模块，暂存数据采集模块发送的数据，并可选择的对数据进行修复或二次处理工作；数据分离及归档存储模块，从前一个模块分布式队列中获取数据，可选择对非结构化数据和描述信息分离，分离后的数据转发或存储至后继模块，流处理模块，对最近接入的数据进行实时监测、比对、计算和处理；分布式数据存储模块，对非结构化数据和描述信息存储；分布式业务处理模块，包含业务处理器、数据访问单元和数据缓存组件；分布式消息中间件，接收前端请求供业务处理器选择执行，或将后台处理结果返回给前端。

Description

面向带有描述信息的海量非结构化数据分布式处理架构

技术领域

本发明涉及分布式系统架构，属于计算机应用软件开发领域，尤指一种面向带有描述信息的海量非结构化数据分布式处理架构。

背景技术

近些年，随着数据采集和传感技术的提升，人们可以收集越来越多的数据并从中提取有价值的信息以供分析决策使用。通常采集到的数据可以分为三类：一类是可以通过二维表结构来逻辑表达的结构化数据；第二类是存在一定结构，但结构本身变化较大的半结构化数据；最后一类是诸如电子文档、图片、视频等非结构化数据。将第三类数据与前面两类结合便成为带有描述信息的非结构化数据，这里的描述信息既可以指结构化的信息，也可以是半结构化信息。现实中这类数据很常见，如摄像机拍摄的图片经识别后按一定格式添加描述标签，带有某种特定内容描述的电子文档等。很多应用需要收集海量此类数据，然后基于描述信息对它们进行检索或完成一些更复杂的业务功能。这就不仅要涉及对这些数据进行自动或触发式的批量操作，有时还需要实时监测和挖掘近期数据中包含的最新信息。传统的集中式存储和处理架构面对如此海量的数据规模已经显得力不从心，而现有的分布式系统又不能简单拿来解决这一问题。

发明内容

本发明的目的就是为了解决上述问题，提供了一种面向带有描述信息的海量非结构化数据分布式处理架构，来同时满足对于这类特殊数据进行批量处理和实时处理的要求。

为了实现上述目的，本发明采用如下技术方案:

一种面向带有描述信息的海量非结构化数据分布式处理架构，包括以下模块：

数据采集模块，包含数个采集终端，负责收集非结构化数据并将它们发送至数据缓冲及预处理模块的数据分布式缓冲队列中；如果终端设备支持，可以在此完成基本的描述信息识别或标注工作；

数据缓冲及预处理模块，主要包含一级数据分布式缓冲队列，用来暂存数据采集模块发送的数据；

数据分离及归档存储模块，从前一个模块的分布式队列中获取数据，并根据实际应用选择的对非结构化数据和描述信息分离，然后将分离后的数据转发或存储至分布式数据存储模块；

流处理模块，该模块基于现有的S4或Storm分布式流处理平台实现，对最近接入的数据实时监测、比对、计算和处理，得到的结果实时推送给后继模块中的分布式业务处理器，同时该模块也接收分布式业务处理器发来的信息和命令以满足可控性要求；

分布式数据存储模块，为满足海量数据需求，该模块中用两种可靠的分布式存储组件即分布式数据库和分布式文件系统，对非结构化数据和描述信息分别存储；

分布式业务处理模块，该模块作为应用业务处理的核心模块，主要包括以下几个组件：

（1）分布式业务处理器，该组件由分布在多台节点上的Share-Nothing式业务处理器组成，主要负责接收前端请求，通过与流处理模块交互和利用分布式计算框架MapReduce，来完成相应业务并向目的组件发送结果；

（2）非结构化数据访问单元，它不仅支持对已归档数据的访问，还能自动到缓冲队列中获取未来及归档的数据，这个过程对使用者而言是完全透明的；

（3）分布式数据缓存，无论是对非结构化数据本身还是对其描述信息的访问可能都会存在一定的延迟，分布式数据缓存组件能够缓解这一问题；

分布式消息中间件，该模块使用现成的中间件系统来充当，其主要功能是接收前端请求以供分布式业务处理器选择执行，业务完成结果也是通过该中间件经网络送达前端应用。

数据缓冲及预处理模块中还需添加一个专门单元即数据修复及二次识别单元，用于对数据修复或二次识别，如果数据采集模块内部分终端没有对非结构化数据识别或标注则在此处处理，然后将处理后的数据存入二级数据分布式缓冲队列中。如果应用不需要此工作，则数据修复及二次识别单元和二级数据分布式缓冲队列可以省略。

数据分离及归档存储模块中，分离过程中需要添加描述信息到非结构化数据的关联，换言之需要支持根据某条特定的描述信息找到其对应的非结构化数据。通常来看，对于后继的流处理模块，出于效率考虑可能仅需要描述信息；而分布式数据存储模块中对于非结构化数据及其描述的存储应该是分离的，例如前者可以归档并存入HDFS或其他分布式文件系统，而后者可以存入HBase分布式数据库中。

分布式业务处理器，业务开始的触发模式有三种，分别是：前端请求触发、流处理模块推送触发以及自身计划任务触发，依托于分布式消息中间件，该处理器组件对于业务请求应提供负载均衡功能，每个节点上的处理器通过跟踪本地当前正在执行的业务，从消息中间件中挑选“合适”的请求并进行处理；如果某个请求未能正常处理，则应根据实际情况选择返回错误信息或将请求交还消息中间件以供其他节点处理。

非结构化数据访问单元，考虑到执行效率及可实施性，分布式业务处理器中的绝大多数业务都不是基于非结构化数据本身而是基于其描述信息的，再加上流处理模块中的数据和分布式数据存储模块中的数据存在不同步的情况（非结构化数据还未来得及归档，仍保留在数据缓冲队列中），有必要为根据描述信息访问其对应的非结构化数据提供一个可靠、通用的组件；非结构化数据访问单元就是为此而设计的。

分布式数据缓存，对于某些较为耗时且相同或近似的计算请求，还能够将请求结果放入缓存中，这样不仅能够降低数据存储模块的访问压力，更能节省大量的计算资源。

分布式数据存储模块还包括描述信息访问单元，并不是所有分布式数据库都支持传统的SQL操作方式，尤其是新兴的MongoDB、HBase、Neo4J NoSQL数据库本身仅仅提供了一些通用而基础的操作接口；为了方便对特定描述信息的访问及操作，有时需要根据具体数据内容对基本操作进行适当封装，提供一个较为专一且方便的接口以供分布式业务处理器使用。

分布式消息中间件，为了保证所有请求都被执行（成功或失败），选用的中间件需要提供超时和显示消息处理回馈机制，以满足整个系统对于可靠性的保证。

本发明的有益效果：本发明所述的分布式处理架构，适用于带有描述信息的海量非结构化数据的实时处理和批量处理，其中包含从数据采集到前端访问的一系列步骤，软件设计人员和开发人员可以据此迅速确定软件架构和部署方案，提供高性能的服务，并可以满足对系统可用性、可扩展性以及容错性方面的要求。

附图说明

图1为一种面向带有描述信息的海量非结构化数据分布式处理架构的示意图；

图2为数据分离及归档存储模块流程图；

图3为流处理模块故障恢复说明图；

图4为单节点业务处理器运行流程；

图5为单个业务处理器处理一次请求的流程。

具体实施方式

下面结合附图与实施例对本发明作进一步说明。

下面结合附图与实施例对本发明作进一步说明。

图1中，一种面向带有描述信息的海量非结构化数据分布式处理架构。它包括以下模块：

模块1.数据采集模块。包含数个采集终端，负责收集非结构化数据并将它们发送至数据缓冲队列中。如果终端设备支持，可以在此完成基本的描述信息识别或标注工作，如果设备较为轻量级则可以将这个工作转移到下个模块中完成。

模块2.数据缓冲及预处理模块。主要包含一级高可用性的分布式缓冲队列，用来暂存数据采集模块发送的数据。此外可能还需添加一个专门单元，用作对数据进行修复或二次识别（如果上个模块内部分终端没有对非结构化数据进行识别或标注则在此处进行），然后将处理后的数据存入二级分布式缓冲队列中，如果具体应用无需此工作，则后两个组件可以省略。

模块3.数据分离及归档存储模块。该模块主要完成如下工作：从前一个模块的分布式队列中获取数据，并根据实际应用可选择的对非结构化数据和描述信息进行分离，然后将分离后的数据转发或存储至后继模块。分离过程中需要添加描述信息到非结构化数据的关联，换言之需要支持根据某条特定的描述信息找到其对应的非结构化数据。通常来看，对于后继的流处理模块，出于效率考虑可能仅需要发送描述信息；而分布式数据存储模块中对于非结构化数据及其描述应该是分别存储的，例如前者可以归档并存入HDFS或其他分布式文件系统，而后者可以存入HBase等分布式数据库中。该模块的高可用性可以通过Heartbeat+虚拟IP的双机冷备实现，通过使用Zookeeper等组件对归档记录进行可靠的存储，来保证数据不会被多次重复归档。

模块4.流处理模块。该模块可基于现有的如S4或Storm等分布式流处理平台实现，主要工作是对最近接入的数据进行实时监测、比对、计算和处理，得到的结果可以实时推送给后继模块中的分布式业务处理器，同时该模块也可以接收分布式业务处理器发来的信息和命令以满足可控性要求。本模块高可用性可以通过内部双机热备实现，即系统内部配置并同步运行两套完全相同的平台，一套作为主平台，另一套作为备份平台只进行计算但不提交最终结果。当主平台发生错误后备份平台可以立即顶替，从而保证系统的正常运行。

模块5.分布式数据存储模块。为满足海量数据需求，该模块中选用两种可靠的分布式存储组件，来对非结构化数据和描述信息进行分别存储。这样不仅可以为结构化程度不同的数据量身打造存储方案，提高数据操作和访问效率，还可以依据数据的重要程度等因素为它们设定不同的存储期限，在一定程度上缓解存储压力。

模块6.分布式业务处理模块。该模块作为应用业务处理的核心模块，主要包括以下几个组件：

（1）分布式业务处理器。该组件由分布在多台节点上的Share-Nothing式业务处理器组成，主要负责接收前端请求，通过与流处理模块交互和利用分布式计算框架如MapReduce，来完成相应业务并向目的组件发送结果。依托于分布式消息中间件，该处理器组件对于前端业务请求应提供负载均衡功能，每个节点上的处理器通过跟踪本地当前正在执行的业务，从消息中间件中挑选“合适”的请求并进行处理。如果某个请求未能正常处理，则应根据实际情况选择返回错误信息或将请求交还消息中间件以供其他节点处理。

（2）非结构化数据访问单元。考虑到执行效率及可实施性，分布式业务处理器中的绝大多数业务可能都不是基于非结构化数据本身而是基于其描述信息的，再加上流处理模块中的数据和分布式存储模块中的数据可能存在不同步的情况（非结构化数据还未来得及归档，仍保留在数据缓冲队列中），有必要为根据描述信息访问其对应的非结构化数据提供一个可靠、通用的组件。非结构化数据访问单元就是为此而设计的，它不仅支持对已归档数据的访问，还能自动到缓冲队列中获取未来及归档的数据，这个过程对使用者而言是完全透明的。该逻辑单元同样可采用Heartbeat+虚拟IP的方案来保证高可用性。

（3）描述信息访问单元（可选）。并不是所有分布式数据库都支持传统的SQL操作方式，尤其是新兴的MongoDB、HBase、Neo4J等NoSQL数据库可能本身仅仅提供了一些通用而基础的操作接口。为了方便对特定描述信息的访问及操作，有时需要根据具体数据内容对基本操作进行适当封装，提供一个较为专一且方便的接口以供分布式业务处理器使用。

（4）分布式数据缓存。无论是对非结构化数据本身还是对其描述信息的访问可能都会存在一定的延迟，分布式数据缓存组件在一定程度上可以缓解这一问题。此外对于特定阶段某些较为耗时且相同或近似的计算请求，还可以将请求结果放入缓存中，这样不仅可以降低数据存储模块的访问压力，更能节省大量的计算资源

模块7.分布式消息中间件。该模块可以使用现成的中间件系统来充当，其主要功能是接收前端请求以供业务处理器选择执行，业务完成结果也是通过该中间件送达前端。为了保证所有请求都被执行（成功或失败），选用的中间件需要提供超时和显示消息处理回馈机制，以满足整个系统对于可靠性的保证。

现结合图2对数据分离及归档存储模块机制做出说明。

（1）模块在启动时首先尝试导入上次归档的写入偏移（用于记录哪些数据已经成功归档）。需要注意的是该模块中用到的偏移有两种，记录归档的偏移叫做写入偏移，而用作标识描述信息存储或发送情况的偏移被称作拉取偏移。由于非结构化信息需要在内存中攒够一定数目才会被归档，因此拉取偏移总通常情况下总会先于写入偏移，而只有数据被归档后才认为是写入成功，因此该模块对于非结构化数据本身的归档可以保证exactly-once语义，而对于描述信息的发送或存储仅能保证at-least-once语义。

（2）初始化工作完成后，系统会依据拉取偏移去数据缓冲队列中拉取数据，成功拉取后依据自定义格式对描述信息和非结构化数据进行分离，建立二者之间的联系工作也是在此时完成。分离后的描述信息立即尝试发送至流处理模块和写入分布式数据库中，两个过程任意一个的失败次数超过一定数值都会导致模块停止运行（由于该模块本身和后继模块都有高可用性保障，因此失败发生概率很低，但不能排除网络或电力等硬件故障）。

（3）描述信息被处理完成后，系统会判断当前内存中的非结构化数据在体积或数量上是否已经满足归档要求。如果满足则对内存中的数据进行归档，并更新写入偏移；如果不满足则将分离后的非结构化数据放入内存数据结构中，以方便将来归档。

（4）无论非结构化数据是否被归档，只要描述信息处理完成便会更新拉取偏移，并依此从数据缓冲队列中获取新的数据。

现结合图3对流处理模块的高可用性机制实现做一个说明。

假设流处理模块有两个主节点1和2，其对应的两个备用节点分别为节点1`和节点2`。其中节点1内有两个运算单元U和X，节点2内有两个运算单元V和Y，同理它们所对应的备用运算单元分别为U`、X`和V`、Y`。假设在某一时刻节点1发生故障，本应从运算单元U发往运算单元Y的数据发生丢失，一旦检测到节点故障，流处理模块立即停止数据流入。由于主平台和备用平台完全一致，因此停止数据流入后备用平台各节点的最终状态一定等价于主平台各节点的最终状态，如图所示，无论数据a和b谁先到达Y`，它们最终都会存在于Y`中。此时将节点2`的状态拷贝到节点2，并以节点1`替代节点1，恢复结束后继续开启数据流入并可以正常进行后续计算，保证系统不会因为单个节点失效而无法正常运作。

下面结合图4和图5对系统业务处理流程做出说明。

（1）业务处理器在启动后首先初始化业务处理线程池，每当收到一个请求都会从线程池中取出一个线程进行处理。

（2）处理器依据自身资源使用情况，从消息中间件中取得一个请求。

（3）对请求进行分析识别，如果成功则进行下面步骤，如果失败则记录并返回未识别请求信息。

（4）针对请求类型，从线程池中取出一个线程开始进行处理。

（5）一旦请求开始处理，便根据请求类型和参数等信息更新自身资源使用情况。之后进行判断，如果系统达到负荷上限则等待已经开始进行的业务结束归还系统资源。

（6）系统有空闲资源时继续重复(2)-(5)过程。

单个业务处理器存在于每个线程之中，其处理过程由一个个最小的基本逻辑处理步骤组成。如图5所示，处理器在收到一次请求后会按照设定一步一步执行每一个处理步骤直到完成。在每个步骤结束后，会向其所在的业务处理器汇报处理进度，且如果超过预设时间还会立即中止对当前请求的处理并返回超时错误。单个业务处理器每次处理无论成功还是失败，最后都会跟随其宿主线程被归还到线程池中，以供其他同类请求使用。

上述虽然结合附图对本发明的具体实施方式进行了描述，但并非对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。

Claims (10)

1.一种面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，它包括以下模块：

数据采集模块，包含数个采集终端，负责收集非结构化数据并将它们发送至数据缓冲及预处理模块的数据分布式缓冲队列中；

数据缓冲及预处理模块，主要包含一级数据分布式缓冲队列，用来暂存数据采集模块发送的数据；

数据分离及归档存储模块，从前一个模块的分布式队列中获取数据，并根据实际应用选择的对非结构化数据和描述信息分离，然后将分离后的数据转发或存储至分布式数据存储模块；

流处理模块，该模块基于现有的S4或Storm分布式流处理平台实现，对最近接入的数据实时监测、比对、计算和处理，得到的结果实时推送给后继模块中的分布式业务处理器，同时该模块也接收分布式业务处理器发来的信息和命令以满足可控性要求；

分布式数据存储模块，为满足海量数据需求，该模块中用两种可靠的分布式存储组件即分布式数据库和分布式文件系统，对非结构化数据和描述信息分别存储；

分布式业务处理模块，该模块作为应用业务处理的核心模块，主要包括以下几个组件：

（1）分布式业务处理器，该组件由分布在多台节点上的Share-Nothing式业务处理器组成，主要负责接收前端请求，通过与流处理模块交互和利用分布式计算框架MapReduce，来完成相应业务并向目的组件发送结果；

（2）非结构化数据访问单元，它不仅支持对已归档数据的访问，还能自动到缓冲队列中获取未来及归档的数据，这个过程对使用者而言是完全透明的；

（3）分布式数据缓存，无论是对非结构化数据本身还是对其描述信息的访问可能都会存在一定的延迟，分布式数据缓存组件能够缓解这一问题；

分布式消息中间件，该模块使用现成的中间件系统来充当，其主要功能是接收前端请求以供分布式业务处理器选择执行，业务完成结果也是通过该中间件经网络送达前端应用。

2.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述数据采集模块中终端设备支持的，则对非结构化数据完成基本的描述信息识别或标注工作。

3.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述数据缓冲及预处理模块中还包括数据修复及二次识别单元和二级分布式数据缓冲队列，数据修复及二次识别单元对数据采集模块中未对非结构化数据进行识别或标注的数据做修复或二次识别，然后将处理后的数据存入二级分布式缓冲队列中。

4.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述数据分离及归档存储模块中，分离过程中需要添加描述信息到非结构化数据的关联，换言之需要支持根据某条特定的描述信息找到其对应的非结构化数据；对于后继的流处理模块，出于效率考虑仅需要描述信息；而分布式数据存储模块中对于非结构化数据及其描述的存储是分离的，前者归档并存入HDFS分布式文件系统，而后者存入HBase分布式数据库中。

5.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，

分布式业务处理模块还包括描述信息访问单元，为了方便对特定描述信息的访问及操作，有时需要根据具体数据内容对基本操作进行适当封装，提供一个较为专一且方便的接口以供分布式业务处理器使用。

6.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，

所述分布式业务处理器中，业务开始的触发模式有三种，分别是：前端请求触发、流处理模块推送触发以及自身计划任务触发，依托于分布式消息中间件，该处理器组件对于业务请求应提供负载均衡功能，每个节点上的处理器通过跟踪本地当前正在执行的业务，从消息中间件中挑选“合适”的请求并处理；当某个请求未能正常处理，则应根据实际情况选择返回错误信息或将请求交还消息中间件以供其他节点处理。

7.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，

所述非结构化数据访问单元的选择是考虑到执行效率及实施性，分布式业务处理器中的绝大多数业务都不是基于非结构化数据本身而是基于其描述信息的，再加上流处理模块中的数据和分布式存储模块中的数据会存在不同步的情况即非结构化数据还未来得及归档，仍保留在数据缓冲队列中，有必要为根据描述信息访问其对应的非结构化数据提供一个可靠、通用的组件，非结构化数据访问单元就是为此而设计的。

8.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述分布式业务处理模块中还包括描述信息访问单元，并不是所有分布式数据库都支持传统的SQL操作方式，尤其是新兴的MongoDB、HBase、Neo4J NoSQL数据库本身仅仅提供了一些通用而基础的操作接口，为了方便对特定描述信息的访问及操作，有时需要根据具体数据内容对基本操作进行适当封装，提供一个专一且方便的接口以供分布式业务处理器使用。

9.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述分布式数据缓存，对于某些较为耗时且相同或近似的计算请求，还能够将请求结果放入缓存中，这样不仅能够降低数据存储模块的访问压力，更能节省大量的计算资源。

10.如权利要求1所述的面向带有描述信息的海量非结构化数据分布式处理架构，其特征是，所述分布式消息中间件，为了保证所有请求都被执行成功或失败，选用的中间件需要提供超时和显示消息处理回馈机制，以满足整个系统对于可靠性的保证。