一种数据处理方法、设备及计算机可读介质
技术领域
本申请涉及信息技术领域,尤其涉及一种数据处理方法、设备及计算机可读介质。
背景技术
随着互联网技术的发展,用户在互联网上实施的行为也越来越多,例如在互联网上进行购物、消费等。随着时间的推移,互联网上的交易系统中会积累很多的用户进行交易的事件数据,例如交易时间、交易金额、交易次数等,这些事件数据能够用于进行数据挖掘,从而获得一些能够用于评价风险的指标数据。
因此,对于风险防控的运营人员来说希望能基于这些历史事件数据,进行离线的过滤和加工,进而提取出一些能用于线上实时防控的指标数据。目前通用的方案时,根据指标数据的需求编写对应的任务,在离线数据平台中执行,获得执行结果(即所需要的指标数据),然后进行数据回流,把执行结果中的指标数据导入到线上数据库使用。
但是,由于风控运营人员在离线数技术处理方面(如脚本编写、调度、数据回流)能力欠缺,此种方案的缺点如下:
1、需要根据每种需求编写任务的脚本代码,复杂度高,风控运营人员不具备相应的能力,需要依赖于编程人员的配合才可以顺利获得需要的指标数据。
2、每种指标数据的需求都需要编写对应的任务,工作量大。
3、编写脚本、离线计算、数据回流都需要人工干预,处理效率低。
申请内容
本申请的一个目的是提供一种数据处理的方案,用以解决现有方案中复杂度高、工作量大、处理效率低的问题。
本申请实施例中提供了一种数据处理方法,该方法包括:
响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系,其中,所述任务用于在被执行时实现相应的处理,所述拓扑关系表示所述多个任务的执行顺序;
基于所述拓扑关系调度并执行所述多个任务,以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。
本申请实施例还提供了一种数据处理设备,该设备包括:
任务构建模块,用于响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系,其中,所述任务用于在被执行时实现相应的处理,所述拓扑关系表示所述多个任务的执行顺序;
任务执行模块,用于基于所述拓扑关系调度并执行所述多个任务,以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。
此外,本申请的一些实施例还提供了一种计算设备,该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发所述设备执行所述的数据处理方法。
本申请的另一些实施例还提供了一种计算机可读介质,其上存储有计算机程序指令,所述计算机可读指令可被处理器执行以实现所述的数据处理方法。
本申请实施例提供方案中,进行数据处理设备可以响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系,当基于所述拓扑关系调度并执行所述多个任务时,可以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。对于用户来说,仅需要了解指标数据对应的指标配置信息和指标提取规则即可,适合于风险防控的运营人员。同时,设备在获得指标配置信息和指标提取规则之后,能够自动生成相应的任务及拓扑关系,并且能够按照拓扑关系顺序执行,完成离线处理至数据回流的整个过程,工作量小且无需人工干预。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1为本申请实施例提供的一种数据处理方法的处理流程图;
图2为本申请实施例中数据计算任务、数据提取任务和回流任务之间的拓扑关系图;
图3为本申请实施例中数据处理方案的一种实际应用的场景示意图;
图4为本申请实施例中数据处理方案实际应用场景中的处理流程图;
图5为本申请实施例提供的一种数据处理设备的结构示意图;
图6为本申请实施例提供的一种计算的结构示意图;
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体,可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的装置或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
本申请实施例提供了一种数据处理方法,执行该方法的数据处理设备可以响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系,当基于所述拓扑关系调度并执行所述多个任务时,可以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。对于用户来说,仅需要了解指标数据对应的指标配置信息和指标提取规则即可,适合于风险防控的运营人员。同时,设备在获得指标配置信息和指标提取规则之后,能够自动生成相应的任务及拓扑关系,并且能够按照拓扑关系顺序执行,完成离线处理至数据回流的整个过程,工作量小且无需人工干预。
在实际场景中,执行该方法的数据处理设备可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备。其中,所述用户设备包括但不限于个人计算机、智能手机、平板电脑等各类终端设备,所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现,可以用于实现设置闹钟时的部分处理功能。在此,云由基于云计算(Cloud Computing)的大量主机或网络服务器构成,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个虚拟计算机。
图1示出了本申请实施例提供的一种数据处理方法的处理流程,该方法至少包括如下处理步骤:
步骤S101,响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系。
在一些实施例中,在获取用户输入的指标配置信息和指标提取规则时,可以向用户提供一输入界面,用户通过在该输入界面提供的输入栏中进行相关内容的输入;或者对应于常见的几种业务场景,该输入界面中也可以提供备选的指标配置信息和指标提取规则,用户通过各种方式从备选的选项进行选取,从而实现相关内容的输入。
所述任务用于在被执行时实现相应的处理,该任务的实质可以是可供数据处理设备执行的脚本代码,根据运行环境的不同,可以采用各类与运行环境相适应的脚本代码。在创建所述任务时,可以根据实际业务场景的需求,预先设定任务的模板,在获取指标配置信息和指标提取规则之后,可以基于获取的指标配置信息和指标提取规则,调整任务模板中的可变内容,进而创建适用于本次数据处理的任务。
由于在指标数据的处理过程中会涉及多个的步骤,例如计算获取指标数据、提取目标指标数据、数据回流等,每次指标数据的处理都可以对应多个任务,以实现对应的处理步骤。为了保证整个处理过程的顺利进行,任务之间相互依赖,需要按照特定的顺序执行,因此在创建多个任务时,还需要生成多个任务之间的拓扑关系。该拓扑关系表示所述多个任务的执行顺序,由此使得多个任务在处理逻辑上形成包含开始和结束的拓扑。
步骤S102,基于所述拓扑关系调度并执行所述多个任务,以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。由此,若用户需要使用这些目标指标数据进行风险防控,则可以从目标数据库中获取并使用。
在本申请的一些实施例中,所述任务可以包括数据计算任务、数据提取任务和回流任务。
所述数据计算任务根据所述指标配置信息创建,用于在被执行时计算所述指标配置信息对应的指标数据。为了能够准确地获取用户需要使用的内容,所述指标配置信息至少包括统计数据源、统计主体和统计指标这三部分信息,所述统计数据源用于表示事件数据的来源,以涉及交易的场景为例,统计数据源可以是关于记录交易事件的某个数据库或者数据表等。所述统计主体用于表示事件数据对应的事件实施主体,例如在前述涉及交易的场景中,所述统计主体可以是本次交易其中一方的用户帐号等标识信息。所述统计指标用于表示需要计算指标数据的具体内容,例如在前述涉及交易的场景中,所述统计指标可以是统计交易的次数或者计算总交易金额等。
由此,当数据计算任务在被执行时,可以从所述统计数据源获取关于所述统计主体的事件数据,并根据统计指标计算指标数据。例如,若用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user1,统计指标为交易次数,结合预设的任务模版可以生成本实施中对应的数据计算任务。当该数据计算任务在被执行时,从数据库A中获取关于用户user1的事件数据,例如关于用户user1的事件数据的记录有17条,由于统计指标是交易次数,因此可以对事件数据的记录进行计数确定指标数据即为交易次数17次。
还如,若用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user2,统计指标为总交易金额,结合预设的任务模版生成本实施中对应的数据计算任务。当该数据计算任务在被执行时,从数据库A中获取关于用户user2的事件数据,例如关于用户user2的事件数据的记录有14条,每条记录中存在一个交易金额的字段,对该14条记录中该字段的值进行累加,计算出总交易金额为2500,则可以确定指标数据即为2500。
所述数据提取任务根据所述指标提取规则确定,用于在被执行时基于所述指标提取规则从所述指标数据中提取目标指标数据。其中,所述指标提取规则是用于对数据计算任务获得的指标数据进行筛选的信息,用户通过设置合适的指标提取规则可以在计算获得的指标数据中提取出需要的部分,以用于风险防控等其它后续处理。例如,所述指标提取规则可以是交易次数>15,若前例中的数据库中的统计主体还包括用户user3和user4,其对应的交易次数的指标数据分别为11次和20次,由此数据计算任务被执行后所获得指标数据如下表所示:
用户 |
交易次数 |
user1 |
17 |
user2 |
14 |
user3 |
11 |
user4 |
20 |
当数据提取任务被执行之后,由于其对应的指标提取规则为交易次数>15,由此提取的目标指标数据为user1,17次和user4,20次。
对于前述的实例,所述指标提取规则也可以与总交易金额相关,例如该指标提取规则可以设定为总交易金额≥2000。由此执行相应的数据提取任务之后,也可以提取对应的目标指标数据,例如user2,2500。在此,本领域技术人员应当能够理解,上述的指标配置信息、指标提取规则的具体内容仅为举例,现有或今后出现的其他用户访问记录如果能够适用于本申请,也应该包含在本申请的保护范围内,并以引用的形式包含于此。
所述回流任务用于在被执行时将所述目标指标数据发送至目标数据库,其中,所述目标数据库是指用于存储目标指标数据的数据库,以便于需要使用目标指标数据的后续处理设备能够从该数据库中获取到需要的数据。例如,在离线数据挖掘实现风险防控的场景中,本申请的方案运行于离线计算平台中,而所述目标数据库可以是线上数据库。
基于上述内容可知,数据计算任务、数据提取任务和回流任务之间存在一定的依赖关系,即先需要执行数据计算任务以计算出指标数据,然后才能够执行数据提取任务以从中提取出目标指标数据,最后才可以执行回流任务以发送目标指标数据。因此,数据计算任务、数据提取任务和回流任务之间的拓扑关系如图2所示,在基于所述拓扑关系调度并执行所述多个任务时,可以基于所述如图2所示的拓扑关系依次调度并执行数据计算任务、数据提取任务和回流任务。
在本申请的一些实施例中,可以根据实际场景的不同设定不同的处理周期,例如处理周期可以设定为1小时、10小时、一天或者一周等。基于设定的处理周期,可以将数据计算任务拆分为增量计算任务和全量计算任务,其中,增量计算任务基于每个新的处理周期中新增的事件数据进行计算,因此所述增量计算任务在被执行时,可以获取所述指标配置信息对应的增量指标数据,该增量指标数据对应最近一个处理周期内的指标数据。
而所述全量计算任务在被执行时获取所述指标配置信息对应的全量指标数据,其中,所述全量指标数据为最近多个处理周期内的指标数据。在本实施例中,根据实际场景中的不同需求,全量可以有不同的含义,例如可以表示从首个处理周期开始至当前处理周期的范围,即已经过的所有处理周期对应的范围;也可以是从当前处理周期往前追溯若干个处理周期的范围,即预设数量的处理周期对应的范围。对应地,所述全量指标数据所表示的最近多个处理周期内的指标数据,可以是表示从首个处理周期开始至当前处理周期的所有指标数据,例如用户user1的所有交易金额;或者,也可以是从当前处理周期往前追溯若干个处理周期内的指标数据,例如处理周期为一天时,用户user1最近一周内的总交易金额。
在实际场景中,用户可以通过输入不同的统计指标来确定全量所表示的数据范围,例如可以是一周的交易次数、一个月的交易次数或者所有的交易次数等。
由于通过执行增量计算任务能够获取最近一个处理周期内的所述指标配置信息对应的指标数据,因此为了提高处理效率,在执行全量计算任务时无需直接基于相应的事件数据进行计算,而是采用迭代的方式进行计算,即在所述增量计算任务执行完成之后,执行全量计算任务,以基于前一次执行全量计算任务所获取的全量指标数据和本次增量计算任务所获取的指标数据,获取本次的全量指标数据。
例如,用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user1,统计指标为所有的交易次数,若处理周期为1天,对应每天00:00:00~23:59:59中产生的事件数据。结合预设的任务模版可以生成本实施中对应的增量计算任务和全量计算任务,首先执行增量计算任务,从数据库A中获取今天00:00:00~23:59:59内关于用户user1的事件数据,若有3条,则可以确定增量指标数据即为3次。若介质到昨天的所有交易次数为14次,即前一次执行全量计算任务所获取的全量指标数据为14次,由此基于前一次执行全量计算任务所获取的全量指标数据14次和本次增量计算任务所获取的指标数据3次,获取本次的全量指标数据17次。
本申请的一些实施例中,数据处理设备可以通过设置一些数据表用于存储整个数据处理过程中所产生的数据。例如对于增量计算任务、全量计算任务所计算获得的增量指标数据和全量指标数据,可以分别设置增量表和全量表,所述增量表用于存储执行增量计算任务所获取的指标数据,所述全量包用于存储执行全量计算任务所获取的全量指标数据。在实际场景中,所述增量表和全量表中可存储的数据大小可以根据需求设定,例如所述增量表可以仅存储本次增量计算任务的计算结果,每次执行增量计算任务之后覆盖前一次的数据,或者也可以存储最近N次的计算结果,每次执行增量计算任务之后覆盖最早一次的数据。类似地,所述全量表也可以根据实际场景的需求采用不同的具体存储方式,以适应用户所需要获得的指标数据。
在执行数据计算任务时,首先执行增量计算任务,以获取最近一个处理周期内的所述指标配置信息对应的指标数据,并将所述指标数据写入到增量表中,然后执行全量计算任务,基于所述全量表中前一次执行全量计算任务所获取的全量指标数据,以及所述增量表中本次增量计算任务所获取的指标数据进行计算,获取本次的全量指标数据,并写入到全量表中。
本申请的另一些实施例中,还可以设置临时表,用于存储从所述指标数据中提取目标指标数据,每次提取到的目标指标数据可以先暂时存放在临时表中,在执行回流任务时,从所述临时表中读取出所需要的目标指标数据即可发送至目标数据库。由此,本申请实施例中,在执行数据提取任务和回流任务时,首先执行数据提取任务,以基于所述指标提取规则从所述指标数据中提取目标指标数据,并写入到所述临时表中,然后执行回流任务,以从所述临时表中读取所述目标指标数据,并发送至目标数据库。
由于设置了特定的数据表,用于统一存储数据处理过程产生的中间数据,因此中间数据都可以存储于特定的数据表中,存储和使用更加规范,需要使用时从特定的数据表中提取即可,便于预先设计任务模板,使得本申请实施例中的方案实现更加简单高效。
基于同一发明构思,本申请实施例中还提供了一种数据处理设备,所述设备对应的方法是前述实施例中数据处理方法,并且其解决问题的原理与该方法相似。
图3示出了本申请实施例提供的一种数据处理设备的结构示意图,该设备包括任务构建模块310和任务执行模块320。其中,所述任务构建模块响应于用户输入的指标配置信息和指标提取规则,创建多个任务,并生成多个任务之间的拓扑关系。
在一些实施例中,在获取用户输入的指标配置信息和指标提取规则时,可以向用户提供一输入界面,用户通过在该输入界面提供的输入栏中进行相关内容的输入;或者对应于常见的几种业务场景,该输入界面中也可以提供备选的指标配置信息和指标提取规则,用户通过各种方式从备选的选项进行选取,从而实现相关内容的输入。
所述任务用于在被执行时实现相应的处理,该任务的实质可以是可供数据处理设备执行的代码,根据运行环境的不同,可以采用各类与运行环境相适应的代码。在创建所述任务时,可以根据实际业务场景的需求,预先设定任务的模板,在获取指标配置信息和指标提取规则之后,可以基于获取的指标配置信息和指标提取规则,调整任务模板中的可变内容,进而创建适用于本次数据处理的任务。
由于在指标数据的处理过程中会涉及多个的步骤,例如计算获取指标数据、提取目标指标数据、数据回流等,每次指标数据的处理都可以对应多个任务,以实现对应的处理步骤。为了保证整个处理过程的顺利进行,任务之间相互依赖,需要按照特定的顺序执行,因此在创建多个任务时,还需要生成多个任务之间的拓扑关系。该拓扑关系表示所述多个任务的执行顺序,由此使得多个任务在处理逻辑上形成包含开始和结束的拓扑。
任务执行模块基于所述拓扑关系调度并执行所述多个任务,以计算所述指标配置信息对应的指标数据,基于所述指标提取规则从所述指标数据中提取目标指标数据,并将所述目标指标数据发送至目标数据库。由此,若用户需要使用这些目标指标数据进行风险防控,则可以从目标数据库中获取并使用。
在本申请的一些实施例中,所述任务可以包括数据计算任务、数据提取任务和回流任务。
所述数据计算任务根据所述指标配置信息创建,用于在被执行时计算所述指标配置信息对应的指标数据。为了能够准确地获取用户需要使用的内容,所述指标配置信息至少包括统计数据源、统计主体和统计指标这三部分信息,所述统计数据源用于表示事件数据的来源,以涉及交易的场景为例,统计数据源可以是关于记录交易事件的某个数据库或者数据表等。所述统计主体用于表示事件数据对应的事件实施主体,例如在前述涉及交易的场景中,所述统计主体可以是本次交易其中一方的用户帐号等标识信息。所述统计指标用于表示需要计算指标数据的具体内容,例如在前述涉及交易的场景中,所述统计指标可以是统计交易的次数或者计算总交易金额等。
由此,当数据计算任务在被执行时,可以从所述统计数据源获取关于所述统计主体的事件数据,并根据统计指标计算指标数据。例如,若用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user1,统计指标为交易次数,结合预设的任务模版可以生成本实施中对应的数据计算任务。当该数据计算任务在被执行时,从数据库A中获取关于用户user1的事件数据,例如关于用户user1的事件数据的记录有17条,由于统计指标是交易次数,因此可以对事件数据的记录进行计数确定指标数据即为交易次数17次。
还如,若用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user2,统计指标为总交易金额,结合预设的任务模版生成本实施中对应的数据计算任务。当该数据计算任务在被执行时,从数据库A中获取关于用户user2的事件数据,例如关于用户user2的事件数据的记录有14条,每条记录中存在一个交易金额的字段,对该14条记录中该字段的值进行累加,计算出总交易金额为2500,则可以确定指标数据即为2500。
所述数据提取任务根据所述指标提取规则确定,用于在被执行时基于所述指标提取规则从所述指标数据中提取目标指标数据。其中,所述指标提取规则是用于对数据计算任务获得的指标数据进行筛选的信息,用户通过设置合适的指标提取规则可以在计算获得的指标数据中提取出需要的部分,以用于风险防控等其它后续处理。例如,所述指标提取规则可以是交易次数>15,若前例中的数据库中的统计主体还包括用户user3和user4,其对应的交易次数的指标数据分别为11次和20次,由此数据计算任务被执行后所获得指标数据如下表所示:
当数据提取任务被执行之后,由于其对应的指标提取规则为交易次数>15,由此提取的目标指标数据为user1,17次和user4,20次。
对于前述的实例,所述指标提取规则也可以与总交易金额相关,例如该指标提取规则可以设定为总交易金额≥2000。由此执行相应的数据提取任务之后,也可以提取对应的目标指标数据,例如user2,2500。在此,本领域技术人员应当能够理解,上述的指标配置信息、指标提取规则的具体内容仅为举例,现有或今后出现的其他用户访问记录如果能够适用于本申请,也应该包含在本申请的保护范围内,并以引用的形式包含于此。
所述回流任务用于在被执行时将所述目标指标数据发送至目标数据库,其中,所述目标数据库是指用于存储目标指标数据的数据库,以便于需要使用目标指标数据的后续处理设备能够从该数据库中获取到需要的数据。例如,在离线数据挖掘实现风险防控的场景中,本申请的方案运行于离线计算平台中,而所述目标数据库可以是线上数据库。
基于上述内容可知,数据计算任务、数据提取任务和回流任务之间存在一定的依赖关系,即任务执行模块先需要执行数据计算任务以计算出指标数据,然后才能够执行数据提取任务以从中提取出目标指标数据,最后才可以执行回流任务以发送目标指标数据。因此,数据计算任务、数据提取任务和回流任务之间的拓扑关系如图2所示,在基于所述拓扑关系调度并执行所述多个任务时,可以基于所述如图2所示的拓扑关系依次调度并执行数据计算任务、数据提取任务和回流任务。
在本申请的一些实施例中,任务执行模块可以根据实际场景的不同设定不同的处理周期,例如处理周期可以设定为1小时、10小时、一天或者一周等。基于设定的处理周期,可以将数据计算任务拆分为增量计算任务和全量计算任务,其中,增量计算任务基于每个新的处理周期中新增的事件数据进行计算,因此所述增量计算任务在被执行时,可以获取所述指标配置信息对应的增量指标数据,该增量指标数据对应最近一个处理周期内的指标数据。
而所述全量计算任务在被执行时获取所述指标配置信息对应的全量指标数据,其中,所述全量指标数据为最近多个处理周期内的指标数据。在本实施例中,根据实际场景中的不同需求,全量可以有不同的含义,例如可以表示从首个处理周期开始至当前处理周期的范围,即已经过的所有处理周期对应的范围;也可以是从当前处理周期往前追溯若干个处理周期的范围,即预设数量的处理周期对应的范围。对应地,所述全量指标数据所表示的最近多个处理周期内的指标数据,可以是表示从首个处理周期开始至当前处理周期的所有指标数据,例如用户user1的所有交易金额;或者,也可以是从当前处理周期往前追溯若干个处理周期内的指标数据,例如处理周期为一天时,用户user1最近一周内的总交易金额。
在实际场景中,用户可以通过输入不同的统计指标来确定全量所表示的数据范围,例如可以是一周的交易次数、一个月的交易次数或者所有的交易次数等。
由于通过执行增量计算任务能够获取最近一个处理周期内的所述指标配置信息对应的指标数据,因此为了提高处理效率,在执行全量计算任务时无需直接基于相应的事件数据进行计算,而是采用迭代的方式进行计算,即在所述增量计算任务执行完成之后,执行全量计算任务,以基于前一次执行全量计算任务所获取的全量指标数据和本次增量计算任务所获取的指标数据,获取本次的全量指标数据。
例如,用户输入的指标配置信息中,统计数据源为交易事件的数据库A,统计主体为用户user1,统计指标为所有的交易次数,若处理周期为1天,对应每天00:00:00~23:59:59中产生的事件数据。结合预设的任务模版可以生成本实施中对应的增量计算任务和全量计算任务,首先执行增量计算任务,从数据库A中获取今天00:00:00~23:59:59内关于用户user1的事件数据,若有3条,则可以确定增量指标数据即为3次。若介质到昨天的所有交易次数为14次,即前一次执行全量计算任务所获取的全量指标数据为14次,由此基于前一次执行全量计算任务所获取的全量指标数据14次和本次增量计算任务所获取的指标数据3次,获取本次的全量指标数据17次。
本申请的一些实施例中,数据处理设备可以通过设置一些数据表用于存储整个数据处理过程中所产生的数据。例如对于增量计算任务、全量计算任务所计算获得的增量指标数据和全量指标数据,可以分别设置增量表和全量表,所述增量表用于存储执行增量计算任务所获取的指标数据,所述全量包用于存储执行全量计算任务所获取的全量指标数据。在实际场景中,所述增量表和全量表中可存储的数据大小可以根据需求设定,例如所述增量表可以仅存储本次增量计算任务的计算结果,每次执行增量计算任务之后覆盖前一次的数据,或者也可以存储最近N次的计算结果,每次执行增量计算任务之后覆盖最早一次的数据。类似地,所述全量表也可以根据实际场景的需求采用不同的具体存储方式,以适应用户所需要获得的指标数据。
任务执行模块在执行数据计算任务时,首先执行增量计算任务,以获取最近一个处理周期内的所述指标配置信息对应的指标数据,并将所述指标数据写入到增量表中,然后执行全量计算任务,基于所述全量表中前一次执行全量计算任务所获取的全量指标数据,以及所述增量表中本次增量计算任务所获取的指标数据进行计算,获取本次的全量指标数据,并写入到全量表中。
本申请的另一些实施例中,还可以设置临时表,用于存储从所述指标数据中提取目标指标数据,每次提取到的目标指标数据可以先暂时存放在临时表中,在执行回流任务时,从所述临时表中读取出所需要的目标指标数据即可发送至目标数据库。由此,本申请实施例中,在执行数据提取任务和回流任务时,首先执行数据提取任务,以基于所述指标提取规则从所述指标数据中提取目标指标数据,并写入到所述临时表中,然后执行回流任务,以从所述临时表中读取所述目标指标数据,并发送至目标数据库。
由于设置了特定的数据表,用于统一存储数据处理过程产生的中间数据,因此中间数据都可以存储于特定的数据表中,存储和使用更加规范,需要使用时从特定的数据表中提取即可,便于预先设计任务模板,使得本申请实施例中的方案实现更加简单高效。
图4示出了本申请实施例中数据处理方案的一种应用场景,该场景中以线上交易系统中的交易数据作为处理的事件数据,处理获得相应的指标数据之后,发送至线上数据库以用于后续的风险防控。
其中,线上交易系统410中的事件数据以可以是用户进行线上交易后生成的交易记录,可以包括:包括用户帐号、交易时间、交易金额、商品内容等信息,这些交易记录在产生之后可以采用预设的方式被同步至离线计算平台。所述离线计算平台420基于本申请实施例提供的数据处理方案获得目标指标数据之后,能够将其发送至线上数据库430。线上数据库430中存储的目标指标数据可以用于实现风险防控,例如在需要控制用户退货时的风险时,需要判断用户是否为交易平台上的优质用户,可以设定当用户的月交易金额≥2000时,认为该用户是优质用户,在退货时可以直接返还退货款;而月交易金额<2000的用户,则需要等待商家确认收到退货的货物时才会返回退货款。
在该场景中,离线计算平台420实现数据处理的过程如图5所示,包括如下的流程:
步骤S501,风控运营人员可以根据该场景的需求,输入指标规则,使得离线计算平台获取到用户输入的指标规则。该指标规则包括了指标配置信息和指标提取规则,例如对于本申请实施例中的需要确定优质用户的场景,所述指标配置信息如下几项:统计数据源为线上交易系统中存储交易记录的数据库,统计主体为各个用户帐号,统计指标为月交易金额,而指标提取规则则是月交易金额≥2000。
步骤S502,离线计算平台对收到的指标规则进行分析、转换和拆解,使得指标规则中的信息分解成数据计算部分、数据提取部分和数据回流部分。
步骤S503,离线计算平台进行任务创建,根据指标规则中的信息,结合任务模版,自动生成可执行的任务。
步骤S504,离线计算平台进行拓扑生成,对于一种需要的目标指标数据都会对应多个任务,例如可以包括数据计算任务、数据提取任务和回流任务,这些任务都是相互依赖的,在执行时需要按照一定的先后顺序,能够生成一个包含开始和结束的任务拓扑。在实际场景中,可以同时处理多种目标指数数据,此时会对应多组任务,每组任务之间可以相互独立并发处理。
步骤S505,拓扑关系可以采用拓扑图的形式生成,以用于进行任务的调度。
步骤S506,根据调度,依次执行数据计算任务、数据提取任务和回流任务,把离线结果数据(即目标指标数据)同步到线上数据库中,使得风控系统可以根据风控策略可以引用离线结果数据。
由此,本申请实施例中的数据处理方案可以用户对指标数据的诉求,采用指标配置信息和指标提取规则的方式描述,而不是复杂的脚本语句,这样对于不熟悉脚本编写的运营人员而言,可以采用他们熟悉的方式定义数据诉求,降低了使用的门槛。
并且本申请实施例的方案把复杂的任务的编写交给了设备去自动适配、生成,用户在需要增加一个数据诉求时,仅需要增加相应的指标配置信息和指标提取规则,而不用再重新编写复杂的脚本语句,提高了处理效率。
同时,本申请实施例的方案把不仅把数据的计算、提取任务进行组装和调度,也把离线计算结果进行了回流,形成了从计算到回流的整个处理流程,中间过程不需要人工干预,降低了实现成本。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一些实施例包括一个如图6所示的计算设备,该设备包括存储有计算机可读指令的一个或多个存储器610和用于执行计算机可读指令的处理器620,其中,当该计算机可读指令被该处理器执行时,使得所述设备执行基于前述本申请的多个实施例的方法和/或技术方案。
此外,本申请的一些实施例还提供了一种计算机可读介质,其上存储有计算机程序指令,所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中,本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。