基于多业务系统的数据预警方法、装置、设备和介质与流程

文档序号:30497534发布日期:2022-06-22 06:39阅读:161来源:国知局
基于多业务系统的数据预警方法、装置、设备和介质与流程

1.本技术涉及计算机技术领域,特别是涉及一种基于多业务系统的数据预警方法、装置、设备和介质。


背景技术:

2.随着计算机技术的高速发展,监控预警在保证业务系统的安全性、高可用性、高性能方面起着至关重要的作用。对于业务系统中的关键性指标,不仅需要实时监控,还需确定监控数据是否符合预测,对于偏离预测的指标做异常告警。
3.在传统方式中,业务系统基于指标进行预警处理的时候,通常是通过单指标进行的,如业绩下滑率指标进行业绩预警处理。由于单指标仅从单一方面进行预警,考虑单一维度的影响,准确性降低,为了提高准确性,从多个方面对待监控业务事项进行衡量,但是这样会使得服务器需要处理大量的数据,导致处理效率降低。


技术实现要素:

4.基于此,有必要针对上述技术问题,提供一种提升预警处理准确性的基于多业务系统的数据预警方法、装置、设备和介质。
5.一种基于多业务系统的数据预警方法,所述方法包括:读取预先配置的预警指标主表;基于预警指标主表,确定待进行预警处理的目标预警指标;从各业务系统获取对应目标预警指标的业务数据;根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将所述业务数据存储至对应的中间数据库,根据所述中间数据库的性能参数,对所存储的业务数据进行计算得到对应所述目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库;根据结果数据库中存储的指标数据进行数据预警。
6.在其中一个实施例中,从各业务系统获取对应目标预警指标的业务数据,包括:根据目标预警指标,确定对应的各指标维度;基于各指标维度,确定对应的各业务系统;根据各业务系统的系统类型,确定与各业务系统对接的数据获取接口;通过对应的各数据获取接口,从各业务系统获取业务数据。
7.在其中一个实施例中,通过对应的各数据获取接口,从各业务系统获取业务数据,包括:通过各数据获取接口,从各业务系统获取原始业务数据;对各原始业务数据进行标准化转换,得到统一数据格式的业务数据。
8.在其中一个实施例中,根据结果数据库中存储的指标数据进行数据预警,包括:根据结果数据库中存储的指标数据,确定对应的预警等级;
根据预警等级,触发执行对应预警等级的警示操作。
9.在其中一个实施例中,根据结果数据库中存储的指标数据进行数据预警之后,还包括:根据结果数据库中存储的指标数据,确定影响数据预警的关联指标;根据关联指标,确定对应的关联业务;确定对应关联业务的任务处理方案,并执行。
10.在其中一个实施例中,得到对应所述目标预警指标的指标数据之后,还包括:对预警指标主表中目标预警指标的属性数据进行更新,并对更新后的预警指标主表进行轮询。
11.在其中一个实施例中,上述方法还包括:接收终端的订阅请求,订阅请求中携带有被订阅的订阅指标;将订阅指标对应的业务数据和/或指标数据推送至终端,并通过终端展示。
12.一种基于多业务系统的数据预警装置,所述装置包括:读取模块,用于读取预先配置的预警指标主表;目标预警指标确定模块,用于基于预警指标主表,确定待进行预警处理的目标预警指标;业务数据获取模块,用于从各业务系统获取对应目标预警指标的业务数据;指标数据生成模块,用于根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将所述业务数据存储至对应的中间数据库,根据所述中间数据库的性能参数,对所存储的业务数据进行计算得到对应所述目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库;数据预警模块,用于根据结果数据库中存储的指标数据进行数据预警。
13.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现上述任一实施例所述方法的步骤。
14.一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一实施例所述的方法的步骤。
15.上述基于多业务系统的数据预警方法、装置、设备和介质中,通过读取预先配置的预警指标主表,并基于预警指标主表,确定待进行预警处理的目标预警指标,然后从各业务系统获取对应目标预警指标的业务数据,并根据各业务系统的业务数据,得到对应目标预警指标的指标数据,进一步根据结果数据库中存储的指标数据进行数据预警。从而,可以通过预先配置的预警指标主表,确定待进行预警处理的目标预警指标,并通过从各业务系统中获取到的业务数据进行综合的指标处理以及数据预警,使得数据预警结合了多方业务数据进行,可以使得生成的指标数据更加准确,进而可以提升预警处理的准确性。此外,在获取到业务数据后,根据业务系统的类型存储到对应的中间数据库,利用中间数据库来进行指标数据的并行计算,减少服务器的压力,提高处理效率,且各个中间数据库互不干扰,进一步保证数据计算的效率,最后将数据存储至结果数据库,保留源数据,便于数据溯源。
附图说明
16.图1为一个实施例中基于多业务系统的数据预警方法的应用场景图;
图2为一个实施例中基于多业务系统的数据预警方法的流程示意图;图3为另一个实施例中基于多业务系统的数据预警方法的流程示意图;图4为又一个实施例中基于多业务系统的数据预警方法的流程示意图;图5为一个实施例中基于多业务系统的数据预警装置的结构框图;图6为一个实施例中计算机设备的内部结构图。
具体实施方式
17.为了使本技术的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本技术进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本技术,并不用于限定本技术。
18.本技术提供的基于多业务系统的数据预警方法,可以应用于如图1所示的应用环境中。其中,终端102通过网络与服务器104进行通信。终端102可以接收用户操作,配置并生成预警指标主表。服务器104可以读取预先配置的预警指标主表,并基于预警指标主表,确定待进行预警处理的目标预警指标。然后服务器104可以从各业务系统获取对应目标预警指标的业务数据,并根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将业务数据存储至对应的中间数据库,根据中间数据库的性能参数,对所存储的业务数据进行计算得到对应目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库。进一步,服务器104可以根据结果数据库中存储的指标数据进行数据预警。其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备,服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
19.在一个实施例中,如图2所示,提供了一种基于多业务系统的数据预警方法,以该方法应用于图1中的服务器为例进行说明,包括以下步骤:步骤s202,读取预先配置的预警指标主表。
20.其中,预警指标主表是指预先配置的,包括对业务系统中各业务进行预警判定的指标的集合,预警指标主表可以是数据表,也可以是数据库,本技术对此不作限制。
21.在本实施例中,预警指标主表还可以包括所有指标的属性数据,如时间属性、预警属性、展示属性、运维属性、数据属性、优先级属性等。部分属性之间存在一定的关联关系,如带有预警属性的指标优先级属性高,带有预警属性的指标肯定展示,带有展示属性的指标优先级属性次之,不带有展示属性的指标优先级属性最低。
22.在本实施例中,服务器可以对业务系统中需要监控的业务事项进行统计分析,并配置生成预警指标主表,使得可以基于预警指标主表进行业务系统的预警处理。
23.步骤s204,基于预警指标主表,确定待进行预警处理的目标预警指标。
24.在本实施例中,参考图3,服务器可以以任务轮询的方式,每天轮询预警指标主表,判定是否存在未运行的指标,即目标预警指标。
25.具体地,服务器可以基于预警指标主表中所包括的时间属性、预警属性、展示属性、运维属性、数据属性、优先级属性等,确定待进行预警处理的目标预警指标。
26.在一个实施例中,参考图4,服务器读取预警指标主表之后,可以通过时间定义表,通过时间关联获取统计范围,确定待进行预警处理的目标预警指标。在其他实施例中,服务
器还可以通过优先级等确定待进行处理的目标预警指标。
27.在本实施例中,时间控制表定义了每个指标的计算范围、数据存储范围、开始和结束时间等。
28.具体地,服务器可以获取到待监控业务事项,然后获取到目前所有的预警指标,对预警指标进行第一次筛选以去掉与待监控业务事项明显无关的预警指标,具体地,可以根据待监控事项确定指标关键词,根据指标关键词对预警指标进行筛选,以删掉明显无关的预警指标。第三,服务器对剩余的预警指标进行第二次处理,例如通过模型的方式计算各个剩余预警指标与待监控业务事项的关联程度,根据该关联程度来确定待监控业务事项对应的目标指标,根据目标指标生成预警指标主表。
29.其中关联程度的计算过程可以包括:通过模型的方式计算各个剩余预警指标与待监控业务事项的关联程度,例如通过改变剩余预警指标后,计算待监控业务事项的预警程度,根据预警程度确定关联程度。在其他实施例中,可以构建一致比较矩阵,通过将两两剩余预警指标进行定量比较以确定各个预警指标的重要程度,例如将两两剩余预警指标进行定量比较得到一致比较矩阵,对一致比较矩阵进行处理得到关联程度。最后将关联程度大于阈值的剩余预警指标作为目标指标。
30.步骤s206,从各业务系统获取对应目标预警指标的业务数据。
31.在本实施例中,继续参考图3,服务器在确定待进行预警处理的目标预警指标之后,可以获取对应的基础明细数据,即业务数据。
32.具体地,服务器可以从各业务系统获取业务数据,如从核心业务系统获取保单业绩明细数据,从人管系统获取佣金、职级以及组织架构等数据,从营销系统获取增员数据,从培训系统获取培训数据,从考勤系统获取考勤数据等。其中,为了提高计算效率,服务器通过并行方式,分别从各个业务系统获取到业务数据。
33.在本实施例中,服务器可以是从各业务系统的记录任务表或者是记录日志表中获取各业务数据,并进行后续的处理。其中,业务数据的获取可以是通过日志获取的,服务器读取各个系统的记录日志表,从日志中读取业务数据。其中各个业务系统在生成日志时,可以对日志进行清洗和分析,得到满足要求的日志信息,并存储在记录日志表中。且为了减少后续业务数据的处理,记录日志表中可以仅存储业务数据发生变化的日志所对应的变化的业务数据,这样减少了发送至服务器中的数据量,从而降低服务器的数据分析量,进而提高数据处理效率。在其他的实施例中,各个业务系统可以根据预先配置的规则对日志进行筛选清洗,以将目标日志的业务数据存储至记录日志表中。
34.此外,为了减少数据处理,服务器还可以判断用于计算指标数据的业务数据是否已存储至对应的中间服务器,若是本次则无需再获取,提高效率,由于不同的指标数据的计算可能需要同一业务数据,因此,若该些业务数据已经存储到中间服务器,则无需再次获取,提高效率。
35.在本实施例中,继续参考图4,服务器可以通过维度定义表以及指标维度表等,确定各目标预警指标对应的计算维度,指标的计算维度决定计算数据的最细粒度,并进行后续的处理。
36.步骤s208,根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将所述业务数据存储至对应的中间数据库,根据所述中间数据库
的性能参数,对所存储的业务数据进行计算得到对应所述目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库。
37.其中,指标数据是指各预警指标所对应的数据内容,如业绩月度产能指标,则具体的指标数据为50或者是60等。
38.在本实施例中,服务器从各业务系统获取业务数据之后,可以对获取到的业务数据进行数据分类汇总,得到对应目标预警指标的指标数据,即参考图3,按照维度进行数据汇总。
39.其中,业务系统的类型可以根据其中存储的数据类型的来确定,例如考勤数据、费用明细数据等等。不同的业务系统的类型,其数据存储的中间数据库不同,服务器将从业务系统获取的业务数据分别存储至对应的中间数据库,例如sqoop同步过来的数据库通过存储在hive数据库进行计算,主要包括考勤数据;ogg和etl同步过来的数据可以存储至oracle数据库进行计算,主要计算核心业务的费用明细数据。
40.各个中间数据库具有不同的性能指标,例如系统的性能压力和批处理运行时长,服务器可以实时获取到各个中间数据库的性能指标,并根据该性能指标来配置中间数据库的数据处理的配置信息,包括数据更新频率以及处理时间节点等等,其中数据更新频率可以是被服务器获取的,服务器根据该数据更新频率定期从业务系统获取到对应的业务数据并存储至中间数据库,处理时间节点可以是指目标指标数据的计算,服务器根据处理时间节点对存储的业务数据进行指标计算,从而得到指标数据,并将所得到的指标数据存储至结果数据库,这样中间数据库中可以保留原始数据,便于后续数据溯源。
41.步骤s210,根据结果数据库中存储的指标数据进行数据预警。
42.在本实施例中,服务器可以基于得到的指标数据,以及对应的指标阈值等,进行数据预警分析处理,如指标数据高于阈值,则进行告警,低于阈值,则不告警等。
43.在本实施例中,服务器在进行告警的时候,可以基于消息模板,生成告警信息,并通过邮件、短信或者其他的方式进行告警。
44.在本实施例中,目标预警指标可以是多个,所得到的指标数据可以是多个,服务器可以分别对各指标数据进行分析,并进行数据预警。
45.以下结合一具体案例进行详细说明。
46.在本实施例中,以业绩月度产能指标为例,服务器可以先读取预警指标主表的月度产能指标,根据月度产能指标的时间属性,读取时间控制表的月度产能指标的统计范围。
47.进一步,服务器可以根据指标维度表读取产能指标的维度,如跟月度产能指标有关的维度有机构、职级、司龄、险种等。
48.在本实施例中,服务器可以根据关联的代理人的机构、入司时间、职级等数据,并获取出代理人当月0点截至到目前的明细数据,如各级机构的机构id和名称、产品id和产品名称、代理人编码、姓名、职级、渠道、入司时间、预收保费、承保保费、预收价值、承保价值、收入、预收件数、承保件数、预收寿险长险件数、承保寿险长险件数以及年度产能等明细数据,即业务数据。
49.在本实施例中,服务器在获取到明细数据之后,可以进行汇总分析处理,如按照机构、职级、司龄、险种等维度进行分类,并进行分类汇总,如,新人分为入司3个月新人、入司4-6个月新人、入司7-12月新人、入司1-2年内新人、入司3-5年新人等,险种分类为人寿险、
健康险、年金险、意外险等。
50.进一步,服务器可以将分类后的数据作为对应目标预警指标的指标数据,并进行后续的预警处理。
51.上述基于多业务系统的数据预警方法中,通过读取预先配置的预警指标主表,并基于预警指标主表,确定待进行预警处理的目标预警指标,然后从各业务系统获取对应目标预警指标的业务数据,并根据各业务系统的业务数据,得到对应目标预警指标的指标数据,进一步根据结果数据库中存储的指标数据进行数据预警。从而,可以通过预先配置的预警指标主表,确定待进行预警处理的目标预警指标,并通过从各业务系统中获取到的业务数据进行综合的指标处理以及数据预警,使得数据预警结合了多方业务数据进行,可以使得生成的指标数据更加准确,进而可以提升预警处理的准确性。此外,在获取到业务数据后,根据业务系统的类型存储到对应的中间数据库,利用中间数据库来进行指标数据的计算,减少服务器的压力,提高处理效率,且各个中间数据库互不干扰,进一步保证数据计算的效率,最后将数据存储至结果数据库,保留源数据,便于数据溯源。
52.在其中一个实施例中,得到对应所述目标预警指标的指标数据之后,还可以包括:对预警指标主表中目标预警指标的属性数据进行更新,并对更新后的预警指标主表进行轮询。
53.如前文所述,服务器可以每天对预警指标主表进行轮询,并确定待进行预警处理的目标预警指标。
54.在本实施例中,服务器在对业务数据进行处理,并生成对应的指标数据之后,还可以对预警指标主表进行更新,如更新已经处理的目标预警指标的下次运行时间以及时间区间等,并待达到对应的运行时间时,再次进行预警计算以及预警处理。
55.在其中一个实施例中,从各业务系统获取对应目标预警指标的业务数据,可以包括:根据目标预警指标,确定对应的各指标维度;基于各指标维度,确定对应的各业务系统;根据各业务系统的系统类型,确定与各业务系统对接的数据获取接口;通过对应的各数据获取接口,从各业务系统获取业务数据。
56.其中,指标维度是指预警指标所属的业务维度,如保险业务相关维度、人员管理相关维度、业绩数据相关维度等,或者也可以是指机构、职级、险种、司龄等不同的维度。
57.在本实施例中,服务器可以基于目标预警指标,确定各目标预警指标的指标维度,进而基于指标维度,确定对应的业务系统。例如,机构、职级以及司龄等维度的指标与人管系统相对应,险种等维度的指标与核心业务系统相对应。
58.在本实施例中,服务器在确定对应各指标维度的业务系统后,可以获取各业务系统的配置数据,并基于各业务系统的配置数据,确定各业务系统的系统类型。
59.进一步,服务器可以基于各业务系统的系统类型,确定对应的数据获取接口,并进行业务数据的获取。例如,服务器可以通过实时同步工具ogg(oracle golden gate)从核心业务系统同步保单业绩明细数据,通过etl(extract-transform-load,数据仓库)工具informatica从人管系统同步佣金、职级、组织架构等数据,通过etl工具informatica从营销系统同步增员数据,通过etl工具informatica从培训系统同步培训数据,通过大数据同步工具sqoop从考勤系统同步考勤数据等。
60.在本实施例中,服务器在获取到各业务数据后,由于数据量较大,服务器可以通过
配置不同的数据库进行后续的数据处理,即对业务数据进行计算,得到对应目标预警指标的指标数据。例如,sqoop同步过来的数据库通过存储在hive数据库进行计算,主要包括考勤数据;ogg和etl同步过来的数据可以存储至oracle数据库进行计算,主要计算核心业务的费用明细数据;redis和mongodb可以用于存储计算得到的结果数据,即对应目标预警指标的指标数据等。
61.在本实施例中,对于不同的数据库,服务器可以基于数据库的性能,设置其对应的数据更新频率以及处理时间节点等。例如,对与oracle的计算任务,可以在考虑减少系统性能压力和批处理运行时长等情况下,高频数据每次更新最近30分钟数据,以防止数据同步延迟,同时可以设置每天凌晨2点更新最近15天的数据,以防止源业务系统更新历史数据;对于大数据hive的计算任务,在早晚班时间每小时计算一次当天刷脸数据,每天12:30和22:30计算当月数据,每月15日及15日之前计算上月数据,15日之后计算当月数据,增员数据每2个小时计算一次当月数据;计算结果同步到redis和mongodb可以通过java的定时job实现的。
62.在本实施例中,为了减少数据库的数据处理压力,服务器可以通过二级机构进行并发处理,提升处理效率。
63.在本实施例中,服务器在进行数据处理的时候,还可以通过批处理优化、索引、分区分片、并行等技术优化,实现均衡处理。
64.在其中一个实施例中,通过对应的各数据获取接口,从各业务系统获取业务数据,可以包括:通过各数据获取接口,从各业务系统获取原始业务数据;对各原始业务数据进行标准化转换,得到统一数据格式的业务数据。
65.在本实施例中,对于不同的业务系统,各业务系统中的业务数据的数据格式可能并不相同。服务器可以通过数据获取接口,从各业务系统获取到原始业务数据,并通过对应的数据获取接口中配置的转换逻辑,进行原始业务数据的数据格式的转换,如转换为同一数据格式的业务数据等。
66.在其中一个实施例中,根据结果数据库中存储的指标数据进行数据预警,可以包括:根据结果数据库中存储的指标数据,确定对应的预警等级;根据预警等级,触发执行对应预警等级的警示操作。
67.在本实施例中,对于各预警指标,服务器可以设置分级预警机制,并在得到数据之后,通过对指标数据进行预警等级的判定,并执行对应的警示操作。
68.例如,对于活动率指标,服务器可以预先设置5%、8%、10%等多个预警阈值,当服务器基于确定的活动率指标的质保数据,确定达到5%预警阈值时,则触发执行对应的警示操作,如将质保数据推送给责任人a,而当确定达到8%预警阈值时,则触发执行对应的警示操作,如将质保数据推送给责任人b等。
69.以上仅为举例说明,在其他实施例中,警示操作可以包括邮件、短信或者是语音提示等,不同的预警等级可以触发执行邮件、短信或者是语音提示等不同的警示操作。
70.在其中一个实施例中,根据结果数据库中存储的指标数据进行数据预警之后,还可以包括:根据结果数据库中存储的指标数据,确定影响数据预警的关联指标;根据关联指标,确定对应的关联业务;确定对应关联业务的任务处理方案,并执行。
71.在本实施例中,关联指标是指影响数据预警的指标。
72.在本实施例中,服务器在得到各指标数据之后,可以对指标数据进行分析判定,以确定对应的关联指标。
73.在其中一个实施例中,以代理人的业绩为例进行说明。
74.在本实施例中,代理人的业绩是主要的分析对象,从时间属性上分析,业绩分析包括周、月、季、年等,影响业绩数据预警的关联指标有很多,包括但是不限于业绩指标、人力指标、活动指标等。以下通过周为时间维度进行说明。
75.在本实施例中,周是指活动周,活动周是按照佣金月周期计算,如每月25所在周的7天为第一周,第二周从下个周一开始到周日,每月26日所在周为最后一周的最后一天,往前推7天为最后一周,这个活动周是指标预警的周指标时间统计区间。
76.在本实施例中,与业绩指标相关的自保数据包括如期交保费、价值、件数、预收和承保等指标数据。
77.其中,期交保费根据进入系统时间进行统计,后续有犹豫期退保、退保、减保、加保等业务操作导致费用变化按照费用发生时间计入对应日期。价值按照最新版本价值进行价值率计算,不同版本价值率不同导致的差异计入校准值,价值指标以当时数据产生的最新版本价值率为准。件数按照统计区间确定,保费》0记为1件,保费《0记为-1件。
78.在本实施例中,与人力指标相关的指标数据包括期初人力、期末人力、平均人力、新增人力等。
79.其中,期初人力是统计期开始时间的在职人力。期末人力是统计期结束时间的在职人力。平均人力是期初人力+期末人力,然后除以2。新增人力是入司时间在统计期内,离司时间为空或者离司日期大于统计期结束时间的在职人力。
80.在本实施例中,当服务器基于本周的指标数据与最近6周的指标数据进行比较,并在确定平均值偏差比较大时告警,如偏差5%-8%低度告警,偏差8%-10%中度告警,偏差超过10%高度告警。
81.在本实施例中,在服务器触发告警后,可以触发根据结果数据库中存储的指标数据进行关联业务的分析与处理。例如,先看基于业绩指标进行分析处理,然后进行人力指标的分析。
82.具体地,服务器可以先判定业绩指标中的价值和保费的趋势是否一致,如果不一致,则可能是销售价值偏低的产品所致,如果一致,再判定件数跟保费是否一致,如果件数下降趋势大于保费,则说明可能是退保较多所致,如果趋势差异不大,再通过对人力指标进行进一步的分析。
83.在本实施例中,服务器可以先查看本周平均人力指标跟最近6周的平均值偏差趋势是否跟业绩一致,如果不一致,说明不是人力导致;如果一致,进一步看期初人力指标、期末人力指标是否偏差较大,如果期初人力一致,期末人力不一致,说明机构最近人员离职较高所致,可以提供对应的任务处理方案,如建议增员,补充人力,并通过跟对应机构沟通讨论确认方案。
84.在本实施例中,如果基于人力指标看不出显著问题,可可以在看下活动指标,如险种维度业绩数据,按照业绩排名的险种是否跟最近6周一致,确认是否因为产品停售,或新产品起售不理想所致。
85.在本实施例中,服务器在确定任务处理方案的时候,可以结合指标与产能维度进
行分析处理,如可以根据人力指标和产能维度结合处理。
86.其中,产能根据入司时长和工作经验对产能层级进行区分,查看入司时长和工作经验对应产能最大的层级人员进行培训或同业引进。
87.在本实施例中,产能维度包括新人以及工作经验等维度,新人分为入司3个月新人、入司4-6个月新人、入司7-12月新人、入司1-2年内新人、入司3-5年新人,工作经验分为1-3年、3-5年、5-7年、7-9年、9年以上等。
88.在本实施例中,服务器可以根据产能分析增员目标和培训目标,增员是以产能最大的同业引进和新人入司为目标人力,培训是以接近产能最大的人员为主要目标人力,其他人员为辅助目标人力,以提高人员素质、业务能力等。
89.在本实施例中,增员过程有增员指标,比如注册人员、申请人员、面谈人员、结训人员、入司人员、转正人员等人员数量。
90.在本实施例中,服务器还可以通过对结训率、入司率、转正率进行计算分析,对各组织机构进行分析,并提出更改建议。
91.在其中一个实施例中,上述方法还可以包括:接收终端的订阅请求,订阅请求中携带有被订阅的订阅指标;将订阅指标对应的业务数据和/或指标数据推送至终端,并通过终端展示。
92.在本实施例中,不同的用户通过终端进入系统后,可以进行指标列表的浏览,通过点击指标订阅,可以订阅指标,并可以选择高中低不同的指标关注度。
93.在本实施例中,每个用户可以关注多个指标,并按照指标关注度进行排序并展示于终端界面上。
94.在本实施例中,用户在订阅指标后,可以根据不同的关注度进行不同的阈值配置,当指标数据的数据趋势异常,达到阈值时,可以触发进行消息推送,并展示于用户终端。
95.在本实施例中,在进行信息推送的,可以按照不同的消息模板进行推送。消息模板中可以包括指标异常数据的详细说明,如指标历史数据、目前数据、偏差量、偏差原因、建议解决方案等。
96.在本实施例中,用户通过终端进入系统后,可以通过点击页面查看不同的指标,每个指标展示不同的指标维度,不同的指标维度可以通过不同的风格展示,具有相关性的指标可以进行关联展示。
97.应该理解的是,虽然图2的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图2中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
98.在一个实施例中,如图5所示,提供了一种基于多业务系统的数据预警装置,包括:读取模块100、目标预警指标确定模块200、业务数据获取模块300、指标数据生成模块400和数据预警模块500,其中:读取模块100,用于读取预先配置的预警指标主表。
99.目标预警指标确定模块200,用于基于预警指标主表,确定待进行预警处理的目标
预警指标。
100.业务数据获取模块300,用于从各业务系统获取对应目标预警指标的业务数据。
101.指标数据生成模块400,用于根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将业务数据存储至对应的中间数据库,根据中间数据库的性能参数,对所存储的业务数据进行计算得到对应目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库。
102.数据预警模块500,用于根据结果数据库中存储的指标数据进行数据预警。
103.在其中一个实施例中,业务数据获取模块300,可以包括:指标维度确定子模块,用于根据目标预警指标,确定对应的各指标维度。
104.业务系统确定子模块,用于基于各指标维度,确定对应的各业务系统。
105.接口确定子模块,用于根据各业务系统的系统类型,确定与各业务系统对接的数据获取接口。
106.业务数据获取子模块,用于通过对应的各数据获取接口,从各业务系统获取业务数据。
107.在其中一个实施例中,业务数据获取子模块,可以包括:原始业务数据获取单元,用于通过各数据获取接口,从各业务系统获取原始业务数据。
108.转换单元,用于对各原始业务数据进行标准化转换,得到统一数据格式的业务数据。
109.在其中一个实施例中,数据预警模块500,可以包括:预警等级确定子模块,用于根据结果数据库中存储的指标数据,确定对应的预警等级。
110.警示子模块,用于根据预警等级,触发执行对应预警等级的警示操作。
111.在其中一个实施例中,上述装置还可以包括:关联指标确定模块,用于根据结果数据库中存储的指标数据进行数据预警之后,根据结果数据库中存储的指标数据,确定影响数据预警的关联指标。
112.关联业务确定模块,用于根据关联指标,确定对应的关联业务。
113.处理方案确定与执行模块,用于确定对应关联业务的任务处理方案,并执行。
114.在其中一个实施例中,上述装置还可以包括:更新模块,用于得到对应所述目标预警指标的指标数据之后,对预警指标主表中目标预警指标的属性数据进行更新,并对更新后的预警指标主表进行轮询。
115.在其中一个实施例中,上述装置还可以包括:订阅请求接收模块,用于接收终端的订阅请求,订阅请求中携带有被订阅的订阅指标。
116.推送与展示模块,用于将订阅指标对应的业务数据和/或指标数据推送至终端,并通过终端展示。
117.关于基于多业务系统的数据预警装置的具体限定可以参见上文中对于基于多业务系统的数据预警方法的限定,在此不再赘述。上述基于多业务系统的数据预警装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于
或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
118.在一个实施例中,提供了一种计算机设备,该计算机设备可以是服务器,其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储预警指标主表、目标预警指标、业务数据以及指标数据等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于多业务系统的数据预警方法。
119.本领域技术人员可以理解,图6中示出的结构,仅仅是与本技术方案相关的部分结构的框图,并不构成对本技术方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
120.在一个实施例中,提供了一种计算机设备,包括存储器和处理器,该存储器存储有计算机程序,该处理器执行计算机程序时实现以下步骤:读取预先配置的预警指标主表;基于预警指标主表,确定待进行预警处理的目标预警指标;从各业务系统获取对应目标预警指标的业务数据;根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将业务数据存储至对应的中间数据库,根据中间数据库的性能参数,对所存储的业务数据进行计算得到对应目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库;根据结果数据库中存储的指标数据进行数据预警。
121.在其中一个实施例中,处理器执行计算机程序时实现从各业务系统获取对应目标预警指标的业务数据,可以包括:根据目标预警指标,确定对应的各指标维度;基于各指标维度,确定对应的各业务系统;根据各业务系统的系统类型,确定与各业务系统对接的数据获取接口;通过对应的各数据获取接口,从各业务系统获取业务数据。
122.在其中一个实施例中,处理器执行计算机程序时实现通过对应的各数据获取接口,从各业务系统获取业务数据,可以包括:通过各数据获取接口,从各业务系统获取原始业务数据;对各原始业务数据进行标准化转换,得到统一数据格式的业务数据。
123.在其中一个实施例中,处理器执行计算机程序时实现根据结果数据库中存储的指标数据进行数据预警,可以包括:根据结果数据库中存储的指标数据,确定对应的预警等级;根据预警等级,触发执行对应预警等级的警示操作。
124.在其中一个实施例中,处理器执行计算机程序时实现根据结果数据库中存储的指标数据进行数据预警之后,还可以实现以下步骤:根据结果数据库中存储的指标数据,确定影响数据预警的关联指标;根据关联指标,确定对应的关联业务;确定对应关联业务的任务处理方案,并执行。
125.在其中一个实施例中,处理器执行计算机程序时实现得到对应所述目标预警指标的指标数据之后,还可以实现以下步骤:对预警指标主表中目标预警指标的属性数据进行更新,并对更新后的预警指标主表进行轮询。
126.在其中一个实施例中,处理器执行计算机程序时还可以实现以下步骤:接收终端的订阅请求,订阅请求中携带有被订阅的订阅指标;将订阅指标对应的业务数据和/或指标
数据推送至终端,并通过终端展示。
127.在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:读取预先配置的预警指标主表;基于预警指标主表,确定待进行预警处理的目标预警指标;从各业务系统获取对应目标预警指标的业务数据;根据各业务系统的业务数据,得到对应目标预警指标的指标数据,包括:根据业务系统的类型,将业务数据存储至对应的中间数据库,根据中间数据库的性能参数,对所存储的业务数据进行计算得到对应目标预警指标的指标数据,并将计算得到的指标数据存储至结果数据库;根据结果数据库中存储的指标数据进行数据预警。
128.在其中一个实施例中,计算机程序被处理器执行时实现从各业务系统获取对应目标预警指标的业务数据,可以包括:根据目标预警指标,确定对应的各指标维度;基于各指标维度,确定对应的各业务系统;根据各业务系统的系统类型,确定与各业务系统对接的数据获取接口;通过对应的各数据获取接口,从各业务系统获取业务数据。
129.在其中一个实施例中,计算机程序被处理器执行时实现通过对应的各数据获取接口,从各业务系统获取业务数据,可以包括:通过各数据获取接口,从各业务系统获取原始业务数据;对各原始业务数据进行标准化转换,得到统一数据格式的业务数据。
130.在其中一个实施例中,计算机程序被处理器执行时实现根据结果数据库中存储的指标数据进行数据预警,可以包括:根据结果数据库中存储的指标数据,确定对应的预警等级;根据预警等级,触发执行对应预警等级的警示操作。
131.在其中一个实施例中,计算机程序被处理器执行时实现根据结果数据库中存储的指标数据进行数据预警之后,还可以实现以下步骤:根据结果数据库中存储的指标数据,确定影响数据预警的关联指标;根据关联指标,确定对应的关联业务;确定对应关联业务的任务处理方案,并执行。
132.在其中一个实施例中,计算机程序被处理器执行时实现得到对应所述目标预警指标的指标数据之后,还可以实现以下步骤:对预警指标主表中目标预警指标的属性数据进行更新,并对更新后的预警指标主表进行轮询。
133.在其中一个实施例中,计算机程序被处理器执行时还可以实现以下步骤:接收终端的订阅请求,订阅请求中携带有被订阅的订阅指标;将订阅指标对应的业务数据和/或指标数据推送至终端,并通过终端展示。
134.在一个实施例中,提供了一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
135.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限,ram以多种形式可得,诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink) dram(sldram)、存储器总线(rambus)直接ram
(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
136.以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
137.以上所述实施例仅表达了本技术的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本技术构思的前提下,还可以做出若干变形和改进,这些都属于本技术的保护范围。因此,本技术专利的保护范围应以所附权利要求为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1