数据连接与集成构建管道Best practices推荐的项目和团队结构

注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。

推荐的项目和团队结构

本页面概述了在 Foundry 中使用项目构建数据管道的推荐方式，以实现：

管道中良好的权限结构
不同角色之间的有效协作
清晰且易于维护的管道结构

此外，我们还介绍了在生产环境中成功管理管道所需的角色和职责。

这提供了各个管道阶段的概念性概述，以及每个阶段的作用。有关如何在 Foundry 中设置此结构的分步指南，请参考平台安全文档中的保护数据基础。

管道阶段

这些阶段定义了构成有序管道的项目的逻辑分离。我们将在下面更详细地介绍每个阶段。

数据连接：将原始数据从源系统同步到 数据源项目。
数据源项目：每个逻辑数据源对应一个 数据源项目，定义每个原始数据集的基本清理步骤并应用一致的模式。
变换项目：从一个或多个 数据源项目中导入数据集并进行变换以生成规范、可重用的数据集。
Ontology 项目：从一个或多个 变换项目中导入数据集并进行变换，以生成表示离散操作对象的规范表。单个 Ontology 项目通常会将相关的对象集组合在一起，以便于管理。
工作流项目：工作流项目从 Ontology 项目中导入数据以追求特定结果。通常这是一个操作工作流、数据科学调查、商业智能分析和报告或应用程序开发项目。

pipeline-overview

每个管道阶段都是一个独立的单元，输出的数据集可供下游项目导入并用于其他应用案例、管道开发、分析等。在每个项目中，负责的团队除了实施变换步骤外，还应该管理其输出的稳定性和完整性。这涉及到管理搭建计划、配置和监控数据健康检查，以及在相关情况下编写单元测试或其他数据完整性测试。

以下部分将详细介绍每种下游项目类型，以便遵循管道中的数据流。在设计管道的过程中，建议从 Ontology 层开始反向推导，以确定需要连接的源系统和需要实现的管道变换。

项目在 Foundry 中提供了一种组织数据和代码的方式。它们是管理个人和团队在特定工作范围内协作时的访问和权限的主要单位。此外，项目还提供功能来捕获和共享元数据，例如项目活动的事件日志、项目文档的空间以及项目资源消耗和计算指标。

当考虑什么构成一个好的项目时，可以类比什么构成一个好的微服务：明确的目的、清晰的输出数据集/API 供下游依赖使用、由足够小的人员集体拥有，以便他们能够有效地进行协调并为项目管理设定自己的标准。

在决定是创建一个新项目还是在现有项目中搭建时，请考虑：

项目应与代码库保持1:1的关系。更大的范围可以实现更深入的协作，但会引入更具挑战性的操作需求以确保无缝版本控制。
项目是您希望对所有相关资源强加文件结构和权限的级别。如果单个概念“项目”有需要单独权限的子组件，请考虑在 Foundry 中创建多个项目。

1. 数据连接

在 Foundry 中流经管道的数据通常来自外部源系统。数据连接服务提供了一个管理界面，用于注册源系统。对于每个源系统，配置一个或多个独立同步以将数据落地到数据源项目中的原始数据集中。

为了配置源系统或同步，通常需要代理管理员配置数据连接代理。每个代理应存储在仅代理管理员可访问的专用项目中。

管理新数据源的连接是一个多学科的工作，需要数据源所有者、代理管理员和数据源开发人员的协作，尽管通常需要合规/法律官员批准将数据从源系统移出到新环境中。

一旦配置了源系统，数据源开发人员就可以独立工作来配置单个同步。这大大减少了团队之间的往返，确保连接新系统的工作量低且一次性。

每个连接的一个关键考虑因素是选择SNAPSHOT（每次同步时替换当前数据）和APPEND（每次同步时累加到现有数据）之间的选择。要更全面地了解这些概念以及在增量管道部分中创建高效、性能良好的管道的影响。

进一步阅读

有关数据源和同步的原则、架构和配置的更多信息，请访问数据连接文档。

有关监控连接并确保流入管道的数据准确且符合预期的更多想法，请查看维护管道部分。

2. 数据源项目

每个源系统应在平台内的匹配项目中落地数据。通常的模式是尽可能以“原始”格式落地每个同步的数据。在项目_代码库_中定义为“干净”数据集的变换步骤。

pipeline_datasource

建立这种每个数据源一个项目的模型有许多便利的好处：

鼓励在一致位置探索新数据源。
提供一个单一位置来指定数据源的访问控制。
最小化不同团队同步相同数据的重复工作。
代码库规模小且专门用于处理源系统数据的类型和格式。
在管道层访问数据之前，允许数据匿名化、清理和标准化。

数据源项目目标

在每个数据源项目中，目标是为组织中的广泛用户、应用案例和管道准备同步的数据进行消费。

输出数据集及其模式应被视为 API，即目标是使其在逻辑上有序并随时间保持稳定，因为数据源项目的输出数据集是所有下游工作的基础。输出应与源表或文件 1:1 映射；数据集中的每一行应与源系统中的一行直接匹配。

为此，原始 → 干净变换的一些典型目标包括：

施加一致的列命名方案。
确保适当的类型应用于列。
处理缺失、格式错误或类型错误的值。
建立主要数据健康检查。
删除不适合一般消费的个人身份信息 (PII) 或其他敏感数据。

即使源系统提供列数据类型信息，有时也需要以 字符串 类型引入值。特别注意 日期、日期时间 和 时间戳 类型，这些类型在源系统中通常以非标准格式表示，数字类型有时也会出现问题。如果这些类型在格式上确实不可靠，从源系统导入为 字符串 类型提供了实施更稳健解析和定义处理格式错误值或删除不可用或重复行的逻辑的选项。

除了这些程序步骤，干净的数据集应严谨地记录。数据集的定性描述、源系统来源、适当的联系人和管理协议以及相关情况下的列元数据描述数据特征将确保未来的开发人员适当地使用数据。

实施数据源项目

系统管理员为目标数据源创建一个新项目，并将适当的数据源开发人员添加到新的用户组以管理项目。
- 只有特定数据源的数据源开发人员组的成员应有权限在项目中搭建数据集。
数据源所有者和代理管理员协作在源系统上部署数据连接代理并在 UI 中配置数据源连接。
- 确保配置适当的权限，以便数据源开发人员能够预览源系统中的表和文件。
数据源开发人员为项目中的一个或多个原始数据集配置同步，考虑正确的同步节奏和同步类型，并为每个原始数据集添加适当的数据健康检查。
数据源开发人员实施清理变换以生成“干净”数据集，以便在其他项目中使用。
下游开发人员通过为项目或特定干净数据集提交问题来请求源系统中的新数据集、增强干净数据集或数据质量问题。

虽然每个数据源都有其独特性，但清理和准备源系统的步骤通常有共同步骤，例如解析原始字符串值为给定类型和处理错误。当数据源具有许多类似的清理变换时，最佳实践是用Python定义一个库，以提供一组一致的工具并减少重复代码。

3. 变换项目

变换项目的目标是封装共享的、语义上有意义的数据分组，并生成规范视图以馈送到 Ontology 层。

这些项目从一个或多个数据源项目中导入清理后的数据集，并与查找数据集合并以扩展值，规范化或去规范化关系以创建对象中心或时间中心的数据集，或聚合数据以创建标准的共享指标。

4. Ontology 项目

Ontology 在 Foundry 中实施共享的沟通层——有时称为“语义层”——并且清理、组织和稳定 Ontology 的策划是确保多种有价值的项目能够同时推进并丰富共同操作视图的最高目标。有关设计和管理 Ontology 的概念和实际操作的更多信息，请参考Ontology 概念文档。

Ontology 项目是任何管道的中心点，代表了生成符合 Ontology 中定义的单个或相关对象组定义的数据集所需的最终变换。这些项目还（单独地）生成同步以支持对象浏览器视图的数据集。

由于 Ontology 数据集代表了它们所代表的操作对象的规范真相，因此它们是所有“消费”项目的起始点。虽然上游清理和管道步骤的来源和变换逻辑是可见的，但概念上这些步骤和中间数据集对于仅从 Ontology 项目消费数据的项目开发人员、分析师、数据科学家和操作用户来说可能是一个黑箱。在这个意义上，Ontology 层充当了操作对象的 API。

实施 Ontology 项目

与数据源项目类似，维护 Ontology 项目的关键因素包括：

稳健的文档
有意义的健康检查
定期计划
在数据目录中的策划和适当的标签

这些将在维护管道中以及下面关于记录项目的提示中更详细地讨论。

此外，随着 Ontology 变得更稳健，并且更多团队为 Ontology 层做出贡献，维护数据集“API”的完整性变得更加关键。为此，请考虑实施额外的检查，以确保建议的更改保留输出数据集模式的完整性。这将在即将提供的额外文档中更详细地讨论。

5. 工作流项目

工作流项目，也称为应用案例项目，应根据具体情况灵活设计，但通常围绕单个项目或团队构建，以成为有效的协作单位，并划定责任和访问的边界。

一般而言，工作流项目应引用 Ontology 项目的数据，以确保操作工作流、商业智能分析和应用程序项目共享世界的共同视图。如果在开发工作流项目的过程中，Ontology 层中可用的数据源不足以作为来源，则表明应丰富和扩展 Ontology。避免引用管道中较早（或较晚）的数据，因为这可能会导致特定数据类型的真相源分裂。

记录项目

每个项目应在开发过程中彻底记录。以下是一些常见模式和最佳实践：

在每个项目的根目录保存一个或多个数据沿袭图资源，以捕捉最重要的数据集和管道关系。不同的图可以使用不同的配色方案来突出相关特征，例如数据刷新规律性、相关数据集的分组或数据集特征（如大小）。
向项目添加简短描述——直接位于项目标题下方。这将在所有项目的列表视图中使用。重点是为可能不熟悉项目的用户提供背景。
使用顶级项目文件夹右侧边栏中的添加文档按钮编写Markdown ↗语法。这是解释项目目的、主要输出以及项目消费者的其他相关信息的最佳位置。
将进一步的全局项目文档放在本地创建并上传到文档文件夹中的 Markdown (.md) 文件中，或在Notepad中，并从顶级文档中链接到这些文件。
在项目的代码库中添加 README.md 文件，并确保每个变换文件都有描述和额外的行内代码注释。

管道管理角色

以下角色是 Foundry 中管道范围、设计、实施和管理中常见的角色示例。并非所有情况下都需要这些角色，尤其是在平台开发的早期阶段，个人可能同时担任多个角色。然而，通常考虑这些角色描述及其交互方式将有助于创建有序且有效的团队。

下图将主要角色与它们最常活跃的管道部分相关联。

pipeline_roles

主要角色

代理管理员： 代理管理员负责创建和配置数据连接_代理_并与相关的数据源所有者共享。这样可以集中代理安装和配置的控制，以提高安全性和控制力。
数据源开发人员： 数据源开发人员是负责为数据湖的每个相关数据源获取数据的工程师。这可以作为一个团队来完成，也可以根据源系统进行分解。
- 每个数据源开发人员拥有（1）一个具有技术连接的数据连接数据源和（2）一个 Foundry 项目，用于同步数据的来源。
- 数据源项目的输出是一个清理和准备好的数据集，供一个或多个下游应用案例项目消费。数据源开发人员还定义他们拥有的每个数据源的刷新频率，并与发布经理或操作经理合作安排_管道搭建策略_。
数据管道开发人员： 数据管道开发人员是负责构建公共 Ontology 层的数据工程师，提供所有应用案例使用的数据资产。数据管道开发人员负责定义此语义层并构建从源结构到 Ontology 结构所需的变换。
发布经理： 发布经理拥有生产管道并管理发布过程，以确保生产管道符合组织的标准并可靠地执行。
- 对于管道的代码更改，这通常通过批准对主分支的拉取请求和批准在主分支上运行管道搭建来完成。为了持续可靠，发布经理监控与管道和数据源开发人员一起定义的关键数据集的_健康检查_。
合规官员 / 法律官员： 合规官员负责在开发应用案例之前批准其使用。此类批准应考虑：（1）需要使用的数据，（2）项目的目的，以及（3）用户在其司法管辖区的数据保护制度和组织自己的政策下对数据的访问。
应用案例开发人员： 应用案例开发人员是拥有应用案例开发的软件开发人员和/或数据科学家。他们使用从 Ontology 层获取的数据，并由合规官员批准给他们。

其他角色

操作经理： 该角色负责监控生产管道的健康执行。他们监控不同来源的数据刷新、不同管道的搭建执行并帮助分流支持请求。此角色支持发布经理。
权限所有者 / 身份管理者： 在大多数情况下，用户分组的分配在客户的身份管理系统中管理，并通过 SAML 集成将信息传递到 Foundry。在这种情况下，权限管理者负责该过程。
数据官员： 负责将语义层建模为用户中心的世界观，负责数据质量，并寻找应集成的新数据源以扩展语义层。数据官员还负责监控在应用案例中进行的丰富化并将其泛化到语义层以提高可重用性。
项目经理： 项目经理与为项目做出贡献的工程师合作，以确保技术和业务目标的对齐、平台开发的最佳实践标准的遵守以及其他项目团队之间的协调。项目经理还负责记录项目。
数据源所有者： 这是特定源系统的主要联系人。他们需要在配置新的数据连接期间与代理管理员密切合作，并在此后承担某种程度的“上游”问题责任——无论是代理服务在他们的服务器或文件系统上运行，还是数据本身的完整性。