CN113051221A - 数据存储方法、装置、介质、设备及分布式文件系统 - Google Patents

Abstract

本公开的实施例提供了一种数据存储方法、装置、介质、设备及分布式文件系统，涉及数据处理技术领域。该方法包括：启动元数据分析进程，并基于元数据分析进程从元数据管理节点获取待分析元数据；通过元数据分析进程对待分析元数据进行解析处理，得到待存储元数据；基于元数据分析进程将待存储元数据存储到目标数据库中。本公开实施例的技术方案能够降低分布式文件系统处理数据时对内存的消耗，提升元数据的解析性能。

Description

数据存储方法、装置、介质、设备及分布式文件系统

技术领域

本公开的实施例涉及数据处理技术领域，更具体地，本公开的实施例涉及数据存储方法、数据存储装置、计算机可读存储介质、电子设备以及分布式文件系统。

背景技术

本部分旨在为权利要求书中陈述的本公开的实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

随着科学技术的飞速发展，分布式文件系统(Distributed File System，DFS)是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点(可简单的理解为一台计算机)相连；或是若干不同的逻辑磁盘分区或卷标组合在一起而形成的完整的有层次的文件系统。Hadoop分布式文件系统(Hadoop Distributed FileSystem，HDFS)是一个被设计成适合运行在通用硬件(Commodity Hardware)上的分布式文件系统。

相关的数据管理方案中，是通过管理节点数据分析服务NameNode analysis对HDFS中的元数据进行分析管理。NameNode analysis复用了管理节点NameNode的对元数据的处理逻辑，会将所有的元数据信息存储在内存中，并在内存中构建与NameNode一致的元数据文件目录树。NameNode analysis的所有针对元数据的请求，需要对元数据文件目录树进行全局的扫描工作。

发明内容

但是，目前的数据管理方案中，一方面，由于NameNode analysis复用了管理节点NameNode的对元数据的处理逻辑，会在内存中构建与NameNode一致的元数据文件目录树，因此NameNode analysis会产生较高的内存消耗，对系统内存负担较大，降低系统性能；另一方面，NameNode使用了一种合成机制，该机制会定时的把旧的元数据文件进行合并，而NameNode analysis通过存算一体的方式解析元数据并存储，这样会导致NameNodeanalysis由于自身解析性能的瓶颈，在NameNode触发合成机制前，来不及解析所有的元数据文件，进而使得整个服务启动失败，降低了系统的稳定性以及数据处理效率。

因此在现有技术中，难以达到令人满意的数据管理方案。

为此，非常需要一种改进的数据存储方法，以使得能够降低对分布式文件系统的内存消耗，提升系统性能，同时能够在NameNode合并元数据文件之前及时解析处理元数据文件，提升系统稳定性，提升系统的数据处理效率。

在本上下文中，本公开的实施例期望提供一种数据存储方法、数据存储装置、计算机可读存储介质以及电子设备。

在本公开实施例的第一方面中，提供了一种数据存储方法，应用于分布式文件系统，所述分布式文件系统包括元数据管理节点、基于存算解耦模式的元数据分析进程和采用键值对存储形式的目标数据库，该方法包括：

启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；

通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；

基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程包括解析计算单线程和存储队列，所述通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据，包括：

通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据；以及

将所述待存储元数据存储到所述存储队列中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程还包括至少一个存储线程，所述基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中，包括：

基于所述至少一个存储线程将所述待存储元数据异步存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括镜像文件和第一编辑日志，所述通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据，包括：

在所述元数据管理节点将所述镜像文件和所述第一编辑日志合并之前，通过所述解析计算单线程对所述第一编辑日志进行解析处理，将解析后的第一编辑日志以及所述镜像文件作为所述待存储元数据。

在本公开的一些实施例中，基于前述方案，所述方法还包括：

确定所述待存储元数据对应的绝对路径以及元数据信息；

将所述绝对路径作为列键以及将所述元数据信息作为所述列键的键值，以构建所述待存储元数据对应的第一键值对；

基于所述第一键值对将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述方法还包括：

根据所述绝对路径将属于同一主目录下的所述键值对存储到所述目标数据库中的同一区域。

在本公开的一些实施例中，基于前述方案，所述目标数据库包括多个存储管理节点，所述方法还包括：

将所述待存储元数据平均分发到所述多个存储管理节点中进行存储。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括第二编辑日志，所述方法还包括：

根据所述第二编辑日志确定各所述待存储元数据的读写热度值；

将所述读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述方法还包括：

根据所述待存储元数据对应的绝对路径确定路径深度值；

结合所述路径深度值、所述绝对路径和所述待存储元数据对应的元数据信息构建所述待存储元数据对应的第二键值对；

基于所述第二键值对将所述待存储元数据分别存储在不同的所述存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述方法还包括：

通过所述元数据分析进程对应的元数据查询接口获取客户端对存储到所述目标数据库中的元数据的查询分析请求，并根据所述查询分析请求确定待请求元数据的目标路径；

基于所述元数据查询接口，根据所述目标路径从所述目标数据库中筛选目标键值对，并根据所述目标键值对读取所述待请求元数据对应的元数据信息；

将所述元数据信息返回给所述客户端。

在本公开的一些实施例中，基于前述方案，所述分布式文件系统包括缓存队列，所述方法还包括：

将所述元数据信息缓存到所述缓存队列中，以在新的查询分析请求需要读取所述元数据信息时，直接从所述缓存队列中读取；以及

如果所述缓存队列中的所述元数据信息的空闲时间大于预设的超时阈值，则将所述元数据信息从所述缓存队列中移除。

在本公开实施例的第二方面中，提供了一种数据存储装置，应用于分布式文件系统，所述分布式文件系统包括元数据管理节点、基于存算解耦模式的元数据分析进程和采用键值对存储形式的目标数据库，该装置包括：

待分析元数据获取模块，用于启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；

待分析元数据解析模块，用于通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；

待存储元数据存储模块，用于基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程包括解析计算单线程和存储队列，所述待分析元数据解析模块包括：

解析单元，用于通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据；以及

存储单元，用于将所述待存储元数据存储到所述存储队列中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程还包括至少一个存储线程，所述待存储元数据存储模块包括：

异步存储单元，用于基于所述至少一个存储线程将所述待存储元数据异步存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括镜像文件和第一编辑日志，所述解析单元还用于：

在所述元数据管理节点将所述镜像文件和所述第一编辑日志合并之前，通过所述解析计算单线程对所述第一编辑日志进行解析处理，将解析后的第一编辑日志以及所述镜像文件作为所述待存储元数据。

在本公开的一些实施例中，基于前述方案，所述数据存储装置还包括：

信息确定单元，用于确定所述待存储元数据对应的绝对路径以及元数据信息；

键值对构建单元，用于将所述绝对路径作为列键以及将所述元数据信息作为所述列键的键值，以构建所述待存储元数据对应的第一键值对；

数据存储单元，用于基于所述第一键值对将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述数据存储装置还包括：

区域存储单元，用于根据所述绝对路径将属于同一主目录下的所述键值对存储到所述目标数据库中的同一区域。

在本公开的一些实施例中，基于前述方案，所述目标数据库包括多个存储管理节点，所述数据存储装置还包括：

均匀存储单元，用于将所述待存储元数据平均分发到所述多个存储管理节点中进行存储。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括第二编辑日志，所述数据存储装置还包括热点数据分开存储单元，所述热点数据分开存储单元用于：

根据所述第二编辑日志确定各所述待存储元数据的读写热度值；

将所述读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述均匀存储单元还用于：

根据所述待存储元数据对应的绝对路径确定路径深度值；

结合所述路径深度值、所述绝对路径和所述待存储元数据对应的元数据信息构建所述待存储元数据对应的第二键值对；

基于所述第二键值对将所述待存储元数据分别存储在不同的所述存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述数据存储装置还包括数据查询单元，所述数据查询单元用于：

通过所述元数据分析进程对应的元数据查询接口获取客户端对存储到所述目标数据库中的元数据的查询分析请求，并根据所述查询分析请求确定待请求元数据的目标路径；

基于所述元数据查询接口，根据所述目标路径从所述目标数据库中筛选目标键值对，并根据所述目标键值对读取所述待请求元数据对应的元数据信息；

将所述元数据信息返回给所述客户端。

在本公开的一些实施例中，基于前述方案，所述分布式文件系统包括缓存队列，所述数据存储装置还包括请求数据缓存单元，所述请求数据缓存单元用于：

将所述元数据信息缓存到所述缓存队列中，以在新的查询分析请求需要读取所述元数据信息时，直接从所述缓存队列中读取；以及

如果所述缓存队列中的所述元数据信息的空闲时间大于预设的超时阈值，则将所述元数据信息从所述缓存队列中移除。

在本公开实施例的第三方面中，提供了一种分布式文件系统，包括：

客户端，用于生成查询分析请求；

元数据管理节点，用于生成元数据；

目标数据库，包括多个存储管理节点，用于将接收到的数据转化成键值对的形式进行存储；

元数据分析进程，与所述客户端、所述目标数据库和所述元数据管理节点对接，用于对所述元数据进行解析，并将解析后的元数据发送给所述目标数据库进行存储，或者基于所述从查询分析请求所述目标数据库读取对应的元数据。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程包括：

拉取线程，用于从所述元数据管理节点周期性获取最新的元数据；

解析计算单线程，用于将所述拉取线程获取的所述元数据进行解析，得到解析后的元数据；

存储队列，用于缓存所述解析计算单线程生成的所述解析后的元数据；

至少一个存储线程，用于将所述存储队列中缓存的所述解析后的元数据异步存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程还包括：

元数据查询接口，用于解析所述客户端生成的查询分析请求，并根据解析得到的目标路径从所述目标数据库中筛选目标键值对，并根据所述目标键值对读取请求的元数据对应的元数据信息，将所述元数据信息返回给所述客户端。

在本公开的一些实施例中，基于前述方案，所述分布式文件系统还包括：

缓存队列，与所述元数据分析进程和所述目标数据库对接，用于缓存已经读取的所述查询分析请求对应的元数据信息。

在本公开实施例的第四方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的数据存储方法。

在本公开实施例的第五方面中，提供了一种电子设备，包括：处理器；以及存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上述第一方面所述的数据存储方法。

根据本公开实施例的技术方案，一方面，通过元数据分析进程以及目标数据库的结合，将元数据存储在目标数据库中，能够避免相关方案中的NameNode analysis为了满足频繁的元数据查询请求而将元数据存储在内存中导致高内存消耗的问题，降低内存的占用，提升系统性能；另一方面，通过基于存算解耦模式的元数据分析进程能够实现对元数据文件的快速解析，避免基于存算强关联的NameNode analysis解析元数据文件具有性能瓶颈的问题，提升系统稳定性，提高系统的数据处理效率。

鉴于分布式文件系统中每条操作记录之间的强关联性，很难在并发的情况下保证元数据的准确性，因此，通过解析计算单线程可以实现元数据的单线程处理，进而保证元数据的准确性。

通过存储队列作为解析计算单线程与存储线程之间的缓冲区域，实现元数据分析进程解析计算过程与存储过程的解耦，避免由于计算过程与存储过程之间强关联导致解析计算单线程无法及时处理FSEditlog文件产生服务崩溃的问题。

为了及时处理FSEditLog文件，增强系统的元数据处理性能，通过由解析计算单线程、存储队列和至少一个存储线程构成的元数据分析进程实现存算分离的技术方案，增加系统的并发处理性能，提升FSEditlog文件的处理效率，提升系统稳定性。

通过将属于同一主目录下的键值对存储到目标数据库Hbase中的同一区域，能够有效提升目标数据库在查找同一主目录下的元数据的效率，提升数据读取效率。

通过将待存储元数据平均分发到多个存储管理节点中进行存储，能够避免将数据集中存储到某个存储管理节点中，导致该存储管理节点的读取请求过多影响数据读取效率的问题，提升数据查询效率。

通过将读写热度值大于或者等于热度值阈值的待存储元数据存储在不同的存储管理节点，能够有效避免将热点数据集中存储到一个存储管理节点中导致该存储管理节点的读写请求过于繁忙，导致存储管理节点的数据处理效率降低的问题，提升数据的处理效率。

通过路径深度值将同一路径深度值的待存储元数据进行存储，实现将待存储元数据均匀分散存储到不同的存储管理节点上，能够有效提升元数据的读取效率。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施例的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施例，其中：

图1示意性示出了根据本公开的一些实施例的示例性应用场景的系统架构的示意框图；

图2示意性地示出了根据本公开的一些实施例的数据存储方法的流程示意图；

图3示意性地示出了根据本公开的一些实施例的解析待分析元数据的流程示意图；

图4示意性地示出了根据本公开的一些实施例的将待存储元数据存储到目标数据库的流程示意图；

图5示意性地示出了根据本公开的另一些实施例的将待存储元数据存储到目标数据库的流程示意图；

图6示意性地示出了根据本公开的再一些实施例的将待存储元数据存储到目标数据库的流程示意图；

图7示意性地示出了根据本公开的一些实施例的查询元数据的流程示意图；

图8示意性地示出了根据本公开的一些实施例的缓存元数据信息的流程示意图；

图9示意性地示出了根据本公开的一些实施例的相关方案中数据存储的架构示意图；

图10示意性地示出了根据本公开的一些实施例的分布式文件系统的架构示意图；

图11示意性地示出了根据本公开的一些实施例的元数据分析进程存取元数据的流程示意图；

图12示意性地示出了根据本公开的一些实施例的数据存储装置的示意框图；

图13示意性地示出了根据本公开的示例实施例的存储介质的示意图；以及

图14示意性地示出了根据发明的示例实施例的电子设备的方框图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施例来描述本公开的原理和精神。应当理解，给出这些实施例仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施例可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施例，提出了一种数据存储方法、数据存储装置、介质和电子设备。

在本文中，需要理解的是，所涉及的术语，比如：

管理节点(NameNode)是整个HDFS的管理节点，维护着整个文件系统的文件目录树，保存着文件数据块的地址。在高可用的实现方案中，一般会保护署两个NameNode节点，一个称为主节点(Active NameNode，ANN)用于对外部提供服务，一个称为备节点(StandbyNameNode，SBN)用于作为主节点的备份节点，一旦主节点宕机了，备节点可以快速成为主节点并对外提供服务。

FSImage是由HDFS生成的一种文件，用来保存某一时刻最新的元数据信息，记录了整个HDFS文件系统的所有目录和文件的信息。

FSEditlog是由HDFS生成的一种文件，用来记录客户端对HDFS进行的各种写操作。

FSAuditlog是由HDFS生成的一种文件，用来记录客户端对HDFS进行的读和写操作。

一致性存储系统(JournalNode Cluster)是ANN与SBN之间共享Editlog的一致性存储系统，是NameNode高可用的核心组件。借助JournalNode Cluster ANN可以尽可能及时同步元数据到SBN。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施例，详细阐释本公开的原理和精神。

发明概述

在相关的数据存储方案中，一般是通过NameNode analysis对HDFS元数据进行管理，但NameNode analysis不提供远程调用(Remote Procedure Call，RPC)服务，而是通过REST API的形式对外提供元数据查询服务。NameNode analysis所有的查询功能都是以整个HDFS的元数据为基础，并进行的复杂扫描。NameNode analysis复用了NameNode的对元数据的处理逻辑，在加载FSImage文件的时候将所有的元数据信息存储在内存中，并在内存中构建与NameNode一致的元数据文件目录树，同时启动一个定时线程从JournalNodeCluster拉取最新的FSEditlog文件，最后通过解析FSEditlog文件不断更新文件目录树。NameNode analysis的所有针对元数据的请求，需要对元数据文件目录树进行全局的扫描工作，但是由于所有数据均在内存中保存，因此这样的查询并不会非常耗时。同时由于NameNode analysis在元数据存储结构、处理逻辑上与NameNode保持一致，也就保证了数据的准确性。

这种数据存储方案中，虽然通过NameNode analysis在内存中构建与NameNode一致的元数据文件目录树能够保证数据的准确性，但是，由于NameNode构建的元数据文件目录树已经消耗了较大的内存，此时NameNode analysis产生高内存消耗，可能导致系统的内存占用率较高，降低系统的性能；同时，由于NameNode在运行过程中会将用户所有的写入操作记录在FSEditlog文件中，默认情况下每2分钟会生成一个FSEditlog文件，为了防止FSEditlog文件堆积过多，NameNode使用了一种合成机制(Checkpoint机制)，该机制会定时的把旧的FSEditlog文件和旧的FSImage文件进行合并形成新的FSImage文件，并把已经合成的FSEditlog文件进行删除。在NameNode analysis实际执行过程中发现，当集群规达到一定大小且集群操作读写较多时，NameNode的合成机制会非常频繁的触发，在这种情况下，基于存算强关联的NameNode analysis会因为自身解析性能的瓶颈，在NameNode触发合成机制前，来不及解析所有的FSEditlog文件，进而使得整个服务启动失败，降低了系统的稳定性，降低数据的处理效率。

基于上述内容，本公开的基本思想在于，通过基于存算解耦模式的元数据分析进程和采用键值对存储形式的目标数据库替代NameNode analysis，进而启动该元数据分析进程，并基于元数据分析进程从元数据管理节点获取待分析元数据；通过元数据分析进程对待分析元数据进行解析处理，得到待存储元数据；基于元数据分析进程将待存储元数据存储到目标数据库中，从而能够有效降低元数据存储对系统内存的占用，提升处理元数据的效率，提升系统稳定性。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施例。

应用场景总览

首先参考图1，图1示出了可以应用本公开实施例的一种数据存储方法及装置的示例性应用场景的系统架构的示意框图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

本公开实施例所提供的数据存储方法一般由服务器105执行，相应地，数据存储装置一般设置于服务器105中。但本领域技术人员容易理解的是，本公开实施例所提供的数据存储方法也可以由终端设备101、102、103执行，相应的，数据存储装置也可以设置于终端设备101、102、103中，本示例性实施例中对此不做特殊限定。

应该理解的是，图1所示的应用场景仅是本公开的实施例可以在其中得以实现的一个示例。本公开实施例的适用范围不受到该应用场景任何方面的限制。

示例性方法

下面结合图1的应用场景，参考图2来描述根据本公开示例性实施例的数据存储方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施例在此方面不受任何限制。相反，本公开的实施例可以应用于适用的任何场景。

本公开首先提供了一种数据存储方法，本示例实施例中以服务器执行该方法为例进行说明。

参照图2所示，在步骤S210中，启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据。

在示例实施例中，元数据分析进程是指在分布式文件系统中实现数据查询分析功能的进程，其中，分布式文件系统包括但不限于HDFS文件系统。

元数据管理节点是指分布式文件系统中管理元数据的节点，例如，元数据管理节点可以包括HDFS文件系统中的NameNode(可以生成FSImage文件)，也可以包括HDFS文件系统中的NameNode关联的JournalNode Cluster(可以生成FSEditlog文件或者FSAuditlog文件)。

元数据分析进程可以包括拉取线程、解析计算单线程、存储队列以及至少一个存储线程，其中，拉取线程可以用于从元数据管理节点周期性获取最新的元数据；解析计算单线程可以用于将拉取线程获取的元数据进行解析，得到解析后的元数据；存储队列可以用于缓存解析计算单线程生成的解析后的元数据；至少一个存储线程可以用于将存储队列中缓存的解析后的元数据异步存储到目标数据库中。

在步骤S220中，通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据。

在示例实施例中，待分析元数据是指分布式文件系统中元数据分析进程尚未进行解析的元数据，例如，待分析元数据可以是NameNode生成的尚未进行解析的FSImage文件，也可以是NameNode关联的JournalNode Cluster生成的FSEditlog文件或者FSAuditlog文件，本示例实施例对此不做特殊限定。

待存储元数据是指元数据分析进程对待分析元数据进行解析后并存储在存储队列中的元数据，例如，待存储元数据可以是解析后存储在存储队列中的FSImage文件，也可以是解析后存储在存储队列中的FSEditlog文件或者FSAuditlog文件，本示例实施例对此不做特殊限定。

在步骤S230中，基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

在示例实施例中，目标数据库是指用于存储元数据分析进程解析得到的待存储元数据的数据库，例如，目标数据库可以是Hbase数据库(一种在HDFS基础上构建的一个分布式、可伸缩的数据库，适用于海量数据的存储场景)，也可以是Redise数据库(一种开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库)，当然，还可以是其他类型的分布式数据库，本示例实施例对此不做特殊限定。

根据图2示例实施例的技术方案，一方面，通过元数据分析进程以及目标数据库的结合，将元数据存储在目标数据库中，能够避免相关方案中的NameNode analysis为了满足频繁的元数据查询请求而将元数据存储在内存中导致高内存消耗的问题，降低内存的占用，提升系统性能；另一方面，通过基于存算解耦模式的元数据分析进程能够实现对元数据文件的快速解析，避免基于存算强关联的NameNode analysis解析元数据文件具有性能瓶颈的问题，提升系统稳定性，提高系统的数据处理效率。

下面，以目标数据库为Hbase数据库的情况对图2中的步骤S210至步骤S230进行详细说明。

在示例实施例中，元数据分析进程可以包括解析计算单线程和存储队列，具体可以通过图3中的步骤实现对待分析元数据的解析处理，参考图3所示，具体可以包括：

步骤S310，通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据；以及

步骤S320，将所述待存储元数据存储到所述存储队列中。

其中，解析计算单线程可以用于将拉取线程获取的元数据进行解析，得到解析后的元数据。解析计算单线程需要解析FSEditlog文件，针对每一条操作记录，进行具体的处理。由于FSEditlog文件中记录的每条记录都有一定的关联性，比如前一条记录是创建目录操作，后一条操作就可能在这个目录下新建一个文件。鉴于每条操作之间的强关联性，很难在并发的情况下保证元数据的准确性，因此，在最终设计上，解析计算单线程可以实现为单线程处理，进而保证数据准确。

存储队列可以用于缓存解析计算单线程解析得到的待存储元数据，通过存储队列作为解析计算单线程与存储线程之间的缓冲区域，实现元数据分析进程解析计算过程与存储过程的解耦，避免由于计算过程与存储过程之间强关联(例如，强关联是指计算过程解析得到的数据，必须等到存储过程将该数据存储后计算过程才能够进行下一次解析计算)导致解析计算单线程无法及时处理FSEditlog文件产生服务崩溃的问题。

进一步的，元数据分析进程还可以包括至少一个存储线程，基于至少一个存储线程将待存储元数据异步存储到目标数据库中。其中，至少一个存储线程可以用于将存储队列中缓存的待存储元数据异步存储到目标数据库中。

由于NameNode会将FSEditlog文件定期的删除，这就要求元数据服务在NameNode启动删除任务之前，就必须将FSEditlog文件记录的数据全部处理结束。而相关方案中的NameNode analysis采用存算一体的方式，无法实现较好的元数据处理性能。因此，为了及时处理FSEditLog文件，增强系统的元数据处理性能，通过由解析计算单线程、存储队列和至少一个存储线程构成的元数据分析进程实现存算分离的技术方案，增加系统的并发处理性能，提升FSEditlog文件的处理效率，提升系统稳定性。

具体的，待分析元数据可以包括镜像文件和第一编辑日志，其中，镜像文件可以是指FSImage文件，第一编辑日志可以是指FSEditlog文件，可以在元数据管理节点将镜像文件和第一编辑日志合并之前，通过解析计算单线程对第一编辑日志进行解析处理，将解析后的第一编辑日志以及镜像文件作为待存储元数据。

在示例实施例中，在元数据分析进程对待分析元数据进行解析计算得到待存储元数据之后，可以通过图4中的步骤基于至少一个存储线程将待存储元数据存储到目标数据库Hbase中，参考图4所示，具体可以包括：

步骤S410，确定所述待存储元数据对应的绝对路径以及元数据信息；

步骤S420，将所述绝对路径作为列键以及将所述元数据信息作为所述列键的键值，以构建所述待存储元数据对应的第一键值对；

步骤S430，基于所述第一键值对将所述待存储元数据存储到所述目标数据库中。

其中，绝对路径是指待存储元数据中包含的数据在分布式文件系统中对应的存储位置，例如，待存储元数据的绝对路径可以是/user/music/data，当然，此处仅是示意性举例说明，并不应对本示例实施例造成任何特殊限定。元数据信息是指待存储元数据包含的数据对应的属性信息，例如，元数据信息可以是数据块的分布信息，也可以是数据的访问权限，本示例实施例对此不做特殊限定。

列键是指Hbase的存储方式中的RowKey，列键的键值是指Hbase的存储方式中的Value。在使用Hbase作为待存储元数据的存储方案时，由于Hbase数据库是基于键值对(RowKey-Value)的存储方式，因此可以将待存储元数据的绝对路径作为RowKey，将元数据信息作为Value，构成第一键值对(绝对路径-元数据信息)存储在Hbase中，这样，在用户请求查询对应的元数据时，元数据分析进程能够根据查询分析请求中包含的路径与键值对中的绝对路径进行匹配，以点对点的方式快速直接定位到对应的元数据信息，能够有效提升元数据信息的查询读取效率。

进一步的，可以根据绝对路径将属于同一主目录下的键值对存储到目标数据库中的同一区域。其中，属于同一主目录下的键值对是指绝对路径的第一层目录是相同的键值对，可以通过绝对路径筛选得到属于同一主目录下的键值对，例如，对于绝对路径分别为“/user/music/data”和“/user/image/type”的键值对属于同一主目录“/user”下的键值对，当然，此处仅是示意性举例说明，本示例实施例对此不做特殊限定。一般来说，用户在查询元数据时，会请求查询同一目录下的多个文件，因此，通过将属于同一主目录下的键值对存储到目标数据库Hbase中的同一区域(Region)，在用户查询同一主目录下的相关元数据时，不需要跨区域去查询元数据，能够有效提升目标数据库在查找同一主目录下的元数据的效率，提升元数据信息的查询读取效率。

在示例实施例中，目标数据库Hbase可以包括多个存储管理节点，可以将待存储元数据平均分发到多个存储管理节点中进行存储。通过将待存储元数据平均分发到多个存储管理节点中进行存储，能够避免将数据集中存储到某个存储管理节点中，导致该存储管理节点的读取请求过多影响数据读取效率的问题，提升数据查询效率。

具体的，待分析元数据还可以包括第二编辑日志，该第二编辑日志可以是FSAuditlog文件，具体还可以通过图5中的步骤实现将待存储元数据存储到目标数据库Hbase的多个存储管理节点上，参考图5所示，具体可以包括：

步骤S510，根据所述第二编辑日志确定各所述待存储元数据的读写热度值；

步骤S520，将所述读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上。

其中，读写热度值可以是指表征元数据的读写频率的数据，例如，读写热度值可以是100，可以表示该元数据在一分钟内被读操作和写操作共处理了100次，而热度值阈值是指预先定义的、用于表征元数据的读写热度值是否满足要求的数值，例如，热度值阈值可以是80，当元数据的读写热度值为100，大于热度值阈值，可以认为该元数据更容易被用户所查询或者修改，当然，热度值阈值也可以是100，具体的热度值阈值可以根据实际情况进行自定义设置，此处仅是示意性举例说明，并不应对本示例实施例造成任何特殊限定。

在示例实施例中，可以将读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上，例如，在当前时刻检测到待存储元数据A的读写热度值大于或者等于热度值阈值，则将待存储元数据A存储到存储管理节点1上，那么在下一时刻检测到待存储元数据B的读写热度值大于或者等于热度值阈值，则将待存储元数据B存储到存储管理节点2上，实现将读写热度值大于或者等于热度值阈值的待存储元数据存储在不同的存储管理节点，能够有效避免将热点数据集中存储到一个存储管理节点中导致该存储管理节点的读写请求过于繁忙，使存储管理节点的数据处理效率降低的问题，提升分布式文件系统的数据处理效率。

在示例实施例中，还可以通过图6中的步骤实现将待存储元数据存储到目标数据库Hbase的多个存储管理节点上，参考图6所示，具体可以包括：

步骤S610，根据所述待存储元数据对应的绝对路径确定路径深度值；

步骤S620，结合所述路径深度值、所述绝对路径和所述待存储元数据对应的元数据信息构建所述待存储元数据对应的第二键值对；

步骤S630，基于所述第二键值对将所述待存储元数据分别存储在不同的所述存储管理节点上。

其中，路径深度值是指待存储元数据对应的绝对路径对应的路径的深度，例如，对于绝对路径“/user/music/data”，其路径深度值为3，对于绝对路径“/user/music/data/time”，其路径深度值为4。第二键值对是指根据绝对路径、绝对路径对应的路径深度值以及元数据信息构成的键值对，例如，可以将待存储元数据的绝对路径以及绝对路径对应的路径深度值作为键值对的RowKey以及将元数据信息作为键值对的Value构成第二键值对，即“(路径深度值+绝对路径)-元数据信息”，例如，待存储元数据对应的绝对路径为“/user/music/data”，该绝对路径对应的深度值为3，待存储元数据对应的元数据为“meta”，那么构建得到的第二键值对为“(3+/user/music/data)-meta”，当然，此处仅是示意性举例说明，并不应对本示例实施例造成任何特殊限定。这样，在将第二键值对存储在Hbase数据库中后，可以根据路径深度值对待存储元数据进行自动编码以便于划分存储，实现将待存储元数据均匀分散存储到不同的存储管理节点上，保证目标数据库中各存储管理节点存储的数据量大致相同，避免元数据集中存储到部分存储管理节点上导致存储管理节点性能下降或者崩溃的现象，有效提升元数据信息的读取效率；同时，通过路径深度值对待存储元数据进行自动编码并分区域存储，能够有效降低划分元数据时的工作量，提升元数据的存储效率。

在示例实施例中，可以通过图7中步骤实现对存储到目标数据库中的元数据的查询，参考图7所示，具体可以包括：

步骤S710，通过所述元数据分析进程对应的元数据查询接口获取客户端对存储到所述目标数据库中的元数据的查询分析请求，并根据所述查询分析请求确定待请求元数据的目标路径；

步骤S720，基于所述元数据查询接口，根据所述目标路径从所述目标数据库中筛选目标键值对，并根据所述目标键值对读取所述待请求元数据对应的元数据信息；

步骤S730，将所述元数据信息返回给所述客户端。

其中，查询分析请求是指客户端发送的用于查询元数据的请求，该查询分析请求可以包括查询元数据的目标路径，进而可以通过元数据查询接口从目标数据库中匹配与目标路径匹配的目标键值对，进而通过目标键值对获取待查询的元数据得到元数据信息。

具体的，分布式文件系统可以包括缓存队列，具体可以通过图8中的步骤实现对元数据信息的读取，参考图8所示，具体可以包括：

步骤S810，将所述元数据信息缓存到所述缓存队列中，以在新的查询分析请求需要读取所述元数据信息时，直接从所述缓存队列中读取；以及

步骤S820，如果所述缓存队列中的所述元数据信息的空闲时间大于预设的超时阈值，则将所述元数据信息从所述缓存队列中移除。

其中，缓存队列是指临时存储客户端已经请求过的元数据的消息队列，例如，缓存队列可以是一个能够缓存5000-20000个元数据信息的固定大小的消息队列，当然，缓存队列也可以由一个用于缓存元数据对应的目录、文件信息的固定大小为10000(即能够缓存10000个数据消息)的消息队列，与一个用于缓存元数据对应的目录列表信息的固定大小为10000的消息队列共同构成，其中，缓存队列的大小可以根据存储的元数据的总数量而定，本示例实施例对此不做特殊限定。通过固定大小的缓存队列暂时缓存短时间内多次被请求的元数据(即热点元数据)的相关信息，能够有效减少对目标数据库的访问请求次数，降低目标数据库的数据读取压力，提升元数据查询响应速度，提高系统的数据处理效率。

空闲时间是指缓存在缓存队列中的元数据信息未被请求的时间值，例如，某元数据信息的空闲时间可以是10s，则可以表示该元数据信息从第一次被客户端请求并缓存在缓存队列中之后，已经有10s没有被重新请求使用过。超时阈值是指判断元数据信息的空闲时间是否满足移除要求的数值，例如，超时阈值可以是5分钟，可以表示在元数据信息的空闲时间大于5分钟时，则可以表示该元数据信息并不是当前的热点数据，因此将其从缓存队列中移除。当然，此处仅是示意性举例说明，本示例实施例对此不做特殊限定。由于缓存队列是基于内存建立的，因此，通过将空闲时间大于超时阈值的元数据信息从缓存队列中移除，能够有效减少缓存队列对内存的消耗，提升系统性能。

图9示意性地示出了根据本公开的一些实施例的相关方案中数据存储的架构示意图。

参考图9所示，步骤S910，客户端901向管理节点元数据分析服务902发送元数据查询请求；

步骤S920，管理节点元数据分析服务902(NameNode analysis)从管理节点903(NameNode)拉取镜像文件FSImage；

步骤S930，管理节点元数据分析服务902从一致性存储系统904(JournalNodeCluster)拉取第一编辑日志FSEditlog或者第二编辑日志FSAuditlog，解析FSEditlog或者FSAuditlog，并将解析后的数据存储到内存中更新文件目录树；

步骤S940，管理节点元数据分析服务902根据客户端901的元数据查询请求从内存中的文件目录树查找相应的元数据信息，并将元数据信息返回给客户端901。

基于此，本公开还提供了一种分布式文件系统，参考图10所示，分布式文件系统可以包括元数据管理节点1010、元数据分析进程1020、目标数据库1030、客户端1040以及元数据查询接口1050。其中：

客户端1040可以用于生成查询分析请求。

元数据管理节点1010可以用于生成元数据，例如，元数据可以包括镜像文件1011(FSImage)、第一编辑日志1012(FSEditlog)以及第二编辑日志1013(FSAuditlog)。

目标数据库1030可以包括多个存储管理节点，可以用于将接收到的数据转化成键值对的形式进行存储。

元数据分析进程1020与客户端1040、目标数据库1030和元数据管理节点1010对接，用于对元数据进行解析，并将解析后的元数据发送给目标数据库1030进行存储，或者基于从查询分析请求目标数据库1030读取对应的元数据；其中，元数据分析进程1020可以设置在分布式文件系统中的元数据分析服务、元数据分析接口、元数据分析节点或者元数据分析服务器，可以用于执行本示例实施例中的数据存储方法。

元数据查询接口1050用于解析客户端1040生成的查询分析请求，并根据解析得到的目标路径从目标数据库1030中筛选目标键值对，并根据目标键值对读取请求的元数据对应的元数据信息，将元数据信息返回给客户端1040。

分布式文件系统还可以包括缓存队列，该缓存队列与元数据分析进程和目标数据库对接，可以用于缓存已经读取的查询分析请求对应的元数据信息。

具体的，元数据分析进程1020可以包括拉取线程、解析计算单线程、存储队列和至少一个存储线程。其中：

拉取线程可以用于从元数据管理节点周期性获取最新的元数据；

解析计算单线程可以用于将拉取线程获取的元数据进行解析，得到解析后的元数据；

存储队列可以用于缓存解析计算单线程生成的解析后的元数据；

至少一个存储线程可以用于将存储队列中缓存的解析后的元数据异步存储到目标数据库中。

图11示意性地示出了根据本公开的一些实施例的元数据分析进程存取元数据的流程示意图。

参考图11所示，步骤S1110，基于元数据分析进程1101中的拉取线程1102定时从管理节点NameNode以及一致性存储系统JournalNode Cluster拉取最新生成的待分析元数据，例如，待分析元数据可以是镜像文件FSImage、第一编辑日志FSEditlog以及第二编辑日志FSAuditlog；

步骤S1120，基于元数据分析进程1101中的解析计算单线程1103对拉取线程1102拉取的待分析元数据进行单线程解析计算处理，得到待存储元数据，并将得到待存储元数据存储到存储队列中；

步骤S1130，基于元数据分析进程1101中的至少一个存储线程1104将存储到存储队列中的待存储元数据以键值对的形式异步存储到目标数据库1105中；

步骤S1140，在接收到元数据查询接口发送的查询分析请求时，基于元数据分析进程1101中的解析计算单线程1103解析得到查询分析请求中的目标路径，并根据目标路径从目标数据库1105匹配得到目标键值对，并将目标键值对对应的元数据信息通过元数据查询接口返回给客户端，同时将该元数据信息存储到缓存队列1106中。

示例性装置

在介绍了本公开示例性实施例的方法之后，接下来，参考图12对本公开示例性实施例的数据存储装置。

在图12中，数据存储装置1200可以包括：待分析元数据获取模块1210、待分析元数据解析模块1220以及待存储元数据存储模块1230。其中：

待分析元数据获取模块1210用于启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；

待分析元数据解析模块1220用于通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；

待存储元数据存储模块1230用于基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程包括解析计算单线程和存储队列，所述待分析元数据解析模块1220包括：

解析单元，用于通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据；以及

存储单元，用于将所述待存储元数据存储到所述存储队列中。

在本公开的一些实施例中，基于前述方案，所述元数据分析进程还包括至少一个存储线程，所述待存储元数据存储模块1230包括：

异步存储单元，用于基于所述至少一个存储线程将所述待存储元数据异步存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括镜像文件和第一编辑日志，所述解析单元还用于：

在所述元数据管理节点将所述镜像文件和所述第一编辑日志合并之前，通过所述解析计算单线程对所述第一编辑日志进行解析处理，将解析后的第一编辑日志以及所述镜像文件作为所述待存储元数据。

在本公开的一些实施例中，基于前述方案，所述数据存储装置1200还包括：

信息确定单元，用于确定所述待存储元数据对应的绝对路径以及元数据信息；

键值对构建单元，用于将所述绝对路径作为列键以及将所述元数据信息作为所述列键的键值，以构建所述待存储元数据对应的第一键值对；

数据存储单元，用于基于所述第一键值对将所述待存储元数据存储到所述目标数据库中。

在本公开的一些实施例中，基于前述方案，所述数据存储装置1200还包括：

区域存储单元，用于根据所述绝对路径将属于同一主目录下的所述键值对存储到所述目标数据库中的同一区域。

在本公开的一些实施例中，基于前述方案，所述目标数据库包括多个存储管理节点，所述数据存储装置还包括：

均匀存储单元，用于将所述待存储元数据平均分发到所述多个存储管理节点中进行存储。

在本公开的一些实施例中，基于前述方案，所述待分析元数据包括第二编辑日志，所述数据存储装置还包括热点数据分开存储单元，所述热点数据分开存储单元用于：

根据所述第二编辑日志确定各所述待存储元数据的读写热度值；

将所述读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述均匀存储单元还用于：

根据所述待存储元数据对应的绝对路径确定路径深度值；

结合所述路径深度值、所述绝对路径和所述待存储元数据对应的元数据信息构建所述待存储元数据对应的第二键值对；

基于所述第二键值对将所述待存储元数据分别存储在不同的所述存储管理节点上。

在本公开的一些实施例中，基于前述方案，所述数据存储装置1200还包括数据查询单元，所述数据查询单元用于：

通过所述元数据分析进程对应的元数据查询接口获取客户端对存储到所述目标数据库中的元数据的查询分析请求，并根据所述查询分析请求确定待请求元数据的目标路径；

基于所述元数据查询接口，根据所述目标路径从所述目标数据库中筛选目标键值对，并根据所述目标键值对读取所述待请求元数据对应的元数据信息；

将所述元数据信息返回给所述客户端。

在本公开的一些实施例中，基于前述方案，所述分布式文件系统包括缓存队列，所述数据存储装置1200还包括请求数据缓存单元，所述请求数据缓存单元用于：

将所述元数据信息缓存到所述缓存队列中，以在新的查询分析请求需要读取所述元数据信息时，直接从所述缓存队列中读取；以及

如果所述缓存队列中的所述元数据信息的空闲时间大于预设的超时阈值，则将所述元数据信息从所述缓存队列中移除。

在本公开实施例的第三方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的数据存储方法。

示例性介质

在介绍了本公开示例性实施例的装置之后，接下来，对本公开示例性实施例的存储介质进行说明。

在一些实施例中，本公开的各个方面还可以实现为一种介质，其上存储有程序代码，当所述程序代码被设备的处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的数据存储方法中的步骤。

例如，所述设备的处理器执行所述程序代码时可以实现如图2中所述的步骤S210，启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；步骤S220，通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；步骤S230，基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

参考图13所示，描述了根据本公开的实施例的用于实现上述数据存储方法的程序产品1300，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性计算设备

在介绍了本公开示例性实施例的数据存储方法、数据存储装置以及存储介质之后，接下来，介绍根据本公开的示例性实施例的电子设备。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施例、完全的软件实施例(包括固件、微代码等)，或硬件和软件方面结合的实施例，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施例中，根据本公开的电子设备可以至少包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的数据存储方法中的步骤。例如，所述处理单元可以执行如图2中所示的步骤步骤S210，启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；步骤S220，通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；步骤S230，基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

下面参照图14来描述根据本公开的示例实施例的电子设备1400。图14所示的电子设备1400仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图14所示，电子设备1400以通用计算设备的形式表现。电子设备1400的组件可以包括但不限于：上述至少一个处理单元1401、上述至少一个存储单元1402、连接不同系统组件(包括存储单元1402和处理单元1401)的总线1403、显示单元1407。

总线1403表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、图形加速端口、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元1402可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1421和/或高速缓存存储器1422，还可以进一步包括只读存储器(ROM)1423。

存储单元1402还可以包括具有一组(至少一个)程序模块1424的程序/实用工具1425，这样的程序模块1424包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备1400也可以与一个或多个外部设备1404(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与电子设备1400交互的设备通信，和/或与使得电子设备1400能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1405进行。并且，电子设备1400还可以通过网络适配器1406与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1406通过总线1403与电子设备1400的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了数据存储装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施例，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施例描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施例，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种数据存储方法，其特征在于，应用于分布式文件系统，所述分布式文件系统包括元数据管理节点、基于存算解耦模式的元数据分析进程和采用键值对存储形式的目标数据库，所述方法包括：

启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；

通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；

基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

2.根据权利要求1所述的方法，其特征在于，所述元数据分析进程包括解析计算单线程和存储队列，所述通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据，包括：

通过所述解析计算单线程对所述待分析元数据进行解析处理，得到待存储元数据；以及

将所述待存储元数据存储到所述存储队列中。

3.根据权利要求1所述的方法，其特征在于，所述元数据分析进程还包括至少一个存储线程，所述基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中，包括：

基于所述至少一个存储线程将所述待存储元数据异步存储到所述目标数据库中。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

确定所述待存储元数据对应的绝对路径以及元数据信息；

将所述绝对路径作为列键以及将所述元数据信息作为所述列键的键值，以构建所述待存储元数据对应的第一键值对；

基于所述第一键值对将所述待存储元数据存储到所述目标数据库中。

5.根据权利要求1所述的方法，其特征在于，所述待分析元数据包括第二编辑日志，所述方法还包括：

根据所述第二编辑日志确定各所述待存储元数据的读写热度值；

将所述读写热度值大于或者等于热度值阈值的待存储元数据按照存储顺序分别存储在不同的存储管理节点上。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

根据所述待存储元数据对应的绝对路径确定路径深度值；

结合所述路径深度值、所述绝对路径和所述待存储元数据对应的元数据信息构建所述待存储元数据对应的第二键值对；

基于所述第二键值对将所述待存储元数据分别存储在不同的所述存储管理节点上。

7.一种数据存储装置，其特征在于，应用于分布式文件系统，所述分布式文件系统包括元数据管理节点、基于存算解耦模式的元数据分析进程和采用键值对存储形式的目标数据库，包括：

待分析元数据获取模块，用于启动所述元数据分析进程，并基于所述元数据分析进程从所述元数据管理节点获取待分析元数据；

待分析元数据解析模块，用于通过所述元数据分析进程对所述待分析元数据进行解析处理，得到待存储元数据；

待存储元数据存储模块，用于基于所述元数据分析进程将所述待存储元数据存储到所述目标数据库中。

8.一种分布式文件系统，其特征在于，包括：

客户端，用于生成查询分析请求；

元数据管理节点，用于生成元数据；

目标数据库，包括多个存储管理节点，用于将接收到的数据转化成键值对的形式进行存储；

元数据分析进程，与所述客户端、所述目标数据库和所述元数据管理节点对接，用于对所述元数据进行解析，并将解析后的元数据发送给所述目标数据库进行存储，或者基于所述从查询分析请求所述目标数据库读取对应的元数据。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如权利要求1至6中任意一项所述的数据存储方法。

10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6中任意一项所述的数据存储方法。

Images