CN110309101A - 一种数据管理方法及Hadoop分布式文件系统 - Google Patents
一种数据管理方法及Hadoop分布式文件系统 Download PDFInfo
- Publication number
- CN110309101A CN110309101A CN201810245832.8A CN201810245832A CN110309101A CN 110309101 A CN110309101 A CN 110309101A CN 201810245832 A CN201810245832 A CN 201810245832A CN 110309101 A CN110309101 A CN 110309101A
- Authority
- CN
- China
- Prior art keywords
- node
- metadata
- data processing
- processing request
- agent
- 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/13—File access structures, e.g. distributed indices
- G06F16/137—Hash-based
-
- 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
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分布式文件系统,涉及计算机技术领域。该数据管理方法及Hadoop分布式文件系统通过代理节点接收一客户端发起的数据处理请求,并在代理节点上基于预建立的哈希模型、数据处理请求确定与数据处理请求对应的元数据节点,通过代理节点向元数据节点发送数据处理请求,最后通过元数据节点响应数据处理请求而反馈报文至客户端;通过统一元数据节点的命令空间,从而将多个独立的元数据节点统一为整体的命名空间,实现了对数据的统一访问;此外,可基于预建立的哈希模型快速查询到与数据处理请求对应的元数据节点,提高了读取/写入效率。
Description
技术领域
本发明涉及计算机技术领域,具体而言,涉及一种数据管理方法及Hadoop分布式文件系统。
背景技术
当面临大数据应用需求时,在单机性能面临瓶颈,关系数据库集群系统已不能满足大数据应用需求的情况下,利用分布式存储系统保存数据并采用基于SQL语言标准用户接口已成为解决大规模结构化数据检索问题的有效方法。
现有技术,通常采用Hadoop分布式文件系统(Hadoop DistributedFile System,HDFS)存储数据文件,并通过维护一份元数据将HDFS文件及其内容映射为表结构。但现在的HDFS只提供了对已存在的数据的统一访问,对于需要写入的客户端而言,HDFS还是多个数据中心;此外,对一个文件的查找,最坏的情况下,需要查找所有数据中心的NameNode节点,效率比较低下。
发明内容
本发明的目的在于提供一种数据管理方法及Hadoop分布式文件系统,以解决上述问题。
为了实现上述目的,本发明实施例采用的技术方案如下:
第一方面,本发明实施例提供了一种数据管理方法,运行于Hadoop分布式文件系统集群节点上,所述集群节点包括代理节点以及元数据节点,所述数据管理方法包括:
通过所述代理节点接收一客户端发起的数据处理请求;
在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点;
通过所述代理节点向所述元数据节点发送所述数据处理请求;
通过所述元数据节点响应所述数据处理请求而反馈报文至所述客户端。
第二方面,本发明实施例还提供了一种Hadoop分布式文件系统,所述Hadoop分布式文件系统包括:
代理节点,用于接收一客户端发起的数据处理请求;
所述代理节点还用于基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点;
所述代理节点还用于向所述元数据节点发送所述数据处理请求;
元数据节点,用于响应所述数据处理请求而反馈报文至所述客户端。
本发明实施例提供的数据管理方法及Hadoop分布式文件系统,通过代理节点接收一客户端发起的数据处理请求,并在代理节点上基于预建立的哈希模型、数据处理请求确定与数据处理请求对应的元数据节点,通过代理节点向元数据节点发送数据处理请求,最后通过元数据节点响应数据处理请求而反馈报文至客户端;通过统一元数据节点的命令空间,从而将多个独立的元数据节点统一为整体的命名空间,实现了对数据的统一访问;此外,可基于预建立的哈希模型快速查询到与数据处理请求对应的元数据节点,提高了读取/写入效率。
为使本发明的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本发明的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了一种可应用于本发明实施例中的服务器的功能框图。
图2示出了本发明实施例提供的Hadoop分布式文件系统的功能模块图。
图3示出了本发明实施例提供的一种哈希环的结构示意图。
图4示出了本发明实施例提供的另一种哈希环的结构示意图。
图5示出了本发明实施例提供的一种数据管理方法的流程图。
图6为图5中步骤S501的具体流程图。
图7为图5中步骤S502的具体流程图。
图8示出了本发明实施例提供的建立哈希环的流程图。
图9为图7中子步骤S5023的第一种具体流程图。
图10为图7中子步骤S5023的第二种具体流程图。
图11为图7中子步骤S5023的第三种具体流程图。
图12为图7中子步骤S5023的第四种具体流程图。
图标:100-服务器;111-存储器;112-处理器;113-通信单元;200-Hadoop分布式文件系统;210-负载均衡节点;220-代理节点;230-元数据节点;240-数据节点。
具体实施方式
下面将结合本发明实施例中附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围,而是仅仅表示本发明的选定实施例。基于本发明的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本发明的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
请参阅图1,图1示出了一种可应用于本发明实施例中的服务器100的功能框图。该服务器100包括Hadoop分布式文件系统200、存储器111、存储控制器,一个或多个(图中仅示出一个)处理器112、通信单元113。这些组件通过一条或多条通讯总线/信号线相互通讯。所述Hadoop分布式文件系统200包括至少一个可以软件或固件(firmware)的形式存储于所述存储器111中或固化在所述服务器100的操作系统(operating System,OS)中的软件功能单元。
存储器111可用于存储软件程序以及单元,如本发明实施例中的Hadoop分布式文件系统200所对应的程序指令/单元,处理器112通过运行存储在存储器111内的Hadoop分布式文件系统200的软件程序以及单元,从而执行各种功能应用以及数据处理,如本发明实施例提供的数据管理方法。其中,所述存储器111可以是,但不限于,随机存取存储器(RandomAccess Memory,RAM),只读存储器(Read Only Memory,ROM),可编程只读存储器(Programmable Read-Only Memory,PROM),可擦除只读存储器(Erasable ProgrammableRead-Only Memory,EPROM),电可擦除只读存储器(Electric Erasable ProgrammableRead-Only Memory,EEPROM)等。处理器112以及其他可能的组件对存储器111的访问可在存储控制器的控制下进行。
所述通信单元113用于通过所述网络建立所述服务器100与其它通信终端之间的通信连接,并用于通过所述网络收发数据。
应当理解的是,图1所示的结构仅为示意,服务器100还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。
第一实施例
本发明实施例提供了一种Hadoop分布式文件系统200,应用于服务器100,用于实现对数据中心更加统一地、高效地管理。请参阅图2,为本发明实施例提供的Hadoop分布式文件系统200的功能模块图。该Hadoop分布式文件系统200包括负载均衡节点210、代理节点220、元数据节点230以及数据节点240。
其中,负载均衡节点210用于接收一客户端发起的数据处理请求。
需要说明的是,数据处理请求包括但不仅限于写入请求、读取请求等。当客户端向服务器100发起写入请求时,表明用户想通过客户端向服务器100写入数据,可以理解为新建数据;当客户端向服务器100发起读取请求时,表明用户想向服务器100获取相关数据。
负载均衡节点210还用于依据预设定的分配算法,将数据处理请求发送至代理节点220。
该预设定的分配算法可以但不仅限于轮叫调度(Round Robin),加权轮叫(Weighted Round Robin),最少链接(Least Connection)等算法。
代理节点220用于基于预建立的哈希模型、数据处理请求确定与数据处理请求对应的元数据节点230。
具体地,代理节点220用于解析数据处理请求,获取与数据处理请求对应的上传路径及文件名。
代理节点220还用于基于预建立的哈希模型、上传路径计算与数据处理请求对应的关键字值。
由于元数据节点230中存储了文件名和目录的关系,从而当得知某一文件的上传路径时,便可得知与之对应的文件名;因此此时选择使用上传路径计算关键字值,而不是基于上传路径及文件名计算关键字值,提高了查询的实时效率。
代理节点220还用于将从预建立的哈希环中预先确定的与关键字值映射的元数据节点230,确定为与数据处理请求对应的元数据节点230。
其中,预建立的哈希环是代理节点220根据元数据节点230的硬件信息建立的。
代理节点220用于获取预先分配在每个元数据节点230的硬件配置信息。
Hadoop分布式文件系统200中存在多个元数据节点230,每个元数据节点230均有预先分配的硬件配置信息。该硬件配置信息包括但不仅限于中央处理器112(CentralProcessing Unit,CPU)、内存等。
代理节点220用于依据每个硬件配置信息计算每个元数据节点230对应的负荷权重。
具体地,代理节点220用于通过算式w=k1*x+k2*y计算负荷权重,其中,w为负荷权重,x为预先分配在该元数据节点230的处理器112的数量,y为预先分配在该元数据节点230的内存的容量,k1、k2均为预先设定的比例系数。
例如,在一种优选的实施例中,预先设定的比例系数k1、k2均为0.5,则预先分配了1核CPU、1GB内存的元数据节点230的负荷权重W=0.5*1+0.5*1=1。
需要说明的是,用户可根据实际设定比例系数k1、k2的值。
代理节点220还用于依据预设定的哈希算法、负荷权重建立哈希环。
具体地,代理节点220依据所有元数据节点230对应的负荷权重确定虚拟节点的个数。
负荷权重可表征该元数据节点230的负载能力,通过依据负荷权重建立哈希环,可使得代理节点220可依据元数据节点230的负载能力分配虚拟节点,即分配文件,而无需人为关注文件应该如何分配,不仅节约了人力,还提高了各个元数据节点230的利用率,也避免了出现文件分配不合理的情况。
代理节点220依据预设定的哈希算法,将虚拟节点映射至哈希环中,然后按顺时针方向,对文件的上传路径进行哈希计算,从而将文件分配到离关键字值最近的虚拟节点中,再依据元数据节点230与虚拟节点的对应关系,找到真实的元数据节点230,将文件分配到元数据节点230中。
可以理解地,哈希环中记录有关键字值与虚拟节点的映射关系,还记录有虚拟节点与元数据节点230的映射关系。
例如,Hadoop分布式文件系统200包括3个元数据节点230,每个元数据节点230分别对应的负荷权重为1、2、3,则虚拟节点有1+2+3=6个,则代理节点220建立的哈希环如图3所示,其中,关键字值、虚拟节点以及元数据节点230具有如下表所示的映射关系:
表1
V1 | 虚拟节点1 | namenode1 |
V2 | 虚拟节点2 | namenode2 |
V3 | 虚拟节点3 | namenode3 |
V4 | 虚拟节点4 | namenode2 |
V5 | 虚拟节点5 | namenode3 |
V6 | 虚拟节点6 | namenode3 |
例如,代理节点220依据接收到的数据处理请求,计算出关键字值key1,比对后确认key1落在V6的范围内,则与之对应的是虚拟节点6,从而对应的元数据节点230为namenode3。
若Hadoop分布式文件系统200增加一个元数据节点230,按照相同的哈希模型进行计算,得到增加的虚拟节点Vn,并确认新增加的虚拟节点Vn映射在原哈希环中的V3与V4之间(如图4),则此时需要进行重新分配的文件即为原哈希环中,Vn沿逆时针遍历到V3之间的文件,而这些文件在原哈希环中,将映射至原V4对应的元数据节点230。
相应地,当Hadoop分布式文件系统200中删除一个元数据节点230时,同样按照上述过程重新建立哈希环并进行文件分配。
从而,通过这种方式分配每个元数据节点230的文件,能有效降低增加或删除元数据节点230时带来的数据迁移量。
需要说明的是,在代理节点220确定与数据处理请求对应的元数据节点230时,还需要确定服务器100当前是否存在数据迁移。
第一种:当不存在数据迁移时,代理节点220中有一个哈希环,即为完成元数据迁移后的当前哈希环。此时,元数据节点230的确定与数据处理请求的类型有关:
当数据处理请求为写入请求时,代理节点220向从当前哈希环中确定的与关键字值映射的元数据节点230发起查询请求,以查询元数据节点230中是否存在与该写入请求对应的文件名,并在元数据节点230中不存在该文件名时,将该元数据节点230确定为与写入请求对应的元数据节点230,在元数据节点230中存在该文件名时,返回拒绝写入指令表示文件名已存在。
需要说明的是,当数据处理请求为强制写入请求时,代理节点220仍然需要向从当前哈希环中确定的与关键字值映射的元数据节点230发起查询请求,但即使元数据节点230中存在与该强制写入请求对应的文件名,也直接将该元数据节点230确定为与强制写入请求对应的元数据节点230,后续对其进行覆盖写入流程即可。
当数据处理请求为读取请求时,代理节点220向从当前哈希环中确定的与关键字值映射的元数据节点230发起查询请求,以查询元数据节点230中是否存在与该写入请求对应的文件名,并在元数据节点230中存在该文件名时,将该元数据节点230确定为与读取请求对应的元数据节点230。
第二种:当存在数据迁移时,代理节点220中包括两个哈希环,分别为完成元数据迁移前的历史哈希环及完成元数据迁移后的当前哈希环。此时,元数据节点230的确定与数据处理请求的类型有关:
当数据处理请求为写入请求时,代理节点220用于向从历史哈希环中预先确定的与关键字值映射的第一元数据节点发起查询请求,以查询第一元数据节点中是否存在与写入请求对应的文件名,并在当第一元数据节点中不存在文件名时,向从当前哈希环中预先确定的与关键字值映射的第二元数据节点发起查询请求以查询第二元数据节点中是否存在文件名,并当第二元数据节点中不存在文件名时,在代理节点220上将第二元数据节点确定为与写入请求对应的元数据节点230。
例如,正在进行的数据迁移的过程中,先查询当前哈希环中预先确定的与关键字值映射的第一元数据节点中否存在与写入请求对应的文件名,很可能因为与写入请求对应的文件名同名的文件正在进行迁移,还未配置到当前哈希环中的元数据节点230,从而导致重名的情况,可以有效避免重名写入的错误产生,并提高了写入效率。
相应地,当数据处理请求为强制写入请求时,代理节点220仍然需要向从当前哈希环中预先确定的与关键字值映射的第二元数据节点发起查询请求,但即使第二元数据节点中存在与该强制写入请求对应的文件名,也直接将该第二元数据节点确定为与强制写入请求对应的元数据节点230,后续对其进行覆盖写入流程即可。
当数据处理请求为读取请求时,代理节点220向从当前哈希环中预先确定的与关键字值映射的第三元数据节点发起查询请求以查询第三元数据节点中是否存在文件名,并在当第三元数据节点中不存在文件名时,向从历史哈希环中预先确定的与关键字值映射的第四元数据节点发起查询请求以查询第四元数据节点中是否存在文件名,并将存储有文件名的第四元数据节点确定为与读取请求对应的元数据节点230。
代理节点220还用于向元数据节点230发送数据处理请求。
元数据节点230用于响应数据处理请求而反馈报文至客户端。
该报文包括但不仅限于block列表和block对应的数据节点240的列表。
具体地,当数据处理请求为写入请求时,客户端依据接收到的报文依次将block写入数据节点240中;当数据处理请求为读取请求时,客户端按照顺序依次读取block,并在读取完毕后关闭文件。
第二实施例
本发明实施例提供了一种数据管理方法,应用于服务器100,运行于Hadoop分布式文件系统200集群节点上。需要说明的是,本实施例所提供的数据管理方法,其基本原理及产生的技术效果和上述实施例相同,为简要描述,本实施例部分未提及之处,可参考上述的实施例中相应内容。请参阅图5,为本发明实施例提供的种数据管理方法的流程图。该种数据管理方法包括:
步骤S501:通过代理节点220接收一客户端发起的数据处理请求。
请参阅图6,为步骤S501的具体流程图。该步骤S501包括:
子步骤S5011:通过负载均衡节点210接收客户端发起的数据处理请求。
需要说明的是,数据处理请求包括但不仅限于写入请求、读取请求等。当客户端向服务器100发起写入请求时,表明用户想通过客户端向服务器100写入数据,可以理解为新建数据;当客户端向服务器100发起读取请求时,表明用户想向服务器100获取相关数据。
子步骤S5012:在负载均衡节点210上依据预设定的分配算法,将数据处理请求发送至代理节点220。
需要说明的是,该预设定的分配算法可以但不仅限于轮叫调度(Round Robin),加权轮叫(Weighted Round Robin),最少链接(Least Connection)等算法。
步骤S502:在代理节点220上基于预建立的哈希模型、数据处理请求确定与数据处理请求对应的元数据节点230。
请参阅图7,为步骤S502的具体流程图。该步骤S502包括:
子步骤S5021:在代理节点220上解析数据处理请求,获取与数据处理请求对应的上传路径及文件名。
子步骤S5022:在代理节点220上基于预建立的哈希模型、上传路径计算与数据处理请求对应的关键字值。
由于元数据节点230中存储了文件名和目录的关系,从而当得知某一文件的上传路径时,便可得知与之对应的文件名;因此此时选择使用上传路径计算关键字值,而不是基于上传路径及文件名计算关键字值,提高了查询的实时效率。
子步骤S5023:在代理节点220上将从预建立的哈希环中预先确定的与关键字值映射的元数据节点230,确定为与数据处理请求对应的元数据节点230。
其中,建立哈希环的流程图如图8所示:
步骤S801:在代理节点220上获取预先分配在每个元数据节点230的硬件配置信息。
Hadoop分布式文件系统200中存在多个元数据节点230,每个元数据节点230均有预先分配的硬件配置信息。该硬件配置信息包括但不仅限于中央处理器112(CentralProcessing Unit,CPU)、内存等。
步骤S802:在代理节点220上依据每个硬件配置信息计算每个元数据节点230对应的负荷权重。
具体地,代理节点220用于通过算式w=k1*x+k2*y计算负荷权重,其中,w为负荷权重,x为预先分配在该元数据节点230的处理器112的数量,y为预先分配在该元数据节点230的内存的容量,k1、k2均为预先设定的比例系数。
例如,在一种优选的实施例中,预先设定的比例系数k1、k2均为0.5,则预先分配了1核CPU、1GB内存的元数据节点230的负荷权重W=0.5*1+0.5*1=1。
步骤S803:在代理节点220上依据预设定的哈希算法、负荷权重建立哈希环。
具体地,代理节点220依据所有元数据节点230对应的负荷权重确定虚拟节点的个数。
代理节点220依据预设定的哈希算法,将虚拟节点映射至哈希环中,然后按顺时针方向,对文件的上传路径进行哈希计算,从而将文件分配到离关键字值最近的虚拟节点中,再依据元数据节点230与虚拟节点的对应关系,找到真实的元数据节点230,将文件分配到元数据节点230中。
可以理解地,哈希环中记录有关键字值与虚拟节点的映射关系,还记录有虚拟节点与元数据节点230的映射关系。
例如,Hadoop分布式文件系统200包括3个元数据节点230,每个元数据节点230分别对应的负荷权重为1、2、3,则虚拟节点有1+2+3=6个,则代理节点220建立的哈希环如图3所示,其中,关键字值、虚拟节点以及元数据节点230具有如下表所示的映射关系:
表1
V1 | 虚拟节点1 | namenode1 |
V2 | 虚拟节点2 | namenode2 |
V3 | 虚拟节点3 | namenode3 |
V4 | 虚拟节点4 | namenode2 |
V5 | 虚拟节点5 | namenode3 |
V6 | 虚拟节点6 | namenode3 |
例如,代理节点220依据接收到的数据处理请求,计算出关键字值key1,比对后确认key1落在V6的范围内,则与之对应的是虚拟节点6,从而对应的元数据节点230为namenode3。
若Hadoop分布式文件系统200增加一个元数据节点230,按照相同的哈希模型进行计算,得到增加的虚拟节点Vn,并确认新增加的虚拟节点Vn映射在原哈希环中的V3与V4之间(如图4),则此时需要进行重新分配的文件即为原哈希环中,Vn沿逆时针遍历到V3之间的文件,而这些文件在原哈希环中,将映射至原V4对应的元数据节点230。
相应地,当Hadoop分布式文件系统200中删除一个元数据节点230时,同样按照上述过程重新建立哈希环并进行文件分配。
从而,通过这种方式分配每个元数据节点230的文件,能有效降低增加或删除元数据节点230时带来的数据迁移量。
需要说明的是,在代理节点220确定与数据处理请求对应的元数据节点230时,还需要确定服务器100当前是否存在数据迁移,从而将确定与数据处理请求对应的元数据节点230的情况分为以下两种:
第一种:当不存在数据迁移时,代理节点220包括完成元数据迁移后的当前哈希环。此时,元数据节点230的确定与数据处理请求的类型有关:
(1)数据处理请求为写入请求时,请参阅图9,子步骤S5023包括:
子步骤S50231:通过代理节点220向从当前哈希环中确定的与关键字值映射的元数据节点230发起查询请求,以查询元数据节点230中是否存在文件名。
子步骤S50232:当元数据节点230中不存在文件名时,将不存在文件名的元数据节点230确定为与写入请求对应的元数据节点230。
由于只存在一个哈希环,因而当确定元数据节点230中不存在该文件名时,便能确定所有元数据节点230中均不存在该文件名,从而可以确定为与写入请求对应的元数据节点230,以响应该数据处理请求。
(2)数据处理请求为读取请求时,请参阅图10,子步骤S5023包括:
子步骤S50233:通过代理节点220向从当前哈希环中确定的与关键字值映射的元数据节点230发起查询请求,以查询元数据节点230中是否存在文件名。
子步骤S50234:当元数据节点230中存在文件名时,将存在文件名的元数据节点230确定为与读取请求对应的元数据节点230。
第二种:当存在数据迁移时,代理节点220中包括两个哈希环,分别为完成元数据迁移前的历史哈希环及完成元数据迁移后的当前哈希环。此时,元数据节点230的确定与数据处理请求的类型有关:
(1)数据处理请求为写入请求时,请参阅图11,子步骤S5023包括:
子步骤S1001:通过代理节点220向从历史哈希环中预先确定的与关键字值映射的第一元数据节点发起查询请求。
子步骤S1002:在第一元数据节点上查询第一元数据节点中是否存在文件名,如果是,则执行子步骤S1003;如果否,则执行子步骤S1004。
子步骤S1003:向客户端发送拒绝写入指令。
子步骤S1004:通过代理节点220向从当前哈希环中预先确定的与关键字值映射的第二元数据节点发起查询请求。
子步骤S1005:在第二元数据节点上查询第二元数据节点中是否存在文件名,如果是,则执行子步骤S1003;如果否,则执行子步骤S1006。
子步骤S1006:在代理节点220上将第二元数据节点确定为与写入请求对应的元数据节点230。
(2)数据处理请求为读取请求时,请参阅图12,子步骤S5023包括:
子步骤S1101:通过代理节点220向从当前哈希环中预先确定的与关键字值映射的第三元数据节点发起查询请求。
子步骤S1102:在第三元数据节点上查询第三元数据节点中是否存在文件名,如果是,则执行子步骤S1103;如果否,则执行子步骤S1104。
子步骤S1103:在代理节点220上将存储有文件名的第三元数据节点确定为与读取请求对应的元数据节点230。
子步骤S1104:通过代理节点220向从历史哈希环中预先确定的与关键字值映射的第四元数据节点发起查询请求。
子步骤S1105:在第四元数据节点上查询第四元数据节点中是否存在文件名,如果是,则执行子步骤S1106;如果否,则执行子步骤S1107。
子步骤S1106:在代理节点220上将存储有文件名的第四元数据节点确定为与读取请求对应的元数据节点230。
子步骤S1107:通过第四元数据节点向客户端发送文件不存在指令。
步骤S503:通过代理节点220向元数据节点230发送数据处理请求。
步骤S504:通过元数据节点230响应数据处理请求而反馈报文至客户端以使客户端依据报文进行数据处理。
该报文包括但不仅限于block列表和block对应的数据节点240的列表。
具体地,当数据处理请求为写入请求时,客户端依据接收到的报文依次将block写入数据节点240中;当数据处理请求为读取请求时,客户端按照顺序依次读取block,并在读取完毕后关闭文件。
综上所述,本发明实施例提供的数据管理方法及Hadoop分布式文件系统,通过代理节点接收一客户端发起的数据处理请求,并在代理节点上基于预建立的哈希模型、数据处理请求确定与数据处理请求对应的元数据节点,通过代理节点向元数据节点发送数据处理请求,最后通过元数据节点响应数据处理请求而反馈报文至客户端;通过统一元数据节点的命令空间,从而将多个独立的元数据节点统一为整体的命名空间,实现了对数据的统一访问;此外,可基于预建立的哈希模型快速查询到与数据处理请求对应的元数据节点,提高了读取/写入效率。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
Claims (10)
1.一种数据管理方法,其特征在于,运行于Hadoop分布式文件系统集群节点上,所述集群节点包括代理节点以及元数据节点,所述数据管理方法包括:
通过所述代理节点接收一客户端发起的数据处理请求;
在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点;
通过所述代理节点向所述元数据节点发送所述数据处理请求;
通过所述元数据节点响应所述数据处理请求而反馈报文至所述客户端。
2.如权利要求1所述的数据管理方法,其特征在于,所述在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤包括:
在所述代理节点上解析所述数据处理请求,获取与所述数据处理请求对应的上传路径;
在所述代理节点上基于预建立的哈希模型、所述上传路径计算与所述数据处理请求对应的关键字值;
在所述代理节点上将从预建立的哈希环中预先确定的与所述关键字值映射的元数据节点,确定为与所述数据处理请求对应的元数据节点。
3.如权利要求2所述的数据管理方法,其特征在于,所述数据处理请求包括写入请求,所述预建立的哈希环包括完成元数据迁移后的当前哈希环,所述在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤还包括:
在所述代理节点上解析所述写入请求,获取与所述写入请求对应的文件名;
在所述代理节点上将从预建立的哈希环中预先确定的与所述关键字值映射的元数据节点确定为与所述数据处理请求对应的元数据节点的步骤包括:
通过所述代理节点向从当前哈希环中确定的与所述关键字值映射的元数据节点发起查询请求,以查询所述元数据节点中是否存在所述文件名;
当所述元数据节点中不存在所述文件名时,将不存在所述文件名的元数据节点确定为与所述写入请求对应的元数据节点。
4.如权利要求2所述的数据管理方法,其特征在于,所述数据处理请求包括读取请求,所述预建立的哈希环包括完成元数据迁移后的当前哈希环,所述在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤还包括:
在所述代理节点上解析所述读取请求,获取与所述读取请求对应的文件名;
在所述代理节点上将从预建立的哈希环中预先确定的与所述关键字值映射的元数据节点确定为与所述数据处理请求对应的元数据节点的步骤包括:
通过所述代理节点向从当前哈希环中确定的与所述关键字值映射的元数据节点发起查询请求,以查询所述元数据节点中是否存在所述文件名;
当所述元数据节点中存在所述文件名时,将存在所述文件名的元数据节点确定为与所述读取请求对应的元数据节点。
5.如权利要求2所述的数据管理方法,其特征在于,所述数据处理请求包括写入请求,所述预建立的哈希环包括完成元数据迁移前的历史哈希环及完成元数据迁移后的当前哈希环,所述在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤还包括:
在所述代理节点上解析所述写入请求,获取与所述写入请求对应的文件名;
在所述代理节点上将从预建立的哈希环中预先确定的与所述关键字值映射的元数据节点确定为与所述数据处理请求对应的元数据节点的步骤包括:
通过所述代理节点向从所述历史哈希环中预先确定的与所述关键字值映射的第一元数据节点发起查询请求,以查询所述第一元数据节点中是否存在所述文件名;
当所述第一元数据节点中不存在所述文件名时,通过所述代理节点向从所述当前哈希环中预先确定的与所述关键字值映射的第二元数据节点发起查询请求以查询所述第二元数据节点中是否存在所述文件名;
当所述第二元数据节点中不存在文件名时,在所述代理节点上将所述第二元数据节点确定为与所述写入请求对应的元数据节点。
6.如权利要求2所述的数据管理方法,其特征在于,所述数据处理请求包括读取请求,所述预建立的哈希环包括完成元数据迁移前的历史哈希环及完成元数据迁移后的当前哈希环,所述在所述代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤还包括:
在所述代理节点上解析所述读取请求,获取与所述读取请求对应的文件名;
在所述代理节点上将从预建立的哈希环中预先确定的与所述关键字值映射的元数据节点确定为与所述数据处理请求对应的元数据节点的步骤包括:
通过所述代理节点向从所述当前哈希环中预先确定的与所述关键字值映射的第三元数据节点发起查询请求以查询所述第三元数据节点中是否存在所述文件名;
当所述第三元数据节点中不存在所述文件名时,通过所述代理节点向从所述历史哈希环中预先确定的与所述关键字值映射的第四元数据节点发起查询请求以查询所述第四元数据节点中是否存在所述文件名;
在所述代理节点上将存储有所述文件名的第四元数据节点确定为与所述读取请求对应的元数据节点。
7.如权利要求2-6中任意一项所述的数据管理方法,其特征在于,在所述在代理节点上基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点的步骤之前,所述数据管理方法还包括:
在所述代理节点上获取预先分配在每个所述元数据节点的硬件配置信息;
在所述代理节点上依据每个所述硬件配置信息计算每个所述元数据节点对应的负荷权重;
在所述代理节点上依据预设定的哈希算法、所述负荷权重建立所述哈希环。
8.如权利要求7中所述的数据管理方法,其特征在于,所述在所述代理节点上依据每个所述硬件配置信息计算每个所述元数据节点对应的负荷权重的步骤包括:
通过算式w=k1*x+k2*y计算所述负荷权重,其中,w为负荷权重,x为预先分配在该元数据节点的处理器的数量,y为预先分配在该元数据节点的内存的容量,k1、k2均为预先设定的比例系数。
9.如权利要求1所述的数据管理方法,其特征在于,所述集群节点还包括负载均衡节点,所述通过代理节点接收一客户端发起的数据处理请求的步骤包括:
通过所述负载均衡节点接收所述客户端发起的数据处理请求;
在所述负载均衡节点上依据预设定的分配算法,将所述数据处理请求发送至所述代理节点。
10.一种Hadoop分布式文件系统,其特征在于,所述Hadoop分布式文件系统包括:
代理节点,用于接收一客户端发起的数据处理请求;
所述代理节点还用于基于预建立的哈希模型、所述数据处理请求确定与所述数据处理请求对应的元数据节点;
所述代理节点还用于向所述元数据节点发送所述数据处理请求;
元数据节点,用于响应所述数据处理请求而反馈报文至所述客户端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810245832.8A CN110309101B (zh) | 2018-03-23 | 2018-03-23 | 一种数据管理方法及Hadoop分布式文件系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810245832.8A CN110309101B (zh) | 2018-03-23 | 2018-03-23 | 一种数据管理方法及Hadoop分布式文件系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110309101A true CN110309101A (zh) | 2019-10-08 |
CN110309101B CN110309101B (zh) | 2021-08-31 |
Family
ID=68073527
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810245832.8A Active CN110309101B (zh) | 2018-03-23 | 2018-03-23 | 一种数据管理方法及Hadoop分布式文件系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110309101B (zh) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102253869A (zh) * | 2010-05-19 | 2011-11-23 | 微软公司 | 可缩放的容错元数据服务 |
CN103036994A (zh) * | 2012-12-18 | 2013-04-10 | 曙光信息产业(北京)有限公司 | 实现负载均衡的云存储系统 |
CN104881443A (zh) * | 2015-05-14 | 2015-09-02 | 新浪网技术(中国)有限公司 | 一种在数据库间迁移数据的方法和系统 |
CN105677736A (zh) * | 2015-12-29 | 2016-06-15 | 曙光信息产业(北京)有限公司 | 一种增加、删除服务器节点的方法及装置 |
US9449008B1 (en) * | 2014-03-31 | 2016-09-20 | Amazon Technologies, Inc. | Consistent object renaming in distributed systems |
CN106131227A (zh) * | 2016-08-31 | 2016-11-16 | 浪潮(北京)电子信息产业有限公司 | 负载平衡方法、元数据服务器系统及负载平衡系统 |
CN106559448A (zh) * | 2015-09-28 | 2017-04-05 | 北京国双科技有限公司 | 服务器负载均衡方法和装置 |
-
2018
- 2018-03-23 CN CN201810245832.8A patent/CN110309101B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102253869A (zh) * | 2010-05-19 | 2011-11-23 | 微软公司 | 可缩放的容错元数据服务 |
CN103036994A (zh) * | 2012-12-18 | 2013-04-10 | 曙光信息产业(北京)有限公司 | 实现负载均衡的云存储系统 |
US9449008B1 (en) * | 2014-03-31 | 2016-09-20 | Amazon Technologies, Inc. | Consistent object renaming in distributed systems |
CN104881443A (zh) * | 2015-05-14 | 2015-09-02 | 新浪网技术(中国)有限公司 | 一种在数据库间迁移数据的方法和系统 |
CN106559448A (zh) * | 2015-09-28 | 2017-04-05 | 北京国双科技有限公司 | 服务器负载均衡方法和装置 |
CN105677736A (zh) * | 2015-12-29 | 2016-06-15 | 曙光信息产业(北京)有限公司 | 一种增加、删除服务器节点的方法及装置 |
CN106131227A (zh) * | 2016-08-31 | 2016-11-16 | 浪潮(北京)电子信息产业有限公司 | 负载平衡方法、元数据服务器系统及负载平衡系统 |
Also Published As
Publication number | Publication date |
---|---|
CN110309101B (zh) | 2021-08-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190303382A1 (en) | Distributed database systems and methods with pluggable storage engines | |
CN109947668B (zh) | 存储数据的方法和装置 | |
CN102708165B (zh) | 分布式文件系统中的文件处理方法及装置 | |
US20170220614A1 (en) | Consistent ring namespaces facilitating data storage and organization in network infrastructures | |
US8990243B2 (en) | Determining data location in a distributed data store | |
CN109726174A (zh) | 数据归档方法、系统、设备以及存储介质 | |
CN101944124A (zh) | 分布式文件系统管理方法、装置以及对应的文件系统 | |
CN103970807B (zh) | 数据库连接管理方法及系统 | |
US10579597B1 (en) | Data-tiering service with multiple cold tier quality of service levels | |
CN106326239A (zh) | 分布式文件系统及其文件元信息管理方法 | |
US10817203B1 (en) | Client-configurable data tiering service | |
CN110321225B (zh) | 负载均衡方法、元数据服务器及计算机可读存储介质 | |
CN102739622A (zh) | 一种可扩展的数据存储系统 | |
CN105005611A (zh) | 一种文件管理系统及文件管理方法 | |
CN102810108A (zh) | 重复数据的处理方法 | |
CN113806300A (zh) | 数据存储方法、系统、装置、设备及存储介质 | |
CN109684270A (zh) | 数据库归档方法、装置、系统、设备及可读存储介质 | |
US10956125B2 (en) | Data shuffling with hierarchical tuple spaces | |
US9449036B2 (en) | Handling an increase in transactional data without requiring relocation of preexisting data between shards | |
CN101483668A (zh) | 热点数据的网络存储和访问方法、设备及系统 | |
CN112540954B (zh) | 以目录单位的多级存储构建与在线迁移方法 | |
CN111274004A (zh) | 进程实例管理方法、装置及计算机存储介质 | |
CN110309101A (zh) | 一种数据管理方法及Hadoop分布式文件系统 | |
CN103970671B (zh) | 用于在存储器中分配管理数据集的系统和方法 | |
CN109408467A (zh) | 一种实现数据存储的方法及装置 |
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 |