CN110287150B - 一种大规模存储系统元数据分布式管理方法与系统 - Google Patents

一种大规模存储系统元数据分布式管理方法与系统 Download PDF

Info

Publication number
CN110287150B
CN110287150B CN201910405408.XA CN201910405408A CN110287150B CN 110287150 B CN110287150 B CN 110287150B CN 201910405408 A CN201910405408 A CN 201910405408A CN 110287150 B CN110287150 B CN 110287150B
Authority
CN
China
Prior art keywords
hdfs
file
data
storing
block
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.)
Active
Application number
CN201910405408.XA
Other languages
English (en)
Other versions
CN110287150A (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.)
Institute of Information Engineering of CAS
Original Assignee
Institute of Information Engineering of CAS
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 Institute of Information Engineering of CAS filed Critical Institute of Information Engineering of CAS
Priority to CN201910405408.XA priority Critical patent/CN110287150B/zh
Publication of CN110287150A publication Critical patent/CN110287150A/zh
Application granted granted Critical
Publication of CN110287150B publication Critical patent/CN110287150B/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/13File access structures, e.g. distributed indices
    • G06F16/134Distributed indices
    • 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/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164File meta data generation
    • 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

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)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种大规模存储系统元数据分布式管理方法与系统。本发明将HDFS存储于NameNode内存中的元数据抽象成二维表的结构,以二维表的形式存储在分布式数据库中;抽象后的各二维表之间通过inode_id相互关联。Namenode成为客户端存取元数据的桥梁,客户端首先连接Namenode,Namenode来操作分布式数据库中的元数据,并将元数据返回给客户端。本发明解决了HDFS的单点故障问题。

Description

一种大规模存储系统元数据分布式管理方法与系统
技术领域
本发明属于分布式数据存储技术领域,具体涉及一种大规模存储系统的元数据分布式管理与组织方法。
背景技术
随着大数据技术与应用、物联网以及云计算的迅猛发展,集中存储的数据量通常可以达到PB甚至EB级别。分布式文件系统是存储和管理大规模数据文件常用的解决方法。分布式文件系统利用多台机器搭建存储集群,数据的存储容量也随着机器数量线性增长。要支持大规模数据的存储,除了需要硬件支持外,元数据的管理技术也是必不可少的关键技术之一。HDFS(Hadoop Distributed File System)是最常见的分布式文件系统,但是HDFS将元数据存储在Namenode单台机器的内存上,限制了元数据存储空间的大小,也成为系统性能的瓶颈。Ceph是一款高性能、高可用、高扩展的分布式文件系统,提出了根据负载情况来动态划分元数据的动态子树划分法,动态地将负载较高节点上的元数据迁移到负载较低的节点上,实现了动态地负载均衡,但是当小文件数目较多时,Ceph扩展多个元数据服务节点还并不稳定,无法提供在线平滑扩容服务。GlusterFS利用弹性哈希算法取代了元数据管理服务,利用文件路径和文件名来计算文件的存储位置,从根本上解决了由于元数据服务导致的系统瓶颈问题,并且遍历效率低,当某个目录下的文件较多时,运行文件扫描、统计、遍历等操作会非常的缓慢。
基于分布式NewSQL数据库开展分布式元数据管理方面,也已经出现相关的研究成果。HopsFS是一款开源的分布式文件系统,它是在HDFS的基础上,将元数据存储在MysqlCluster分布式内存数据库中,以此来扩大元数据的存储容量。但是Mysql Cluster依然对机器的内存要求比较高,并且Mysql Cluster在数据表规模较大时,对数据表与数据分片管理灵活性差,一般是通过数据表分区的方式把每个表数据分布在所有的数据节点上,同时Mysql Cluster采用GPLv2开源协议,而本发明用的Postgres-XL采用BSD协议,更适合商业化的二次开发。
发明内容
针对现有技术中存在的技术问题,本发明的目的在于提供一种基于NewSQL的大规模存储系统元数据分布式管理方法与系统。
本发明提出基于Postgres-XL分布式数据库来存储分布式文件系统的元数据。Postgres-XL分布式关系型数据库既保持了ACID特性,又具有海量数据的存储能力。本发明利用Postgres-XL分布式关系型数据库,设计一种高可扩展性的元数据服务,将HDFS存储于单台机器的元数据抽象成二维表的形式,存储于分布式数据库中。相比于HDFS和HopsFS依赖于内存的大小的弊端,本发明的元数据存储空间更大。Postgres-XL是可扩展的、高可用的分布式数据库,数据分布在多台数据节点中,每台都可以设置相应的备用机器或者以多副本的形式存储,具备高可用性。因此利用Postgres-XL搭建的元数据服务集群也具有可扩展性和高可用性。
本发明将元数据全部存储在分布式数据库中,Namenode不再存储元数据。Namenode成为客户端存取元数据的桥梁,客户端首先连接Namenode,Namenode来操作分布式数据库中的元数据,并将元数据返回给客户端。由于Namenode不再存储元数据,因此本发明利用一组Namenode集群管理客户端会话,并与分布式数据库交互存取元数据,解决了HDFS的单点故障问题。
本发明利用Postgres-XL的特性提出合理高效的数据分片方法。当一个数据节点中存储的数据越多,性能将会越低,如何有效地将一个大表水平拆分存储到不同数据节点中是很有必要的。Postgres-XL支持两种数据分片方案:复制模式和分片模式。并且可以指定哪个表在哪些数据节点上使用哪种分片方案,因此可以根据自身应用特征合理划分数据,使得元数据的存取更加高效。
本发明利用Postgres-XL直接存储小文件的优化方法。海量小文件会大量占据元数据存储空间,造成元数据服务性能的下降,进而导致存储系统的性能下降。本发明将小文件直接存储在Postgres-XL分布式数据库中,简化小文件读写流程,提高小文件的存储效率。
附图说明
图1是本发明的整体架构图。
图2是本发明方法中元数据表的实体关系图,带下划线的属性是表的主键。
图3是本发明方法中的数据分片示意图。
图4为文件的写流程图。
图5为文件的读取流程图。
图6为并发创建文件的性能对比图。
图7为并发读取文件的性能对比图。
图8为小文件读取的性能对比图。
图9为小文件写入的性能对比图。
具体实施方式
本发明基于HopsFS设计思想,利用NewSQL关系数据库管理大规模存储系统中的元数据。本发明具体提出一种基于Postgres-XL分布式元数据存储管理方法,通过采用Postgres-XL分布式数据库扩展元数据的存储空间,并利用Postgres-XL的特性来提供灵活地元数据分片处理方案。
本发明的整体架构图如图1所示,在图1中,元数据服务集群中的各个组件就是Postgres-XL分布式数据库的组件,全局事物管理器保证整个集群的事务一致性;协调器主要是协调管理用户会话,解析优化SQL语句;数据节点是真正存储用户文件数据的节点。元数据服务集群中每个组件节点都可以配置多个数据节点以提高集群的可用性。然后是Namenode集群,Namenode集群由多个Namenode组成,其中有一个Leader Namenode,负责统一接收Datanode的块报告。每个Namenode都会封装一层DAL数据访问层的驱动,DAL主要负责与数据库交互,实现元数据的存取,主要是有数据库连接池、SQL语言编写的数据访问程序以及Postgresql的JDBC驱动程序。最底层的是由一组Datanode集群组成的数据存储层,是真正存储文件块数据的地方。
(1)分布式元数据建模方法与数据结构设计
HDFS只将元数据存储在NameNode单台机器的内存中,元数据的存储空间有限,NameNode也成为了整个系统的瓶颈。本发明为了扩大元数据的存储量,将HDFS存储于NameNode内存中的元数据抽象成二维表的结构,以二维表的形式存储在Postgres-XL分布式数据库中。图2是本发明方法中元数据表的实体关系图,带下划线的属性是表的主键,各二维表之间通过各自的inode_id相互关联(node_id是二维表的主键,通过主键进行多表关联),每个inode的全局唯一id,inode是指储存文件元数据的区域,中文译名为"索引节点"。下表是元数据表的说明。
表1元数据表的说明
Figure BDA0002061044040000031
Figure BDA0002061044040000041
(2)关系模型与集中式元数据结构对应关系
HDFS内存中的元数据主要包括两部分:Namespace和BlocksMap。Namespace用来存储分层的全局目录树以及目录树上各个节点的信息,目录树上每个节点表示的是某个目录或者某个文件,节点信息就是目录或文件的属性,例如名称、所属组、所属用户、访问权限、访问时间、数据大小等等。BlocksMap用来存储Block的信息以及每个副本与DataNode的映射关系。本发明将HDFS的Namespace中的INodeFile(文件节点,继承自INode类)和INodeDirectory(目录节点,继承自INode类)统一用hdfs_inodes表来表示,用hdfs_inodes表中的is_dir字段来区分是文件还是目录。对于HDFS另外一个重要的元数据BlocksMap,本发明用hdfs_block_infos和hdfs_replicas表来表示,hdfs_block_infos存储了Block的相关信息,hdfs_replicas存储了Block与物理DataNode的映射关系。对于Block和文件副本Replica的不同状态,也都有不同的表来对应。HDFS的租约是HDFS给予客户端写入文件的一个临时牌照,没有此临时牌照的客户端不允许操作该文件,避免了多个客户端同时写入同一个文件造成混乱的问题。本发明将租约用hdfs_lease_paths和hdfs_leases两个表来表示,hdfs_lease_paths记录具体某个文件与持有该文件租约的holder_id,hdfs_leases记录了holder_id对应的持有者信息。
(3)分布式元数据分片组织技术
Postgres-XL分布式数据库支持自定义字段分片,主要有两种模式:分片模式和复制模式。创建表的时候用DISTRIBUTE BY关键字指定需要作为分片的字段或分片模式,创建表的语句为:CREATE TableName(...)DISTRIBUTE BY HASH(col)|MODULO(col)|ROUNDROBIN|REPLICATION TO NODE(nodename[,...])。其中DISTRIBUTE BY后面如果是REPLICATION,则表示采用复制模式,一个表中的数据会以多个副本的形式存储在指定的节点上。除此之外的其它三种均为分片模式,分片模式将一个表的数据按照指定的规则将数据分布到指定的多个数据节点上,多个数据节点共同保存整个表的数据。分片模式共有三种规则:(1)如果后面是HASH(col),则表示采用哈希方式来分片;(2)如果后面是MODULO(col),则表示采用取模方式来分片;(3)如果后面是ROUNDROBIN,则表示采用轮询方式来分片。最后TO NODE关键字指定了数据具体分布在那些数据节点上,如果没有指定,那么就默认数据分布到所有的数据节点上。
本发明采用复制模式和哈希分片的组合模式来将数据分片到所有的数据节点中。本发明的元数据表中,hdfs_inodes表以及对应的hdfs_block_infos和hdfs_replicas占据了主要元数据存储空间,对于这些表,本发明采用哈希分片的方式将这些表中存储的元数据分片到每个数据节点上,如图3所示,其中PG-XL-DNi代表Postgres-XL分布式数据库的数据节点。对于hdfs_inodes表中的数据,设计了一个partition_id作为分片的字段,这个字段通常都等于parent_id字段,也就是父目录的id。因此同一个目录下子文件和子目录的Inode数据都存在同一个数据节点上,这有利于”ls”这样查询一层目录的操作。无论什么操作,都需要先从根目录开始,那么根目录所在的节点将会成为热点,因此将根目录在文件系统初始化时自动创建并缓存到各个NameNode上。但是这就导致根目录下的所有子文件和子目录都存放在同一台数据节点上,那么这台数据节点又成为了热点,因为所有路径必定会有根节点的子文件或者子目录。为了解决这个问题,本发明对于根目录的子文件和子目录采用随机分片,本发明中hdfs_inodes表中根目录的子目录和子文件采用随机分片的方式,也就是先判断当前路径的上一级是否为根目录,若是根目录则将partition_id等于一个随机值而不是等于parent_id,这样根目录的子文件或子目录将会分散于不同的数据节点。对于hdfs_block_infos和hdfs_replicas等表,则利用inode_id作为分片字段,这使得同一个Inode的相关元数据都存在同一个数据节点,避免跨不同节点查询。
对于其它的元数据表例如hdfs_small_file_inode_data、hdfs_lease_paths和hdfs_leases,数据规模不是很大,可以利用复制模式来存储。假设需要复制模式的副本数为2,那么创建表的时候可以指定该表的数据存储在哪两台数据节点上,由于数据量不多,单台机器可以在完全存储下整张表的数据情况下还能提供很好的性能,而多副本的方案也提高了数据可用性。
当需要增加一个数据节点到一个表的分布集群中时,可以利用ALTER TABLEtable_nameADD NODE(datanode_3)命令来增加一个节点。当需要删除一个数据节点时,可以利用ALTERTABLE table_name DELETE NODE(datanode_3)命令来删除某个表的一个数据节点。除此之外,还支持更改一个表的分布策略,例如从分片模式改为复制模式,更改的命令为ALTER TABLEtable_name DISSTRIBUTE BY REPLICATION。
(4)文件读写流程
1)文件的写流程
本发明将HDFS的Namenode内存中的元数据存储在分布式数据库中,主要修改了元数据的结构和存取方式。图4为文件的写流程图,其中DB表示数据库用来存储元数据,NameNode是元数据节点,负责管理客户端发起的会话并数据库进行交互,DataNode是数据节点用来存储实际的用户数据,DistributedFileSystem和FSDataOutputStream是Hadoop定义的方法中的两个对象,主要用于读写文件的操作,详细过程如下:
①客户端发起写文件请求;
②NameNode响应请求,在数据库hdfs_inodes表中插入一行表示一个空文件的inode,用于存储文件的属性,如文件名、权限、时间信息等;
③客户端通过对DistributedFileSystem对象调用create()来新建文件;DistributedFileSystem向客户端返回一个FSDataOutputStream对象,由此客户端可以开始写入数据。就像读取事件一样,FSDataOutputStream封装一个DFSOutputStream对象,该对象负责处理DataNode和NameNode之间通信;
④客户端开始写入文件数据,将文件按照128MB大小切分为Block,并向NameNode申请Block来存储数据;
⑤NameNode在数据库hdfs_block_infos表中插入一行表示正在构建的Block记录,在hdfs_replica_under_constructions表中插入数据记录该Block存储在哪台DataNode上,NameNode返回LocatedBlock对象,里面封装了DataNode列表,告诉客户端往那些DataNode中写入数据;
⑥客户端向DataNode中写入数据,数据以管道的形式写入到各个DataNode中;
⑦每个DataNode完成一个Block的写入后都会返回一个确认信息,数据全部写入完成后关闭资源;
⑧客户端向NameNode发送close命令,表示文件已经写入完成;
⑨NameNode将数据库中的元数据表中的状态转换为完成状态,需要更改状态的表有hdfs_inodes,hdfs_block_infos等。
2)文件的读流程
对于文件读取流程,需要先获取数据存储在哪些Datanode中,然后从Datanode中读取文件数据。图5为文件的读取流程图,其中DB表示数据库用来存储元数据,NameNode是元数据节点,负责管理客户端发起的会话并数据库进行交互,DataNode是数据节点用来存储实际的用户数据,DistributedFileSystem和FSDataOutputStream是Hadoop定义的方法中的两个对象,主要用于读写文件的操作,详细过程如下:
①客户端发起读文件请求
②NameNode响应请求,从数据库中获取该文件的Inode,根据从数据库中获取的inode的inode_id查询该文件的所有Block,每个Block与DataNode的映射信息封装在LocatedBlock对象中,最后LocatedBlock以列表的形式封装在DFSInputStream对象中;
③NameNode返回该DFSInputStream对象,供客户端读取数据;
④客户端根据LocatedBlock中的Datanode地址向相关的Datanode读取文件数据;
⑤文件所有Block读取完后,说明读取操作完成,关闭资源。
(5)海量小文件存储管理优化技术;
1)小文件优化技术
本发明利用Postgres-XL分布式数据库来存储元数据,Postgres-XL具有很高的扩展性,因此元数据的存储空间已经不再是问题。对于海量小文件问题,本发明直接用Postgres-XL分布式数据库来存储小文件的内容。为了保证数据的可用性以及可靠性,对于存储小文件内容的表hdfs_small_file_inode_data,可以采用复制模式的分区方案,利用多台机器以多副本的形式存储小文件的数据,如果条件允许,还可以专门指定几台机器只用来存储该表的数据,避免由于小文件太多或者频繁操作而影响集群中其它表的查询和写入性能。
首先需要在配置文件hdfs-site.xml中配置小文件的临界大小,在该配置文件中加入以下配置信息:
<property>
<name>dfs.store.small.files.in.db</name>
<value>true</value>
</property>
<property>
<name>dfs.db.file.max.size</name>
<value>65536</value>
</property>
上述dfs.store.small.files.in.db配置选项若设置为true,则表示开启小文件存入数据库中,若设置为false,则小文件都跟普通文件一样存入DataNode中。dfs.db.file.max.size配置项定义了小文件的临界大小,单位是字节,小于该临界大小的文件都直接存储到Postgres-XL分布式数据库中。
每个小文件和普通文件一样,在hdfs_inodes表中用一行来记录该小文件的相关信息。hdfs_inodes上的file_stored_in_db字段表示该文件是否是小文件,若值为1,则表示是小文件并且该文件的内容存储在数据库中,若该值为0,则表示是普通文件且该文件的内容以Block的形式存储在DataNode中。小文件的内容存储在表hdfs_small_file_inode_data中,该表只有三个字段组成:inode_id、dindex和data。inode_id是所有文件的唯一标识,通过inode_id可以在hdfs_inodes表中可以查找到该文件的所有属性。dindex表示文件块的序号,小文件会按照64KB大小切分成块,每块都在hdfs_small_file_inode_data表中插入一行数据,data字段中的数据就是文件块的数据。
2)小文件读写流程
本发明利用分布式数据库来直接存储小文件的数据,简化读写流程,减少RPC请求和网络通信的开销,以此来提高小文件的读写性能。
相比图4中的普通文件写入流程,小文件写入时在步骤④时将小文件的数据存储在本地缓存中,然后直接跳到步骤⑧,在关闭文件的时候将本地缓存的数据写入到数据库中,简化了小文件的写入流程。相比于图5中的普通文件读取流程,小文件读取时在步骤②根据Inode的属性判断该文件是否为小文件,若该文件为小文件,则虚构一个LocatedBlock对象,虚构的block_id小于0,并将小文件的数据存储在LocatedBlock对象中,最后LocatedBlock以列表的形式封装在DFSInputStream对象中。然后在步骤④中直接读取LocatedBlock的小文件数据,避免了再去Datanode中读取文件数据。
实验分析与结论
本实验只统计一定元数据空间内的文件数目,不计算目录的数量,那么HDFS内存中存储元数据的主要结构是INodeFile(保存文件属性)和BlockInfo(保存Block属性)这两个类的对象。假设集群中存储的每个文件需要2个Block和3个副本,文件名占8个字节,那么HDFS存储一个文件的元数据大约需要内存空间520bytes。本发明采用数据库来存储元数据,其中最主要的三个表分别是:hdfs_inodes、hdfs_block_infos和hdfs_replicas。本发明存储每个文件需要的元数据存储空间的大小为1366字节。下面从大规模元数据管理能力、并发读写效率、小文件读写效率测试三个方面说明系统性能的改进:
(1)大规模元数据管理能力测试与分析
表2给出了HDFS和本发明的数据存储规模。由于HDFS是将元数据存储在单台机器上的内存中,目前单台设备内存容量就在200GB左右,而本发明采用分布式数据库的形式来存储元数据,存储空间上限远远大于单机内存容量。所以HDFS虽然在元数据存储空间较少的时候能够存储更多的文件,但是本发明的元数据存储空间远大于单台机器的内存容量,最后文件存储数量的上限也远大于HDFS。
表2文件存储规模对比表
Figure BDA0002061044040000091
(2)并发读写效率测试
为了充分验证本发明在并发场景下元数据服务的性能,设计了创建空文件和读取文件这两种情况下的性能测试实验,对比了本发明和HDFS在并发场景下这两种情况的性能对比。图6和图7分别为并发场景下创建文件和读取文件的性能对比,其中每个线程表示一个客户端。从图中可以看到本研究发明在创建文件上比HDFS具有更好的性能。而在读取文件上,本发明在线程数较少的时候性能略低于HDFS,当时线程数较多时读取性能高于HDFS。
(3)小文件读写性能效率测试
本发明对比了在1、8、16、32、64个线程下同时读写小文件的性能,不论线程数是多少,小文件的恒定数量为8192个,每个小文件的大小为8KB。每个线程相当于一个客户端。图6和图7分别为小文件读取和写入的性能对比,从图中可以看出,开启小文件优化可以提升小文件的读写性能。
以上实施例仅用以说明本发明的技术方案而非对其进行限制,本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明的精神和范围,本发明的保护范围应以权利要求书所述为准。

Claims (10)

1.一种大规模存储系统元数据分布式管理方法,其特征在于,将HDFS存储于NameNode内存中的元数据抽象成二维表的结构,以二维表的形式存储在分布式数据库中;抽象后的各二维表之间通过inode_id相互关联,其中inode_id是二维表的主键,所述二维表包括:hdfs_inodes表,用于存储各文件的文件名或者文件所在的目录名;hdfs_small_file_inode_data表,用于存储数据量小于设定阈值的文件中的数据;hdfs_lease_paths表,用于存储文件的租约;hdfs_leases表,用于存储租约持有者的信息以及持有者最后一次更新的时间;hdfs_block_infos表,用于存储文件的Block信息;hdfs_pending_blocks表,用于存储正在进行复制的Block信息;hdfs_under_replicated_blocks表,用于存储正在等待复制的Block信息及其优先级;hdfs_replicas表,用于存储每个文件的副本的位置信息;hdfs_invalidated_blocks表,用于存储无效的副本信息;hdfs_excess_replicas表,用于存储超过副本数的副本信息;hdfs_corrupt_replicas表,用于存储损坏的副本信息;hdfs_replica_under_construction表,用于临时存储客户端当前写入Block的Block副本信息;其中,所述文件为NameNode内存中存储元数据的文件。
2.如权利要求1所述的方法,其特征在于,对hdfs_inodes表、hdfs_block_infos表和hdfs_replicas表存储的数据采用哈希分片的方式进行存储;对于hdfs_block_infos表和hdfs_replicas表中的数据,则利用inode_id作为分片字段使得同一个inode的相关元数据存在同一个数据节点;利用复制模式将hdfs_small_file_inode_data表、hdfs_lease_paths表和hdfs_leases表所要存储的相关数据存储到对应表中;采用随机分片的方式对hdfs_inodes表中根目录的子目录和子文件进行存储,将根目录的子文件或子目录分散于不同的数据节点。
3.如权利要求1所述的方法,其特征在于,将文件写入所述分布式数据库的方法为:
①NameNode响应客户端发起的写文件请求,在hdfs_inodes表中插入一行表示一个空文件的inode,用于存储文件的属性;
②NameNode根据客户端发送的数据存储请求,在hdfs_block_infos表中插入一行表示正在构建的Block记录,在hdfs_replica_under_constructions表中插入数据记录该Block所在的DataNode,NameNode返回封装了DataNode列表的LocatedBlock对象,该DataNode列表包括用于存储该客户端所写入数据的Block所在的DataNode;
③NameNode接收该客户端写入的数据,并写入到各个对应DataNode中;
④各DataNode完成一个Block的写入后返回一个确认信息给该客户端;
⑤NameNode收到客户端向发送的写入完成命令时,将hdfs_inodes表、hdfs_block_infos表的状态转换为完成状态。
4.如权利要求3所述的方法,其特征在于,所述属性包括文件名、权限和时间信息;NameNode以管道的形式将数据写入到各个对应DataNode中。
5.如权利要求1所述的方法,其特征在于,读取所述分布式数据库中的文件的方法为:
①NameNode响应客户端发起的读文件请求,从数据库中获取所请求文件的inode,然后根据inode获取inode_id查询该文件的所有Block,每个Block与DataNode的映射信息封装在LocatedBlock对象中,各LocatedBlock以列表的形式封装在DFSInputStream对象中;
②NameNode返回该DFSInputStream对象,供客户端读取数据;
③该文件所有Block读取完后,关闭资源。
6.如权利要求1所述的方法,其特征在于,所述分布式数据库为Postgres-XL分布式关系型数据库。
7.一种大规模存储系统元数据分布式管理系统,其特征在于,包括元数据服务集群、Namenode集群和Datanode集群;其中,
所述元数据服务集群包括:全局事务管理器,用于保证整个元数据服务集群的事务一致性;协调器,用于协调管理用户会话,解析优化SQL语句;多个数据节点构成的分布式数据库,分别用于存储文件数据;
Namenode集群包括多个Namenode,其中一个作为Leader Namenode,用于负责统一接收Datanode的块报告;每个Namenode封装一层DAL数据访问层的驱动,负责与分布式数据库交互,实现元数据的存取;
Datanode集群包括多个Datanode,Datanode用于存储文件的块数据;
其中,HDFS存储于NameNode内存中的元数据抽象成二维表的结构,以二维表的形式存储在分布式数据库中;抽象后的各二维表之间通过inode_id相互关联,inode_id是二维表的主键,所述二维表包括:hdfs_inodes表,用于存储各文件的文件名或者文件所在的目录名;hdfs_small_file_inode_data表,用于存储数据量小于设定阈值的文件中的数据;hdfs_lease_paths表,用于存储文件的租约;hdfs_leases表,用于存储租约持有者的信息以及持有者最后一次更新的时间;hdfs_block_infos表,用于存储文件的Block信息;hdfs_pending_blocks表,用于存储正在进行复制的Block信息;hdfs_under_replicated_blocks表,用于存储正在等待复制的Block信息及其优先级;hdfs_replicas表,用于存储每个文件的副本的位置信息;hdfs_invalidated_blocks表,用于存储无效的副本信息;hdfs_excess_replicas表,用于存储超过副本数的副本信息;hdfs_corrupt_replicas表,用于存储损坏的副本信息;hdfs_replica_under_construction表,用于临时存储客户端当前写入Block的Block副本信息;其中,所述文件为NameNode内存中存储元数据的文件。
8.如权利要求7所述的系统,其特征在于,NameNode收到客户端发起的写文件请求时,该NameNode在hdfs_inodes表中插入一行表示一个空文件的inode,用于存储文件的属性;然后根据客户端发送的数据存储请求,在hdfs_block_infos表中插入一行表示正在构建的Block记录,在hdfs_replica_under_constructions表中插入数据记录该Block所在的DataNode,NameNode返回封装了DataNode列表的LocatedBlock对象,该DataNode列表包括用于存储该客户端所写入数据的Block所在的DataNode;然后NameNode接收该客户端写入的数据,并写入到各个对应DataNode中,DataNode完成一个Block的写入后返回一个确认信息给该客户端;当NameNode收到客户端向发送的写入完成命令时,将hdfs_inodes表、hdfs_block_infos表的状态转换为完成状态。
9.如权利要求7所述的系统,其特征在于,NameNode收到客户端发起的文件读取请求时,该NameNode从数据库中获取所请求文件的inode,然后根据所请求文件的inode_id查询该文件的所有Block,每个Block与DataNode的映射信息封装在LocatedBlock对象中,各LocatedBlock以列表的形式封装在DFSInputStream对象中;然后NameNode返回该DFSInputStream对象,供客户端读取数据;该文件所有Block读取完后,关闭资源。
10.如权利要求7所述的系统,其特征在于,对hdfs_inodes表、hdfs_block_infos表和hdfs_replicas表存储的数据采用哈希分片的方式进行存储;对于hdfs_block_infos表和hdfs_replicas表中的数据,则利用inode_id作为分片字段使得同一个inode的相关元数据存在同一个数据节点;利用复制模式将hdfs_small_file_inode_data表、hdfs_lease_paths表和hdfs_leases表所要存储的相关数据存储到对应表中;采用随机分片的方式对hdfs_inodes表中根目录的子目录和子文件进行存储,将根目录的子文件或子目录分散于不同的数据节点。
CN201910405408.XA 2019-05-16 2019-05-16 一种大规模存储系统元数据分布式管理方法与系统 Active CN110287150B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910405408.XA CN110287150B (zh) 2019-05-16 2019-05-16 一种大规模存储系统元数据分布式管理方法与系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910405408.XA CN110287150B (zh) 2019-05-16 2019-05-16 一种大规模存储系统元数据分布式管理方法与系统

Publications (2)

Publication Number Publication Date
CN110287150A CN110287150A (zh) 2019-09-27
CN110287150B true CN110287150B (zh) 2021-05-11

Family

ID=68001926

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910405408.XA Active CN110287150B (zh) 2019-05-16 2019-05-16 一种大规模存储系统元数据分布式管理方法与系统

Country Status (1)

Country Link
CN (1) CN110287150B (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324305B (zh) * 2020-02-16 2021-02-02 西安奥卡云数据科技有限公司 一种分布式存储系统中数据写入/读取方法
CN111708738B (zh) * 2020-05-29 2023-11-03 深圳市瑞驰信息技术有限公司 实现hadoop文件系统hdfs与对象存储s3数据互访方法及系统
CN113051221B (zh) * 2021-03-31 2023-06-30 网易(杭州)网络有限公司 数据存储方法、装置、介质、设备及分布式文件系统
CN113377868B (zh) * 2021-06-16 2022-07-26 浪潮卓数大数据产业发展有限公司 一种基于分布式kv数据库的离线存储系统
CN115623081A (zh) * 2021-07-16 2023-01-17 广州视源电子科技股份有限公司 数据下载方法、上传方法及分布式存储系统
CN113434489B (zh) * 2021-08-26 2021-11-16 西安热工研究院有限公司 一种实时数据库在线扩容方法、系统、设备及存储介质
CN116166671B (zh) * 2023-04-21 2023-08-15 南方电网数字电网研究院有限公司 一种内存数据库表格预关联的处理方法、系统和介质
CN116305297B (zh) * 2023-05-22 2023-09-15 天云融创数据科技(北京)有限公司 一种用于分布式数据库的数据分析方法及系统
CN118535537A (zh) * 2024-07-26 2024-08-23 天翼视联科技有限公司 分布式元数据管理方法、异地异构元数据管理系统及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106777344A (zh) * 2017-01-16 2017-05-31 郑州云海信息技术有限公司 一种数据库集群的数据节点扩展方法及装置
CN107066499A (zh) * 2016-12-30 2017-08-18 江苏瑞中数据股份有限公司 面向异构存储多源数据管理及可视化系统的数据查询方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11106625B2 (en) * 2015-11-30 2021-08-31 International Business Machines Corporation Enabling a Hadoop file system with POSIX compliance
US11030215B2 (en) * 2016-12-23 2021-06-08 Ingram Micro Inc. Technologies for scaling user interface backend clusters for database-bound applications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107066499A (zh) * 2016-12-30 2017-08-18 江苏瑞中数据股份有限公司 面向异构存储多源数据管理及可视化系统的数据查询方法
CN106777344A (zh) * 2017-01-16 2017-05-31 郑州云海信息技术有限公司 一种数据库集群的数据节点扩展方法及装置

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
DiNoDB: Efficient Large-Scale Raw Data Analytics;Yongchao Tian et al;《Proceedings of the First International Workshop on Bringing the Value of "Big Data" to Users 》;20141231;第1-6页 *
NameNode and DataNode Coupling for a Power-Proportional Hadoop Distributed File System;Hieu Hanh Le et al;《International Conference on Database Systems for Advanced Applications》;20131231;第99-107页 *
Performance evaluation of HDFS in big data management;Dipayan Dev et al;《2014 International Conference on High Performance Computing and Applications 》;20150219;第1-7页 *
基于HDFS的海量小文件存储策略的研究;徐士坤;《中国优秀硕士学位论文全文数据库 信息科技辑》;20180715;第2018年卷(第07期);第I137-87页 *
基于Postgres-XL的数据管理优化技术研究;艾丽蓉 等;《计算机技术与发展》;20180331;第28卷(第3期);第11-14页 *

Also Published As

Publication number Publication date
CN110287150A (zh) 2019-09-27

Similar Documents

Publication Publication Date Title
CN110287150B (zh) 一种大规模存储系统元数据分布式管理方法与系统
US11704290B2 (en) Methods, devices and systems for maintaining consistency of metadata and data across data centers
KR101453425B1 (ko) 메타데이터 서버 및 메타데이터 관리 방법
US9501550B2 (en) OLAP query processing method oriented to database and HADOOP hybrid platform
CN106874383B (zh) 一种分布式文件系统元数据的解耦合分布方法
CA2139693C (en) Summary catalogs
WO2018059032A1 (zh) 一种虚拟节点的数据迁移方法和虚拟节点
CN101556557B (zh) 一种基于对象存储设备的对象文件组织方法
CN108600321A (zh) 一种基于分布式内存云的图数据存储方法和系统
CN112236758A (zh) 云存储分布式文件系统
US20110153606A1 (en) Apparatus and method of managing metadata in asymmetric distributed file system
CN104657459A (zh) 一种基于文件粒度的海量数据存储方法
CN111522880B (zh) 一种基于mysql数据库集群的提升数据读写性能的方法
Vogt et al. Polypheny-DB: towards a distributed and self-adaptive polystore
CN113377868A (zh) 一种基于分布式kv数据库的离线存储系统
Xiong et al. Data vitalization: a new paradigm for large-scale dataset analysis
CN105701219A (zh) 一种分布式缓存的实现方法
CN111078120A (zh) 一种分布式文件系统的数据迁移方法、系统及相关组件
CN115114294A (zh) 数据库存储模式的自适应方法、装置、计算机设备
US10387384B1 (en) Method and system for semantic metadata compression in a two-tier storage system using copy-on-write
CN111274259A (zh) 一种分布式存储系统中存储节点的数据更新方法
Avilés-González et al. Scalable metadata management through OSD+ devices
WO2021004295A1 (zh) 一种元数据的处理方法、装置及计算机可读存储介质
Klein et al. Dxram: A persistent in-memory storage for billions of small objects
Vohra Apache HBase Primer

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