CN107870763A - 用于创建海量数据实时分拣系统的方法及其装置 - Google Patents

Abstract

本发明涉及用于创建海量数据实时分拣系统的方法及其装置，该方法包括对实时接入数据进行规范设计，并对接入数据进行分配存储；设计编程模型；设计实时计算内部组织；设计实时计算EPL模型。本发明通过对接入数据的设计、分配、编程模型的设计、实时计算内部组织的设计以及实时计算EPL模型的设计，建立分布式的基于push‐subscribe的消息系统，用于实时分拣海量数据，该系统具备快速、可扩展、可持久化的效果，使其可以实时的处理大量数据以满足各种需求场景。

Description

用于创建海量数据实时分拣系统的方法及其装置

技术领域

本发明涉及海量数据分拣方法，更具体地说是指用于创建海量数据实时分拣系统的方法及其装置。

背景技术

当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下三大挑战，如何收集这些巨大的信息、如何分析它以及如何及时做到如上两点；以上三个挑战形成了一个业务需求模型，即生产者生产各种信息，消费者消费信息，而在生产者与消费者之间，需要一个沟通两者的桥梁即消息系统。从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息，即如何进行数据的实时分拣。

目前采用RabbitMQ、ZeroMQ以及ActiveMQ三种消息处理方式进行数据实时分拣，RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议有AMQP、XMPP、SMTP、STOMP，更适合于企业级的开发，同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持；Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃，入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则分拣速率很慢；ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景，ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了，但是ZeroMQ仅提供非持久性的队列，也就是说如果死机，则数据将会丢失；ActiveMQ是Apache下的一个子项目，类似于ZeroMQ，它能够以代理人和点对点的技术实现队列，也存在仅提供非持久性的队列，如果死机，则数据将会丢失。

因此，有必要设计一种用于创建海量数据实时分拣系统的方法，实现具备快速、可扩展、可持久化的效果，实时的处理大量数据以满足各种需求场景。

发明内容

本发明的目的在于克服现有技术的缺陷，提供用于创建海量数据实时分拣系统的方法及其装置。

为实现上述目的，本发明采用以下技术方案：用于创建海量数据实时分拣系统的方法，所述方法包括：

对实时接入数据进行规范设计，并对接入数据进行分配存储；

设计编程模型；

设计实时计算内部组织；

设计实时计算EPL模型。

其进一步技术方案为：设计编程模型的步骤，包括以下具体步骤：

提交作业，并启动任务控制节点；

利用作业内的执行进程以线程方式运行任务；

任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

维护任务控制节点汇报的块的ID；

定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器；

调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段；

将任务调度到执行进程上，并维护任务的运行状态。

其进一步技术方案为：设计实时计算内部组织的步骤，包括以下具体步骤：

获取提交的计算应用，并构建基本运行环境；

向资源管理器注册并申请运行执行进程的资源；

分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上；

根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理；

执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程；

获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器；

写入数据并释放所有任务集的资源。

其进一步技术方案为：所述方法包括：

构建Spark，将Spark批处理程序变成streaming程序。

其进一步技术方案为：构建spark，将spark批处理程序变成streaming程序的步骤，构建spark时需要构建一个静态RDD DAG模板、一个动态工作控制器、DAG实例、任务控制节点以及长时运行任务的保障处理。

其进一步技术方案为：设计实时计算EPL模型的步骤，具体是对实时事件处理引擎进行设计。

本发明还提供了用于创建海量数据实时分拣系统的装置，包括数据设计单元、编程模型设计单元、组织设计单元以及EPL模型设计单元；

所述数据设计单元，用于对实时接入数据进行规范设计，并对接入数据进行分配存储；

所述编程模型设计单元，用于设计编程模型；

所述组织设计单元，用于设计实时计算内部组织；

所述EPL模型设计单元，用于设计实时计算EPL模型。

其进一步技术方案为：所述编程模型设计单元包括提交模块、运行模块、备份模块、维护模块、启动模块、阶段生成模块以及调度模块；

所述提交模块，用于提交作业，并启动任务控制节点；

所述运行模块，用于利用作业内的执行进程以线程方式运行任务；

所述备份模块，用于任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

所述维护模块，用于维护任务控制节点汇报的块的ID；

所述启动模块，用于定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器；

所述阶段生成模块，用于调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段；

所述调度模块，用于将任务调度到执行进程上，并维护任务的运行状态。

其进一步技术方案为：所述组织设计单元包括构建模块、申请模块、分配模块、计算模块、发放模块、反馈模块以及释放模块；

所述构建模块，用于获取提交的计算应用，并构建基本运行环境；

所述申请模块，用于向资源管理器注册并申请运行执行进程的资源；

所述分配模块，用于分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上；

所述计算模块，用于根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理；

所述发放模块，用于执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程；

所述反馈模块，用于获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器；

所述释放模块，用于写入数据并释放所有任务集的资源。

其进一步技术方案为：所述系统还包括Spark构建单元，所述Spark构建单元用于构建Spark，将Spark批处理程序变成streaming程序。

本发明与现有技术相比的有益效果是：本发明的用于创建海量数据实时分拣系统的方法，通过对接入数据的设计、分配、编程模型的设计、实时计算内部组织的设计以及实时计算EPL模型的设计，建立分布式的基于push-subscribe的消息系统，用于实时分拣海量数据，该系统具备快速、可扩展、可持久化的效果，使其可以实时的处理大量数据以满足各种需求场景。

下面结合附图和具体实施例对本发明作进一步描述。

附图说明

图1为本发明具体实施例提供的用于创建海量数据实时分拣系统的方法的流程图；

图2为本发明具体实施例提供的Kafka拓扑结构的示意图；

图3为本发明具体实施例提供的用于创建海量数据实时分拣系统的装置的结构框图；

图4为本发明具体实施例提供的设计实时计算内部组织的示意图；

图5为本发明具体实施例提供的EPL模型的长度窗口的示意图；

图6为本发明具体实施例提供的EPL模型的过滤器的示意图；

图7为本发明具体实施例提供的where过滤的处理模型的示意图；

图8为本发明具体实施例提供的EPL模型的时间窗口的示意图；

图9为本发明具体实施例提供的EPL模型的时间窗口的示意图。

具体实施方式

为了更充分理解本发明的技术内容，下面结合具体实施例对本发明的技术方案进一步介绍和说明，但不局限于此。

如图1～9所示的具体实施例，本实施例提供的用于创建海量数据实时分拣系统的方法，可以运用在处理海量数据的过程中，实现具备快速、可扩展、可持久化的效果，实时的处理大量数据以满足各种需求场景。

如图1所示，本实施例提供的用于创建海量数据实时分拣系统的方法，该方法包括：

S1、对实时接入数据进行规范设计，并对接入数据进行分配存储；

S2、设计编程模型；

S3、设计实时计算内部组织；

S4、设计实时计算EPL模型。

对于上述的S1步骤，如图2所示，一个典型的Kafka集群中包含若干生产者(可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等)，若干代理点(Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高)，若干消费群以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举管理者，以及在消费群发生变化时进行重新平衡，生产者使用push模式将消息发布到代理点，消费者使用pull模式从代理点订阅并消费消息，并形成日志文件，每个日志文件都是一个记录序列，每个记录序列包含一个4字节整型数值(值为N+5)，1个字节的"magic value"，4个字节的CRC校验码，其后跟N个字节的消息体。每条消息都有一个当前Partition下唯一的64字节的offset，它指明了这条消息的起始位置。磁盘上存储的消息格式如下：

message length：4bytes(value:1+4+n)；

"magic"value：1byte；

crc：4bytes；

payload：n bytes。

这个记录序列并非由一个文件构成，而是分成多个部分，每个部分以该部分第一条消息的函数命名并以“.kafka”为后缀，另外会有一个索引文件，它标明了每个部分下包含的登记条目的函数范围。每条消息都被附加到到该分区中，属于顺序写磁盘，因此效率非常高，实现高吞吐率。另外还提供两种策略删除旧数据，一是基于时间，二是基于Partition文件大小。例如可以通过配置$KAFKA_HOME/config/server.properties，让Kafka删除一周前的数据，也可在分区文件超过1GB时，删除旧数据。

Kafka使用zookeeper来存储一些元信息，并使用了zookeeper监测机制来发现元信息的变更并作出相应的动作，比如消费失效，触发负载均衡等。每个消费客户端被创建时，会向zookeeper注册自己的信息，实现负载均衡，当一个kafka代理点启动后，首先会向zookeeper注册自己的节点信息，同时当代理点r和zookeeper断开连接时，此节点信息会被删除；当一个代理点启动时,会向zookeeper注册自己持有的主题和分区信息，仍然是一个临时节点；保证此主题的所有分区都能被此集群所消费，且消费时为了性能考虑，让分区相对均衡的分散到每个消费者上；每个消费者都有一个唯一的ID，可以通过配置文件指定,也可以由系统生成，此ID用来标记消费者信息；当消费者启动时,所触发的操作:首先进行"Consumer id Registry"；在"Consumer id Registry"节点下注册一个监测点用来监听当前集群中其他消费者的离开和加入情况，只要此节点分区下节点列表变更，都会触发此集群下消费者的负载均衡，比如一个消费者失效,那么其他消费者接管该分区。

更进一步地，在某些实施例中，上述的S2步骤，设计编程模型的步骤，包括以下具体步骤：

S21、提交作业，并启动任务控制节点；

S22、利用作业内的执行进程以线程方式运行任务；

S23、任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

S24、维护任务控制节点汇报的块的ID；

S25、定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器；

S26、调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段；

S27、将任务调度到执行进程上，并维护任务的运行状态。

DStream(即Discretized Stream)作为Spark Streaming的基础抽象，它代表持续性的数据流，这些数据流既可以通过外部输入源赖获取，也可以通过现有的Dstream的转换操作来获得。在内部实现上，DStream由一组时间序列上连续的RDD来表示。每个RDD都包含了自己特定时间间隔内的数据流。Spark Streaming根据流式处理在RDD的基础上做一层封装，即建立DStream。

Spark Streaming还提供了窗口的计算，允许通过滑动窗口对数据进行转换；比如：window用于返回一个基于源DStream的窗口批次计算后得到新的DStream；countByWindow用于返回基于滑动窗口的DStream中的元素的数量；reduceByWindow用于基于滑动窗口对源DStream中的元素进行聚合操作，得到一个新的DStream；reduceByKeyAndWindow用于基于滑动窗口对(K，V)键值对类型的DStream中的值按K使用聚合函数func进行聚合操作，得到一个新的DStream；reduceByKeyAndWindow是一个更高效的reduceByKkeyAndWindow()的实现版本，先对滑动窗口中新的时间间隔内数据增量聚合并移去最早的与新增数据量的时间间隔内的数据统计量。例如，计算t+4秒这个时刻过去5秒窗口的WordCount，那么我们可以将t+3时刻过去5秒的统计量加上[t+3，t+4]的统计量，在减去[t-2，t-1]的统计量，这种方法可以复用中间三秒的统计量，提高统计的效率；countByValueAndWindow用于基于滑动窗口计算源DStream中每个RDD内每个元素出现的频次并返回DStream[(K,Long)]，其中K是RDD中元素的类型，Long是元素频次。与countByValue一样，reduce任务的数量可以通过一个可选参数进行配置。通过窗口滑动进行计算，可以提高海量数据实时分拣时的计算效率，具备快速的效果。

更进一步地，在某些实施例中，上述的S3步骤，设计实时计算内部组织的步骤，包括以下具体步骤：

S31、获取提交的计算应用，并构建基本运行环境；

S32、向资源管理器注册并申请运行执行进程的资源；

S33、分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上；

S34、根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理；

S35、执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程；

S36、获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器；

S37、写入数据并释放所有任务集的资源。

Spark运行架构包括集群资源管理器、运行作业任务的工作节点、每个应用的任务控制节点和每个工作节点上负责具体任务的执行进程。其中，集群资源管理器可以是Spark自带的资源管理器，也可以是YARN或Mesos等资源管理框架。与Hadoop MapReduce计算框架相比，Spark所采用的执行进程有两个优点：一是利用多线程来执行具体的任务(HadoopMapReduce采用的是进程模型)，减少任务的启动开销；二是执行进程中有一个BlockManager存储模块，会将内存和磁盘共同作为存储设备，当需要多轮迭代计算时，可以将中间结果存储到这个存储模块里，下次需要时，就可以直接读该存储模块里的数据，而不需要读写到HDFS等文件系统里，因而有效减少了IO开销；或者在交互式查询场景下，预先将表缓存到该存储系统上，从而可以提高读写IO性能。在Spark中，一个应用由一个任务控制节点和若干个作业构成，一个作业由多个阶段构成，一个阶段由多个任务组成。当执行一个应用时，任务控制节点会向集群管理器申请资源，启动执行进程，并向执行进程发送应用程序代码和文件，然后在执行进程上执行任务，运行结束后，执行结果会返回给任务控制节点，或者写到HDFS或者其他数据库中。

对于上述的S31步骤，具体是由任务控制节点创建一个Spark Context，由SparkContext负责和资源管理器的通信以及进行资源的申请、任务的分配和监控等。SparkContext会向资源管理器注册并申请运行执行任务的资源。

对于上述的S34步骤，Spark Context根据RDD的依赖关系构建DAG图，DAG图提交给DAG调度器进行解析，将DAG图分解成多个“阶段”(每个阶段都是一个任务集)，并且计算出各个阶段之间的依赖关系，把一个个“任务集”提交给底层的任务调度器进行处理；执行进程向Spark Context申请任务，任务调度器将任务分发给执行进程运行，同时，SparkContext将应用程序代码发放给执行进程。

当用户应用新的Spark Context后，集群就会为在任务列表上分配执行进程，以单机的集群为例，任务调度器是通过不同的Scheduler Backend来调度和管理任务。它包含资源分配和任务调度。它实现了FIFO调度和FAIR调度，基于此来决定不同任务之间的调度顺序。并且管理任务，包括任务的提交和终止，为饥饿任务启动备份任务。不同的集群，包括本地模式，都是通过不同的Scheduler Backend的实现其不同的功能。

刚获取来的文件部分存放在软件缓冲区，经过处理后的数据放在内存+磁盘上。处理后的数据，可以灵活设置为“只用内存”或者“内存+磁盘”。如果spark.shuffle.spill＝false，则只用内存从存储处理后锷数据。由于不要求数据有序，块索引将数据区分好，并持久化，，一方面是要减少内存存储空间压力，另一方面也是为了容错。清洗部分之所以需要把中间结果放到磁盘文件中，是因为虽然上一批任务结束了，下一批任务还需要使用内存。如果全部放在内存中，内存会不够。另外一方面为了容错，防止任务挂掉。

本实施例中还使用文件合并的方式解决磁盘上存在大量的数据文件以及缓冲区占用内存空间大这两个问题，具体地，在一个要点上连续执行的索引映射任务可以共用一个输出文件索引部分。先执行完的索引映射任务形成索引块，后执行的索引映射任务可以将输出数据直接追加到索引块后面，形成索引块'，每个索引块被称为文件部分。下一个阶段的生产者只需要获取整个索引部分就行了。这样，每个工作者持有的文件数降为cores×R。FileConsolidation功能可以通过spark.shuffle.consolidateFiles＝true来开启。

Spark程序是使用一个spark应用实例一次性对一批历史数据进行处理，Sparkstreaming是将持续不断输入的数据流转换成多个分批处理的分片，使用一批Spark应用实例进行处理。

更进一步地，在某些实施例中，上述的方法包括：

构建Spark，将Spark批处理程序变成streaming程序。

另外，该构建spark，将spark批处理程序变成streaming程序的步骤，构建spark时需要构建一个静态RDD DAG模板、一个动态工作控制器、DAG实例、任务控制节点以及长时运行任务的保障处理。

一个静态RDD DAG模板表示处理逻辑；一个动态的工作控制器将连续的引擎日志切分数据片段，并按照模板复制出新的RDD；DAG的实例对数据片段进行处理；任务控制节点进行原始数据的产生和导入；任务控制节点将接收到的数据合并为数据块并存到内存或硬盘中，供后续分批处理的RDD进行消费；对长时运行任务的保障，包括输入数据的失效后的重构，处理任务的失败后的重调。

更进一步地，上述的S4步骤，设计实时计算EPL模型的步骤，具体是对实时事件处理引擎进行设计。

出版的处理模型是持续性的——根据报表中事件流、视图、过滤器等的选择，出版引擎一旦处理事件数据，就会变更报表中监听或用户接收到事件信息。实时事件处理引擎还表示新事件进入到引擎，并进入到事件窗口等。当使用实时事件处理引擎内的IRStream时，EPL中就会有事件窗口——长度窗口或者时间窗口的使用。比如下面的EPL语句：select*from Withdrawal.win:length(5)。这个EPL语句使用了长度窗口(lengthwindow)—win:length(N)。表示引擎会将过去的n条事件保存在事件流中，如图5所示。win:length(5)在字串流中最多保存5条数据，当W5作为新事件进入到事件窗口时，此时窗口中的数据条数为5，达到了窗口的最大长度；W6事件进入时，则把W1从窗口中移除出去——遵循的是FIFO原则(先进先出)，每一个进入的新事件都会在监听中作为新事件输出，只有窗口长度5的情况下，才会有旧事件的输出。比如当W6进入时，监听中的新事件为W6，而W1则作为旧事件被监听获取。在这个EPL中，有一个特殊的语法也就是Withdrawal(amount>＝200)，通过Stream(表达式)的语法，即为filter。其实现的功能是对即将进入到事件窗口的事件进行过滤，满足条件的事件，则被放入到窗口中。上面EPL表达的是只有amount>＝200的withdrawal事件，才可以被放入到长度为5的事件窗口。换句话说，这个事件窗口中所有的事件，其amount属性都不小于200，如图6所示，每一个进入的事件，首先通过过滤器，当满足过滤器条件时，才会放入到事件窗口；而进入事件窗口的同时，引擎也会将该事件作为新事件推送给监听或者用户，如图7所示。当有新事件进入时，会先进入到事件窗口；在引擎要将事件推送给监听之前，判断where条件，满足where条件的事件，才会作为新事件传送给监听。实时事件处理引擎还包括时间窗口，其为一个滑动的事件窗口，其以系统时间为准，延伸到过去指定的时间间隔。比如win:time(10seconds)，这个时间窗口保存的事件是当前时间以及此前10秒这一时间间隔的所有事件。比如下面的EPL语句：select*fromWithdrawal.win:time(4sec)表示时间窗口中的事件是过去4秒钟所有的withdrawal事件，如图8所示。当第一个事件W1在t+4时刻进入到引擎时，其时间窗口从t到t+4这一时间段，只有一个事件W1，同时该事件作为新事件推送给监听；当在t+5时刻，W2进入到引擎，此时事件窗口的时间范围为t+1～t+5，窗口数据为W1和W2，而此时W2也作为新事件输出到监听。时间窗口随着系统时间的变化，其窗口表示的时间范围也发送变化，当在t+8时，因为在t+4(其实是个临界点)这个时刻进入的W1，因为已经不在该时间窗口，故W1作为旧事件被推送给监听，如图9所示。实时事件处理引擎也包括批量窗口，批量窗口包括时间批量窗口和长度批量窗口。首先从时间批量开始，Time bath view缓存事件信息并且按照指定时间间隔在一次变更中释放所有缓存的事件。EPL如下：select*from Withdrawal.win:time_batch(4sec)上述时间批量窗口表示每隔4s形成一个事件窗口，老的窗口中的所有事件则作为新事件推送给监听。t+1时，W1事件发生并进入批量缓存，此时不会通知监听；t+3时，W2事件发生并进入批量缓存，不通知监听；t+4时，满足了窗口间隔时间，此时缓存中有两个事件W1和W2，引擎处理，并通知监听，此时输出事件为W1和W2。此时创建一个新的bath buffer；t+6与t+7之间有事件W3进入bath buffer，监听无动作；+8时，引擎处理bath缓存中的事件，并传递给监听。此时输出事件为W3。Old Events中包括了W1和W2，上述的实时事件处理引擎还包括长度批量窗口，基本上与时间批量窗口一样，比如：select*from withdrawal.win:length_batch(5)，长度批量窗口，每当窗口事件总数达到5条时，则创建一个新的batchbuffer，而老的事件窗口中5条事件作为新事件输出到监听。

过滤器和where的区别在于条件执行的时机，过滤器是事件进入事件窗口之前就进行了过滤，不满足条件的事件不会进入到窗口，更不会交付给引擎进行处理；而where则是从事件窗口中取出事件，通过引擎进行条件筛选，满足条件的事件则作为新事件交付给监听。从这个地方，可以看出，在过滤相同条件时，过滤器的效率会高于where，所以在能使用过滤器的时候，尽量不要使用where语句进行事件筛选。事件窗口——时间窗口和长度窗口，这里时间窗口时一个滑动的窗口，随着时间推移，窗口也在不断移动；长度窗口更像是一个固定长度的队列，当达到窗口的总容量时，移除窗口中最先进入的事件，并作为旧事件交付给监听。批量窗口其实就是每个多久或者每个多少条事件做一次输出，本次输出的内容为新事件；当下一次输出时，上一次输出的新事件也就成了本次输出的旧事件。

上述的用于创建海量数据实时分拣系统的方法，通过对接入数据的设计、分配、编程模型的设计、实时计算内部组织的设计以及实时计算EPL模型的设计，建立分布式的基于push-subscribe的消息系统，用于实时分拣海量数据，该系统具备快速、可扩展、可持久化的效果，使其可以实时的处理大量数据以满足各种需求场景。

如图3所示，本实施例还提供了用于创建海量数据实时分拣系统的装置，其包括数据设计单元1、编程模型设计单元2、组织设计单元3以及EPL模型设计单元4。

数据设计单元1，用于对实时接入数据进行规范设计，并对接入数据进行分配存储。

编程模型设计单元2，用于设计编程模型。

组织设计单元3，用于设计实时计算内部组织。

EPL模型设计单元4，用于设计实时计算EPL模型。

更进一步地，在某些实施例中，编程模型设计单元2包括提交模块、运行模块、备份模块、维护模块、启动模块、阶段生成模块以及调度模块。

提交模块，用于提交作业，并启动任务控制节点。

运行模块，用于利用作业内的执行进程以线程方式运行任务。

备份模块，用于任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

维护模块，用于维护任务控制节点汇报的块的ID。

启动模块，用于定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器。

阶段生成模块，用于调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段。

调度模块，用于将任务调度到执行进程上，并维护任务的运行状态。

DStream(即Discretized Stream)作为Spark Streaming的基础抽象，它代表持续性的数据流，这些数据流既可以通过外部输入源赖获取，也可以通过现有的Dstream的转换操作来获得。在内部实现上，DStream由一组时间序列上连续的RDD来表示。每个RDD都包含了自己特定时间间隔内的数据流。Spark Streaming根据流式处理在RDD的基础上做一层封装，即建立DStream。

Spark Streaming还提供了窗口的计算，允许通过滑动窗口对数据进行转换；比如：window用于返回一个基于源DStream的窗口批次计算后得到新的DStream；countByWindow用于返回基于滑动窗口的DStream中的元素的数量；reduceByWindow用于基于滑动窗口对源DStream中的元素进行聚合操作，得到一个新的DStream；reduceByKeyAndWindow用于基于滑动窗口对(K，V)键值对类型的DStream中的值按K使用聚合函数func进行聚合操作，得到一个新的DStream；reduceByKeyAndWindow是一个更高效的reduceByKkeyAndWindow()的实现版本，先对滑动窗口中新的时间间隔内数据增量聚合并移去最早的与新增数据量的时间间隔内的数据统计量。例如，计算t+4秒这个时刻过去5秒窗口的WordCount，那么我们可以将t+3时刻过去5秒的统计量加上[t+3，t+4]的统计量，在减去[t-2，t-1]的统计量，这种方法可以复用中间三秒的统计量，提高统计的效率；countByValueAndWindow用于基于滑动窗口计算源DStream中每个RDD内每个元素出现的频次并返回DStream[(K,Long)]，其中K是RDD中元素的类型，Long是元素频次。与countByValue一样，reduce任务的数量可以通过一个可选参数进行配置。通过窗口滑动进行计算，可以提高海量数据实时分拣时的计算效率，具备快速的效果。

更进一步地，在某些实施例中，上述的组织设计单元3包括构建模块、申请模块、分配模块、计算模块、发放模块、反馈模块以及释放模块。

构建模块，用于获取提交的计算应用，并构建基本运行环境。

申请模块，用于向资源管理器注册并申请运行执行进程的资源。

分配模块，用于分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上。

计算模块，用于根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理。

发放模块，用于执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程。

反馈模块，用于获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器。

释放模块，用于写入数据并释放所有任务集的资源。

Spark运行架构包括集群资源管理器、运行作业任务的工作节点、每个应用的任务控制节点和每个工作节点上负责具体任务的执行进程。其中，集群资源管理器可以是Spark自带的资源管理器，也可以是YARN或Mesos等资源管理框架。与Hadoop MapReduce计算框架相比，Spark所采用的执行进程有两个优点：一是利用多线程来执行具体的任务(HadoopMapReduce采用的是进程模型)，减少任务的启动开销；二是执行进程中有一个BlockManager存储模块，会将内存和磁盘共同作为存储设备，当需要多轮迭代计算时，可以将中间结果存储到这个存储模块里，下次需要时，就可以直接读该存储模块里的数据，而不需要读写到HDFS等文件系统里，因而有效减少了IO开销；或者在交互式查询场景下，预先将表缓存到该存储系统上，从而可以提高读写IO性能。在Spark中，一个应用由一个任务控制节点和若干个作业构成，一个作业由多个阶段构成，一个阶段由多个任务组成。当执行一个应用时，任务控制节点会向集群管理器申请资源，启动执行进程，并向执行进程发送应用程序代码和文件，然后在执行进程上执行任务，运行结束后，执行结果会返回给任务控制节点，或者写到HDFS或者其他数据库中。

对于上述的构建模块，具体是由任务控制节点创建一个Spark Context，由SparkContext负责和资源管理器的通信以及进行资源的申请、任务的分配和监控等。SparkContext会向资源管理器注册并申请运行执行任务的资源。

对于上述的计算模块，Spark Context根据RDD的依赖关系构建DAG图，DAG图提交给DAG调度器进行解析，将DAG图分解成多个“阶段”(每个阶段都是一个任务集)，并且计算出各个阶段之间的依赖关系，把一个个“任务集”提交给底层的任务调度器进行处理；执行进程向Spark Context申请任务，任务调度器将任务分发给执行进程运行，同时，SparkContext将应用程序代码发放给执行进程。

当用户应用新的Spark Context后，集群就会为在任务列表上分配执行进程，以单机的集群为例，任务调度器是通过不同的Scheduler Backend来调度和管理任务。它包含资源分配和任务调度。它实现了FIFO调度和FAIR调度，基于此来决定不同任务之间的调度顺序。并且管理任务，包括任务的提交和终止，为饥饿任务启动备份任务。不同的集群，包括本地模式，都是通过不同的Scheduler Backend的实现其不同的功能。

刚获取来的文件部分存放在软件缓冲区，经过处理后的数据放在内存+磁盘上。处理后的数据，可以灵活设置为“只用内存”或者“内存+磁盘”。如果spark.shuffle.spill＝false，则只用内存从存储处理后锷数据。由于不要求数据有序，块索引将数据区分好，并持久化，，一方面是要减少内存存储空间压力，另一方面也是为了容错。清洗部分之所以需要把中间结果放到磁盘文件中，是因为虽然上一批任务结束了，下一批任务还需要使用内存。如果全部放在内存中，内存会不够。另外一方面为了容错，防止任务挂掉。

本实施例中还使用文件合并的方式解决磁盘上存在大量的数据文件以及缓冲区占用内存空间大这两个问题，具体地，在一个要点上连续执行的索引映射任务可以共用一个输出文件索引部分。先执行完的索引映射任务形成索引块，后执行的索引映射任务可以将输出数据直接追加到索引块后面，形成索引块'，每个索引块被称为文件部分。下一个阶段的生产者只需要获取整个索引部分就行了。这样，每个工作者持有的文件数降为cores×R。FileConsolidation功能可以通过spark.shuffle.consolidateFiles＝true来开启。

Spark程序是使用一个spark应用实例一次性对一批历史数据进行处理，Sparkstreaming是将持续不断输入的数据流转换成多个分批处理的分片，使用一批Spark应用实例进行处理。

更进一步地，在某些实施例中，上述的系统还包括Spark构建单元，所述Spark构建单元用于构建Spark，将spark批处理程序变成streaming程序。

另外，该构建spark，将spark批处理程序变成streaming程序的步骤，构建spark时需要构建一个静态RDD DAG模板、一个动态工作控制器、DAG实例、任务控制节点以及长时运行任务的保障处理。

一个静态RDD DAG模板表示处理逻辑；一个动态的工作控制器将连续的引擎日志切分数据片段，并按照模板复制出新的RDD；DAG的实例对数据片段进行处理；任务控制节点进行原始数据的产生和导入；任务控制节点将接收到的数据合并为数据块并存到内存或硬盘中，供后续分批处理的RDD进行消费；对长时运行任务的保障，包括输入数据的失效后的重构，处理任务的失败后的重调。

更进一步地，上述的EPL模型设计单元，具体是对实时事件处理引擎进行设计。

出版的处理模型是持续性的——根据报表中事件流、视图、过滤器等的选择，出版引擎一旦处理事件数据，就会变更报表中监听或用户接收到事件信息。实时事件处理引擎还表示新事件进入到引擎，并进入到事件窗口等。当使用实时事件处理引擎内的IRStream时，EPL中就会有事件窗口——长度窗口或者时间窗口的使用。比如下面的EPL语句：select*from Withdrawal.win:length(5)。这个EPL语句使用了长度窗口(lengthwindow)—win:length(N)。表示引擎会将过去的n条事件保存在事件流中，如图5所示。win:length(5)在字串流中最多保存5条数据，当W5作为新事件进入到事件窗口时，此时窗口中的数据条数为5，达到了窗口的最大长度；W6事件进入时，则把W1从窗口中移除出去——遵循的是FIFO原则(先进先出)，每一个进入的新事件都会在监听中作为新事件输出，只有窗口长度5的情况下，才会有旧事件的输出。比如当W6进入时，监听中的新事件为W6，而W1则作为旧事件被监听获取。在这个EPL中，有一个特殊的语法也就是Withdrawal(amount>＝200)，通过Stream(表达式)的语法，即为filter。其实现的功能是对即将进入到事件窗口的事件进行过滤，满足条件的事件，则被放入到窗口中。上面EPL表达的是只有amount>＝200的withdrawal事件，才可以被放入到长度为5的事件窗口。换句话说，这个事件窗口中所有的事件，其amount属性都不小于200，如图6所示，每一个进入的事件，首先通过过滤器，当满足过滤器条件时，才会放入到事件窗口；而进入事件窗口的同时，引擎也会将该事件作为新事件推送给监听或者用户，如图7所示。当有新事件进入时，会先进入到事件窗口；在引擎要将事件推送给监听之前，判断where条件，满足where条件的事件，才会作为新事件传送给监听。实时事件处理引擎还包括时间窗口，其为一个滑动的事件窗口，其以系统时间为准，延伸到过去指定的时间间隔。比如win:time(10seconds)，这个时间窗口保存的事件是当前时间以及此前10秒这一时间间隔的所有事件。比如下面的EPL语句：select*fromWithdrawal.win:time(4sec)表示时间窗口中的事件是过去4秒钟所有的withdrawal事件，如图8所示。当第一个事件W1在t+4时刻进入到引擎时，其时间窗口从t到t+4这一时间段，只有一个事件W1，同时该事件作为新事件推送给监听；当在t+5时刻，W2进入到引擎，此时事件窗口的时间范围为t+1～t+5，窗口数据为W1和W2，而此时W2也作为新事件输出到监听。时间窗口随着系统时间的变化，其窗口表示的时间范围也发送变化，当在t+8时，因为在t+4(其实是个临界点)这个时刻进入的W1，因为已经不在该时间窗口，故W1作为旧事件被推送给监听，如图9所示。实时事件处理引擎也包括批量窗口，批量窗口包括时间批量窗口和长度批量窗口。首先从时间批量开始，Time bath view缓存事件信息并且按照指定时间间隔在一次变更中释放所有缓存的事件。EPL如下：select*from Withdrawal.win:time_batch(4sec)上述时间批量窗口表示每隔4s形成一个事件窗口，老的窗口中的所有事件则作为新事件推送给监听。t+1时，W1事件发生并进入批量缓存，此时不会通知监听；t+3时，W2事件发生并进入批量缓存，不通知监听；t+4时，满足了窗口间隔时间，此时缓存中有两个事件W1和W2，引擎处理，并通知监听，此时输出事件为W1和W2。此时创建一个新的bath buffer；t+6与t+7之间有事件W3进入bath buffer，监听无动作；+8时，引擎处理bath缓存中的事件，并传递给监听。此时输出事件为W3。Old Events中包括了W1和W2，上述的实时事件处理引擎还包括长度批量窗口，基本上与时间批量窗口一样，比如：select*from withdrawal.win:length_batch(5)，长度批量窗口，每当窗口事件总数达到5条时，则创建一个新的batchbuffer，而老的事件窗口中5条事件作为新事件输出到监听。

过滤器和where的区别在于条件执行的时机，过滤器是事件进入事件窗口之前就进行了过滤，不满足条件的事件不会进入到窗口，更不会交付给引擎进行处理；而where则是从事件窗口中取出事件，通过引擎进行条件筛选，满足条件的事件则作为新事件交付给监听。从这个地方，可以看出，在过滤相同条件时，过滤器的效率会高于where，所以在能使用过滤器的时候，尽量不要使用where语句进行事件筛选。事件窗口——时间窗口和长度窗口，这里时间窗口时一个滑动的窗口，随着时间推移，窗口也在不断移动；长度窗口更像是一个固定长度的队列，当达到窗口的总容量时，移除窗口中最先进入的事件，并作为旧事件交付给监听。批量窗口其实就是每个多久或者每个多少条事件做一次输出，本次输出的内容为新事件；当下一次输出时，上一次输出的新事件也就成了本次输出的旧事件。

上述的用于创建海量数据实时分拣系统的装置，通过对接入数据的设计、分配、编程模型的设计、实时计算内部组织的设计以及实时计算EPL模型的设计，建立分布式的基于push-subscribe的消息系统，用于实时分拣海量数据，该系统具备快速、可扩展、可持久化的效果，使其可以实时的处理大量数据以满足各种需求场景。

上述仅以实施例来进一步说明本发明的技术内容，以便于读者更容易理解，但不代表本发明的实施方式仅限于此，任何依本发明所做的技术延伸或再创造，均受本发明的保护。本发明的保护范围以权利要求书为准。

Claims (10)

1.用于创建海量数据实时分拣系统的方法，其特征在于，所述方法包括：

对实时接入数据进行规范设计，并对接入数据进行分配存储；

设计编程模型；

设计实时计算内部组织；

设计实时计算EPL模型。

2.根据权利要求1所述的用于创建海量数据实时分拣系统的方法，其特征在于，设计编程模型的步骤，包括以下具体步骤：

提交作业，并启动任务控制节点；

利用作业内的执行进程以线程方式运行任务；

任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

维护任务控制节点汇报的块的ID；

定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器；

调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段；

将任务调度到执行进程上，并维护任务的运行状态。

3.根据权利要求2所述的用于创建海量数据实时分拣系统的方法，其特征在于，设计实时计算内部组织的步骤，包括以下具体步骤：

获取提交的计算应用，并构建基本运行环境；

向资源管理器注册并申请运行执行进程的资源；

分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上；

根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理；

执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程；

获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器；

写入数据并释放所有任务集的资源。

4.根据权利要求3所述的用于创建海量数据实时分拣系统的方法，其特征在于，所述方法包括：

构建Spark，将Spark批处理程序变成streaming程序。

5.根据权利要求4所述的用于创建海量数据实时分拣系统的方法，其特征在于，构建spark，将spark批处理程序变成streaming程序的步骤，构建spark时需要构建一个静态RDDDAG模板、一个动态工作控制器、DAG实例、任务控制节点以及长时运行任务的保障处理。

6.根据权利要求5所述的用于创建海量数据实时分拣系统的方法，其特征在于，设计实时计算EPL模型的步骤，具体是对实时事件处理引擎进行设计。

7.用于创建海量数据实时分拣系统的装置，其特征在于，包括数据设计单元、编程模型设计单元、组织设计单元以及EPL模型设计单元；

所述数据设计单元，用于对实时接入数据进行规范设计，并对接入数据进行分配存储；

所述编程模型设计单元，用于设计编程模型；

所述组织设计单元，用于设计实时计算内部组织；

所述EPL模型设计单元，用于设计实时计算EPL模型。

8.根据权利要求7所述的用于创建海量数据实时分拣系统的装置，其特征在于，所述编程模型设计单元包括提交模块、运行模块、备份模块、维护模块、启动模块、阶段生成模块以及调度模块；

所述提交模块，用于提交作业，并启动任务控制节点；

所述运行模块，用于利用作业内的执行进程以线程方式运行任务；

所述备份模块，用于任务控制节点接收接入数据，生成块，将块的ID汇报给任务控制节点，并备份到另外一个执行进程；

所述维护模块，用于维护任务控制节点汇报的块的ID；

所述启动模块，用于定时启动任务发生器，根据仿真器的关系生成逻辑RDD，创建任务椎并发送至任务调度器；

所述阶段生成模块，用于调度任务椎并发送至给DAG调度器，DAG调度器根据逻辑RDD生成相应的阶段；

所述调度模块，用于将任务调度到执行进程上，并维护任务的运行状态。

9.根据权利要求8所述的用于创建海量数据实时分拣系统的装置，其特征在于，所述组织设计单元包括构建模块、申请模块、分配模块、计算模块、发放模块、反馈模块以及释放模块；

所述构建模块，用于获取提交的计算应用，并构建基本运行环境；

所述申请模块，用于向资源管理器注册并申请运行执行进程的资源；

所述分配模块，用于分配资源至执行进程，并启动执行进程，执行进程运行情况发送至资源管理器上；

所述计算模块，用于根据RDD的依赖关系构建DAG图，并发送至DAG调度器进行解析将DAG图分解成多个阶段，计算出各个阶段之间的依赖关系，将阶段的任务集提交至底层的任务调度器进行处理；

所述发放模块，用于执行进程向SparkContext申请任务，任务调度器将任务分发给执行进程运行，且将应用程序代码发放给执行进程；

所述反馈模块，用于获取执行进程运行任务的执行结果，并反馈给任务调度器以及DAG调度器；

所述释放模块，用于写入数据并释放所有任务集的资源。

10.根据权利要求9所述的用于创建海量数据实时分拣系统的装置，其特征在于，所述系统还包括Spark构建单元，所述Spark构建单元用于构建Spark，将Spark批处理程序变成streaming程序。