一种准实时调度方法及系统与流程

文档序号:30305300发布日期:2022-06-05 04:58阅读:128来源:国知局
一种准实时调度方法及系统与流程

1.本发明属于数据仓库处理技术领域,具体来说,涉及一种准实时调度方法及系统。


背景技术:

2.整个数据仓库系统是一个包含四个层次的体系结构,包括数据源、数据仓库、联机分析处理(olap,on-line analytical processing)系统及前端工具,其中:
3.数据源,是数据仓库系统的基础,通常包括企业内部信息和外部信息。
4.数据仓库,是以数据表的结构存储所述数据源的数据,每个数据表对应一个数据对象,一个数据源可以对应多个数据对象。
5.olap系统,用于对分析需要的数据进行有效集成,按多维模型予以组织,以便进行多角度、多层次的分析,并发现趋势。
6.前端工具,主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库的应用开发工具,实现对数据仓库的访问。
7.以网络游戏为例,当用户注册的游戏账户,当天进入游戏同时进行游戏货币交易。这些数据会实时的记录在数据源中。数据仓库每天定时同步这些数据,然后通过计算这些原始数据,更新数据仓库中数据。并且,服务器定期根据数据源中的数据处理数据仓库中的数据时,将处理可通过设置若干任务等来完成,每一任务完成一次或一批数据仓库中的数据同步/更新。
8.上述实现根据数据源中的数据处理数据仓库中数据的过程,我们称之为数据仓库的调度。
9.现有的数据仓库调度方法包括以下步骤:1.将所有的任务等需要处理器处理的单元划按照数据处理类型分为同步处理单元和更新处理单元;2.确认同步处理单元中任务执行的规则;随后,按照任务的依赖关系(比如,任务3依赖于任务2)以及服务器性能等来确认更新处理单元中一共有多少条执行线并排执行,以及每一执行线中的任务个数及任务的先后顺序;3.服务器先执行同步处理单元中每一任务;4.当同步处理单元中每一任务都执行完毕后,按照处理单元中设定的并排执行线及每一执行线的任务,并排执行这些任务。
10.现有技术中的缺陷在于,1、更新处理单元中的每一执行线上的任务都是以串行的方式进行执行的,在任意一个任务失败以后,后续无关任务也无法运行,导致后续任务数据不准确的问题,特别是当发生这些问题时,技术人员需要花大量精力去解决它,费时费力且效率差。2、一个更新处理单元的所有任务只能在同一个服务器中运行,无法根据服务器状态不同进行不同任务数量的执行;同时在服务器出现异常时无法快速切换服务器执行更新处理,从而使数据的及时性得不到保障。


技术实现要素:

11.针对现有技术中一个任务更新失败,后续无关任务也无法运行,导致后续任务数据不准确的问题,一个更新处理单元的所有任务只能在同一个服务器中运行,无法根据服
务器状态不同进行不同任务数量的执行;同时在服务器出现异常时无法快速切换服务器执行更新处理的问题;本发明提供了一种准实时调度方法及系统。
12.为实现上述技术目的,本发明采用的技术方案如下:
13.一种准实时调度方法,包括步骤:
14.s1、将运行的服务器和数据源的基础属性配置完成;
15.s2、预先建立保存每一节点之间依赖关系的节点关系表;
16.s3、定期启动起始节点,同时查询配置的处理器,并根据线程池最小算法选择最优执行器调度;
17.s4、执行器接收调度请求,并根据配置的执行逻辑进行调度处理;
18.s5、执行器调度完成后,返回管理工具调度结果和状态;
19.s6、将调度结果根据依赖关系往后续节点陆续处理,同时需要将入库数据发送至临时数据存储器redis中等待入库处理;
20.s7、监听临时数据存储器redis,一旦有数据输入则马上获取;
21.s8、当获取到数据后,检查所有执行器的运行状态与正在处理数据的目标存储空间;
22.s9、判断是否有相同目标存储空间,若有,则直接把数据分发到该执行器上;若没有,则判断是否有空闲执行器,若有,则直接把数据分发到该执行器上,进入步骤s11;若没有,进入步骤s10;
23.s10、等待到设定时间,跳转到步骤s8;
24.s11、执行器解析数据的主键,根据主键确定并发数量,执行处理数据;
25.s12、若执行失败,则发送错误信息,执行器停止执行。
26.进一步地,所述步骤s6中调度结果根据依赖关系往后续节点陆续处理前需要先判断是否有后续节点,如果无则结束整个流程,如果有,则返回步骤s4中。
27.进一步地,所述步骤s6中将入库数据发送至临时数据存储器redis中等待入库处理前,先判断数据是否需要入数据存储器redis中。
28.进一步地,所述依赖关系至少包括所述节点的所有前置节点,起始节点配置开始调度的时间。
29.进一步地,所述线程池最小算法为:nthreads=ncpu*ucpu*(1+w/c)。nthreads=线程数量,ncpu=cpu核心数,ucpu=cpu使用率,(0~1),w/c=等待时间与计算时间的比率;即当前执行器运行线程/nthreads(总线程数量)比率最小的机器。
30.一种准实时调度系统,包括调度单元、任务执行单元、数据中控单元和数据执行器;
31.所述调度单元,用于对数据源和节点信息配置,定时启动数据处理的运行,同时对服务器进行管理;
32.所述任务执行单元,用于接收调度单元发送的数据处理信息,并对该数据进行处理,返回告知调度单元处理结果;
33.所述数据中控单元,用于对数据进入数据库中的处理;
34.所述数据执行器,用于执行数据入库,采用并发处理,保证高效率的处理数据。
35.进一步地,所述数据中控单元需要入库的数据,统一存放在一个redis临时存储器
中等待处理;先对数据进行初步分析,再确定分发数据执行器,不同数据执行器之间不会同时处理同一目标存储位置的数据。
36.进一步地,所述调度单元获取系统任务信息表和数据执行器执行任务指令方式;获取系统任务信息表,由任务脚本人员进行配置,配置内容为:具体任务执行文件的所在位置以及后续任务节点id、任务类型的基本属性;根据任务节点id配置内容向对应数据执行器发送启动监听程序指令,并且发送任务所需的数据流/信息流至kafka队列中。
37.进一步地,所述kafka对列中至少存储3个信息:待执行的任务id、该任务需要的数据流/信息流和该任务信息存储在kafka上的具体位置/位点信息;通过监听kafka队列中来确定是否有任务需要执行,并且在任务执行时开启子线程实时记录执行的输出流内容作为日志,在任务发生异常结束时记录未执行的任务,用于下次开启程序时读取并继续执行。
38.进一步地,所述数据执行器包括执行器状态表,根据执行器状态表来获取执行器的运行状态(空闲,正在运行,异常停运)与正在处理数据属性信息;具体地通过监听redis临时存储器获得待处理入库数据以及数据的属性信息,更新执行器状态表中的执行器状态(无数据-空闲,有数据-正在运行)与正在处理数据属性信息;构建连接数据库引擎(数据属性中的目标数据库连接信息解密),解析数据内容,根据数据内容(主键信息)进行处理线程分类(同一主键数据只由同一线程处理),根据执行器所在服务器运行状态确定线程启动数量,从而取得数据的准确性与入库效率的最大公约数,启动线程执行。
39.本发明相比现有技术,具有如下有益效果:
40.通过生产/处理数据与存储数据分离,使生产/处理数据过程中可以高并发/实时处理数据,异步并发存储数据。
41.单机分布式处理可增大系统容量,可面对逐渐扩大的业务量充分并行,最大限度提高机器资源;多机分布式策略,解决因处理过多导致cpu过高出现的效率低下问题。该策略主要监控执行器资源,使得各个执行器资源利用率最大化,比较于单服务器而言,该方案更具扩展性。
42.摆脱处理数据依赖存储数据仓库平台,使处理数据过程能在多个平台中重复使用,减少重复开发。
43.对错误的修复功能,可以使用替代节点去代替错误节点;当出现错误节点(即节点池记录表中的节点之当前状态为处理出错),并且无法自动修复的时候,系统完成其他所有没有依赖关系的节点以后,调度终止。由于该错误节点的出现,以该节点为前置节点的节点都不会被调度,后续技术人员只需对错误节点进行修复后,重新调度调度程序,从而实现数据处理出现断点的无缝连接。
44.支持批/流一体化处理数据。
附图说明
45.图1为本发明一种准实时调度方法的运行阶段流程图;
46.图2为本发明一种准实时调度方法的配置阶段流程图;
47.图3为本发明一种准实时调度系统的数据处理总流程图;
48.图4为本发明一种准实时调度系统的调度单元内部处理流程图;
49.图5为本发明一种准实时调度系统的任务执行单元内部处理流程图;
50.图6为本发明一种准实时调度系统的数据中控单元内部处理流程图;
51.图7为本发明一种准实时调度系统的数据执行器内部处理流程图。
具体实施方式
52.为了便于本领域技术人员的理解,下面结合实施例与附图对本发明作进一步的说明,实施方式提及的内容并非对本发明的限定。
53.如图1和2所示,一种准实时调度方法,包括步骤:s1、将运行的服务器和数据源的基础属性配置完成。
54.s2、预先建立保存每一节点之间依赖关系的节点关系表;所述依赖关系至少包括所述节点的所有前置节点。(起始节点可配置开始调度时间)
55.s3、定期启动起始节点,同时查询配置的处理器,并根据线程池最小算法选择最优执行器调度;线程池最小算法为:nthreads=ncpu*ucpu*(1+w/c)。nthreads=线程数量,ncpu=cpu核心数,ucpu=cpu使用率,(0~1),w/c=等待时间与计算时间的比率;即当前执行器运行线程/nthreads(总线程数量)比率最小的机器。
56.s4、执行器接收调度请求,并根据配置的执行逻辑进行调度处理;可选择多线程处理,目前支持java、datax工具、python脚本、存储过程等方式。
57.s5、执行器调度完成后,返回管理工具调度结果和状态。
58.s6、将调度结果根据依赖关系往后续节点陆续处理,同时需要将入库数据发送至临时数据存储器redis中等待入库处理;步骤s6中调度结果根据依赖关系往后续节点陆续处理前需要先判断是否有后续节点,如果无则结束整个流程,如果有,则返回步骤s4中。依赖关系至少包括所述节点的所有前置节点,起始节点配置开始调度的时间。
59.步骤s6中将入库数据发送至临时数据存储器redis中等待入库处理前,先判断数据是否需要入数据存储器redis中。
60.s7、监听临时数据存储器redis,一旦有数据输入则马上获取。
61.s8、当获取到数据后,检查所有执行器的运行状态(正常工作,错误,空闲)与正在处理数据的目标存储空间。
62.s9、判断是否有相同目标存储空间,若有,则直接把数据分发到该执行器上;若没有,则判断是否有空闲执行器,若有,则直接把数据分发到该执行器上,进入步骤s11;若没有,进入步骤s10;
63.s10、等待到设定时间(可以设定为1s-10s),跳转到步骤s8;
64.s11、执行器解析数据的主键,根据主键确定并发数量,执行处理数据;实际并发数据=min(主键数,最大并发数),执行处理数据。
65.s12、若执行失败,则发送错误信息,执行器停止执行。
66.如图3、4、5、6和7所示,一种准实时调度系统,包括调度单元、任务执行单元、数据中控单元和数据执行器。
67.所述调度单元,用于对数据源和节点信息配置,定时启动数据处理的运行,同时对服务器进行管理;所述调度单元获取系统任务信息表和数据执行器执行任务指令方式;获取系统任务信息表,由任务脚本人员进行配置,配置内容为:具体任务执行文件的所在位置以及后续任务节点id、任务类型的基本属性;根据任务节点id配置内容向对应数据执行器
发送启动监听程序指令,并且发送任务所需的数据流/信息流至kafka队列中。同时kafka在接收存储信息同时广播信息,也可以事后人工重新广播信息(异常处理时)。
68.kafka对列中至少存储3个信息:待执行的任务id、该任务需要的数据流/信息流和该任务信息存储在kafka上的具体位置/位点信息;通过监听kafka队列中来确定是否有任务需要执行,并且在任务执行时开启子线程实时记录执行的输出流内容作为日志,在任务发生异常结束时记录未执行的任务,用于下次开启程序时读取并继续执行。
69.所述任务执行单元,用于接收调度单元发送的数据处理信息,并对该数据进行处理,返回告知调度单元处理结果;可根据配置的线程数量多线程执行相应任务,启动的任务类型有:存储过程、python等,任务运行依赖于服务器的环境,故可满足于不同的场景。
70.主要通过监听redis临时存储器(通过发送请求数据指令(阻塞请求)到redis上,一但有数据进入则会马上将该数据通过请求路径返回给监听器)获得待处理入库数据以及数据的属性信息(目标数据库连接信息(ip地址账号密码等)-密文,目标数据库,目标数据表,数据业务主键字段等),根据【执行器状态表】来获取执行器的运行状态(空闲,正在运行,异常停运)与正在处理数据属性信息。通过分发不同执行来确保每一个数据表在同一时间内只会有一个执行器在运行,从而保证每个数据表中的数据唯一性与高效并发处理大量目标不同的数据。
71.所述数据中控单元,用于对数据进入数据库中的处理;数据中控单元需要入库的数据,统一存放在一个redis临时存储器中等待处理;先对数据进行初步分析,再确定分发数据执行器,不同数据执行器之间不会同时处理同一目标存储位置的数据。
72.所述数据执行器,用于执行数据入库,采用并发处理,保证高效率的处理数据。
73.数据执行器包括执行器状态表,根据执行器状态表来获取执行器的运行状态(空闲,正在运行,异常停运)与正在处理数据属性信息;具体地通过监听redis临时存储器获得待处理入库数据以及数据的属性信息,更新执行器状态表中的执行器状态(无数据-空闲,有数据-正在运行)与正在处理数据属性信息;构建连接数据库引擎(数据属性中的目标数据库连接信息解密),解析数据内容,根据数据内容(主键信息)进行处理线程分类(同一主键数据只由同一线程处理),根据执行器所在服务器运行状态确定线程启动数量,从而取得数据的准确性与入库效率的最大公约数,启动线程执行。
74.所有单元互相之间独立运行,数据交互通过各种不同中间件交互。最大限度增加整体系统的稳定性(任意独立子系统出现异常都可以秒切备份系统运行),数据的完整性(数据与系统切分开运作,系统本身不存储数据)以及系统可快速备份迭代,并将调度作业与业务系统进行分离,降低或者是消除和业务系统的耦合度,进行高效分布式异步任务处理。将各个业务单元进行节点化并进行监控,日志记录等。
75.使用引擎建立独立的连接数据库通道(保证数据不会发生错乱),然后根据入库逻辑进行入库操作。在入库结束后则关闭通道,返回执行结果。
76.若正常结束,则将信息返回给执行器,执行器启动新的线程(之前的数据未处理完)/继续监听新的数据(所有数据已经处理完成)。若是异常结束,则直接更新总控监听(注8)中的状态表(改为异常),等待剩余线程运行完,关闭执行器。
77.本发明相比现有技术,具有如下有益效果:
78.通过生产/处理数据与存储数据分离,使生产/处理数据过程中可以高并发/实时
处理数据,异步并发存储数据。
79.单机分布式处理可增大系统容量,可面对逐渐扩大的业务量充分并行,最大限度提高机器资源;多机分布式策略,解决因处理过多导致cpu过高出现的效率低下问题。该策略主要监控执行器资源,使得各个执行器资源利用率最大化,比较于单服务器而言,该方案更具扩展性。
80.摆脱处理数据依赖存储数据仓库平台,使处理数据过程能在多个平台中重复使用,减少重复开发。
81.对错误的修复功能,可以使用替代节点去代替错误节点;当出现错误节点(即节点池记录表中的节点之当前状态为处理出错),并且无法自动修复的时候,系统完成其他所有没有依赖关系的节点以后,调度终止。由于该错误节点的出现,以该节点为前置节点的节点都不会被调度,后续技术人员只需对错误节点进行修复后,重新调度调度程序,从而实现数据处理出现断点的无缝连接。
82.支持批/流一体化处理数据。
83.以上对本技术提供的一种准实时调度方法及系统进行了详细介绍。具体实施例的说明只是用于帮助理解本技术的方法及其核心思想。应当指出,对于本技术领域的普通技术人员来说,在不脱离本技术原理的前提下,还可以对本技术进行若干改进和修饰,这些改进和修饰也落入本技术权利要求的保护范围内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1