什么是元数据，如何管理和利用元数据？

随着企业信息化建设的不断深入，以及公司数字化型智能转型发展的需要，很多地方都需要做元数据建设与管理。基于元数据可以开展各种各样的应用设计，比如企业级统一标准规范建设实施、统一的数据管理，统一的授权管理，统一的数据质量把控，统一的数据传输与同步迁移，统一的数据服务设计等，高效应对各类风险，推动公司数据治理工作的高质量开展，促进数据挖掘和数据的高价值输出利用。

一、什么是元数据

元数据就是数据的数据，或者是描述数据的数据，元数据的范围一般比较广，包括数据本身（如数据库，元素，模型等）、数据表示的概念（如业务流程，应用系统，软件代码，基础设施等）、数据与概念之间的关系。

二、元数据的价值

元数据用于帮助企业或组织理解管理自身的数据、流程和系统，并评估数据质量；

对数据库和信息系统的理解、管理与使用来说，元数据必不可少;

对组织开展数据管理和利用活动来说，元数据必不可少；

元数据管理是企业获取和管理数据的主要方法；

元数据管理不仅是知识管理面临的一个挑战，也是风险管理的一个必要条件；

企业如果没有元数据，可能无法管理其数据；

元数据驱动的实现是数据驱动得以实现的前提；

元数据是企业数据管理的指南；

元数据是用来创建新数据、了解现有数据、实现系统之间的流转、访问数据和共享数据的基础。

三、元数据的类型有哪些？

一般分为业务、技术和操作元数据。业务元数据关注数据的内容、条件、数据治理相关的详细信息；技术元数据关注数据的技术细节、系统、系统内外的数据流转的过程信息；操作元数据关注处理和访问数据的细节。

四、非结构化数据的元数据有哪些？

什么是非结构化数据？任何不在数据库或数据文件中的数据（包括文档或其他介质）。非结构化数据的元数据更为重要，是理解数据的关键元数据，一般叫做著录项、头尾文件、描述信息等

非结构化数据的元数据包括描述、结构、管理、书目、记录和保存元数据。收集非结构化数据的元数据一般与数据采集流程有关，为了支撑后续的大数据分析、BI等工作。

五、元数据的架构类型有哪些？

元数据管理的解决方案或架构需要解决元数据的采存管集用等元数据的生命周期问题。具体包括采集、存储、集成、交付、使用、控制与管理。

架构类型主要有：集中、分布式、混合式和双向元数据架构，大部分企业采用混合式元数据架构模式。详见下图。

1.集中式元数据架构

集中式元数据架构由单一的元数据存储库组成，该存储库包含来自各种不同源的元数据副本

优点：

因为它独立于源系统，具有高可用性。
因为元数据集中在存储库中，具备快速能力。
解決了数据库结构问题，使其不受第三方或商业系统特有属性的影响。
抽取元数据时可进行转换、自定义或使用其他源系统中的元数据来补充，提高了元数据质量。

缺点：

必须采用复杂流程确保元数据源头中的更改能够快速同步到存储库中。
维护集中式存储库的成本可能很高。
元数据的抽取可能需要自定义模块或中间件。
验证和维护自定义代码会增加对内部IT人员和软件供应商的要求

2.分布式元数据架构

元数据检索引擎通过实时从源系统检索数据来响应用户请求；分布式元数据架构没有持久化的存储库

优点

元数据总是尽可能保持最新且有效，因为它是从其数据源中直接检索的。
查询是分布式的，会提高响应和处理的效率。
来自专有系统的元数据请求仅限于查询处理而不需要详细了解专有数据结构，因此最大限度地减少了实施和维护所需的工作量
自动化元数据查询处理的开发可能更简单，只需要很少的人工干预。
减少了批处理，没有元数据复制或同步过程

缺点

无法支持用户定义或手动插入的元数据项，因为没有存储库可以放置这些添加项.。
需要通过统一的、标准化的展示方式呈现来自不同系统的元数据
查询功能受源系统可用性的影响。
元数据的质量完全取决于源系统

3.混合式元数据架构

混合架构结合了集中式和分布式架构的特性；该模式也是最常采用的元数据管理方案。

4.双向元数据架构

允许元数据在架构的任何部分（源、数据集成、用户界面）中进行更改，然后将变更从存储库（代理）同步到其原始源以实现反馈。

六、元数据架构演变史

1.第一代架构：Monolith 一切

详见下图，通常是一个经典的单体前端（可能是一个 Flask 应用程序），连接到主要存储进行查找（通常是 MySQL/Postgres），一个用于服务搜索查询的搜索索引（通常是 Elasticsearch），并且对于该架构的第 1.5 代，可能是一个图形索引，用于在达到“递归查询”的关系数据库的限制时处理谱系（通常是 Neo4j）的图查询。

2.第二代架构：具备服务 API 的三层应用

详见下图，单体应用程序已拆分为前后端分离的服务。该服务提供了一个 API，允许使用推送机制将元数据写入系统，需要以编程方式读取元数据的程序可以使用此 API 读取元数据。但是，通过此 API 可访问的所有元数据仍存储在单个元数据存储中，该存储可以是单个关系数据库或扩展的键值存储。

3.第三代架构：基于事件的元数据

完整实现详见下图，第二种架构的“中央服务”元数据解决方案难以跟上企业对元数据用例的需求。为了解决这个问题，必须满足两个需求。首先是元数据本身需要是自由流动的、基于事件的、可实时订阅的。第二个是元数据模型必须支持随着新扩展和添加的出现而不断发展——而不会受限于中央团队。这将使元数据始终可以被多种类型的消费者大规模使用和扩展，客户可以根据他们的需要以不同的方式与元数据数据库交互。他们获得基于流的元数据日志（用于摄取和更改消费）、元数据的低延迟查找、对元数据属性进行全文和排名搜索的能力、对元数据关系的图形查询以及全扫描和分析能力。可以在此元数据流之上构建具有不同核心元数据模型扩展的不同用例和应用程序，而不会牺牲一致性或新鲜度。您还可以将此元数据与您的开发工具（例如 git）集成，方法是与代码一起创作和版本化此元数据。元数据的改进和丰富可以通过以低延迟处理元数据更改日志或通过批处理压缩的元数据日志作为数据湖上的表来执行。