DCM Projects 의 엔터프라이즈 사용 사례¶

소유권¶

각 프로젝트에는 정의된 모든 오브젝트를 배포할 수 있는 하나의 소유자 역할이 있습니다. 권한 부여를 사용하면 프로젝트 내의 개별 오브젝트에 대한 세분화된 액세스 관리를 수행할 수 있습니다. 그러나 서로 다른 사용자 그룹이 프로젝트에 변경 사항을 배포해야 하는 경우에는 일반적으로 그에 따라 DCM project 를 분할하는 것이 합리적입니다.

다음은 예시 시나리오입니다.

• 플랫폼 관리자는 데이터베이스와 웨어하우스를 배포하고, 팀 관리자 역할을 생성하고, 해당 데이터베이스 내부에 정의된 오브젝트 유형 세트에 대해 팀 관리자에게 CREATE 권한을 부여하고, 정의된 계정 수준 통합 세트에 액세스합니다.

• 이제 팀 관리자는 해당 데이터베이스 내에서 스키마와 동적 테이블을 구성하고, 새로 고침 빈도를 미세 조정하고, 개별 팀 구성원에게 보다 세분화된 읽기 액세스 권한을 부여하는 방법을 결정할 수 있습니다.

다음은 솔루션입니다.

• 플랫폼 관리자는 팀을 위한 상위 수준 인프라를 배포하고 팀 관리자에게 데이터베이스 내에 DCM project 프로젝트를 생성할 수 있는 권한을 부여합니다.

• 이제 팀 관리자는 팀 데이터베이스 내에 하나 이상의 프로젝트를 생성하여 테이블을 관리하고 팀 구성원에게 권한을 부여하여 DCM Projects 를 활용할 수도 있습니다.

템플릿 변수¶

DCM project 가 대부분 유사하고, 유사하게 유지해야 하는 오브젝트의 범위를 정의하는 경우, 일반적으로 매개 변수화된 템플릿으로 한 번 정의하는 것이 더 편리합니다.

다음은 예시 시나리오입니다.

• 플랫폼 팀은 조직의 각 리전 팀을 위한 데이터베이스를 배포합니다.

• 시간이 지남에 따라 새로운 리전이 추가될 예정입니다.

• 모든 리전에는 스키마, 랜딩 테이블, 역할 및 웨어하우스에 대해 대부분 동일한 설정이 필요합니다.

• 이 데이터베이스 템플릿의 변경 사항은 모든 팀에 적용되어야 합니다(예: 읽기 전용 역할 추가).

다음은 솔루션입니다.

• 매니페스트 프로필에 나열된 각 리전 팀에 대해 루프에서 단일 정의 세트를 실행할 수 있습니다.

이 템플릿의 더 많은 요소가 분기되기 시작하고 템플릿 조건의 수가 증가하면 개별 오브젝트 정의가 있는 별도의 DCM 프로젝트를 읽고 유지 관리하기가 더 쉬워질 수 있습니다.

별도의 계정과 별도의 데이터베이스¶

Snowflake는 일반적으로 각 환경을 별도의 Snowflake 계정으로 설정할 것을 권장합니다. 이를 통해 실험적 개발과 프로덕션 인프라를 완전히 분리하고 프로덕션 데이터에 대한 개발자 액세스를 제한할 수 있습니다.

그러나 신중한 액세스 관리를 통해 하나의 Snowflake 계정에서 여러 환경을 성공적으로 관리할 수 있습니다. 이는 데이터베이스가 명확하게 분리되어 있을 때 더 쉽고 계정 수준 오브젝트와 통합이 포함될 때 더 어려워질 수 있습니다.

단일 계정 설정의 이점은 프로덕션에 변경 사항을 배포하기 전에 변경 사항을 테스트하기 위해 프로덕션 인프라와 데이터를 쉽게 복제할 수 있다는 점입니다. 그러나 예를 들어 조직 내부 데이터 공유를 통해 프로덕션 데이터와 인프라의 일부를 다른 계정으로 복사하는 것은 비용이 더 많이 들 수 있습니다.

DCM project 템플릿에 미치는 영향¶

각 환경에 대한 고유한 오브젝트 이름은 단일 계정 설정의 요구 사항입니다(예: EMEA_DB 및 EMEA_ADMIN``을 ``EMEA_DB_DEV 및 EMEA_ADMIN_DEV``와 별도로 유지하기 위해). Snowflake는 다중 계정 설정에도 이 방법을 권장합니다. 템플릿화된 이름을 사용하면 ``EMEA_DB_DEV_JOHN 및 ``EMEA_DB_DEV_MARY``와 같은 엔터티의 여러 인스턴스가 독립적인 개발을 위해 공존하고 샌드박스 환경을 신속하게 생성 및 파괴하여 다양한 솔루션을 테스트할 수 있습니다.

이는 데이터베이스, 역할, 웨어하우스 등 모든 계정 수준 오브젝트에 적용됩니다. 그런 다음 이러한 템플릿화된 이름을 중첩된 오브젝트의 모든 정규화된 이름에 적용해야 합니다.

공유 개발 환경¶

여러 개발자가 데이터 제품을 동시에 빌드하고 반복하기 위해 일반적으로 동일한 개발 계정을 공유합니다. 그러나 여러 사용자가 동일한 프로젝트에서 동시에 작업하는 경우 PLAN 및 DEPLOY 작업에서 템플릿을 사용하여 고유한 이름을 생성하지 않으면 충돌이 발생할 수 있습니다.

다음은 예시 시나리오입니다.

• 사용자 A와 B 모두 이미 프로덕션에서 실행 중인 프로젝트 ``TASTYBYTES``의 다른 부분에 대한 변경 사항을 테스트하고 있습니다.

• 각 사용자는 ``prod-main``의 고유한 기능 분기를 생성하고 엔터티 정의 편집을 시작합니다.

• 각 사용자는 자신의 |dcm-object|(TASTYBYTES_DEV_A 및 TASTYBYTES_DEV_B) 를 생성합니다.

• 두 사용자 모두 동일한 DEV 템플릿 구성으로 동일한 Snowflake 계정에 배포하는 경우 다음과 같습니다.

  • 사용자 A는 TASTYBYTES_DEV_A``를 포함한 모든 엔터티의 새 ``_DEV 인스턴스를 먼저 배포하므로 해당 TB_WAREHOUSE_DEV 프로젝트에서 관리됩니다.

  • 사용자 B가 하나 이상의 동일한 오브젝트 이름(예: TB_WAREHOUSE_DEV)을 배포하려고 시도하면, 웨어하우스가 이미 ``TASTYBYTES_DEV_A``에서 관리되고 있으므로 ``TASTYBYTES_DEV_B``에 대한 배포가 실패합니다.

• 또는 두 사용자 모두 동일한 TASTYBYTES_DEV 프로젝트를 소유하고 배포할 수 있으며, 각각은 서로 다른 분기 폴더를 가리킵니다. 이로 인해 사용자 B가 사용자 A의 배포된 모든 엔터티 버전을 덮어쓰게 되며, 그 반대의 경우도 마찬가지입니다.

다음은 솔루션입니다.

• 동일한 개발 환경에서 동시에 작업할 때 Snowflake는 오브젝트 이름 충돌을 방지하기 위해 항상 고유한 엔터티 이름을 사용할 것을 권장합니다. 이는 고유한 접미사로 데이터베이스, 웨어하우스 및 역할 이름을 템플릿화하여 달성할 수 있습니다. 예: DEFINE DATABASE DCM_PROJECT_{{db}};.

• 다음 예제와 같은 구성 프로필을 사용하는 경우 여러 개발자가 모두 DEV 구성을 사용하여 웨어하우스를 ``X-SMALL``로 설정할 수 있습니다.

• 데이터베이스 이름 충돌을 방지하기 위해 개발자는 고유 문자열이 있는 db 변수를 덮어써야 합니다. 이는 사용자 이름, 기능 이름, 티켓 번호 또는 분기 이름을 기반으로 할 수 있습니다.

  예를 들어, snow dcm deploy --variable "db='DEV_JS'"``는 고유한 ``DEFINE DATABASE DCM_PROJECT_DEV_JS; 작업으로 해결됩니다.

  CopyExpand

  templating:
    defaults:
      wh_size: "X-SMALL"
  
    configurations:
      DEV:
        db: "DEV"
  
      TEST:
        db: "TEST"
  
      PROD:
        db: "PROD"
        wh_size: "LARGE"
  

  Show lessSee more

  Scroll to top

• 한 개발자가 여러 프로젝트에서 작업할 때 동일한 템플릿 솔루션을 적용할 수 있습니다.

• 다음은 팀을 위한 확장 가능한 프로젝트 설정의 예제입니다.

  새 Jira 티켓을 시작할 때 다음 단계를 완료합니다.

  1. CREATE GIT BRANCH {{ticket_number}} FROM REPO

  2. CREATE DCM PROJECT {{ticket_number}}

  3. EXECUTE DCM PROJECT {{ticket_number}} PLAN USING CONFIGURATION "DEV" (db => '{{ticket_number}}') FROM @REPO/BRANCHES/{{ticket_number}}/DCM_PROJECT/