数据治理实践：元数据管理架构的演变.docVIP

数据治理实践：元数据管理架构的演变 前言 近几年来数据的量级在疯狂的增长，由此带来了系列的问题。作为对人工智能团队的数据支撑，我们听到的最多的质疑是 “正确的数据集”，他们需要正确的数据用于他们的分析。我们开始意识到，虽然我们构建了高度可扩展的数据存储，实时计算等等能力，但是我们的团队仍然在浪费时间寻找合适的数据集来进行分析。 也就是我们缺乏对数据资产的管理。事实上，有很多公司都提供了开源的解决方案来解决上述问题，这也就是数据发现与元数据管理工具， 在这篇文章中，我将描述行业迄今为止元数据管理的三代架构， 希望本文能帮助您在选择自己的数据治理解决方案时做出最佳决策。 什么是元数据管理？ 简单地说，元数据管理是为了对数据资产进行有效的组织。它使用元数据来帮助管理他们的数据。它还可以帮助数据专业人员收集、组织、访问和丰富元数据，以支持数据治理。 三十年前，数据资产可能是 Oracle 数据库中的一张表。然而，在现代企业中，我们拥有一系列令人眼花缭乱的不同类型的数据资产。可能是关系数据库或 NoSQL 存储中的表、实时流数据、 AI 系统中的功能、指标平台中的指标，数据可视化工具中的仪表板。 现代元数据管理应包含所有这些类型的数据资产，并使数据工作者能够更高效地使用这些资产完成工作。 所以，元数据管理应具备的功能如下： 搜索和发现：数据表、字段、标签、使用信息 访问控制：访问控制组、用户、策略 数据血缘：管道执行、查询 合规性：数据隐私/合规性注释类型的分类 数据管理：数据源配置、摄取配置、保留配置、数据清除策略 AI 可解释性、再现性：特征定义、模型定义、训练运行执行、问题陈述 数据操作：管道执行、处理的数据分区、数据统计 数据质量：数据质量规则定义、规则执行结果、数据统计 第一代架构 基于抽取的元数据 下图描述了第一代元数据架构。它通常是一个经典的单体前端（可能是一个 Flask 应用程序），连接到主要存储进行查询（通常是 MySQL/Postgres），一个用于提供搜索查询的搜索索引（通常是 Elasticsearch），并且对于这种架构的第 1.5 代，也许一旦达到关系数据库的“递归查询”限制，就使用了处理谱系（通常是 Neo4j）图形查询的图形索引。 元数据通常通过连接到元数据源（如Hive 、Kafka ）使用查询方式摄取，这种方式通常是单个进程（非并行），每天运行一次左右。 该架构的稍微高级的版本还将允许批处理作业（例如，Spark 作业），然后将此元数据加载到存储和索引中。 优点 架构简单，只需一个存储、一个搜索引擎，就可以快速聚合元数据并构建一个应用程序，使数据工作者提高工作效率。 由于架构简单，我们需要的开发人员成本也是很低的。 缺点 抽取元数据的性能压力。什么时候去抽取元数据，跑多久，用多少负载？这些问题估计让运维团队很头疼。随之导致的就是暂停抽取，或者隔几天抽取，元数据也就变得越来越陈旧。 实时性。刚开始的时候，每天跑一次元数据爬取似乎没有问题。但是实时计算的兴起让数据的实时性要求越来越高，这种架构就不再适用了。 Amundsen拥有第一代架构，他侧重在实现搜索排名的功能，这一部分非常的强大。 第二代架构：带有服务 API 的三层应用 很快，我们找到了第二代的架构升级。单体应用程序已拆分为位于元数据存储数据库前面的服务。该服务提供了一个 API，允许使用推送机制将元数据写入系统，需要以编程方式读取元数据的程序可以使用此 API 读取元数据。 优点 提供基于推送的模式，可以立即在元数据生产者和元数据服务之间建立联系。当然还是需要元数据的实时推送， 实时性得以解决。实时的推送让元数据的实时性得到非常大的提高。 缺点 没有日志。当出现问题时，很难可靠地引导（重新创建）或修复您的搜索和图形索引。 第二代元数据系统通常可以成为公司数据资产的可靠搜索和发现门户，它们确实满足了数据工作者的需求，Marquez拥有第二代元数据架构。 第三代架构：基于事件的元数据 第 1 步：面向日志的元数据架构 元数据提供者可以实时推送或基于 API推送元数据变化日志。 日志是元数据领域的中心，如果出现任何不一致，您可以随意引导图形索引或搜索索引，并确定性地修复错误。 第 2 步：面向领域的解耦元数据模型 强类型元数据模型和关系。这种建模使团队能够通过添加特定领域的扩展来改进全局元数据模型。 好处 客户可以根据他们的需要以不同的方式与元数据数据库交互。 元数据的低延迟查找、对元数据属性进行全文和排名搜索的能力、对元数据关系的图形查询以及全扫描和分析能力。 下图显示了该架构的完全实现版本： 缺点 组件分散。运维难度也就成倍的提高。 我们调查过的所有系统中，拥有第三代元数据架构的系统是 Altas 和DataHub。 Apache Atl