Anwendungsfälle in Unternehmen für DCM Projects¶

Eigentümerschaft¶

Jedes Projekt hat eine Eigentümerrolle, die alle definierten Objekte bereitstellen kann. Zuweisungen ermöglichen eine detaillierte Zugriffsverwaltung für einzelne Objekte innerhalb des Projekts. Wenn jedoch verschiedene Gruppen von Benutzenden für die Bereitstellung von Änderungen an einem Projekt zuständig sind, ist es im Allgemeinen sinnvoll, ein DCM project entsprechend zu teilen.

Nachfolgend ein Beispielszenario:

• Der Plattformadministrator stellt eine Datenbank und ein Warehouse bereit, erstellt die Rolle des Teamadministrators und weist CREATE-Berechtigungen an den Teamadministrator für einen definierten Satz von Objekttypen innerhalb dieser Datenbank sowie Zugriff auf einen definierten Satz von Integrationen auf Kontoebene zu.

• Der Teamadministrator kann nun entscheiden, wie Schemas und dynamische Tabellen in dieser Datenbank organisiert werden sollen, wie die Aktualisierungsfrequenzen angepasst werden und wie einzelnen Teammitgliedern ein detaillierterer Lesezugriff gewährt werden soll.

Im Folgenden finden Sie eine Lösung:

• Der Plattformadministrator stellt die allgemeine Infrastruktur für das Team bereit und erteilt dem Teamadministrator die Berechtigung, DCM project-Projekte in der dazugehörigen Datenbank zu erstellen.

• Der Teamadministrator kann jetzt auch von DCM Projects profitieren, indem ein oder mehrere Projekte innerhalb der Teamdatenbank erstellt werden, um Tabellen und Berechtigungen für Teammitglieder zu verwalten.

Vorlagenvariablen¶

Wenn ein DCM project einen Bereich von Objekten definiert, die ähnlich sind und größtenteils auch ähnlich bleiben sollten, ist es im Allgemeinen bequemer, sie einmal als parametrisierte Vorlage zu definieren.

Nachfolgend ein Beispielszenario:

• Das Plattformteam stellt für jedes regionale Team in der Organisation eine Datenbank bereit.

• Es wird erwartet, dass im Laufe der Zeit neue Regionen hinzugefügt werden.

• Alle Regionen erfordern meist die gleiche Einrichtung von Schema, Zieltabellen, Rollen und Warehouse.

• Änderungen an dieser Datenbankvorlage sollten auf alle Teams angewendet werden, z. B. das Hinzufügen einer Nur-Lese-Rolle.

Im Folgenden finden Sie eine Lösung:

• Sie können für jedes im Manifest-Profil aufgeführte regionale Team einen einzigen Satz von Definitionen in einer Schleife ausführen.

Wenn mehr Elemente dieser Vorlage abweichen und sich die Anzahl der Vorlagenbedingungen erhöht, kann es einfacher sein, separate DCM-Projekte mit ihren individuellen Objektdefinitionen zu lesen und zu verwalten.

Separate Konten vs. separate Datenbanken¶

Snowflake empfiehlt im Allgemeinen, jede Umgebung als separates Snowflake-Konto einzurichten. Dies stellt eine vollständige Trennung der Produktionsinfrastruktur von der experimentellen Entwicklung dar und garantiert einen eingeschränkten Zugriff von Entwickelnden auf die Produktionsdaten.

Mit einer sorgfältigen Zugriffsverwaltung können Sie jedoch erfolgreich mehrere Umgebungen in einem Snowflake-Konto verwalten. Dies ist einfacher, wenn die Datenbanken deutlich getrennt sind, und kann schwieriger werden, wenn Objekte und Integrationen auf Kontoebene beteiligt sind.

Der Vorteil einer Einzelkonto-Einrichtung ist die Möglichkeit, auf einfache Weise die Infrastruktur und die Daten der Produktion zu klonen, um Änderungen zu testen, bevor diese Änderungen in der Produktion bereitgestellt werden. Das Kopieren von Teilen der Produktionsdaten und der Infrastruktur auf ein anderes Konto, z. B. über organisationsinterne Datenfreigaben, kann jedoch teurer sein.

Auswirkungen auf DCM project-Vorlagen¶

Eigene Objektnamen für jede Umgebung sind eine Anforderung für Einzelkonto-Einrichtungen, um z. B. EMEA_DB und EMEA_ADMIN getrennt von EMEA_DB_DEV und``EMEA_ADMIN_DEV`` beizubehalten. Snowflake empfiehlt dieses Verfahren auch bei Konfigurationen mit mehreren Konten. Namensvorlagen ermöglichen mehrere Instanzen von Entitäten, wie z. B. EMEA_DB_DEV_JOHN und EMEA_DB_DEV_MARY, für eine unabhängige Entwicklung und um schnell Sandbox-Umgebungen zu erstellen und zu beseitigen, um verschiedene Lösungen zu testen.

Dies gilt für alle Objekte auf Kontoebene, wie Datenbanken, Rollen und Warehouses. Sie müssen diese Namensvorlagen dann auf alle vollqualifizierten Namen verschachtelter Objekte anwenden.

Freigegebene Entwicklungsumgebung¶

Mehrere Entwickelnde teilen sich in der Regel dasselbe Entwicklungskonto, um Datenprodukte parallel zu erstellen und zu iterieren. Wenn jedoch mehrere Benutzende parallel an demselben Projekt arbeiten, können ihre PLAN- und DEPLOY-Operationen Konflikte verursachen, wenn sie keine Vorlagen verwenden, um eindeutige Namen zu erstellen.

Nachfolgend ein Beispielszenario:

• Die Benutzenden A und B testen die Änderungen an verschiedenen Teilen des Projekts TASTYBYTES, das bereits in der Produktion ist.

• Jeder Benutzende erstellt seinen eigenen Feature-Zweig von prod-main und beginnt mit der Bearbeitung der Entitätsdefinitionen.

• Jeder Benutzende erstellt sein eigenes DCM project (TASTYBYTES_DEV_A und TASTYBYTES_DEV_B).

• Wenn beide Benutzenden mit derselben DEV-Vorlagenkonfiguration auf dasselbe Snowflake-Konto bereitstellen, dann gilt Folgendes:

  • Der Benutzende A stellt die neue _DEV-Instanz aller Entitäten zuerst bereit, einschließlich TB_WAREHOUSE_DEV, sodass sie von dem dazugehörigen Projekt TASTYBYTES_DEV_A verwaltet werden.

  • Sobald der Benutzende B versucht, einen oder mehrere der gleichen Objektnamen bereitzustellen (z. B. TB_WAREHOUSE_DEV), schlägt die Bereitstellung für TASTYBYTES_DEV_B fehl, weil das Warehouse bereits von TASTYBYTES_DEV_A verwaltet wird.

• Alternativ können beide Benutzenden dasselbe Projekt besitzen und von demselben Projekt TASTYBYTES_DEV aus bereitstellen, die jeweils auf ihre verschiedenen Zweigordner verweisen. Dies würde dazu führen, dass der Benutzende B alle bereitgestellten Entitätsversionen des Benutzenden A überschreibt und umgekehrt.

Im Folgenden finden Sie eine Lösung:

• Wenn Sie parallel in derselben Entwicklungsumgebung arbeiten, empfiehlt Snowflake immer unterschiedliche Entitätsnamen zu verwenden, um widersprüchliche Objektnamen zu vermeiden. Sie können dies erreichen, indem Sie Vorlagen für Datenbank-, Warehouse- und Rollennamen mit eindeutigen Suffixen erstellen. Beispiel: DEFINE DATABASE DCM_PROJECT_{{db}};.

• Wenn Sie Konfigurationsprofile wie im folgenden Beispiel verwenden, können mehrere Entwickelnde die DEV-Konfiguration verwenden, um deren Warehouses auf X-SMALL einzustellen.

• Um widersprüchliche Datenbanknamen zu vermeiden, sollten Entwickelnde die db-Variable mit einer eindeutigen Zeichenfolge überschreiben. Diese Informationen können auf Benutzernamen, Funktionsnamen, Ticket-Nummern oder Zweignamen basieren.

  Zum Beispiel würde snow dcm deploy --variable "db='DEV_JS'" zu einer eindeutigen DEFINE DATABASE DCM_PROJECT_DEV_JS;-Operation aufgelöst werden.

  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

• Sie können dieselbe Vorlagenlösung anwenden, wenn ein Entwickelnder an mehreren Projekten arbeitet.

• Im Folgenden finden Sie ein Beispiel für eine skalierbare Projekteinrichtung für Teams.

  Wenn Sie ein neues Jira-Ticket erstellen, führen Sie die folgenden Schritte aus:

  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/