CN111159140A - 数据处理方法、装置、电子设备及存储介质 - Google Patents

数据处理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN111159140A
CN111159140A CN201911422019.4A CN201911422019A CN111159140A CN 111159140 A CN111159140 A CN 111159140A CN 201911422019 A CN201911422019 A CN 201911422019A CN 111159140 A CN111159140 A CN 111159140A
Authority
CN
China
Prior art keywords
data
redis
key value
value pair
hadoop
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
Application number
CN201911422019.4A
Other languages
English (en)
Other versions
CN111159140B (zh
Inventor
李宗祥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Migu Cultural Technology Co Ltd
China Mobile Communications Group Co Ltd
Original Assignee
Migu Cultural Technology Co Ltd
China Mobile Communications Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Migu Cultural Technology Co Ltd, China Mobile Communications Group Co Ltd filed Critical Migu Cultural Technology Co Ltd
Priority to CN201911422019.4A priority Critical patent/CN111159140B/zh
Publication of CN111159140A publication Critical patent/CN111159140A/zh
Application granted granted Critical
Publication of CN111159140B publication Critical patent/CN111159140B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/172Caching, prefetching or hoarding of files

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例公开了一种数据处理方法、装置、电子设备及存储介质,本发明实施例将数据加载进Hadoop文件并按列进行存储,使得在Redis中能够建立面向列索引的存储方式,从而可以优化Redis的存储性能。本发明实施例可以根据Redis中各个键值的访问频率,确定数据在Redis中的存储方式为数据还是数据在Hadoop文件中的访问地址,从而可以进一步优化Redis的存储空间,解决因数据量太大无法而放进Redis内存的问题。此外,本发明实施例根据Redis中各个键值的访问频率能够将热点数据留在Redis里,而将冷数据放在Hadoop上,这样可以提高数据访问效率。

Description

数据处理方法、装置、电子设备及存储介质
技术领域
本发明涉及计算机技术领域,具体涉及一种数据处理方法、装置、电子设备及存储介质。
背景技术
现今Hadoop凭借其处理数据的高效性和可靠性已成为企业处理大数据的主要工具。但是由于Hadoop并行批处理的特性,使Hadoop无法有效地适应共享数据的处理,例如树形索引的创建、PageRank等迭代算法的训练等。针对这个问题目前有如下处理方法:
第一种是基于Hadoop的文件系统。在Hadoop中HDFS负责存储与管理数据。HDFS即Hadoop分布式文件系统,它是主/从结构的,由一个NameNode节点和多个DataNode节点组成。HDFS中数据被分散地存储在HDFS的各个DataNode(数据节点)中。对于共享数据可将其存放在HDFS上的一个文件里,在Hadoop运行任务时通过在程序中设置指定路径来访问这个共享数据的文件,以获取所需要的数据。
第二种是基于Hadoop的分布式缓存。Hadoop自身提供了基于内存的分布式缓存功能。当共享数据量比较小的时候可以将共享数据放入Hadoop的分布式缓存中,在运行MapReduce任务时HDFS将分布式缓存中的数据写入的分布式共享文件进行存储,并将分布式共享文件发送给Hadoop集群中的每一个节点,每个节点会将分布式共享文件的副本存入自己的内存中,从而使Hadoop集群在运行时每个节点上的任务都可以高效地访问共享数据。
第三种是基于Redis的分布式缓存。Redis是一种基于key/value存储形式的分布式内存数据库,基于Redis的分布式缓存方法将共享数据以key/value的形式存储在Redis集群中,当Hadoop运行任务时会通过Jedis客户端从Redis中获取所需要的共享数据,依托Redis的分布性与集群性可以高效地访问共享数据。
然而,在实际应用中由于共享数据的量级和复杂程度都是不断增长与变化的,在这种情况下,上面所述的几种方法存在以下问题:
首先,数据量过大的问题。实际应用中的共享数据量可能会很大,当数据量非常大,例如每月有10亿条左右时,不适用于Hadoop分布式缓存,即使使用Redis集群后续也可能会因为数据量的增长而存不进内存,导致无法进行处理。
其次,数据的访问效率问题。针对共享数据量过大的情况,如果直接使用Hadoop的文件系统将会产生大量的磁盘I/O操作,从而降低数据处理的效率;此外,行存储的形式下如果数据的维度很多(即数据的列很多)但真正使用到的又很少,就会读取大量无用的数据,降低数据的传输与处理效率,即便使用Redis处理,也会使Redis成为系统处理的瓶颈。
发明内容
由于现有方法存在上述问题,本发明实施例提出一种数据处理方法、装置、电子设备及存储介质。
具体地,本发明实施例提供了以下技术方案:
第一方面,本发明实施例提供了一种数据处理方法,包括:
将数据加载进Hadoop文件并按列进行存储;
从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;
其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
进一步地,所述根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式,具体包括:
在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将对应的第二数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中。
进一步地,所述在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将对应的第二数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中,具体包括:
在每个查询周期,若键值对为第一类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若是,则更新键值对的失效时间,否则,重新生成新键值对替代旧键值对,该新键值对中只包含第二数据在Hadoop文件中的访问地址;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
若键值对为第二类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若否,则更新键值对的失效时间;若是,则重新生成新键值对替代旧键值对,该新键值对中只包含第一数据;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
其中,第一类型键值对为存储有第一数据的键值对,第二类型键值对为存储有第二数据在Hadoop文件中的访问地址的键值对。
进一步地,所述将数据加载进Hadoop文件并按列进行存储,具体包括:
将数据加载进Hadoop文件,并将数据按列进行归并后写入Block中,其中,一个Block只写一个列的列数据。
进一步地,所述将生成的键值对对应写入Redis中,具体包括:
根据第一关系模型确定每个键值对在Redis中的存储位置,所述第一关系模型为Loc=(crc16(key)+h%n)%16384;
根据确定的存储位置,将键值对对应写入Redis中;
其中,Loc表示需写入的键值对在Redis中的存储位置,key表示需写入的键值对的键值,crc16()表示将key转换为整数值的函数,%表示求模操作,h表示需写入的列数据对应的索引树的深度,n表示Redis的节点个数。
进一步地,所述数据处理方法,还包括:
将Redis中的任务队列分为任务执行队列和任务等待队列;其中,任务执行队列中的任务用于被依次执行;所述任务等待队列包括多个处于任务等待状态的队列,每个处于任务等待状态的队列与一个列数据相对应,只接收访问相应列数据的访问任务;
根据任务入队次序和任务读写类型对每个处于任务等待状态的队列进行排序,其中,先入队任务排列在后入队任务前面,读写任务排列在只读任务前面;
所述任务执行队列随机从多个处于等待状态的队列中选取队头任务进队。
进一步地,在将数据加载进Hadoop文件并按列进行存储之前,所述方法还包括:
在同一物理机上部署Hadoop与Redis,并在Hadoop和Redis之间设置数据访问接口,通过所述数据访问接口实现Hadoop与Redis之间的数据交互。
第二方面,本实施例还提供了一种数据处理装置,包括:
加载模块,用于将数据加载进Hadoop文件并按列进行存储;
读取模块,用于从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
处理模块,用于根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;
其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
第三方面,本发明实施例还提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如第一方面所述的数据处理方法。
第四方面,本发明实施例还提供了一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如第一方面所述的数据处理方法。
由上述技术方案可知,本发明实施例提供的数据处理方法、装置、电子设备及存储介质,本发明实施例将数据加载进Hadoop文件并按列进行存储,使得在Redis中能够建立面向列索引的存储方式,因而能够优化Redis的存储性能,同时由于在Redis中建立了面向列索引的存储方式,因此在需要获取相应的列数据时,可以直接在Redis中访问相应的列数据,因此可以提高数据访问效率。此外,本发明实施例根据Redis中各个键值的访问频率,确定数据在Redis中的存储方式为数据还是数据在Hadoop文件中的访问地址,从而可以进一步优化Redis的存储空间,解决因数据量太大无法而放进Redis内存的问题。此外,根据Redis中各个键值的访问频率能够将热点数据留在Redis里,而将冷数据放在Hadoop上,这样能够提高数据访问效率。由此可见,本发明实施例提供的数据处理方法尤其适用于数据量较大的共享数据应用场合。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些图获得其他的附图。
图1是本发明一实施例提供的数据处理方法的流程图;
图2是本发明一实施例提供的Redis中索引的逻辑结构示意图;
图3是本发明一实施例提供的索引节点的逻辑图;
图4是本发明一实施例提供的缓存替换策略示意图;
图5是本发明一实施例提供的将数据从Hadoop写入Redis的处理流程图;
图6是本发明一实施例提供的数据互斥访问方法的总体构思示意图;
图7是本发明一实施例提供的数据互斥访问方法的实现流程图;
图8是本发明一实施例提供的Hadoop与Redis两个集群的部署方式示意图;
图9是本发明一实施例提供的数据处理方法的实现过程示意图;
图10是本发明一实施例提供的数据处理装置的结构示意图;
图11是本发明一实施例提供的电子设备的结构示意图。
具体实施方式
下面结合附图,对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案,而不能以此来限制本发明的保护范围。
图1示出了本发明一实施例提供的数据处理方法的流程图,如图1所示,本发明实施例提供的数据处理方法,具体包括如下内容:
步骤101:将数据加载进Hadoop文件并按列进行存储;
在本步骤中,在Hadoop中建立一个文件,并将共享数据加载进这个文件中,接着对加载进Hadoop文件的数据按列进行归并,以便于后续在Redis中可以建立面向列索引的存储方式。
步骤102:从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
在本步骤中,将Hadoop中的数据按列加载进Redis并进行索引构建。由于数据在Hadoop文件按列存储,因此可以在Redis中建立面向列索引的存储方式,从而可以优化Redis的存储性能。由此可见,本步骤解决了现有技术中面向行索引的存储方式的缺陷,需要说明的是,对于面向行索引的存储方式,当数据维度很多(即数据的列很多)但真正使用到的又很少时,会读取大量无用的数据,降低数据的传输与处理效率,使Redis成为系统处理的瓶颈。而本步骤直接面向有用的列数据建立索引,因此不存在现有技术中的问题。
在本步骤中,在建立面向Redis的列索引结构时,由于Redis以Key-Value键值对的形式存储数据,因此本实施例设计的索引结构也是以Key-Value键值对的形式进行存储的。本实施例设计以列的形式在Redis中存储数据,在系统启动时将Hadoop中的共享数据按列加载进Redis并进行索引构建,Redis中索引的逻辑结构如图2所示。参见图2可知,在建立面向Redis的列索引结构时,每个列都会对应不同的键值对。例如图2中“列1-Key1”就是列1的键值对,这个键值对中只包含有“列1”的数据。本实施例设计了面向Redis的索引结构,在索引中有些节点直接存储共享数据,而有些节点则是只是存储数据在Hadoop中的访问地址,哪些数据该存储在节点里、哪些数据该存储在Hadoop里将由步骤103介绍的缓存替换策略来进行管理。Hadoop中数据按列存储,如图中的“列1-Block1”只存储列1的数据,每个Block只存储一个列的数据,这样可以加速数据的读取,每次只读取需要用到的列数据。
在本步骤中,需要说明的是,本实施例设计的索引节点的存储结构如下所示:
Key=<原文件名称>,<列名称>,<节点编号>,<节点类型>
Value=<数据的值>,<下层节点的指针>
其中,Key中包含了原文件名称、列名称、节点编号和节点类型这四种信息,其中节点编号取节点能存储的最大值减1,如图3所示的逻辑图中<1,3,7>这个节点的编号就是9;节点类型用来标识节点有没有存储数据。Value则只是存储列的数据值或者数据值的访问地址,以及下层节点的指针(即下层节点的访问地址)。
步骤103:根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
在本步骤中,为进一步优化Redis的存储空间,在Redis中引入了新的数据存储方式,也即有的键值对存储的为数据,有的键值对存储的为数据在Hadoop中的访问地址,这样做能够解决因数据量太大共享数据无法放进Redis内存的问题。本步骤根据Redis中各个键值的访问频率可以将作为热点数据的第一数据留在Redis里,而将作为冷数据的第二数据放在Hadoop上,这样访问次数多的热点数据在Redis中,从而不但可以优化Redis内存的存储空间,而且还可以提高访问效率。由于冷数据访问次数较少,因此冷数据存储在Hadoop中不会对整个数据访问的吞吐量造成太大影响。
在本步骤中,需要说明的是,在Hadoop运行任务时,有些数据经常被访问而有些数据很少被访问,因此,将那些访问频繁的数据即热点数据保存在Redis内存中,可以有效保证数据读取的效率。基于此,本实施例设计了两种存储方式:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址。其中,第一数据为访问频率满足预设条件的键值对对应的数据(也即热点数据),第二数据为访问频率不满足预设条件的键值对对应的数据(也即冷数据)。也即在本实施例中,数据存储结构包含两个部分,一部分数据将存储在Redis中,另一部分数据将存储在Hadoop中。这种处理不但可以解决因数据量太大无法而放进Redis内存的问题,而且由于将热点数据存储在Redis中,还可以提高访问效率。
在本步骤中,需要说明的是,在建立面向Redis的列索引结构时,逻辑上每个列数据都对应一个类似B-Tree/B+-Tree的索引,树中的每个节点都对应一个Key-Value键值对。不过本实施例设计的索引与B-Tree/B+-Tree的索引的区别就在于本实施例中的索引有的是存储了真实共享数据,有的只是存储了共享数据在Hadoop中的访问地址,这样做是为了解决数据量太大无法放进Redis内存时,可以通过缓存替换策略将热点数据留在Redis里,而将冷数据放在Hadoop上,这样访问次数多的热点数据在Redis中具有较高的访问效率,而访问次数少的冷数据在Hadoop中,由于冷数据访问次数较少所以对整个共享数据访问的吞吐量也不会有太大的影响。
可以理解的是,本实施例设计每个键值对所存储数据的大小最好不超过64KB,即某个节点对应的键值对存储的数据量大于64KB时则进行树节点的分裂,这么做是因为Hadoop集群传输的最小数据量单位就是64KB,这样可以提升网络传输速率,当然,本实施例对此不作限定,根据需要每个键值对所存储数据的大小可以自行设定。
由上述技术方案可知,本发明实施例提供的数据处理方法,将数据加载进Hadoop文件并按列进行存储,使得在Redis中能够建立面向列索引的存储方式,因而能够优化Redis的存储性能,同时由于在Redis中建立了面向列索引的存储方式,因此在需要获取相应的列数据时,可以直接在Redis中访问相应的列数据,因此可以提高数据访问效率。此外,本发明实施例根据Redis中各个键值的访问频率,确定数据在Redis中的存储方式为数据还是数据在Hadoop文件中的访问地址,从而可以进一步优化Redis的存储空间,解决因数据量太大无法而放进Redis内存的问题。此外,根据Redis中各个键值的访问频率能够将热点数据留在Redis里,而将冷数据放在Hadoop上,这样能够提高数据访问效率。由此可见,本发明实施例提供的数据处理方法尤其适用于数据量较大的共享数据应用场合。
进一步地,基于上面所述的实施例内容,在本实施例中,所述根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式,具体包括:
在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将第二数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中。
在本实施例中,查询周期可以为每小时,每天等,本实施例对此不作限定。在本实施例中,访问频率满足预设条件可以指访问频率大于预设阈值或访问频率处于第一预设范围内等等。访问频率满足不预设条件可以指访问频率小于或等于预设阈值或访问频率处于第二预设范围内等等。其中,第一预设范围内的数值大于第二预设范围内的数值。
在本实施例中,设计了一种缓存替换策略,根据数据的冷热进行替换,将Redis中不常用的数据移动至Hadoop中,并将Hadoop中访问热度很高的共享数据加载进Redis,以保持Redis中尽可能多的存储热点数据以优化数据访问效率。
进一步地,基于上面所述的实施例内容,在本实施例中,所述在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中,具体包括:
在每个查询周期,若键值对为第一类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若是,则更新键值对的失效时间,否则,重新生成新键值对替代旧键值对,该新键值对中只包含第二数据在Hadoop文件中的访问地址;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
若键值对为第二类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若否,则更新键值对的失效时间;若是,则重新生成新键值对替代旧键值对,该新键值对中只包含第一数据;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
其中,第一类型键值对为存储第一数据的键值对,第二类型键值对为存储第二数据在Hadoop文件中的访问地址的键值对。
在本实施例中,以键值对Key-Value为缓存替换的基本单位,统计键值对在某个时间周期(即轮询周期)内的访问频率,每个键值对都设置一个失效时间使键值对在一段时间后自动失效,设置某一阈值作为区分数据冷热的分界线,即在失效时间内键值对的访问次数大于该阈值则视为热点数据,小于或等于该阈值则视为冷数据。如图4所示,本实施例提供的缓存替换策略实现方式如下:
S1、设置系统需要的相应参数,包括键值对的失效时间、判断数据冷热的阈值、以及轮询周期等。在本实施例中,设置的轮询周期稍微小于失效时间,这样可以使那些变更为冷数据的索引节点在一次轮询后可以很快地自动销毁;这里的轮询周期稍微小于失效时间是指轮询周期和失效时间的差值小于某一较小值(如5s)。
S2、按照设定的轮询周期,每隔固定时间计算该周期内系统中键值对的访问频率,以支撑缓存替换策略;
S3、进行键值对的类型判断,如果键值对所对应的节点存储了数据则转S4,如果键值对所对应的节点存储的只是数据的地址则转S5;
S4、得出当前键值对所对应的节点为存储数据的节点,进行阈值判断,判断在这个轮询周期内该键值对的访问频率是否大于阈值,如果是则转S6,如果否则转S7;
S5、得出当前键值对所对应的节点为存储数据地址的节点,进行阈值判断,判断在这个轮询周期内该键值对的访问频率是否大于阈值,如果是则转S8,如果否则转S9;
S6、因为当前节点存储了数据且访问频率大于阈值,所以该节点已经存储热点数据不需要进行操作,只需设置新的失效时间等待下一次轮询即可;
S7、因为当前节点存储了数据且访问频率小于阈值,所以该节点的数据为冷数据,取该节点数据的地址重新生成一个新的节点替代它挂接在索引里,而原先的节点不做处理,等失效时间到了Redis会自动回收;
S8、因为当前节点存储的只是数据地址且访问频率大于阈值,因此需要将Hadoop中的相应数据加载至Redis内存,也是生成一个新节点来替换老的节点,而老的节点则等其失效时间到了就会被Redis回收;
S9、因为当前节点只存储了数据地址且访问频率小于或等于阈值,所以该节点已经存储热点数据不需要操作,只需设置新的失效时间等待下一次轮询即可;
S10、在系统轮询完一次后则可等待下一次轮询。
由此可见,本实施例设计了一种Redis缓存替换策略,将那些Redis中不常用的数据清除,并将Hadoop中访问热度很高的共享数据加载进Redis,用来保证热点共享数据的访问效率。
进一步地,基于上面所述的实施例内容,在本实施例中,所述将数据加载进Hadoop文件并按列进行存储,具体包括:
将数据加载进Hadoop文件,并将数据按列进行归并,同时将归并好的列数据写入Block中,其中,一个Block只写一个列的列数据。
在本实施例中,先在Hadoop中建立一个文件,然后将数据加载进这个文件。接着对加载进Hadoop文件的数据按列进行归并,将归并好的列数据写入相应的Block中,其中,一个Block只写一个列的数据,需要说明的是,本实施例设计了Hadoop中面向列的Block存储方式,使每个Block只存储同一个列的数据,这样可以优化列数据的读取效率,进而可以提升Hadoop中共享数据的读写效率。
在本实施例中,如图5所示的流程图,在将数据从Hadoop写入Redis时,可以读取各个列的第一个Block的数据,并将读取的各个列的Block的数据生成键值对,写入Redis集群中,然后根据所读取的Block中的数据构建索引,在这步创建的所有节点都包含数据,此外可以根据索引的深度计算键值对的存储位置进行存储,关于这部分内容后面实施例会有相应介绍。
进一步地,基于上面所述的实施例内容,在本实施例中,所述将生成的键值对写入Redis中,具体包括:
根据第一关系模型确定每个键值对在Redis中的存储位置,所述第一关系模型为Loc=(crc16(key)+h%n)%16384;
根据确定的存储位置,将键值对对应写入Redis中;
其中,Loc表示需写入的键值对在Redis中的存储位置,key表示需写入的键值对的键值,crc16()表示将key转换为整数值的函数,%表示求模操作,h表示需写入的列数据对应的索引树的深度,n表示Redis的节点个数。
在本实施例中,由于不同的列数据量的大小可能不同,因此,本实施例改进了Redis自身的数据分布策略,使得能够在总体上保证所有键值对均匀分布的同时,还可以保证每个列所对应的键值对可以在Redis集群中均匀分布。
在本实施例中,假设每个列数据对应的索引树的深度是h,Redis的节点个数为n,则每个键值Key在Redis中的存储位置由如下公式求出:
Loc=(crc16(key)+h%n)%16384
其中,Redis使用crc16算法将key转换为一个整数值,再对Redis的槽数16384(Key存储在Redis的槽中)求模来得到数据的存储位置,本实施例在计算存储位置时考虑了树的深度,因为树的深度越大就说明列数据就越多,因此考虑深度后可以使那些数据量大的键值对分散存储的效果更好,因为h越大存储位置移动的也越大,数据会更分散。用h%n是为了减少数据存储位置移动后与之前位置重合的概率。由此可见,本实施例针对Redis中的数据设计了一种面向索引的数据分布方法,有效地应对了不同列数据量不同的问题,根据索引将共享数据均匀地分布存储在Redis集群中,以保证Redis存储的负载均衡,避免某个Redis节点因成为访问热点而降低系统的数据访问效率。
进一步地,需要说明的是,现有技术中的基于Hadoop的文件系统、基于Hadoop的分布式缓存以及基于Redis的分布式缓存,均不能很好的应对任务运行过中共享数据改变的问题。例如,HDFS不支持对文件的随机写,无法做到共享数据的实时修改;而基于Redis的共享数据存储方法也只是在一轮MapReduce任务结束后才去更新共享数据,无法在运行过程中更新共享数据。针对该问题,本实施例提出一种整合Hadoop与Redis的共享数据处理方法,使其能够在Hadoop任务运行时能实时更改共享数据的状态。因此,基于上面所述的实施例内容,为了保证在Hadoop运行任务的过程中可以正确地实时更改数据状态,本实施例改造了Redis的任务等待队列,设计了一种数据互斥访问方法,可以有效解决共享数据状态更改的问题。在本实施例中,所述数据处理方法,还包括:
将Redis中的任务队列分为任务执行队列和任务等待队列;其中,任务执行队列中的任务用于被依次执行;所述任务等待队列包括多个处于任务等待状态的队列,每个处于任务等待状态的队列与一个列数据相对应,只接收访问相应列数据的访问任务;
根据任务入队次序和任务读写类型对每个处于任务等待状态的队列进行排序,其中,先入队任务排列在后入队任务前面,读写任务排列在只读任务前面;
所述任务执行队列随机从多个处于等待状态的队列中选取队头任务进队。
在本实施例中,需要说明的是,为了保证在Hadoop运行任务的过程中可以正确地实时更改数据状态,本实施例改造了Redis的任务等待队列,设计了一种数据互斥访问方法,可以有效解决共享数据状态更改的问题。在本实施例中,数据互斥访问方法在每个Redis节点上均被执行,数据互斥访问方法的总体构思如图6所示:本实施例将Redis原有的任务队列拆分成两部分,一部分是任务执行队列,如图6右边所示,该队列中的任务都会被依次执行;另一部分是任务等待队列,任务根据自己入队的次序等待进入执行队列。本实施例设计了面向列数据访问的任务队列,每个任务会进入它所要访问数据的列队列里,如图6所示,列1-队列只接收访问列1数据的任务,而列2-队列则只接收访问列2数据的任务,而执行队列会随机调取任务等待队列队头的任务进队,这样可以平衡每个获取不同列数据任务等待的时间,避免出现某个任务等待太久的情况。此外,本实施例根据Redis的特性将任务分为两类即只读任务和读写任务,只读任务只是单纯的读取数据,而读写任务不仅要读出数据还要更改原先的数据,对于同一批次提交的任务除了根据任务入队的次序外还要使读写任务排在只读任务前面,这样可以保证数据先改后读,避免了读脏数据;数据互斥访问方法的执行步骤如图7所示:
S1、不同Hadoop节点上的执行任务分别发出Redis请求任务,请求任务包含了只读任务和读写任务;
S2、每个请求任务根据各自访问的列数据进入列等待队列中,并以到达时间的先后顺序为权重排序,其中读写任务要排在只读任务前面;
S3、执行队列随机选取不同列等待队列的队头任务入队,等待执行;
S4、执行队列中的任务按进入队列的顺序执行,完成任务。
进一步地,基于上面所述的实施例内容,在本实施例中,在将数据加载进Hadoop文件并按列进行存储之前,所述数据处理方法还包括:
在同一物理机上部署Hadoop与Redis,并在Hadoop和Redis之间设置数据访问接口,通过所述数据访问接口实现Hadoop与Redis之间的数据交互。
在本实施例中,需要说明的是,本实施例提供的存储结构整合了Hadoop与Redis两个集群。如图8所示,在图8所示的物理机器上同时部署Hadoop集群节点与Redis集群节点,此外可以通过编程方式实现一个数据访问接口,通过这个数据接口实现Hadoop集群节点与Redis集群几点之间的数据交互。之所以设计成上述的结构,一是为了充分利用集群资源,使Hadoop与Redis共用机器的内存,在Hadoop减少内存的使用时可以将节省的内存分配给Redis;二是因为Redis节点与Hadoop节点部署在同一台物理机器上可以使Hadoop直接从本机获取Redis节点的数据,减少网络通信,降低网络数据传输量。
下面结合图9所示流程图对本实施例提供的数据处理方法进行解释说明。如图9所示,本实施例提供的数据处理方法包括:
S1、先将数据加载进Hadoop并按列存储,之后将数据加载进Redis并构建索引,将共享数据均匀地分到Redis的各个节点中;
S2、Hadoop在执行任务的过程中可以通过数据接口访问Redis中的数据;
S3、在系统运行的过程中按照前面实施例介绍的缓存替换策略管理缓存数据,根据数据的冷热划分替换Redis缓存中的数据,保证Redis缓存中的大部分数据是热点访问的数据;
S4、在Hadoop执行任务过程中可以通过前面实施例介绍的数据互斥访问方法来对Redis中的数据做实时修改。
根据上面介绍的内容可知,本实施例设计的数据处理方法使用Redis来存储共享数据,但是与现有技术不同的是,本实施例在Redis中按列存储共享数据。此外,本实施例设计了一种面向Redis的列索引方法来优化共享数据的存储性能,同时本实施例设计一种缓存替换策略来保持访问数据的高效性,此外本实施例还设计了一种面向Redis的数据互斥访问方法以保证共享数据可以被正确地实时修改。具体来说,在Redis中,本实施例设计了一种面向列索引的数据存储方式,即本实施例先将共享数据按列归并,再对每个列的数据建立索引,同时本实施例设计一种分布方法可以根据索引将共享数据均匀地分布存储在Redis集群中,以保证Redis存储的负载均衡,避免某个Redis节点因成为访问热点而降低系统的数据访问效率。在Hadoop中,本实施例设计直接将全部共享数据进行文件存储,但是文件要按列进行存储且每个Block只能存储一个列的数据,以提升Hadoop中共享数据的读写效率。此外本实施例还设计一种Redis缓存替换策略,将那些Redis中不常用的数据清除,并将Hadoop中访问热度很高的共享数据加载进Redis,用来保证热点共享数据的访问效率。与此同时本实施例还设计了一种面向Redis索引的数据互斥访问方法以保证共享数据可以被正确地实时修改。由此可见,本实施例为一种整合了Hadoop与Redis的数据处理方法,本实施例提供的方法能够很好地应对共享数据量大的问题。
需要说明的是,在一些结算系统应用场合,需要使用鉴权日志来过滤CDN日志,基于一条鉴权只能匹配一条CDN的处理规则,本实施例将鉴权日志作为共享数据与CDN匹配,得出的结果表明本实施例的设计可以正确高效地处理这一类共享数据的问题。
图10示出了本发明实施例提供的数据处理装置的结构示意图。如图10所示,本发明实施例提供的数据处理装置包括:记载模块21、读取模块22和处理模块23,其中:
加载模块21,用于将数据加载进Hadoop文件并按列进行存储;
读取模块22,用于从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
处理模块23,用于根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;
其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
由于本实施例提供的数据处理装置,可以用于执行上述实施例提供的数据处理方法,其工作原理和有益效果类似,此处不再详述。
基于相同的发明构思,本发明又一实施例提供了一种电子设备,参见图11,所述电子设备具体包括如下内容:处理器301、存储器302、通信接口303和通信总线304;
其中,所述处理器301、存储器302、通信接口303通过所述通信总线304完成相互间的通信;所述通信接口303用于实现各设备之间的信息传输;
所述处理器301用于调用所述存储器302中的计算机程序,所述处理器执行所述计算机程序时实现上述数据处理方法的全部步骤,例如,所述处理器执行所述计算机程序时实现下述步骤:将数据加载进Hadoop文件并按列进行存储;从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
基于相同的发明构思,本发明又一实施例提供了一种非暂态计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器执行时实现上述数据处理方法的全部步骤,例如,所述处理器执行所述计算机程序时实现下述步骤:将数据加载进Hadoop文件并按列进行存储;从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
此外,上述的存储器中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的数据处理方法。
此外,在本发明中,诸如“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
此外,在本发明中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
此外,在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种数据处理方法,其特征在于,包括:
将数据加载进Hadoop文件并按列进行存储;
从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;
其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
2.根据权利要求1所述的数据处理方法,其特征在于,所述根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式,具体包括:
在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将对应的第二数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中。
3.根据权利要求2所述的数据处理方法,其特征在于,所述在每个查询周期,将Redis中访问频率不满足预设条件的键值对对应的第二数据存入Hadoop中,并将对应的第二数据在Hadoop文件中的访问地址存入Redis中;以及,在每个查询周期,将Hadoop文件中访问频率满足预设条件的键值对对应的第一数据存入Redis中,具体包括:
在每个查询周期,若键值对为第一类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若是,则更新键值对的失效时间,否则,重新生成新键值对替代旧键值对,该新键值对中只包含第二数据在Hadoop文件中的访问地址;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
若键值对为第二类型键值对,则判断在该查询周期内该键值对的访问频率是否大于预设阈值,若否,则更新键值对的失效时间;若是,则重新生成新键值对替代旧键值对,该新键值对中只包含第一数据;其中,当键值对的失效时间结束时Redis自动回收旧键值对;
其中,第一类型键值对为存储有第一数据的键值对,第二类型键值对为存储有第二数据在Hadoop文件中的访问地址的键值对。
4.根据权利要求1所述的数据处理方法,其特征在于,所述将数据加载进Hadoop文件并按列进行存储,具体包括:
将数据加载进Hadoop文件,并将数据按列进行归并后写入Block中,其中,一个Block只写一个列的列数据。
5.根据权利要求1所述的数据处理方法,其特征在于,所述将生成的键值对对应写入Redis中,具体包括:
根据第一关系模型确定每个键值对在Redis中的存储位置,所述第一关系模型为Loc=(crc16(key)+h%n)%16384;
根据确定的存储位置,将键值对对应写入Redis中;
其中,Loc表示需写入的键值对在Redis中的存储位置,key表示需写入的键值对的键值,crc16()表示将key转换为整数值的函数,%表示求模操作,h表示需写入的列数据对应的索引树的深度,n表示Redis的节点个数。
6.根据权利要求1所述的数据处理方法,其特征在于,还包括:
将Redis中的任务队列分为任务执行队列和任务等待队列;其中,任务执行队列中的任务用于被依次执行;所述任务等待队列包括多个处于任务等待状态的队列,每个处于任务等待状态的队列与一个列数据相对应,只接收访问相应列数据的访问任务;
根据任务入队次序和任务读写类型对每个处于任务等待状态的队列进行排序,其中,先入队任务排列在后入队任务前面,读写任务排列在只读任务前面;
所述任务执行队列随机从多个处于等待状态的队列中选取队头任务进队。
7.根据权利要求1所述的数据处理方法,其特征在于,在将数据加载进Hadoop文件并按列进行存储之前,所述方法还包括:
在同一物理机上部署Hadoop与Redis,并在Hadoop和Redis之间设置数据访问接口,通过所述数据访问接口实现Hadoop与Redis之间的数据交互。
8.一种数据处理装置,其特征在于,包括:
加载模块,用于将数据加载进Hadoop文件并按列进行存储;
读取模块,用于从Hadoop文件中读取各个列数据,根据各个列数据生成与各个列数据对应的键值对,并将生成的键值对对应写入Redis中;
处理模块,用于根据Redis中各个键值的访问频率,调整各个键值对在Redis中的存储方式;其中,所述存储方式包括:第一存储方式和第二存储方式;第一存储方式是指在Redis中存储第一数据;第二存储方式是指在Redis中存储第二数据在Hadoop文件中的访问地址;
其中,第一数据为访问频率满足预设条件的键值对对应的数据,第二数据为访问频率不满足预设条件的键值对对应的数据。
9.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现如权利要求1至7任一所述的数据处理方法。
10.一种非暂态计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1至7任一所述的数据处理方法。
CN201911422019.4A 2019-12-31 2019-12-31 数据处理方法、装置、电子设备及存储介质 Active CN111159140B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911422019.4A CN111159140B (zh) 2019-12-31 2019-12-31 数据处理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911422019.4A CN111159140B (zh) 2019-12-31 2019-12-31 数据处理方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN111159140A true CN111159140A (zh) 2020-05-15
CN111159140B CN111159140B (zh) 2023-09-19

Family

ID=70560614

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911422019.4A Active CN111159140B (zh) 2019-12-31 2019-12-31 数据处理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN111159140B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112068956A (zh) * 2020-08-24 2020-12-11 北京首汽智行科技有限公司 一种基于redis缓存的负载均衡方法及服务器
CN112487326A (zh) * 2020-11-27 2021-03-12 杭州安恒信息技术股份有限公司 数据缓存方法、系统、存储介质及设备
CN113177090A (zh) * 2021-04-30 2021-07-27 中国邮政储蓄银行股份有限公司 数据处理方法及装置
CN118250295A (zh) * 2024-05-28 2024-06-25 北京科杰科技有限公司 一种多网络环境的访问对象存储方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102915365A (zh) * 2012-10-24 2013-02-06 苏州两江科技有限公司 基于Hadoop的分布式搜索引擎构建方法
CN103366015A (zh) * 2013-07-31 2013-10-23 东南大学 一种基于Hadoop的OLAP数据存储与查询方法
US20150193491A1 (en) * 2012-09-24 2015-07-09 Huawei Technologies Co., Ltd. Data indexing method and apparatus
CN108111600A (zh) * 2017-12-20 2018-06-01 山东浪潮云服务信息科技有限公司 一种数据管理方法和智能运维平台
WO2019071055A1 (en) * 2017-10-04 2019-04-11 Fractal Industries, Inc. IMPROVING A DISTRIBUABLE DISTRIBUTED DATA MODEL
CN109871367A (zh) * 2019-02-28 2019-06-11 江苏实达迪美数据处理有限公司 一种基于Redis和HBase的分布式冷热数据分离方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150193491A1 (en) * 2012-09-24 2015-07-09 Huawei Technologies Co., Ltd. Data indexing method and apparatus
CN102915365A (zh) * 2012-10-24 2013-02-06 苏州两江科技有限公司 基于Hadoop的分布式搜索引擎构建方法
CN103366015A (zh) * 2013-07-31 2013-10-23 东南大学 一种基于Hadoop的OLAP数据存储与查询方法
WO2019071055A1 (en) * 2017-10-04 2019-04-11 Fractal Industries, Inc. IMPROVING A DISTRIBUABLE DISTRIBUTED DATA MODEL
CN108111600A (zh) * 2017-12-20 2018-06-01 山东浪潮云服务信息科技有限公司 一种数据管理方法和智能运维平台
CN109871367A (zh) * 2019-02-28 2019-06-11 江苏实达迪美数据处理有限公司 一种基于Redis和HBase的分布式冷热数据分离方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DA-WEI ZHANG; FU-QUAN SUN; XU CHENG;ET.AL.: "Research on hadoop-based enterprise file cloud storage system" *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112068956A (zh) * 2020-08-24 2020-12-11 北京首汽智行科技有限公司 一种基于redis缓存的负载均衡方法及服务器
CN112487326A (zh) * 2020-11-27 2021-03-12 杭州安恒信息技术股份有限公司 数据缓存方法、系统、存储介质及设备
CN112487326B (zh) * 2020-11-27 2024-03-19 杭州安恒信息技术股份有限公司 数据缓存方法、系统、存储介质及设备
CN113177090A (zh) * 2021-04-30 2021-07-27 中国邮政储蓄银行股份有限公司 数据处理方法及装置
CN118250295A (zh) * 2024-05-28 2024-06-25 北京科杰科技有限公司 一种多网络环境的访问对象存储方法
CN118250295B (zh) * 2024-05-28 2024-07-23 北京科杰科技有限公司 一种多网络环境的访问对象存储方法

Also Published As

Publication number Publication date
CN111159140B (zh) 2023-09-19

Similar Documents

Publication Publication Date Title
JP6560308B2 (ja) データ記憶サービスを実装するシステム及び方法
CN111159140A (zh) 数据处理方法、装置、电子设备及存储介质
US20240004834A1 (en) Directory structure for a distributed storage system
Băzăr et al. The Transition from RDBMS to NoSQL. A Comparative Analysis of Three Popular Non-Relational Solutions: Cassandra, MongoDB and Couchbase.
US20240061812A1 (en) Metadata control in a load-balanced distributed storage system
CN108616581B (zh) 基于olap/oltp混合应用的数据存储系统及方法
US9984139B1 (en) Publish session framework for datastore operation records
CN107368260A (zh) 基于分布式系统的存储空间整理方法、装置及系统
CN104735110A (zh) 元数据管理方法和系统
US11960442B2 (en) Storing a point in time coherently for a distributed storage system
US20170270149A1 (en) Database systems with re-ordered replicas and methods of accessing and backing up databases
Ma et al. Dependency-aware data locality for MapReduce
CN111930716A (zh) 一种数据库扩容方法、装置及系统
CN112965939A (zh) 一种文件合并方法、装置和设备
CN115840731A (zh) 文件处理方法、计算设备及计算机存储介质
CN108153759B (zh) 一种分布式数据库的数据传输方法、中间层服务器及系统
US11429311B1 (en) Method and system for managing requests in a distributed system
CN107948229A (zh) 分布式存储的方法、装置及系统
CN107102898B (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
CN105279166A (zh) 文件管理方法和系统
CN112988696B (zh) 文件整理方法、装置及相关设备
Ge et al. Cinhba: A secondary index with hotscore caching policy on key-value data store
ELomari et al. New data placement strategy in the HADOOP framework
CN112860694B (zh) 业务数据的处理方法、装置及设备
US11816088B2 (en) Method and system for managing cross data source data access requests

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant