具体实施方式
本申请实施例提供一种实现批量数据处理的方法、系统和计算机集群。
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
本申请实施例提供一种实现批量数据处理的方法,如图1所示,包括:
S110:基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表。
仍以前述对账系统需要将大量三方支付流水和对应的银行交易流水进行资金核对的例子为例进行说明。设某一银行(银行1)的海量数据的原始数据表如下所示:
表X:原始数据表
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
A0001 |
银行1 |
A_1(充值) |
|
|
|
|
|
|
A0002 |
银行1 |
A_2(提现) |
|
|
|
|
|
|
A0003 |
银行1 |
A_1(充值) |
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
例如表X有3000万条数据。上表X中,账号这一维度,例如末尾为若干位数字。此外,例如还存在一个业务维度,如为银行渠道。所述银行渠道一般表示清算银行面向第三方支付公司某个业务提供的资金接口,例如充值、提现等,通过银行渠道进行区分。
并且,所述至少两个不相关的维度包括至少两个值随序号变化规律不相同的维度。对于上述例子来说,账号与银行渠道不具有相关性。即表X中账号随序号的变化规律与银行渠道随序号的变化规律并不一致,也不具有相似的规律。
基于上述表X的原始数据,可以其中的账号(第一维度)和银行渠道(第二维度)建立处理任务表。例如对账号数字部分以100取模(账号数字部分除以100的余数)以及银行渠道的种类这两个维度的结合建立处理任务表,如下:
表Y:处理任务表
这样,可以建立处理任务表。其中,处理任务1(RN=1)的为银行渠道为A_1及账号数字部分以10取模(账号数字部分除以10的余数)为0(表Y中显示00)的数据。以此类推。可见,该例子中两个维度分别是账号和银行渠道。
上述给出了两个维度的例子。当然,也可以基于海量数据的原始数据表中三个不相关的维度建立处理任务表,如下表:
表T:处理任务表
这样,可以建立处理任务表,其中,处理任务1(RN=1)的为银行渠道为A_1、账号数字部分以10取模为0,账号类型为借方账号的的数据。以此类推。可见,该例子中三个维度分别是账号、银行渠道和账号类型。当然,还可以包括第四维度,例如将业务分类(包括借记卡、网银、基金等)作为第四维度。此外,还可以包括第五维度、第六维度等等,这里不做限定。需要说明的是,上述账号、银行渠道并不是必须为第一维度和第二维度,也可以将账号和账号类型作为第一维度和第二维度;也可以是将账号、业务分类作为第一维度和第二维度;也可以是将账号类型、业务分类作为第一维度和第二维度;等等。
此外,S110也可以具体如下:
S111:基于海量数据的原始数据表中第一维度建立数据分表。
S112:基于建立的数据分表并根据所述原始数据表中的第二维度建立处理任务表。
所述第二维度与第一维度不相关。
本实施例中,如对原始数据表的账号这一维度的数字部分按照以100取模的结果0,1,2,…,99来分配为100个分表:
表X-分表_00:
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
… |
A0100 |
银行1 |
A_1 |
|
|
|
|
|
|
|
A0200 |
银行1 |
A_2 |
|
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
|
表X-分表_01:
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
… |
A0001 |
银行1 |
A_1 |
|
|
|
|
|
|
|
A0101 |
银行1 |
A_2 |
|
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
|
表X-分表_02:
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
… |
A0002 |
银行1 |
A_1 |
|
|
|
|
|
|
|
A0102 |
银行1 |
A_2 |
|
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
|
……
表X-分表_99:
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
… |
A0099 |
银行1 |
A_2 |
|
|
|
|
|
|
|
A0199 |
银行1 |
A_1 |
|
|
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
|
其中,分表后缀例如为以表X按照账号的数字部分取模后的结果对核对任务进行分配。
进而,基于上述表X的各分表,可以根据所述原始数据表中的第二维度建立处理任务表。例如在上述表X-分表_00,表X-分表_01,表X-分表_02,…,表X-分表_99的基础之上,可以基于银行渠道这一业务维度账号建立处理任务表——表Z,如下:
表Z:处理任务表
上述例子中的两个维度,即账号与银行渠道不具有相关性,即账号随序号的变化规律与银行渠道随序号的变化规律并不一致,也不具有相似的规律。这样,表Y与Z中每一行的任务分配对应原始数据表中的数据将会大幅缩小。
如上方式创建处理任务,可以控制数据处理的分表的大小,从而可以灵活地控制核对量级。较小数据量的数据处理表,可以实现批量数据处理过程的精细化的管理和控制。
S120:捞取所述处理任务表中的待处理任务。
计算机集群中的服务器可以捞取所述处理任务表中的待处理任务,从而各服务器可以捞取到待处理任务。例如计算机集群中的某服务器捞取到所述处理任务表中的待处理任务的序号为RN=1,即对应后缀为00的分表中银行渠道为A_1的所有流水。该数据量将会大幅降低。
计算机集群中的各服务器可以并发方式捞取所述处理任务表中的待处理任务,从而各服务器可以捞取到待处理任务。例如计算机集群中的第一服务器捞取到所述处理任务表中的待处理任务的序号为RN=2,即对应后缀为01的分表中银行渠道为A_1的所有流水;计算机集群中的第二服务器捞取到所述处理任务表中的待处理任务的序号为RN=3,即对应后缀为02的分表中银行渠道为A_1的所有流水;等等。每一服务器捞取到的每一处理任务所对应的数据量将会大幅降低。
S130:处理所述捞取到的待处理任务所对应的原始数据表中的数据。
计算机集群中的服务器捞取到待处理任务后,进而可以处理所述捞取到的待处理任务所对应的原始数据表中的数据。
本申请上述实施例中,基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表,可以控制数据处理的分表的大小,从而可以灵活地控制核对量级。较小数据量的数据处理表,可以实现批量数据处理过程的精细化的管理和控制。
S120中,当计算机集群中的两个服务器并发捞取时捞取到同一条RN的核对任务,则S130中,先捞取到核对任务可以先执行数据处理,这里即核对数据。而后捞取到的可以放弃捞取到的任务,并再次进行捞取。可以在预定时间间隔之后进行下次捞取。这种分布式分发调用捞取核对任务的方式,可以充分利用每台服务器来达到尽可能快速地核对的目的。
所述原始数据表和处理任务表可以存储于数据库中。具体的,同一银行的原始数据表和处理任务表可以存储于同一数据库中。对于数据库来说,可以设置并发访问数量,以控制数据访问给数据库带来的负荷压力。例如,银行1的原始数据表和如S110建立的处理任务表可以存储于数据库1中,银行2的原始数据表和如S110建立的处理任务表可以存储于数据库2中。
此外,所述处理任务表也可以是存储于计算机集群中。
S120和S130中可以利用计算机集群中的分布式分发调功能来捞取和处理。在部署分布式集群的场景下,例如数据处理任务需要整个计算机集群中所有服务器进行计算,那么该计算机集群中的某个服务器收到一条调用指令时,该服务器可以将该指令分发到集群中各个服务器上,进而各服务器并发处理任务。一般这种策略适合集群批量数据处理。
上述的例子中,表X有3000万条数据。如果按照现有技术的处理方式,可能每个分表的数量达30万条,即每一处理任务包括30万条数据的核对。而按照本申请实施例的方式,由于在账号的基础上还引入了业务渠道,该业务渠道例如有3种取值,且假设这3种业务渠道取值对应的数据数量近似,则以账号和业务渠道这两个维度创建处理任务表后,每一处理任务包括的数据可以降低到约10万条左右,即单表核对量级为10w。这样,通过降低单表的数据量,可以降低访问数据库带来的资源消耗,实现精细化的管理和控制。
进一步的,为了控制S130的处理速度,可以对数据库允许的访问并发数进行限制。例如,数据库1中存储的银行1的原始数据表每天的流水量级较大,则可以将数据库1的并发数调高,从而加快处理速度。调高所述并发数后,不可避免的会加重数据库的资源负担,从而加重负荷。例如,在某些对数据库压力较大时间段(如双11大促活动等)会占用较多的计算资源。这时,可以调低并发数,从而保证其他正常业务不受影响。这样,通过引入数据库的并发数调整,可以灵活地控制在不同场景下处理数据对数据库计算性能带来的影响。
例如数据库1的捞取并发数初始时设置10,计算机集群中的某一服务器或某些服务器接收到捞取指令后,这一服务器或这些服务器可以最多10个并发去数据库1捞取RN=x的任务,这里x的取值为从1到10,也就是一个并发对应一条任务记录。如果数据库1的捞取并发数初始时设置10,计算机集群中的3台服务器接收到捞取指令后,这3台服务器可以最多共10个并发去数据库1捞取RN=x的任务,这里x的取值为从1到10,例如服务器1产生3个向数据库1发起的捞取请求,服务器2产生5个向数据库1发起的捞取请求,服务器3产生2个向数据库1发起的捞取请求。为了控制对数据库1中数据处理的速度,以及调整数据库的负荷压力,可以调高或调低并发数。
上述实施例中,不同维度对应的处理数据量不同,维度对应数据量大的数据在处理时,占用数据库的系统资源较多。具体的,在上面的核对业务流水的例子中,不同业务维度对应的流水量级别不同。业务维度对应的量大的流水在核对时,占用数据库的CPU等系统资源较多。
如上面表X中,假设银行渠道为A_1的数量明显大于为A_2的,这样,在表Y或Z中,RN为1-100中的任一项,其处理任务对应的原始数据表中的数据也明显大于RN为101-200中的任一项。即处理任务表中每一涉及维度A_1的任务对应的原始数据表中的数据量明显大于涉及A_2的。这样,计算机集群在处理数据时,对数据库的访问给服务器带来的资源消耗将基于处理的任务的不同而发生变化。在处理并发数保持不变的情况下,例如保持同时仅允许处理1个任务的情况下,对于处理涉及A_1的数据时数据库的资源占用将较高,对于处理涉及A_2的数据时数据库的资源占用将较低。
图2给出了一个数据库资源占用比例随时间变化的示意图。如图2所示,例如A时刻,数据库存在1个数据任务的处理,这个数据处理任务是关于A_2的数据。由于涉及A_2的数据处理任务中数据量明显少,因此A时刻的数据库系统资源占用比例不高。在B时刻,数据库存在3个数据处理任务,其中1个涉及A_2,2个涉及A_1,此时数据库系统资源占用比例明显提升。在C时刻,数据库存在8个数据处理任务,都是涉及A_2,此时数据库系统资源占用比例达80%。在K时刻,数据库存在6个数据处理任务,都是涉及A_1,此时数据库系统资源占用比例达90%。从C时刻与K时刻数据库系统资源占用比例对比可知,处理一个涉及A_1的任务需要占用的系统资源明显高于处理一个涉及A_2的任务。
核对业务流水的例子中,同样的,处理量大的业务维度对应的流水在核对时对数据库的系统资源的消耗是非常明显的,而其他量小的业务维度对应的流水在核对时,资源消耗比较小。在大促等活动场景时,由于流水数量可能会翻倍,对数据库的系统资源的消耗更为突出。
针对上述问题,本申请实施例还提供一种实现批量数据处理的方法,如图3所示,包括:
S310:基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表。
该步骤与S110类似,不再赘述。
S320:选择所述维度中的一个,并基于所选择的维度中不同值对应数据的量设置任务的并发捞取数量。
仍假设按照前述例子,S310中的两个不相关的维度包括账号数值部分对10取余及银行渠道这一业务维度。这里,选择所述维度中的一个,如前所述,可以选择银行渠道这一业务维度。在上述例子中,银行渠道包括三种取值,如A_1,A_2和A_3。仍例如表X的原始数据表中共有3000万条数据,其中A_1对应的数据量最大,达1800万条,A_2对应的数据量为900万条,A_3对应的数据量为300万条。
可以基于所选择维度中不同值对应数据的量来设置不同值对应任务的并发访问数量。整体来说,可以将所选择维度中取值对应数据量大的设置较大的并发访问数,将所选择维度中取值对应数据量少的设置较少的并发捞取数量。例如,对于数据量最大的A_1来说,可以设置A_1对应任务的并发捞取数量为7;对于数据量较少的A_2来说,可以设置A_2对应任务的并发捞取数量为2;对于数据量最少的A_3来说,A_3对应任务的并发捞取数量为1。
进一步的,可以基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量。例如,表X的原始数据表中共有3000万条数据,其中A_1对应的数据量为1800万条,A_2对应的数据量为900万条,A_3对应的数据量为300万条,则可以设置A_1、A_2及A_3对应数据的并发访问数量为分别为6、3、1,即符合三者对应数据量的比例,同时并发访问数量的总和不超过所在数据库所设置的并发数限制。
类似的,所述并发数可以根据限制数据处理的速度及数据库的负载压力的要求调整。
S330:在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务。
计算机集群中的服务器可以并发捞取所述处理任务表中的待处理任务,从而各服务器可以捞取到待处理任务。具体的,计算机集群在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务。
例如A_1对应任务的并发捞取数量为7,A_2对应任务的并发捞取数量为2,A_3对应任务的并发捞取数量为1。则计算机集群中的服务器捞取银行渠道为A_1的任务最多不超过7条,捞取银行渠道为A_2的任务最多不超过2条,捞取银行渠道为A_3的任务最多不超过1条。
例如基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量,A_1对应任务的并发捞取数量为6,A_2对应任务的并发捞取数量为3,A_3对应任务的并发捞取数量为1。则计算机集群中的服务器捞取银行渠道为A_1的任务最多不超过6条,捞取银行渠道为A_2的任务最多不超过3条,捞取银行渠道为A_3的任务最多不超过1条。
S340:处理所述捞取到的待处理任务所对应的原始数据表中的数据。
计算机集群中的服务器捞取到待处理任务后,进而可以处理所述捞取到的待处理任务所对应的原始数据表中的数据。
本申请上述实施例中,基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表,可以控制数据处理的分表的大小,从而可以灵活地控制核对量级。较小数据量的数据处理表,可以实现批量数据处理过程的精细化的管理和控制。而且,通过所选择的维度中不同值对应数据的量设置任务的并发捞取数量,可以限制并发捞取所述处理任务表中的所选择维度中不同值对应的任务数,进而可以控制数据库资源的消耗,从而降低数据流水产生高峰时间段数据库资源的过高占用。此外,还可以在数据流水产生的低估时间段提高数据库资源的利用率。整体上,图3实施例可以使得数据库资源占用率达到如图4所示的水平,相对于图2,可以达到削峰填谷的作用。
此外,S330中,当计算机集群中的两个服务器并发捞取时捞取到同一条RN的核对任务,则S340中,先捞取到核对任务可以先执行数据处理,这里即核对数据,而后捞取到的可以放弃捞取到的任务,并进行下次捞取。可以在预定时间间隔之后进行下次捞取,即进行下一次捞取。这种分布式分发调用捞取核对任务的方式,可以充分利用每台服务器来达到尽可能快速地核对的目的。
所述原始数据表和处理任务表可以存储于数据库中。具体的,同一银行的原始数据表和处理任务表可以存储于同一数据库中。对于数据库来说,可以设置并发访问数量,以控制数据访问给数据库带来的负荷压力。例如,银行1的原始数据表和如S310建立的处理任务表可以存储于数据库1中,银行2的原始数据表和如S310建立的处理任务表可以存储于数据库2中。
S330和S340中可以利用计算机集群中的分布式分发调功能来捞取和处理。在部署分布式集群的场景下,例如数据处理了任务需要整个计算机集群中所有服务器进行计算,那么在该计算机集群中的某个服务器收到一条调用指令时,可以将该指令分发到集群中各个服务器上,进而各服务器并发处理所述任务。一般这种策略适合集群批量数据处理。
本申请还提供一种实现批量数据处理的系统实施例,可以对应图1所示方法实施例。所述系统可以如图5所示,包括数据库51和计算机集群52,其中:
所述数据库51基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表;
所述计算机集群52捞取所述处理任务表中的待处理任务,并处理所述捞取到的待处理任务所对应的原始数据表中的数据。
优选地,所述至少两个不相关的维度包括:至少两个值随序号变化规律不相同的维度。
优选地,所述数据库包括:
第一建立单元,基于海量数据的原始数据表中第一维度建立数据分表;
第二建立单元,基于建立的数据分表并根据所述原始数据表中的第二维度建立处理任务表。
优选地,所述计算机集群并发捞取所述处理任务表中的待处理任务。
优选地,当所述计算机集群中不同服务器并发捞取时捞取到同一条待处理任务时,先捞取到该待处理任务的服务器执行对应的原始数据表中的数据处理。
优选地,后捞取到该待处理任务的所述服务器放弃处理,并进行下次捞取。
优选地,所述并发捞取所述处理任务表中的待处理任务设置有并发数限制,所述计算机集群同时处理的任务数不大于所述并发数。
优选地,所述并发数根据限制数据处理的速度及数据库的负载压力的要求调整。
本申请还提供一种实现批量数据处理的计算机集群实施例,可以对应图1所示方法实施例。所述计算机集群可以如图6所示,所述计算机集群中的任一服务器包括:
任务建立单元61,基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表;
捞取单元62,用于捞取所述处理任务表中的待处理任务;
处理单元63,并处理所述捞取到的待处理任务所对应的原始数据表中的数据。
优选地,所述至少两个不相关的维度包括:至少两个值随序号变化规律不相同的维度。
优选地,所述任务建立单元包括:
第一建立单元,基于海量数据的原始数据表中第一维度建立数据分表;
第二建立单元,基于建立的数据分表并根据所述原始数据表中的第二维度建立处理任务表。
优选地,所述计算机集群中的服务器并发捞取所述处理任务表中的待处理任务。
优选地,当所述计算机集群中不同服务器并发捞取时捞取到同一条待处理任务时,先捞取到该待处理任务的服务器执行对应的原始数据表中的数据处理。
优选地,后捞取到该待处理任务的所述服务器放弃处理,并进行下次捞取。
优选地,所述并发捞取所述处理任务表中的待处理任务设置有并发数限制,所述计算机集群同时处理的任务数不大于所述并发数。
优选地,所述并发数根据限制数据处理的速度及数据库的负载压力的要求调整。
本申请还提供一种实现批量数据处理的系统实施例,可以对应图3所示方法实施例。所述系统可以包括数括数据库和计算机集群,其中:
所述数据库基于海量数据的原始数据表中至少两个不相关的维度建立处理任务表;选择所述维度中的一个,并基于所选择的维度中不同值对应数据的量设置任务的并发捞取数量;
所述计算机集群在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务;
所述计算机集群处理所述捞取到的待处理任务所对应的原始数据表中的数据。
优选地,所述至少两个不相关的维度包括:至少两个值随序号变化规律不相同的维度。
优选地,所述数据库包括:
第一建立单元,基于海量数据的原始数据表中第一维度建立数据分表;
第二建立单元,基于建立的数据分表并根据所述原始数据表中的第二维度建立处理任务表。
优选地,所述数据库基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量。
优选地,当所述计算机集群中不同服务器并发捞取时捞取到同一条待处理任务时,先捞取到该待处理任务的服务器执行对应的原始数据表中的数据处理。
优选地,后捞取到该待处理任务的服务器放弃处理,并进行下次捞取。
优选地,所述并发捞取数量设置有并发数限制,所述同时处理的任务数不大于所述并发数。
优选地,所述并发数根据限制数据处理的速度及数据库的负载压力的要求调整。
本申请实施例还提供一种实现批量数据处理的方法,如图7所示,包括:
S710:选择海量数据的原始数据表中一个维度,并基于所选择的维度建立处理任务表。
例如,原始数据表与前述一致,如下表X:
表X:原始数据表
账号 |
银行 |
银行渠道(业务维度1) |
业务维度2 |
… |
… |
… |
… |
… |
A0001 |
银行1 |
A_1(充值) |
B_1 |
|
|
|
|
|
A0002 |
银行1 |
A_2(提现) |
B_2 |
|
|
|
|
|
A0003 |
银行1 |
A_1(充值) |
B_3 |
|
|
|
|
|
… |
… |
|
|
|
|
|
|
|
可以选择原始数据表中的业务维度2,例如包括B_1、B_2、B_3…等多个值。
本实施例中,例如业务维度2即业务分类,B_1、B_2、B_3…等值分别为借记卡、网银、基金等。这样,可以基于所述原始数据表中的业务维度2建立处理任务表,例如下表W:
表W:处理任务表
上述例子中,原始数据表中业务分类为借记卡、网银、基金等值的数据的数量可能很不相同。这样,表W中,B_1、B_2、B_3…等值对应的原始数据表中的数据数量也可能很不相同。
S720:基于所选择维度中不同值对应数据的量设置任务的并发捞取数量。
仍假设按照前述例子,S710中的所选择的维度为业务分类这一业务维度,其包括多种不同的取值,如B_1,B_2和B_3等。仍例如表X的原始数据表中共有3000万条数据,其中B_1对应的数据量最大,达800万条,B_2对应的数据量为500万条,B_3对应的数据量为300万条…。
可以基于所选择维度中不同值对应数据的量来设置不同值对应任务的并发访问数量。整体来说,可以将所选择维度中取值对应数据量大的设置较大的并发访问数,将所选择维度中取值对应数据量少的设置较少的并发捞取数量。例如,对于数据量最大的B_1来说,可以设置B_1对应任务的并发捞取数量为7;对于数据量较少的B_2来说,可以设置B_2对应任务的并发捞取数量为2;对于数据量最少的B_3来说,B_3对应任务的并发捞取数量为1。
进一步的,可以基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量。例如,表X的原始数据表中共有3000万条数据,其中B_1对应的数据量为1800万条,B_2对应的数据量为900万条,B_3对应的数据量为300万条,则可以设置B_1、B_2及B_3对应数据的并发访问数量为分别为6、3、1,即符合三者对应数据量的比例,同时并发访问数量的总和不超过所在数据库所设置的并发数限制。
类似的,所述并发数可以根据限制数据处理的速度及数据库的负载压力的要求调整。
S730:在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务。
计算机集群中的服务器可以并发捞取所述处理任务表中的待处理任务,从而各服务器可以捞取到待处理任务。具体的,计算机集群在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务。
例如B_1对应任务的并发捞取数量为7,B_2对应任务的并发捞取数量为2,B_3对应任务的并发捞取数量为1。则计算机集群中的服务器捞取业务分类为B_1的任务最多不超过7条,捞取业务分类为B_2的任务最多不超过2条,捞取业务分类为B_3的任务最多不超过1条。
例如基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量,B_1对应任务的并发捞取数量为6,B_2对应任务的并发捞取数量为3,B_3对应任务的并发捞取数量为1。则计算机集群中的服务器捞取业务分类为B_1的任务最多不超过6条,捞取业务分类为B_2的任务最多不超过3条,捞取业务分类为B_3的任务最多不超过1条。
S740:处理所述捞取到的待处理任务所对应的原始数据表中的数据。
计算机集群中的服务器捞取到待处理任务后,进而可以处理所述捞取到的待处理任务所对应的原始数据表中的数据。
本申请上述实施例中,通过所选择的维度中不同值对应数据的量设置任务的并发捞取数量,可以限制并发捞取所述处理任务表中的所选择维度中不同值对应的任务数,进而可以控制数据库资源的消耗,从而降低数据流水产生高峰时间段数据库资源的过高占用。此外,还可以在数据流水产生的低估时间段提高数据库资源的利用率。整体上,图7实施例可以使得数据库资源占用率达到如图4所示的水平,相对于图2,可以达到削峰填谷的作用。
此外,S730中,当计算机集群中的两个服务器并发捞取时捞取到同一条RN的核对任务,则S740中,先捞取到核对任务可以先执行数据处理,这里即核对数据,而后捞取到的可以放弃捞取到的任务,并进行下次捞取。可以在预定时间间隔之后进行下次捞取,即进行下一次捞取。这种分布式分发调用捞取核对任务的方式,可以充分利用每台服务器来达到尽可能快速地核对的目的。
所述原始数据表和处理任务表可以存储于数据库中。具体的,同一银行的原始数据表和处理任务表可以存储于同一数据库中。对于数据库来说,可以设置并发访问数量,以控制数据访问给数据库带来的负荷压力。例如,银行1的原始数据表和如S710建立的处理任务表可以存储于数据库1中,银行2的原始数据表和如S710建立的处理任务表可以存储于数据库2中。
S730和S740中可以利用计算机集群中的分布式分发调功能来捞取和处理。在部署分布式集群的场景下,例如数据处理了任务需要整个计算机集群中所有服务器进行计算,那么在该计算机集群中的某个服务器收到一条调用指令时,可以将该指令分发到集群中各个服务器上,进而各服务器并发处理所述任务。一般这种策略适合集群批量数据处理。
本申请还提供你一种实现批量数据处理的系统实施例,对应图7所述方法,包括数据库和计算机集群,其中:
所述数据库选择海量数据的原始数据表中一个维度,并基于所选择的维度建立处理任务表;基于所选择维度中不同值对应数据的量设置任务的并发捞取数量;
所述计算机集群在所述并发捞取数量限制下并发捞取所述处理任务表中的待处理任务,并处理所述捞取到的待处理任务所对应的原始数据表中的数据。
优选地,所述数据库基于所选择的维度中不同值对应数据占总数据量的比例来设置任务的并发捞取数量。
优选地,当所述计算机集群中不同服务器并发捞取时捞取到同一条待处理任务时,先捞取到该待处理任务的服务器执行对应的原始数据表中的数据处理。
优选地,后捞取到该待处理任务的服务器放弃处理,并进行下次捞取。
优选地,所述并发捞取数量限制数据处理的速度及数据库的负载压力的要求调整。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(ProgrammableLogic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware DescriptionLanguage,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(AdvancedBoolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等,目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、MicrochipPIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。