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

语言 Chinese, Simplified

SEO Title

Metamodels — Foundation of Data Governance platforms — Part 1

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

支持业务、数据、治理和技术元数据类型的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平台。这就是电源自定义工作流。