CN114265814B - 一种基于对象存储的数据湖文件系统 - Google Patents
一种基于对象存储的数据湖文件系统 Download PDFInfo
- Publication number
- CN114265814B CN114265814B CN202210189508.5A CN202210189508A CN114265814B CN 114265814 B CN114265814 B CN 114265814B CN 202210189508 A CN202210189508 A CN 202210189508A CN 114265814 B CN114265814 B CN 114265814B
- Authority
- CN
- China
- Prior art keywords
- file
- component
- management
- data
- storage
- 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
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
本发明提供了一种基于对象存储的数据湖文件系统,包括本地文件存储组件、文件管理组件和本地元数据存储组件,其中,文件管理组件包括操作事务管理组件和文件版本管理组件;本地文件存储组件受文件管理组件控制,本地文件存储组件负责把业务数据存储对象文件保存到本地,并调用本地元数据存储组件保存业务数据目标对象对应的元数据;操作事务管理组件用来控制整个本地文件存储组件事务的生命周期,在事务提交、回滚操作过程中联动文件版本管理组件。本发明使组件应用方不用意识到底层文件系统原理即可达到缓存的效果,使用户不必关心数据治理细节,只关注上层用户接口就能提升数据治理效果和精度,降低了数据应用难度,提升了数据应用灵活性。
Description
技术领域
本发明属于数据湖文件系统领域,尤其是涉及一种基于对象存储的数据湖文件系统。
背景技术
现有的数据湖的存储一般为HDFS或者OSS对象存储或者其他的文件存储方式(比如网络存储等),现有方式主要是为解决结构化、半结构化、非结构化文件的存储,最初发明此种文件系统是为了分布式计算(HDFS),存取使用方便(对象存储OSS,S3,CEPH等),大量文件存储(网络存储GlusterFS等),缺少考虑数据湖的应用场景。
近年数据湖由于存储管理原始数据,相比数据仓库、数据市集而言,在后面的大数据处理以及AI的数据应用上更容易,灵活使用,因此在市场上迅猛发展。但市面上没有特别适合数据湖应用特点的文件系统。主要表现为:1、数据源多种多样,处理方式不统一,处理效率低下;2、数据仓库里数据基本固定,数据变动成本巨大;3、数据变动随之带来的数据分析,科学计算等后续数据应用也需要变动,成本巨大;4、数据变动的管理缺失,造成数据治理,数据血缘等信息缺失,数据利用效率低下。
发明内容
有鉴于此,本发明主要解决上述问题,发明一种数据湖文件系统,能够大大提升数据湖应用以及建设的效率,方便各种类型的数据分析,数据应用,数据科学计算,旨在利用linux的FUSE技术以及类似Git的版本管理思想,开发一种全新的基于对象存储的用户空间文件系统。该文件系统支持统一的各种文件对象的存、取、列表、删除、检索等操作,支持对象统一的缓存操作,增加文件写入以及读取的性能,支持各种常用数据格式以及文件格式的存储,支持动态分区以及分布式存储;支持数据的版本,分支,标签管理,支持按照数据的版本,分支,标签以及其他元数据信息进行数据对象检索;支持分布式事务确保数据原子一致性,支持常见大数据分析,处理,科学计算工具方便集成。
为达到上述目的,本发明的技术方案是这样实现的:一种基于对象存储的数据湖文件系统,包括:本地文件存储组件、文件管理组件和本地元数据存储组件,其中,所述文件管理组件包括操作事务管理组件和文件版本管理组件;
所述本地文件存储组件受所述文件管理组件控制,所述本地文件存储组件负责把业务数据存储对象文件保存到本地,并调用所述本地元数据存储组件保存业务数据目标对象对应的元数据;
所述操作事务管理组件用来控制整个本地文件存储组件事务的生命周期,在事务提交、回滚操作过程中联动所述文件版本管理组件,所述操作事务管理组件利用Hashgraph分布式共识技术实现文件操作的分布式事务;
所述本地元数据存储组件采用LSM tree的SSTable结构,同时构筑成两层的Merkle Tree结构,所述Merkle Tree结构包括元数据范围结点和元数据结点,元数据范围结点包含所有元数据结点,同时每条元数据结点的内容都存储有自己的物理地址,且元数据范围结点可以通过记录的内容数据的地址,取得元数据结点的具体数据。
进一步的,所述本地文件存储组件和本地元数据存储组件以本地保存的文件块为单位进行业务数据的组织管理;所述本地文件存储组件利用Linux FUSE架构实现用户区文件系统,支持mount、mkdir、create file、rm和ls操作以及实现上层应用操作接口。
进一步的,所述操作事务管理组件在事务提交操作成功后将进行文件版本升级记录,并调用所述本地元数据存储组件更新整个文件的版本信息,同时将版本信息作为元数据进行存储。
进一步的,所述文件版本管理组件采用默克尔图算法实现,分为仓库管理,分支管理,标签管理,提交管理和对象管理;仓库管理为分支管理、标签管理、提交管理和对象管理的逻辑集合;分支管理以及标签管理操作用于记录文件内容的变化部分,然后将内容变化部分的记录地址指向原记录的地址;提交管理用于记录同一数据两个版本间的差分内容,同时用于提交履历以及和业务相关的元数据;对象管理用于管理具体的业务数据以及和业务相关的元数据。
进一步的,所述系统还包括网络通讯组件、数据交换组件、文件缓存管理组件、文件分区管理组件、应用组件和外部通讯组件,所述网络通讯组件包含IP信息取得以及配置,同时还包括结点ID的生成,所述网络通讯组件通过网络协议取得区块链网络的路由联通信息以及通过利用Gossip协议取得构成网络的各个结点的状态信息,为所述数据交换组件及外部通讯组件提供网络路由信息。
进一步的,所述数据交换组件通过网络通讯协议能够完成各个数据结点的数据块获取以及写入发送,同时所述数据交换组件负责各个数据结点的数据块的交换过程控制;所述应用组件包括外部使用提供认证服务、文件系统运行状态监控以及和操作系统一致的命令,同时还包括基于gRPC的接口;所述外部通讯组件用于提供与外部系统兼容的各类接口,以及提供本系统的应用网关功能。
进一步的,所述本地文件存储组件和文件缓存管理组件结合形成分层存储的架构,所述分层存储的架构包括文件缓存、本地磁盘存储以及远程集群存储。
进一步的,所述文件分区管理组件在进行大文件存储时,能够将大文件分成固定大小的文件块进行实际的物理存储,且每个文件块的存储在集群的位置由一致性Hash算法决定。
进一步的,所述文件管理组件结合文件版本管理组件以及操作事务管理组件,三者一起提供文件整体的组织管理。
相对于现有技术,本发明所述的基于对象存储的数据湖文件系统具有以下优势:
(1)以文件系统形式为基础统一数据操作,降低了数据湖构筑成本;
(2)支持版本,分支,标签等数据管理方式,方便数据治理,应用以及分析;
(3)支持对象缓存提升存取性能;
(4)支持根据元数据进行文件对象查询操作,提升数据应用效率以及体验;
(5)支持分布式事务提升数据精度,方便数据应用集成提升大数据基础建设效率。
本发明通过操作系统的FUSE API接口构造本地文件存储的抽象层,统一数据存储方式提升效率,降低数据湖建设周期以及成本,通过统一的文件缓存,使组件应用方不用意识到底层文件系统原理即可达到缓存的效果,本地元数据存储组件以及相关版本管理组件,实现基于元数据的数据治理以及版本管理,使用户不必关心数据治理细节,只关注上层用户接口就能够提升数据治理效果和精度,降低了数据应用难度以及提升了数据应用灵活性。
附图说明
构成本发明的一部分的附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为本发明实施例所述的系统的整体架构图;
图2为本发明实施例采用的HashGraph算法示意图;
图3为单个默克尔图示例;
图4为本发明实施例采用的SSTable存储结构示意图;
图5为本发明实施例的元数据存储结构示意图;
图6为本发明实施例所述系统进行文件创建的流程图;
图7为本发明实施例所述系统进行文件读取的流程图。
具体实施方式
需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
下面将参考附图并结合实施例来详细说明本发明。
如图1-图5所示,本发明为一种基于对象存储的数据湖文件系统,包括:本地文件存储组件、文件管理组件和本地元数据存储组件,其中,所述文件管理组件包括操作事务管理组件和文件版本管理组件;所述本地文件存储组件利用FUSE API构建本地文件存储的抽象层,统一文件操作以及分层存储,用于提升响应速度;所述文件管理组件结合文件版本管理组件以及操作事务管理组件,三者一起提供文件整体的组织管理,具体包含文件切分、文件构成、版本抽取、版本比较和版本合并等基础功能,其中所述文件版本管理组件通过实现数据文件的版本以及分支管理,用于提升文件管理的灵活性,所述操作事务管理组件利用Hashgraph分布式共识技术实现文件操作的分布式事务;所述本地元数据存储组件利用LSMtree算法实现元数据的快速保存以及检索,用于提升大规模元数据的治理能力,元数据是指具体业务数据之外的相关信息的数据,比如:数据类型,数据版本,数据长度,数据分布,提交用户等各种信息。本发明利用linux的FUSE技术以及类似Git的版本管理思想,开发一种全新的基于对象存储的用户空间文件系统。支持统一的各种文件对象的存、取、列表、删除、检索等操作,支持对象统一的缓存操作,增加文件写入以及读取的性能,支持各种常用数据格式以及文件格式的存储,支持动态分区以及分布式存储。支持数据的版本、分支、标签管理,支持按照数据的版本、分支、标签以及其他元数据信息进行数据对象检索。支持分布式事务确保数据原子一致性,支持常见大数据分析,处理,科学计算工具方便集成。
所述本地文件存储组件的整个周期受所述文件管理组件控制,为所述文件管理组件进行管理;所述本地文件存储组件和本地元数据存储组件以本地保存的文件块为单位进行业务数据的组织管理;所述操作事务管理组件用来控制整个本地文件存储组件事务的生命周期,在事务提交、回滚操作等各个过程中联动所述文件版本管理组件,所述操作事务管理组件在事务提交操作成功后将进行文件版本升级记录,并调用所述本地元数据存储组件更新整个文件的版本信息,同时将版本信息作为元数据进行存储。所述本地文件存储组件负责把业务数据存储对象文件(如果文件尺寸小于指定阈值则保存源文件;如果文件尺寸大于指定阈值,则只保存属于自己的文件块)保存到本地,本地文件存储到本地成功后,会调用所述本地元数据存储组件来保存业务数据目标对象对应的元数据,即上传的人、文件ID、文件版本、分块数、保存位置及操作时间等数据。
所述本地文件存储组件利用Linux FUSE架构实现用户区文件系统,支持mount、mkdir、create file、rm和ls等多种常见操作以及实现上层应用操作接口,方便上层应用调用,同时内部连接文件版本管理等组件为单机文件系统的核心部分。
目前,一般分布式事务采用RAFT等Paxos类协议完成,但此类算法需要推选中心结点(Leader),因此存在一个问题,那便是一旦中心结点出现问题,整个系统比较容易受到影响。为了达到比较好的分布式事务一致性管理,本发明采用Hashgraph方式进行无中心的事务共识算法,提升了系统健壮性以及可用性。所述操作事务管理组件通过对元数据进行版本管理,记录各个事务提交(Commit)的差异,以及Hashgraph异步进行共识计算,达成共识的事务进行版本归并(Merge)操作,未达成共识的操作进行回滚(Rollback)操作,这样就实现了无中心,异步的分布式式事务管理。
如图2所示,HashGraph算法通过网络中的各个结点向其他结点广播自己接收到的数据信息和结点状态信息,然后利用这种相互间传话的方式(Gossip about Gossip),结点B把B知道的信息传送给D,结点D把B传来的信息加上自己的信息传送给B,而B又把B知道的信息传送给结点A和结点D,每次结点下一次把消息传送给哪个结点都是随机的,这样随着时间的推移,如果2/3以上的结点能够达成共识,就能够形成共识。因为结点间相互传播,所以不需要中心结点进行控制,每个结点运行的算法都是相同的。上述的消息传播过程通过HashGraph数据结构进行记录(如图2所示结构),网络中每个结点都保存有HashGraph数据结构。通过虚拟投票的规则(Virtual Voting),网络中每个结点都能够通过HashGraph数据结构计算本结点的拜占庭协议,如果达成协议就发起投票,并把信息传送给其他结点,如果N个结点都能通过虚拟投票信息计算某个结点的虚拟投票,则说明该N个结点达成了拜占庭协议,从而很容易计算出是否已经2/3达成共识。
所述文件版本管理组件采用类似Git(Git是业界著名源代码版本管理工具,其数据格式为公开数据格式)对源代码进行管理的类似机制,采用默克尔图(Merkle DAG)算法实现,分为仓库管理(Repositories),分支管理(Branches),标签管理(Tags),提交管理(Commits)和对象管理(Objects);仓库管理为分支管理、标签管理、提交管理和对象管理的逻辑集合,用于方便单个文件对象的管理;为了提升效率,分支管理以及标签管理操作不进行整个文件的复制,而是记录文件内容的变化部分,然后将内容变化部分的记录地址指向原记录的地址,减少IO操作;提交管理用于记录同一数据两个版本间的差分内容,同时用于提交履历以及和业务相关的元数据,即和业务相关的元数据,比如提交人是谁,提交时间,提交前版本等非实际业务数据的数据。比如:需要将原内容“张飞,小二班,女”更改为“张飞,中二班,女”,则此时的变化部分就是将“小二班”改为“中二班”,变化内容为“小->中”,在该条记录中,原纪录就是“张飞,小二班,女”这条记录,而这条记录的物理地址就是该记录指针的值,也就是把变化内容“小->中”指向原记录的地址,即只记录同一数据两个版本间的差分内容,而不必记录“张飞,中二班,女”整个记录,因为如果整个内容进行记录则会出现重复的内容,而只记录变化部分的内容,则会有效节省空间。对象管理用于管理具体的业务数据以及和业务相关的元数据,支持常见Parquet、ORC、AVRO、CSV、XML、JSON、JSON-LD,以及图片,音频和视频多种格式文件,其中具体业务数据,不同业务需求不同,存储数据格式,载体不一定相同,和业务相关的元数据,指的是提交人是谁、提交时间、提交前版本等非实际业务数据的数据。
所述本地元数据存储组件采用LSM tree的SSTable结构,内存缓存存储结构和本地磁盘存储结构一致,充分发挥LSM tree的写入性能,提高系统吞吐以及性能,存储元数据(Metadata)为了提升性能,SSTable结构构筑成两层的Merkle Tree结构,所述Merkle Tree结构包括元数据范围结点(MetaRange)和元数据结点(Range),元数据范围结点包含所有元数据结点,而元数据结点为叶子结点,同时每个元数据结点的内容(Contents)都存储有自己的物理地址,在元数据范围结点中记录着元数据结点中内容数据的地址,故元数据范围结点可以通过记录的内容数据的地址,取得元数据结点的具体数据,元数据(Metadata)的存储分为两步进行提交,由操作事务管理组件保证其事务的一致性。
所述系统还包括网络通讯组件、数据交换组件、文件缓存管理组件、文件分区管理组件、应用组件和外部通讯组件,所述网络通讯组件包含IP信息取得以及配置,同时还包括结点ID的生成,用于完成网络基本信息的初始化配置,以及网络配置变化的监控功能,所述网络通讯组件通过网络协议取得区块链网络的路由联通信息以及通过利用Gossip协议取得构成网络的各个结点的状态信息,为所述数据交换组件及外部通讯组件提供网络路由信息。数据湖(DataLake)是大数据里的术语,是一种抽象的表达,并非特指数据文件还是数据库等,数据湖文件系统为网络文件系统,由多台计算机构成的计算网络构成,网络中的每台计算机称为一个结点,各个结点的结点ID、IP信息及路由信息等在结点接入网络初始化时进行自动收集并保存到配置文件中,系统在运行过程中会通过Gossip协议广播自己的状态,当结点的状态发生变化时会更新配置文件,配置文件始终反应数据湖网络的最新状态。
所述数据交换组件通过网络通讯协议能够完成各个数据结点的数据块获取以及写入发送,同时所述数据交换组件负责各个数据结点的数据块的交换过程控制,包含交换过程中的文件合并,文件拆分等操作;所述应用组件包括外部使用提供认证服务、文件系统运行状态监控以及和操作系统一致的rm,ls,create命令,同时还包括基于gRPC的接口;所述外部通讯组件用于提供与外部系统兼容的各类接口,比如:S3接口,Restful接口,gRPC接口等,以及提供本系统的应用网关功能。
所述本地文件存储组件和文件缓存管理组件结合形成分层存储的架构,所述分层存储的架构包括文件缓存、本地磁盘存储以及远程集群存储,文件缓存用于存储最热数据,然后从本地磁盘存储到远程集群存储依次递减为远端存储,缓存的作用就是把最经常使用的数据放到效率最高的存储位置,最热数据指最经常使用的数据,而并非具体的数据,在使用中数据也会经常变化。比如“张飞,小二班,女”这条数据用户经常使用,这条数据就是热数据。通常会根据一定算法确定什么是最常用,比如:LRU等。文件缓存分为两部分构成,一个为元数据(Metadata)的缓存,由SSTable格式在内存中存储,另一个为具体文件块的存储,具体文件块存储在Linux RAMDISK上,确保原始数据快速存储,提升系统性能,此处的元数据的缓存,指具体业务数据之外的相关信息的数据,比如:数据类型、数据版本、数据长度、数据分布、提交用户等各种信息;具体文件块的存储,指具体的业务数据文件块的存储,业务数据根据实际业务决定,比如:幼儿园系统业务数据可能就是“张飞,小二班,女”这样的记录,而农业应用的系统可能就是“收割机,42000,20190101”这样的数据,这些数据在电脑里是以文件形式存储,电脑的文件在硬盘是以块(Block)单位存储,简称文件块。
为了保证大文件的快速写入以及读取,发挥分布式多机器的能力,所述文件分区管理组件在进行大文件存储时,会将大文件分成固定大小的文件块进行实际的物理存储,且每个文件块的存储在集群的位置由一致性Hash算法决定,这样能够在存取文件时很快的找到构成文件的块的物理位置,不需要检索,扫描类算法,大大提升了系统性能。
本发明利用操作系统的FUSE API接口构造本地文件存储的抽象层,统一数据存储方式提升效率,降低数据湖建设周期以及成本,通过统一的文件缓存,使组件应用方不用意识到底层文件系统原理即可达到缓存的效果,本地元数据存储组件,实现基于元数据的数据治理以及版本管理,使用户不必关心数据治理细节,只关注上层用户接口就能够提升数据治理效果和精度,降低数据应用难度以及提升数据应用灵活性。
本系统外部通讯组件以Restful接口的方式提供创建文件的功能,如图6所示,进行文件创建的过程如下:
调用方使用httpClient调用外部通讯组件的创建(Create)接口,应用组件进行相应http请求,文件操作模块调用对应创建命令进行文件创建,在创建命令的执行过程中会调用文件管理组件,文件管理组件调用操作事务管理组件创建一个事务会话(Session),该会话对整个事务(Transaction)的生命周期进行管理,在操作事务管理组件中发起创建文件的操作请求,该请求由本地文件存储组件来响应,本地文件存储组件请求操作系统FUSEAPI接口进行实际的文件创建,并且调用文件缓存管理组件根据缓存算法执行相应的缓存操作。将创建的文件与事先设置的阈值比较,如果文件尺寸大于阈值则调用文件分区管理组件,然后将文件分为多份并行进行创建,文件创建成功后,由本地元数据存储组件记录该请求的申请用户,申请IP,操作时间等元数据信息,同时由文件版本管理组件为该文件创建版本,因为是初始创建版本,故为1.00版;如果文件尺寸小于阈值则直接作为一个文件块在本地进行保存,文件创建成功后,由本地元数据存储组件记录该请求的申请用户,申请IP,操作时间等元数据信息,同时由文件版本管理组件为该文件创建版本,因为是初始创建版本,故为1.00版。以上操作全部成功后由操作事务管理组件对该事务进行提交操作,文件创建完成。由外部通讯组件返回响应代码200通知httpClient,文件创建成功。大文件的创建过程,一个文件根据算法会分成多份保存到不同的电脑中,原理和上面的过程相同,本地文件存储只保存属于自己的一部分,文件块的分发以及各个计算的存储结果这些由数据交换和网络通讯组件来完成。
如图7所示,进行文件取得(本地无缓存情况)的过程如下:
1.外部通讯组件的客户端模块发起文件取得请求,参数信息中包含文件名以及版本。
2.应用组件的参数解析模块进行参数解析,得到所需文件以及版本,执行取得(Get)命令操作。
3.取得命令操作通过文件管理组件取得文件的版本信息,取得到版本对应的文件ID。
4.文件分区管理组件根据文件ID,通过文件管理组件取得分区信息。
5.如果只有一个分区,直接调用本地块读取模块,从本地取得文件,并且返回给应用组件。
6.如果为分布式存储形式(多块文件构成),则通过文件分区管理组件进行分区信息解析。
7.数据交换组件根据分区信息计算所取文件块,并通过网络通讯组件分发给各个网络结点。
8.各个网络结点接收到通讯组件的指令,进行文件读取操作。
9.本地元数据存储组件读取本地文件块元数据信息,本地文件存储组件读取本地文件块数据。
10.文件块读取模块全部文件块读取完成(读取大小=元数据信息的文件块尺寸大小)后,通过网络通讯组件把文件内容返回。
11.数据交换组件把所有文件块数据进行合并组合,然后传送给应用组件。
12.应用组件把接收到的文件,返回给客户端计算机。
13.客户端计算机上的外部通讯组件进行文件接收。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (8)
1.一种基于对象存储的数据湖文件系统,其特征在于,包括:本地文件存储组件、文件管理组件和本地元数据存储组件,其中,所述文件管理组件包括操作事务管理组件和文件版本管理组件;
所述本地文件存储组件受所述文件管理组件控制,所述本地文件存储组件负责把业务数据存储对象文件保存到本地,并调用所述本地元数据存储组件保存业务数据目标对象对应的元数据;
所述操作事务管理组件用来控制整个本地文件存储组件事务的生命周期,在事务提交、回滚操作过程中联动所述文件版本管理组件,所述操作事务管理组件利用Hashgraph分布式共识技术实现文件操作的分布式事务;
所述本地元数据存储组件采用LSM tree的SSTable结构,同时构筑成两层的MerkleTree结构,所述Merkle Tree结构包括元数据范围结点和元数据结点,元数据范围结点包含所有元数据结点,同时每条元数据结点的内容都存储有自己的物理地址,且元数据范围结点可以通过记录的内容数据的地址,取得元数据结点的具体数据。
2.根据权利要求1所述的基于对象存储的数据湖文件系统,其特征在于:所述本地文件存储组件和本地元数据存储组件以本地保存的文件块为单位进行业务数据的组织管理;所述本地文件存储组件利用Linux FUSE架构实现用户区文件系统,支持mount、mkdir、createfile、rm和ls操作以及实现上层应用操作接口。
3.根据权利要求1所述的基于对象存储的数据湖文件系统,其特征在于:所述操作事务管理组件在事务提交操作成功后将进行文件版本升级记录,并调用所述本地元数据存储组件更新整个文件的版本信息,同时将版本信息作为元数据进行存储。
4.根据权利要求1所述的基于对象存储的数据湖文件系统,其特征在于:所述文件版本管理组件采用默克尔图算法实现,分为仓库管理,分支管理,标签管理,提交管理和对象管理;仓库管理为分支管理、标签管理、提交管理和对象管理的逻辑集合;分支管理以及标签管理操作用于记录文件内容的变化部分,然后将内容变化部分的记录地址指向原记录的地址;提交管理用于记录同一数据两个版本间的差分内容,同时用于提交履历以及和业务相关的元数据;对象管理用于管理具体的业务数据以及和业务相关的元数据。
5.根据权利要求1所述的基于对象存储的数据湖文件系统,其特征在于:所述系统还包括网络通讯组件、数据交换组件、文件缓存管理组件、文件分区管理组件、应用组件和外部通讯组件,所述网络通讯组件包含IP信息取得以及配置,同时还包括结点ID的生成,所述网络通讯组件通过网络协议取得区块链网络的路由联通信息以及通过利用Gossip协议取得构成网络的各个结点的状态信息,为所述数据交换组件及外部通讯组件提供网络路由信息。
6.根据权利要求5所述的基于对象存储的数据湖文件系统,其特征在于:所述数据交换组件通过网络通讯协议能够完成各个数据结点的数据块获取以及写入发送,同时所述数据交换组件负责各个数据结点的数据块的交换过程控制;所述应用组件包括外部使用提供认证服务、文件系统运行状态监控以及和操作系统一致的命令,同时还包括基于gRPC的接口;所述外部通讯组件用于提供与外部系统兼容的各类接口,以及提供本系统的应用网关功能。
7.根据权利要求5所述的基于对象存储的数据湖文件系统,其特征在于:所述本地文件存储组件和文件缓存管理组件结合形成分层存储的架构,所述分层存储的架构包括文件缓存、本地磁盘存储以及远程集群存储。
8.根据权利要求5所述的基于对象存储的数据湖文件系统,其特征在于:所述文件分区管理组件在进行大文件存储时,能够将大文件分成固定大小的文件块进行实际的物理存储,且每个文件块的存储在集群的位置由一致性Hash算法决定。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210189508.5A CN114265814B (zh) | 2022-03-01 | 2022-03-01 | 一种基于对象存储的数据湖文件系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210189508.5A CN114265814B (zh) | 2022-03-01 | 2022-03-01 | 一种基于对象存储的数据湖文件系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114265814A CN114265814A (zh) | 2022-04-01 |
CN114265814B true CN114265814B (zh) | 2022-06-07 |
Family
ID=80833801
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210189508.5A Active CN114265814B (zh) | 2022-03-01 | 2022-03-01 | 一种基于对象存储的数据湖文件系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114265814B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116028504B (zh) * | 2023-02-20 | 2023-05-30 | 北京数元灵科技有限公司 | 一种数据湖元数据管理方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109491962A (zh) * | 2018-11-06 | 2019-03-19 | 深圳市网心科技有限公司 | 一种文件目录树管理方法及相关装置 |
CN109656889A (zh) * | 2018-12-26 | 2019-04-19 | 百度在线网络技术(北京)有限公司 | 基于区块链的文件系统实现方法、装置、设备和存储介质 |
CN111221887A (zh) * | 2018-11-27 | 2020-06-02 | 中云开源数据技术(上海)有限公司 | 一种对数据湖服务器中的数据进行管理和访问的方法 |
CN111221791A (zh) * | 2018-11-27 | 2020-06-02 | 中云开源数据技术(上海)有限公司 | 一种多源异构数据导入数据湖的方法 |
CN113761294A (zh) * | 2021-09-10 | 2021-12-07 | 北京火山引擎科技有限公司 | 数据管理方法、装置、存储介质以及电子设备 |
CN113901024A (zh) * | 2021-09-26 | 2022-01-07 | Oppo广东移动通信有限公司 | 数据存储系统、数据存储方法、可读介质和电子设备 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102930185B (zh) * | 2012-11-28 | 2015-07-29 | 中国人民解放军国防科学技术大学 | 运行时程序安全关键数据的完整性验证方法及装置 |
CN106790434B (zh) * | 2016-12-05 | 2020-03-27 | 上海爱数信息技术股份有限公司 | 网络数据的管理方法、网络附属存储网关及存储服务系统 |
CN109408689B (zh) * | 2018-10-24 | 2020-11-24 | 北京金山云网络技术有限公司 | 数据获取方法、装置、系统及电子设备 |
-
2022
- 2022-03-01 CN CN202210189508.5A patent/CN114265814B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109491962A (zh) * | 2018-11-06 | 2019-03-19 | 深圳市网心科技有限公司 | 一种文件目录树管理方法及相关装置 |
CN111221887A (zh) * | 2018-11-27 | 2020-06-02 | 中云开源数据技术(上海)有限公司 | 一种对数据湖服务器中的数据进行管理和访问的方法 |
CN111221791A (zh) * | 2018-11-27 | 2020-06-02 | 中云开源数据技术(上海)有限公司 | 一种多源异构数据导入数据湖的方法 |
CN109656889A (zh) * | 2018-12-26 | 2019-04-19 | 百度在线网络技术(北京)有限公司 | 基于区块链的文件系统实现方法、装置、设备和存储介质 |
CN113761294A (zh) * | 2021-09-10 | 2021-12-07 | 北京火山引擎科技有限公司 | 数据管理方法、装置、存储介质以及电子设备 |
CN113901024A (zh) * | 2021-09-26 | 2022-01-07 | Oppo广东移动通信有限公司 | 数据存储系统、数据存储方法、可读介质和电子设备 |
Non-Patent Citations (4)
Title |
---|
Azure Data Lake Store:A Hyperscale Distributed File Service for Big Data Analytics;Raghu Ramakrishnan et al.;《Proceedings of the 2017 ACM International Conference on Management of Data》;20170509;全文 * |
基于Linux的分布式文件系统的设计与实现;王亮;《中国优秀硕士学位论文全文数据库信息科技辑》;20140615(第06期);论文第三章-第四章 * |
基于Merkle Tree的分布式文件系统设计;黄翔;《万方数据库》;20191029(第27期);全文 * |
面向海量数据的分布式用户态文件系统研究与设计;龚恒等;《通信技术》;20200210(第02期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN114265814A (zh) | 2022-04-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11562091B2 (en) | Low latency access to physical storage locations by implementing multiple levels of metadata | |
US8504571B2 (en) | Directed placement of data in a redundant data storage system | |
US7797275B2 (en) | System and method of time-based cache coherency maintenance in user file manager of object-based storage system | |
US10789217B2 (en) | Hierarchical namespace with strong consistency and horizontal scalability | |
CN102779185B (zh) | 一种高可用分布式全文索引方法 | |
JP5387757B2 (ja) | 並列データ処理システム、並列データ処理方法及びプログラム | |
CN106775446B (zh) | 基于固态硬盘加速的分布式文件系统小文件访问方法 | |
US11561930B2 (en) | Independent evictions from datastore accelerator fleet nodes | |
US10747673B2 (en) | System and method for facilitating cluster-level cache and memory space | |
US20190102087A1 (en) | Remote one-sided persistent writes | |
EP3262512B1 (en) | Application cache replication to secondary application(s) | |
US10802766B2 (en) | Database with NVDIMM as persistent storage | |
CN104239575A (zh) | 一种虚拟机镜像文件存储、分发方法及装置 | |
US8631209B2 (en) | Reusable content addressable stores as building blocks for creating large scale storage infrastructures | |
JP5375972B2 (ja) | 分散ファイルシステム、そのデータ選択方法およびプログラム | |
US10503693B1 (en) | Method and system for parallel file operation in distributed data storage system with mixed types of storage media | |
US11080207B2 (en) | Caching framework for big-data engines in the cloud | |
US11818012B2 (en) | Online restore to different topologies with custom data distribution | |
Merceedi et al. | A comprehensive survey for hadoop distributed file system | |
CN114265814B (zh) | 一种基于对象存储的数据湖文件系统 | |
US11288237B2 (en) | Distributed file system with thin arbiter node | |
US10387384B1 (en) | Method and system for semantic metadata compression in a two-tier storage system using copy-on-write | |
US20230169048A1 (en) | Detecting idle periods at network endpoints for management actions at processing clusters for managed databases | |
US10628391B1 (en) | Method and system for reducing metadata overhead in a two-tier storage architecture | |
US20240111751A1 (en) | Record-level locks with constant space complexity |
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 |