一种离线数据批量更新方法、装置和分布式存储系统
技术领域
本申请涉及互联网领域,特别是涉及一种离线数据批量更新方法、装置和分布式存储系统。
背景技术
互联网金融近几年得到了飞速的发展,给很多中小企业和个人解决了部分贷款的需求,互联网金融的出现很好弥补了传统金融机构线下审核和放款手段这个缺陷,但是它又面临着线上交易的风险,因此,风控策略是互联网金融的核心。
而风控策略就必然离不开各种各样的风控模型,为了保证在不同的阶段都能用风控模型进行很好的风险控制,风控模型需要海量用户的不同维度的特征数据作为基础,相关在线服务场景上经常存在百T级以上的查询需求,并且为了加速风控模型的迭代,分布式存储系统中的特征数据能非常快速的批量更新是非常必要的。
目前,采用在线批量更新的方法对分布式存储系统中的特征数据进行更新。但是,这种方法在将新数据批量更新到分布式存储系统的存储节点上时,需要对新数据进行一系列处理,且由于在线检索对在线批量更新的影响,使得数据批量更新的速率较慢,耗时过长。
发明内容
为了解决上述技术问题,本申请提供了离线数据批量更新方法、装置和分布式存储系统,提高数据批量更新的速率,减少数据批量更新的耗时。
本申请实施例公开了如下技术方案:
第一方面,本申请提供一种离线数据批量更新方法,所述方法包括:
获取离线挖掘的原始数据,所述原始数据用于对在线检索模块目标位置的数据进行更新;
对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据;
当达到数据更新周期时,将所述目标数据更新到所述目标位置。
可选的,当达到数据更新周期时,将所述数据分片更新到所述目标位置之前,所述方法还包括:
将所述目标数据存储在分布式文件系统中。
可选的,若所述目标数据存储在分布式文件系统中,所述目标数据为数据分片。
可选的,对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据,包括:
基于MapReduce机制设置与所述目标位置分片一致的Map任务和Reduce任务;
通过所述Map任务和Reduce任务离线生成数据格式满足线上加载需求的数据分片。
可选的,当达到数据更新周期时,将所述数据分片更新到所述目标位置之前,所述方法还包括:
确定压缩参数,利用所述压缩参数对所述数据分配进行压缩;
所述将所述数据分片更新到所述目标位置,包括:
将所述数据分片和所述压缩参数更新到所述目标位置,以便在线检索系统利用所述压缩参数对压缩后的数据分片进行在线解压。
第二方面,本申请实施例提供一种离线数据批量更新装置,所述装置包括:
获取单元,用于获取离线挖掘的原始数据,所述原始数据用于对在线检索系统目标位置的数据进行更新;
处理单元,用于对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据;
更新单元,用于当达到数据更新周期时,将所述目标数据更新到所述目标位置。
可选的,所述装置还包括:
存储单元,用于将所述目标数据存储在分布式文件系统中。
可选的,若所述目标数据存储在分布式文件系统中,所述目标数据为数据分片。
可选的,所述处理单元,具体用于:
基于MapReduce机制设置与所述目标位置分片一致的Map任务和Reduce任务;
通过所述Map任务和Reduce任务离线生成数据格式满足线上加载需求的数据分片。
可选的,所述装置还包括:
压缩单元,用于确定压缩参数,利用所述压缩参数对所述数据分配进行压缩;
所述更新单元,具体用于:
将所述数据分片和所述压缩参数更新到所述目标位置,以便在线检索系统利用所述压缩参数对压缩后的数据分片进行在线解压。
第三方面,本申请实施例提供一种分布式存储系统,所述系统包括在线检索模块和批量更新模块:
所述在线检索模块,所述在线检索模块用于为业务方提供在线检索服务;
所述批量更新模块,获取离线挖掘的原始数据,所述原始数据用于对在线检索模块目标位置的数据进行更新;对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据;当达到数据更新周期时,将所述目标数据更新到所述目标位置。
由上述技术方案可以看出,本申请将检索与数据更新进行分离,通过离线的方式进行批量数据更新。具体的,获取离线挖掘的原始数据,该原始数据用于对在线检索模块目标位置的数据进行更新;然后,对原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据。当达到数据更新周期时,只需将数据格式满足线上加载需求的目标数据更新到目标位置。该方法将离线挖掘得来数据,通过离线的方式快速地生成数据格式满足线上加载需求的目标数据,这样,在达到数据更新周期需要对目标位置的数据进行批量更新时,只需将已经离线得到的满足线上加载需求的目标数据更新到分布式存储系统的存储节点上,无需进行其他处理,且由于离线更新与在线检索分离,避免在线检索对在线批量更新的影响,从而提高数据批量更新的速率,减少数据批量更新的耗时。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种分布式存储系统的结构图;
图2为本申请实施例提供的一种分布式存储系统的结构图;
图3为本申请实施例提供的一种离线数据批量更新方法的流程图;
图4为本申请实施例提供的一种利用MapReduce机制进行分片处理操作的流程图;
图5为传统更新流程与本申请提供的一种离线数据批量更新流程的对比图;
图6为本申请实施例提供的一种对数据分片进行压缩的压缩流程以及对应的在线检索流程;
图7为本申请实施例提供的一种离线数据批量更新装置的结构图。
具体实施方式
下面结合附图,对本申请的实施例进行描述。
利用风控模型进行风险控制可以基于图1所示的分布式存储系统,该系统通过上层分布式框架101+下层存储引擎102分层的架构设计。在该系统中包括Master、Zookeeper、代理(Proxy)、客户端(Client)、Operator、存储节点(Node)和存储引擎。Master负责系统的元数据查询,修改,维护Node节点的心跳等;Zookeeper负责Master选举,元数据维护;Proxy提供用户可见的Restful接口,解析请求并发查询Operator,合并查询结果;Client提供工具级的Eggroll管理功能,包括表的创建,删除,迁移,属性修改以及宕机情况下的人工介入命令;Operator接收proxy的请求,查询本地的存储节点Node,并调用算子处理查询结果,与本地Node捆绑布署;Node:维护本地元数据,调用接口操作存储引擎;存储引擎与上层分布式框架独立。
传统的分布式存储系统中,存储引擎为leveldb引擎,基于leveldb引擎将数据批量在线更新到分布式存储系统的存储节点上时,需要在线对数据进行一系列处理,且由于在线检索对在线批量更新的影响,使得数据批量更新的速率较慢,耗时过长。
为了解决上述技术问题,本申请实施例提供一种离线数据批量更新方法,该方法可以应用到分布式存储系统中。该分布式存储系统与传统的分布式存储系统有所不同,该系统在图1的基础上将该系统经线检索和离线批量更新进行分离,参见图2,该系统包括在线检索模块201和批量更新模块202。所述在线检索模块201,用于为业务方提供在线检索服务;所述批量更新模块202,用于获取离线挖掘的原始数据,所述原始数据用于对在线检索模块目标位置的数据进行更新;对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据;当达到数据更新周期时,将所述目标数据更新到所述目标位置。
如图2所示,本申请实施例提供的分布式存储系统中,在线检索模块201具体可以分为业务方2011、代理模块2012、集中控制模块2013、节点模块2014和存储引擎2015。批量更新模块202具体可以分为自动入库处理模块2021和分布式文件系统(HadoopDistributed File System,简称HDFS)2022。
与传统的分布式存储系统相比,传统的分布式存储系统将用于更新的数据写入到一个磁盘中,由于磁盘IO瓶颈,在通过leveldb引擎进行批量更新时会造成写放大问题,写放大会造成Leveldb L0层的文件数达到极限(默认是12个文件),而且Leveldb的层数默认配置7层,也就是说,对于一个长尾key的检索在此场景下是会存在19次磁盘输入输出(IO)读取,检索毛刺非常明显;另外Leveldb存储引擎由于后台合并会造成瞬时的写放大,对磁盘利用率低,而数据的暴涨会给存储资源造成很大的压力。
而本实施例提供的分布式存储系统中,批量更新模块202在进行批量更新时,将目标数据存储在HDFS 2022中,将目标数据分布式存储,从而避免由于磁盘IO瓶颈造成写放大问题,避免系统毛刺的产生。
另外,为了保证目标数据可以存储在HDFS 2022中,存储引擎2015中用于数据更新的存储引擎为Rainbowdb引擎,该Rainbowdb引擎利用了MapReduce机制,从而通过MapReduce机制实现将目标数据存储在HDFS 2022中。
基于图2提供的分布式存储系统中,本申请提供一种离线数据批量更新方法。参见图3,图3示出了一种离线数据批量更新方法的流程图,所述方法包括:
S301、获取离线挖掘的原始数据。
需要说明的是,业务方利用风控模型进行风险控制所采用的用户的特征数据一般包括用户申请时提交的基本数据(如年龄、性别、籍贯、收入状况等)、用户产生的行为数据(如资料的更改、选填资料的顺序、申请中使用的设备等)、用户在平台上累积的交易数据(如用户借款相关数据)、第三方数据(如来自政府、公用事业、银行等机构的数据,以及用户在电商、社交网络、网络新闻等互联网应用上留存的数据)。这些特征数据可能会发生改变,为了保证风控模型在进行迭代时可以利用准确的特征数据,需要对特征数据进行更新。故,需要获取离线挖掘的原始数据,原始数据用于对在线检索模块目标位置的数据进行更新。
S302、对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据。
需要说明的是,为了避免由于磁盘IO瓶颈造成写放大问题,进而避免系统毛刺的产生,在本实施中,用于更新的数据例如目标数据不再写入到单一磁盘,而是将目标数据存储到分布式文件系统(HDFS)中。
在本实施例中,为了保证目标数据可以存储到HDFS中,目标数据可以是通过对原始数据进行分片处理得到的数据分片。一般情况下,对原始数据进行分片处理的方式可以包括很多种,在一种可能的实现方式中,可以利用Rainbowdb引擎的MapReduce机制对原始数据进行分片处理。具体的,基于MapReduce机制设置与所述目标位置分片一致的Map任务和Reduce任务,通过所述Map任务和Reduce任务离线生成数据格式满足线上加载需求的数据分片。
利用MapReduce机制进行分片处理的操作流程参见图4所示。针对全量的原始数据创建MAP任务,MAP任务如图4中401所示。MAP任务内通过与线上相同的murmurhash-key生成各个murmurhash-key的hash-key,并且计算好各hash-key路由的数据分片id。然后根据生成的数据分片id将对应的hash-key按大小进行排序,从而得到反映分片数大小的Reduce任务的输入参数。
Reduce任务如图4中402所示,Reduce任务是生成各个独立的分片文件Part-xxx,而Part-00xxx文件格式是按照block块存储的,分片文件Part-xxx的存储结构是block块+block的index+index的偏移的方式。分片文件Part-xxx如图4中403所示。
而Block块内部的存储格式又是按slice内容+slice的index+index的偏移组成;Block块的大小支持可配置,目前根据业务需求,Block块的大小选取4k和1M可配。之所以有slice结构是因为考虑murmurhash-key会有冲突,那么hashkey冲突的key-value则存储在slice结构当中。Block块存储格式如图4中404所示。
Slice结构中存储的是由于hash-key冲突产生的key和value,存储格式是按value+key及value偏移+index偏移的方式存储。Slice内部存储格式如图4中405所示。
本实施例结合MapReduce的机制是可以通过定制与线上分片一致的Map任务以及Reduce任务来离线快速生成线上需要加载的数据格式,然后通过存储节点去加载要更新的数据到线上的方式达到快速批量更新需求。
S303、当达到数据更新周期时,将所述目标数据更新到所述目标位置。
在线检索是实时需求而数据批量更新不是实时的,数据批量更新是按照一定的数据更新周期进行的。本实施例通过在线下对原始数据进行一系列数据处理,离线生成数据格式满足线上加载需求的目标数据。这样,当达到数据更新周期时,只需直接将数据格式满足线上加载需求的目标数据更新到所述目标位置,例如,直接将数据格式满足线上加载需求的目标数据复制到所述目标位置以对目标位置原有数据进行更新,提高数据批量更新的速率。
由于完成数据批量更新,因此,在线检索时便可以检索到更新后的数据,使得进行风险控制所依赖的数据更加准确、可靠。
可以理解的是,在利用MapReduce机制进行分片处理,通过Map任务和Reduce任务离线生成数据格式满足线上加载需求的数据分片的情况下,在线检索流程可以参见图4所示。具体的,首先proxy根据用户传过来的key进行murmurhash确定指定的数据分片,根据数据分片的id定位到对应的分片文件part-xxx。
然后通过加载到系统内存的各分片文件的index部分去查询该murmurhash生成的hash-key在哪个Block,查询的方式由于文件内部全局有序所以可进行二分查找。
在通过加载到内存的索引定位到对应的Block块之后,将进行一次IO读取,把对应的Block块内容加载到内存中,仍然通过二分精确查找可定位到某一个Slice结构。
定位到Slice结构之后按顺序遍历所有冲突的key精确查找到要检索的key从而取到对应的value返回用户,完成在线检索。
整个离线批量更新与在线检索都是严格按读写分离流程进行操作,这样可保证离线批量更新过程中没有在线流量在进行检索,避免由于批量更新操作给在线检索造成磁盘IO瓶颈,从而避免了系统毛刺的产生。
参见图5,图5示出了传统更新流程与本申请提供的一种离线数据批量更新流程的对比图。从图中可以看出,传统的更新方法与检索都是在线进行的,数据批量更新到leveldb引擎;而本申请实施例提供的更新方法是离线的,与在线检索分离,通过MapReduce机制对原始数据进行分片处理,离线生成数据格式满足线上加载需求的数据分片,将数据分片存储在HDFS中,当达到数据更新周期时,将需要更新的数据分片更新到Rainbowdb的目标位置。
由上述技术方案可以看出,本申请将检索与数据更新进行分离,通过离线的方式进行批量数据更新。具体的,获取离线挖掘的原始数据,该原始数据用于对在线检索模块目标位置的数据进行更新;然后,对原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据。当达到数据更新周期时,只需将数据格式满足线上加载需求的目标数据更新到目标位置。该方法将离线挖掘得来数据,通过离线的方式快速地生成数据格式满足线上加载需求的目标数据,这样,在达到数据更新周期需要对目标位置的数据进行批量更新时,只需将已经离线得到的满足线上加载需求的目标数据更新到分布式存储系统的存储节点上,无需进行其他处理,且由于离线更新与在线检索分离,避免在线检索对在线批量更新的影响,从而提高数据批量更新的速率,减少数据批量更新的耗时。
需要说明的是,目前风控模型非常多且仍在增加,各模型涉及的特征维度也在不断增加,后续挖掘的特征数据量也呈爆炸式增长,出于存储成本的考虑,我们针对上述Rainbowdb引擎设计了相应的压缩方案,从而提高存储资源利用率和更新效率。
因此,在一种可能的实现方式中,在执行S303之前,所述方法还包括:确定压缩参数,利用所述压缩参数对所述数据分配进行压缩;相应的,S303的一种可能实现方式为:将所述数据分片和所述压缩参数更新到所述目标位置,以便在线检索系统利用所述压缩参数对压缩后的数据分片进行在线解压。
可以理解的是,由于压缩方案包括很多种,不同的压缩方案对应的压缩参数有所不同(压缩参数例如压缩算法、Block大小)。故,本实施例中可以首先确定压缩参数,以便利用该压缩参数对数据分配进行压缩。
在选择压缩参数时,可以从算法压缩率、算法解压速度、压缩block大小评估、用户对耗时的敏感度、压缩算法语言的支持5个维度进行筛选。由于数据分配是利用MapReduce机制生成的,因此需要压缩算法支持JAVA,另外根据各压缩算法的解压效率评估snappy、gzip、zstd的解压效率1MB的速度都是维持在几ms之内,再结合用户对耗时的敏感度进行综合确定。一般情况下,可以选择snappy、gzip等压缩算法。另外,Block块的大小根据用户需求提供4K和1M两种选择。在一种可能的实现方式中,压缩参数默认是snappy-4k。
参见图6,图6示出了对数据分片进行压缩的压缩流程以及对应的在线检索流程。
S601、获取业务方输入参数。
S602、根据输入参数确定压缩参数。
S603、利用MapReduce机制进行分片处理,离线生成数据格式满足线上加载需求的数据分片。
S604、利用压缩参数对数据分配进行压缩得到压缩后的数据分片。
S605、更新入库指令到分布式存储系统的master。
S606、分布式存储系统中的node维护最新表对应的压缩参数。
S607、业务在线读取。
S608、node根据压缩参数在线进行解压检索。
基于前述实施例提供的离线数据批量更新方法,本申请实施例提供一种离线数据批量更新装置,参见图7,图7示出了一种离线数据批量更新装置的结构图,所述装置包括:
获取单元701,用于获取离线挖掘的原始数据,所述原始数据用于对在线检索系统目标位置的数据进行更新;
处理单元702,用于对所述原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据;
更新单元703,用于当达到数据更新周期时,将所述目标数据更新到所述目标位置。
可选的,所述装置还包括:
存储单元,用于将所述目标数据存储在分布式文件系统中。
可选的,若所述目标数据存储在分布式文件系统中,所述目标数据为数据分片。
可选的,所述处理单元,具体用于:
基于MapReduce机制设置与所述目标位置分片一致的Map任务和Reduce任务;
通过所述Map任务和Reduce任务离线生成数据格式满足线上加载需求的数据分片。
可选的,所述装置还包括:
压缩单元,用于确定压缩参数,利用所述压缩参数对所述数据分配进行压缩;
所述更新单元,具体用于:
将所述数据分片和所述压缩参数更新到所述目标位置,以便在线检索系统利用所述压缩参数对压缩后的数据分片进行在线解压。
由上述技术方案可以看出,本申请将检索与数据更新进行分离,通过离线的方式进行批量数据更新。具体的,获取离线挖掘的原始数据,该原始数据用于对在线检索模块目标位置的数据进行更新;然后,对原始数据进行数据处理,离线生成数据格式满足线上加载需求的目标数据。当达到数据更新周期时,只需将数据格式满足线上加载需求的目标数据更新到目标位置。该方法将离线挖掘得来数据,通过离线的方式快速地生成数据格式满足线上加载需求的目标数据,这样,在达到数据更新周期需要对目标位置的数据进行批量更新时,只需将已经离线得到的满足线上加载需求的目标数据更新到分布式存储系统的存储节点上,无需进行其他处理,且由于离线更新与在线检索分离,避免在线检索对在线批量更新的影响,从而提高数据批量更新的速率,减少数据批量更新的耗时。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质可以是下述介质中的至少一种:只读存储器(英文:read-only memory,缩写:ROM)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于设备及系统实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述,仅为本申请的一种具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应该以权利要求的保护范围为准。