エンタープライズにおける|dcm|のユースケース¶

所有権¶

各プロジェクトには、定義されたすべてのオブジェクトをデプロイできる所有者ロールが1つあります。権限付与により、プロジェクト内の個々のオブジェクトに対する詳細なアクセス管理が可能になります。ただし、プロジェクトへの変更のデプロイを担当するユーザーグループが異なる場合は、一般に、|dcm-object|をそれに応じて分割することが理にかなっています。

以下はシナリオ例です。

• プラットフォーム管理者は、データベースとウェアハウスをデプロイし、チーム管理者ロールを作成して、そのデータベース内の定義された一連のオブジェクトタイプに対するCREATE権限と、定義された一連のアカウントレベル統合へのアクセス権をチーム管理者に付与します。

• チーム管理者は、そのデータベース内のスキーマや動的テーブルを整理する方法を決定したり、更新頻度を微調整したり、個々のチームメンバーに対してより詳細な読み取りアクセス権を付与したりできるようになりました。

以下は解決策です。

• プラットフォーム管理者は、チーム向けにハイレベルなインフラストラクチャをデプロイし、そのデータベース内で|dcm-object|プロジェクトを作成する権限をチーム管理者に付与します。

• チーム管理者は、チームデータベース内に1つ以上のプロジェクトを作成してテーブルやチームメンバーへの権限付与を管理することで、さらに|dcm|を活用できるようになりました。

テンプレート変数¶

|dcm-object|において、内容がほぼ共通しており、今後もその状態を維持するべき一連のオブジェクトを定義する場合は、それらをパラメーター化されたテンプレートとして一度定義する方が一般的に便利です。

以下はシナリオ例です。

• プラットフォームチームは、組織内の各リージョンチーム向けにデータベースをデプロイします。

• 新たなリージョンは、今後追加されていく予定です。

• すべてのリージョンにおいて、スキーマ、ランディングテーブル、ロール、およびウェアハウスの設定はほぼ同じである必要があります。

• このデータベーステンプレートへの変更は、すべてのチームに適用する必要があります。例えば、読み取り専用ロールを追加する場合です。

以下は解決策です。

• マニフェストプロファイルにリストされている各リージョンチームに対して、単一の定義セットをループ処理で実行できます。

このテンプレートの多くの要素に相違が生じ始め、テンプレート化条件の数が増えると、個別のオブジェクト定義を持つ別々のDCMプロジェクトとして読み取りやメンテナンスを行う方が容易になる場合があります。

個別のアカウントと個別のデータベース¶

Snowflakeでは通常、各環境を個別のSnowflakeアカウントとして設定することを推奨しています。これにより、本番環境のインフラストラクチャと実験的な開発を完全に分離し、本番データへの開発者のアクセスを確実に制限できます。

ただし、アクセス管理を慎重に行うと、1つのSnowflakeアカウントで複数の環境を適切に管理できます。これは、データベースが明確に分離されている場合は簡単ですが、アカウントレベルのオブジェクトや統合が関係する場合は、より困難になる可能性があります。

単一アカウント設定の利点は、本番環境に変更をデプロイする前に、本番環境のインフラストラクチャとデータを簡単にクローンしてその変更をテストできることです。ただし、本番データとインフラストラクチャの一部を組織内部のデータ共有などを介して別のアカウントにコピーする場合は、コストが高くなる可能性があります。

|dcm-object|のテンプレート化への影響¶

単一アカウント設定では、各環境で異なるオブジェクト名を使用する必要があります。例えば、``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が``TB_WAREHOUSE_DEV``を含むすべてのエンティティの新しい``_DEV``インスタンスをデプロイし、それらはプロジェクト``TASTYBYTES_DEV_A``によって管理されます。

  • ユーザーBが同じオブジェクト名（例：TB_WAREHOUSE_DEV）を1つ以上デプロイしようとすると、ウェアハウスがすでに``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

• 1人の開発者が複数のプロジェクトで作業する場合、同じテンプレート化ソリューションを適用できます。

• 以下は、チーム向けのスケーラブルなプロジェクト設定の例です。

  新しい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/