一种大数据的实时存储、处理和查询系统的制作方法

本发明涉及计算机内部的数据处理，特别涉及大数据实时存储、实时处理分析、实时查询系统。

背景技术：

近几年来，随着计算机和信息技术的迅猛发展和普及应用，行业应用系统的规模迅速扩大，行业应用所产生的数据呈爆炸性增长。动辄达到数百TB甚至数十至数百PB规模的行业/企业大数据已远远超出了现有传统的计算技术和信息系统的实时处理、存储和查询能力，因此，寻求有效的大数据在实时数据中的处理技术、存储、查询等方法和手段已经成为现实世界的迫切需求。

传统的存储系统需要存储的文件将呈指数级增长态势，这就要求存储系统的容量扩展能够跟得上数据量的增长，做到无限扩容，同时在扩展过程中最好还要做到简便易行，不能影响到数据中心的整体运行，如果容量的扩展需要复杂的操作，甚至停机，这无疑会极大地降低数据中心的运营效率。传统的存储系统由于没有采用分布式的文件系统，无法将所有访问压力平均分配到多个存储节点，因而在存储系统与计算系统之间存在着明显的传输瓶颈，由此而带来单点故障等多种后续问题。

传统的数据处理系统主要面向结构化数据的处理，但现实世界中的大数据具有各种不同的格式和形态，据统计现实世界中80％以上的数据都是文本和媒体等非结构化数据；我们不方便从多个角度分类数据的类型和计算特征。对传统的通用系统的要求是大的系统吞吐量，合理的响应速度，对每个系统用户相对公平的进行计算资源的分配。在实时系统中系统的一切动作都以实时任务为中心。实时的数据吞吐取代了以吞吐量为目标的标准。对硬实时应用的优先响应取代了对每个用户的恰当的反应速度。系统的计算资源和其他外设资源必须优先满足实时应用的要求。针对实时系统新的要求，必须以实时的进程调度在实时操作系统中是一个关键性的问题。

传统的查询系统实时采集用户操作产生的互联网数据，并根据采集系统的传输规则将所述数据分类传输给消息订阅系统；所述消息订阅系统根据所述采集系统的传输规则将存储空间划分为不同的目录结构，所述不同的目录结构分别接收并存储由所述采集系统传输的不同类别的所述数据；所述消息订阅系统根据消息订阅系统的配置规则，将所述目录结构中的数据划分为最新数据和过期数据；查询引擎在调度系统的配合下按照调度系统设置的调度规则将所述过期数据迁移至数据仓库工具不同的分区中；弊端是所述查询引擎发起查询请求，数据将不能读取到内存中进行处理，也不可实现高效的海量数据的实时查询。为配合大数据整体实时平台系统，该系统不可避免的要替换新的数据仓库完成数据查询交互。

综上所述，在传统的一站式实时数据存储、数据处理分析、数据查询的系统中，很难做到海量、高速和多变。海量是指数据容量越来越大；高速表示需要处理的速度和响应的时间越来越快，对系统的延时要求相当高；多变就要处理各种各样类型的数据，包括结构化的、半结构化的、甚至是非结构化的数据的方面。因此，要实现一站式的实时大数据系统平台，帮助更多的用户/企业完成数据采集、存储、处理分析、查询的高可用、高吞吐、实时性的系统平台是迫切的，也是未来发展实时数据系统平台的重点所在。

技术实现要素：

本发明的目的针对上述现有存在的问题，实现网络应用上所产生海量数据的存储、处理和查询功能的平台。克服传统技术在海量、高速和多变的实时性数据平台系统的不足，提供一种大数据实时存储、处理分析、查询的平台系统，该系统利用系统总控制模块实现数据帧在各模块之间的调度、流转。

本发明的上述目的是通过如下的技术方案予以实现的：

一种大数据的实时存储、处理和查询系统，包括分布式支撑模块、数据采集模块、消息中间件模块、数据清洗模块、数据处理模块、数据深度挖掘模块、数据管理模块、数据查询模块、系统调度模块；各模块在系统调度模块的协调下运作，实现数据流在各模块之间的调度、流转；分布式支撑模块在物理结构上能够克服单节点限制，通过数据采集模块将多形式、多规格传输类型的网络应用数据流采集，数据流通过消息中间件模块完成消息信息的订阅发布功能，数据流按照规则在数据清洗模块进行数据清洗后，进入到流式引擎数据处理模块，数据流采用数据管理模块中分布式存储系统，完成实时数据的存储过程，数据深度挖掘模块还提供针对数据流的高级模型挖掘分析，数据查询模块对实时数据流信息的查询；

其特征在于：

分布式支撑模块，用于提供多种资源共享和协同计算的能力，其包括HDFS分布式文件系统和YRAN分布式计算框架；

数据采集模块，其信息源为嵌入式设备、网络协议数据、直连数据库、WEB端信息采集系统；

消息中间件模块，采用分布式发布订阅消息系统，先接收发布客户端发布的消息；查找订阅的客户端，其中，订阅客户端订阅的消息的主题和所述发布的消息的主题一样；检测查找到的订阅客户端所设置的会话清理标识的数值；响应于订阅的客户端上设置的会话清洗标识的值，将所述的消息存储在分布式系统中，再将存储在分布式系统中的消息发送给查找到的订阅客户端；

数据清洗模块：用于发现并纠正数据文件中可识别的错误，包括检查数据一致性，处理无效值和缺失值；

数据处理模块：基于MapReduce的分布式计算框架，其核心是弹性分布式数据集，能够快速在内存中对数据集进行多次迭代，以支持复杂的数据挖掘算法和图形计算算法；

数据深度挖掘模块：用于从大量的数据中通过算法搜索隐藏于其中信息，其分析方法包括分类、估计、预测、相关性分组或关联规则、聚类、复杂数据类型挖掘；

数据查询模块：查询存储在Hadoop的HDFS和HBase中的PB级大数据，不需要把中间结果写入磁盘，省掉了大量的I/O开销，省掉了MapReduce作业启动的开销；

数据管理模块：实现数据存储及管理，数据存储对象包括数据流在加工过程中产生的临时文件或加工过程中需要查找的信息；利用Google BigTable技术搭建结构化存储集群；分布式存储系统中的所有数据文件都存储在Hadoop HDFS文件系统上。

本发明与现有技术相比具有如下有益效果：

本发明通过系统调度完成大数据领域的实时数据的处理分析、数据存储、数据查询的系统平台。可以协调各模块之间的处理流程，加快了数据实时性的特定，针对高吞吐、海量级数据、快速响应消息、数据高可用等特点做出了有效的改进，从而提高了大数据实时数据业务系统中综合能力。

在该实时系统平台中增添了可二次开发的数据分析接口，相比一般的数据平台系统，提供了数据挖掘方面的深度学习，机器学习等领域方面的扩展，从而更适合企业级客户在实时数据方面对自身的数据进行有效的挖掘。

附图说明

图1大数据的实时存储、处理和查询系统框架层次图

图2分布式文件系统架构图

图3分布式计算框架

图4消息中间件流程图

图5Resful接口消息示意图

具体实施方式

下面结合附图对本发明做进一步的说明，以下说明只是为了更好理解本发明，不是对本发明的保护范围进行设定。

本发明提供了一种大数据的实时存储、处理和查询系统，可以有效数据实时性的特定，针对高吞吐、海量级数据、快速响应消息、数据高可用等特点做出了有效的改进，从而提高了大数据实时数据业务系统中综合能力。如图1所示的系统组成框图，本发明的大数据实时存储、处理和查询系统包括分布式支撑模块、数据采集模块、消息中间件模块、数据清洗模块、数据处理模块、数据深度挖掘模块、数据管理模块、数据查询模块、系统调度模块。各模块在系统调度模块的协调下统一运作，实现数据流在各模块之间的调度、流转。

各模块组件之间对协同对数据流的处理过程如下：

分布式支撑模块在物理结构上能够克服单节点限制，为数据流提供了硬件平台的保障。通过采集模块完成数据流正式介入该实时数据平台，多形式、多规格传输类型的网络应用数据流采集到数据平台。数据流通过消息中间件完成消息信息的订阅发布功能。数据流经过按照规则进行数据清洗的工作区间后，正式进入到流式引擎数据处理系统，在该系统中完成针对海量数据的主题式规则处理。数据流进行持久性落地，采用分布式存储系统，完成实时数据的存储过程。另外，针对数据流的高级模型挖掘分析，采用一整套机器学习库，能够实现数据建模的高级管理以及深度挖掘功能。对实时流信息的查询与参考信息，可用于对数据流的展示、交换等方面做最基础的处理过程。

下面分别进行说明。

(一)、分布式支撑模块

分布式支撑模块：用于提供多种资源共享和协同计算的能力，可以很好地解决大规模数据的处理问题。分布式平台在物理构成上，各主机之间通过高速的内部网络进行连接，在此基础上配置分布式管理系统，以对外提供硬件共享、软件共享、数据共享、服务共享等多种资源共享服务。分布式文件系统是文件系统管理的物理存储资源不都是直接连接在本地节点上，而是分布在由高速内部网络连接的一组机器节点上，这些机器节点共同构成了一个集群。分布式计算把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，并由许多相互独立的计算机进行协同处理，以得到最终结果。分布式计算是让几个物理上独立的组件作为一个单独的系统协同工作，这些组件可能指多个CPU或者网络中的多台计算机。

分布式文件系统是HDFS，采用master/slave架构。具体可参考附图2。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

分布式计算框架YARN总体上仍然是Master/Slave结构，分布式计算框架可参考附图3，YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成。在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

其算法步骤如下：

步骤1：用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。

步骤3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4～7。

步骤4：ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

步骤5：一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。

步骤6：NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。

步骤7：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。

步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

(二)、数据采集模块

数据采集模块：数据采集的信息源为嵌入式设备、网络协议数据、直连数据库、WEB端信息采集系统等。

其中嵌入式设备中的配备RS232、RS485串口，可连接多个检测仪器实现自动数据采集；可配备USB接口采集网口设备等，配备USB控制器设备采用OHCI，UHCI，EHCI，XHCI标准协议完成采集传输。

配置传输控制协议/网际协议、用户数据报协议、其他网络socket数据流等，支持传统的tcp、udp通用协议，同时也包括HTTP应用层网络协议，通常采用Restful接口形式进行传输数据。为在分层的网络中传输数据，从应用程序传输数据到协议栈中相应的协议。之后，此协议处理完数据之后，将数据传向栈中的下一个协议。在数据穿越每一层协议的同时，协议栈上相应协议为了栈中下一层协议，将数据封装起来，封装就是一个将数据存储成协议栈中更低层协议要求的格式的过程。

可采用传统关系型数据库Mysql，Oracle等，列式数据库Nosql，MongoDB等。进行传统关系数据库的数据存取。通过数据的共享通道，来实现元数据同步，数据库文件的同步与更新。

Web个性化定制采集系统具有多元数据采集端。通过Restful接口作为数据传输的通道，再通过Post请求方式，完成数据的录入，最终可以作为数据源的一种实现方式。

(三)、消息中间件模块

消息中间件模块：消息中间件是用于传输消息的方法和装置。采用高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作流数据(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志、网络协议流和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析系统，但又要求能够实时处理，这是一个可行的解决方案。消息中间件的目的是通过Hadoop的并行加载机制来统一线上和消息处理，也为了通过集群机来提供实时的消费。

具体实施如图4所示：接收发布客户端发布的消息；查找订阅的客户端，其中，订阅客户端订阅的消息的主题和所述发布的消息的主题一样；检测查找到的订阅客户端所设置的会话清理标识的数值；响应于订阅的客户端上设置的会话清洗标识的值，将所述的消息存储在分布式系统中，再将存储在分布式系统中的消息发送给查找到的订阅客户端。

该消息中间件的采用了分布式配置消息队列的传输服务，能够解决流式消息拥塞等问题。

该消息中间件详细说明如下：

1)队列管理器

队列管理器是消息中间件系统中最上层的一个概念，由它提供基于队列的消息服务。

2)消息

在消息中间件中，把应用程序交由消息中间件传输的数据定义为消息，可以定义消息的内容并对消息进行广义的理解，比如：用户的各种类型的数据文件，某个应用向其它应用发出的处理请求等都可以作为消息。

消息有两部分组成：

消息描述符(Message Discription或Message Header)，描述消息的特征，如：消息的优先级、生命周期、消息Id等；

消息体(Message Body)，即用户数据部分。在消息中间件中，消息分为两种类型，非永久性(non-persistent)消息和永久性(persistent)消息，非永久性消息是存储在内存中的，它是为了提高性能而设计的，当系统掉电或消息中间件队列管理器重新启动时，将不可恢复。当用户对消息的可靠性要求不高，而侧重系统的性能表现时，可以采用该种类型的消息，如：当发布股票信息时，由于股票信息是不断更新的，我们可能每若干秒就会发布一次，新的消息会不断覆盖旧的消息。永久性消息是存储在硬盘上，并且纪录数据日志的，它具有高可靠性，在网络和系统发生故障等情况下都能确保消息不丢、不重。

3)队列

队列是消息的安全存放地，队列存储消息直到它被应用程序处理。

消息队列以下述方式工作：

a)程序A形成对消息队列系统的调用，此调用告知消息队列系统，消息准备好了投向程序B；

b)消息队列系统发送此消息到程序B驻留处的系统，并将它放到程序B的队列中；

c)适当时间后，程序B从它的队列中读此消息，并处理此信息。

由于采用了先进的程序设计思想以及内部工作机制，消息中间件能够在各种网络条件下保证消息的可靠传递，可以克服网络线路质量差或不稳定的现状，在传输过程中，如果通信线路出现故障或远端的主机发生故障，本地的应用程序都不会受到影响，可以继续发送数据，而无需等待网络故障恢复或远端主机正常后再重新运行。

在消息中间件中，队列分为很多种类型，其中包括：本地队列、远程队列、模板队列、动态队列、别名队列等。

普通本地队列和传输队列，普通本地队列是应用程序通过API对其进行读写操作的队列；传输队列可以理解为存储-转发队列，比如：将某个消息交给消息中间件系统发送到远程主机，而此时网络发生故障，消息中间件将把消息放在传输队列中暂存，当网络恢复时，再发往远端目的地。

远程队列是目的队列在本地的定义，它类似一个地址指针，指向远程主机上的某个目的队列，它仅仅是个定义，不真正占用磁盘存储空间。

模板队列和动态队列是消息中间件的一个特色，它的一个典型用途是用作系统的可扩展性考虑。可以先创建一个模板队列，当今后需要新增队列时，每打开一个模板队列，消息中间件便会自动生成一个动态队列，还可以指定该动态队列为临时队列或者是永久队列，若为临时队列可以在关闭它的同时将它删除，相反，若为永久队列，可以将它永久保留，为后面所用。

4)通道

通道是消息中间件系统中队列管理器之间传递消息的管道，它是建立在物理的网络连接之上的一个逻辑概念，也是消息中间件产品的核心。

在消息中间件中，主要有三大类通道类型，即消息通道，消息中间件I通道和Cluster通道。消息通道是用于在消息中间件的服务器和服务器之间传输消息的，需要强调指出的是，该通道是单向的，它又有发送(sender)、接收(receive)、请求者(requestor)、服务者(server)等不同类型，供用户在不同情况下使用。消息中间件I通道是消息中间件Client和消息中间件Server之间通讯和传输消息用的，与消息通道不同，它的传输是双向的。群集(Cluster)通道是位于同一个消息中间件群集内部的队列管理器之间通讯使用的。

首先来看本地通讯的情况，应用程序A和应用程序B运行于同一系统A，它们之间可以借助消息队列技术进行彼此的通讯：应用程序A向队列1发送一条信息，而当应用程序B需要时就可以得到该信息。

其次是远程通讯的情况，如果信息传输的目标改为在系统B上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列2发送一条信息，系统A的消息中间件发现Q2所指向的目的队列实际上位于系统B，它将信息放到本地的一个特殊队列-传输队列(Transmission Queue)。建立一条从系统A到系统B的消息通道，消息通道代理将从传输队列中读取消息，并传递这条信息到系统B，然后等待确认。只有消息中间件接到系统B成功收到信息的确认之后，它才从传输队列中真正将该信息删除。如果通讯线路不通，或系统B不在运行，信息会留在传输队列中，直到被成功地传送到目的地。这是消息中间件最基本而最重要的技术--确保信息传输，并且是一次且仅一次(once-and-only-once)的传递。

消息中间件提供了用于应用集成的松耦合的连接方法，因为共享信息的应用不需要知道彼此物理位置(网络地址)；不需要知道彼此间怎样建立通信；不需要同时处于运行状态；不需要在同样的操作系统或网络环境下运行。

消息中间件的基本配置举例

要实现网络上多台主机上的通讯，至少要建立如下消息中间件的对象：

在发送方A：

1)建立队列管理器QMA：crt消息中间件m-q QMA

2)定义本地传输队列：define qlocal(QMB)usage(xmitq)defpsist(yes)

3)创建远程队列：define qremote(QR.TOB)rname(LQB)rqmname(QMB)xmitq(QMB)

4)定义发送通道：define channel(A.TO.B)chltype(sdr)conname(′IP of B′)xmitq(QMB)+trptype(tcp)

在接收方B：

1)建立队列管理器QMB：crt消息中间件m-q QMB

2)定义本地队列QLB：define qlocal(LQB)

3)创建接收通道：define channel(A.TO.B)chltype(rcvr)trptype(tcp)

经过上述配置，就可以实现从主机A到B的单向通讯，若要实现二者之间的双向通讯，可参考此例创建所需要的消息中间件对象。

消息中间件的通讯模式

1)点对点通讯：点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。

2)多点广播：消息中间件适用于不同类型的应用。其中重要的，也是正在发展中的是″多点广播″应用，即能够将消息发送到多个目标站点(Destination List)。可以使用一条消息中间件指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。消息中间件不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，消息中间件将消息的一个复制版本和该系统上接收者的名单发送到目标消息中间件系统。目标消息中间件系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。

3)发布/订阅(Publish/Subscribe)模式：发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。消息中间件Event Broker是专门用于使用发布/订阅技术进行数据通讯的，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。

4)群集(Cluster)：为了简化点对点通讯模式中的系统配置，消息中间件提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。

在实施该消息中间件的方式中，采用高吞吐量的分布式发布订阅消息系统，处理消费者规模的网络数据中的所有动作流数据。对于其他特定的应用，比如消息推送方式，采用redis或者Hbase存储消息，这种场景适用于消息数据较少的情况。

在实时该消息中间件的过程中，将存储在分布式系统中的消息发送给所查找的订阅客户端。分布式系统备份了将要发送的消息信息。如果客户端断开或者超过预定的时间没有收到心跳，可从分布式系统中读取待发送的消息给订阅客户端。

在实时该消息中间件的过程中，响应于所查找的订阅客户端上所设置的会话清理标识的值为真值，将消息存储在所述的订阅客户端的缓存中，再将存储在缓存中的消息发送给订阅客户端，如果客户端断开，就清除该客户端的会话信息，包括缓存信息。

在实施该消息中间件的过程中，分布式系统中所述的消息发送给所查找的订阅客户端，通知订阅客户端从分布式系统读取所述消息；响应于收到的订阅客户端的读取请求，读取所述消息并将读取的消息发送给订阅客户端，并且记录数据的位置的偏移Offset，该偏移Offset记录每条日志的偏移量。

当前读到消息的offset值是由consumer来维护的，因此，consumer可以自己决定如何读取中间件的数据。consumer可以通过重设offset值来重新消费已消费过的数据。不管有没有被消费，broke会保存数据一段时间，这个时间周期是可配置的，只有到了过期时间，才会删除这些数据。

在实施该消息中间件的过程中，上述响应于收到所述的订阅客户端的读取请求，在读取所述的消息并将所读取的消息发送给所述的订阅客户端，包括：根据所述信息的存储位置和所属偏移确定是否需要读取所述消息；响应于确定需要读取所述消息，则读取所述消息并将所读取的消息发送给所述的订阅客户端。可以通过将发送给客户端的数据保存到消息中间件的主题，每个客户端都会分配一个唯一的主题，然后启动一个任务去从这个唯一的主题读取数据。消息中间件采用消息订阅发布模式，是一种客户端采用pull方式进行订阅信息的方式，在API接口注册驱动模块上需要进行默认的事件驱动模式的配置。由于该消息中间件是采用拉的方式去消费数据，在申请中采用事件驱动的方式实现，每次写入的数据都会从返回一个指示消息的存储位置的偏移，同时会记录订阅客户端消费数据的位置偏移用于读取请求中发送，如果消息管道最上面的消息的存储位置偏移大于订阅客户端消费数据的位置偏移，就会有一个任务不停的去读取数据，如果相等之后就停止，如果有新的数据，就会重新启动这个任务，消息中间件读写数据的操作都是(01)的性能，所以即使有很多数据的写入也不会存在任何性能的问题。

当一个中间件块broker出现问题，那么就无法保证数据发送到对应的客户端了，特别是会话清理标识的值为假的客户端，为了优化此问题，可以将会话清理标识的信息写入到消息中间件的主题中。只要其中一个broker和zookeeper失去连接，就认为该broker出现异常情况，zookeeper是维护会话信息的中央，如果失去连接，那么该broker上面的状态信息就不准确，该broker会主动断开所有和他保持连接的客户端，用于会话清理标识。连接其他机器，重新构建会话信息。同时也不会阻塞其他客户端的消息发送。

消息中间件可实现解决网络异构平台间的数据沟通，其步骤流程图可以参考图5中接口消息订阅发布，首先需要将数据通过标准的RestfulProxy代理来完成消息订阅的发布功能，其主要的基本协议是Http协议封装，在通过Partition分区功能指定消费客户端完成消息流过程。

(四)、数据清洗模块

数据清洗模块：用于发现并纠正数据文件中可识别的错误，包括检查数据一致性，处理无效值和缺失值等。因为数据仓库中的数据是面向某一主题的数据的集合，这些数据从多个业务系统中抽取来而且包含历史数据，这样就避免不了有的数据是错误数据、有的数据相互之间有冲突，这些错误的或有冲突的数据显然是不需要的，称为“脏数据”。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。

第一步：初步处理数据。去除不需要的字段，填充缺失内容以业务知识或经验推测填充缺失值；以同一指标的计算结果(均值、中位数、众数等)填充缺失值；以不同指标的计算结果填充缺失值。

第二步：格式内容清洗。如果数据是由系统日志而来，那么通常在格式和内容方面，要与元数据的描述一致。

第三步：逻辑错误清洗。数据去重，去除不合理值，修正矛盾内容。

第四步：非需求数据清洗。把不需要的字段删除。如果数据量没有大到不删除字段就没办法处理的程度，那么尽量不删除字段。

第五步：关联性验证。如果数据有多个来源，那么有必要进行关联性验证。多个来源的数据整合，关联数据变动在数据库模型中检验。

(五)、数据处理模块

数据处理模块：基于MapReduce的分布式计算框架，其核心是弹性分布式数据集，提供了比MapReduce更丰富的模型，可以快速在内存中对数据集进行多次迭代，以支持复杂的数据挖掘算法和图形计算算法。处理大规模流式数据的能力能运行在100以上的结点上，并达到秒级延迟。使用基于内存的Spark作为执行引擎，具有高效和容错的特性。

DStream作为流式计算框架的基础抽象，持续性的数据流。这些数据流既可以通过外部输入源赖获取，也可以通过现有的Dstream的transformation操作来获得。在内部实现上，DStream由一组时间序列上连续的RDD来表示。每个RDD都包含了自己特定时间间隔内的数据流。

流式计算框架初始化：在开始进行DStream操作之前，需要对Streaming进行初始化生成StreamingContext。参数中比较重要的是第一个和第三个，第一个参数是指定Streaming运行的集群地址，而第三个参数是指定Streaming运行时的batch窗口大小。

Streaming的输入操作：目前Streaming已支持了丰富的输入接口，大致分为两类：一类是磁盘输入，如以batch size作为时间间隔监控HDFS文件系统的某个目录，将目录中内容的变化作为Streaming的输入；另一类就是网络流的方式，目前支持Kafka、Flume、Twitter和socket。

Streaming的转换操作：与RDD的操作极为类似，Streaming也就是通过转换操作将一个或多个DStream转换成新的DStream。常用的操作包括map、filter、flatmap和join，以及需要进行shuffle操作等。

(六)、数据深度挖掘模块

数据深度挖掘模块：从大量的数据中通过算法搜索隐藏于其中信息。数据挖掘通常与计算机科学有关，并通过统计、在线分析处理、情报检索、机器学习、专家系统和模式识别等诸多方法来实现上述目标。分析方法包括分类、估计、预测、相关性分组或关联规则、聚类、复杂数据类型挖掘(如针对Text、Web、图形图像、视频、音频等)。提高洞察律，数据挖掘增大对业务的认知，帮助业务目标是所有数据解决方案的来源。业务知识是数据挖掘过程每一步的核心，预测提高了信息泛化能力。

数据深度挖掘模块由以下部分组成：通用的学习算法和工具类，包括分类、回归、聚类、协同过滤、降维，当然也包括调优的部分，即挖掘算法的二次开发集成。具体包括如下：

基本统计：概括统计、相关性、分层取样、假设检验、随机数生成。

离散和连续性数据分析：分类针对离散型数据而言的，回归是针对连续性数据的。其中主要包括线性模型，支持向量机，逻辑回归，线性回归。算法包含有贝叶斯算法，决策树，多种树，随机森林等。

协同过滤：使用交替最小二乘法。

聚类：K均值算法。

降维：奇异值分析，主成分分析PCA。

(七)、数据查询模块

数据查询模块：能查询存储在Hadoop的HDFS和HBase中的PB级大数据。不需要把中间结果写入磁盘，省掉了大量的I/O开销，省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢(默认每个心跳间隔是3秒钟)，计算框架启动分配任务，资源开销很大，时间开销也多，当下次同步心跳的时间是3s的倍数，只有同步心跳后，才能注册任务，正常运行功能。数据仓库直接通过相应的服务进程来进行作业调度，速度加快很多。该数据仓库完全抛弃了MapReduce这个不太适合做SQL查询的范式，通过Mpp方式获得良好的交互式查询模式，节省不必要的shuffle、sort等开销。并且通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。可用C++实现，并且很多有针对性的硬件优化，例如使用SSE指令。使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

第一种应用方式，当应用时通过ODBC，JDBC发送SQL查询给数据仓库(底层由Hive构建)。用户应用可以连接到任何一个分布式数据仓库节点，该分布式数据仓库节点成为这个query的协调者；分布式数据仓库解析query，分析并决定分布式数据仓库实体需要执行什么tasks。执行会针对优化效率进行plan；分布式数据仓库实体访问本地分布式数据库，通过HDFS服务获取数据；每个分布式数据仓库返回数据给协调者分布式数据仓库，协调者返回result给client；

第二种应用方式，对于可视化的Web系统中使用SQL查询数据库信息，可更加简单应用该数据查询模块。

(八)、数据管理模块

数据管理模块：实现数据存储及管理，数据存储对象包括数据流在加工过程中产生的临时文件或加工过程中需要查找的信息。数据以某种格式记录在计算机内部或外部存储介质上。数据存储要命名，这种命名要反映信息特征的组成含义。数据流反映了系统中流动的数据，表现出动态数据的特征；数据存储反映系统中静止的数据，表现出静态数据的特征。分布式的、面向列的开源数据库，一个结构化数据的分布式存储系统。利用了Google文件系统所提供的分布式数据存储一样，不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。

数据管理模块是高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用Google BigTable技术可搭建起大规模结构化存储集群。

分布式存储系统中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括两个文件类型：Hfile和StoreFile，其中Hfile是分布式存储库中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile。

HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。Trailer中有指针指向其他数据块的起始点。File Info中记录了文件的一些Meta信息，Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

Data Block是HBase I/O的基本单元，为了提高效率，RegionServer中有基于LRU的Block Cache机制。每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询。每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成，Magic内容就是一些随机数字，目的是防止数据损坏。

HFile里面的每个KeyValue对是一个简单的byte数组。这个byte数组里面包含了很多项，并且有固定的结构。具体结构：先是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是Key部分，先是一个固定长度的数值，表示RowKey的长度，紧接着是RowKey，然后是第二个固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后又是两个固定长度的数值，分别表示Time Stamp和Key Type。Value部分没有复杂的结构，只是纯粹的二进制数据。

以上所述是本发明的实施例，应当指出的是以上实施例仅用以说明发明的技术方案而非限制，尽管参照教佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的技术和范围。