CN117992553A - 元数据管理方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请涉及数据处理领域，提供了一种元数据管理方法、装置、电子设备及可读存储介质，该方法包括：利用预设采集方法对元数据进行采集，其中预设采集方法包括定时采集方法和实时采集方法；将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，父元模型用于定义所述元数据的第一属性信息，多个二次元模型用于存储所述元数据的第二属性信息；将第一属性信息作为关联工具，利用关联工具建立父元模型与所述多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。本申请实现了元数据的统一管理，解决了元数据查找困难以及元数据指标口径不统一的问题。

Description

元数据管理方法、装置、电子设备及可读存储介质

技术领域

本申请涉及数据管理领域，尤其涉及一种元数据管理方法、装置、电子设备及可读存储介质。

背景技术

元数据(Metadata)是一种关于其他数据的数据，用于描述信息资源或数据等对象。其应用目标包括：识别资源、评估资源、追踪资源在使用过程中的变化、实现对大量网络化数据的高效管理以及实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。

当前，元数据的管理方法主要依赖于业务系统或数据仓库的开发人员在提交正式生产环境上线申请时，提交包含上线内容的相关备注，如物理表、ETL任务等。然而，这种方法使得元数据信息的完整性和有效性很大程度上取决于人工核验。此外，上线后缺乏统一的平台进行检索，导致用户需通过分散的上线文档逐一查找，效率低下且难以评估生产环境元数据的质量。同时，不同部门各自维护元数据文档库，可能导致相同指标在不同部门间存在不同的叫法和口径，从而引发管理层或业务人员在查看指标时产生歧义，甚至做出错误决策。

发明内容

有鉴于此，本申请实施例提供了一种元数据管理方法、装置、电子设备及存储介质，以解决现有技术无法统一管理元数据，导致数据查找困难以及元数据指标口径不统一的问题。

本申请实施例的第一方面，提供了一种元数据管理方法，包括：

利用预设采集方法对元数据进行采集，其中预设采集方法包括定时采集方法和实时采集方法；将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。

本申请实施例的第二方面，提供了一种元数据管理装置，包括：

采集模块，被配置为利用预设采集方法对元数据进行采集，其中预设采集方法包括定时采集方法和实时采集方法；存储模块，被配置为将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，其中父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；关联模块，被配置为将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果是：

利用预设采集方法对元数据进行采集，其中所述预设采集方法包括定时采集方法和实时采集方法；通过将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。本申请提出元数据统一管理方案，解决元数据查找困难和业务元数据指标口径不统一的问题，同时通过集中管理和标准化处理，提高数据一致性和准确性，促进数据的高效利用。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种元数据管理方法的流程示意图；

图2是本申请实施例提供的一种元数据管理装置的结构示意图；

图3是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。需要注意，本申请中提及的“第一”“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本申请中提及的“一个”“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

在数字化时代，企业需了解数据状况、存储位置、负责人、数据价值、生命周期、安全性、隐私保护及数据使用情况等，这需通过元数据管理解决。无效的元数据管理会使数据资产成为企业负担。传统上，元数据是数据描述，可分为技术元数据和业务元数据。技术元数据关注数据系统技术细节，如结构、识别、存储、传输和转换；业务元数据则描述数据业务定义和规则，提供语义层，连接用户和系统，消除数据二义性，支持数据分析和应用。

目前对于元数据管理的方法是基于数据中台来实现的，以哈多普生态为数据中台底座，hive数仓的元数据信息维护在关系型数据库mysql中，包含了数仓的物理表，视图，字段，分区，hdfs文件位置等技术元数据，而ETL任务相关的调度数据，调度频次，创建人，修改人，任务依赖等信息则维护在调度平台和上线文档中。

当用户对一张表增加了某个字段时，需要查找多个文档来判断这张表被哪些ETL任务所使用，再依次修改ETL任务明细，人工成本较高，且容易出错；对于业务系统而言，他们的表和字段不在数据中台中管理，需要自行维护各自系统的元数据文档，容易形成数据孤岛和数据标准不一致的问题。

而对于指标定义等业务元数据管理，现有管理流程是，业务提需求给开发人员，开发人员理解需求并开发指标，填写上线文档，写明指标定义和口径，完成上线评审；指标元数据的维护由开发人员维护在线下文档，容易造成指标定义不清晰，过于技术化的问题，指标文档没有线上化更会产生后续检索困难，难以维护的问题。

基于上述问题，如何提出一种既能统一管理元数据，消除数据标准不一致，又能解决指标口径不统一以及指标重复建设的问题，是当前技术发展中的一个重要问题。

下面将结合附图详细说明根据本申请实施例的一种元数据管理方法、装置、电子设备及可读存储介质。

图1是本申请实施例提供的一种元数据管理方法的流程示意图。如图1所示，该方法包括：

S101，利用预设采集方法对元数据进行采集，其中预设采集方法包括定时采集方法和实时采集方法；

S102，将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；

S103，将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。

首先对本申请实施例在实际应用场景中涉及的一些技术术语进行解释，具体可以包括以下内容：

父元模型：父元模型是元模型中的最高级别，用于定义元数据的第一属性信息。该第一属性信息包含了元数据的核心属性和基本描述。父元模型可以被看作是整个元数据集合的结构框架。在这个框架中，可以定义元数据实体的标识符、名称、类型和其他基本属性等信息。父元模型通常是所有元数据的共同属性和特征的集合。

二次元模型：二次元模型是建立在父元模型之上的，即二次元模型是在父元模型的基础之上做了相应扩展，可以用于存储元数据的第二属性信息。该第二属性信息可以包括更具体和详细的元数据属性、描述、分类等信息。不同的二次元模型可以按照不同的维度或特征对元数据进行分类和组织。例如，在一个数据管理系统中，可以使用不同的二次元模型来存储数据的物理属性、逻辑属性、关系属性等。每个二次元模型可以根据具体的需求和维度定义不同的属性，在此不进行具体限定。

通过将元数据存储在预先构建的父元模型和多个二次元模型中，可以实现对元数据的层次化和结构化管理。父元模型提供了元数据的基本属性和共同特征，而二次元模型则提供了更具体和详细的属性和分类。并且将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，即可以通过第一属性信息来查找建立在该信息基础之上的父元模型和二次元模型，通过这种层次结构，可以更好地组织和管理大量的元数据，并根据不同的维度和需求进行查询、分析和应用。

本申请实施例通过将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。本申请提出元数据统一管理方案，解决元数据查找困难和业务元数据指标口径不统一的问题，同时通过集中管理和标准化处理，提高数据一致性和准确性，促进数据的高效利用。

在一些实施例中，利用预设采集方法对元数据进行采集，包括：对接调度平台并获取用户配置的定时采集数据源；根据定时采集数据源配置采集任务；基于采集任务确定定时采集适配器，其中定时采集适配器用于转换元数据的数据结构；利用定时采集适配器按照预设采集频率对元数据进行定时采集。

具体地，首先，管理平台会与调度平台进行对接，从调度平台中获取用户已经配置好的定时采集数据源。这些数据源可能是各种不同的数据源，例如数据库、应用程序编程接口、文件等。

进一步地，基于用户配置的定时采集数据源，系统会进一步配置相应的采集任务。这些任务会明确如何从数据源中采集数据，例如：确定采集时间、采集频率、采集方式以及数据传输和存储等。

此外，还需说明的是，为了确保采集任务的顺利进行，管理平台还可以提供任务调度和监控功能。任务调度可以根据采集任务的优先级和依赖关系进行智能调度，确保任务的高效执行；监控功能则可以实时监控任务运行状态，及时发现和处理异常情况。

进一步地，在确定采集任务之后可以基于已配置的采集任务来选择或确定一个“定时采集适配器”。该适配器是一个中间件，用于连接不兼容的系统接口或是转换元数据的数据结构。简单地说，就是有些数据源的格式可能与管理平台需要的数据格式不符，所以需要通过这个适配器来进行转换，最后，系统会使用这个定时采集适配器按照预设采集频率(例如每小时、每天、每周等)从数据源中定时采集元数据。

本实施例用一系列措施对元数据进行定时采集，提高了数据采集、处理和应用的效率，同时降低了人工干预的程度，以便于进行后续的元数据管理。

此外，在一些实施例中，利用预设采集方法对元数据进行采集，包括：对接消息队列；响应于元数据提供方发送到消息队列的元数据消息，将消息队列作为实时采集数据源；基于实时采集数据源配置实时采集适配器，其中实时采集适配器用于转换元数据的数据结构；利用实时采集适配器对元数据进行实时采集。

具体地，在进行实时采集时，管理平台可以与消息队列(可以是一个中立的、发布/订阅型的数据传输系统)进行集成或连接。使得该平台能够与消息队列进行交互。当元数据提供方(可以是一个外部系统或服务，可以负责产生或提供元数据消息)向消息队列发送元数据消息时，管理平台能够感知并响应。

需要说明的是元数据提供方可以遵循一个预先定义好的结构或格式，将元数据消息放入消息队列中，确保消息在传输和接收时保持一致，并且可以被正确地解析和处理。

进一步地，管理平台可以将消息队列视为实时数据来源，在基于从消息队列中获取的数据配置一个实时采集适配器。这个适配器主要用于转换元数据的数据结构，利用已配置的实时采集适配器，系统能够实时地采集并处理从消息队列中获取的元数据。

本实施例通过实时采集数据，确保数据的及时性和准确性，使得元数据的变化能够迅速地被捕捉和处理，提高了系统的响应速度和数据质量。此外，通过配置实时采集适配器，可以灵活地转换元数据的数据结构，适应不同的数据处理需求，有助于提高系统的灵活性和可扩展性。同时，使用消息队列作为实时采集数据源，可以有效地解耦元数据提供方和数据处理方，降低系统的复杂性和耦合度，提高系统的可维护性和可扩展性。

另外，在一些实施例中，第一属性信息包括唯一编码；将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系：将唯一编码作为父元模型的外键关联；利用外键关联将父元模型与多个二级元模型进行关联。

具体地，外键关联是一种数据库关系设计中的概念，主要在关系型数据库中使用。外键是一个表中的字段，它的值来自另一个表的主键。外键关联的目的是建立两个表之间的联系，确保数据之间的引用完整性和一致性。

父元模型和多个二次元模型之间通过外键关联进行关联。具体来说，唯一编码被用作关联工具，这个唯一编码同时作为父元模型的外键。这样，父元模型和多个二次元模型通过这个唯一编码进行关联，从而建立起它们之间的关系。

作为一示例，如果父元模型是"订单"，包含一些基本信息，比如订单号、订单日期、客户等。同时，我们有多个二级元模型，比如"订单明细"和"订单状态历史"，分别存储有关订单的明细信息和状态历史。

如果订单号是唯一编码，我们可以利用它作为关联工具来建立父元模型(订单)与多个二级元模型(订单明细和订单状态历史)的关联关系。将订单号作为父元模型(订单)的外键关联。这意味着在订单明细和订单状态历史中，我们将添加一个外键字段来引用父元模型的订单号。

使用外键关联将父元模型(订单)与多个二级元模型(订单明细和订单状态历史)进行关联。即在订单明细和订单状态历史中，通过外键字段与订单的唯一编码(订单号)进行关联，建立起父元模型与多个二级元模型之间的联系。这样的关联关系可以更好地管理和组织数据，以及进行数据的查询和分析。

当查询某个订单的详细信息时，可以通过订单号从订单明细和订单状态历史中找到相关数据，实现数据的关联查询。同时，当有关订单的某些属性发生变化时，可以通过唯一编码作为标识，更新多个二级元模型中与该订单相关的数据，保持数据的一致性。

本实施例通过将唯一编码作为父元模型的外键关联；利用外键关联将父元模型与多个二级元模型进行关联，有助于在数据库中维护数据的完整性和一致性，因为任何对父元模型的修改都可能影响到依赖于此模型的二次元模型。同时，外键关联也有助于提高查询效率，因为可以通过外键快速找到相关联的记录。

在一些实施例中，利用预设关联方法建立多个二级元模型之间的关系类型，包括：获取存储在每个二级元模型中的标识信息，其中标识信息指示包括元数据的目标唯一编码和源唯一编码；基于目标唯一编码和源唯一编码建立二维表，其中二维表用于指示二级元模型之间的关系类型。

具体地，二维表又称为二维数组或表格，由行和列组成，行用于表示数据的记录，列用于表示记录中的不同属性或字段。在二维表中，每行包含一组相关的数据，例如在数据库中，每行代表一个记录，每列代表一个字段。每个单元格表示一条记录在某个字段上的取值。通过使用行和列的组合，可以形成一个二维的数据结构，用于存储和组织大量的数据。

当设计二次元模型与二次元模型之间的关系时，可以通过一个二维表来存储这些关系。这个表可以包括以下列：

目标唯一编码：表示该关系的目标元数据的标识信息。

源唯一编码：表示该关系的源元数据的标识信息。

关系类型：表示目标元数据和源元数据之间的关系类型，例如依赖关系、引用关系等。

在元数据采集时，可以将关系数据传输给适配器。适配器可以解析传入的关系数据，并将其存储到二维表中。这样，当元数据被采集并存储到元模型中时，相应的关系数据也会被自动解析和存储。

此外，还可以提供一个用户界面，允许用户手动建立元数据之间的关系。通过界面操作，用户可以选择目标元数据和源元数据，并指定关系类型，然后将这些关系数据存储到关系表中。

具体实现方法可以使用SQL语句来创建此表，并设置适当的索引和约束。具体实现方法在此不进行具体限定。

本实施例通过从每个二级元模型中提取目标唯一编码和源唯一编码，并基于这些唯一编码建立二维表，用于明确数据之间的关系，可以提高数据处理效率、数据可理解性，有助于维护数据的完整性，为决策制定提供支持。

此外，在一些实施例中，还包括：获取业务需求指标，并基于业务需求指标，确定是否存在开发需求；若存在开发需求，则基于业务需求指标建立新增需求并将新增需求发送至开发人员，其中新增需求包括业务定义和业务口径；响应于开发人员发送的基于新增需求所完成的新增需求，对所完成的新增需求进行需求评审。

具体地，为了解决指标口径不统一和重复性建设的问题。当业务人员需要使用某个指标时，可以将需求指标发送至管理平台，然后由平台查看是否已经存在相同的指标。

如果在管理平台上已经存在相同的指标，可以直接查询该指标的定义和使用方式发送至业务人员进行使用；如果该指标不存在，管理平台可以向开发人员提出开发需求，并在管理平台上新增这个指标。同时还可以需要给出该指标的业务定义和业务口径，明确指标的意义和适用范围。

进一步地，开发人员会根据管理平台提出的需求进行指标的开发。在开发完成后，开发人员会在元数据管理平台上维护该指标的技术口径。包括指标使用的库表字段信息以及加工逻辑，即如何从底层数据计算出这个指标的值。维护完技术口径后，开发人员会提交指标上线评审，确保指标的准确性和有效性。如果评审通过，该指标就存储在管理平台中，以便后续使用。

本实施例通过获取业务需求指标，并基于业务需求指标，确定是否存在开发需求；若存在开发需求，则基于业务需求指标建立新增需求并将新增需求发送至开发人员，其中新增需求包括业务定义和业务口径；响应于开发人员发送的基于新增需求所完成的新增需求，对所完成的新增需求进行需求评审可以确保所有指标的定义和使用都是统一和标准的，实现了业务元数据的管理流程，避免了口径不统一和重复性建设的问题，同时也可以提高指标管理的效率和精度。

另外，在一些实施例中，方法还包括：封装查询服务，并利用查询服务接收订阅消息，其中订阅消息包括订阅方和订阅元数据；当订阅元数据变更时，发送通知消息至订阅方，其中通知消息用于指示订阅元数据的变更信息。

具体地，管理平台可以封装一个查询服务用于执行查询操作，可以数据源检索该管理平台所存储的元数据，及检测存储的元数据的变化情况，具体可以表现为将查询服务封装成一个可供其他应用程序调用的接口或组件。

能够理解的是，订阅消息是指当某个订阅方对特定的订阅元数据感兴趣时发送的消息。订阅元数据是描述订阅方所关注的数据的信息，它可以包括数据的某些属性、条件或其他相关内容。

进一步地，订阅方可以订阅某个订阅元数据，以获取与该元数据相关的变更通知，当订阅元数据发生变更时，通知消息会被发送给订阅方，以指示变更的信息，这样订阅方就可以及时了解到所关注的数据发生了什么变化。

本实施例通过封装查询服务来让订阅方可以通过查询服务来订阅元数据，当这些订阅数据发生改变时，订阅方会收到通知消息，以便及时获取最新的数据信息。及通过提供实时的数据更新和改变的通知机制，使订阅方能够及时了解和响应元数据的变化情况。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不一一赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应该对本申请实施例的过程构成任何限定。

图2是本申请实施例提供的一种元数据管理装置的示意图。如图2所示，该装置包括：

采集模块201，被配置为利用预设采集方法对元数据进行采集，其中预设采集方法包括定时采集方法和实时采集方法；

存储模块202，被配置为将采集到的元数据存储在预先构建的元模型中，其中元模型包括父元模型和多个二次元模型，其中父元模型用于定义元数据的第一属性信息，多个二次元模型用于存储元数据的第二属性信息；

关联模块203，被配置为将第一属性信息作为关联工具，利用关联工具建立父元模型与多个二次元模型的关联关系，并利用预设关联方法建立多个二级元模型之间的关系类型。

在一些实施例中，采集模块201还用于对接调度平台并获取用户配置的定时采集数据源；根据定时采集数据源配置采集任务；基于采集任务确定定时采集适配器，其中定时采集适配器用于转换元数据的数据结构；利用定时采集适配器按照预设采集频率对元数据进行定时采集。

在一些实施例中，采集模块201还用于对接消息队列；响应于元数据提供方发送到消息队列的元数据消息，将消息队列作为实时采集数据源；基于实时采集数据源配置实时采集适配器，其中实时采集适配器用于转换元数据的数据结构；利用实时采集适配器对元数据进行实时采集。

在一些实施例中，第一属性信息包括唯一编码，关联模块203还用于将唯一编码作为父元模型的外键关联；利用外键关联将父元模型与多个二级元模型进行关联。

在一些实施例中，关联模块203还用于获取存储在每个二级元模型中的标识信息，其中标识信息指示包括元数据的目标唯一编码和源唯一编码；基于目标唯一编码和源唯一编码建立二维表，其中二维表用于指示二级元模型之间的关系类型。

在一些实施例中，关联模块203还用于获取业务需求指标，并基于业务需求指标，确定是否存在开发需求；若存在开发需求，则基于业务需求指标建立新增需求并将新增需求发送至开发人员，其中新增需求包括业务定义和业务口径；响应于开发人员发送的基于新增需求所完成的新增需求，对所完成的新增需求进行需求评审。

在一些实施例中，关联模块203还用于封装查询服务，并利用查询服务接收订阅消息，其中订阅消息包括订阅方和订阅元数据；当订阅元数据变更时，发送通知消息至订阅方，其中通知消息用于指示订阅元数据的变更信息。

本申请实施例提供的装置能够实现上述方法实施例的所有方法步骤，并能达到相同的技术效果，在此不再赘述。

图3是本申请实施例提供的电子设备3的示意图。如图3所示，该实施例的电子设备3包括：处理器301、存储器302以及存储在该存储器302中并且可在处理器301上运行的计算机程序303。处理器301执行计算机程序303时实现上述各个方法实施例中的步骤。或者，处理器301执行计算机程序303时实现上述各装置实施例中各模块/单元的功能。

电子设备3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备3可以包括但不仅限于处理器301和存储器302。本领域技术人员可以理解，图3仅仅是电子设备3的示例，并不构成对电子设备3的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器301可以是中央处理单元(Central Processing Unit，CPU)，也可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器302可以是电子设备3的内部存储单元，例如，电子设备3的硬盘或内存。存储器302也可以是电子设备3的外部存储设备，例如，电子设备3上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器302还可以既包括电子设备3的内部存储单元也包括外部存储设备。存储器302用于存储计算机程序以及电子设备所需的其他程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

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

Claims (10)

1.一种元数据管理方法，其特征在于，包括：

利用预设采集方法对元数据进行采集，其中所述预设采集方法包括定时采集方法和实时采集方法；

将采集到的所述元数据存储在预先构建的元模型中，其中所述元模型包括父元模型和多个二次元模型，所述父元模型用于定义所述元数据的第一属性信息，所述多个二次元模型用于存储所述元数据的第二属性信息；

将所述第一属性信息作为关联工具，利用所述关联工具建立所述父元模型与所述多个二次元模型的关联关系，并利用预设关联方法建立所述多个二级元模型之间的关系类型。

2.根据权利要求1所述的方法，其特征在于，所述利用预设采集方法对元数据进行采集，包括：

对接调度平台并获取用户配置的定时采集数据源；

根据所述定时采集数据源配置采集任务；

基于所述采集任务确定定时采集适配器，其中所述定时采集适配器用于转换所述元数据的数据结构；

利用所述定时采集适配器按照预设采集频率对所述元数据进行定时采集。

3.根据权利要求1所述的方法，其特征在于，所述利用预设采集方法对元数据进行采集，包括：

对接消息队列；

响应于元数据提供方发送到所述消息队列的元数据消息，将所述消息队列作为实时采集数据源；

基于所述实时采集数据源配置实时采集适配器，其中所述实时采集适配器用于转换所述元数据的数据结构；

利用所述实时采集适配器对所述元数据进行实时采集。

4.根据权利要求1所述的方法，其特征在于，所述第一属性信息包括唯一编码；

所述将所述第一属性信息作为关联工具，利用所述关联工具建立所述父元模型与所述多个二次元模型的关联关系：

将所述唯一编码作为所述父元模型的外键关联；

利用所述外键关联将所述父元模型与所述多个二级元模型进行关联。

5.根据权利要求1所述的方法，其特征在于，所述利用预设关联方法建立所述多个二级元模型之间的关系类型，包括：

获取存储在每个二级元模型中的标识信息，其中所述标识信息包括元数据的目标唯一编码和源唯一编码；

基于所述目标唯一编码和源唯一编码建立二维表，其中所述二维表用于指示所述二级元模型之间的所述关系类型。

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

获取业务需求指标，并基于所述业务需求指标，确定是否存在开发需求；

若存在开发需求，则基于所述业务需求指标建立新增需求并将所述新增需求发送至开发人员，其中所述新增需求包括业务定义和业务口径；

响应于所述开发人员发送的基于所述新增需求所完成的新增需求，对所完成的新增需求进行需求评审。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

封装查询服务，并利用所述查询服务接收订阅消息，其中所述订阅消息包括订阅方和订阅元数据；

当所述订阅元数据变更时，发送通知消息至所述订阅方，其中所述通知消息用于指示所述订阅元数据的变更信息。

8.一种元数据管理装置，其特征在于，包括：

采集模块，被配置为利用预设采集方法对元数据进行采集，其中所述预设采集方法包括定时采集方法和实时采集方法；

存储模块，被配置为将采集到的所述元数据存储在预先构建的元模型中，其中所述元模型包括父元模型和多个二次元模型，其中所述父元模型用于定义所述元数据的第一属性信息，所述多个二次元模型用于存储所述元数据的第二属性信息；

关联模块，被配置为将所述第一属性信息作为关联工具，利用所述关联工具建立所述父元模型与所述多个二次元模型的关联关系，并利用预设关联方法建立所述多个二级元模型之间的关系类型。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。

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