元模型.数据管理平台的基础.第1部分

管理元模型所需的功能及其设计注意事项

元模型或元数据模型是数据治理（DG）平台的基础组件之一。就像数据模型是应用程序持久化和查询数据的基础一样，元模型支持DG平台的元数据存储/查询。

元模型设计由DG用例及其操作的元数据驱动，如数据模型如何基于应用程序用例。元数据通常分为

• 业务元数据（业务术语、业务流程、度量/KPI等）、
• 与数据资产相关的元数据（数据实体、数据属性、表、列、参考数据（如代码集、代码值））、
• 治理元数据（策略、业务规则、数据质量规则和度量）、
• 技术/技术元数据（服务器、数据库、应用程序、系统）。

元模型设计的两个关键期望是：

• （a）支持来自各种来源的元数据的能力——无论是来自各种平台的数据和技术元数据，还是来自各种流程的业务元数据
• （b）为这些元数据对象提供用户友好的命名法的能力，帮助用户轻松搜索和理解与其来源的平台相关的元数据。

例如，当从Tableau中获取元数据时，将这些命名为“Tableau工作簿”、“Tableau-工作表”等的能力使它们比仅将它们命名为报告或仪表板更有意义和相关性。
在本文的第1部分中，我们将研究DG平台应该提供的各种功能，以管理这些元模型。此外，我还将回顾基于大型DG实现中的经验设计元模型时的一些关键考虑事项。

除了核心元模型设计功能外，不能遗漏一些功能，例如在DG平台中管理元数据的组织，以及通过与相关角色和权限映射的管理工作流管理元数据的生命周期。因此也包括它们。
下面是列表：

内置元数据类型、属性和关系的丰富性-

支持业务、数据、治理和技术元数据类型的DG平台内置的元数据类型的丰富性是元模型设计的一个非常好的起点。与加速数据模型设计的行业数据模型一样，内置元模型指导设置初始元模型。例如，当我们试图定义术语表时，内置的元数据类型（如业务术语或缩写词）指导DG团队定义业务术语需要携带的属性。术语的定义是关键的，并且可能是与同义词业务术语的关系。类似地，在缩写词的情况下，捕获为定义的缩写词的扩展for以及与提供业务定义的业务术语的关系是关键。
这是建立术语表的良好开端。随着用户体验词汇表，可以发展其他属性和关系，并将其包含在元模型中。

考虑事项：考虑到内置元数据可以随着产品/平台的发展而发展，从而增强它们与其他产品功能的良好集成，因此尽可能利用内置元数据是一种良好的做法。然而，如果可用的丰富性是有限的，那么将我们限制在内置不是一个好主意。

定义自定义元数据类型的能力

——这是使DG平台可扩展并满足我上面提到的元模型设计的两个期望的关键能力。元数据源的性质可能会不同，强制将它们安装到某些标准内置资产类型中不是一个好主意。我认为这是DG平台的关键区别之一，因为强制将不同的元数据拟合到同一类型不仅会影响用户体验，而且在根据其表示的内容改变其属性和关系方面也成为一项挑战。例如，Alation as平台提供通用文章元数据/对象类型。如果要定义“Metric”甚至“Application”元数据类型，则必须使用并自定义Article对象来处理Metric和Application。查看度量时，我们需要隐藏应用程序的属性和关系，反之亦然。

注意事项：当我们定义的自定义元数据类型也作为产品功能的一部分发布时，就会出现挑战。我们需要管理这一点，确保在自定义类型和内置类型之间有明确的区别，以便最终用户不会混淆或受到影响。

定义自定义属性和关系的能力——

随着组织在其DG过程中的成熟，捕获的元数据的丰富性也会增加。元数据中捕获的属性和关系越多，其搜索能力和提供所描述资产的更好上下文的能力越好，这是元数据管理的要点。假设您从名为Data Product的元数据类型开始。其目的是描述组织中的实际数据产品。作为一个概念，这仍然在发展，人们正在寻找构建这些产品的最佳方法。从治理的角度来看，我们希望捕获其元数据。所以，我们从这些数据产品中常见的属性和关系的初始列表开始。随着这些对象的成熟，我们看到需要围绕它们捕获更多的元数据特征。此时，定义自定义属性和关系的功能成为关键。我将其与前面的自定义元数据类型区分开来的原因是，一些平台允许定义自定义元数据类型，重用内置属性和关系以及有限的自定义属性/关系。向内置元数据类型和自定义元数据类型添加自定义属性/关系的灵活性很重要。

注意事项：这里再次强调，利用内置是一种良好的实践，除非它是有限的。定义自定义属性/关系时的一个方面是，看看如何将它们定义为足够通用的，以便重用，从而避免此类特征的扩散。

支持简单和复杂关系-

这更多地是Collibra平台使用的术语，但它是元模型设计中存在的强大功能之一。简单关系与两个元数据对象相关，而复杂关系与多个元数据对象有关。将业务术语链接到列以描述列是一种简单的关系，而将数据管道的源和目标与其字段级映射链接是一种复杂的关系。复杂关系有时可以被视为简单关系的组合，但大多数时候，它是第三个上下文中两个对象之间的关系（例如，用于度量的SQL查询不能在没有执行它的系统上下文的情况下独立相关）
注意事项：大多数场景仅保证简单的关系，即使是产品也建议这样做，因为加载内容更容易，用户也更容易理解。然而，复杂的关系场景不能被简单的关系所取代。

支持在关系上定义属性-

作为上述复杂关系功能的扩展，最好定义描述关系的属性。在上面的数据管道示例中，它有助于将实际的转换逻辑捕获为源系统和目标系统之间的字段映射中的属性。这些属性不能作为源系统或目标系统的一部分捕获。它在源和目标字段映射的上下文中。例如，假设POS系统中的Transaction表映射到零售数据集市中的Sales Roll-up表，并在两者之间进行字段映射。对于映射的每个列，我们可以提供转换逻辑。对于transaction_amt to Sales列，我们可以从ePOS捕获 ‘ select sum(e.transaction_amt) from ePOS.Transaction e…’

以定义良好的结构组织元数据的能力—

现在，我们来看一下支持元数据设计的功能，以使基础健壮，从而支持任何数据治理用例。其中一个是分类法，支持如何在平台中组织不同的元数据对象以供用户使用。有两个组织级别（a）基于访问和所有权来组织元数据对象-属于财务功能的度量应该仅由所有用户都可以访问企业级度量的团队访问（b）按元数据类型组织-将业务术语分组为术语表，将数据模型分组为逻辑数据字典，并将模式/表/列分组为物理数据字典下。两者都是在数据治理平台内推动用户体验的关键

注意事项：定义分类与元模型设计一样重要，并且必须与元模型并行/同步完成。定义新的元数据类型时，应该清楚这些类型将位于何处，以及哪些角色将管理这些类型等。

丰富的内置角色和权限—

这是另一个关键功能，用于管理如何允许从平台创建/读取/更新/删除元数据对象。平台中的角色再次存在于两个级别（a）产品模块/功能级别-以管理该模块特定的功能，例如，设置元数据连接器将需要相关角色来设置和管理连接器（b）资源级别，例如在元数据对象级别或管理其中所有元数据的元数据分类文件夹/结构级别。这为角色提供了粒度权限，以对对象执行CRUD操作以及参与其他管理活动。
定义自定义角色和权限的能力-对于大型组织，角色的数量和变化将保证扩展内置角色及其相应权限的能力。

注意事项：通常，作为一种最佳实践，最好创建自定义角色，即使角色的一个权限与内置角色的权限不同。这有助于简化管理。

丰富的内置管理工作流-

管理工作流是实施数据治理策略和标准以及管理DG平台中元数据对象的生命周期的关键。一些平台提供了各种基本功能，例如仅批准对象的创建/更新，而一些平台则超越了使用投票机制支持多步骤批准的范围，为元数据对象分配所有权/角色，触发元数据摄取连接器，甚至通过API与外部系统接口。

构建定制管理工作流的能力-

正如我们上面看到的，内置的功能可以启动DG实现，而随着DG用例的成熟，扩展内置功能的能力成为关键。定制工作流可以帮助我们想象这样的场景：元数据对象的生命周期不仅限于平台内，而且扩展到驱动外部平台中的操作。例如，管理访问（例如表或数据集）的工作流是内置的，它在验证相关标准后将访问分配给特定用户组。然后，假设过程的其余部分是手动的，并且在DG平台之外。现在，定制工作流可以更进一步，在目标平台（如Snowflake）中启动实际的访问供应，或者在ServiceNow中向相关IT团队发出请求。然后，该配置的状态可以反映回DG平台。这就是电源自定义工作流。

注意事项：构建自定义工作流时应牢记DG产品/平台施加的边界，而不是充当循环孔来打破这些边界。例如，DG产品可能是基于云的平台，并承诺不直接访问prem系统上组织的。工作流由于能够进行外部API调用，因此不能违反此边界。

在本文的下一部分（第2部分）中，我们将研究三个领先的DG平台——Collibra、Alation和MS Purview如何支持上述功能。在此之前，渴望听到您对上述主题的想法和经验！