笔记-三代元数据目录架构

元数据目录架构发展概述

源头文章：https://engineering.linkedin.com/blog/2020/datahub-popular-metadata-architectures-explained

核心诉求：如何快速并准确地找到分析所需要的数据集？

数据资产在技术上的分类涉及哪些东西？

表格，流，AI features，指标，仪表盘……

一个数据目录常见的需求

• 搜索和发现：数据模式、字段、标签、使用信息
• 访问控制：访问控制组、用户、政策
• 数据流传：管道执行、查询、API日志、API模式
• 合规性：数据隐私/合规性注释类型的分类法
• 数据管理：数据源配置、摄取配置、保留配置、数据清除策略（例如，GDPR的 “被遗忘权”）、数据导出策略（例如，GDPR的 “访问权”)
• AI的可解释性、可重复性：特征定义、模型定义、训练运行执行、问题陈述
• 数据操作：管道执行、处理的数据分区、数据统计
• 数据质量：数据质量规则定义、规则执行结果、数据统计

https://engineering.linkedin.com/blog/2020/datahub-popular-metadata-architectures-explained
这篇文章是数据治理必读文章之一。作者Shirshanka Das是Acryl Data公司的首席执行官和联合创始人。他在LinkedIn工作了近十年，领导其数据平台战略，DataHub是以开发者为主导的现代数据发现(data discovery)、质量和自动治理的方法。

Shirshanka在文中分析了元数据管理发展的三个“世代”。第一代元数据管理主要是通过抓取数据库元数据信息来实现，缺点很明显。元数据抓取本身就会耗费数据库资源，这就好像你在电脑打开进程监控器一样，monitor本身就会占掉你一部分CPU和内存。这也导致了应用方常常不喜欢Data Team做的各种监控，觉得这是应用体验变差的主要症结。

第二代元数据管理从原来抓取变成了push API，这样减少了对原系统的影响，但其元数据信息依旧存在一个单一的元数据store里面。这样的问题是我们依旧无法追踪数据的变化（no ChangLog），当图谱或搜索的索引损坏时，修复的代价高昂。同时push API意味着Data Team要对业务系统开发方进行强有力的管控，这的实际项目运作中是不现实的。

第三代元数据管理彻底转为“面向日志”的元数据架构。要实现这样的前提是，几乎所有的数据源都要通过类似于binlog或者是kafka schema registry的方式来做元数据同步。但好处是显而易见的：

1. 支持可扩展的、强类型的元数据模型和关系，并且由企业协同定义。Data Team能够通过添加领域特定的扩展来独立地发展全局元数据模型，而不会受到应用开发的阻碍。
2. 采用流优先架构，元数据基于事件和实时订阅自由流动。这将允许元数据始终可消费，可扩展。
3. 提供基于流的元数据日志（用于提取和更改消费），支持低延迟的元数据查找，元数据属性全文检索，以及元数据关系图查询，扫描和分析等。这些特点使数据使用方可根据需求以不同方式与元数据交互，而不会牺牲一致性。

第三代元数据管理的一个终极目标可能是将所有的数据都能高效完成“语义映射”，核心理念与领域设计思想同出一辙。只有在一开始应用领域设计，将业务需求通过自然语言来形成软件架构甚至到达代码级别的设计，才有可能让后续的元数据跟业务可以通过基本的语义进行自动关联。