CN109889561A - 一种数据处理方法及装置 - Google Patents
一种数据处理方法及装置 Download PDFInfo
- Publication number
- CN109889561A CN109889561A CN201711424094.5A CN201711424094A CN109889561A CN 109889561 A CN109889561 A CN 109889561A CN 201711424094 A CN201711424094 A CN 201711424094A CN 109889561 A CN109889561 A CN 109889561A
- Authority
- CN
- China
- Prior art keywords
- namenode
- target
- client
- reading
- shared drive
- 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.)
- Pending
Links
Abstract
本发明提供一种数据处理方法及装置,所述方法包括:当接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。应用本发明可以提高HDFS HA集群的处理性能,避免性能瓶颈的产生,降低对部署NameNode的服务器的硬件配置的需求。
Description
技术领域
本发明涉及大数据技术领域,尤其涉及一种数据处理方法及装置。
背景技术
HDFS(Hadoop Distributed File System,Hadoop分布式文件系统)是一个主/从(Master/Slave)体系结构,一个HDFS集群由一个NameNode(名字节点)和多个DataNode(数据节点)组成。NameNode为元数据节点,管理文件系统的元数据,DataNode为数据节点,存储实际的文件数据。
由于在HDFS中NameNode只有一个,因此NameNode的可靠性是影响HDFS可靠性的重要因素。
目前,提高HDFS可靠性的主要实现方案是HDFS HA(High Available,高可用性)集群方案,其主要实现原理为:
在HDFS HA集群中,将两台独立的机器配置为NameNode(检测NN)节点,在任何时间点只有一台NN节点处于Active(活跃)状态,另一台NN节点处于Standby(备用)状态。Active状态的NN节点负责所有的客户端操作。处于Standby状态的NN节点的元数据与Active状态的NN节点保持一致,并且当Active状态的NN节点无法对外提供服务时,Active状态的NN节点将接替Active NameNode工作。
然而实践发现,在现有HDFS HA集群方案中,仅有Active状态的NN节点提供服务,而Standby状态的NN节点不提供服务,HDFS HA集群处理性能较差,且单台NN节点的性能容易形成性能瓶颈。
发明内容
本发明提供一种数据处理方法及装置,以解决现有HDFS HA集群处理性能较差,且容易出现性能瓶颈的问题。
根据本发明实施例的第一方面,提供一种数据处理方法,应用于HDFS HA集群中的Zookeeper集群中的Zookeeper,所述HDFS HA集群中还包括多个NameNode,所述方法包括:
当接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;
将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
根据本发明实施例的第二方面,提供一种数据处理方法,应用于HDFS HA集群中的NameNode,所述HDFS HA集群中包括Zookeeper集群以及多个所述NameNode,所述方法包括:
接收客户端发送的数据读写请求;
响应所述数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
根据本发明实施例的第三方面,提供一种数据处理装置,应用于HDFS HA集群中的Zookeeper集群中的Zookeeper,所述HDFS HA集群中还包括多个NameNode,所述装置包括:
接收单元,用于接收客户端发送的NameNode访问请求;
选择单元,用于当所述接收单元接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;
发送单元,用于将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
根据本发明实施例的第四方面,提供一种数据处理装置,应用于HDFS HA集群中的NameNode,所述HDFS HA集群中还包括Zookeeper集群以及多个所述NameNode,所述装置包括:
接收单元,用于接收客户端发送的数据读写请求;
处理单元,用于响应所述数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
应用本发明实施例,通过使用共享内存层存储元数据,HDFS HA集群中多个NameNode均可以根据共享内存层中存储的元数据对外提供服务,当Zookeeper接收到客户端发送的NameNode访问请求时,从多个NameNode中选择用于提供服务的目标NameNode,并将目标NameNode的地址信息发送给客户端,以使客户端向目标NameNode发起读写请求;目标NameNode接收到客户端发起的读写请求时,可以响应客户端发起的数据读写请求对共享内存层中存储的元数据进行数据读写处理,提高了HDFS HA集群的处理性能,避免了性能瓶颈的产生,降低了对部署NameNode的服务器的硬件配置的需求。
附图说明
图1是本发明实施例提供的一种HDFSHA集群的架构示意图;
图2是本发明实施例提供的一种数据处理方法的流程示意图;
图3是本发明实施例提供的一种数据处理方法的流程示意图;
图4是本发明实施例提供的一种数据处理装置的结构示意图;
图5是本发明实施例提供的另一种数据处理装置的结构示意图;
图6为本发明实施例提供的一种数据处理装置的硬件结构示意图;
图7是本发明实施例提供的一种数据处理装置的结构示意图;
图8为本发明实施例提供的一种数据处理装置的硬件结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明实施例中的技术方案,并使本发明实施例的上述目的、特征和优点能够更加明显易懂,下面结合附图对本发明实施例中技术方案作进一步详细的说明。
请参见图1,为本发明实施例提供的一种HDFS HA集群的架构示意图,如图1所示,该HDFS HA集群包括Zookeeper集群、多个NameNode以及多个DataNode;其中:
NameNode启动时,需要向Zookeeper注册,并与Zookeeper维持一个会话;Zookeeper根据该会话监测NameNode的可用性;
HDFS HA集群中首个NameNode初次启动时,需要初始化元数据至共享内存层;后续,HDFS HA集群中所有NameNode均可以对共享内存层进行读写;其中,NameNode对共享内层的写操作为原子操作。
当客户端需要进行数据读写时,需要先向Zookeeper发送NameNode访问请求,由Zookeeper从多个NameNode中选择用于提供服务的NameNode(本文中称为目标NameNode);
Zookeeper选定目标NameNode后,可以将目标NameNode的地址信息发送给客户端,由客户端向目标NameNode发起数据读写请求;
目标NameNode接收到客户端发送的数据读写请求时,可以根据共享内存层中存储的元数据响应客户端的数据读写请求。
其中,客户端获取到目标NameNode的地址信息之后,向目标NameNode发起数据读写请求,以及目标NameNode响应数据读写请求的具体处理流程可以参见图3所示方法流程中的相关描述,本发明实施例对此不做赘述。
可见,在本发明实施例中,HDFS HA集群中多个NameNode不存在主备之分,均可以提供服务,提高了HDFS HA集群的处理性能,并避免了性能瓶颈的产生;此外,通过使用共享内存层存储元数据,降低了对部署NameNode的服务器的硬件配置的需求。
请参见图2,为本发明实施例提供的一种数据处理方法的流程示意图,其中,该数据处理方法可以应用于图1中的Zookeeper,如图2所示,该数据处理方法可以包括:
步骤201、当接收到客户端发送的NameNode访问请求时,从多个NameNode中选择用于提供服务的目标NameNode。
本发明实施例中,当客户端需要进行数据读写时,客户端需要先向Zookeeper发送NameNode访问请求,以请求Zookeeper分配用于提供服务的目标NameNode。
Zookeeper接收到客户端发送的NameNode访问请求时,可以按照预设策略从HDFSHA集群中的多个NameNode中选择用于提供服务的目标NameNode。
例如,Zookeeper可以采集随机选择的方式从多个NameNode中选择用于提供服务的目标NameNode;或,采用轮询的方式从多个NameNode中选择用于提供服务的目标NameNode;或,从多个NameNode中选择负载最低的NameNode作为目标NameNode。
本发明实施例中,Zookeeper确定了用于向客户端提供服务的目标NameNode之后,可以将目标NameNode的地址信息发送给客户端。
步骤202、将目标NameNode的地址信息发送给客户端,以使目标NameNode响应客户端发起的数据读写请求对共享内存层中存储的元数据进行数据读写处理。
本发明实施例中,Zookeeper确定了用于提供服务的目标NameNode之后,可以将目标NameNode的地址信息发送给客户端;客户端接收到目标NameNode的地址信息之后,可以根据目标NameNode的地址信息向目标NameNode发起数据读写请求。
目标NameNode接收到客户端发起的数据读写请求时,可以响应客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。其中,目标NameNode响应数据读写请求的具体实现可以参见图3所示方法流程中的相关描述,本发明实施例在此不做赘述。
可见,在本发明实施例中,HDFS HA集群中各NameNode之间不存在主备关系,以对等的身份向客户端提供服务,提高了HDFS HA集群的处理性能,避免了性能瓶颈的产生。
进一步地,在本发明其中一个实施例中,上述将目标NameNode的地址信息发送给客户端之后,还可以包括:
当检测到目标NameNode故障时,从其他NameNode中选择另一目标NameNode;
将该另一目标NameNode的地址信息发送给客户端,以使该另一目标NameNode替代该目标NameNode响应客户端发起的数据读写请求。
在该实施例中,当目标NameNode在响应客户端的数据读写请求的过程中出现故障时,Zookeeper会检测到NameNode不可用(通过Zookeeper与NameNode之间的会话实现),此时Zookeeper可以从HDFS HA集群中其它的NameNode(可用NameNode)中重新选择用于为客户端提供服务的NameNode(本文中称为另一目标NameNode),并将另一目标NameNode的地址信息发送给客户端,由该另一目标NameNode替代目标NameNode响应客户端发起的数据读写请求。
可见,在本发明实施例中,当NameNode出现故障时,不需要进行主备切换,即可使用其它NameNode继续提供服务,实现了无状态HA,降低了NameNode故障对文件操作的影响。
请参见图3,为本发明实施例提供的一种数据处理方法的流程示意图,其中,该数据处理方法可以应用于图1中的NameNode,如图3所示,该数据处理方法可以包括:
为便于描述,下文中以步骤301~步骤302的执行主体为目标NameNode为例进行说明。
步骤301、接收客户端发送的数据读写请求。
本发明实施例中,客户端获取提供服务的NameNode的地址信息的具体实现可以参见图2所示方法流程中的相关描述,本发明实施例对此不再赘述。
本发明实施例中,客户端获取到用于提供服务的NameNode(即目标NameNode)之后,可以向目标NameNode发送数据读写请求。
步骤302、响应该数据读写请求对共享内存层中存储的元数据进行数据读写处理。
本发明实施例中,由于HDFS HA集群中各NameNode以对等身份对外提供服务,即各NameNode均可能会对元数据进行修改,若各NameNode均各自进行元数据管理,则每次元数据的修改均需要触发各NameNode节点之间的元数据同步,影响HDFS HA集群的处理性能,且提高了对部署NameNode的服务器的硬件配置的需求;同时,若各NameNode均各自进行元数据管理,则HDFS HA集群保存的文件数量受单个NameNode的内存大小的影响较大,容易导致HDFS HA集群保存的文件数量较低,或对部署NameNode的服务器的硬件配置需要较高,因此,本发明实施例中通过共享内存层对元数据进行存储,各NameNode不再各自维护元数据,而是共同对共享内存层中的元数据进行管理,以提高HDFS HA集群的处理性能,并降低对部署NameNode的服务器的硬件配置的需求。
相应地,在本发明实施例中,当目标NameNode接收到客户端发送的数据读写请求时,可以响应该数据读写请求对共享内存层中存储的元数据进行数据读写处理。
具体地,对于数据读取请求,目标NameNode可以响应该数据读取请求查询共享内存层中存储的元数据,其中,该元数据可以包括待读取数据与block的对应关系,以及block与DataNode的对应关系。
相应地,当目标DataNode通过查询共享内存层中的元数据确定了待读取的数据的block列表,以及block对应的DataNode时,可以将查询到的DataNode的地址信息返回给客户端。
对于任一block,客户端从保存有该block的DataNode中选择与客户端最近的DataNode读取block的数据。其中,若对于某一block,保存有该block的DataNode中存在与客户端部署于同一服务器的DataNode,则客户端将从本地直接读取该block的数据。
客户端读取完当前block的数据后,关闭与当前的DataNode连接,并选择用于读取下一个block的数据的DataNode。
客户端每读取完一个block的数据,都会对所读取的数据进行checksum(校验和)验证;若验证不通过,则客户端会通知NameNode,然后从其余保存有该block的数据的DataNode中重新选择用于读取该block的数据的DataNode,并进行数据读取。
当客户端成功完成文件读取后,会关闭输入流。
对于数据写入请求,目标NameNode可以响应该数据读请求查询共享内存层中存储的元数据。其中,HDFS系统中数据写入以写文件的方式实现,而元数据中包括系统中已存在的文件的信息,以及文件创建的权限信息,因此,目标NameNode可以根据共享内存层中的元数据确定是否允许此次数据写入操作。
相应地,当目标NameNode根据共享内存层中的元数据确定允许此次数据写入操作时,客户端将文件切分成多个packet(包),以“dataqueue(数据队列)”的形式管理这些packet,然后向NameNode申请新的blocks,获取用来存储replicas(副本)的DataNode列表,DataNode列表的大小根据在NameNode中对block副本数的设置而定,这个DataNode列表形成一个pipeline(管道);例如,假设副本数为3,则pipeline中存在3个DataNode。
客户端将packet以流的方式写入pipeline中的第一个DataNode,该DataNode把该packet存储之后,再将其传递给在此pipeline中的下一个DataNode,直到最后一个DataNode。
最后一个DataNode成功存储packet之后会返回一个ackpacket(确认包),该ackpacket在pipeline里传递至客户端,客户端会从其维护的“ack queue(确认队列)”,并移除相应的packet。
当客户端完成了整个文件中所有block的写操作之后,关闭输入流,并通知NameNode提交这个文件中的所有block。
需要说明的是,在本发明实施例中,当目标NameNode接收到的数据读写请求为数据写入请求时,则在完成数据写入之后,目标NameNode需要将写入文件与所分配的block的对应关系,以及所分配的block与归属的DataNode的对应关系更新到共享内存层中存储的元数据中。由于HDFS HA集群中各NameNode均可以对等身份对外提供服务,因此,为了避免多个NameNode对共享内存层中存储的元数据的更新操作产生冲突,需要将NameNode对共享内存层中存储的元数据的更新操作设置为原子操作,以避免同一时间内多个NameNode更新共享内存层中的同一元数据。
可见,在本发明实施例中,通过使用共享内存层存储元数据,HDFS HA集群中多个NameNode均可以对共享内存层中存储的元数据进行读写,且该多个NameNode可以根据共享内存层中存储的元数据以对等身份对外提供服务,提高了HDFS HA集群的处理性能,避免了性能瓶颈的产生,降低了对部署NameNode的服务器的硬件配置的需求。
此外,由于元数据存储在共享内存层中,非首个NameNode启动时,无需解析EditLog(日志)和FsImage(文件镜像)以生成元数据,从而,可以提高NameNode的启动效率,进一步提高HDFS HA集群的处理性能。
在本发明其中一个实施例中,上述接收客户端发送的数据读写请求之前,还可以包括:
当NameNode启动,且确定共享内存层中不存在元数据时,将元数据初始化至共享内存层。
在该实施例中,当HDFS HA集群中首个NameNode初次启动时,需要初始化元数据至共享内存层。
相应地,在该实施例中,目标NameNode启动时,需要确定共享内存层中是否存在元数据。
若目标NameNode确定共享内存层中不存在元数据,则目标NameNode可以确定自身为最先启动的NameNode,此时,目标NameNode可以初始化相关元数据至共享内存层。
其中,在本发明实施例中,NameNode初始化元数据至共享内存层的具体实现可以参见现有HDFS系统中NameNode初次启动时初始化元数据至本地内存的相关实现,本发明实施例对此不做赘述。
在该实施例中,若目标NameNode确定共享内存层中存在元数据,则目标NameNode可以根据需求对共享内存层中的元数据进行读写。
其中,NameNode对共享内存层中的元数据的写入操作为原子操作。
在本发明其中一个实施例中,上述共享内存层为Alluxio共享内存层。
在该实施例中,通过Alluxio(一个基于内存的分布式文件系统)系统架构对共享内存层中的元数据进行管理,HDFS HA集群中各NameNode可以作为Allulxio系统架构中的client对共享内存层中存储的元数据进行操作,其具体实现可以参见现有Alluxio技术中的相关描述,本发明实施例在此不做赘述。
应该认识到,在本发明实施例中,通过Alluxio系统架构对共享内存层中的元数据进行管理仅仅是本发明实施例中对共享内存层中的元数据进行管理的一种具体示例,而不是对本发明保护范围的限定,即在本发明实施例中,也可以通过其它方式对共享内存层中的元数据进行管理,例如,上述共享内存层也可以为Redis共享内存层,即通过Redis(一种开源数据库)系统架构对共享内存层中的元数据进行管理,其具体实现在此不做赘述。
进一步地,在本发明实施例中,当内存共享层出现内存不足的情况时,如剩余内存低于预设容量阈值,或内存使用比例超过预设比例阈值等,共享内存层可以根据预先配置的策略,对指定元数据进行本地文件持久化处理,而不加载至内存,以节省内存空间。
例如,可以将最近一次更新的时间与当前系统时间的差值超过预设时间阈值的元数据以文件的形式保存至服务器的磁盘中。
通过以上描述可以看出,在本发明实施例提供的技术方案中,通过使用共享内存层存储元数据,HDFS HA集群中多个NameNode均可以根据共享内存层中存储的元数据对外提供服务,当Zookeeper接收到客户端发送的NameNode访问请求时,从多个NameNode中选择用于提供服务的目标NameNode,并将目标NameNode的地址信息发送给客户端,以使客户端向目标NameNode发起读写请求;目标NameNode接收到客户端发起的读写请求时,可以响应客户端发起的数据读写请求对共享内存层中存储的元数据进行数据读写处理,提高了HDFSHA集群的处理性能,避免了性能瓶颈的产生,降低了对部署NameNode的服务器的硬件配置的需求。
请参见图4,为本发明实施例提供的一种数据处理装置的结构示意图,其中,所述装置可以应用于上述方法实施例中的Zookeeper,如图4所示,该数据处理置可以包括:
接收单元410,用于接收客户端发送的NameNode访问请求;
选择单元420,用于当所述接收单元420接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;
发送单元430,用于将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
请一并参见图5,为本发明实施例提供的另一种数据处理装置的结构示意图,如图5所示,在图4所示数据处理装置的基础上,图5所示的数据处理装置还包括:
检测单元440,用于检测NameNode是否故障;
所述选择单元420,还用于当所述检测单元440检测到所述目标NameNode故障时,从其他NameNode中选择另一目标NameNode;
所述发送单元430,还用于将所述另一目标NameNode的地址信息发送给所述客户端,以使所述另一目标NameNode替代所述目标NameNode响应所述客户端发起的数据读写请求。
图6为本公开示例提供的一种数据处理装置的硬件结构示意图。该数据处理装置可包括处理器601、存储有机器可执行指令的机器可读存储介质602。处理器601与机器可读存储介质602可经由系统总线603通信。并且,通过读取并执行机器可读存储介质602中与数据处理逻辑对应的机器可执行指令,处理器601可执行图2所示的数据处理方法。
本文中提到的机器可读存储介质602可以是任何电子、磁性、光学或其它物理存储装置,可以包含或存储信息,如可执行指令、数据,等等。例如,机器可读存储介质可以是:RAM(RadomAccess Memory,随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等),或者类似的存储介质,或者它们的组合。
请参见图7,为本发明实施例提供的一种数据处理装置的结构示意图,其中,所述装置可以应用于上述方法实施例中的NameNode,如图7所示,该数据处理置可以包括:
接收单元710,用于接收客户端发送的数据读写请求;
处理单元720,用于根据所述数据读写请求查询共享内存层中存储的元数据,并根据查询结果响应所述客户端的读写查询请求。
在可选实施例中,所述处理单元720,还用于当所述NameNode启动,且确定所述共享内存层中不存在元数据时,将元数据初始化至所述共享内存层。
在可选实施例中,所述共享内存层为Alluxio共享内存层。
图8为本公开示例提供的一种数据处理装置的硬件结构示意图。该数据处理装置可包括处理器801、存储有机器可执行指令的机器可读存储介质802。处理器801与机器可读存储介质802可经由系统总线803通信。并且,通过读取并执行机器可读存储介质802中与数据处理逻辑对应的机器可执行指令,处理器801可执行图3所示的数据处理方法。
本文中提到的机器可读存储介质802可以是任何电子、磁性、光学或其它物理存储装置,可以包含或存储信息,如可执行指令、数据,等等。例如,机器可读存储介质可以是:RAM、易失存储器、非易失性存储器、闪存、存储驱动器、固态硬盘、任何类型的存储盘,或者类似的存储介质,或者它们的组合。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
由上述实施例可见,通过使用共享内存层存储元数据,HDFS HA集群中多个NameNode均可以根据共享内存层中存储的元数据对外提供服务,当Zookeeper接收到客户端发送的NameNode访问请求时,从多个NameNode中选择用于提供服务的目标NameNode,并将目标NameNode的地址信息发送给客户端,以使客户端向目标NameNode发起读写请求;目标NameNode接收到客户端发起的读写请求时,可以响应客户端发起的数据读写请求对共享内存层中存储的元数据进行数据读写处理,提高了HDFS HA集群的处理性能,避免了性能瓶颈的产生,降低了对部署NameNode的服务器的硬件配置的需求。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求指出。
应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。
Claims (10)
1.一种数据处理方法,其特征在于,应用于Hadoop分布式文件系统HDFS高可用性HA集群中的Zookeeper集群中的Zookeeper,所述HDFS HA集群中还包括多个名字节点NameNode,所述方法包括:
当接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;
将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
2.根据权利要求1所述的方法,其特征在于,所述将所述目标NameNode的地址信息发送给所述客户端之后,还包括:
当检测到所述目标NameNode故障时,从其他NameNode中选择另一目标NameNode;
将所述另一目标NameNode的地址信息发送给所述客户端,以使所述另一目标NameNode替代所述目标NameNode响应所述客户端发起的数据读写请求。
3.一种数据处理方法,其特征在于,应用于Hadoop分布式文件系统HDFS高可用性HA集群中的名字节点NameNode,所述HDFS HA集群中包括Zookeeper集群以及多个所述NameNode,所述方法包括:
接收客户端发送的数据读写请求;
响应所述数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
4.根据权利要求3所述的方法,其特征在于,所述接收客户端发送的数据读写请求之前,还包括:
当所述NameNode启动,且确定所述共享内存层中不存在元数据时,将元数据初始化至所述共享内存层。
5.根据权利要求3或4所述的方法,其特征在于,所述共享内存层为Alluxio共享内存层。
6.一种数据处理装置,其特征在于,应用于Hadoop分布式文件系统HDFS高可用性HA集群中的Zookeeper集群中的Zookeeper,所述HDFS HA集群中还包括多个名字节点NameNode,所述装置包括:
接收单元,用于接收客户端发送的NameNode访问请求;
选择单元,用于当所述接收单元接收到客户端发送的NameNode访问请求时,从所述多个NameNode中选择用于提供服务的目标NameNode;
发送单元,用于将所述目标NameNode的地址信息发送给所述客户端,以使所述目标NameNode响应所述客户端发起的数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
7.根据权利要求6所述的装置,其特征在于,所述装置还包括:
检测单元,用于检测NameNode是否故障;
所述选择单元,还用于当所述检测单元检测到所述目标NameNode故障时,从其他NameNode中选择另一目标NameNode;
所述发送单元,还用于将所述另一目标NameNode的地址信息发送给所述客户端,以使所述另一目标NameNode替代所述目标NameNode响应所述客户端发起的数据读写请求。
8.一种数据处理装置,其特征在于,应用于Hadoop分布式文件系统HDFS高可用性HA集群中的名字节点NameNode,所述HDFS HA集群中还包括Zookeeper集群以及多个所述NameNode,所述装置包括:
接收单元,用于接收客户端发送的数据读写请求;
处理单元,用于响应所述数据读写请求对所述共享内存层中存储的元数据进行数据读写处理。
9.根据权利要求8所述的装置,其特征在于,
所述处理单元,还用于当所述NameNode启动,且确定所述共享内存层中不存在元数据时,将元数据初始化至所述共享内存层。
10.根据权利要求8或9所述的装置,其特征在于,所述共享内存层为Alluxio共享内存层。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711424094.5A CN109889561A (zh) | 2017-12-25 | 2017-12-25 | 一种数据处理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711424094.5A CN109889561A (zh) | 2017-12-25 | 2017-12-25 | 一种数据处理方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109889561A true CN109889561A (zh) | 2019-06-14 |
Family
ID=66924722
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201711424094.5A Pending CN109889561A (zh) | 2017-12-25 | 2017-12-25 | 一种数据处理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109889561A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111309805A (zh) * | 2019-12-13 | 2020-06-19 | 华为技术有限公司 | 数据库的数据读写方法及装置 |
CN113127420A (zh) * | 2021-03-30 | 2021-07-16 | 山东英信计算机技术有限公司 | 一种元数据请求处理方法、装置、设备、介质 |
CN114780293A (zh) * | 2022-04-26 | 2022-07-22 | 北京科杰科技有限公司 | 基于hadoop的异地双活容灾方法、装置、设备和可读存储介质 |
WO2023207492A1 (zh) * | 2022-04-29 | 2023-11-02 | 济南浪潮数据技术有限公司 | 一种数据处理方法、装置、设备及可读存储介质 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102929667A (zh) * | 2012-10-24 | 2013-02-13 | 曙光信息产业(北京)有限公司 | 一种hadoop集群性能的优化方法 |
CN103491192A (zh) * | 2013-09-30 | 2014-01-01 | 北京搜狐新媒体信息技术有限公司 | 一种分布式系统的Namenode切换方法和系统 |
CN103986789A (zh) * | 2014-06-05 | 2014-08-13 | 浪潮电子信息产业股份有限公司 | 一种实现基于nfs的hadoop ha集群中nfs节点双机冗余的方法 |
CN104461792A (zh) * | 2014-12-03 | 2015-03-25 | 浪潮集团有限公司 | 一种解决hadoop分布式文件系统namenode单点故障的ha方法 |
CN104951475A (zh) * | 2014-03-31 | 2015-09-30 | 中国电信股份有限公司 | 分布式文件系统和实现方法 |
CN105554130A (zh) * | 2015-12-18 | 2016-05-04 | 深圳中兴网信科技有限公司 | 基于分布式存储系统的NameNode切换方法和切换装置 |
CN107368490A (zh) * | 2016-05-12 | 2017-11-21 | 中国移动通信集团河北有限公司 | 数据处理方法及装置 |
CN108259608A (zh) * | 2018-01-19 | 2018-07-06 | 中国科学院生态环境研究中心 | 一种多智能体集群运算方法 |
-
2017
- 2017-12-25 CN CN201711424094.5A patent/CN109889561A/zh active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102929667A (zh) * | 2012-10-24 | 2013-02-13 | 曙光信息产业(北京)有限公司 | 一种hadoop集群性能的优化方法 |
CN103491192A (zh) * | 2013-09-30 | 2014-01-01 | 北京搜狐新媒体信息技术有限公司 | 一种分布式系统的Namenode切换方法和系统 |
CN104951475A (zh) * | 2014-03-31 | 2015-09-30 | 中国电信股份有限公司 | 分布式文件系统和实现方法 |
CN103986789A (zh) * | 2014-06-05 | 2014-08-13 | 浪潮电子信息产业股份有限公司 | 一种实现基于nfs的hadoop ha集群中nfs节点双机冗余的方法 |
CN104461792A (zh) * | 2014-12-03 | 2015-03-25 | 浪潮集团有限公司 | 一种解决hadoop分布式文件系统namenode单点故障的ha方法 |
CN105554130A (zh) * | 2015-12-18 | 2016-05-04 | 深圳中兴网信科技有限公司 | 基于分布式存储系统的NameNode切换方法和切换装置 |
CN107368490A (zh) * | 2016-05-12 | 2017-11-21 | 中国移动通信集团河北有限公司 | 数据处理方法及装置 |
CN108259608A (zh) * | 2018-01-19 | 2018-07-06 | 中国科学院生态环境研究中心 | 一种多智能体集群运算方法 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111309805A (zh) * | 2019-12-13 | 2020-06-19 | 华为技术有限公司 | 数据库的数据读写方法及装置 |
WO2021114848A1 (zh) * | 2019-12-13 | 2021-06-17 | 华为技术有限公司 | 数据库的数据读写方法及装置 |
CN111309805B (zh) * | 2019-12-13 | 2023-10-20 | 华为技术有限公司 | 数据库的数据读写方法及装置 |
US11868333B2 (en) | 2019-12-13 | 2024-01-09 | Huawei Technologies Co., Ltd. | Data read/write method and apparatus for database |
CN113127420A (zh) * | 2021-03-30 | 2021-07-16 | 山东英信计算机技术有限公司 | 一种元数据请求处理方法、装置、设备、介质 |
CN114780293A (zh) * | 2022-04-26 | 2022-07-22 | 北京科杰科技有限公司 | 基于hadoop的异地双活容灾方法、装置、设备和可读存储介质 |
WO2023207492A1 (zh) * | 2022-04-29 | 2023-11-02 | 济南浪潮数据技术有限公司 | 一种数据处理方法、装置、设备及可读存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11570255B2 (en) | SMB2 scaleout | |
KR102193012B1 (ko) | 분산 처리 시스템 및 이의 동작 방법 | |
CN109889561A (zh) | 一种数据处理方法及装置 | |
KR101700667B1 (ko) | 스토리지 네트워크 데이터 할당 | |
US8151062B2 (en) | Consistency models in a distributed store | |
US9917884B2 (en) | File transmission method, apparatus, and distributed cluster file system | |
US9229751B2 (en) | Apparatus and method for managing virtual memory | |
JP2012142012A5 (zh) | ||
CN109379448B (zh) | 一种文件分布式部署方法、装置、电子设备及存储介质 | |
CN105760556A (zh) | 低延时高吞吐量的多副本文件读写优化方法 | |
JP5503678B2 (ja) | ホスト提供システム及びホスト提供方法 | |
CN113282564B (zh) | 数据存储方法、系统、节点和存储介质 | |
CN108337116B (zh) | 消息保序方法及装置 | |
CN107566466A (zh) | 负载均衡方法及装置 | |
CN107948229B (zh) | 分布式存储的方法、装置及系统 | |
CN110012050A (zh) | 消息处理、存储方法、装置及系统 | |
CN107493309A (zh) | 一种分布式系统中的文件写入方法及装置 | |
US10474643B2 (en) | Distributed file system and method of creating files effectively | |
CN110337633A (zh) | 一种数据存储方法及设备 | |
CN107547605B (zh) | 一种基于节点队列的消息读写方法及节点设备 | |
CN115378799B (zh) | 基于PaxosLease算法的设备集群中的选举方法及装置 | |
US10409920B1 (en) | Data services for tiered memory | |
CN108804355B (zh) | 使用目标协作的快速排序写入的方法和系统 | |
KR102137217B1 (ko) | 비대칭 파일 시스템의 데이터 복제 방법 | |
US9330709B2 (en) | Tape library string request management |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190614 |
|
RJ01 | Rejection of invention patent application after publication |