注意:以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
Foundry 的总体目标是为您的组织提供一个客观现实的标准视图。构建这一现实的第一步是搭建和权限化您的数据基础。为了说明如何保护您的数据基础,我们将通过一个名为 Sky Industries 的飞机制造商的概念性例子来为您讲解。我们将代表一个 Sky Industries 的开发人员,他们正在整合原始的航班、跑道、机场、警报、路线和乘客数据,为Ontology做准备,然后将其提供给整个 Sky Industries 组织。
设计数据基础的一个关键部分是决定需要为生产数据管道创建哪些项目,以便实现未来的扩展和便捷的维护。在我们的例子中,我们将使用推荐的项目设置,并拥有三个具有不同目的的项目:
根据您的 Foundry 实例,您可以同时创建项目和/或组。目标是每个项目有三个组,每个组映射到一个默认角色(例如,一个只读
)。我们希望我们的项目可以被我们组织中的其他用户发现,所以我们将项目的默认角色设置为发现者
,并且不会向项目添加权限标记。此外,在每个项目中,我们将创建一个代码库,存放我们的变换。下面是我们**航班延误 [变换]**项目的最终设置。
现在我们有了一个用于搭建管道的项目,可以开始使用 Foundry 来编写我们的业务逻辑。有关最佳实践的详细信息,请查看数据集成文档。
在我们可以使用另一个项目的数据之前,我们需要在当前项目中创建对其的引用。一旦这样做,我们可以在我们的搭建中使用该数据集,并允许我们项目中的任何人对该数据进行变换,即使他们自己没有访问源项目的权限。
下面是我们将**航班控制系统 [数据源]项目中的航班数据集添加为航班延误 [变换]**项目的项目引用时的样子。
在编写完所有的变换后,下面是我们最终的生产管道的样子。
由于我们的管道涵盖了三个项目,我们可以为每个项目分别赋予用户特定的角色访问权限。
例如,我们将我们的第一个运营用户 Eric 添加到航空 [Ontology] - 只读组,这将赋予他对航空 [Ontology]项目的只读访问权限。鉴于默认角色是发现者,这些用户在航班控制系统 [数据源]和航班延误 [变换]项目上只会有发现者访问权限,但在航空 [Ontology]项目上是只读。请注意,拥有数据源项目的发现者访问权限不会阻止用户被授予对下游数据的访问权限,比如在Ontology项目中。
下面是 Eric 的资源访问权限的样子。
Eric 的同事 Linda 将负责维护生产管道。因此,Linda 被添加到所有三个项目的相应所有者和编辑者组中。将您的管道分解为离散的项目和组是长期维护最简单的方法。
我们建议通过将同事添加到正确的项目组中来与他们共享数据和资源,以便他们对项目有统一的访问权限。这种方法比直接共享资源更清晰且更易于管理。除了通过正确的项目组成员身份提供正确的角色外,您还应检查其他访问要求,如权限标记和组织成员资格是否满足。查看检查权限部分以获取更多详细信息。