一种图数据更新方法、装置及系统
技术领域
本申请涉及计算机技术领域,尤其涉及一种图数据更新方法、装置及系统。
背景技术
随着互联网大数据技术的迅速发展,人们越来越重视数据之间的关联。
目前,一般采用图数据对相互之间有关联的多个数据(可以是关系网络中的各个节点相关的数据)进行表示和存储,以便于用户进行查询或是进一步地作数据挖掘等操作。具体的,当采用连通子图这种结构的图数据时,可以将特定介质所具有的属性数据作为连通子图中的节点数据,将反映属性数据之间关联的关联数据作为对应于节点数据的边数据。例如,所述特定介质可以是用户的邮箱、银行卡、手机等,相应的,所述属性数据可以是邮箱地址、银行卡号、手机号等,所述关联数据可以是用于记录邮箱地址、银行卡号、手机号之间绑定关系的数据、不同的银行卡号之间的转账次数、不同的手机号之间的通话次数,等等。
进一步的,由于上述数据随着新增的业务数据的生成,可能会发生变化,因此,需要相应地对已有图数据(已有图数据,也即,已经生成并存储的图数据)进行更新。其中,每一条业务数据可以是用于记录两个节点之间进行的一次业务交互的交互过程和/或交互结果的数据,每一条业务数据还包含有时间戳,该时间戳用于记录该业务交互的发生时间,或者该业务数据的生成时间。例如,某条业务数据可以表示为:“2014年1月1日,12:00,手机号A向手机号B成功发起了一次通话,通话持续时间为1分钟”,需要说明的是,在实际应用中,上例中的业务数据也可以用指定的数据结构进行表示。
在现有技术中,每次更新时会获取全部的业务数据,然后根据全部的业务数据重新计算一次图数据,再用重新计算出的图数据对已有图数据进行同步更新,这种图数据更新方法耗费资源多,效率低,而且实时性很差。
发明内容
本申请实施例提供一种图数据更新方法,用以解决现有技术中采用的图数据更新方法耗费资源多,效率低,而且实时性很差的问题。
本申请实施例提供一种图数据更新装置,用以解决现有技术中采用的图数据更新方法耗费资源多,效率低,而且实时性很差的问题。
本申请实施例提供一种图数据更新系统,用以解决现有技术中采用的图数据更新方法耗费资源多,效率低,而且实时性很差的问题。
本申请实施例提供的一种图数据更新方法,包括:
获取新增的业务数据,并提取所述新增的业务数据中的节点数据;
根据已有图数据和提取出的节点数据,生成合并决策结果,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的;
根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新。
本申请实施例提供的一种图数据更新装置,包括:
获取模块,用于获取新增的业务数据,并提取所述新增的业务数据中的节点数据;
合并决策模块,用于根据已有图数据和提取出的数据,生成合并决策结果,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的;
更新模块,用于根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新。
本申请实施例提供的一种图数据更新系统,包括:合并决策模块、合并模块、控制模块;
所述合并决策模块用于,获取新增的业务数据,并提取所述新增的业务数据中的节点数据,根据已有图数据和提取出的节点数据,生成合并决策结果,并将获取的新增的业务数据和生成的合并决策结果输出至所述合并模块,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的;
所述合并模块用于,根据接收到的所述合并决策模块输出的合并决策结果和所述新增的业务数据,对所述已有图数据进行更新;
所述控制模块用于,用于管理对所述新增的业务数据的处理状态,以及控制对所述新增的业务数据的处理流程。
本申请实施例通过上述至少一种技术方案,可以根据在一定时间段内新增的业务数据对已有图数据增量地更新,而不需要根据全部的新增的业务数据重新生成图数据,因此,本申请实施例提供的图数据更新方法资源耗费低,效率和实时性高。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为在现有技术中,一种基于图数据的业务平台;
图2为本申请实施例提供的图数据更新过程;
图3为在实际应用中的一个连通子图;
图4为本申请实施例提供的生成第一决策结果的过程;
图5为本申请实施例提供的,实际应用中的一种已有图数据;
图6为本申请实施例提供的,实际应用中的一种根据新增的业务数据中提取出的节点数据生成的连通子图;
图7为本申请实施例提供的,实际应用中的一种对多个连通子图进行合并后可以生成的合并目标连通子图;
图8为本申请实施例提供的,实际应用中的生成合并决策结果时所采用的设置Giraph边输入格式算法;
图9为本申请实施例提供的,实际应用中的生成合并决策结果时所采用的设置Giraph顶点计算算法;
图10为本申请实施例提供的图数据更新装置结构示意图;
图11为本申请实施例提供的图数据更新系统示意图;
图12为本申请实施例提供的图数据更新系统包含的模块和单元示意图;
图13为将本申请实施例提供的图数据更新系统应用于图1中的业务平台中的示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
随着互联网大数据技术的发展,人们越来越重视对海量的业务数据的存储以及挖掘这些业务数据之间的关联。由于单台服务器已经无法满足海量的业务数据的存储需求,因此,在现有技术中一般基于分布式存储方式,将业务数据分布存储在多台服务器上,而且,为了反映业务数据之间的关联,还可以将业务数据组织为图数据的形式进行存储、使用和更新。但是,现有的图数据更新方法存在问题,为了便于理解,下面以实际应用中的业务平台为例对该问题进行说明。
图1示出了在现有技术中,一种基于图数据的业务平台。该平台主要分为生产环境和离线环境两部分,生产环境用于处理业务和生成业务数据(用成条的业务数据进行表示),离线环境用于根据生产环境生成的业务数据生成相应的图数据,并同步更新至生产环境。
具体的,生产业务系统接收和处理业务请求,并根据业务请求数据生成业务数据。可以定时地(如每天一次)将生产环境中新增的业务数据同步到离线环境并保存为历史业务数据。
离线计算中心可以定时地根据全部的历史业务数据,计算生成相应的图数据并保存在离线环境的图数据存储系统中,进一步的,可以将保存的图数据从离线环境同步更新到生产环境中,以便于生产业务系统在处理业务时可以根据业务需求从生产环境的图数据存储系统中获取和使用图数据。
但是,在上述图数据更新过程中,离线计算中心每次都要根据全部的历史业务数据重新计算图数据,资源耗费大,效率低,而且,由于生产环境和离线环境之间一般会间隔较长时间才同步更新一次业务数据和图数据,因此,生产业务系统所获取到的图数据实时性较差,进而可能会影响业务处理的可靠性。
本申请提供的图数据更新方法及系统可以解决该问题,下面进行详细阐述。
图2为本申请实施例提供的图数据更新过程,具体包括以下步骤:
S201:获取新增的业务数据,并提取所述新增的业务数据中的节点数据。
本申请实施例提供的图数据更新方法的执行主体可以是:单台服务器、分布式的多台服务器或终端。所述服务器包括但不限于:个人计算机、大中型计算机、计算机集群等;所述终端包括但不限于:手机、平板电脑、智能手表、车载移动台、个人计算机等。所述的执行主体并不构成对本申请的限定。
在本申请实施例中,为了提高图数据更新的效率,在每次更新时,可以不根据全部的历史业务数据重新生成图数据,而是可以只根据新增的业务数据,在已有图数据的基础上进行更新即可,其中,所述已有图数据可以是根据新增的业务数据之前的历史业务数据生成的图数据。
在本申请实施例中,每一条新增的业务数据中的各节点数据是相互关联的,所述已有图数据也包含有节点数据,已有图数据包含的节点数据与从新增的业务数据中提取的节点数据可能相同,也可能不同。在后续过程中,可以基于所述各节点数据对已有图数据进行更新。
其中,本申请中所述的节点数据可以是用于描述关系网络(以图数据的形式表示)中的节点的相关信息的数据。
S202:根据已有图数据和提取出的节点数据,生成合并决策结果,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的。
在本申请实施例中,可以根据每一条新增的业务数据,分别对已有图数据进行一次更新,这种更新方法实时性更高;也可以每次根据多个新增的业务数据,对已有图数据进行一次更新,这种更新方法资源耗费更少,且效率更高。
当采用前一种更新方法时,由于计算量较小,因此,也可以不生成合并决策结果,而是直接根据已有图数据和当前选定的一条新增的业务数据,对已有图数据进行更新。
S203:根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新。
在实际应用中,一般采用分布式的多台服务器处理业务,则该多台服务器可能并发地生成大量新增的业务数据,在这种情况下,步骤S202中阐述的后一种更新方法更加适用,进一步的,为了提高这些服务器所获取的图数据的可靠性,可以先根据已有图数据和当前选定的多条新增的业务数据生成合并决策结果,再根据合并决策结果和当前选定的多条新增的业务数据,对图数据进行更新,这样可以有效地减少数据操作冲突。其中,所述更新过程主要包括两部分:一是将所述新增的业务数据写入图数据;二是对写入了新增的业务数据后的图数据的拓扑结构(如图数据包含的各连通子图等)进行相应的更新(如在图数据中新增连通、合并连通子图等)。
通过上述方法,由于可以根据在一定时间段内新增的业务数据对已有图数据增量地更新,而不需要根据全部的新增的业务数据重新生成图数据,因此,本申请实施例提供的图数据更新方法资源耗费低,效率和实时性高。
在本申请实施例中,可以用业务数据标识(Identity,ID)对每条业务数据进行标识,一般的,业务数据中还可以包含时间戳,该时间戳记录了该业务数据的生成时间,因此,可以通过比较时间戳的方法确定新增的业务数据。具体的,所述新增的业务数据具体包括包含的时间戳晚于系统时间戳的业务数据,其中,所述系统时间戳是在用于生成所述已有图数据的各历史业务数据中,最新的一条历史业务数据包含的时间戳。当然,除了时间戳之外,也可以根据各业务数据的业务逻辑顺序等依据确定新增的业务数据。
在本申请实施例中,可以采用连通子图这种数据结构表示图数据。具体的,可以将特定介质所具有的属性数据作为连通子图中的节点数据,将反映属性数据之间关联的关联数据作为对应于节点数据的边数据,连通子图中的任意两个节点数据。例如,所述特定介质可以是用户的邮箱、银行卡、手机等,相应的,所述属性数据可以是邮箱地址、银行卡号、手机号等,所述关联数据可以是记录邮箱地址、银行卡号、手机号之间绑定关系的数据、不同的银行卡号之间的转账次数、不同的手机号之间的通话次数,等等。
例如,图3示出了实际应用中的一个连通子图,该连通子图中包含有多个节点数据(USERID-1、CC-1、Email-1、DFPrint-1、UMID-1、收货地址-1,等等),以及多个边数据(图中用节点数据之间的连线表示),。在实际应用场景下,边数据可以表示各种含义。如,节点数据“USERID-2”和“收货地址-1”之间的边数据可以表示USERID-2所标识的用户向收货地址-1发送快递的次数,又例如,节点数据“USERID-1”和“Email-1”之间的边数据可以表示USERID-1所标识的用户与邮箱地址Email-1进行绑定后生成的关联数据,等等。
为了便于对连通子图进行处理,可以用连通子图标识(Identity,ID)对各连通子图进行标识。因此,根据上述说明,所述已有图数据具体包括至少一个连通子图,所述连通子图具体包括连通子图标识和至少一个节点数据。
进一步的,根据获取新增的业务数据的不同,在上述步骤S203的更新过程中,已有图数据中包含各连通子图可能发生两类改变,第一类是已有图数据中包含各连通子图本身的拓扑结构改变,第二类是有新的连通子图加入已有图数据中,且加入的新的连通子图不与已有图数据中包含各连通子图连通。这两类改变可能同时存在,也可能只存在一种。相应的,在上述步骤S102中,生成的合并决策结果具体可以包含第一决策结果和/第二决策结果,第一决策结果与上述第一类改变对应,第二决策结果与上述第二类改变对应。下面分别对第一决策结果和第二决策结果的生成进行说明。
图4示出了在上述步骤S202中,根据已有图数据和所述新增的业务数据,生成合并决策结果(此处的合并决策结果指第一决策结果)的过程,具体包括以下步骤:
S401:在所述已有图数据包含的连通子图中,确定与提取出的节点数据对应的连通子图。
仍以图3为例,对所述提取出的节点数据进行说明。
假定某条新增的业务数据表示:USERID-2所标识的用户向收货地址-1请求发送一次快递。这样的话,从该新增的业务数据可以提取出的节点数据即为“USERID-2”和“收货地址-1”。
进一步的,从新增的业务数据提取出的节点数据也可能是新增的节点数据,例如,某条新增的业务数据可以表示:USERID-2所标识的用户向收货地址-3请求发送一次快递。这样的话,从该新增的业务数据可以提取出的节点数据即为“USERID-2”和“收货地址-3”。显然,节点数据“收货地址-3”是新增的,并不包含在图3中的连通子图(为已有图数据)内,则后续对图3中的连通子图进行更新时,该节点数据“收货地址-3”会使图3中的连通子图的拓扑结构改变。
另外,需要说明的是,本申请对所述业务数据的具体格式并不做限定。
在本申请实施例中,在后续的图数据更新过程中,所述与提取出的节点数据对应的连通子图的拓扑结构可能改变。
S402:根据提取出的节点数据和所述已有图数据包含的节点数据在业务数据中的关联,生成所述第一决策结果,其中,所述第一决策结果用于对提取出的节点数据对应的各连通子图进行合并。
在本申请实施例中,与提取出的节点数据对应的连通子图,既可以是提取出的节点数据直接所属的连通子图,也可以是可与提取出的节点数据连通的连通子图。相应的,在上例中,节点数据“USERID-2”直接属于图3中的连通子图,而节点数据“收货地址-3”虽然不是直接属于图3中的连通子图,但它可通过节点数据“USERID-2”与图3中的连通子图连通,因此,图3中的连通子图既与节点数据“USERID-2”对应,也与节点数据“收货地址-3”对应。
对于上述步骤S402,根据提取出的节点数据和所述已有图数据包含的节点数据在业务数据中的关联,生成所述第一决策结果,具体包括:根据提取出的节点数据和所述已有图数据包含的节点数据在业务数据中的关联,确定在与提取出的节点数据对应的各连通子图中待合并的连通子图包含的连通子图标识、合并目标连通子图标识、在所述新增的业务数据中与所述待合并的连通子图对应的业务数据包含的业务数据标识,作为生成的所述第一决策结果。
需要说明的是,合并目标连通子图标识可以是从各待合并的连通子图包含的连通子图标识中,选定出的连通子图标识,也可以是不同于各待合并的连通子图包含的连通子图标识的其他尚未使用的连通子图标识。这样的话,可以防止正在使用的各连通子图重复。
例如,假定已有图数据中包含有3个连通子图,分别为连通子图1(包含的连通子图标识为ID1)、连通子图2(包含的连通子图标识为ID2)、连通子图3(包含的连通子图标识为ID3),且根据新增的业务数据(包含的业务数据标识为id1),需要将连通子图2和连通子图3进行合并。则生成的合并决策结果具体可以是:待合并的连通子图包含的连通子图标识(ID2、ID3),合并目标连通子图标识(IDX)、在所述新增的业务数据中与所述待合并的连通子图对应的业务数据包含的业务数据标识(id1)。
其中,所述合并目标连通子图标识IDX用于,对将连通子图2和连通子图3合并后生成的连通子图进行标识,进一步的,IDX可以是ID2或ID3,也可以是不同于ID1、ID2、ID3的其他尚未使用的连通子图标识,如ID4等。
进一步的,对于上述步骤S401,还可能存在这样的情况:在提取出的节点数据中,存在不与已有图数据包含的连通子图对应的节点数据。所述第二决策结果即是为了后续可以将这部分节点数据更新至已有图数据中而生成的,下面说明第二决策结果的生成过程。
对于上述步骤S202,根据已有图数据和所述新增的业务数据,生成合并决策结果(此处的合并决策结果指第二决策结果),具体包括:当确定在提取出的节点数据中,存在不与所述各连通子图对应的节点数据时,根据各不与所述各连通子图对应的节点数据在业务数据中的关联,生成对应的连通子图,作为所述第二决策结果。后续更新时,可以将所述生成对应的连通子图并加入已有图数据中。从而保证更新后的图数据的完整性。
仍以图3为例进行说明,假定某条新增的业务数据表示:USERID-4所标识的用户向收货地址-4请求发送一次快递。这样的话,从该新增的业务数据可以提取出的节点数据即为“USERID-4”和“收货地址-4”。显然,节点数据“USERID-4”和“收货地址-4”均为新增的节点数据,而且不与图3中的连通子图对应,这样的话,可以根据节点数据“USERID-4”和“收货地址-4”在该业务数据中的关联,再生成一个连通子图,生成的该连通子图包含两个节点数据(即为“USERID-4”和“收货地址-4”),且这两个节点数据相互连通。后续更新时,可以将生成的该连通子图加入图3中的连通子图中。
在本申请实施例中,对于上述步骤S203,根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新,具体包括:根据所述新增的业务数据,对所述已有图数据中包含的节点数据,以及所述节点数据之间的关联数据进行更新,根据所述第一决策结果和/或所述第二决策结果,对更新了所述节点数据和所述关联数据后的已有图数据进行更新。
进一步的,根据所述第一决策结果,对更新了所述节点数据和所述关联数据后的已有图数据进行更新,具体包括:根据所述待合并的连通子图包含的连通子图标识,对所述待合并的连通子图进行合并计算,生成包含所述合并目标连通子图标识的合并目标连通子图;将所述合并目标连通子图,以及在更新了所述节点数据和所述关联数据后的已有图数据中,除了所述待合并的连通子图之外的其他连通子图作为更新后的已有图数据;
根据所述第二决策结果,对更新了所述节点数据和所述关联数据后的已有图数据进行更新,具体包括:将所述第二决策结果加入更新了所述节点数据和所述关联数据后的已有图数据中。
对于上述的生成合并决策结果,以及根据合并决策结果和新增的业务数据,对已有图数据进行更新这两大步骤,每一个步骤内的各种计算过程都可以在分布式的多台服务器上并行执行,从而,可以提高图数据更新的效率和实时性。
在实际应用中,可以采用基于Hadoop的开源图形处理平台Giraph实现上述步骤S202中,生成合并决策结果的具体过程。下面进行说明。
首先,对在生成合并决策结果的过程中,常用的存储已有图数据、业务数据、合并决策结果的方法进行说明。
对于已有图数据,可以将其用Hadoop数据库(Hadoop Database,HBase)表进行存储,假定将已有图数据存储在图节点表、连通子图表和连接子图信息表这三张HBase表中。其中,图节点表中可以存储已有图数据包含的节点数据,连通子图表中可以存储已有图数据包含的连通子图的主要信息,如连接子图ID等,连接子图信息表中可以存储已有图数据包含的连通子图的附属信息,连接子图中包含的节点数据的个数等。
假定节点数据包括两个属性:节点类型和节点值。对于某节点数据,当节点类型的取值为“1”时,表示节点值是一个手机号码(假定为“18000001234”)。则可以基于节点类型的取值和节点值,生成图节点表中的行键(row key),例如,生成的row key可以是将节点类型的取值和节点值进行拼接后得到的字符串,如将“1”和“18000001234”拼接后表示为“1#18000001234”,或者“18000001234#1”,等等,则拼接后表示出的字符串即为该节点数据在图节点表中的row key。
类似的,对于业务数据,也可以将其用HBase表进行存储,称为业务数据表。则业务数据表的row key可以是业务数据ID。
类似的,对于合并决策结果,也可以将其用HBase表进行存储。如图5所述,假定已有图数据包含了3个连通子图:连通子图1、连通子图2、连通子图3。其中,连通子图1包含节点数据1、节点数据2、节点数据3,连通子图2包含节点数据4、节点数据5、节点数据6,连通子图3包含节点数据7、节点数据8、节点数据9、节点数据10。
假定从新增的业务数据(称为业务数据1)中提取出的节点数据可以用图6中的连通子图进行表示。该连通子图包含节点数据1、节点数据6、节点数据8。显然,由于节点数据1、节点数据6、节点数据8分别属于连通子图1、连通子图2、连通子图3,因此,可以该连通子图和连通子图1、连通子图2、连通子图3合并为一个合并目标连通子图。
进一步的,将多条新增的业务数据合并更新至已有图数据中时,可以分布式地计算合并决策结果,继续用上例进行说明,除了业务数据1之外,假定还有业务数据2、业务数据2也是新增的业务数据。其中,业务数据1导致可以将连通子图1、连通子图2、连通子图3进行合并,假定业务数据2导致可以将连通子图1、连通子图4进行合并,假定业务数据3导致可以将连通子图3、连通子图8进行合并。合并后可以生成的合并目标连通子图如图7所示,可以看到,连通子图1、连通子图2和连通子图3相互之间直接连通,且连通子图1还与连通子图4直接连通,连通子图3还与连通子图8直接连通。
继续沿用上例进行说明,上例中生成的合并决策结果可以存储在以下形式的HBase表中,如下表1所示:
表1
其中,表1的row key列用于存储合并目标连通子图标识(此处选取了在待合并的连通子图包含的连通子图标识,最小的连通子图标识:ID1),列簇的动态列(column),也即,f family,用于存储各待合并的连通子图包含的连通子图标识。另外,由于在后合并计算时,还可以将业务数据1、业务数据2、业务数据3中除了节点数据的其它数据合并更新到已生成图数据中,因此,在表1中还可以保存这些业务数据的ID以便于检索这些业务数据,或者,也可以直接保存这些业务数据。
基于以上的存储方法,在生成合并决策结果的过程中,可以对Giraph参数进行设置,所述设置包括但不限于:
设置输入的数据表,可以是记录业务数据的HBase表;
设置输入数据的HBase浏览(Scan)操作的起始时间戳,可以是所述的系统时间戳;
设置输入数据的HBase Scan操作的截止时间戳,可以是当前最新的一条业务数据包含的时间戳;
设置输出表,可以是记录合并决策结果的HBase表。
进一步的,对Giraph顶点ID对象、Giraph顶点值对象、Giraph顶点的边的值、Giraph消息进行定义:所述Giraph顶点ID定义为文本(Text)类型,用于存储连通子图ID;所述Giraph顶点值定义为Text类型,用于存储待合并的连通子图包含的连通子图ID;所述Giraph顶点的边的值定义为Text类型,用于存储业务数据ID;所述Giraph消息的类型包括待合并目标(也即连通子图)和消息创建者ID的数据类型。
图8示出了在实现生成合并决策结果这一步骤中所采用的设置Giraph边输入格式算法,具体包括以下步骤:
S801:判断新增的业务数据是否已经处理完毕,若是,结束整个算法流程,否则,执行步骤S802。
S802:获取下一条尚未处理的业务数据。
S803:从获取的该业务数据中提取节点数据。
S804:确定提取出的节点数据对应的连通子图ID,当提取出的节点数据均无对应的连通子图ID时,为提取出的节点数据创建新的连通子图ID。
S805:根据业务数据中的预设规则,将确定出的各连通子图ID组合为边形式列表,其中,出现在同一个边中的连通子图ID表示:这些连通子图ID对应的连通子图需要合并。
S806:将组合出的边形式列表转换为Giraph所支持的边列表,并将业务数据ID作为边属性,存储在其中一个出边的值,所述边列表提供给Giraph读入。返回执行S801。
图9示出了在实现生成合并决策结果这一步骤中所采用的设置Giraph顶点计算算法,具体包括以下步骤:
S901:判断SuperStep参数是否等于0,若是,则执行步骤S902,否则,执行步骤S907。
S902:遍历所有的出边的顶点ID,计算出字典序最小的顶点ID。
S903:通过将该最小的顶点ID和当前顶点ID比较,确定出最终的最小顶点ID。
S904:将最终的最小顶点ID作为顶点值。
S905:遍历所有的出边,若出边的顶点ID不为当前顶点,则发送消息。其中,消息的合并目标为该顶点值,消息的创建者ID为当前顶点的ID。
S906:挂起当前顶点。结束整个算法流程。
S907:遍历所有接收到的消息,从所有消息中计算出字典序最小的合并目标。
S908:判断该字典序最小的合并目标的字典序是否小于当前顶点值,若是,则执行步骤S909,否则,执行步骤S906。
S909:修改当前定点值为字典序最小的合并目标。执行步骤S905。
在实现生成合并决策结果这一步骤中所采用的设置Giraph顶点输出格式算法具体包括:
根据顶点值,构建HBase的Put对象,则Giraph框架会将该Put对象通过HBase客户端输出到HBase表中。将顶点值作为Put的row key,顶点ID作为Put的Column,顶点的所有出边值里保存的业务数据的ID按照一定格式进行格式化后作为Put的value。
以上对采用基于Hadoop的开源图形处理平台Giraph实现生成合并决策结果的具体过程进行的说明,进一步的,还可以Giraph或Hadoop MapReduce等并行计算框架实现上述步骤S203,也即,根据所述合并决策结果,将所述新增的业务数据合并更新至所述已有图数据中。
例如,当使用Hadoop MapReduce时,可以将生成的合并决策结果作为MapReduce的输入。在map阶段,一次map计算会传入一个HBase Result对象,一个HBase Result对象存储的可以是合并决策结果中的一行数据(待合并的一组连通子图)。在进行合并计算时,可以对HBase Result对象进行解析,然后读取对应的业务数据和已有图数据,以及进行合并。
以上为本申请实施例提供的图数据更新方法,基于同样的思路,本申请实施例还提供相应的图数据更新装置,如图10所示。
图10为本申请实施例提供的图数据更新装置结构示意图,具体包括:
获取模块1001,用于获取新增的业务数据,并提取所述新增的业务数据中的节点数据;
合并决策模块1002,用于根据已有图数据和提取出的节点数据,生成合并决策结果,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的;
更新模块1003,用于根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新。
所述新增的业务数据具体包括包含的时间戳晚于系统时间戳的业务数据,其中,所述系统时间戳是在用于生成所述已有图数据的各历史业务数据中,最新的一条历史业务数据包含的时间戳。
所述合并决策结果包括第一决策结果,所述已有图数据具体包括至少一个连通子图,所述连通子图具体包括连通子图标识和至少一个节点数据;则
所述合并决策模块1002具体用于,在所述已有图数据包含的连通子图中,确定与提取出的节点数据对应的连通子图,根据提取出的各节点数据和所述已有图数据包含的节点数据在业务数据中的关联,生成所述第一决策结果,其中,所述第一决策结果用于对与提取出的节点数据对应的各连通子图进行合并。
所述合并决策结果还包括第二决策结果,则所述合并决策模块1002还用于,当确定在提取出的节点数据中,存在不与所述各连通子图对应的节点数据时,根据各不与所述各连通子图对应的节点数据在业务数据中的关联,生成对应的连通子图,作为所述第二决策结果。
所述合并决策模块1002具体用于,根据提取出的节点数据和所述已有图数据包含的节点数据在业务数据中的关联,确定在与提取出的节点数据对应的各连通子图中待合并的连通子图包含的连通子图标识、合并目标连通子图标识、在所述新增的业务数据中与所述待合并的连通子图对应的业务数据包含的业务数据标识,作为生成的所述第一决策结果。
所述更新模块1003具体用于,根据所述新增的业务数据,对所述已有图数据中包含的节点数据,以及所述节点数据之间的关联数据进行更新,根据所述第一决策结果和/或所述第二决策结果,对更新了所述节点数据和所述关联数据后的已有图数据进行更新。
所述更新模块1003包括第一更新子模块10031和第二更新子模块10032;
所述第一更新子模块10031用于,根据所述待合并的连通子图包含的连通子图标识,对所述待合并的连通子图进行合并计算,生成包含所述合并目标连通子图标识的合并目标连通子图,将所述合并目标连通子图,以及在更新了所述节点数据和所述关联数据后的已有图数据中,除了所述待合并的连通子图之外的其他连通子图作为更新后的已有图数据;
所述第二更新子模块10032用于,将所述第二决策结果加入更新了所述节点数据和所述关联数据后的已有图数据中。
具体的上述如图10所示的装置可以位于服务器、终端上。
本申请实施例还提供一种图数据更新系统,如图11所示。
图11为本申请实施例提供的图数据更新系统示意图,包括:合并决策模块1101、合并模块1102、控制模块1103;
所述合并决策模块1101用于,获取新增的业务数据,并提取所述新增的业务数据中的节点数据,并根据已有图数据和提取出的节点数据,生成合并决策结果,并将获取的新增的业务数据和生成的合并决策结果输出至所述合并模块1102,其中,所述合并决策结果用于将提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的;
所述合并模块1102用于,根据接收到的所述合并决策模块1101输出的合并决策结果和所述新增的业务数据,对所述已有图数据进行更新;
所述控制模块1103用于,用于管理对所述新增的业务数据的处理状态,以及控制对所述新增的业务数据的处理流程。
在实际应用中,还可以将图11中的每个模块划分为多个单元。
例如,如图12所示,可以将所述合并决策模块1101划分为业务流水解析单元11011、合并决策计算单元11012、合并决策结果输出单元11013。其中,业务流水解析单元11011用于获取新增的业务数据,并从获取的新增的业务数据中提取节点数据,合并决策计算单元11012用于根据提取出的节点数据和已有图数据,生成合并决策结果,合并决策结果输出单元11013用于输出生成的生成合并决策结果。
可以将所述合并模块1102划分为合并决策结果解析单元11021、合并计算单元11022、合并结果输出单元11023。其中,合并决策结果解析单元11021用于解析合并决策结果以确定待合并的连通子图和业务数据,合并计算单元11022用于根据解析后的合并决策结果,将待合并的连通子图和业务数据合并更新至已有图数据中,合并结果输出单元11023用于输出合并更新后的已有图数据。
将所述控制模块1103划分为状态管理单元11031、流程管理单元11032。其中,状态管理单元11031用于管理对所述新增的业务数据的处理状态,流程管理单元11032用于控制对所述新增的业务数据的处理流程。
进一步的,如图10所示,可以将本申请实施例提供的图数据更新系统应用于图1的业务平台中。可以看到,图数据更新系统可以直接获取到新增的业务数据,然后将其合并更新至生产环境存储的已有图数据中,相比于图1中采用的图数据更新方法,效率和实时性更高。
本申请实施例提供一种图数据更新方法、装置及系统,该方法获取新增的业务数据,并提取所述新增的业务数据中的节点数据,根据已有图数据和提取出的节点数据,生成合并决策结果,根据所述合并决策结果和所述新增的业务数据,对所述已有图数据进行更新,其中,所述合并决策结果用于将从所述新增的业务数据中提取出的节点数据并入所述已有图数据,所述已有图数据是根据所述新增的业务数据之前的历史业务数据生成的。通过上述方法,可以根据在一定时间段内新增的业务数据对已有图数据增量地更新,而不需要根据全部的新增的业务数据重新生成图数据,因此,本申请实施例提供的图数据更新方法资源耗费低,效率和实时性高。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。