CN103346901A - 一种面向数据流处理的元组跟踪方法及系统 - Google Patents
一种面向数据流处理的元组跟踪方法及系统 Download PDFInfo
- Publication number
- CN103346901A CN103346901A CN 201310227114 CN201310227114A CN103346901A CN 103346901 A CN103346901 A CN 103346901A CN 201310227114 CN201310227114 CN 201310227114 CN 201310227114 A CN201310227114 A CN 201310227114A CN 103346901 A CN103346901 A CN 103346901A
- Authority
- CN
- China
- Prior art keywords
- tuple
- root
- tracking cell
- value
- checkvalue
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000005111 flow chemistry technique Methods 0.000 title abstract description 6
- 230000008569 process Effects 0.000 claims abstract description 47
- 238000012545 processing Methods 0.000 claims abstract description 39
- 238000013507 mapping Methods 0.000 claims description 59
- 230000002159 abnormal effect Effects 0.000 claims description 18
- 230000015654 memory Effects 0.000 description 20
- 238000005516 engineering process Methods 0.000 description 11
- 238000011144 upstream manufacturing Methods 0.000 description 7
- 230000009286 beneficial effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000007812 deficiency Effects 0.000 description 2
- 239000012467 final product Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 239000005441 aurora Substances 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000009545 invasion Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000007493 shaping process Methods 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种面向数据流处理的元组跟踪方法及系统,该系统包括元组生成器、元组跟踪器和若干个元组处理器,元组生成器生成根元组并处理产生新的元组,然后,将新的元组发送给不同的元组处理器,元组处理器对接收的元组进行处理产生新的元组,每个根元组经过处理后会产生一个元组树,在每个元组树生成过程中,元组生成器向元组跟踪器发送该根元组的相关信息,供元组跟踪器构建该根元组的跟踪记录,元组跟踪器为每个根元组选择一个元组跟踪单元;每个元组处理器处理元组的过程中向元组跟踪器发送元组的相关信息来对跟踪记录的标识位进行更新,本发明可以实现大大降低内存开销,实现元组跟踪单元的负载均衡,提高元组处理的可靠性。
Description
技术领域
本发明涉及分布式的数据流处理领域,特别是保证了数据流中需要处理的每个元组都不会因为丢失而无法得到处理的面向数据流处理的元组跟踪方法及系统。
背景技术
随着云计算、物联网等技术的兴起,数据正以前所未有的速度不断地增长和积累,并且越来越多地以大规模、连续的流的形式出现在应用程序中,其中最典型的应用就是监控应用,例如金融市场监控、网络监控、移动对象监控、入侵检查和生态系统监控等,因为这类应用监控的都是处理实时数据,所以数据的价值会随着时间的推移而不断减小,因此低延迟处理对这类应用是一个关键需求,为此工业界和学术界开发了很多数据流处理系统,包括斯坦福大学的STREAM、施乐公司的Tapestry、加州大学伯克利分校的Telegraph、布朗大学和麻省理工学院合作的Aurora,Apache的HadoopOnline以及Yahoo的S4。这些系统从集中式演化到并行分布式,其主要目的就是为了提高数据流处理的性能,降低处理延迟。但是在分布式的环境中,随着服务器和通信次数的增多,数据流处理过程中出现故障的几率也随之增加。其中,任何一台服务器出现故障都会对数据流处理过程产生延迟,不仅如此,故障还可能导致产生最终结果的至关重要的数据丢失。因此,提高分布式环境下的数据流处理系统的可靠性是一个关键需求。
目前,提高可靠性的技术主要包括三种:主动备份,被动备份和上游备份。这三种技术的主要区别在于服务器出现故障时恢复丢失数据的方式。
主动备份技术通过一个备用服务器来进行恢复。当主服务器出现故障时,这个技术会使用备用服务器。这个技术的不足是内存空间开销大。此外,元组必须发送到备用服务器也会带来额外的时间开销。同时,这个技术只需要把主服务器的输出流切换到备用服务器,因此故障恢复的时间较少。
被动备份技术把主服务器的状态周期性地拷贝到备用服务器上。当主服务器出现故障时,这些拷贝被安装到备用服务器。一个服务器的周期性的拷贝被称为校验。与主动备份相比,由于主服务器和备用服务器之间周期性进行校验可以减少需要主动备份时主服务器发送的元组个数,因此被动备份会带来较少的时间开销。另一方面,由于在最后一次校验和出现故障的这段时间内发送到主服务器的所有元组都没有在备用服务器中备份,所以这些元组需要重新发送到备用服务器上,因此导致被动备份的故障恢复时间较长。
上游备份技术不需要使用任何备用服务器,只依赖上游服务器和下游服务器。上游服务器在输出队列中备份输出元组,直到下游服务器确认这些元组可以被删除。这个技术的核心思想是:当主服务器出现故障时,上游服务器把所有在输出队列并且还没有被下游服务器确认的元组重新发送到主服务器的备用服务器。上游备份的时间开销较少,只需要上游服务器在输出队列中备份输出元组,但是故障恢复的时间也较长。
然而,上述备份技术只适用于故障粒度是服务器的情况,当服务器没有出现故障,但是它所处理的元组由于内存限制等原因丢失时,上述技术无法对这些元组进行重新处理。然而,如果把故障粒度定为数据流处理过程中的每个元组,那么当元组数量很多时,为了保证每个元组被正常处理,系统需要在内存中把它们一直保留到被正常处理确认之后,因此内存开销会很大。因此我们需要一种既能节约内存又能够保证需要处理的每个元组都被处理的可靠方案。
发明内容
本发明所要解决的技术问题是针对现有技术的不足,提供一种节省内存、负载均衡、元组处理可靠的能保证数据流中需要处理的每个元组都不会因为丢失而无法得到处理的面向数据流处理的元组跟踪方法及系统。
本发明解决上述技术问题的技术方案如下:一种面向数据流处理的元组跟踪方法,包括如下步骤:
步骤1:元组生成器内设有若干个元组转换单元,将元组生成器生成的若干个根元组分配给若干个元组转换单元存储并处理,每个根元组经过元组转换单元处理后产生一个或一个以上的元组;
步骤2:元组生成器将若干个根元组编号及与根元组对应的元组转换单元编号的对应关系发送给元组跟踪器;
步骤3:元组跟踪器根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录<SpringTupleId,taskId,checkValue>,其中,SpringTupleId为根元组编号,taskId为元组转换单元编号,checkValue为标识根元组对应的元组树是否得到一次完整处理的标识位,checkValue的初始值为0;
步骤4:元组跟踪器内设有若干个元组跟踪单元,每个元组跟踪单元具有一个元组跟踪单元编号ackerId,元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元,并将步骤2中构建的若干个根元组的跟踪记录分别存储在相应的元组跟踪单元中;
步骤5:对步骤1中每个元组转换单元生成的一个或一个以上的1级元组分别发送给不同的1级元组处理器处理,每个1级元组处理器对接收到的1级元组进行处理,产生一个或一个以上的2级元组,依次执行下去,n-1级元组处理器对接收的n-1级元组进行处理,产生一个或一个以上的n级元组,并将n级元组分别发送给n级元组处理器,n级元组处理器对接收的n级元组进行处理,不再产生新的元组,一个根元组经过元组生成器中的元组转换单元和若干个元组处理器处理后会生成一个元组树;
步骤6:在步骤5由每个根元组产生一个元组树的过程中,元组转换单元将产生的1级元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;每级元组处理器将接收的元组的元组编号和处理产生的新元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;直到最后一级元组处理器对接收的元组进行处理后不再产生新的元组为止,最后一级元组处理器仅将接收的元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新,进而得到checkValue值的最终结果;
步骤7:根据跟踪记录<SpringTupleId,taskId,checkValue>,将步骤6中所得的checkValue的最终结果反馈给元组生成器中相应的元组转换单元;
步骤8:元组转换单元判断checkValue的值是否为0,如果为0,表明该根元组对应的元组树的得到一次完整处理,将该根元组从元组转换单元中删除,否则,表明该根元组对应的元组树的未得到一次完整处理,该根元组对应的元组转换单元重新对该根元组进行处理,并将重新生成的新元组发送给不同的元组处理器。
本发明的有益效果是:
节省内存:元组跟踪器跟踪每个元组树仅需要大约20字节的内存空间,跟踪时,为节约内存,只需要在内存中保留元组编号的异或运算的数值,而无须保留元组;元组树上的每个元组经过处理后,将该元组的元组编号和处理产生的新元组的元组编号发送给元组跟踪器进行异或运算,运算结果与checkValue进行异或运算,然后,再用与checkValue进行异或运算的结果对checkValue更新,所以元组跟踪器中仅保存checkValue的更新值,大大降低了对该元组树上所有元组进行跟踪的内存开销;
负载均衡:元组跟踪器内设有若干个元组跟踪单元,保证每个元组跟踪单元跟踪元组的数量基本相同,不会出现某个元组跟踪单元负载过大的情况;
可靠的元组处理:元组跟踪器利用元组树上的所有元组的元组编号对跟踪记录的checkValue值进行更新,对于处理结束时checkValue的值为0的根元组从元组生成器的元组转换单元中删除,将处理结束时checkValue的值不为0的根元组进行重新处理,保证每个根元组得到一次完整的处理。
只需对跟踪记录的标识位进行不断更新来记录元组树的处理情况,大大降低了内存开销;且每个元组跟踪单元跟踪的根元组数量基本相同,实现了负载均衡,根据跟踪记录确保每个根元组对应的元组树都能得到一次完整的处理,提高了元组处理的可靠性。
在上述技术方案的基础上,本发明还可以做如下改进。
进一步,步骤4中所述元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元的具体步骤如下:
步骤4.1:分别计算若干个根元组编号和若干个元组跟踪单元编号的映射值,并将计算的映射值对应到一个由0-(232-1)的数值构成的数值环上;
步骤4.2:将映射结果封装为location=<key,type,active>,其中location为映射结果,key表示根元组编号或元组跟踪单元编号的映射值;type表示映射类型,type为0表示为根元组编号的映射,type为1表示元组跟踪单元编号的映射;active默认值为0表示元组跟踪单元未启动,active为1表示元组跟踪单元正常运行,active为2表示元组跟踪单元异常终止;
步骤4.3:对于每个根元组,在环上从该根元组的映射值出发,沿顺时针方向寻找离该根元组距离最近的元组跟踪单元的映射值,将该根元组的映射结果location存储在找到的元组跟踪单元的映射值所对应的元组跟踪单元中;
步骤4.4:根据根元组与其找到的元组跟踪单元的对应关系,将元组跟踪器为该根元组构建的跟踪记录存储在找到的元组跟踪单元中。
进一步,所述步骤4.1中计算若干个根元组编号和若干个元组跟踪单元编号的映射值的步骤如下:
步骤4.11:初始化全局变量hash=0;
步骤4.12:将根元组编号或元组跟踪单元编号的字符串的每个字符从左到右执行如下公式,hash=hash*131+字符的ASCII码;
步骤4.13:按如下公式计算根元组编码或元组跟踪单元编码的映射值,
key=hash/(232-1)。
进一步,元组跟踪器在运行过程中,如果元组跟踪器的某个元组跟踪单元异常终止时,则将该元组跟踪单元跟踪的根元组按照步骤4.3和4.4中的操作进行重新分配。
进一步,当根元组过多,需要增加元组跟踪单元时,按步骤4.1和4.2中的操作将增加的元组跟踪单元编号映射到环上,将受影响的根元组重新按照步骤4.3和4.4中的操作进行重新分配。
进一步,针对步骤5中所述元组树,当某个根元组对应的元组树中的所有元组都得到处理时,则认为该元组树得到一次完整处理,如果该根元组对应的元组树中任意一个元组在指定时间内没有被成功处理,则认为该元组树没有得到一次完整处理。
进一步,步骤6的每个根元组产生一个元组树的过程中,对每个根元组对应的元组跟踪单元中存储的元组跟踪记录的checkValue值进行更新的步骤如下:
步骤6.1:元组跟踪单元将接收的元组转换单元发送的一批元组的元组编号进行异或运算,用得到的结果与checkValue值进行异或运算,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.2:每个元组处理器处理完接收的元组后,将接收的元组的元组编号和产生的新元组的元组编号发送给步骤6.1中所述的元组跟踪单元,并进行异或运算,用运算结果与checkValue值进行异或运算,然后,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.3:当经过若干个元组处理器后,最后一批元组处理器处理接收到的元组但不再产生新的元组,该批元组处理器仅将接收的元组的元组编号发送给步骤6.1中所述的元组跟踪单元进行异或运算,用得到的结果与checkValue值进行异或运算,再用与checkValue值进行异或运算的结果更新checkValue值,得到checkValue值的最终结果。
本发明解决上述技术问题的另一技术方案如下:一种面向数据流处理的元组跟踪系统,包括元组生成器、元组跟踪器和若干个元组处理器;
所述元组生成器包括若干个元组转换单元,所述元组生成器用于生成若干个根元组,将生成的若干个根元组分配到元组转换单元中存储并处理;还用于将根元组的编号和其分配到的元组转换单元的编号发送给元组跟踪器;
元组跟踪器内设有若干个元组跟踪单元,元组跟踪器用于根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录,还用于为每个根元组选择一个元组跟踪单元,并将该根元组的跟踪记录存储在相应的元组跟踪单元中;
所述元组处理器用于对接收的元组进行处理并且产生一批新的元组,同时,还用于将接收的元组的元组编号和产生的新元组的元组编号发送给元组跟踪器中相应的元组跟踪单元,并对元组跟踪记录值进行更新。
本发明的有益效果是:本发明所述面向数据流处理的元组跟踪系统结构简单、易于实现,能有效实现元组的跟踪,且跟踪过程中可节省内存开销,实现负载均衡,提高元组处理的可靠性。
进一步,所述元组跟踪器内置根元组分配策略,所述元组跟踪器根据根元组分配策略为每个根元组选择相应的元组跟踪单元。
采用上述进一步方案的有益效果是:为元组跟踪器中的每个元组跟踪单元能跟踪数量基本相同的根元组提供依据。
进一步,元组生成器还用于判断是由以下那种原因造成某一根元组对应的元组树没有得到一次完整处理,
情况1)元组生成器异常终止;
情况2)元组生成器中的某个元组转换单元异常终止;
情况3)在元组树生成过程中由于某些元组丢失造成元组树未得到一次完整处理;
如果是情况1)则元组生成器将所有已产生的元组重新分配给元组转换单元进行处理;
如果是情况2)则将异常终止的元组转换单元中的根元组重新处理;
如果是情况3)则根据跟踪记录找到该元组树对应的根元组及其对应的元组转换单元,并由该元组转换单元对该根元组进行重新处理。
采用上述进一步方案的有益效果是:可针对因不同情况造成根元组对应的元组树未得到一次完整处理,进行不同的操作,提高操作的准确度。
附图说明
图1为本发明所述一种面向数据流处理的元组跟踪系统的结构图;
图2为本发明所述一种面向数据流处理的元组跟踪方法的流程图;
图3是实施例中根元组编号springTupleId和元组跟踪单元编号ackerid映射到环状地址空间的示例图;
图4是实施例中有元组跟踪单元acker副本的元组分配策略图;
图5是实施例中根元组与元组跟踪单元的实际映射图;
图6是实施例中有故障元组跟踪单元acker时根元组重新分配策略图;
图7是实施例中增加元组跟踪单元acker时根元组重新分配策略图;
图8是实施例中checkValue更新步骤一的示意图;
图9是实施例中checkValue更新步骤二的示意图;
图10是实施例中checkValue更新步骤三的示意图;
图11是实施例中checkValue更新步骤四的示意图。
附图中,各标号所代表的部件列表如下:
1、元组生成器,2、元组跟踪器,3、一级元组处理器,4、二级元组处理器,n+2、N级元组处理器,101、元组转换单元,201、元组跟踪单元。
具体实施方式
以下结合附图对本发明的原理和特征进行描述,所举实例只用于解释本发明,并非用于限定本发明的范围。
元组:组成数据流的基本数据结构。元组是由一些Value组成的列表,Value可以是任意类型,如整形,字节型,字符型,比特数组,浮点型,双精度型,比特型,短整型,长整型,布尔型等等,同样也可以是自定义可序列化类型。
元组状态:处理元组过程的状态分为以下三种:正在处理状态pending、处理失败状态failure和处理成功状态finish。
数值环:由0到232-1数值组成的一个首尾相接的数值空间。
数据流:数据流是一个没有界限的元组序列。
Spring:元组生成器,产生并且发送数据流元组的组件,一个Spring可以产生一个或者多个数据流的元组。
Processor:元组处理器,接收数据流的元组并进行处理的组件,处理后的元组也可能被发送给其他元组处理器。
Acker:元组跟踪器中的元组跟踪单元。
根元组:是从外部接收的数据(消息)。
元组树:一个根元组被处理后产生一个或一个以上的元组,产生的元组还可能继续产生新的元组,直到不再产生新元组为止,所有元组所形成的一个树状结构就是元组树。在这个元组树中,根元组的唯一标识表示为springTupleId,其他元组的唯一标识表示为tupleId。
元组树的一次完整的处理:以Spring产生的元组为根的元组树中的所有元组都被成功处理时,则认为是Spring产生的这个元组得到一次完整的处理。如果一棵元组树中的任意一个元组在指定的时间内没有被成功处理,那么Spring发出的元组被认为处理失败。
跟踪记录:是一个包含三个字段的结构体,表示为<springTupleId,taskId,checkValue>。其中,springTupleId是Spring产生的根元组的唯一标识,taskId用来表示被元组生成器Spring的哪个元组转换单元Task来处理,checkValue用来表示Spring产生的根元组对应的元组树是否得到一次完整的处理。
如图1所示,一种面向数据流处理的元组跟踪系统,包括元组生成器1、元组跟踪器2和若干个元组处理器3;
所述元组生成器1包括若干个元组转换单元101,所述元组生成器1用于生成若干个根元组,将生成的若干个根元组分配到元组转换单元101中存储并处理;还用于将根元组的编号和其分配到的元组转换单元的编号发送给元组跟踪器2;
元组跟踪器2内设有若干个元组跟踪单元201,元组跟踪器1用于根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录,还用于为每个根元组选择一个元组跟踪单元201,并将该根元组的跟踪记录存储在相应的元组跟踪单元201中;
所述元组处理器3用于对接收的元组进行处理产生一批新的元组,还用于将接收的元组的元组编号和产生的新元组的元组编号发送给元组跟踪器2中相应的元组跟踪单元201,并对元组跟踪记录值进行更新。
其中,所述元组跟踪器2内置根元组分配策略,所述元组跟踪器根据根元组分配策略为每个根元组选择相应的元组跟踪单元201,根元组分配策略的具体方案如下:
步骤4.1:分别计算若干个根元组编号和若干个元组跟踪单元编号的映射值,并将计算的映射值对应到一个由0-(232-1)的数值构成的数值环上;
步骤4.2:将映射结果封装为location=<key,type,active>,其中location为映射结果,key表示根元组编号或元组跟踪单元编号的映射值;type表示映射类型,type为0表示为根元组编号的映射,type为1表示元组跟踪单元编号的映射;active默认值为0表示元组跟踪单元未启动,active为1表示元组跟踪单元正常运行,active为2表示元组跟踪单元异常终止;
步骤4.3:对于每个根元组,在环上从该根元组的映射值出发,沿顺时针方向寻找离该根元组距离最近的元组跟踪单元的映射值,将该根元组的映射结果location存储在找到的元组跟踪单元的映射值所对应的元组跟踪单元中;
步骤4.4:根据根元组与其找到的元组跟踪单元的对应关系,将元组跟踪器为该根元组构建的跟踪记录存储在找到的元组跟踪单元中。
其中,所述步骤4.1中计算若干个根元组编号和若干个元组跟踪单元编号的映射值的步骤如下:
步骤4.11:初始化全局变量hash=0;
步骤4.12:将根元组编号或元组跟踪单元编号的字符串的每个字符从左到右执行如下公式,hash=hash*131+字符的ASCII码;
步骤4.13:按如下公式计算根元组编码或元组跟踪单元编码的映射值,
key=hash/(232-1)。
另外,元组生成器还用于判断是由以下那种原因造成某一根元组对应的元组树没有得到一次完整处理,
情况1)元组生成器异常终止;
情况2)元组生成器中的某个元组转换单元异常终止;
情况3)在元组树生成过程中由于某些元组丢失造成元组树未得到一次完整处理;
如果是情况1)则元组生成器将所有已产生的元组重新分配给元组转换单元进行处理;
如果是情况2)则将异常终止的元组转换单元中的根元组重新处理;
如果是情况3)则根据跟踪记录找到该元组树对应的根元组及其对应的元组转换单元,并由该元组转换单元对该根元组进行重新处理。
元组树得到一次完整处理的定义如下:当某个根元组对应的元组树中的所有元组都得到处理时,则认为该元组树得到了一次完整处理,如果该根元组对应的元组树中任意一个元组在指定时间内没有被成功处理,则认为该元组树没有得到一次完整处理。
如图2所示,一种面向数据流处理的元组跟踪方法,包括如下步骤:
步骤1:元组生成器内设有若干个元组转换单元,将元组生成器生成的若干个根元组分配给若干个元组转换单元存储并处理,每个根元组经过元组转换单元处理后产生一个或一个以上的元组;
步骤2:元组生成器将若干个根元组编号及与根元组对应的元组转换单元编号的对应关系发送给元组跟踪器;
步骤3:元组跟踪器根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录<SpringTupleId,taskId,checkValue>,其中,SpringTupleId为根元组编号,taskId为元组转换单元编号,checkValue为标识根元组对应的元组树是否得到一次完整处理的标识位,checkValue的初始值为0;
步骤4:元组跟踪器内设有若干个元组跟踪单元,每个元组跟踪单元具有一个元组跟踪单元编号ackerId,元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元,并将步骤2中构建的若干个根元组的跟踪记录分别存储在相应的元组跟踪单元中;
步骤5:对步骤1中每个元组转换单元生成的一个或一个以上的1级元组分别发送给不同的1级元组处理器处理,每个1级元组处理器对接收到的1级元组进行处理,产生一个或一个以上的2级元组,依次执行下去,n-1级元组处理器对接收的n-1级元组进行处理,产生一个或一个以上的n级元组,并将n级元组分别发送给n级元组处理器,n级元组处理器对接收的n级元组进行处理,不再产生新的元组,一个根元组经过元组生成器中的元组转换单元和若干个元组处理器处理后会生成一个元组树;其中,每级元组处理器处理完接收的元组后将元组删除。
步骤6:在步骤5由每个根元组产生一个元组树的过程中,元组转换单元将产生的1级元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;每级元组处理器将接收的元组的元组编号和处理产生的新元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;直到最后一级元组处理器对接收的元组处理不再产生新的元组为止,最后一级元组处理器仅将接收的元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新,进而得到checkValue值的最终结果;
步骤7:根据跟踪记录<SpringTupleId,taskId,checkValue>,将步骤6中所得的checkValue的最终结果反馈给元组生成器中相应的元组转换单元;
步骤8:元组转换单元判断checkValue的值是否为0,如果为0,表明该根元组对应的元组树的得到一次完整处理,将该根元组从元组转换单元中删除,否则,表明该根元组对应的元组树的未得到一次完整处理,该根元组对应的元组转换单元重新对该根元组进行处理,并将重新生成的新元组发送给不同的元组处理器。
其中,步骤4中所述元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元的具体步骤如下:
步骤4.1:分别计算若干个根元组编号和若干个元组跟踪单元编号的映射值,并将计算的映射值对应到一个由0-(232-1)的数值构成的数值环上;
步骤4.2:将映射结果封装为location=<key,type,active>,其中location为映射结果,key表示根元组编号或元组跟踪单元编号的映射值;type表示映射类型,type为0表示为根元组编号的映射,type为1表示元组跟踪单元编号的映射;active默认值为0表示元组跟踪单元未启动,active为1表示元组跟踪单元正常运行,active为2表示元组跟踪单元异常终止;
步骤4.3:对于每个根元组,在环上从该根元组的映射值出发,沿顺时针方向寻找离该根元组距离最近的元组跟踪单元的映射值,将该根元组的映射结果location存储在映射值所对应的元组跟踪单元上;
步骤4.4:根据根元组与其找到的元组跟踪单元的对应关系,将元组跟踪器为该根元组构建的跟踪记录存储在找到的元组跟踪单元中。
其中,所述步骤4.1中计算若干个根元组编号和若干个元组跟踪单元编号的映射值的步骤如下:
步骤4.11:初始化全局变量hash=0;
步骤4.12:将根元组编号或元组跟踪单元编号的字符串的每个字符从左到右执行如下公式,hash=hash*131+字符的ASCII码;
步骤4.13:按如下公式计算根元组编码或元组跟踪单元编码的映射值,
key=hash/(232-1)。
如图3所示,假如有根元组1,根元组2···根元组6和元组跟踪单元acker A、acker B,将这四个根元组的元组编号springTupleId和两个元组跟踪单元的编号ackerId映射到数值环上,然后将映射的结果封装成location=<key,type,active>,其中type为0表示元组的映射,type为1表示元组跟踪单元acker的映射,active默认值为0表示acker未启动,active为1表示acker正常运行,active为2表示acker异常终止。映射的结果在数值环中的分布如图3所示。
在这个环中,对于每一个根元组,从该根元组的key值出发,沿顺时针方向旋转,当遇到第一个acker时,将该元组的location存储在acker上,因为springTupleId和ackerId的hash值是固定的,因此这个根元组和元组跟踪单元acker的关系必然是唯一和确定的。理想的hash的结果是将所有根元组均匀分配到各acker中去,采取的策略就是将一个ackerId映射到两(N)个位置(N默认值可到配置文件中读取,元组跟踪器也提供一个对外修改的接口setAckers()方法,该接口专门用于修改N值)。此时value为acker_id#1,acker_id#2···acker_id#N,hash值key=hash(value),hash值在环上的分布以及分配结果如图4所示,元组和acker实际的对应关系如图5所示。
如图6所示,元组跟踪器在运行过程中,如果元组跟踪器的某个元组跟踪单元acker异常终止时或者通过修改元组跟踪器的元组跟踪单元acker数量N值减少acker(假设强行终止了acker B),则将该元组跟踪单元acker跟踪的根元组按照步骤4.3和4.4中的操作进行重新分配,将受影响的根元组沿逆时针遍历直到下一个元组跟踪单元acker(acker A2和acker A1)之间的location,也就是本来映射到acker B上的那些location。那么,仅需要将元组2对应的location分配给acker A2,元组4和元组6对应的location分配给acker A1即可,元组的重新分配如图6所示。
如图7所示,当根元组过多,需要增加元组跟踪单元时,(仅仅有ackerA和acker B记录这些元组对应的location状态负载过大)而增加acker或者通过修改元组跟踪器的acker数量N值增加acker(假设新增acker C),按步骤4.1和4.2中的操作将增加的元组跟踪单元编号映射到环上,将元组重新按照步骤4.3和4.4中的操作进行重新分配;将元组跟踪单元acker C的两个hash值分别映射到数值环元组3和元组5之间、元组4和元组6所对应的location之间,这时受影响的元组将仅是那些沿acker C1或acker C2逆时针遍历直到下一个acker B2和acker A2之间的对象(它们是原来映射到acker B1和acker A2上的),将这些根元组重新映射到acker C1和ackerC2上即可,映射的结果如图7所示。
针对步骤5中所述元组树,当某个根元组对应的元组树中的所有元组都得到处理时,则认为该元组树得到一次完整处理,如果该根元组对应的元组树中任意一个元组在指定时间内没有被成功处理,则认为该元组树没有得到一次完整处理。
步骤6每个根元组产生一个元组树的过程中,对每个根元组对应的元组跟踪单元中存储的元组跟踪记录的checkValue值进行更新的步骤如下:
步骤6.1:元组跟踪单元将接收的元组转换单元发送的一批元组的元组编号进行异或运算,运算结果再与checkValue值进行异或运算,然后,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.2:每个元组处理器处理完接收的元组后,将接收的元组的元组编号和产生的新元组的元组编号发送给步骤6.1中所述的元组跟踪单元,并进行异或运算,运算结果再与checkValue值进行异或运算,然后,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.3:当经过若干个元组处理器处理后,最后一批元组处理器处理接收到的元组不会产生新的元组,该批元组处理器仅将接收的元组的元组编号发送给步骤6.1中所述的元组跟踪单元进行异或运算,用得到的结果与checkValue值进行异或运算,再用与checkValue值进行异或运算的结果更新checkValue值,得到checkValue值的最终结果。
如图8-11所示,checkValue更新的一个实施例
1.元组生成器Spring产生id为0001的根元组,元组生成器1的某一元组转换单元101处理该根元组并产生了id为0010和1011两个元组,同时将id为0010和1011两个元组的id发送给元组跟踪器2的该根元组的元组跟踪单元acker;
2.元组跟单元acker将这两个id0010和1011进行异或运算,将得到的结果与checkValue中的值做异或运算;用所得的结果更新checkValue值;
3.将id为0010的元组传到元组处理器Processor1中,将id为1011的元组传到元组处理器Processor2中;。
4.Processor1确认已经处理0010这个元组,处理元组的结果是产生了新id为0110的元组,Processor1将处理的元组的id0010和新产生的元组的id0110发送给元组跟踪器中相应的元组跟踪单元acker;
5.元组跟踪单元acker将0010和0110进行异或运算,然后,所得的结果与checkValue中的值做异或运算,然后,再用与checkValue中的值做异或运算的结果更新checkValue值;
6.Processor2确认已经处理1011这个元组,处理元组的结果是产生了新的id为0111的元组,Processor2将处理的元组id1011和新产生的元组的id0111发送给元组跟踪器中相应的元组跟踪单元acker;
7.元组跟踪单元acker将1011和0111进行异或运算,然后,所得的结果与checkValue中的值做异或运算,然后,再用与checkValue中的值做异或运算所得的结果更新checkValue值;
8.将4中Processor1产生的元组的id为0110的元组传到Processor3中,将6中Processor2产生的元组的id为0111的元组传到Processor3;
9.Processor3确认已经处理0110和0111这两个元组,不再有新的元组生成,然后Processor3仅将接收的两个元组的id发送给元组跟踪器中相应的元组跟踪单元acker;
10.元组跟踪单元acker仅将0110和0111做异或运算,将所得的结果与checkValue中的值做异或运算,然后,再用与checkValue异或运算的结果更新checkValue值,得到该根元组对应的跟踪记录中checkValue的最终结果。
以上过程就是某一个跟踪记录中checkValue的变化过程。判断跟踪记录字段springTupleId所代表的根元组是否重新处理的依据就是判断checkValue值是否为0。当checkValue中的值为0时,元组跟踪器将会将该springTupleId和taskId发给Spring组件,Spring组件会将会根据taskId把springTupleId的根元组状态置为finish状态,并将该根元组从内存中移出。假如checkValue中的值不为0,将会通知Spring组件更新taskId中springTupleId的根元组状态为failure,那么Spring组件会重新处理该根元组。
本发明可实现以下有益效果:
节省内存
在数据流处理的过程中,元组的数量很多。要保证从Spring产生的每个根元组对应的元组树都得到至少一次完整的处理,则需要对每个元组进行跟踪。Spring产生的每个根元组会形成一个以该元组为根的元组树,为了保证元组树中的每个元组都被成功处理,最简单的方式是对元组树中的每个节点进行跟踪,然而,如果这个元组树中含有成千上万个节点,对元组树的跟踪会占用大量的内存,可能导致内存泄漏。为了解决跟踪元组树的内存开销问题,本发明提供了元组跟踪器,它跟踪一棵任意大小的元组树只需要大约20字节的内存空间,极大地降低了保证元组树得到至少一次完整的处理对内存的要求。
负载均衡
由于Spring产生根元组的速度很快并且数量很多,元组跟踪器如果只使用一个元组跟踪单元acker来跟踪Spring产生的所有根元组是远远不够的。因此,本发明的元组跟踪器同时使用多个元组跟踪单元acker跟踪Spring产生的所有根元组。为了使各个acker跟踪元组的数量尽量均衡,需要一个对Spring产生根元组的负载均衡策略(即步骤4中对应的在数值环上的分配原则),使得元组跟踪单元acker不会因为跟踪Spring产生的根元组个数过多而异常终止。假如某个元组跟踪单元acker异常终止,元组跟踪器将该元组跟踪单元acker所跟踪的元组分配给其它的元组跟踪单元acker。元组跟踪器使用一个映射函数实现了元组在acker上的负载均衡策略,该映射函数首先将Spring产生的根元组的id映射到数值环上的某一个值,然后将一个acker及其副本分别映射到数值环上的某一个值,每个acker跟踪以逆时针方向与它数值距离最近的根元组,这样每个acker跟踪的元组数量就会相对均衡。
可靠的元组处理
元组跟踪器会保证Spring产生的每个根元组至少得到一次完整的处理。为了实现每个根元组至少得到一次完整的处理,当元组没有被成功处理后,元组跟踪器会针对以下三种情况进行处理:
Spring出现异常终止,那么所有的元组将会重新处理。
执行Spring的某个元组转换单元异常终止,那么该元组转换单元处理的元组会重新处理。
元组跟踪器通过跟踪记录中的checkValue的值(0/非0)来判断该Spring产生的根元组是否得到完整的处理,如果某个元组没有得到一次完整处理(checkValue为非0),那么元组跟踪器会通知Spring中处理该元组的元组转换单元重新处理该根元组。
元组丢失重新处理
元组跟踪器用跟踪记录<springTupleId,taskId,checkValue>来跟踪Spring输出的根元组。跟踪记录中checkValue字段是Spring输出的根元组形成元组树的一个表示,通过对checkValue值判断元组树是否已经得到完整的处理。不管这棵元组树多大,它只是简单地把这棵树上的所有节点已处理的元组的id和新产生的元组的id做异或(XOR)运算,用异或的结果与checkValue进行异或,然后,再用与checkValue异或的结果更新checkValue值。当checkValue为0,表示跟踪记录中对应的Spring产生的根元组被完整的处理,因为元组树中的每个元组都出现两次,所以异或的结果为0,由此证明该Spring产生的根元组产生的元组树中的所有元组都得到了处理。反之,没有得到完整的处理,这是因为在处理元组的过程中如果存在元组丢失的现象,那么元组树中不是每个元组都会出现两次,所以结果不为0,此时,将会通过跟踪记录中的taskId通知Spring组件相应的元组转换单元重新处理该根元组并将产生的新元组重新发送给元组处理器。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种面向数据流处理的元组跟踪方法,其特征在于,包括如下步骤:
步骤1:元组生成器内设有若干个元组转换单元,将元组生成器生成的若干个根元组分配给若干个元组转换单元存储并处理,每个根元组经过元组转换单元处理后产生一个或一个以上的元组;
步骤2:元组生成器将若干个根元组编号及与根元组对应的元组转换单元编号的对应关系发送给元组跟踪器;
步骤3:元组跟踪器根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录<SpringTupleId,taskId,checkValue>,其中,SpringTupleId为根元组编号,taskId为元组转换单元编号,checkValue为标识根元组对应的元组树是否得到一次完整处理的标识位,checkValue的初始值为0;
步骤4:元组跟踪器内设有若干个元组跟踪单元,每个元组跟踪单元具有一个元组跟踪单元编号ackerId,元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元,并将步骤2中构建的若干个根元组的跟踪记录分别存储在相应的元组跟踪单元中;
步骤5:对步骤1中每个元组转换单元生成的一个或一个以上的1级元组分别发送给不同的1级元组处理器处理,每个1级元组处理器对接收到的1级元组进行处理,产生一个或一个以上的2级元组,依次执行下去,n-1级元组处理器对接收的n-1级元组进行处理,产生一个或一个以上的n级元组,并将n级元组分别发送给n级元组处理器,n级元组处理器对接收的n级元组进行处理,不再产生新的元组,一个根元组经过元组生成器中的元组转换单元和若干个元组处理器处理后会生成一个元组树;
步骤6:在步骤5由每个根元组产生一个元组树的过程中,元组转换单元将产生的1级元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;每级元组处理器将接收的元组的元组编号和处理产生的新元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新;直到最后一级元组处理器对接收的元组处理不再产生新的元组为止,最后一级元组处理器仅将接收的元组的元组编号发送给元组跟踪器中相应的元组跟踪单元并对跟踪记录的checkValue值进行更新,进而得到checkValue值的最终结果;
步骤7:根据跟踪记录<SpringTupleId,taskId,checkValue>,将步骤6中所得的checkValue的最终结果反馈给元组生成器中相应的元组转换单元;
步骤8:元组转换单元判断checkValue的值是否为0,如果为0,表明该根元组对应的元组树得到一次完整处理,将该根元组从元组转换单元中删除,否则,表明该根元组对应的元组树的未得到一次完整处理,该根元组对应的元组转换单元重新对该根元组进行处理,并将重新生成的新元组发送给不同的元组处理器。
2.根据权利要求1所述一种面向数据流处理的元组跟踪方法,其特征在于,步骤4中所述元组跟踪器根据根元组编号SpringTupleId和元组跟踪单元编号ackerId为每个根元组选择一个元组跟踪单元的具体步骤如下:
步骤4.1:分别计算若干个根元组编号和若干个元组跟踪单元编号的映射值,并将计算的映射值对应到一个由0-(232-1)的数值构成的数值环上;
步骤4.2:将映射结果封装为location=<key,type,active>,其中location为映射结果,key表示根元组编号或元组跟踪单元编号的映射值;type表示映射类型,type为0表示为根元组编号的映射,type为1表示元组跟踪单元编号的映射;active默认值为0表示元组跟踪单元未启动,active为1表示元组跟踪单元正常运行,active为2表示元组跟踪单元异常终止;
步骤4.3:对于每个根元组,在环上从该根元组的映射值出发,沿顺时针方向寻找离该根元组距离最近的元组跟踪单元的映射值,将该根元组的映射结果location存储在找到的元组跟踪单元的映射值所对应的元组跟踪单元中;
步骤4.4:根据根元组与其找到的元组跟踪单元的对应关系,将元组跟踪器为该根元组构建的跟踪记录存储在找到的元组跟踪单元中。
3.根据权利要求2所述一种面向数据流处理的元组跟踪方法,其特征在于,所述步骤4.1中计算若干个根元组编号和若干个元组跟踪单元编号的映射值的步骤如下:
步骤4.11:初始化全局变量hash=0;
步骤4.12:将根元组编号或元组跟踪单元编号的字符串的每个字符从左到右执行如下公式,hash=hash*131+字符的ASCII码;
步骤4.13:按如下公式计算根元组编码或元组跟踪单元编码的映射值,key=hash/(232-1)。
4.根据权利要求1所述一种面向数据流处理的元组跟踪方法,其特征在于,当元组跟踪器运行时,如果元组跟踪器的某个元组跟踪单元异常终止时,则将该元组跟踪单元跟踪的根元组按照步骤4.3和4.4中的操作进行重新分配。
5.根据权利要求1所述一种面向数据流处理的元组跟踪方法,其特征在于,当根元组过多,需要增加元组跟踪单元时,按步骤4.1和4.2中的操作将增加的元组跟踪单元编号映射到环上,将受影响的元组重新按照步骤4.3和4.4中的操作进行重新分配。
6.根据权利要求1所述一种面向数据流处理的元组跟踪方法,其特征在于,针对步骤5中所述元组树,当某个根元组对应的元组树中的所有元组都得到处理时,则认为该元组树得到一次完整处理,如果该根元组对应的元组树中任意一个元组在指定时间内没有被成功处理,则认为该元组树没有得到一次完整处理。
7.根据权利要求1所述一种面向数据流处理的元组跟踪方法,其特征在于,步骤6每个根元组在产生一个元组树的过程中,对每个根元组对应的元组跟踪单元中存储的元组跟踪记录的checkValue值进行更新的步骤如下:
步骤6.1:元组跟踪单元将接收的元组转换单元发送的一批元组的元组编号进行异或运算,用得到的结果与checkValue值进行异或运算,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.2:每个元组处理器处理完接收的元组后,将接收的元组的元组编号和产生的新元组的元组编号发送给步骤6.1中所述的元组跟踪单元,并进行异或运算,运算结果与checkValue值进行异或运算,然后,再用与checkValue值进行异或运算的结果更新checkValue值;
步骤6.3:当经过若干个元组处理器处理后,最后一批元组处理器处理接收到的元组但不再产生新的元组,该批元组处理器仅将接收到的元组的元组编号发送给步骤6.1中所述的元组跟踪单元进行异或运算,用得到的结果与checkValue值进行异或运算,再用与checkValue值进行异或运算的结果更新checkValue值,得到checkValue值的最终结果。
8.一种面向数据流处理的元组跟踪系统,其特征在于,包括元组生成器、元组跟踪器和若干个元组处理器;
所述元组生成器包括若干个元组转换单元,所述元组生成器用于生成若干个根元组,将生成的若干个根元组分配到元组转换单元中存储并处理;还用于将根元组的编号和其分配到的元组转换单元的编号发送给元组跟踪器;
元组跟踪器内设有若干个元组跟踪单元,元组跟踪器用于根据根元组编号及与根元组对应的元组转换单元编号为每个根元组构建元组跟踪记录,还用于为每个根元组选择一个元组跟踪单元,并将该根元组的跟踪记录存储在相应的元组跟踪单元中;
所述元组处理器用于对接收的元组进行处理并产生一批新的元组,还用于将接收的元组的元组编号和产生的新元组的元组编号发送给元组跟踪器中相应的元组跟踪单元,并对元组跟踪记录值进行更新。
9.根据权利要求8所述一种面向数据流处理的元组跟踪系统,其特征在于,所述元组跟踪器内置根元组分配策略,所述元组跟踪器根据根元组分配策略为每个根元组选择相应的元组跟踪单元。
10.根据权利要求8所述一种面向数据流处理的元组跟踪系统,其特征在于,元组生成器还用于判断是由以下那种原因造成某一根元组对应的元组树没有得到一次完整处理,
情况1)元组生成器异常终止;
情况2)元组生成器中的某个元组转换单元异常终止;
情况3)在元组树生成过程中由于某些元组丢失造成元组树未得到一次完整处理;
如果是情况1)则元组生成器将所有已产生的元组重新分配给元组转换单元进行处理;
如果是情况2)则将异常终止的元组转换单元中的根元组重新处理;
如果是情况3)则根据跟踪记录找到该元组树对应的根元组及其对应的元组转换单元,并由该元组转换单元对该根元组进行重新处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310227114.5A CN103346901B (zh) | 2013-06-07 | 2013-06-07 | 一种面向数据流处理的元组跟踪方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310227114.5A CN103346901B (zh) | 2013-06-07 | 2013-06-07 | 一种面向数据流处理的元组跟踪方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103346901A true CN103346901A (zh) | 2013-10-09 |
CN103346901B CN103346901B (zh) | 2016-01-20 |
Family
ID=49281677
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310227114.5A Expired - Fee Related CN103346901B (zh) | 2013-06-07 | 2013-06-07 | 一种面向数据流处理的元组跟踪方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103346901B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105141472A (zh) * | 2015-08-07 | 2015-12-09 | 北京思特奇信息技术股份有限公司 | 一种基于异或运算的流计算跟踪方法及系统 |
WO2017049861A1 (zh) * | 2015-09-25 | 2017-03-30 | 中兴通讯股份有限公司 | 数据处理状态监控方法和装置 |
WO2021212385A1 (zh) * | 2020-04-22 | 2021-10-28 | 深圳市欢太科技有限公司 | 数据检测方法、装置、服务器以及数据处理系统 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102646126A (zh) * | 2012-02-29 | 2012-08-22 | 浙江工商大学 | 一种基于元组不确定性的数据流有效聚类方法 |
CN103078754B (zh) * | 2012-12-29 | 2016-09-28 | 大连环宇移动科技有限公司 | 一种基于计数型bloom filter的网络数据流统计方法 |
-
2013
- 2013-06-07 CN CN201310227114.5A patent/CN103346901B/zh not_active Expired - Fee Related
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105141472A (zh) * | 2015-08-07 | 2015-12-09 | 北京思特奇信息技术股份有限公司 | 一种基于异或运算的流计算跟踪方法及系统 |
WO2017049861A1 (zh) * | 2015-09-25 | 2017-03-30 | 中兴通讯股份有限公司 | 数据处理状态监控方法和装置 |
CN106559278A (zh) * | 2015-09-25 | 2017-04-05 | 中兴通讯股份有限公司 | 数据处理状态监控方法和装置 |
US10680974B2 (en) | 2015-09-25 | 2020-06-09 | Zte Corporation | Method and device for monitoring data processing status |
CN106559278B (zh) * | 2015-09-25 | 2020-09-15 | 中兴通讯股份有限公司 | 数据处理状态监控方法和装置 |
WO2021212385A1 (zh) * | 2020-04-22 | 2021-10-28 | 深圳市欢太科技有限公司 | 数据检测方法、装置、服务器以及数据处理系统 |
Also Published As
Publication number | Publication date |
---|---|
CN103346901B (zh) | 2016-01-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220156259A1 (en) | Dynamically resizable structures for approximate membership queries | |
US11869586B2 (en) | Increased data protection by recovering data from partially-failed solid-state devices | |
US20160140253A1 (en) | Platform for Continuous Graph Update and Computation | |
US11341136B2 (en) | Dynamically resizable structures for approximate membership queries | |
US20200401316A1 (en) | Replication across partitioning schemes in a distributed storage system | |
CN103607304B (zh) | 一种基于纠删码的失效数据线形修复方法 | |
US11194473B1 (en) | Programming frequently read data to low latency portions of a solid-state storage array | |
US11662909B2 (en) | Metadata management in a storage system | |
CN106663030A (zh) | 在分布式集群中的可扩展故障恢复通信 | |
CN103581332B (zh) | HDFS架构及HDFS架构中NameNode节点的压力分解方法 | |
DE112020003277T5 (de) | Erzeugen von tags für die datenzuweisung | |
US11893126B2 (en) | Data deletion for a multi-tenant environment | |
US11899582B2 (en) | Efficient memory dump | |
CN103810061A (zh) | 一种高可用云存储方法 | |
US11249831B2 (en) | Intelligent durability acknowledgment in a storage system | |
CN103346901A (zh) | 一种面向数据流处理的元组跟踪方法及系统 | |
US20220327208A1 (en) | Snapshot Deletion Pattern-Based Determination of Ransomware Attack against Data Maintained by a Storage System | |
CN109284518A (zh) | 一种乐观时间管理方法及装置 | |
US11159387B1 (en) | Systems and methods for visualization based on historical network traffic and future projection of infrastructure assets | |
CN109344009A (zh) | 基于分级检查点的移动云系统容错方法 | |
CN108733307B (zh) | 存储管理方法、设备以及计算机可读介质 | |
US20210326225A1 (en) | Intelligent access to a storage device | |
US20210397599A1 (en) | Techniques for generating a consistent view of an eventually consistent database | |
CN104102558A (zh) | 一种基于纠删码的文件追加方法 | |
CN101986602B (zh) | 基于报文数目检验无阻塞检查点设置和故障进程恢复方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20160120 |