实现元数据湖…

在我上一篇关于“为元数据湖构建案例”的博客中，我曾写道，如何从多个平台集成元数据来产生价值，就像数据湖或湖泊之类的数据集成存储所产生的价值一样。

在决定选项之前，让我们列出此元数据存储所需的关键特征：
 

• 存储不同元数据对象类型的灵活性-元模型应该是可定制和可扩展的，以支持各种元数据对象类型。我们正在研究要在这里持久化的各种业务、技术和运营/安全元数据。管理元数据类型或元模型本身与应用程序数据模型或数据仓库的数据模型一样具有挑战性。需要在要标准化的元数据类型和可以为其源平台定制的元数据类型之间保持平衡。例如，我们应该将Power BI、Tableau、Qlik等平台的报告元数据命名为“报告”类型以标准化，还是分别称它们为“报告页面”、“工作表”或“工作表“，以使它们与基于源平台的最终用户相关。
• 扩展元数据对象类型的能力——这是关键，因为组织在平台上以增量方式进入湖泊，我们不能预先预见所有元数据类型。它可以是来自仪表板平台的“故事”元数据、来自数据保护平台的“敏感度标签”或来自数据安全平台的“访问策略”。
• 链接或关联元数据对象类型的能力-这是一个关键特征，将推动“元数据拼接”，这是数据沿袭和相关分析的基础。无论是ETL作业的元数据到其源/目标表结构的元数据之间的链接，还是报告中的度量到底层数据集之间的链路，它们都有助于推动跟踪数据沿袭/来源的数据质量问题的根本原因分析。影响/依赖性分析，即了解如果开发人员更改表结构，什么将中断，也是通过跟踪这些链接来驱动的。另一个有用的功能是通过这些链接传播元数据。如果我知道其中一个源列包含PII数据，则可以将相同的信息传播到数据管道，最后传播到使用它的报表属性，从而根据用户角色对属性进行屏蔽/模糊处理。
• 能够存储对象及其关系的丰富和可扩展属性/属性-这将推动强大的搜索和洞察。用户可以搜索对象属性或关系的属性。例如，您可以查询分配给特定所有者的所有报告（捕获为其属性），或者查询链接到业务单元的所有报告，其中业务单元（表示为另一个元数据对象）被筛选为所需的值。

让我们来看一下解决上述需求所需的三个常见选项——关系数据库（例如：SQL server）、NoSQL文档数据库（例如，MongoDB）、图形数据库（如：Neo4j）。

毫无疑问，“图形数据库”是一个突出的选项。
事实上，两个开源但功能强大的数据治理平台/框架——Apache Atlas和Amundsen——使用基于图的元数据存储库。Apache Atlas是一些流行的商业平台（如Microsoft Purview和Atlan）的基础，而Amundsen是由Lyft engineering构建的，用于内部使用，然后开源。
现在，让我们尝试将集成到湖中的一些元数据元素（如上一篇博客中所讨论的）描述为典型图模型中的对象，并查看它将如何支持一些元数据集成用例。

Partial Graph model depicting the interlinking of metadata objects

在图中，圆或节点表示元数据对象的实例。节点旁边的胶囊指示其对象类型。属性或属性列在节点旁边。这些关系描述为链接节点的箭头。箭头表示关系的性质，其中两个箭头表示它们的属性（例如DQ得分）。

表和列元数据是从数据目录平台接收的。来自数据保护平台的数据分类（数据类）和相关策略（访问策略）。基于数据类及其来自数据质量平台的数据质量分数（DQ分数）生成的应用数据质量规则（DQ规则）。实现的策略（访问策略）来自数据安全/访问管理平台。

利用联系(linkages)的力量，我们能够向下游传播“DQ得分”和“PII标志”（或敏感度标签）。因此，可以基于来源的传播DQ得分来计算消费报告的质量（客户流失分析）。报告中的任何数据问题也可以通过其链接或“世系”追溯到其来源进行分析。

您现在看到了将所有这些元数据对象集成到一个Lake或Repository（“1+1=3”场景）中的威力了吗？让我知道你的想法和类似的经历。