Snowflake & dbt Cloudハンズオン実践 #3: 『dbtの基本構造』 #snowflakeDB #dbt

2024.01.30

アライアンス事業部 エンジニアグループ モダンデータスタック(MDS)チームの しんや です。

Snowflakeが展開しているサイト『Snowflake Quickstarts』では、Snowflake単体、またSnowflakeと他サービスとの連携について実戦形式で手を動かしながら学んでいけるコンテンツが多数公開されています。

その中の1つ『Accelerating Data Teams with Snowflake and dbt Cloud Hands On Lab(Snowflake と dbt Cloud ハンズオン ラボを使用してデータ チームを加速する)』は、dbt CloudとSnowflakeを連携させる形で、Snowflakeのデータを使ってdbt Cloudでデータ変換の処理を作り上げていく流れを学ぶことが出来る非常に参考になるコンテンツです。

当エントリ及び一連のエントリ群では、この一連の手順を実際に手を動かしながら進めた記録をまとめて行こうと思います。

第3弾の当エントリでは『dbtの基本構造』パートについて実践内容を紹介します。

一連の内容を1本にまとめようとするとめちゃくちゃボリュームが大きくなる内容でしたので、以下の形でそれぞれ分けて紹介していこうと思います。
#1: Snowflake環境準備編 [Snowflake QuickStarts: Step01-04]
#2: dbt Cloud IDE探索編 [Snowflake QuickStarts: Step05]
#3: dbt Cloud 基本構造紹介編 [Snowflake QuickStarts: Step06]
#4: dbt Cloud 実践編1(ソース設定&ステージングモデル作成) [Snowflake QuickStarts: Step07]
#5: dbt Cloud 実践編2(シード&マテリアライゼーション) [Snowflake QuickStarts: Step08]
#6: dbt Cloud 実践編3(マートモデルの作成) [Snowflake QuickStarts: Step09]
#7: dbt Cloud 実践編4(テスト&ドキュメント) [Snowflake QuickStarts: Step10]
#8: dbt Cloud 実践編5(デプロイ) [Snowflake QuickStarts: Step11]
#9: Snowsightダッシュボード可視化編 [Snowflake QuickStarts: Step12]

目次

 

Step06. dbtの基本構造

dbt_project.ymlの設定

dbt Cloudで開発を進めていくには、作業用に新しいgitブランチを作成することから始める必要があります。画面左上、Git管理ペインにある[Create branch]を押下し、任意のブランチ名を指定してブランチを作成します。

dbtプロジェクトの開発でまず着手するのはdbt_project.ymlと呼ばれるファイルの更新です。このファイルは、dbtが私達が作業しているファイルディレクトリがdbtプロジェクトであることを認識するために探すファイルです。このファイルはプロジェクト直下に存在します。

ファイルをクリックして開き、既存の内容をすべて以下のコードに置き換え、保存。

既存の内容:

# Name your project! Project names should contain only lowercase characters
# and underscores. A good package name should reflect your organization's
# name or the intended use of these models
name: 'my_new_project'
version: '1.0.0'
config-version: 2

# This setting configures which "profile" dbt uses for this project.
profile: 'default'

# These configurations specify where dbt should look for different types of files.
# The `model-paths` config, for example, states that models in this project can be
# found in the "models/" directory. You probably won't need to change these!
model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target"  # directory which will store compiled SQL files
clean-targets:         # directories to be removed by `dbt clean`
  - "target"
  - "dbt_packages"


# Configuring models
# Full documentation: https://docs.getdbt.com/docs/configuring-models

# In dbt, the default materialization for a model is a view. This means, when you run 
# dbt run or dbt build, all of your models will be built as a view in your data platform. 
# The configuration below will override this setting for models in the example folder to 
# instead be materialized as tables. Any models you add to the root of the models folder will 
# continue to be built as views. These settings can be overridden in the individual model files
# using the `{{ config(...) }}` macro.

models:
  my_new_project:
    # Applies to all files under models/example/
    example:
      +materialized: table

変更内容:

name: 'snowflake_workshop'
version: '1.0.0'
config-version: 2

profile: 'default'

source-paths: ["models"]
analysis-paths: ["analysis"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target"  
clean-targets:         
    - "target"
    - "dbt_modules"

models:
  snowflake_workshop:
    staging:
      materialized: view
      snowflake_warehouse: pc_dbt_wh
    marts:
      materialized: table
      snowflake_warehouse: pc_dbt_wh_large

ポイントはモデルに関する部分(19〜26行目:models:セクション)です。この部分では、フォルダレベルで、そのフォルダ内のすべてのモデルに適用したい設定を定義しています。具体的には

  • materialized: - dbtがSnowflakeにプッシュする前にコードをコンパイルする際に、どのようにモデルをマテリアライズするかを指示。
  • snowflake_warehouse: - Snowflakeでモデルをビルドするときに使用するSnowflakeウェアハウスを指定。

ここで出てきたマテリアライゼーション(materialization)というのは、dbtモデルをウェアハウスに永続化するための戦略です。指定可能な選択肢は全部で4つありますが、テーブルとビューが最も一般的に利用されるタイプです。デフォルトでは、すべてのdbtモデルはビューとしてマテリアライズされ、他のマテリアライゼーションタイプはdbt_project.ymlファイルまたはモデル自体で設定することが可能です。詳細に関してはこちらをご参照ください。

dbt_project.ymlのこの設定では、dbtは以下の処理を行っています。dbt のマテリアライゼーションを使用する利点は、dbt モデルを実行する際、dbt はマテリアライゼーションに関連する適切な DDL を使用してデータウェアハウス内にモデルと同等のものを作成します。

  • staging フォルダにあるすべてのモデルをビューとして実体化
  • marts フォルダにあるすべてのモデルをテーブルとして実体化

そしてdbtでは、各dbtの接続は実行時にSnowflakeでモデルを構築する際に使用するデフォルトの倉庫を宣言します。この宣言をdbt_project.ymlで行うことにより、dbt以下の作業をそれぞれに行います。この構成により、プロジェクトのさまざまな部分の計算ニーズに基づいて、ウェアハウスのサイズをスケールアップしたりスケールダウンしたりすることができます。

  • ウェアハウス:x-small pc_dbt_whを使用してステージングフォルダ内のすべてを構築
  • ウェアハウス:large pc_dbt_wh_largeを使用してmartsフォルダ内のすべてを構築

dbt_project.ymlで設定出来ることはまだ他にもあります。マテリアライゼーションとウェアハウスだけでなく、モデル、シード、そしてテストに設定を適用する方法についても指定が可能です。詳細はこちらの情報をご参照ください。

dbtのフォルダ構造

dbtでは、dbt Labs社がプロジェクト構造に関するガイドを「ベストプラクティス」として作成・公開しています。

この実践内容で構築するフォルダ構造は、このガイダンスに従い、ガイドに記載されている以下のカテゴリに当てはまります。

  • Sources(ソースデータ):
    • TPC-Hデータセットであり、ソースYAMLファイルで定義される。
  • ステージング層のモデル:
    • これらのモデルは、対応するソースと1対1の関係を持ち、名前を変更したり、キャストを変更したり、一般的にプロジェクトの残りの部分を通して一貫して使用される軽度の変換を実行するための場所として機能する。
  • マート層のモデル:
    • ビジネスプロセスやエンティティを表現するモデルで、ベースとなるデータソースから抽象化されている。ここで主要な変換を行う。

定義されたプロジェクト構造を持つことで、(それが正確なものでなくても)予測可能なファイルツリーを作成し、モデルがどのフォルダに存在すべきかを推測する必要がなくなります。フォルダ構造を実装して、モデル開発の舞台を整えましょう。

上記の構造をdbtプロジェクトにも作成します。まずはフォルダから。dbt Cloudではフォルダやファイル作成時にショートカット的記法を用いることで作成作業を効率化出来ます。

ファイルツリーのmodelsサブディレクトリにカーソルを合わせ、フォルダ名の右に表示される3つの点を選択の上[Create Folder]をクリック。ファイルパスにstaging/tpchと入力して、stagingとtpchの2つの新しいフォルダを追加します。追加のフォルダ名が含まれていないことを確認し、[作成]をクリック。

同じ手順でmarts/coreフォルダもmodelsフォルダ配下に作成します。

作業が全て完了すると、modelsフォルダ配下のフォルダ構造は以下のようになっているはずです。

dbtパッケージ

dbtには「パッケージ」という概念・機能があります。dbtパッケージは基本的にdbtプロジェクトであり、自分のプロジェクトに取り込むことで、あたかも自分のプロジェクトのようにコードを使用することができます。

多くのパッケージは「dbt Packages Hub」というサイトでホストされています。

パッケージを活用することで、以下のようなことが出来たりします。

「Jinja」と「マクロ」というワードが出てきたのでここで簡単な紹介をしておきます。

Jinja」はpythonic(Python風)なテンプレート言語で、(dbtでは)SQLでは通常不可能なことを行うことができます。例えば、if文やforループのような制御構造を構築したり、コードの断片を再利用可能なマクロに抽象化して、同じことを繰り返さないようにしたり(DRY)ということを実現出来たりします。

また「マクロ(Macro)」は他のプログラミング言語における関数のように、dbtプロジェクト全体で何度も再利用できるjinjaコードの一部です。dbtで最も重要な関数であるsourceやrefもマクロの一部です。dbtのモデルの記載でSQLの変換を繰り返しているのであれば、パッケージの中にマクロがあるはずです。マクロは自分で構築することも出来ます。

Jinjaに関しては下記ドキュメントを試してみて頂くことをお勧めします。

また、マクロに関してはdbt_project.ymlファイルでウェアハウスを具体的に宣言するプロセスをダイナミックにするマクロなんてのもあります。

さて、ここでdbt Cloud上でパッケージを導入する手順を試してみましょう。「dbt_utils」というパッケージは、dbtで開発を行っていく上で非常に便利な機能が揃っています。ここでは試しにこのパッケージを入れてみます。

パッケージをインストールするには、まずホームディレクトリ(dbt_project.ymlファイルと同じ階層)に新しいファイルを作成し、packages.ymlとします。

ファイルの中身は以下のテキストを記載。

packages:
  - package: dbt-labs/dbt_utils
    version: 0.8.4

パッケージをインストールするdbtのコマンド:dbt depsを実行。コマンドが成功すればパッケージ導入も成功です。

以上で当ステップは完了。ここまでの作業内容をコミット&プッシュしておきます。(以降ステップの区切りで修正内容をコミット、プッシュする流れで進めます)

 

まとめ

という訳で、Snowflake QuickStarts『Accelerating Data Teams with Snowflake and dbt Cloud Hands On Lab』実践第3弾、dbtの基本構造に関する内容の紹介でした。

次エントリ(第4弾)ではdbt Cloudでのモデル作成実践編その1(ソース設定&ステージングモデル作成)に関するパートを進めていきます。