CN107092604A - 一种文件处理方法和装置 - Google Patents
一种文件处理方法和装置 Download PDFInfo
- Publication number
- CN107092604A CN107092604A CN201610091248.2A CN201610091248A CN107092604A CN 107092604 A CN107092604 A CN 107092604A CN 201610091248 A CN201610091248 A CN 201610091248A CN 107092604 A CN107092604 A CN 107092604A
- Authority
- CN
- China
- Prior art keywords
- file
- combined
- bit array
- merging
- read
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
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
本发明实施例公开了一种文件处理方法,包括:获取至少两个文件;在获取的文件满足文件合并条件时,将满足文件合并条件的各个文件进行合并,得出合并文件;将合并文件以BloomMapFile形式进行存储。本发明实施例还公开了一种文件处理装置。
Description
技术领域
本发明涉及数据业务技术,尤其涉及一种文件处理方法和装置。
背景技术
随着互联网技术的高速发展以及数字化信息的不断增加,信息的存储问题已经成为当下最为关注的焦点之一;目前对于这类文件数据的存储主要是通过部署分布式文件系统来进行管理,国内外有多款分布式文件系统,例如Google File System(GFS)、HadoopDistributed File System(HDFS)、Lustre、Fast Distributed File System(FDFS)等。其中,HDFS是Hadoop中最为重要的组件之一,HDFS作为分布式文件系统,其发展速度和应用领域越发受到关注。
文件存储于HDFS必然会产生相应的元数据,现有技术方案均是将元数据存储于Namenode节点,当需要访问储存的文件时Namenode需读取所有的元数据并选出访问文件的元数据信息,从而访问相应文件。
如此,访问储存的文件时,Namenode需读取所有的元数据并选出访问文件的元数据信息,Namenode节点的内存访问压力大,判断小文件是否存在时需扫描Namenode节点的所有元数据,耗时较长,文件读取效率不高。
发明内容
为解决上述技术问题,本发明实施例期望提供一种文件处理方法和装置,使得在访问储存的文件时,缓解Namenode节点的工作压力,同时提高了小文件的处理速度以及存取效率。
本发明实施例提供了一种文件处理方法,该方法包括:
获取至少两个文件;
将满足文件合并条件的各个文件进行合并,得出合并文件;
将合并文件以BloomMapFile形式进行存储。
上述方案中,所述将满足文件合并条件的各个文件进行合并,得出合并文件,包括:对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件。
上述方案中,所述利用BloomFilter实现各个待合并文件的合并,包括:启动MapReduce任务将对应类别的各个待合并文件合并。
上述方案中,在将合并文件以BloomMapFile形式进行存储之后,所述方法还包括:接收文件读取请求;确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件。
上述方案中,确定所述文件读取请求对应的文件不存在时,所述方法还包括:返回读取文件不存在的指示信息。
上述方案中,所述利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件,还包括:获取每个待合并文件的位数组;建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容;
在利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件之后,所述方法还包括:建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件;
在接收文件读取请求之后,所述方法还包括:获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在;
所述基于所述文件读取请求读取文件,包括:在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,读取对应的文件。
上述方案中,所述获取每个待合并文件的位数组,包括:基于对应待合并文件的文件名生成至少两个哈希函数,将生成的各个哈希函数映射至预设的位数组中,得出新的位数组,将得出的新的位数组的位数组序列确定为对应待合并文件的位数组。
上述方案中,在得出合并文件之后,所述方法还包括:生成所述合并文件的元数据,将生成的合并文件的元数据存储在第一节点中;第一节点将存储的合并文件的元数据发送至第二节点;
所述基于所述文件读取请求读取文件,包括:第二节点基于所述文件读取请求以及与所述文件读取请求对应的合并文件的元数据读取文件。
本发明实施例还提供了一种文件处理装置,所述装置包括:获取模块、得出模块和存储模块;其中,
获取模块,用于获取至少两个文件;
得出模块,用于将满足文件合并条件的各个文件进行合并,得出合并文件;
存储模块,用于将合并文件以BloomMapFile形式进行存储。
上述方案中,所述得出模块,具体用于对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件。
上述方案中,所述得出模块,具体用于启动MapReduce任务将对应类别的各个待合并文件合并。
上述方案中,所述得出模块还包括接收模块和读取模块;其中,
接收模块,用于接收文件读取请求;
读取模块,用于确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件。
上述方案中,所述读取模块,还用于在确定所述文件读取请求对应的文件不存在时,返回读取文件不存在的指示信息。
上述方案中,所述得出模块还包括索引建立单元;
索引建立单元用于获取每个待合并文件的位数组,建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容;
所述索引建立单元,还用于建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件;
所述读取模块,还用于在接收文件读取请求之后,获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在;
所述读取模块,具体用于在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,读取对应的文件。
上述方案中,所述索引建立单元,具体用于基于对应待合并文件的文件名生成至少两个哈希函数,将生成的各个哈希函数映射至预设的位数组中,得出新的位数组,将得出的新的位数组的位数组序列确定为对应待合并文件的位数组。
上述方案中,所述存储模块位于第一节点中,所述读取模块位于第二节点中;
所述存储模块,具体用于将生成的合并文件的元数据进行存储,并将存储的合并文件的元数据发送至所述读取模块;
所述读取模块,具体用于基于所述文件读取请求以及与所述文件读取请求对应的合并文件的元数据读取文件。
本发明实施例提供的一种文件处理方法和装置,获取至少两个文件;在获取的文件满足文件合并条件时,将满足文件合并条件的各个文件进行合并,得出合并文件;将合并文件以BloomMapFile形式进行存储;如此,缓解了Namenode节点的工作压力,同时提高了小文件的处理速度以及存取效率。
附图说明
图1为本发明文件处理方法的第一实施例的第一流程图;
图2为本发明文件处理方法的第一实施例的第二流程图;
图3为本发明实施例中利用Bloom文件判定规则判断文件是否存在的示意图;
图4为本发明实施例中文件处理装置的组成结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述。
本发明实施例提供了一种文件处理方法,使得在访问储存的文件时,缓解Namenode节点的工作压力,同时提高了小文件的处理速度以及存取效率。
第一实施例
参见图1,其出示了本发明文件处理方法的第一实施例的第一流程图,该流程可以包括:
步骤100:获取至少两个文件。
这里,可以利用Hadoop集群的Namenode节点获取文件,例如,Hadoop集群的Namenode节点通过ftp下载方式获取文件,此时,将获取的文件存储在Hadoop集群本地存储目录。
本步骤中,并不对所获取的文件的来源进行限制,例如,可以从接口机获取文件。
步骤101:将满足文件合并条件的各个文件进行合并,得出合并文件。
具体地说,对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件;其中,在利用BloomFilter实现各个待合并文件的合并过程时,通过启动MapReduce任务将对应类别的各个待合并文件合并。
这里,BloomFilter是一种空间效率很高的随机数据结构,它利用位数组很简洁地表示一个集合;BloomFilter会使用m位的位数组以及k个相互独立的哈希函数,这里,m大于1,位数组中每位的初始数值均为0,k大于1;可以理解的是,同一个输入值经过k个相互独立的哈希函数进行计算后,能够得出互不相同的k个哈希计算结果;在k个相互独立的哈希函数中,第i个哈希函数表示为H(i,文件名),0≤i≤k-1;在应用BloomFilter时,使用H(i,文件名)映射至位数组中,被映射到的位置为1,使用位数组序列作为文件的key值。可以看出,在上述过程中生成的序列个数可表示为C(k,m),若m=80,k=18,则C(k,m)=355214207837288770,通过C(k,m)的计算结果看出:在选取适合的m和k时,可以在保证序列结果唯一准确的同时能够表示很多的文件。
具体地,在对获取的各个文件进行分类时,可以根据文件内容类型进行分类,这里,可以通过Namenode节点判断文件内容类型,获取的文件可以是信令类文件或图片类文件;在判断文件内容类型之后,对不同内容类型的文件分别进行处理;判断分类后的每个文件是否达到设置的文件大小阈值,如果达到,将对应的文件直接保存于HDFS;如果未达到,将对应文件标记为对应类别的待合并文件;这里,设置的文件大小阈值可以是32M、64M等。
这里,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件,还包括:获取每个待合并文件的位数组;建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容。
对于各个待合并文件合并的合并过程,示例性地,诸如A口信令文件、GN口信令文件、fcdr信令文件等,可通过启动MapReduce任务实现文件内容合并,主要包括内容去重、排序等操作;如此,经过MapReduce合并后的有序文件替换原始文件保存于HDFS相应目录下,可实现用户使用查询语句直接读取文件内容。
在利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件之后,所述方法还包括:建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件。
具体地,上述一级索引以及二级索引的建立的过程具体为:
步骤101a:初始化位数组。初始化m位的位数组,例如,m为32,并置位数组各位为0。下面通过表1说明一个32位的位数组的结构。
表1
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
步骤101b:哈希映射。计算选择的相互独立的k个哈希函数,第i个哈希函数为H(i,文件名),0≤i≤k-1,k为大于1的自然数;将各个哈希函数映射至位数组,得出新的位数组。具体地,得出各个哈希函数对应的哈希结果,获取哈希结果中的第j个数值Pj,将原位数组中第Pj+1个位置的数值变为1,得出新的位数组,这里,j取1至k;例如k=10,10个哈希函数对应的哈希结果为{2,4,7,8,10,14,15,17,27,30},则新的位数组如表2所示。
表2
0 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 0 |
步骤101c:得出key值。将上述新的位数组的位数组序列确定为key值,即,将上述新的位数组的各个数值排列后形成的数值确定为key值。例如,根据步骤101b的映射结果得出的key值为00101001101000110100000000010010。
这里,本步骤得出的key值为对应的待合并文件的位数组;也就是说,对于任意一个待合并文件,根据其文件名得出相应的各个哈希函数,再基于步骤101b和101c,对得出各个哈希函数进行处理,便可得出对应的待合并文件的位数组。
步骤101d:生成一级索引。建立一级索引(key,value),其中,key为步骤101c中得出的key值,value为对应文件的内容。
步骤101e:生成二级索引。经过内容类型合并的信令类文件,建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组。
步骤102:将合并文件以BloomMapFile形式进行存储。
这里,获得合并文件之后,可以采用多种现有的实现方式将合并文件以BloomMapFile形式进行存储,这里不再赘述。
进一步地,本发明第一实施例的文件处理方法还包括文件读取方法。
参见图2,其出示了本发明文件处理方法的第一实施例的第二流程图,该流程可以包括:
步骤103:接收文件读取请求。
示例性地,客户端发送读取文件请求至接收节点,利用接收节点接收客户端发起的文件读取请求。这里,接收节点包括但不限于Namenode节点,可以理解的是,Namenode节点位于Hadoop集群中。
下面以接收节点是Namenode节点为例进行说明。
这里,接收文件读取请求的Namenode节点与步骤100中获取文件的Namenode节点可以是不同的节点,具体地说,在步骤100中,所述的Namenode 节点为第一Namenode节点,第一Namenode节点在得到合并文件之后,生成合并文件的元数据,并发送合并文件的元数据到第二Namenode节点;在本步骤中,所述的接收节点为第二Namenode节点,第二Namenode节点主要负责文件的读取。
本发明第一实施例中,第一Namenode节点与第二Namenode节点分工协作,同时工作。第一Namenode节点用以实现文件合并,产生元数据信息,并发送合并文件的元数据到第二Namenode节点;第二Namenode节点利用合并文件的元数据实现文件读取。此种工作模式可以极大减轻单一Namenode节点工作的压力,加快处理速度,同时第二Namenode节点具有与第一Namenode节点相同的元数据信息,在第一Namenode节点出现故障时,第二Namenode节点可立即接手其工作,从而保障文件存储与文件读取的正常运行。
本步骤中,发起读取某个文件至第二Namenode节点,第二Namenode节点接收客户端发起的文件读取请求。
步骤104:确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件。
本步骤中,获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在;在一级索引中不存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件不存在;在确定所述文件读取请求对应的文件不存在时,返回读取文件不存在的指示信息。
确定所述文件读取请求对应的文件存在时,获取文件读取请求对应的位数组信息,在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,根据所获取的位数组信息的key值,读取对应的文件。
可以理解的是,在读取出对应的合并文件,还需要利用所述文件读取请求对应的合并文件的元数据。
这里,在从HDFS中读取出相应的合并文件之后,可以通过计算得出的key值将读取的对应的文件下载至客户端。
本步骤中,在获取文件读取请求对应的位数组信息,可以基于Bloom文件判定规则快速判别在一级索引中是否存在匹配所获取的位数组信息的key值,进而判别读取文件是否存在,如附图3所示。假设位数组的位数m=32,哈希函数个数k=10,客户端需要读取两个文件时;第二Namenode节点判断所读取的两个文件是否存在时,获取相应两个文件读取请求;根据这两个文件读取请求,获取相应的两个key值,这两个key值是通过哈希函数得出的,结果分别为A1和A2,其中A1为{2,4,7,8,10,14,15,16,20,22},A2为{7,8,9,13,14,15,19,21,28,30}。从表中可以看出A1对应的位数组各位均为1,而A2对应的部分位数组位为0,根据Bloom文件判定规则,文件映射结果位不全为1时此文件不存在,反之则可能存在,可以看出,在一级索引中存在A1对应的key值,不存在A2对应的key值,也就是说A1对应的待读取文件可能存在,需读取元数据获取文件存储信息,而A2对应的待读取文件是不存在的,无需读取元数据至内存。
可以看出,本步骤中,基于查询文件名并通过k个哈希函数计算得出key值,之后,可在基于Bloom文件判定规则快速识别文件是否存在,若不存在则直接返回所查文件不存在信息给客户端,若存在则通过计算得到的key值读出文件。此种判断方式,不仅可以快速判断出查询的文件是否存在,同时加快了文件的检索速度,更重要的是判断文件是否存在时无需将全部元数据读取至内存中,极大的加快了节点的运行速度。
步骤105:将读取的文件发送至至客户端。
具体地说,第二Namenode节点将读取的文件发送至发起文件读取请求的客户端,此时,文件读取过程完毕。
应用本发明第一实施例的文件处理方法,利用第一Namenode节点与第二Namenode节点分工协作,同时工作。可以极大减轻单一Namenode节点工作的压力,加快处理速度,同时第二Namenode节点具有与第一Namenode节点相同的元数据信息,在第一Namenode节点出现故障时,第二Namenode节点可立即接手其工作,从而保障系统正常运行;另外,使用BloomFilter实现文件合并,并将合并文件以BloomMapFiles形式保存,便于实现文件的快速查询,如此,缓解了Namenode节点的工作压力,同时提高了小文件的存储和读取速度。
第二实施例
参见图4,其出示了本发明实施例中文件处理装置的组成结构示意图,该装置包括:获取模块200、得出模块201和存储模块202;
获取模块200,用于获取至少两个文件。
得出模块201,用于将满足文件合并条件的各个文件进行合并,得出合并文件。
存储模块202,用于将合并文件以BloomMapFile形式进行存储。
具体地,所述得出模块201,用于对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;在任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件。
这里,所述得出模块201,用于启动MapReduce任务将对应类别的各个待合并文件合并。
进一步地,得出模块201包括索引建立单元2011;
这里,索引建立单元2011,用于获取每个待合并文件的位数组,建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容;
所述索引建立单元2011,还用于建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件;
进一步地,所述文件处理装置还包括:接收模块203和读取模块204;
接收模块203,用于接收文件读取请求。
读取模块204,用于确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件;还用于在确定所述文件读取请求对应的文件不存在时,返回读取文件不存在的指示信息。
具体地,读取模块204,还用于在接收文件读取请求之后,获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在。
进一步地,读取模块204,还用于在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,读取对应的文件。
存储模块202位于第一节点中,读取模块204位于第二节点中。
具体地,存储模块202用于将生成的合并文件的元数据进行存储,并将存储的合并文件的元数据发送至所述读取模块;
读取模块204,用于基于所述文件读取请求以及与所述文件读取请求对应的合并文件的元数据读取文件。
在实际应用中,所述获取模块200、得出模块201、存储模块202、接收模块203和读取模块204均可由位于Hadoop集群中的中央处理器(Central Processing Unit,CPU)、微处理器(Micro Processor Unit,MPU)、数字信号处理器(Digital Signal Processor,DSP)、或现场可编程门阵列(Field Programmable Gate Array,FPGA)等实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。
Claims (12)
1.一种文件处理方法,其特征在于,所述方法包括:
获取至少两个文件;将满足文件合并条件的各个文件进行合并,得出合并文件;将合并文件以BloomMapFile形式进行存储。
2.根据权利要求1所述的方法,其特征在于,所述将满足文件合并条件的各个文件进行合并,得出合并文件,包括:对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件。
3.根据权利要求2所述的方法,其特征在于,所述利用BloomFilter实现各个待合并文件的合并,包括:启动MapReduce任务将对应类别的各个待合并文件合并。
4.根据权利要求2或3所述的方法,其特征在于,在将合并文件以BloomMapFile形式进行存储之后,所述方法还包括:接收文件读取请求;确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件。
5.根据权利要求4所述的方法,其特征在于,确定所述文件读取请求对应的文件不存在时,所述方法还包括:返回读取文件不存在的指示信息。
6.根据权利要求4所述的方法,其特征在于,所述利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件,还包括:获取每个待合并文件的位数组;建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容;
在利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件之后,所述方法还包括:建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件;
在接收文件读取请求之后,所述方法还包括:获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在;
所述基于所述文件读取请求读取文件,包括:在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,读取对应的文件。
7.根据权利要求6所述方法,其特征在于,所述获取每个待合并文件的位数组,包括:基于对应待合并文件的文件名生成至少两个哈希函数,将生成的各个哈希函数映射至预设的位数组中,得出新的位数组,将得出的新的位数组的位数组序列确定为对应待合并文件的位数组。
8.一种文件处理装置,其特征在于,所述装置包括:获取模块、得出模块和存储模块;其中,
获取模块,用于获取至少两个文件;
得出模块,用于将满足文件合并条件的各个文件进行合并,得出合并文件;
存储模块,用于将合并文件以BloomMapFile形式进行存储。
9.根据权利要求8所述的装置,其特征在于,所述得出模块,具体用于对获取的各个文件进行分类;在每个类别的文件中,将容量小于容量阈值的文件标记为对应类别的待合并文件;任意一个类别的各个待合并文件的容量之和达到容量阈值时,利用BloomFilter将对应类别的各个待合并文件合并,得出合并文件。
10.根据权利要求9所述的装置,其特征在于,所述得出模块还包括接收模块和读取模块;其中,
接收模块,用于接收文件读取请求;
读取模块,用于确定所述文件读取请求对应的文件存在时,基于所述文件读取请求读取文件。
11.根据权利要求10所述的装置,其特征在于,所述得出模块还包括索引建立单元;
索引建立单元用于获取每个待合并文件的位数组,建立一级索引(key,value),其中,key表示每个待合并文件的位数组,value表示每个待合并文件的内容;
所述索引建立单元,还用于建立二级索引(new_key,(key,value)),new_key表示对应类别的合并文件的位数组,对应类别的合并文件为对应类别的各个待合并文件合并后形成的文件;
所述读取模块,还用于在接收文件读取请求之后,获取文件读取请求对应的位数组信息,在一级索引中存在匹配所获取的位数组信息的key值时,确定所述文件读取请求对应的文件存在;
所述读取模块,具体用于在二级索引中,查找出所获取的位数组信息对应的new_key值,基于查找出的new_key值,读取出对应的合并文件;基于文件读取请求,从读取出的合并文件中,读取对应的文件。
12.根据权利要求11所述的装置,其特征在于,所述索引建立单元,具体用于基于对应待合并文件的文件名生成至少两个哈希函数,将生成的各个哈希函数映射至预设的位数组中,得出新的位数组,将得出的新的位数组的位数组序列确定为对应待合并文件的位数组。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610091248.2A CN107092604B (zh) | 2016-02-18 | 2016-02-18 | 一种文件处理方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610091248.2A CN107092604B (zh) | 2016-02-18 | 2016-02-18 | 一种文件处理方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107092604A true CN107092604A (zh) | 2017-08-25 |
CN107092604B CN107092604B (zh) | 2020-03-20 |
Family
ID=59646073
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610091248.2A Active CN107092604B (zh) | 2016-02-18 | 2016-02-18 | 一种文件处理方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107092604B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111104529A (zh) * | 2018-10-26 | 2020-05-05 | 深圳云天励飞技术有限公司 | 一种索引文件的控制方法、装置及电子设备 |
CN111262837A (zh) * | 2020-01-09 | 2020-06-09 | 奇安信科技集团股份有限公司 | 一种数据加密方法、数据解密方法、系统、设备和介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7225207B1 (en) * | 2001-10-10 | 2007-05-29 | Google Inc. | Server for geospatially organized flat file data |
CN101226546A (zh) * | 2008-02-01 | 2008-07-23 | 华为技术有限公司 | 文件的组织、检索方法 |
CN104778229A (zh) * | 2015-03-31 | 2015-07-15 | 南京邮电大学 | 基于Hadoop的电信业务小文件存储系统及方法 |
CN105183839A (zh) * | 2015-09-02 | 2015-12-23 | 华中科技大学 | 一种基于Hadoop的小文件分级索引的存储优化方法 |
-
2016
- 2016-02-18 CN CN201610091248.2A patent/CN107092604B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7225207B1 (en) * | 2001-10-10 | 2007-05-29 | Google Inc. | Server for geospatially organized flat file data |
CN101226546A (zh) * | 2008-02-01 | 2008-07-23 | 华为技术有限公司 | 文件的组织、检索方法 |
CN104778229A (zh) * | 2015-03-31 | 2015-07-15 | 南京邮电大学 | 基于Hadoop的电信业务小文件存储系统及方法 |
CN105183839A (zh) * | 2015-09-02 | 2015-12-23 | 华中科技大学 | 一种基于Hadoop的小文件分级索引的存储优化方法 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111104529A (zh) * | 2018-10-26 | 2020-05-05 | 深圳云天励飞技术有限公司 | 一种索引文件的控制方法、装置及电子设备 |
CN111104529B (zh) * | 2018-10-26 | 2024-03-29 | 深圳云天励飞技术有限公司 | 一种索引文件的控制方法、装置及电子设备 |
CN111262837A (zh) * | 2020-01-09 | 2020-06-09 | 奇安信科技集团股份有限公司 | 一种数据加密方法、数据解密方法、系统、设备和介质 |
CN111262837B (zh) * | 2020-01-09 | 2023-04-11 | 奇安信科技集团股份有限公司 | 一种数据加密方法、数据解密方法、系统、设备和介质 |
Also Published As
Publication number | Publication date |
---|---|
CN107092604B (zh) | 2020-03-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101137147B1 (ko) | 질의 강제 인덱싱 | |
US9165068B2 (en) | Techniques for cloud-based similarity searches | |
US9442929B2 (en) | Determining documents that match a query | |
US10831747B2 (en) | Multi stage aggregation using digest order after a first stage of aggregation | |
US11075991B2 (en) | Partitioning data according to relative differences indicated by a cover tree | |
AU2014212780A1 (en) | Data stream splitting for low-latency data access | |
CN112136123A (zh) | 表征文件以进行相似性搜索 | |
Long et al. | On optimal worst-case matching | |
EP2804115A1 (en) | Index scanning apparatus and index scanning method | |
WO2013046667A1 (ja) | 情報システム、その管理方法およびプログラム、データ処理方法およびプログラム、ならびに、データ構造 | |
WO2017118335A1 (zh) | 一种映射方法和设备 | |
CN101184091A (zh) | 一种确定相似文件的方法及装置 | |
US20090265314A1 (en) | Secure file searching | |
US10700934B2 (en) | Communication control device, communication control method, and computer program product | |
CN111723161A (zh) | 一种数据处理方法、装置及设备 | |
CN109947759A (zh) | 一种数据索引建立方法、索引检索方法及装置 | |
Li et al. | Losha: A general framework for scalable locality sensitive hashing | |
US10713592B2 (en) | Jaccard similarity estimation of weighted samples: circular smearing with scaling and randomized rounding sample selection | |
US10698955B1 (en) | Weighted abstract path graph database partitioning | |
CN107092604A (zh) | 一种文件处理方法和装置 | |
Adhinugraha et al. | Finding reverse nearest neighbors by region | |
CN107562762A (zh) | 数据索引构建方法及装置 | |
Papadopoulos et al. | Efficient distributed range query processing in apache spark | |
KR20160100224A (ko) | 오디오 핑거프린트 데이터베이스 구축 및 오디오 핑거프린트 검색 방법 및 장치 | |
Li et al. | MR‐tree: an efficient index for MapReduce |
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 |