[发明专利]支持高并发的分布式内存计算集群系统

说明书

本发明申请提供了一种保持高并发的分布式内存计算集群系统，包括：Master节点、多个Node节点、集群管理部件和数据库，Master节点，主要功能为接收请求，预分析请求，分配和调度作业、集群监控、收集和返回分析结果。Master节点包括请求分析器、作业调度控制器、作业监视器、集群监视器、请求队列、作业队列和耗时作业队列，Node节点包括任务分析器、任务调度控制器、任务监视器、数据加载引擎、任务队列、数据缓冲区和中间结果缓冲区，集群管理部件主要用于监控和维护整个集群的健康状态，数据库，用于储存历史分片数据和实时数据。能够有效降低“框架消耗”，并能实现数据预加载、请求预分析及纯内存操作。

技术领域

本发明涉及一种软件工程、大数据以及分布式存储和计算等领域，尤其涉及一种支持高并发的分布式内存计算集群系统。

背景技术

随着计算机硬件和大数据技术的发展，在这个信息爆炸的时代，人们渴望从海量数据中快速地统计和获取有价值的信息，这些信息对于企业的发展以及人们的生活有着重要的决策和参考作用。

目前可行性技术方案总结如下：使用hadoop或spark技术，例如，使用hdfs/habse作为数据存储引擎，使用map/reduce或spark技术作为离线数据分析引擎，使kafka、spark-streaming或storm作为实时数据分析引擎。

虽然上述技术方案也能对数据进行分析计算，但是个人认为仍然有存在一些不足，现总结如下：

a)“框架消耗”现象普遍存在。不少大数据技术框架为了达到“综合性”和“共性”，对于一些用之甚少、较难实现而又必须要有的功能，往往采取一些“折中”的办法来实现它们，这在一定程度上牺牲了框架“整体性能”。使用“二八定律”很容易理解，即使用率较高的百分之八十的功能的运作只需要占用百分之二十的资源，而使用率较低的百分之二十的算法却占用着高达百分之八十的资源。为了满足了“综合性”而削弱了“专业性”。这明显不能满足一些并发性和性能要求较高的需求。

b)存在“数据加载”消耗现象。一般大数据分析引擎完成一次请求需要：①加载数据②分析③保存或返回结果这三个环节，而加载数据环节往往是最耗时的，一般需要建立连接、检索数据、传输数据这三个步骤，每个步骤都需要消耗一定的时间，特别是检索数据和传输数据环节，对于数据量比较大的请求，光“加载数据”就要耗费10s加的时间，这还未考虑非并发数据或并发数不足的情况。

c)请求“预分析”不足。对于像SPARK这样的大数据分析引擎，当多个并发请求同时到达时，采取的是“不拒绝”方案。即不管目前集群的资源消耗如何，也不管当下有多少个作业正在运行，SPARK都会给请求分配资源，甚至“抢”占正在运行作业的资源，导致前面运行的所有作业进度变慢，更严重的情况是造成系统瘫痪，即作业之间因为发生资源“抢占”而死锁的现象。

d)非“纯内存”。虽然曾经一度因为SPARK内存计算而取代MAP/REDUCE而轰动整个大数据界，然而SPARK并非纯内存运作，许多中间结果仍然要保存为文件的形式，特别是发生shuffle的时候，即数据需要跨网络传输的时候，中间结果数据一般都会因为内存不足或多或少地保存为文件的形式，有的甚至还要压缩保存，这在一定程度上降低了系统的性能。

发明内容

本发明提供一种支持高并发的分布式内存计算集群系统，有效降低“框架消耗”，并能实现数据预加载、请求预分析及纯内存操作。

为实现上述目的，本申请实施例提供了如下技术方案：

一种支持高并发的分布式内存计算集群系统，包括：Master节点、多个Node节点、集群管理部件和数据库；

所述Master节点，用于接收请求，预分析请求，分配和调度作业、集群监控、收集和返回分析结果，所述Master节点具体包括请求分析器、作业调度控制器、作业监视器、集群监视器、请求队列、作业队列和耗时作业队列，其中：