Foundry의 궁극적인 목표는 그룹 내에서 객관적 현실의 표준적 보기를 제공하는 것입니다. 이 현실을 구축하는 첫 번째 단계는 데이터 기반을 빌드하고 권한을 설정하는 것입니다. 데이터 기반을 어떻게 보안할 수 있는지 설명하기 위해, 우리는 Sky Industries라는 항공기 제조업체의 예시를 통해 설명하겠습니다. Sky Industries 개발자가 원시 비행, 활주로, 공항, 경고, 경로 및 승객 데이터를 통합하여 온톨로지에 준비하고, 이를 전체 Sky Industries 그룹에 제공하는 과정을 나타낼 것입니다.
데이터 기반 설계의 핵심 부분은 생산 데이터 파이프라인을 위해 어떤 프로젝트를 생성해야 하는지를 결정하는 것입니다. 이는 향후 확장 및 쉬운 유지보수를 가능하게 합니다. 예시에서는 추천 프로젝트 설정을 사용하고, 각기 다른 목적을 가진 3개의 프로젝트를 가집니다:
Foundry 인스턴스에 따라 프로젝트와/또는 그룹을 동시에 생성할 수 있습니다. 목표는 각 프로젝트마다 기본 역할(예: Viewer
)에 매핑된 세 그룹을 갖는 것입니다. 우리는 프로젝트가 그룹 내 다른 사용자에게 모두 발견 가능하도록 하고 싶기 때문에 프로젝트의 기본 역할을 Discoverer
로 설정하고 프로젝트에 마킹을 추가하지 않을 것입니다. 또한 각 프로젝트에서 변환이 저장될 Code Repositories를 생성할 것입니다. 아래는 Flight Delays [Transform] 프로젝트에 대한 최종 설정입니다.
이제 파이프라인을 빌드할 프로젝트가 생겼으니, Foundry를 사용하여 비즈니스 로직을 작성할 수 있습니다. 모범 사례에 대한 자세한 내용은 데이터 통합 문서를 확인 해주세요.
다른 프로젝트의 데이터를 사용하기 전에 현재 프로젝트에 대한 출처를 생성해야 합니다. 이렇게 하면, 빌드에서 해당 데이터셋을 사용할 수 있으며, 프로젝트 내 누구나 데이터의 변환을 작성할 수 있습니다. 심지어 소스 프로젝트에 대한 접근 권한이 없어도 가능합니다.
아래는 Flight Control System [Datasource] 프로젝트의 flights 데이터셋을 Flight Delays [Transform] 프로젝트에 추가할 때의 모습입니다.
모든 변환을 작성한 후, 아래는 최종 생산 파이프라인의 모습입니다.
파이프라인이 3개의 프로젝트를 포함하므로, 각 프로젝트에 대해 사용자의 특정 역할 접근을 별도로 제공할 수 있습니다.
예를 들어, 첫 번째 운영 사용자 Eric을 Aviation [Ontology] - Viewer 그룹에 추가하여 Aviation [Ontology] 프로젝트에 대한 Viewer 접근을 부여할 것입니다. 기본 역할이 Discoverer이므로, 동일한 사용자는 Flight Control System [Datasource] 및 Flight Delays [Transform] 프로젝트에서는 Discoverer 접근만 가지지만, Aviation [Ontology] 프로젝트에서는 Viewer 접근을 가집니다. 데이터소스 프로젝트에 대한 발견자 접근이 있다고 해서 온톨로지 프로젝트와 같은 하류 데이터에 대한 접근이 부여되지 않는 것은 아닙니다.
아래는 Eric의 리소스 접근 모습입니다.
Eric의 동료인 Linda는 생산 파이프라인을 유지할 사람입니다. 따라서 Linda는 모든 3개 프로젝트의 해당 소유자 및 편집자 그룹에 추가됩니다. 파이프라인을 개별 프로젝트와 그룹으로 나누는 것이 장기적으로 가장 유지보수하기 쉽습니다.
동료와 데이터를 공유하고 리소스를 공유하는 가장 좋은 방법은 올바른 프로젝트 그룹에 추가하여 프로젝트에 대한 일관된 접근을 제공하는 것입니다. 이 방법은 리소스를 직접 공유하는 것보다 더 읽기 쉽고 관리하기 쉽습니다. 올바른 프로젝트 그룹 멤버십을 통해 적절한 역할을 제공하는 것 외에도, 마킹 및 그룹 멤버십과 같은 다른 접근 요구 사항이 충족되는지 확인해야 합니다. 자세한 내용은 권한 확인 섹션을 확인 해주세요.