一种元数据的管理方法、相关装置、设备以及存储介质

技术领域

本申请涉及云技术领域，尤其涉及一种元数据的管理方法、相关装置、设备以及存储介质。

背景技术

分布式数据仓库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来，并组成一个逻辑上统一的数据仓库。近年来，随着数据量的高速增长，分布式数据仓库技术也得到了快速的发展。分布式数据仓库将数据分散存储到多个通过网络连接的数据节点上，以此可获得更大的存储容量和更高的并发访问量。

分布式数据仓库的元数据管理非常重要。在现有方案中，可将元数据持久化到关系型数据库中。在调用元数据时，首先需要查询元数据，以获取库表结构和数据存储位置，然后执行结构化查询语言(Structured Query Language，SQL)，以此实现对元数据的增删改查等操作。

发明人发现现有方案中至少存在如下问题，由于所有租户共用一个元数据库进行元数据管理，因此，多租户之间无法实现元数据资源的隔离。例如，租户A创建了名为“DB.01”的元数据库，那么租户B则无法再创建名为“DB.01”的元数据库，从而导致租户之间的元数据资源受到影响。

发明内容

本申请实施例提供了一种元数据的管理方法、相关装置、设备以及存储介质。不仅有利于扩展云账号对于元数据管理的边界，而且能够实现元数据资源(例如，元数据库和元数据表)的隔离，从而达到更好的元数据管理效果。

有鉴于此，本申请一方面提供一种元数据的管理方法，包括：

接收客户端发送的账号认证请求，其中，账号认证请求携带云账号信息；

若账号认证请求校验成功，则向客户端发送元数据租户集合，其中，元数据租户集合与云账号信息具有绑定关系；

响应于客户端发送的租户选择请求，向客户端发送元数据库集合，其中，租户选择请求携带目标元数据租户的标识，目标元数据租户包含于元数据租户集合，元数据库集合与目标元数据租户具有映射关系；

响应于客户端发送的数据库查询请求，向客户端发送元数据表集合，其中，数据库查询请求携带目标元数据库的标识，目标元数据库包含于元数据库集合，元数据表集合与目标元数据库具有映射关系。

本申请另一方面提供一种元数据管理装置，包括：

接收模块，用于接收客户端发送的账号认证请求，其中，账号认证请求携带云账号信息；

发送模块，用于若账号认证请求校验成功，则向客户端发送元数据租户集合，其中，元数据租户集合与云账号信息具有绑定关系；

发送模块，还用于响应于客户端发送的租户选择请求，向客户端发送元数据库集合，其中，租户选择请求携带目标元数据租户的标识，目标元数据租户包含于元数据租户集合，元数据库集合与目标元数据租户具有映射关系；

发送模块，还用于响应于客户端发送的数据库查询请求，向客户端发送元数据表集合，其中，数据库查询请求携带目标元数据库的标识，目标元数据库包含于元数据库集合，元数据表集合与目标元数据库具有映射关系。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

发送模块，还用于响应于客户端发送的数据库查询请求，向客户端发送元数据表集合之后，响应于客户端发送的数据表查询请求，向客户端发送目标元数据表，其中，数据表查询请求携带目标元数据表的标识，目标元数据表包含于元数据表集合。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

发送模块，还用于若账号认证请求校验成功，则向客户端发送业务租户集合，其中，业务租户集合与云账号信息具有绑定关系；

发送模块，还用于响应于客户端发送的业务选择请求，向客户端发送基于目标业务租户生成的业务处理信息，其中，业务选择请求携带目标业务租户的标识，目标业务租户包含于业务租户集合。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

发送模块，具体用于响应于所述客户端发送的业务选择请求，确定目标元数据租户集合，其中，目标元数据租户集合与目标业务租户具有映射关系。

获取与目标元数据租户集合具有映射关系的目标元数据表集合；

根据目标元数据表集合获取业务数据；

对业务数据进行处理，得到业务处理信息。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，元数据管理装置还包括处理模块以及获取模块；

接收模块，具体用于通过目标通信接口接收客户端发送的账号认证请求，其中，目标通信接口为客户端原生支持的通信接口；

处理模块，用于若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

获取模块，用于当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

接收模块，具体用于接收客户端发送的账号认证请求，其中，账号认证请求为客户端调用第一传输方法对云账号信息封装后生成的；

调用第二传输方法对账号认证请求进行解封装处理，得到云账号信息，其中，第二传输方法与第一传输方法采用相同的协议类型；

处理模块，还用于若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

获取模块，还用于当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

接收模块，还用于若账号认证请求校验成功，则接收客户端发送的元数据表创建请求，其中，元数据表创建请求携带第一对象参数，第一对象参数包括元数据类别信息；

处理模块，还用于对元数据表创建请求中携带的第一对象参数进行参数校验；

处理模块，还用于若第一对象参数校验通过，则根据元数据类别信息创建元数据表。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

接收模块，还用于若账号认证请求校验成功，则接收客户端发送的元数据表更新请求，其中，元数据表更新请求携带第二对象参数，第二对象参数包括元数据类别信息以及表名信息；

处理模块，还用于对元数据表更新请求中携带的第二对象参数进行参数校验；

获取模块，还用于若第二对象参数校验通过，则根据表名信息获取元数据表；

处理模块，还用于将元数据表中的字段信息进行删除，并根据元数据类别信息对元数据表进行更新。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

接收模块，还用于若账号认证请求校验成功，则接收客户端发送的元数据表删除请求，其中，元数据表删除请求携带第三对象参数，第三对象参数包括元数据类别信息以及表名信息；

处理模块，还用于对元数据表删除请求中携带的第三对象参数进行参数校验；

处理模块，还用于若第三对象参数校验通过，则根据表名信息删除元数据表。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，数据表查询请求还携带第四对象参数，其中，第四对象参数包括查询信息；

发送模块，具体用于对数据表查询请求中携带的第四对象参数进行参数校验；

若第四对象参数校验通过，则根据查询信息向客户端发送目标元数据表。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

处理模块，还用于当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

处理模块，还用于当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系；

处理模块，还用于当接收到第三查询请求时，根据第三查询请求从第三元数据表中确定与元数据表外键对应的元数据表，其中，第三查询请求携带分区标识，分区标识与元数据表外键具有关联关系；

处理模块，还用于当接收到第四查询请求时，根据第四查询请求从第四元数据表中确定与存储表外键对应的存储描述符，其中，第四查询请求携带分区标识，分区标识与存储表外键具有关联关系；

处理模块，还用于当接收到第五查询请求时，根据第五查询请求从第五元数据表中确定与存储表外键对应的存储描述符，其中，第五查询请求携带表标识，表标识与存储表外键具有关联关系；

处理模块，还用于当接收到第六查询请求时，根据第六查询请求从第六元数据表中确定与元数据库外键对应的元数据库，其中，第六查询请求携带函数标识，函数标识与元数据库外键具有关联关系。

在一种可能的设计中，在本申请实施例的另一个方面的另一种实现方式中，

处理模块，还用于当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

处理模块，还用于当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系。

本申请另一方面提供一种计算机设备，包括：存储器、处理器以及总线系统；

其中，存储器用于存储程序；

处理器用于执行存储器中的程序，处理器用于根据程序代码中的指令执行上述各方面的方法；

总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。

本申请的另一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

本申请的另一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方面所提供的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，提供了一种元数据的管理方法，接收客户端发送的账号认证请求，如果通过账号认证请求，则向客户端发送元数据租户集合，这里的元数据租户集合与云账号信息具有绑定关系。基于此，客户端可触发租户选择请求，服务器响应于客户端发送的租户选择请求，向客户端发送元数据库集合，进一步地，客户端可触发数据库查询请求，然后，服务器响应于客户端发送的数据库查询请求，向客户端发送元数据表集合，元数据表集合与目标元数据库具有映射关系。通过上述方式，在元数据库的上层设计了元数据租户的概念，将元数据租户作为租户之间隔离的最小粒度，并支持一个云账号绑定多个元数据租户的模式，由此，有利于扩展云账号对于元数据管理的边界。对于同一个元数据租户而言，具有独立的元数据管理空间，对于不同的元数据租户而言，能够实现元数据资源(例如，元数据库和元数据表)的隔离，从而达到更好的元数据管理效果。

附图说明

图1为本申请实施例中元数据管理系统的一个物理架构示意图；

图2为本申请实施例中元数据管理系统的一个逻辑架构示意图；

图3为本申请实施例中数据湖计算的一个应用场景示意图；

图4为本申请实施例中数据湖构建的一个应用场景示意图；

图5为本申请实施例中元数据管理方法的一个流程示意图；

图6为本申请实施例中多租户设计模型的一个示意图；

图7为本申请实施例中多租户设计模型的另一个示意图；

图8为本申请实施例中基于业务场景关联元数据租户的一个示意图；

图9为本申请实施例中基于业务场景关联元数据租户的另一个示意图；

图10为本申请实施例中基于业务场景关联元数据租户的另一个示意图；

图11为本申请实施例中多计算引擎兼容的一个示意图；

图12为本申请实施例中信息认证的一个流程示意图；

图13为本申请实施例中信息认证的另一个流程示意图；

图14为本申请实施例中基于安全框架的实现信息认证的一个示意图；

图15为本申请实施例中创建元数据表的一个流程示意图；

图16为本申请实施例中更新元数据表的一个流程示意图；

图17为本申请实施例中删除元数据表的一个流程示意图；

图18为本申请实施例中查询元数据表的一个流程示意图；

图19为本申请实施例中通用元数据数据模型的一个示意图；

图20为本申请实施例中通用元数据数据模型的另一个示意图；

图21为本申请实施例中响应耗时的一个对比示意图；

图22为本申请实施例中每秒请求事务数的一个对比示意图；

图23为本申请实施例中元数据管理装置的一个示意图；

图24为本申请实施例中计算机设备的一个结构示意图。

具体实施方式

本申请实施例提供了一种元数据的管理方法、相关装置、设备以及存储介质。不仅有利于扩展云账号对于元数据管理的边界，而且能够实现元数据资源(例如，元数据库和元数据表)的隔离，从而达到更好的元数据管理效果。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

随着大数据和云计算技术的广泛使用，越来越体会到数据目录和数据治理的重要性。数据治理需要清晰的知道有哪些数据，通过人工梳理的方式显然已经跟不上数据增长和变化的速度。随着数据操作的成熟以及数据管道变得越来越复杂，传统的数据目录往往不能满足这些需求。因此，实现元数据管理有着重要意义。

元数据进行管理的过程可涉及到大数据技术以及公有云应用等，下面将分别进行说明。其中，大数据(Big Data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。随着云时代的来临，大数据也吸引了越来越多的关注，大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。

公有云(Public Cloud)通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过Internet使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务。

为了达到更好的元数据管理效果，本申请提出了一种元数据的管理方法，该方法应用于元数据管理系统。为了便于理解，下面将结合图1介绍元数据管理系统的物理架构组成。请参阅图1，图1为本申请实施例中元数据管理系统的一个物理架构示意图，如图所示，元数据服务是微服务架构设计，将服务按照功能模块独立且内部闭包，服务之前的调用通过远程过程调用(Remote Procedure Call，RPC)实现。图1所示的虚线框内构成一个元数据微服务体系，主要包括三个部分，分别为基础服务、组件服务以及业务服务。其中，基础服务包括核心基础服务(Hybris Service)、统一数据源服务(Hybris DataSource)以及统一调度服务(Hybris Scheduler)，基础服务负责元数据管理的基础功能和基础模块维护，可实现元数据的增删改查，数据源管理，元数据发现调度任务管理等。组件服务包括在线元数据服务(Hybris MetaStore)以及消息中间件数据处理服务(Hybris Databus)，组件服务对外部组件提供通用的非业务处理能力，可实现元数据在线管理RPC服务和元数据消息处理服务等。业务服务包括业务接口服务(Hybris Center)，业务服务与具体的产品业务相关，可为不同的业务产品提供超文本传输协议(Hyper Text Transfer Protocol，HTTP)接口进行元数据管理。

为了便于理解，下面将结合图2介绍多租户元数据在线数据目录管理的整体架构。请参阅图2，图2为本申请实施例中元数据管理系统的一个逻辑架构示意图，如图所示，统一元数据在线管理的核心逻辑是定义数据目录模型，图示出两类数据模型定义。一类是Hive数据模型，用于存储Hive类型的元数据，提供兼容Hive Metastore的元数据目录管理核心功能，例如，数据库(Database，DB)、表(Table)、字段(Columns)和分区(Partitions)等。另一类是通用数据模型，用于存储更广泛的非Hive元数据，提供通用的其他数据源(即，其他关系型数据库管理系统)的元数据目录管理功能。在数据目录模型之上，进行多租户和认证(或，鉴权)的管理，以实现安全可靠的公有云多租户元数据在线数据目录管理；而外部组件可通过提供的自研软件开发工具包(Software Development Kit，SDK)、通用RPC接口和HTTP接口实现元数据访问与管理。

为了便于理解，下面将对本申请涉及的专业词语进行介绍。

(1)Hive元数据存储(Hive Metastore)：是Hive系统提供的内置在线元数据管理服务，主要用于管理和存储Hive中定义的数据库、表、字段和分区和用户自定义函数(UserDefined Function，UDF)等元数据。

(2)元数据：是数据的抽象，是描述数据的数据，例如：描述数据的属性信息或组织关系等。在关系型数据库中，表结构信息(包括表名和字段名列表等))是对具体表数据组织关系的描述信息，而这些表结构信息就是表数据的元数据。

(3)数据目录：是企业数据资产的有序清单，提供元数据中央汇总，便于理解数据、分析数据以及治理数据。本申请主要针对结构化数据的数据目录进行讨论，例如，关系型数据库系统下的库、表、字段以及分区等元数据。

(4)数据目录管理：基于数据目录提供的管理服务，包括数据目录的增删改查(增加、删除、改正更新和查找)功能，添加分类标签，数据地图等功能。

(5)在线数据目录管理：数据目录管理可分为在线管理和离线管理，在线管理需要保证管理操作的即时性、原子性和一致性，执行结束后，用户能很快地获取到管理操作结果。而离线管理主要基于非实时的离线计算实现数据资产挖掘和分析，例如，数据趋势分区，数据质量管理等。本申请可实现多租户的在线数据目录管理，常见场景是针对数据库、表、字段和分区等的增删改查管理操作。

(6)多租户技术：也称为多重租赁技术，是一种软件架构技术，探讨在多租户(例如，用户组和资源组等)环境下如何共用相同的程序软件，通过单一软件架构可为多个不同的租户提供服务，而每个租户关联使用的资源(由软件服务提供)是相互隔离和互不干扰的。多租户技术是云服务提供的基础能力，保证云上客户的资源隔离。本申请设计有两个多租户技术维度，分别是元数据租户和业务租户，以此实现公有云场景的通用元数据资源隔离管理。

(7)元数据租户：是本申请定义的租户维度之一，在数据目录管理中针对元数据的划分，是元数据多租户隔离的最小粒度，即一个元数据租户不同被多个上层租户(例如，用户组和资源组等)共享。本申请中，一个元数据租户可类比为一个Hive Metastore系统，或者，可以类比为一个数据库管理系统。在一个元数据租户下，可以支持创建多个不重名的数据库。

(8)业务租户：是本申请定义的租户维度之一，在数据目录管理中针对业务的划分，以通用的业务划分进行租户资源隔离，业务租户是对具体业务场景的抽象，通过业务租户的设计，使得本申请能通用适配个性化的具体业务场景。例如，数据开发平台的一个业务租户代表一个工作空间，数据湖计算的一个业务租户代表一个数据源。基于业务租户，可使用一套数据目录管理系统，支持不同的产品诉求。

(9)租户维度映射：本申请中定义的两种租户维度(即，元数据租户和业务租户)之间是没有直接且确定的关联关系，但可以通过租户维度映射定义元数据租户与业务租户的映射关系，该映射关系与具体的业务逻辑诉求相关，即根据业务场景实现具体映射的。例如，数据开发平台中一个业务租户代表一个工作空间，一个工作空间中可对应多个元数据租户，因此，业务租户与元数据租户是一对多映射关系。数据湖计算的一个业务租户代表一个数据源，一个数据源对应一个元数据租户，因此，业务租户与元数据租户是一对一映射关系。

(10)数据湖计算(Data Lake Compute，DLC)：用于提供了敏捷高效的数据湖分析与计算服务，多租户在线数据目录系统支持不同的调用访问入口和场景。为了便于理解，请参阅图3，图3为本申请实施例中数据湖计算的一个应用场景示意图，如图所示，结构化查询语言(Structured Query Language，SQL)路由是进行SQL路由转发的，识别用户传入的SQL。如果SQL为数据定义语言(Data Definition Language，DDL)类型，则路由转发给在线数据处理目录处理，如果SQL为数据查询语句(Data Query Language，DQL)类型，则路由转发给计算引擎。支持以SQL语句方式进行数据目录管理。DLC还支持通用的大数据计算引擎等，基于RPC接口方式进行数据目录管理。

(11)数据湖构建(Data Lake Formation，DLF)：用于提供数据湖的快速构建，与湖上元数据管理服务，帮助用户快速高效的构建企业数据湖技术架构。多租户在线数据目录的主要职责是与数据发现和入湖构建任务对接，提供元数据运营管理能力。其中，数据发现可支持多类型的存量数据源和云对象存储(Cloud Object Storage，COS)数据文件的元数据发现采集，获取元数据结构信息(例如，库定义结构和表定义结构)，并最终持久化维护到多租户数据目录管理系统。入湖构建可支持实时和离线的数据同步方式，将数据从原始数据源迁移集成到COS对象存储系统，迁移过程中，入湖构建任务会同步元数据信息到数据目录管理系统中，便于后续对迁移后的COS数据进行计算分析。

结合上述介绍，下面将对本申请中元数据的管理方法进行介绍，请参阅图5，本申请实施例中元数据管理方法的一个实施例包括：

110、接收客户端发送的账号认证请求，其中，账号认证请求携带云账号信息；

在一个或多个实施例中，元数据管理装置接收客户端发送的账号认证请求，账号认证请求中携带云账号信息，云账号可以是企业注册的账号，云账号信息可包括企业账号和密码等。云账号也可以是个人注册的账号，云账号信息可包括个人账号(或，手机、邮箱地址等)和密码。

需要说明的是，元数据管理装置可部署于一个或多个服务器上，不仅支持物理服务器(例如，多个物理服务器构成的服务器集群或者分布式系统)，也支持容器化的部署。

需要说明的是，客户端可通过浏览器的形式运行于终端设备上，也可以通过独立的应用程序(application，APP)的形式运行于终端设备上等，对于客户端的具体展现形式，此处不做限定。终端设备可以是智能手机、平板电脑、笔记本电脑、掌上电脑、个人电脑、智能电视、智能手表、车载设备、可穿戴设备等，但并不局限于此。

120、若账号认证请求校验成功，则向客户端发送元数据租户集合，其中，元数据租户集合与云账号信息具有绑定关系；

在一个或多个实施例中，元数据管理装置对账号认证请求中携带的云账号信息进行校验，校验成功之后，可向客户端反馈元数据租户集合，其中，一个云账号信息绑定一个元数据租户集合，元数据租户集合包括至少一个可供选择的元数据租户。

具体地，元数据租户集合可采用列表的形式呈现在客户端上，为了便于理解，请参阅表1，表1为云账号信息与元数据租户集合之间关系的一个示意。

表1

需要说明的是，表1所示的对应关系仅为一个示意，不应理解为对本申请的限定。

130、响应于客户端发送的租户选择请求，向客户端发送元数据库集合，其中，租户选择请求携带目标元数据租户的标识，目标元数据租户包含于元数据租户集合，元数据库集合与目标元数据租户具有映射关系；

在一个或多个实施例中，用户从元数据租户集合中选择一个元数据租户，并对该元数据租户触发租户选择请求，租户选择请求携带目标元数据租户的标识，这里的目标元数据租户属于元数据租户集合。元数据管理装置基于租户选择请求，向客户端反馈元数据库集合，其中，一个元数据租户关联一个元数据库集合，元数据库集合包括至少一个元数据库。

具体地，元数据库集合可采用列表的形式呈现在客户端上，结合表1，假设用户从元数据租户集合中选择“元数据租户A”作为目标元数据租户，基于此，请参阅表2，表2为目标元数据租户与元数据库集合之间关系的一个示意。

表2

需要说明的是，表2所示的对应关系仅为一个示意，不应理解为对本申请的限定。

140、响应于客户端发送的数据库查询请求，向客户端发送元数据表集合，其中，数据库查询请求携带目标元数据库的标识，目标元数据库包含于元数据库集合，元数据表集合与目标元数据库具有映射关系。

在一个或多个实施例中，用户从元数据库集合中选择一个元数据库，并对该元数据库触发数据库查询请求，数据库查询请求携带目标元数据库的标识，这里的目标元数据库属于元数据库集合。元数据管理装置基于数据库查询请求，向客户端反馈元数据表集合，其中，一个元数据库关联一个元数据表集合，元数据表集合包括至少一个元数据表。

具体地，元数据表集合可采用列表的形式呈现在客户端上，结合表3，假设用户从元数据库集合中选择“元数据库A”作为目标元数据库，基于此，请参阅表3，表3为目标元数据库与元数据表集合之间关系的一个示意。

表3

需要说明的是，表3所示的对应关系仅为一个示意，不应理解为对本申请的限定。

本申请实施例中，提供了一种元数据的管理方法。通过上述方式，在元数据库的上层设计了元数据租户的概念，将元数据租户作为租户之间隔离的最小粒度，并支持一个云账号绑定多个元数据租户的模式，由此，有利于扩展云账号对于元数据管理的边界。对于同一个元数据租户而言，具有独立的元数据管理空间，对于不同的元数据租户而言，能够实现元数据资源(例如，元数据库和元数据表)的隔离，从而达到更好的元数据管理效果。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，响应于客户端发送的数据库查询请求，向客户端发送元数据表集合之后，还可以包括：

响应于客户端发送的数据表查询请求，向客户端发送目标元数据表，其中，数据表查询请求携带目标元数据表的标识，目标元数据表包含于元数据表集合。

在一个或多个实施例中，介绍了一种基于元数据租户实现元数据表查询的方式。由前述实施例可知，用户从元数据表集合中选择一个元数据表，并对该元数据表触发数据表查询请求，数据表查询请求携带目标元数据表的标识，这里的目标元数据表属于元数据表集合。基于数据表查询请求，向客户端反馈目标元数据。

具体地，为了便于理解，请参阅图6，图6为本申请实施例中多租户设计模型的一个示意图，如图所示，云账号信息(例如，公司A申请的云账号信息)与元数据租户是一对多关系(即，1对0…*)，一个云账号信息下可创建多个元数据租户，一对多的映射关系可以类比公司A在其云账号信息下可以维护多个Hive Metastore，且这些元数据租户是私有的，与其他元数据租户的元数据是隔离的。一对多的关系可以极大的拓展单个云账号信息对于元数据管理的边界。为了便于元数据租户的管理和识别，用户可自定义元数据租户的命名空间(即，名称标识)。一个云账号信息和一个命名空间可唯一确定一个元数据租户。除此之外，元数据租户的类型是可自定义的，可以支持不同的元数据类型，例如，Hive、MySQL等。

元数据租户与元数据库是一对多关系(即，1对0…*)，基于此，一个元数据租户下可创建多个元数据库。

元数据库与元数据表是一对多关系(即，1对0…*)，一个元数据库下可创建多个元数据表。

其次，本申请实施例中，提供了一种基于元数据租户实现元数据表查询的方式，通过上述方式，针对在线数据目录管理设计了元数据租户的概念，从而能够针对元数据进行划分，将元数据租户作为多租户隔离的最小粒度，使得不同元数据租户下的元数据相互隔离，互不影响。因此，对于不同的元数据租户而言，可在元数据隔离的情况下，实现对元数据表查询等操作，从而提升方案的灵活性和可行性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

若账号认证请求校验成功，则向客户端发送业务租户集合，其中，业务租户集合与云账号信息具有绑定关系；

响应于客户端发送的业务选择请求，向客户端发送基于目标业务租户生成的业务处理信息，其中，业务选择请求携带目标业务租户的标识，目标业务租户包含于业务租户集合。

在一个或多个实施例中，介绍了一种多维租户体系下的元数据管理方式。由前述实施例可知，本申请还定义了业务租户，业务租户是对具体业务场景的抽象，以通用的业务划分进行租户资源隔离。通过业务租户的设计，能够通用适配不同个性化的具体业务场景。设计业务租户可以解耦元数据租户与具体的业务场景的强关联关系，使得底层的元数据租户与具体业务无关，而由业务租户与具体业务使用场景挂钩。

具体地，为了便于理解，请参阅图7，图7为本申请实施例中多租户设计模型的另一个示意图，如图所示，云账号信息(例如，公司A申请的云账号信息)与业务租户是一对多关系(即，1对0…*)，一个云账号信息下可创建多个业务租户。一对多的关系可以极大的拓展单个云账号信息对于业务管理的边界。为了便于业务租户的管理和识别，用户可自定义业务租户的命名空间(即，名称标识)。一个云账号信息和一个命名空间可唯一确定一个业务租户。业务租户与数据源是一对多关系(即，1对0…*)，基于此，一个业务租户下可创建多个数据源。数据源与数据源引擎是多对一关系(即，0…*对1)。

元数据管理装置对账号认证请求中携带的云账号信息进行校验，校验成功之后，可向客户端反馈业务租户集合，其中，一个云账号信息绑定一个业务租户集合，业务租户集合包括至少一个可供选择的业务租户。业务租户集合可采用列表的形式呈现在客户端上，为了便于理解，请参阅表4，表4为云账号信息与业务租户集合之间关系的一个示意。

表4

需要说明的是，表4所示的对应关系仅为一个示意，不应理解为对本申请的限定。

用户从业务租户集合中选择一个业务租户，并对该业务租户触发业务选择请求，业务选择请求携带目标业务租户的标识，这里的目标业务租户属于业务租户集合。由此，根据业务选择请求向客户端反馈基于目标业务租户生成的业务处理信息，客户端可显示该业务处理信息。一个业务租户关联一个元数据租户集合，元数据租户集合包括至少一个元数据租户。可以理解的是，业务租户与元数据租户可以是一对一的关系，或者，一对多的关系，或者，多对一的关系，又或者，多对多的关系。

结合表4，假设用户从业务租户集合中选择“业务租户_01”作为目标业务租户，基于此，请参阅表5，表5为目标业务租户与目标元数据租户集合之间关系的一个示意。

表5

需要说明的是，表5所示的对应关系仅为一个示意，不应理解为对本申请的限定。

其次，本申请实施例中，提供了一种多维租户体系下的元数据管理方式，通过上述方式，为了满足公有云场景下的多租户元数据统一管理，本申请抽象设计出多维租户领域模型，即元数据租户和业务租户。由此，能够满足不同业务场景对于统一元数据的诉求，提供公有云多租户在线数据目录管理功能。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，响应于客户端发送的类型选择请求，向客户端发送基于目标业务类型生成的业务处理信息，具体可以包括：

响应于客户端发送的业务选择请求，确定目标元数据租户集合，其中，目标元数据租户集合与目标业务租户具有映射关系。

获取与目标元数据租户集合具有映射关系的目标元数据表集合；

根据目标元数据表集合获取业务数据；

对业务数据进行处理，得到业务处理信息。

在一个或多个实施例中，介绍了一种在不同业务场景下进行业务处理的方式。由前述实施例可知，业务租户与元数据租户通过租户维度映射实现关联，租户维度映射可表现为映射表的形式，基于此，根据业务选择请求携带的目标业务租户的标识，可确定对应的目标元数据租户集合，由此，获取与目标元数据租户集合具有映射关系的目标元数据表集合，结合目标元数据表集合获取到相关的业务数据，以此，根据目标业务类型对业务数据进行相应的处理，得到业务处理信息。

示例性地，请参阅图8，图8为本申请实施例中基于业务场景关联元数据租户的一个示意图，如图所示，以数据开发平台为例，一个业务租户代表一个工作空间，一个工作空间可对应一个元数据租户集合(即，包括至少一个元数据租户)，因此，业务租户与元数据租户是一对多的映射关系。例如，工作空间_01对应的元数据租户集合包括元数据租户A、元数据租户B和元数据租户C。而工作空间_02对应的元数据租户集合包括元数据租户D和元数据租户E。

示例性地，请参阅图9，图9为本申请实施例中基于业务场景关联元数据租户的另一个示意图，如图所示，以数据开发平台为例，元数据租户与业务租户是多对多的映射关系。例如，工作空间_01对应的元数据租户集合包括元数据租户A、元数据租户B和元数据租户C。而工作空间_02对应的元数据租户集合包括元数据租户B、元数据租户C、元数据租户D和元数据租户E。

示例性地，请参阅图10，图10为本申请实施例中基于业务场景关联元数据租户的另一个示意图，如图所示，以DLC或DLF业务场景为例，一个业务租户代表一个数据源，一个数据源对应一个元数据租户，因此，业务租户与元数据租户是一对一映射关系。例如，数据源_01对应元数据租户A，数据源_02对应元数据租户B。

再次，本申请实施例中，提供了一种在不同业务场景下进行业务处理的方式，通过上述方式，基于租户维度映射实现两种租户维度之间的关联，即通过租户维度映射定义元数据租户与业务租户的映射关系，该映射关系与具体的业务逻辑诉求相关，结合具体业务场景进行映射，从而实现通用且多场景的中央元数据的在线数据目录管理系统。该在线数据目录管理系统具有高扩展，高性能，高容错的优势，并且支持多计算引擎快速适配对接。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，接收客户端发送的账号认证请求，具体可以包括：

通过目标通信接口接收客户端发送的账号认证请求，其中，目标通信接口为客户端原生支持的通信接口；

还可以包括：

若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

在一个或多个实施例中，介绍了一种在实现多计算引擎兼容的情况下增强安全认证的方式。由前述实施例可知，考虑到一些原生的在线元数据管理服务(例如，HiveMetastore)属于通用且公认的在线数据目录管理组件，因此，很多大数据组件都适配对接通用的数据目录管理组件服务(即，Hive Metastore)进行数据目录管理。为了降低存量组件和客户端的切换成本，支持快速高效的元数据系统切换，本申请设计了一套兼容通用的数据目录管理组件服务(即，Hive Metastore)的RPC接口服务，以较小的改造成本完成元数据切换对接。除了为大数据的计算分析引擎提供RPC接口调用，还提供了HTTP接口支持界面的数据目录管理操作，满足上层业务产品的多样化使用需求。

具体地，为了便于理解，请参阅图11，图11为本申请实施例中多计算引擎兼容的一个示意图，如图所示，以原生的Hive Metastore为例，在原生的Hive Metastore中定义接口类IHMSHandler，该类继承RPC接口定义的ThriftHiveMetastore.Iface。HMSHandler类实现IHMSHandler定义的所有接口，且基于Java数据对象(Java Data Objects，JDO)框架进行单租户元数据的持久化，其中，常用的元数据存储数据库包含但不仅限于Java编写的数据库(Derby)、关系型数据库管理系统(MySQL)和对象关系型数据库管理系统(PostgreSQL)等。为了保证RPC接口兼容性，本申请创建并实现自定义Handler类，该类继承IHMSHandler接口并完全重新实现元数据的管理逻辑，自定义Handler主要对请求参数进行认证鉴权和数据封装处理，通过元数据内部的RPC接口调用元数据底层服务的服务层实现持久化操作。

在RPC接口兼容性的情况下，还可以对RPC接口进行安全认证加强。为了便于理解，请参阅图12，图12为本申请实施例中信息认证的一个流程示意图，如图所示，可以复用已有接口set_ugi传递认证信息。其中，原生的set_ugi接口用于设置Hive类型中使用的分布式系统基础架构(例如，Hadoop)的用户组信息(UserGroupInformation，UGI)，即set_ugi(setUserGroupInformation)。由于公有云场景，基于COS存储无法使用Hadoop的用户组信息，因此，需要重写复用该方法接收云账号信息并进行认证校验。

在步骤A1中，元数据存储客户端(Metastore Client)创建RPC连接。

在步骤A2中，Metastore Client通过目标通信接口(即，原生的set_ugi接口)向元数据存储(Hybris Metastore)发送账号认证请求。

在步骤A3中，Hybris Metastore调用RPC服务端校验账号认证请求，如果云账号信息未通过认证，则关闭此次RPC的调用。

在步骤A4中，如果云账号信息通过认证，则云账号信息会存储在本次调用的目标会话(session)中，当账号认证请求通过时，可在本地线程(ThreadLocal)创建目标会话。

在步骤A5中，Metastore Client向Hybris Metastore发起其他的RPC请求。

在步骤A6中，从ThreadLocal的目标会话中获取该次RPC请求所需的云账号信息。

其次，本申请实施例中，提供了一种在实现多计算引擎兼容的情况下增强安全认证的方式，通过上述方式，创建并实现自定义Handler类，该Handler类继承IHMSHandler接口，并重新实现元数据的管理逻辑，自定义Handler类主要对请求参数进行认证鉴权和数据封装处理，最终通过元数据内部的RPC接口调用元数据底层服务的服务层进行持久化操作。此外，能够直接复用已经有的接口，加强对RPC接口的安全认证，从而提升数据安全性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，接收客户端发送的账号认证请求，具体可以包括：

接收客户端发送的账号认证请求，其中，账号认证请求为客户端调用第一传输方法对云账号信息封装后生成的；

调用第二传输方法对账号认证请求进行解封装处理，得到云账号信息，其中，第二传输方法与第一传输方法采用相同的协议类型；

还可以包括：

若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

在一个或多个实施例中，介绍了另一种在实现多计算引擎兼容的情况下增强安全认证的方式。由前述实施例可知，为了降低存量组件和客户端的切换成本，支持快速高效的元数据系统切换，本申请不仅设计了一套兼容原生在线元数据管理服务的RPC接口服务，还提供了HTTP接口支持界面的数据目录管理操作，满足上层业务产品的多样化使用需求。

需要说明的是，多计算引擎兼容的设计可参阅图11以及图11所对应的描述，此处不做赘述。在RPC接口兼容性的情况下，还可以对RPC接口进行安全认证加强。为了便于理解，请参阅图13，图13为本申请实施例中信息认证的另一个流程示意图，如图所示，RPC服务端使用TSaslServerTranspor，自定义认证调用函数(CallbackHandler)，从RPC客户端连接获取认证的信息进行校验。

在步骤B1中，元数据存储客户端(Metastore Client)创建RPC连接，并向元数据存储(Hybris Metastore)发送账号认证请求。

在步骤B2中，Hybris Metastore调用RPC服务端校验账号认证请求，如果云账号信息未通过认证，则关闭此次RPC的调用。

在步骤B3中，如果云账号信息通过认证，则云账号信息会存储在本次调用的目标会话(session)中，当账号认证请求通过时，可在本地线程(ThreadLocal)创建目标会话。

在步骤B4中，Metastore Client向Hybris Metastore发起其他的RPC请求。

在步骤B5中，从ThreadLocal的目标会话中获取该次RPC请求所需的云账号信息。

在扩展的RPC认证框架下，RPC服务端和RPC客户端均添加了相应的模块。请参阅图14，图14为本申请实施例中基于安全框架的实现信息认证的一个示意图，如图所示，RPC服务端调用TSaslServerTransport方法对云账号信息进行认证，RPC客户端调用TSaslClientTransport方法封装认证信息。最后，可调用TSaslTransport方法和TTransport方法进行安全认证传输。

其次，本申请实施例中，提供了另一种在实现多计算引擎兼容的情况下增强安全认证的方式，通过上述方式，创建并实现自定义Handler类，该Handler类继承IHMSHandler接口，并重新实现元数据的管理逻辑，自定义Handler类主要对请求参数进行认证鉴权和数据封装处理，最终通过元数据内部的RPC接口调用元数据底层服务的服务层进行持久化操作。此外，可以对每次请求都进行认证，从而有利于提升认证的安全性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

若账号认证请求校验成功，则接收客户端发送的元数据表创建请求，其中，元数据表创建请求携带第一对象参数，第一对象参数包括元数据类别信息；

对元数据表创建请求中携带的第一对象参数进行参数校验；

若第一对象参数校验通过，则根据元数据类别信息创建元数据表。

在一个或多个实施例中，介绍了一种创建元数据表的方式。由前述实施例可知，在线服务提供RPC接口方法，基于此，在账号认证请求校验成功之后，根据客户端发送的元数据表创建请求，可调用create_table方法创建元数据表。其中，元数据表创建请求携带第一对象参数，第一对象参数包括元数据类别信息以及其他参数。元数据类别信息用于指示数据类型，例如，Hive类型。对第一对象参数进行参数校验之后，如果校验成功，则创建对应的元数据表。

为了便于理解，下面将结合图示对元数据表的创建过程进行介绍，请参阅图15，图15为本申请实施例中创建元数据表的一个流程示意图，如图所示，在线元数据服务(HybrisMetaStore)包括在线元数据服务处理器(HybrisMetastoreHandler)以及METASTORE表转换器(MetastoreTableConverter)，核心基础服务(Hybris Service)包括元数据表服务(MetaTblService)、Hive表服务(HiveTblService)以及弹性搜索(elastic search，ES)索引。

在步骤C1中，HybrisMetastoreHandler调用create_table方法创建元数据表。

在步骤C1.1中，进行用户认证，即获取客户端的云账号信息，到认证中心进行认证校验，判断该用户是否认证通过，如果认证通过则继续执行，否则会断开连接。

在步骤C1.2中，进行对象封装及服务间接口调用，即获取RPC接口的第一对象参数，将第一对象参数进行对象封装，转换为底层服务所需的请求参数对象。

在步骤C1.3中，通过服务间调用请求底层服务的创建接口，该底层服务是一个基础组件，用于封装管理元数据的最终持久化操作。

在步骤C1.3.1中，进行通用的表创建前置校验，例如，判断参数是否齐全，是否存在租户资源限制，例如，对于数据库限制该库所能创建的数据表的个数。

在步骤C1.3.2中，前置校验成功后，根据入参指定的元数据类别信息，若是Hive类型的元数据操作，则调用Hive元数据表管理类HiveTblService执行创建。

在步骤C1.3.2.1中，进行前置校验，例如，如判断所属的数据库是否存在。

在步骤C1.3.2.2中，前置校验完成后，保存元数据表的序列化对象存储描述符(Storage Descriptor，SDS)。

在步骤C1.3.2.3中，保存表信息。

在步骤C1.3.2.4中，保存表关联的字段信息，包括分区和非分区字段。

在步骤C1.3.3中，采用通用的表创建后置钩子(Hook)执行方法，通过异步事件处理机制实现相应的操作。

在步骤C1.3.3.1中，将元数据表信息同步至ES索引，便于元数据信息的全局检索。

其次，本申请实施例中，提供了一种创建元数据表的方式，通过上述方式，能够基于在线服务提供的RPC接口方法实现元数据表的创建，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

若账号认证请求校验成功，则接收客户端发送的元数据表更新请求，其中，元数据表更新请求携带第二对象参数，第二对象参数包括元数据类别信息以及表名信息；

对元数据表更新请求中携带的第二对象参数进行参数校验；

若第二对象参数校验通过，则根据表名信息获取元数据表；

将元数据表中的字段信息进行删除，并根据元数据类别信息对元数据表进行更新。

在一个或多个实施例中，介绍了一种更新元数据表的方式。由前述实施例可知，在线服务提供RPC接口方法，基于此，在账号认证请求校验成功之后，根据客户端发送的元数据表更新请求，可调用alter_table方法更新元数据表。其中，元数据表更新请求携带第二对象参数，第二对象参数包括元数据类别信息以及表名信息等。元数据类别信息用于指示数据类型，例如，Hive类型。对第二对象参数进行参数校验之后，如果校验成功，则根据表名信息获取元数据表，然后将该元数据表中的字段信息删除，并根据元数据类别信息重新创建字段，由此，对元数据表进行更新。

为了便于理解，下面将结合图示对元数据表的创建过程进行介绍，请参阅图16，图16为本申请实施例中更新元数据表的一个流程示意图，如图所示，在线元数据服务(HybrisMetaStore)包括在线元数据服务处理器(HybrisMetastoreHandler)以及METASTORE表转换器(MetastoreTableConverter)，核心基础服务(Hybris Service)包括元数据表服务(MetaTblService)、Hive表服务(HiveTblService)以及弹性搜索(elastic search，ES)索引。

在步骤D1中，HybrisMetastoreHandler调用alter_table方法更新元数据表。

在步骤D1.1中，进行用户认证，即获取客户端的云账号信息，到认证中心进行认证校验，判断该用户是否认证通过，如果认证通过则继续执行，否则会断开连接。

在步骤D1.2中，进行对象封装及服务间接口调用，即获取RPC接口的第二对象参数，将第二对象参数进行对象封装，转换为底层服务所需的请求参数对象。

在步骤D1.3中，通过服务间调用请求底层服务的更新接口，该底层服务是一个基础组件，用于封装管理元数据的最终持久化操作。

在步骤D1.3.1中，进行通用的表创建前置校验，例如，判断参数是否齐全，是否存在租户资源限制，例如，对于数据库限制该库所能创建的数据表的个数。

在步骤D1.3.2中，前置校验成功后，根据入参指定的元数据类别信息，若是Hive类型的元数据操作，则调用Hive元数据表管理类HiveTblService执行更新操作。

在步骤D1.3.2.1中，进行前置校验，例如，如判断所属的数据库是否存在，以及对表进行重命名校验。

在步骤D1.3.2.2中，前置校验完成后，获取待更新的表的旧表原始信息。

在步骤D1.3.2.3中，判断是否存在表字段级联操作。

在步骤D1.3.2.4中，更新元数据表的序列化对象存储描述符(StorageDescriptor，SDS)。

在步骤D1.3.2.5中，更新表信息。

在步骤D1.3.2.6中，删除原有的全量字段信息。

在步骤D1.3.2.7中，重建全量表关联的字段信息(包括分区和非分区字段)

在步骤D1.3.3中，采用通用的表创建后置钩子(Hook)执行方法，通过异步事件处理机制实现相应的操作。

在步骤D1.3.3.1中，将元数据表信息同步至ES索引，便于元数据信息的全局检索。

其次，本申请实施例中，提供了一种更新元数据表的方式，通过上述方式，能够基于在线服务提供的RPC接口方法实现元数据表的更改，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

若账号认证请求校验成功，则接收客户端发送的元数据表删除请求，其中，元数据表删除请求携带第三对象参数，第三对象参数包括元数据类别信息以及表名信息；

对元数据表删除请求中携带的第三对象参数进行参数校验；

若第三对象参数校验通过，则根据表名信息删除元数据表。

在一个或多个实施例中，介绍了一种删除元数据表的方式。由前述实施例可知，在线服务提供RPC接口方法，基于此，在账号认证请求校验成功之后，根据客户端发送的元数据表删除请求，可调用alter_table方法删除元数据表。其中，元数据表删除请求携带第三对象参数，第三对象参数包括元数据类别信息以及表名信息等。元数据类别信息用于指示数据类型，例如，Hive类型。对第三对象参数进行参数校验之后，如果校验成功，则根据表名信息获取元数据表，然后将该元数据表中的字段信息删除，由此，对元数据表进行删除。

为了便于理解，下面将结合图示对元数据表的创建过程进行介绍，请参阅图17，图17为本申请实施例中删除元数据表的一个流程示意图，如图所示，在线元数据服务(HybrisMetaStore)包括在线元数据服务处理器(HybrisMetastoreHandler)以及METASTORE表转换器(MetastoreTableConverter)，核心基础服务(Hybris Service)包括元数据表服务(MetaTblService)、Hive表服务(HiveTblService)以及弹性搜索(elastic search，ES)索引。

在步骤E1中，HybrisMetastoreHandler调用delete_table方法删除元数据表。

在步骤E1.1中，进行用户认证，即获取客户端的云账号信息，到认证中心进行认证校验，判断该用户是否认证通过，如果认证通过则继续执行，否则会断开连接。

在步骤E1.2中，进行对象封装及服务间接口调用，即获取RPC接口的第三对象参数，将第三对象参数进行对象封装，转换为底层服务所需的请求参数对象。

在步骤E1.3中，通过服务间调用请求底层服务的删除接口，该底层服务是一个基础组件，用于封装管理元数据的最终持久化操作。

在步骤E1.3.1中，进行通用的表创建前置校验，例如，判断参数是否齐全，是否存在租户资源限制，例如，对于数据库限制该库所能创建的数据表的个数。

在步骤E1.3.2中，前置校验成功后，根据入参指定的元数据类别信息，若是Hive类型的元数据操作，则调用Hive元数据表管理类HiveTblService执行删除操作。

在步骤E1.3.2.1中，进行前置校验，例如，如判断所属的数据库是否存在，以及对表进行重命名校验。

在步骤E1.3.2.2中，前置校验完成后，获取待删除的表的旧表原始信息。

在步骤E1.3.2.3中，判断是否存在表字段级联操作。

在步骤E1.3.2.4中，删除元数据表的序列化对象存储描述符(StorageDescriptor，SDS)。

在步骤E1.3.2.5中，删除表信息。

在步骤E1.3.2.6中，删除原有的全量字段信息。

在步骤E1.3.3中，采用通用的表创建后置钩子(Hook)执行方法，通过异步事件处理机制实现相应的操作。

在步骤E1.3.3.1中，将元数据表信息同步至ES索引，便于元数据信息的全局检索。

其次，本申请实施例中，提供了一种删除元数据表的方式，通过上述方式，能够基于在线服务提供的RPC接口方法实现元数据表的删除，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，数据表查询请求还携带第四对象参数，其中，第四对象参数包括查询信息；

响应于客户端发送的数据表查询请求，向客户端发送目标元数据表，具体可以包括：

对数据表查询请求中携带的第四对象参数进行参数校验；

若第四对象参数校验通过，则根据查询信息向客户端发送目标元数据表。

在一个或多个实施例中，介绍了一种查找元数据表的方式。由前述实施例可知，在线服务提供RPC接口方法，基于此，在账号认证请求校验成功之后，根据客户端发送的数据表查询请求可查询元数据表。其中，元数据表创建请求携带第四对象参数，第四对象参数包括元数据类别信息以及表名信息等，对第四对象参数进行参数校验之后，如果校验成功，则查询到对应的元数据表。

为了便于理解，下面将结合图示对元数据表的查询过程进行介绍，请参阅图18，图18为本申请实施例中查询元数据表的一个流程示意图，如图所示，在线元数据服务(HybrisMetaStore)包括HMS处理器(HybrisMetastoreHandler)以及METASTORE表转换器(MetastoreTableConverter)，核心基础服务(Hybris Service)包括元数据表服务(MetaTblService)、Hive表服务(HiveTblService)以及弹性搜索(elastic search，ES)索引。

在步骤F1中，HybrisMetastoreHandler调用query_table方法查询元数据表。

在步骤F1.1中，进行用户认证，即获取客户端的云账号信息，到认证中心进行认证校验，判断该用户是否认证通过，如果认证通过则继续执行，否则会断开连接。

在步骤F1.2中，进行对象封装及服务间接口调用，即获取RPC接口的第四对象参数，将第四对象参数进行对象封装，转换为底层服务所需的请求参数对象。

在步骤F1.3中，通过服务间调用请求底层服务的查询接口，该底层服务是一个基础组件，用于封装管理元数据的最终持久化操作。

在步骤F1.3.1中，进行通用的表创建前置校验，例如，判断参数是否齐全，是否存在租户资源限制，例如，对于数据库限制该库所能创建的数据表的个数。

在步骤F1.3.2中，前置校验成功后，根据入参指定的元数据类别信息，若是Hive类型的元数据操作，则调用Hive元数据表管理类HiveTblService执行查询。

在步骤F1.3.2.1中，进行前置校验，例如，如判断所属的数据库是否存在，以及对表进行重命名校验。

在步骤F1.3.2.2中，前置校验完成后，获取查询的表详情。

在步骤F1.3.3中，采用通用的表创建后置钩子(Hook)执行方法，通过异步事件处理机制实现相应的操作。

其次，本申请实施例中，提供了一种查找元数据表的方式，通过上述方式，能够基于在线服务提供的RPC接口方法实现元数据表的查找，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系；

当接收到第三查询请求时，根据第三查询请求从第三元数据表中确定与元数据表外键对应的元数据表，其中，第三查询请求携带分区标识，分区标识与元数据表外键具有关联关系；

当接收到第四查询请求时，根据第四查询请求从第四元数据表中确定与存储表外键对应的存储描述符，其中，第四查询请求携带分区标识，分区标识与存储表外键具有关联关系；

当接收到第五查询请求时，根据第五查询请求从第五元数据表中确定与存储表外键对应的存储描述符，其中，第五查询请求携带表标识，表标识与存储表外键具有关联关系；

当接收到第六查询请求时，根据第六查询请求从第六元数据表中确定与元数据库外键对应的元数据库，其中，第六查询请求携带函数标识，函数标识与元数据库外键具有关联关系。

在一个或多个实施例中，介绍了另一种通用的元数据数据模型。由前述实施例可知，原生数据模型对于数据模块的设计比较复杂，并且进行了多个表之间的关联操作，导致元数据读写比较慢，此外，原生数据模型也无法支持多租户的设计，因此，本申请对原生的数据模型进行了改造和精简，仅能够实现多租户下元数据的逻辑划分，又能够提升元数据的读写性能。

具体地，为了便于理解，请参阅图19，图19为本申请实施例中通用元数据数据模型的一个示意图，如图所示，元数据数据模型包括元数据库(DBS)、元数据表(TBLS)、字段(COLUMNS)、存储描述符(Storage Descriptor，SDS)、分区(PARTITIONS)、分区字段(PART_COLUMNS)、用户自定义函数(User Defined Function，UDF)和UDF资源(UDF Resource)。下面将对这些模型进行说明。

元数据库(DBS)是数据库的定义，用于维护通用数据库的基本信息(例如，库名、库描述等)以及所属元数据租户。

元数据表(TBLS)是数据表的定义，用于维护通用数据表的基本信息(例如，表名、表描述等)以及所属元数据租户。

字段(COLUMNS)包括类Hive表的非分区和分区字段定义，用于维护字段的基本信息(例如，字段名、字段类型等)。

存储描述符(SDS)是Hive表的序列化存储信息描述，用于维护序列化信息(例如，序列化名称、序列化Lib包等)；

分区(PARTITIONS)是Hive表的分区信息，用于维护表分区详情(例如，具体分区名称等。

分区字段(PART_COLUMNS)是Hive表的分区字段定义，类Hive表的每个分区可独立维护对应的字段信息，若不维护，则默认以表分区字段定义为主。

示例性地，元数据表(TBLS)通过元数据库外键(Foreign Key，FK)(即，DB_ID)，维护表与库的关联关系，可通过表的记录在元数据库(DBS)上关联到对应的库记录。例如，收到第一查询请求时，基于第一查询请求中携带的表标识(即，TBL_ID)，以及TBL_ID与DB_ID之间的关联关系，可找到DB_ID对应的元数据库(DBS)，由此，实现数据查询。

示例性地，字段(COLUMNS)通过元数据表FK(即，TBL_ID)，维护字段与表的关联关系，可通过字段的记录在元数据表(TBLS)上关联到对应的表记录。例如，收到第二查询请求时，基于第二查询请求中携带的字段，以及字段与TBL_ID之间的关联关系，可找到TBL_ID对应的元数据表(TBLS)，由此，实现数据查询。

示例性地，分区(PARTITIONS)通过元数据表FK(即，TBL_ID)，维护分区与表的关联关系，可通过分区的记录在元数据表(TBLS)上关联到对应的表记录。例如，收到第三查询请求时，基于第三查询请求中携带的分区标识(即，PART_ID)，以及PART_ID与TBL_ID之间的关联关系，可找到TBL_ID对应的元数据表(TBLS)，由此，实现数据查询。

示例性地，分区(PARTITIONS)通过存储表FK(即，SD_ID)，维护分区与存储描述符的关联关系，可通过分区的记录在存储描述符(SDS)上关联到对应的记录。例如，收到第四查询请求时，基于第四查询请求中携带的分区标识(即，PART_ID)，以及PART_ID与SD_ID之间的关联关系，可找到SD_ID对应的存储描述符(SDS)，由此，实现数据查询。

示例性地，元数据表(TBLS)通过存储表FK(即，SD_ID)，维护表与存储描述符的关联关系，可通过表的记录在存储描述符(SDS)上关联到对应的记录。例如，收到第五查询请求时，基于第五查询请求中携带的表标识(即，TBL_ID)，以及TBL_ID与SD_ID之间的关联关系，可找到SD_ID对应的存储描述符(SDS)，由此，实现数据查询。

示例性地，UDF通过元数据库FK(即，DB_ID)，维护函数与库的关联关系，可通过函数在元数据库(DBS)上关联到对应的库记录。例如，收到第六查询请求时，基于第六查询请求中携带的函数标识(即，func_ID)，以及func_ID与DB_ID之间的关联关系，可找到DB_ID对应的元数据库(DBS)，由此，实现数据查询。

其次，本申请实施例中，提供了一种通用的元数据数据模型，对于Hive类型的数据而言，设计了更精简的通用数据模型，在支持元数据多租户的情况下，进行元数据资源的逻辑划分。通过底层数据模型的设计优化，能够提升元数据管理的性能，加速元数据读写性能，去除数据库的多表依赖，通过逻辑实现依赖关系。此外，基于分布式存储系统，可支持海量元数据的存储和管理。

可选地，在上述图5对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系。

在一个或多个实施例中，介绍了另一种通用的元数据数据模型。由前述实施例可知，原生数据模型对于数据模块的设计比较复杂，并且进行了多个表之间的关联操作，导致元数据读写比较慢，此外，原生数据模型也无法支持多租户的设计，因此，本申请对原生的数据模型进行了改造和精简，仅能够实现多租户下元数据的逻辑划分，又能够提升元数据的读写性能。

具体地，为了便于理解，请参阅图20，图20为本申请实施例中通用元数据数据模型的另一个示意图，如图所示，元数据数据模型包括元数据库(DBS)、元数据表(TBLS)和字段(COLUMNS)。下面将对这些模型进行说明。

元数据库(DBS)是数据库的定义，用于维护通用数据库的基本信息(例如，库名、库描述等)以及所属元数据租户。

元数据表(TBLS)是数据表的定义，用于维护通用数据表的基本信息(例如，表名、表描述等)以及所属元数据租户。

字段(COLUMNS)是表字段的定义，用于维护字段的基本信息(例如，字段名、字段类型等)。

示例性地，元数据表(TBLS)通过元数据库FK(即，DB_ID)，维护表与库的关联关系，可通过表的记录在元数据库(DBS)上关联到对应的库记录。例如，收到第一查询请求时，基于第一查询请求中携带的表标识(即，TBL_ID)，以及TBL_ID与DB_ID之间的关联关系，可找到DB_ID对应的元数据库(DBS)，由此，实现数据查询。

示例性地，字段(COLUMNS)通过元数据表FK(即，TBL_ID)，维护字段与表的关联关系，可通过字段的记录在元数据表(TBLS)上关联到对应的表记录。例如，收到第二查询请求时，基于第二查询请求中携带的字段，以及字段与TBL_ID之间的关联关系，可找到TBL_ID对应的元数据表(TBLS)，由此，实现数据查询。

其次，本申请实施例中，提供了另一种通用的元数据数据模型，对于非Hive类型的数据而言，设计了更精简的通用数据模型，例如，存储系型数据库管理系统中的元数据可采用该数据模型，仅需要关注库、表和字段的元数据即可。在支持元数据多租户的情况下，进行元数据资源的逻辑划分。通过底层数据模型的设计优化，能够提升元数据管理的性能，加速元数据读写性能，去除数据库的多表依赖，通过逻辑实现依赖关系。此外，基于分布式存储系统，可支持海量元数据的存储和管理。

基于上述介绍，下面将对本申请提供的数据目录管理性能进行评估。相比于原生的数据目录管理(例如，Hive Metastore的数据目录管理)，本申请实现了通用的公有云多租户的元数据在线数据目录管理，能够以一套软件即服务(Software-as-a-Service，SaaS)元数据管理服务，为云上不同账号提供服务，支持可扩展，高伸缩性，低成本元数据管理。

除此之外，统一元数据的在线目录管理性能得到了大幅度的提升。为了便于说明，请参阅图21，图21为本申请实施例中响应耗时的一个对比示意图，如图所示，本申请提供的数据目录管理相比于原生的数据目录管理而言，在创建库，创建表和创建分区方面的响应耗时都存在大幅度下降。请参阅图22，图22为本申请实施例中每秒请求事务数的一个对比示意图，如图所示，本申请提供的数据目录管理相比于原生的数据目录管理而言，每秒请求事务数(Transactions Per Second，TPS)也显著提升。基于1000万分区进行创建操作(其中，并发线程为200)，原生的数据目录管理针对分区操作的TPS为1200，平均响应耗时为160毫秒。本申请提供的数据目录管理针对分区操作的TPS为7000，平均响应耗时为28毫秒。

下面对本申请中的元数据管理装置进行详细描述，请参阅图23，图23为本申请实施例中元数据管理装置的一个实施例示意图，元数据管理装置20包括：

接收模块210，用于接收客户端发送的账号认证请求，其中，账号认证请求携带云账号信息；

发送模块220，用于若账号认证请求校验成功，则向客户端发送元数据租户集合，其中，元数据租户集合与云账号信息具有绑定关系；

发送模块220，还用于响应于客户端发送的租户选择请求，向客户端发送元数据库集合，其中，租户选择请求携带目标元数据租户的标识，目标元数据租户包含于元数据租户集合，元数据库集合与目标元数据租户具有映射关系；

发送模块220，还用于响应于客户端发送的数据库查询请求，向客户端发送元数据表集合，其中，数据库查询请求携带目标元数据库的标识，目标元数据库包含于元数据库集合，元数据表集合与目标元数据库具有映射关系。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，在元数据库的上层设计了元数据租户的概念，将元数据租户作为租户之间隔离的最小粒度，并支持一个云账号绑定多个元数据租户的模式，由此，有利于扩展云账号对于元数据管理的边界。对于同一个元数据租户而言，具有独立的元数据管理空间，对于不同的元数据租户而言，能够实现元数据资源(例如，元数据库和元数据表)的隔离，从而达到更好的元数据管理效果。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

发送模块220，还用于响应于客户端发送的数据库查询请求，向客户端发送元数据表集合之后，响应于客户端发送的数据表查询请求，向客户端发送目标元数据表，其中，数据表查询请求携带目标元数据表的标识，目标元数据表包含于元数据表集合。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，针对在线数据目录管理设计了元数据租户的概念，从而能够针对元数据进行划分，将元数据租户作为多租户隔离的最小粒度，使得不同元数据租户下的元数据相互隔离，互不影响。因此，对于不同的元数据租户而言，可在元数据隔离的情况下，实现对元数据表查询等操作，从而提升方案的灵活性和可行性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

发送模块220，还用于若账号认证请求校验成功，则向客户端发送业务租户集合，其中，业务租户集合与云账号信息具有绑定关系；

发送模块220，还用于响应于客户端发送的业务选择请求，向客户端发送基于目标业务租户生成的业务处理信息，其中，业务选择请求携带目标业务租户的标识，目标业务租户包含于业务租户集合。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，为了满足公有云场景下的多租户元数据统一管理，本申请抽象设计出多维租户领域模型，即元数据租户和业务租户。由此，能够满足不同业务场景对于统一元数据的诉求，提供公有云多租户在线数据目录管理功能。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

发送模块220，具体用于响应于客户端发送的业务选择请求，确定目标元数据租户集合，其中，目标元数据租户集合与目标业务租户具有映射关系。

获取与目标元数据租户集合具有映射关系的目标元数据表集合；

根据目标元数据表集合获取业务数据；

对业务数据进行处理，得到业务处理信息。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，基于租户维度映射实现两种租户维度之间的关联，即通过租户维度映射定义元数据租户与业务租户的映射关系，该映射关系与具体的业务逻辑诉求相关，结合具体业务场景进行映射，从而实现通用且多场景的中央元数据的在线数据目录管理系统。该在线数据目录管理系统具有高扩展，高性能，高容错的优势，并且支持多计算引擎快速适配对接。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，元数据管理装置20还包括处理模块230以及获取模块240；

接收模块210，具体用于通过目标通信接口接收客户端发送的账号认证请求，其中，目标通信接口为客户端原生支持的通信接口；

处理模块230，用于若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

获取模块240，还用于当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，创建并实现自定义Handler类，该Handler类继承IHMSHandler接口，并重新实现元数据的管理逻辑，自定义Handler类主要对请求参数进行认证鉴权和数据封装处理，最终通过元数据内部的RPC接口调用元数据底层服务的服务层进行持久化操作。此外，能够直接复用已经有的接口，加强对RPC接口的安全认证，从而提升数据安全性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

接收模块210，具体用于接收客户端发送的账号认证请求，其中，账号认证请求为客户端调用第一传输方法对云账号信息封装后生成的；

调用第二传输方法对账号认证请求进行解封装处理，得到云账号信息，其中，第二传输方法与第一传输方法采用相同的协议类型；

处理模块230，还用于若账号认证请求校验成功，则将云账号信息存储于目标会话中，其中，目标会话为基于账号认证请求创建的；

获取模块240，还用于当接收到远程过程调用RPC请求时，从目标会话中获取云账号信息。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，创建并实现自定义Handler类，该Handler类继承IHMSHandler接口，并重新实现元数据的管理逻辑，自定义Handler类主要对请求参数进行认证鉴权和数据封装处理，最终通过元数据内部的RPC接口调用元数据底层服务的服务层进行持久化操作。此外，可以对每次请求都进行认证，从而有利于提升认证的安全性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

接收模块210，还用于若账号认证请求校验成功，则接收客户端发送的元数据表创建请求，其中，元数据表创建请求携带第一对象参数，第一对象参数包括元数据类别信息；

处理模块230，还用于对元数据表创建请求中携带的第一对象参数进行参数校验；

处理模块230，还用于若第一对象参数校验通过，则根据元数据类别信息创建元数据表。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，能够基于在线服务提供的RPC接口方法实现元数据表的创建，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

接收模块210，还用于若账号认证请求校验成功，则接收客户端发送的元数据表更新请求，其中，元数据表更新请求携带第二对象参数，第二对象参数包括元数据类别信息以及表名信息；

处理模块230，还用于对元数据表更新请求中携带的第二对象参数进行参数校验；

获取模块240，还用于若第二对象参数校验通过，则根据表名信息获取元数据表；

处理模块230，还用于将元数据表中的字段信息进行删除，并根据元数据类别信息对元数据表进行更新。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，能够基于在线服务提供的RPC接口方法实现元数据表的更改，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

接收模块210，还用于若账号认证请求校验成功，则接收客户端发送的元数据表删除请求，其中，元数据表删除请求携带第三对象参数，第三对象参数包括元数据类别信息以及表名信息；

处理模块230，还用于对元数据表删除请求中携带的第三对象参数进行参数校验；

处理模块230，还用于若第三对象参数校验通过，则根据表名信息删除元数据表。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，能够基于在线服务提供的RPC接口方法实现元数据表的删除，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，数据表查询请求还携带第四对象参数，其中，第四对象参数包括查询信息；

发送模块220，具体用于对数据表查询请求中携带的第四对象参数进行参数校验；

若第四对象参数校验通过，则根据查询信息向客户端发送目标元数据表。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，能够基于在线服务提供的RPC接口方法实现元数据表的查找，由此，在兼容多计算引擎的情况下，通过元数据内部的RPC接口调用元数据底层服务以进行持久化操作，从而提升方案的可行性和可操作性。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

处理模块230，还用于当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

处理模块230，还用于当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系；

处理模块230，还用于当接收到第三查询请求时，根据第三查询请求从第三元数据表中确定与元数据表外键对应的元数据表，其中，第三查询请求携带分区标识，分区标识与元数据表外键具有关联关系；

处理模块230，还用于当接收到第四查询请求时，根据第四查询请求从第四元数据表中确定与存储表外键对应的存储描述符，其中，第四查询请求携带分区标识，分区标识与存储表外键具有关联关系；

处理模块230，还用于当接收到第五查询请求时，根据第五查询请求从第五元数据表中确定与存储表外键对应的存储描述符，其中，第五查询请求携带表标识，表标识与存储表外键具有关联关系；

处理模块230，还用于当接收到第六查询请求时，根据第六查询请求从第六元数据表中确定与元数据库外键对应的元数据库，其中，第六查询请求携带函数标识，函数标识与元数据库外键具有关联关系。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，对于Hive类型的数据而言，设计了更精简的通用数据模型，在支持元数据多租户的情况下，进行元数据资源的逻辑划分。通过底层数据模型的设计优化，能够提升元数据管理的性能，加速元数据读写性能，去除数据库的多表依赖，通过逻辑实现依赖关系。此外，基于分布式存储系统，可支持海量元数据的存储和管理。

可选地，在上述图23所对应的实施例的基础上，本申请实施例提供的元数据管理装置20的另一实施例中，

处理模块230，还用于当接收到第一查询请求时，根据第一查询请求从第一元数据表中确定与元数据库外键对应的元数据库，其中，第一查询请求携带表标识，表标识与元数据库外键具有关联关系；

处理模块230，还用于当接收到第二查询请求时，根据第二查询请求从第二元数据表中确定与元数据表外键对应的元数据表，其中，第二查询请求携带字段，字段与元数据表外键具有关联关系。

本申请实施例中，提供了一种元数据管理装置。采用上述装置，对于非Hive类型的数据而言，设计了更精简的通用数据模型，例如，存储系型数据库管理系统中的元数据可采用该数据模型，仅需要关注库、表和字段的元数据即可。在支持元数据多租户的情况下，进行元数据资源的逻辑划分。通过底层数据模型的设计优化，能够提升元数据管理的性能，加速元数据读写性能，去除数据库的多表依赖，通过逻辑实现依赖关系。此外，基于分布式存储系统，可支持海量元数据的存储和管理。

图24是本申请实施例提供的一种计算机设备结构示意图，该计算机设备300可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)322(例如，一个或一个以上处理器)和存储器332，一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储介质330通信，在计算机设备300上执行存储介质330中的一系列指令操作。

计算机设备300还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341，例如Windows Server

上述实施例中由计算机设备所执行的步骤可以基于该图24所示的计算机设备结构。

本申请实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如前述各个实施例描述的方法。

本申请实施例中还提供一种包括程序的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例描述的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。