DBTデータ変換ツールのスタートガイド - DBT CORE基礎編

はじめに

最近、私はデータ開発に関連する仕事をしています。データ開発と言えば、現在非常に人気のあるオープンソースのデータ変換ツールであるdbtについて話さなければなりません。dbtはETL（抽出・変換・書き出し）プロセスで非常に重要な役割を果たしています。

私自身もデータ開発の初心者ですが、この期間中に多くの経験を積みました。dbt関連の文書が詳細に記録されていることは少ないので、自分が開発中に得た知識を共有するためにいくつかのシリーズ記事を通じて情報を提供したいと考えました。このシリーズは特に初心者向けであり、ご参考になれば幸いです。

本記事はdbtシリーズ記事の冒頭部分です。この記事を読むことで、以下の情報をお伝えしたいと思います：

• データ開発やデータ分析初心者が事前に知っておく必要がある概念
• dbtとは何か？dbtの重要な概念を紹介する
• dbtを使用するための環境準備
• dbtコアとdbtアダプターのインストール方法
• dbtアダプターでデータベースに接続する方法
• dbtで自分自身の最初のモデルを作成する方法

それでは、質問から始めましょう。

データ開発で知っておくべき前提の概念

まず、データ開発初心者が知っておくべきいくつかの前提概念について理解しましょう。

dbtとは何ですか？

DBT（Data Build Tools）は、データ変換ワークフローツールです。データ開発者として、私たちは元のデータをさまざまな加工や集計処理にかけて、より複雑なデータ分析ニーズに対応する必要があります。正確に言えば、dbtはさまざまなデータクエリSQLを書くためのデータ変換ツールです。

「ただSQLを書くだけなら、どうしてdbtを使う必要があるのか」と思うかもしれません。実際には、さまざまな種類のデータベースが存在し、異なるデータベースではSQL文に互換性の問題が生じることがあります。また、データ変換には依存関係も存在します。例えば、基礎的な元のデータからビジネス上の情報へと段階的に変換する場合、この依存関係を自分で管理する必要があるかもしれません。おそらくdbtの多くの機能を実現できるかもしれませんが、実は細部への対応は非常に手間暇がかかります。それではなんで基本的な作業を助けてくれるツールを使わないでしょうか？

dbtをより良く理解するために、dbtをシェフと考えることができます。そして、元のデータは食材です。シェフ（DBT）の仕事は、食材（元のデータ）をおいしい料理（ビジネス価値のあるデータモデル）に加工することです。このプロセスは料理と同じように、特定の順序や手順に従って操作する必要があります。

dbtのワークフローは調理手順のようなものであり、単にdbtに何を作りたいか伝えるだけです（どんなデータモデルが欲しいかを定義してSQLを指定します）。その後、dbtは指示通りに一つずつ食材（元のデータ）を処理し、最終的に望む料理（必要なデータモデル）を作り上げます。

実際、これまで話した内容から分かるように、dbtは私たちがどんなデータが欲しいかやどんなデータモデルを定義するかに集中できるよう支援してくれます。残りの作業フローはすべてdbtに任せられるわけです。それがdbtの役割です。さらに話すと、dbt Cloudはモデルの構築を支援するために自動展開や定期タスクの自動化も提供していますが、これらは後続の記事で詳しく説明します。

dbt Coreとdbt Cloudとは？

dbtのドキュメントを読む予定がある場合、おそらく「dbt Core」と「dbt Cloud」という2つの用語に注目することでしょう。これら2つの役割と違いについて理解しましょう。

• dbt Core：dbt Coreはdbtのオープンソース部分であり、データモデリング、変換、管理の核心機能を提供します。dbt Coreを使用すると、データ変換モデルを定義して実行し、SQLクエリを生成することができます。そして、データをターゲットのデータウェアハウス（BigQuery、Snowflakeなど）に書き込まれます。要するに、次にコンソールで使用するdbtコマンドはすべてdbt coreに基づいているため、dbt coreをインストールする必要があります。
• dbt Cloud：dbt Cloudはdbt Coreを基盤として構築されたdbtのクラウドサービスです。ホスティングサービスやCI/CDデプロイメント、グラフィカルなユーザーインターフェースを提供し、自分でインフラストラクチャを設定・構築せずに直接プラットフォーム上でdbtモデルを実行できます。後続の文書では個別に「dbt cloud」について説明し、プロジェクトの展開やモデルの定期的な更新を自動化する方法も紹介します。

まずは、「dbt core」について理解しておきましょう。後続の記事では、dbt cloudを使用したデータ開発方法も紹介します。

dbtアダプタとは何ですか？

データ開発にdbt coreを使用する場合、ローカルのdbtとリモートのデータベースを接続する必要があります。そのため、dbt core以外にも非常に重要な概念であるdbtアダプタが存在します。実際、特定のデータベースに接続するためには、対応するdbtアダプタを使用する必要があります。

異なるデータベース間でSQLクエリには若干の差異があることは知っていますが、すべてのデータベース固有の文法を覚えるコストは高く効果も低いです。しかし、dbtアダプタはこの問題を解決してくれます。dbtアダプタの一つの役割は、標準化されたインターフェースを提供し、データベースの互換性に過度に気を使わずにプロジェクトでSQL文を安心して書くことができるようにすることです。

dbtは多くのアダプタを提供しており、dbt公式ウェブサイトがメンテナンスするアダプタ以外にも、コミュニティが自主的にメンテナンスし、dbt公式から認められているアダプタもあります。したがって、ビッグクエリやPostgresなどのデータプラットフォームからMySQLなどのデータベース自体までさまざまなアダプタが利用可能です。 dbtはすべてのアダプタに独立したドキュメントと詳細な設定説明を提供しており、接続するデータベースの種類に応じて対応するアダプタを選択することができます。詳細はabout-core-connectionsを参照してください。

ELTとETLの違いは何ですか？

ELTとETLは、データ分析のための2つの一般的なパターンであり、データ処理の手順において異なる順序を持っています。

ETL：

• 抽出（Extract）： ソースシステムからデータを抽出します。

• 変換（Transform）： 抽出したデータをクリーニング（空値の削除など）、加工、変換します。

• ロード（Load）： 変換されたデータをターゲットシステムにロードします。通常、データウェアハウスにロードされます。

  ETLパターンでは、データは抽出後に一連の複雑な変換操作を経てからターゲットシステムにロードされます。このパターンは、複数のソースからのデータをマージしたり、集計したりするなど、データを複数回または複雑な方法で変換する必要がある場合に適しています。

ELT（Extract, Load, Transform）：

名前の通り、処理順序が異なります。ELTパターンでは、まずデータがターゲットシステムにロードされた後で内部で変換が行われます。このパターンは、目標システムが十分な計算リソースを持っており、元のデータを直接目標システムで処理できる場合に適しています。

両者の違い：

• ETLの利点： ETLは、データがターゲットシステムに到着する前に複雑なデータクリーニングと変換を行う必要がある場合に適しています。これにより、クリーニングと変換のロジックを分離し、ターゲットシステム内のデータ品質を確保できます。
• ELTの利点： ELTは、強力な計算能力を持つクラウドデータウェアハウスなどのシステム（例：bigQuery）に特に適しています。これにより、元のデータを直接目標システムで処理することができ、データ転送の複雑さが減少し、大規模なデータ処理に適しています。

Dbt, bigQuery,およびFivetran の役割

ELT（Extract, Load, Transform）およびETL（Extract, Transform, Load）の概念を理解すると、これらの3つのツールがデータ処理と分析における役割をより良く理解するのに役立ちます。

Fivetran:

• ETLの役割： Fivetranは、さまざまなデータソースからデータを抽出（Extract）し、それらのデータをBigQueryなどのターゲットデータウェアハウスにロード（Load）することが主な役割です。
• 機能： Fivetranは、データ抽出とロードのプロセスを簡素化し、データ準備段階を迅速かつシームレスにします。また、一部のデータ前処理作業も行います。具体的な機能は以下です：
  • データ形式変換： Fivetranは異なるデータソースから取得したデータを処理し、ターゲットデータウェアハウス向けに適切な形式に変換できます。これには、日付形式や数字形式などの調整が含まれる場合があります。
  • スキーママッピング： Fivetranは、ターゲットデータウェアハウスの構造に基づいて、データソースのテーブルとフィールドを対応する構造にマッピングします。
  • 増分同期： Fivetranは通常、変更が発生した部分だけを同期し、データ転送コストを削減します。
  • エラー処理： データロード中に発生する可能性のあるエラーを処理し、データの完全性を確保します。
  • パフォーマンス最適化： データロードのパフォーマンスを最適化して、データが迅速に利用できるようにします。

BigQuery:

• ETLの役割: BigQueryはELTプロセスにおいて、Loadフェーズの役割を果たします。これはクラウドデータウェアハウスであり、読み込まれた元のデータを保存し処理する責任があります。
• 機能: BigQueryは強力な分散型クエリエンジンを提供し、ユーザーが元のデータ上で複雑なSQLクエリや初歩的なデータ分析を実行できるようにします。

dbt:

• ETLの役割: dbtはELTモードまたはETLモードのどちらでも使用することができます。具体的なアーキテクチャ設計に依存します。ELTでは、dbtはデータ変換とモデリングに使用され、通常読み込んだ元のデータ上で実行されます。dbtは他のETLツールと組み合わせて使用することができ、より複雑なデータ変換ロジックを定義および実行するために使用されます。
• 機能： dbtの主な機能は、データモデルを定義および実行し、分析モデルを構築および管理するためのメンテナンス可能でテスト可能な方法を提供することです。

全体のプロセス：

ELTプロセス：

• Extract（Fivetran）：さまざまなデータソースからデータを抽出します。
• Load（FivetranおよびBigQuery）： FivetranはデータをBigQueryに読み込みます。
• Transform（dbt）： dbtを使用してBigQueryで分析モデルを作成および維持します。

ETLプロセス：

• Extract（Fivetran）：さまざまなデータソースからデータを抽出します。
• Transform（dbt等のツール）：dbtや他のETLツールを使用して、データ変換ロジックを定義および実行します。
• Load（BigQuery）：変換されたデータをBigQueryまたは他のデータストレージにロードします。

このELTとETLの組み合わせは、Fivetranの強力なデータローディング機能を活用し、同時にdbtが提供するデータモデリングツールによって柔軟でメンテナンス性の高いデータ処理および分析フローが実現されています。

dbtはデータ変換を担当し、Fivetranもまたそれが可能です。なぜdbtが必要なのですか？

Fivetran：
Fivetranは、主にデータ統合に特化しており、異なるソースからデータをターゲットのデータウェアハウスに転送します。信頼性と効率性の高いデータ移動を重視しています。Fivetranは基本的な前処理機能も提供していますが、複雑なデータ変換やビジネスロジックのための専門ツールではありません。その目標は、データエンジニアが迅速にデータフローを設定・管理できるようにすることです。

dbt：
dbt（data build tool）は、データ変換とモデリングに特化しています。これにより、分析用のより読みやすく使いやすいデータ構造を提供するため、変換と集計をデータウェアハウス内で実行します。dbtでは、分析者がビジネスロジックを定義したり派生フィールドを作成したり集計操作を実行したりすることができ、原始の倉庫データをより理解しやすく、使いやすい形式に変換します。dbtは、データの転送と保存だけでなく、分析者がデータをより良く理解し、使用することをサポートすることが得意です。

総合的に考えると、Fivetranとdbtは協力して働くことができます。Fivetranはデータをソースからデータウェアハウスに移動させる役割を担い、dbtはデータウェアハウス内でさらなる処理やモデリングを行い、複雑なクエリや分析がより容易に行えるようにします。簡単に言えば、Fivetranは基本的なデータのクリーニングや変換のみ提供し、dbtはより専門的かつ強力で自由度の高いデータ変換を提供します。

dbt環境準備（Pythonを例とする）

前提概念について話し終わったので、今から正式にdbtに触れてみましょう。まずは環境設定から始めます。

Pythonバージョンの注意事項

npmがnodeに依存するように、pipコマンドもPythonをインストールする必要があります。バージョンについては、3.8または3.9を推奨しますが、3.10はインストールしないでください。Python 3.10をインストールした後、mysqlアダプターとcoreパッケージのインストールで、バージョン0.19.2のみがインストールできるという問題が発生しています。しかし、coreの最新バージョンは1.1.6まで存在します。これにより、パッケージのバージョン依存性エラーに陥ってしまっています。

dbt coreのインストール

前述したように、dbt coreはdbtのオープンソースコアです。これ以降使用するコマンドはすべてこのパッケージから提供されます。dbt coreをインストールする方法はさまざまですが、公式はpip、docker、homebrewなどをサポートしま。

前述の通りPythonをインストール済みですので、ターミナルで以下のコマンドを実行します：

pip install dbt-core

dbtはデフォルトでグローバルにインストールされるため、プロジェクトパス内でもグローバルインストールに基づいて動作します。インストールが完了したら、次のコマンドを実行してインストールが正常に完了したか確認することができます。

pip show dbt-core

例えば私はバージョン1.1.6のcoreをインストールしました。ここではバージョンやパスなど関連情報が表示されます。

dbtアダプターのインストール

これからすべての作業では、coreとadaptersの2つのパッケージを基にして行われます。実際には、adapterをインストールする際には、関連するcoreパッケージもデフォルトでインストールされるため、1つのコマンドで2つのパッケージが自動的にインストールされます。ここではbigQueryを例に挙げます：

pip install dbt-bigquery

同様に、インストール後は以下のコマンドを使用してバージョンなどの情報を確認できます：

pip show dbt-bigquery

特定の場合には、アダプターのダウンロードコマンドを先に実行すると、自動的にcoreパッケージが一緒にインストールされます。もし個別により新しいバージョンのcoreパッケージをインストールしたい場合は、アンインストールしてから再インストールする方法で行うことができます。例えば、

##　 まずアンインストール
 pip uninstall dbt-core
## 次に特定のバージョンをインストール 
pip install dbt-core==1.1.6

以上がdbtの2つの主要なパッケージです。これら2つのパッケージをインストールするだけで、次に進めるすべての作業がサポートされます。さらに詳しく説明し、それぞれの役割は以下の通りです：

• dbt-core：オープンソースのコアパッケージであり、このパッケージをインストールすることでdbtコマンドを実行できます。
• アダプターパッケージ（dbt-bigquery）：データベースプラットフォームやデータベースの互換性を扱うパッケージであり、異なるデータベース間のコマンドの違いを吸収します。また、対応するデータベースに接続するためには、事前に対応するアダプターをインストールする必要があります。

異なるデータベースに対するアダプターの互換性に関する詳細な情報については、公式ウェブサイトの説明をご覧ください。

DBTプロジェクトの初期化

3.1 コマンドによる初期化

ここまで、皆さんはアダプターとDBTコアをインストールするだけで十分だと思うかもしれませんが、実際にはDBT以外にも、食材やレシピという前述したプロジェクトを準備する必要があります。このプロジェクトではデータモデルを定義し、プロジェクトのターミナルでDBTコマンドを実行することでステップバイステップで料理を作ることができます。

DBTプロジェクトの初期化方法は2つあります。最初の方法は直接コマンドを使用する方法です：

 ## プロジェクトディレクトリ内でコマンドを実行しますその後。
 dbt init

DBTがテンプレートプロジェクトを作成してくれます。仮に、dbtコマンドが存在しないエラーが発生した場合、それはdbt coreパッケージが正しくインストールされていないことを意味します。前述のdbt coreのインストールコマンドを再度実行し、pip show dbt-coreを使用してcoreのバージョン情報を確認してください。

注意すべき点は、私が最初にdbt initコマンドを使用してプロジェクトを初期化した際に、このコマンドは非常に奇妙であり、ルートディレクトリにprofiles.yml設定ファイルを作成します。しかし、プロジェクト自体はこの設定ファイルを使用してデータベースと接続する必要があります。

実際的に考えればわかるように、このような重要な設定はプロジェクトごとに管理されるべきであり、グローバルな設定でもプロジェクト内の設定で上書きされるべきです。しかし私はプロジェクトのルートディレクトリに明示的にprofiles.ymlファイルを作成しましたが、毎回まだルートパスの設定が適用されています。この問題は、私のdbtバージョンと関連している可能性がありますが、現時点ではまだ説明できません。

公式ウェブサイトの説明を参照しましたが、プロジェクトのルートディレクトリの設定が優先されることも確認されています。コンピューターのルートディレクトリの設定はデフォルト設定として機能するだけです。

公式テンプレートプロジェクトを使用する

コマンド以外にも、公式dbtテンプレートプロジェクトを使用することをお勧めします。なぜなら、dbtコマンドにはデータ変換だけでなく、ソースデータをデータベースに書き込むためのコマンドも含まれているからです。一方、initで作成されるテンプレートは基本的なものであり、模擬データや模擬データモデルは含まれていません。すべてをゼロから始める場合には少し難しいです。

したがって、皆さんには公式テンプレートプロジェクト**jaffle_shop** を使用することをお勧めします。GitHubに移動して、git cloneを使用してローカルにダウンロードします。以前にcoreと対応するアダプターをインストールしたため、このプロジェクトを直接使って練習できます。jaffle_shopプロジェクトのもう一つの利点は、initコマンドの手順がないため、上記で述べたようなルートディレクトリの設定作成による問題が発生しないことです。

データベースへの接続

今すべての環境が整ったので、データベースに接続しましょう。ここではbigqueryを例に挙げますので、bigqueryアダプターを使用します。

まずbigqueryはGoogleのデータプラットフォームであり、4種類の接続方法をサポートしています。具体的な接続方法や設定はbigquery setupを参考にしてください。ここでは、 Service Account File を使用して接続します。

profiles.ymlファイルの作成

以前にクローンしたjaffle_shopプロジェクトのルートディレクトリに profiles.yml ファイルを作成する必要があります。以下のコードをファイルに貼り付けてください：

jaffle_shop:
  target: dev
  outputs:
    dev:
      type: bigquery
      method: service-account
      project: demo-data-analytics
      dataset: dev_data_statistics
      threads: 4 # Must be a value of 1 or greater
      keyfile: data-analytics-bef7505.json

設定を説明しましょう

まず、jaffle_shopフィールドは、プロジェクトのルートディレクトリにある dbt_project.yml ファイルのprofile属性フィールドと同じでなければなりません。名前は任意ですが、両方が一致している必要があります。

target： dbtプロジェクト自体にもブランチと環境の違いがあります。現在私たちは学習段階にあるため、ここでは環境をdevと定義するだけで十分です。

type： 使用しているアダプターに対応するデータベースの名前です。私たちはbigqueryを使用しているため、ここにはbigqueryを入力します。

method： bigqueryへの接続方法として Service Account File を選択したため、したがって、ここに service-account を入力します。

project： データベースの最上位コンテナ名です。

dataset： データセット名であり、作成したモデルはこのデータセットに書き込まれます。

threads： dbtタスクの実行時に使用する並行スレッド数を指定します。複数のスレッドを使用すると、dbtパイプラインの実行速度が向上します。ここではデフォルト値として4を設定しています。

keyfile：Googleデータベースへの接続も認証が必要ですが、これは単純にキーの一部です。私のキーもプロジェクトのルートパスに直接配置されているため、そのまま参照すればよいです。bigqueryを使用している場合は、サービスアカウントの作成方法について ドキュメント

接続の確認

設定が完了したら、dbt debug を実行してプロジェクトとデータベースの接続状況を確認できます，例えば。

ここまでくれば、dbtプロジェクトがBigQueryに正常に接続されました（エラーが発生した場合は、前述の設定を確認してください）。

データ開発やデータ分析を行うためには、データベース内に一部のデータが既に存在する必要があります。そして、jaffle_shopではソースファイルとモデルファイルを事前準備しています。現在、次のコマンドを実行します：

## プロジェクト内のscvデータファイルを接続されたデータベースに書き込む
dbt seed

## dbtプロジェクト全体を実行し、データモデリングを開始する
dbt run

完了後、bigqueryに移動してdev_data_statisticsデータセットを見つけると、jaffle_shopで定義されたモデルファイルが表示されます。

注意点としては、dbtが作成したすべてのモデル名はSQLファイル名と同じであることです。これにより、dbtが作成したテーブルやビューを対応付けて検索することが容易になります。

以上で、基本的なdbtプロセスの設定および最初の一連のデータモデルの成功した実行が完了しました。

dbtコマンドの注釈

最後に、いくつかのdbtコマンドの注釈を整理しました。以下は参考になります：

• build：指定された順序でデータロード、データモデル、データスナップショット、およびデータテストを実行します。このコマンドはSQLをコンパイルして対応する操作を実行し、データウェアハウスを構築します。
  • buildにはseed、run、test、snapshotが含まれています。つまり元のデータをデータベースに追加し、モデルに基づいてビューとテストケースを生成することです。
• clean：指定したフォルダーを削除します。通常は生成されたファイルやフォルダーのクリーンアップに使用されます。
• clone：ノードの複製を作成し、プロジェクト内でノードの複製と再利用が可能です。このコマンドは似たようなデータモデルを素早く作成するのに役立ちます。
• compile：dbtプロジェクトのコードを実行可能なSQL文に変換します。このコマンドは、コードが正しいかどうかをチェックおよび検証するのに役立ちます。
• debug：現在のdbt環境と設定情報（前述したもの）を表示します。このコマンドは、現在のdbtの設定と環境変数を理解するために役立ちます。
• deps：プロジェクトで使用されている依存関係を更新し、最新バージョンの依存ライブラリを取得します（後続記事で説明します）。
• docs：プロジェクトのドキュメントウェブサイトを生成または提供します。このコマンドは、他の人がデータモデルや操作方法を理解するために、プロジェクトのドキュメントを生成および表示することができます。
• init：新しいdbtプロジェクトを初期化します。このコマンドは新しいdbtプロジェクトを作成し、必要なファイルとディレクトリ構造も生成します。
• list：プロジェクト内のリソース（データモデル、テーブル、ビューなど）を一覧表示します。このコマンドはプロジェクト内のすべてのリソースを確認するために使用されます。
• parse：プロジェクトを解析し、パフォーマンスに関する情報を提供します。このコマンドはプロジェクトの構造とパフォーマンスを理解し、最適化するために使用されます。
• retry：前回失敗したノードを再実行します。このコマンドは失敗したデータモデルや操作を再実行してエラーを解決するために使用されます。
• run：指定したデータモデルや操作のSQL文をコンパイルして実行します。このコマンドはdbtプロジェクト内のデータモデルや操作を実行して、データウェアハウスを構築するために使用されます。
  • seedとrunの違い:
    • seedの主な目的は元々静的なデータ（raw data） を読み込むことです。これらのデータは通常、頻繁に変更する必要はありません。例えば、国のリストや製品カテゴリなどです。seed はこれらの静的データをデータベースにロードし、後続の分析や変換に基礎となるデータを提供します。
    • run の主な目的は、データモデルを実行することです。SQLクエリと変換ロジックを実行して新しいテーブル、ビュー、または他のデータ構造を生成します。これらのモデルは、seed でインポートされたデータに依存する場合もありますし、他のモデルが生成したデータに依存する場合もあります。
  • 特定のモデルだけを実行したい場合がありますが、--model オプションを使用して特定のモデルを実行できます。例えば dbt run --models model_name や dbt run --models model1, model2, ...
  • ときどき環境を区別するためにコマンドを使用したい場合があります。例えば、 dbt run --target devやprodのようなものです。
• run-operation：指定されたマクロ（macro）を実行し、任意の引数を渡します。このコマンドはカスタムマクロを実行して特定のデータ処理ロジックを実現するのに役立ちます。`
• seed：CSVファイルからデータウェアハウスにデータを読み込みます。このコマンドはデータウェアハウスにデータを読み込んで後続のデータモデルで使用するためのものです。`
• show：指定されたデータモデルまたは操作用に実行可能なSQL文を生成します。このコマンドは指定されたデータモデルや操作のSQLコードを確認する際に役立ちます。`
• snapshot：プロジェクトで定義されているデータスナップショット操作を実行します。 このコマンドは、dbtプロジェクトで定義されたデータスナップショット操作を実行し、データの履歴状態をキャプチャします。
• source：プロジェクトのデータソースを管理します。このコマンドは、異なるデータソースからデータを抽出するために、プロジェクト内のデータソースを追加、設定、および管理するのに役立ちます。`
• test：このコマンドは展開済みのデータモデルでデータテストを実行して、データの正確性と一貫性を確認するために使用されます。基本的な目的：
  • データの正確性、完全性、および一貫性の検証
  • データ変換ロジックが正しいかどうかの検証 -
  • データ間の関係と制約条件の検証

例を挙げます：

models:
  - name: my_model
    tests:
      - my_test:
          severity: error
          description: "Check if column X contains null values"
          check: "select count(*) from {{ ref('my_model') }} where X is null"
          expect: "select 0"

上記の例では、my_testはテストケースの名前であり、my_modelはモデルの名前です。 checkクエリでは、モデルを参照するために {{ ref('my_model') }} を使用し、その後、モデルの列 X に空値が含まれているかどうかをチェックします。

おわりに

次回の記事では、dbt coreの高度な使用方法について学びます。例えば、テストと本番環境を区別する方法や、同じモデルを異なる環境に書き込んで期待されるデータセットを作成する方法、さらに高度なdbtコマンドや詳細なdbt設定について理解していただけます，お楽しみにしてください。

創作チーム

作者：Echo

校閲：Lila、Yuki