《流式Data Mesh》第五章：联邦计算数据治理-灵析社区

攻城狮无远

第五章：联邦计算数据治理

治理提供了互操作性和控制，使各个领域能够共同合作，同时保护每个领域免受不必要的活动干扰。此外，在流数据网中进行数据治理提供了一种集中分布式的方式来管理领域操作、元数据和服务定义。这就是我们在定义流数据网中的策略和控制时所关注的内容。 在流数据网中，联邦数据治理的任务是创建一个共享数据的领域之间和谐共存的社区，同时保持领域的自治性。

第一章讨论了在流数据网中拥有多个网格（mesh）的概念，这些网格超越了数据范畴。其中之一就是用于流数据治理的网格。这种数据治理网格的概念类似于我们今天在社会中看到的州和联邦政府之间的关系。州或地方政府对特定地区拥有自治权，而联邦政府制定的政策会对州和地方层面的运作产生影响。这种关系的目标是创建和谐的社区。对于流数据网也是如此。我们可以将州和地方政府视为控制数据治理范围仅限于其领域边界的领域，而联邦计算数据治理则类似于联邦政府，强制执行旨在保持领域之间和谐的政策。 联邦计算数据治理中的"计算"意味着支持数据治理的规则和政策是以自助服务或自动化的方式实现的。

自助服务和自动化以代码的形式编写，并由支持网格的工程师构建，我们称之为集中化工程师或集中化团队。 在本章中，我们将概述数据治理的重要原则，并确定在流数据网中管理这些原则的权威所有权。我们还将涵盖与流数据网相关的数据治理的计算方面。

在本章中，我们将介绍一些数据治理的基础知识，并将其应用于流数据治理。然后我们将讨论元数据流数据产品的重要性以及其应包含的内容。我们将介绍一些简化元数据管理的工具，这些工具可以包括在流数据网中。最后，我们将介绍有助于数据治理的角色。

流数据网格中的数据治理

数据治理是一套政策、标准、流程、角色和责任，共同确保企业对数据的问责和拥有权。政策是企业本身或者更重要的是外部法律定义的围绕数据的规则和规定，如果违反这些规定，企业可能面临巨额罚款。这些政策还包括对标准的执行，以实现不同领域之间数据的互操作性和可用性，尤其是在像流数据网格这样的分散式数据平台中。这些政策通过授权、认证和保护私密或个人数据的方式来实施流程和数据控制。政策使用代表组、人员或系统的角色来创建围绕数据的访问控制。

数据血缘图

数据血缘图是将所有数据治理信息（政策、标准、流程和角色）聚合在一起的图形化工具。数据血缘提供了数据的完整历史：起源、转换、增强、进行转换的用户等。数据的使用者需要相信他们使用的数据是正确的数据。数据血缘提供了一种能够建立信任的视角。它通过绘制涉及数据的采集、转换、增强和清理的政策、标准、流程、角色和责任的步骤来实现这一目标。

在图5-1中，数据治理政策清晰地标识为“GDPR过滤”和“标准化清洗”。血缘图中的批注还分别标识了领域和发布、组装数据产品的工程师。

在流数据网格中的数据治理应满足以下要求： 在数据流动时，领域需要格外小心，确保受保护的数据不会违反可能会导致巨额罚款和损害客户信任的法规。领域需要确定影响流数据产品的法规，并提供领域工具，以便轻松保护受保护的数据。

  • 由于领域之间将共享数据，因此需要一套促进互操作性的标准。为实现这一点，需要一种使用模式定义数据模型的方式，以便领域可以轻松地编写和使用这些标准。
  • 在流数据网格中，定义角色或用户组对于保护受保护的数据至关重要。例如，一个整个领域可以属于一个用户组。这将使流数据产品所有者更容易地授予或撤销对其领域数据的访问权限。
  • 构建流数据产品的领域工程师需要简单的方法来混淆受保护的数据。例如，他们需要简单的工具，在数据离开领域之前对其进行加密。相应地，使用数据的领域需要一种解密相同数据的方法。类似地，领域工程师需要一种对数据进行标记化/去标记化的能力。
  • 领域工程师需要一种简单的方法来构建跨多个领域的数据血缘。他们需要保留与标准化和安全性相关的详细源信息和转换信息。

流数据网格中的数据治理需要数据监管责任，这与数据产品所有者提供的责任基本相同。数据产品所有者对领域内的数据产品以及其元数据的质量、可访问性和安全性负有责任。这创建了消费者所依赖的高度透明性，并且是一个良好的流数据产品的一部分。

流数据目录以组织数据产品

流数据目录是一种应用程序，用于在企业中组织和管理数据及其元数据的清单，以实现其发现和治理。这适用于流数据产品，并为领域提供一个一站式的平台，用于在流数据网格中搜索和订阅流数据。它提供描述数据如何准备、格式化、起源以及其执行的安全性和法规的所有元数据。在流数据网格中，流数据目录应向用户展示的不仅仅是数据本身，还包括数据产品的可扩展性限制（计算限制等）。

在接下来的章节中，我们将讨论构成发布的流数据产品元数据的组件。我们将讨论如何捕获这些数据，以防止丢失。最终，我们将将所有这些组件编制成一个联合模型，以便在流数据网格中共享这些元数据。

元数据

元数据通常是一个涵盖多个不同用法的术语。在数据平台的背景下，元数据通常被定义为包含以下信息的数据：

  • 表定义、列名、描述和关系
  • 数据资产的验证规则
  • 数据类型
  • 数据所有者
  • 包括源和应用的转换的血缘信息

流数据产品附带的元数据应该提供足够的信息，使领域能够了解数据的来源、组装方式以及安全性。我们可以用一个比喻来更清楚地解释：数据产品就像杂货店里的产品。在购物时，我们希望确保产品来自值得信赖的制造商，并包含符合我们消费需求的成分。我们还确信该产品在安全和可信赖的地方制造，包装方式确保产品没有被篡改，且产品的保质期尚未过期。关于数据产品的元数据也是如此。

了解对流数据产品所做的处理可以展现透明度和信任。许多企业环境通常存在多个“副本”数据，这些数据通常具有相似的内容，由完全不同的团队维护。这往往导致部门报告之间存在差异，因为真正的单一数据源，即使存在，也不为所有团队所理解或利用。数据产品通过创建一个企业内部和超企业信息的单一来源解决了这个问题——一个具有共同内容和更重要的共同元数据的受管控数据源。

当元数据得到维护和发布时，企业内部的用户能够为其使用找到合适的数据源，了解数据的描述信息，解释可能发生的任何转换，并通过了解适当的数据类型来正确使用数据。如果数据的定义存在问题，用户可以提请产品所有者注意，并在迭代周期或功能请求中进行内容更正，以避免数据碎片化和工作重复。

元数据与逐渐变化的维度数据并无不同，应予以相同对待。在流数据网格中，元数据必须作为一个数据产品本身进行发布。其定义必须可被数据产品的用户全局消费，同时也可被其他数据产品在数据丰富和增强中利用其他数据产品。随着元数据的变化，其影响必须实时可用，以确保所有数据产品保持同步。因此，在一个领域中暴露所有数据产品的元数据的流数据产品是必需的。这个要求可以利用构建流数据网格的相同流技术来实现。

在本节中，我们将讨论四个元数据类别：模式、血缘、安全性和可扩展性。这四个类别提供了足够的元数据，使我们的流数据产品能够获得领域消费者的信任。

模式（schema)

在第3章中，我们介绍了领域驱动设计，并强调了它能够帮助业务专家和工程师构建领域模型的能力。这些模型自然地帮助揭示出在一个领域内成为数据产品的实体。这些领域实体和事件是通过模式进行定义的，这些模式成为了关于数据结构和安全性的规则的基础。这些规则最终成为了数据治理的业务驱动策略。

假设在领域驱动设计阶段定义了一个名为Employee的实体（参见图5-2）。为了简单起见，我们只关心以下属性：ID、社会安全号码(SSN)、名字、姓氏和地址。

Example 5-1将是对应的JSON模式，用于编码可以由工具和应用程序处理的实体。

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "$id": "https://example.com/product.schema.json",
    "title": "Employee",
    "description": "An employee in your company",
    "type": "object",
    "properties": {
        "empid": {
            "description": "Identifier that is not a SSN",
            "type": "integer"
        },
        "SSN": {
            "description": "SSN",
            "type": "string"
        }
        ,
        "fname": {
            "description": "First name",
            "type": "string"
        },
        "lname": {
            "description": "Last name",
            "type": "string"
        },
        "address": {
            "description": "Address",
            "type": "string"
        }
    },
    "required": [
        "empid", "SSN", "fname", "lname", "address"
    ]
}

血缘

数据血缘是数据从源头起始处经过的路径，途中的停留点以及其最终目的地。这包括数据通过的所有系统、数据的清洗过程、数据的增强方式以及数据的安全性信息。捕获所有这些元数据是困难的，因为其中许多系统和应用程序不共享信息。您需要通过从所有这些系统/应用程序中提取元数据并组装它们，以找到数据从当前位置（目的地）到源系统的路径。对于流式或批处理数据管道来说，血缘可能是最难获取的元数据。

OpenLineage是一个开源的血缘平台，用于跟踪有关ETL应用程序的元数据。它为领域提供了一种无需组装大量元数据就能构建血缘的方式。它具有用于应用程序提交开始和结束ETL作业的REST、Java和Python API。它是一种在单个应用程序中收集、聚合和可视化数据管道的方式。

OpenLineage使用一个名为Marquez的工具作为其用户界面和血缘存储库，如图5-3所示。同时请注意，OpenLineage最适合批处理过程，但您可以定义可以作为流式ETL作业的运行。

您可以在流式数据管道的每个步骤中调用OpenLineage API，以将血缘信息添加到流式ETL血缘中，一直到消费领域。在图5-4中，您可以看到随着流式数据管道添加了更多组件，血缘图开始构建的情况。

在调用OpenLineage API时，请确保提供足够的元数据，以便领域能够全面了解数据在流式处理过程中的转换和增强方式。例如：

  • 提供足够的信息，以便领域能够完全识别流式数据产品的来源系统，包括使用或创建数据的所有相关应用程序。
  • 识别被标记化或加密的字段，并确定如何推导或查找原始值。
  • 识别被过滤掉的字段，并说明过滤的原因。
  • 包括来自其他领域的其他流式数据产品的信息，这些产品被用作派生产品，以便OpenLineage可以构建超出领域范围的完整血缘图。
  • 在流式处理管道的每个步骤中，提供相关的模式(schema)，以及它如何对数据进行增强或转换。
  • 如果可能，为每个步骤提供联系人，以便消费领域可以查询实现或问题的相关信息。

在本书的GitHub存储库中，您将能够使用Docker运行OpenLineage，并使用存储库中提供的示例构建自己的血缘图。

不幸的是，大多数流处理引擎不支持OpenLineage集成。在这些情况下，您需要在CI/CD过程中调用OpenLineage API来发送START和COMPLETE事件。这将构建血缘图和页面，可以从AsyncAPI生成的流式数据产品页面中引用。关于如何从AsyncAPI生成数据产品页面的内容，我们将在后续章节中介绍。

安全

安全信息通常在元数据中不足或甚至被省略。许多企业具有全球业务，将数据在全球范围内传输最终将受到诸如GDPR等数据隐私法规的约束。同样，如果数据与医疗保健有关，则受到HIPAA规定的法规约束。提供有关流式数据产品如何处理法规的信息非常重要，以便领域可以保持合规性。

例如，在接受审计时，领域必须知道哪些字段被视为私密字段，该过程在哪里运行以保护该私密数据，并且是如何实施的。这些信息可以很容易地在血缘图中提供。审计员可以遍历图形以查看数据的来源和如何保护数据。当企业在全球区域拥有多个领域时，这一点尤为重要。应该有证据表明我们通过领域实践了可传递的数据保护和权限。

对数据访问的信息也很重要。某些领域不应该有私密数据。血缘图应显示私密数据被过滤掉的情况，而其他具有访问权限的领域应该有一种方法来获取私密数据，因为它不应该在未受保护的情况下传输。

基于角色的访问控制（RBAC）是一种限制对数据访问的模型。同样，基于属性的访问控制（ABAC）在字段级别限制访问。RBAC和ABAC使得组织对数据的可访问性更易于理解和实施。元数据中的访问角色提供了更高的可信度。大多数流式处理平台都具有一定级别的访问控制，并提供用于查询已定义的访问规则的API。

描述流式数据产品的不同系统中的所有元数据创建了我们在前几章中提到的数据治理的“网格”。来自这个数据治理工具网格的元数据需要被汇总到一个单一的视图中，供领域查看。在下一节中，我们将介绍如何聚合这些元数据，并构建一个流式数据产品视图，以部署到流式数据目录中。

可扩展性

可扩展性不仅仅提供有关流数据产品本身的元数据是不够的，还需要提供关于它的服务方式和所提供的保证的元数据。 在第4章中，我们强调在数据派生品摄取时需要早期考虑可扩展性。这种可扩展性会传递到最终的流数据产品中。保留这些信息可以让数据消费者对数据产品的可扩展性有良好的理解。

元数据应包括吞吐量（以兆字节每秒（MBps）计）和分区数量等信息。 您还应提供有关使用统计的元数据。域消费者可以了解有多少现有消费者正在读取数据产品。他们将能够确定数据产品是否已达到最大服务能力，并确定是否需要向数据产品所有者请求更多数据。他们还可以了解过去一年发生了多少次停机，以了解其正常运行时间的保证。 所有这四个类别的元数据都应该与流数据产品一起提供。

在第4章中，我们使用了AsyncAPI中的标签来帮助用户提供有关流数据产品的更多元数据。接下来，我们将生成一个数据目录页面，描述流数据产品并提供链接到附加元数据的页面。

从AsyncAPI生成数据产品页面

在第4章中，我们生成了一个AsyncAPI YAML文档，用于定义流数据产品。由于AsyncAPI可以扩展，我们为数据产品积累的所有元数据可以用于填充或在AsyncAPI中引用。

在本节中，我们将展示如何使用AsyncAPI YAML文档生成一个HTML页面，并填充它以展示域所希望了解的有关数据产品的信息。 在本书的GitHub存储库中，我们提供了示例供您克隆，参考示例5-2。

git clone https://github.com/hdulay/streaming-data-mesh.git

命令的输出结果如图5-5所示。该页面包含了在AsyncAPI YAML中输入的所有流数据产品。此HTML页面可以用于发布到流数据目录中。或者，目录可以使用AsyncAPI插件从AsyncAPI YAML文档动态生成HTML页面。

在图5-5中，我们添加了三个按钮，展示了如何将流数据网格工作流嵌入到HTML中。流数据网格工作流定义了用户如何请求访问并最终开始使用流数据产品。请注意，您完全可以控制生成此HTML文档的方式，并且可以符合满足您业务需求的工作流程。数据产品的消费者可以点击"请求访问"按钮来请求访问数据产品。"创建连接器"和"创建Spring客户端"按钮是数据产品的消费者在请求被批准后订阅流数据产品并将其拉入其域中的方式。有关流数据网格工作流的建议将在"访问工作流"中介绍。

截至本书撰写时，没有开源的数据目录可以使用AsyncAPI作为发布流数据产品的方式。许多公司都构建了自己的数据目录，可以支持流数据产品。或者，由于AsyncAPI是对定义同步RESTful API的规范OpenAPI的扩展，我们可以使用现有的OpenAPI注册表（如Apicurio）来发布我们的流数据产品。

Apicurio注册

Apicurio是一个开源的注册表，用于存储文件。它通过REST API提供向存储中添加、更新和删除这些文件的功能。它支持的文件类型包括OpenAPI、AsyncAPI、GraphQL、Apache Avro、Google Protocol Buffers、JSON Schema、Kafka Connect schema、WSDL和XML Schema（XSD）。

Apicurio还可以用作模式注册表，在本章后面我们将更详细地介绍它。目前，我们将使用它来注册我们的AsyncAPI YAML文档，作为发布流数据产品的一种方式。在GitHub存储库中，我们使用Docker来运行Apicurio并注册我们的AsyncAPI YAML文档。图5-6显示了在加载AsyncAPI后Apicurio中的页面。

在Apicurio中，域可以通过名称、组、描述、标签、全局ID和内容ID来搜索数据产品。然后，他们可以使用在“内容”下找到的电子邮件联系该域。

访问工作流

图5-5是由一个AsyncAPI HTML生成器生成的，它在页面上添加了三个按钮：请求访问、创建连接器和创建Spring客户端。它们暗示了一个可能的工作流程，其中用户请求访问权限，数据产品所有者授予访问权限并发送访问凭证，然后用户可以使用这些凭证通过连接器或Spring客户端将数据消费到他们的领域中（参见图5-7）。企业可以添加额外的工作流程步骤，以满足其数据治理要求。

组织任务，如授予访问请求，可能会令人困惑。在下一节中，我们将尝试解决这个问题。

集中化与分散化

角色和任务需要被指定为联邦（集中化）或领域（分散化）。有些任务和角色很容易分配，但其他任务可能会同时涉及集中化和分散化团队。在本节中，我们将尝试提供一些区分。

集中化的工程师团队

集中化的工程师专注于构建域使用的自助服务，用于构建和发布流式数据产品。 这些集中化的工程师还负责维护和管理所有域及其流式数据产品的元数据和安全性。 这些元数据包括以下内容：

流式数据目录

注册所有流式数据产品的位置，域可以在其中进行搜索。

模式注册表

域注册其模式的位置，但模式演化由集中化团队控制。

OpenLineage

可以集中地组装完整的血统图，允许在不同域之间进行链接。当域构建从其他域的流式数据产品派生的流式数据产品时，这一点非常关键。

安全任务包括：

  • 集成对流式数据网格进行用户身份验证的系统，例如轻量级目录访问协议（LDAP）和单点登录（SSO）。
  • 启用域之间的加密连接。

分散化（域）工程师

分散化（域）工程师是指域内的应用工程师，他们通常对数据工程知之甚少或毫无了解。他们需要工具来获取、构建和发布流式数据产品，而无需太多编码工作。低代码和简单配置是这些工程师的期望，这样他们就可以更多地专注于支持业务的应用程序。

这些工程师应该对自己的域模型有足够的了解，以了解什么样的流式数据产品更好。他们定义代表其数据的模式（schemas）。但是，他们并不完全控制模式的演化方式。模式的演化应由由中央团队管理的模式注册表控制。模式注册表将强制域演化其模式，以确保与已经使用其流式数据产品的域兼容，而不会产生破坏性的变化。

域工程师还控制对其流式数据产品的授权（或访问）。他们需要了解将其数据提供给其他域是否会违反诸如GDPR或HIPAA之类的法规。他们需要拒绝不应订阅其数据的域的访问请求，或者提供经过过滤、标记化或加密的数据。授权对于流式数据产品应该已经内建在流式平台中，并通常以访问控制列表（ACLs）或基于角色的访问控制（rRBACs）的形式实现。

域工程师应该具备所有必要的工具和服务，以便能够执行所有这些任务。

总结

在本章中，我们提到目前没有一个数据目录可以按照我们定义的访问工作流程进行操作。作为替代方案，您可以尝试扩展现有的流式数据目录以支持访问工作流程。否则，您需要从头开始构建一个支持访问工作流程的数据目录，并满足以下要求：

  • 支持不同角色的视图：数据产品工程师、数据产品所有者、数据产品消费者。
  • 能够在域注册新的或更新的流式数据产品时使用 AsyncAPI YAML 文档。
  • 支持对流式数据产品的访问工作流程请求。

阅读量：1437

点赞量：0

收藏量:0