Snowflake に dbt プロジェクトを保存できるようになりました。dbt プロジェクトとは、dbt_project.yml、profiles.yml、そしてモデルなどのアセットファイルを含む関連ファイルのセットです。
Snowflake では、dbt プロジェクトをスキーマオブジェクトとして保存できます。1 つの dbt プロジェクトに属するファイルはグループ化され、1 つのユニット（スキーマレベルオブジェクト）として扱われます。この機能は「dbt Project on Snowflake」と呼ばれます。
Snowflake で dbt プロジェクトを作成する方法
ステップ 1: ソースファイルをアップロードする
dbt プロジェクトのソースファイルは、次のいずれかの場所に配置できます。
- 内部の名前付きステージ
- Git リポジトリステージ
- 既存の dbt プロジェクトオブジェクト
- Snowflake 上の dbt 用ワークスペース
上記の場所に関する追加情報
Git リポジトリステージ：
Snowflake は、リモート Git リポジトリのクローン作成をサポートしています。Snowflake の Git リポジトリクローンは、ブランチ、タグ、コミットを含むリモートリポジトリの完全なクローンを持つローカル Git リポジトリとして機能します。
Snowflake 上のワークスペース：
Snowflake には、ローカルワークスペースとリモート Git リポジトリ統合ワークスペースの 2 種類のプライベートワークスペースがあります。
- ローカルワークスペースでは、すべてのファイルは Snowflake のローカルに保存されます。ファイルは Snowflake 内にのみ保存されます。
- リモート Git リポジトリ統合ワークスペースでは、ワークスペースは基本的にリモートリポジトリのクローンを持つエディターになります。ファイルはリモート Git リポジトリと Snowflake の両方に保存されます。 （Git 統合ワークスペースと Git リポジトリステージの違いは、前者にはエディターがあることです。）Git 統合ワークスペースには、フェッチ、プッシュなどの Git 機能を有効にする UI コメントがあります。
リモート Git リポジトリへの接続
以下のリモート Git リポジトリに接続するには、Snowflake のオブジェクト/設定が必要です。
- API 統合
- リポジトリがプライベートの場合は、シークレット
- ネットワークルール
- ネットワークルールを参照する外部アクセス統合
ステップ 2: dbt プロジェクトのデプロイ（作成）
ソースファイルを Snowflake に コピー した後、スキーマ内に dbt プロジェクトとしてデプロイできます。「デプロイ」とは、ソースファイルを Snowflake スキーマに（単一のユニットとして）保存することを意味します。dbt プロジェクトを実行することを意味するものではありません。
ソースファイルが Snowflake ワークスペースにある場合の dbt プロジェクトのデプロイ例。
(Snowflake ワークスペースには、デプロイを可能にする UI コンポーネントがあります。)
CREATE DBT PROJECT some_db.xyz_schema.my_dbt_project
FROM 'snow://workspace/user$.public."My DBT Project"/versions/live/'
dbt プロジェクトがデプロイされるたびに、Snowflake は Version$1 から始まるバージョン仕様を作成します。dbt プロジェクトが変更されるたびに、バージョンは 1 ずつ更新されます。
dbt プロジェクトの実行
dbt プロジェクトがデプロイされると(スキーマに保存されると)、実行できるようになります。UI、SQL ステートメントを使用して実行できます。
EXECUTE DBT PROJECT my_database.my_schema.my_dbt_project args='run --target prod';
上記のコマンドを Snowflake のプロシージャとタスクでラップすることもできます。
自動更新なし
ワークスペースまたは Git リポジトリでソースコードを編集しても、変更は dbt プロジェクトには反映されません。(dbt project on Snowflakeは、特定のスキーマにアタッチされたソースファイルのコピーだけです)。変更を dbt プロジェクトに適用するには、再度デプロイする必要があります（これにより、dbt プロジェクトの新しいバージョンが作成されます）。
Snowflake における dbt プロジェクトのメリットとデメリット
Snowflakeにおけるdbtプロジェクトの明確なメリットを見つけるのは困難です。潜在的なメリットは1つだけあります。
セキュリティ：dbtプロジェクトのソースコードを、実際のデータが保存されているSnowflake内に保存する方が安全だと言えるでしょう。 この場合、ソースファイルはローカルワークスペースで編集する必要があります。共同作業が必要な場合は、共有ワークスペースを使用する必要があります。
しかし、(Microsoftの) GitHubはソースコードの保存において同等の高いセキュリティを提供します。さらに、Snowflakeのローカルワークスペースを使用すると、エディター拡張機能やsqlfluffなどのコマンドラインツールを使用できなくなります。
タスクを使用してdbtプロジェクトの実行をSnowflake上の他のアクションとスケジュールして組み合わせることはメリットと考えられるかもしれませんが、必ずしも他に類を見ないものです。ほGitHub Actions等は、スケジュール実行をサポートする CI/CD 機能が備わっています。そのため、これは明確な利点とは言えません。ストアド プロシージャなどの他のアクションの実行と dbt プロジェクトの実行を組み合わせるには、dbt の on-run-start フックと on-run-end フックを使用することもできます。
さらに、Snowflake 上の dbt プロジェクトでは（ローカル ワークスペース、Git 統合ワークスペース、Git リポジトリ ステージのいずれを使用していても）、ソース ファイルが変更されると、dbt プロジェクトを（再）デプロイする必要があります。
結論
データが存在する場所にソースコードを保存するなど、ニーズがあれば、dbt Project on Snowflakeが唯一の選択肢と思います。その他の場合は、Snowflake 上の dbt プロジェクトは、既存のソリューションに対して明確な利点を提供しません。
Comments
Post a Comment