はじめに
dbtを利用し始めて日の浅い筆者ですが、SELECT文さえ扱えれば誰でも簡単にデータを加工することができ、さらにモデル同士の関係性をグラフィカルに出力することができる手軽さに魅力を感じ、日々勉強をしております。
そんな中、dbtで設計したモデルのUT/IT実施時に詰まったところとその解決にprehookとposthookを使った方法を検討したため、ご紹介します。
prehookとposthookを使ってUT/ITのセットアップを効率化
prehook/posthookとは
dbtには、general configという様々なオブジェクトレベルで設定することができるパラメータがあり、その中の1つがprehook/posthookです。モデル単位、シード単位、スナップショットの単位で設定することができ、それぞれの処理を実行する前（prehook）あるいは実行した後（posthook）に、指定したSQLを実行することができます。
models:
<resource-path>:
+pre-hook: SQL-statement | [SQL-statement]
+post-hook: SQL-statement | [SQL-statement]
dbtでのUT/IT試験
下図のようにソースデータ（tpch.orders,tpch.lineitem）からデータマート（fct_orders）を作るケースでアプリ観点のUT/ITについて考えます。
UTやITではそれぞれの加工処理が正しいロジックになっていることを確認するため、期待値比較テストを実施すると思います。その期待値比較ではテストデータのセットアップから加工処理の実行および期待値との比較を行うため、工数を抑えて実施するには極力手間を省く工夫が必要になります。
しかし、dbtでは同じテーブル名を作る定義は実装できないため、テストデータを定義したシードでインプットテーブルに挿入することや、ソーステーブルを構築するモデルにテストデータを取り込むSQLを定義して実行するなどの方法を取ることはできません。
dbtと接続しているDB製品に直接ログインしてデータのセットアップをすることは可能ですが、dbtのテストのために別のサービスにログインする必要があるのは非常に面倒ですよね。
そこで、我々はprehookとposthookを使うことで、dbtだけで効率的にセットアップを行うことができるようにしました。
prehook/posthookによるテストセットアップ
我々が実装したセットアップ機能は下記の4stepを1つのテストセットアップ用モデルで定義することにより実現します。Model定義の例とセットアップのイメージは下記のとおりです。
{{ config(
--① 試験対象の加工処理がインプットとしているテーブルのレコードを削除
pre_hook="truncate {{ref('stg_tpch_orders')}};",
post_hook=[
--③ 試験対象の加工処理がインプットとしているテーブルに②のデータを挿入
"insert into {{ref('stg_tpch_orders')}} select * from {{this}};",
--④ ②で構築したテーブルを削除
"drop view {{this}};"
]
)}}
--② テストデータをテストセットアップ用モデルに挿入
select 1, 2, 'A', 1.1, '2024-12-20', 'B', 'C', 0, 'ABC' from dual
union all
select 2, 3, 'B', 2.2, '2024-12-21', 'C', 'D', 1, 'BCD' from dual
① 試験対象の加工処理がインプットとしているテーブルのレコードを削除（prehook）
② テストデータをテストセットアップ用モデルに挿入
③ 試験対象の加工処理がインプットとしているテーブルに②のデータを挿入（posthook）
④ ②で構築したテーブルを削除（posthook）
1つのモデルファイルに上記の4ステップを詰め込むことで、加工処理1つ1つに対して1つのセットアップ用モデルファイルを用意するだけでセットアップができるようになり、テスト準備に利用した中間テーブルなどのごみ掃除もすることができます。
ITの場合も同様にDAGの1つ目のテーブルをセットアップすることで簡単に試験準備を整えることができるため、UTからITまで統一的な仕組み試験環境を作ることができます。
Appendix
prehook/posthookのその他の使い道
prehookとposthookは、接続しているDB製品で利用できるSQLであれば発行することができるため、かなり自由度高く利用することができます。
例えば、Snowflakeであればdbtが利用しているセッション単位でパラメータを変更する「alter session」コマンドが利用できるため、dbtでの利用時のみウェアハウスのタイムアウト時間を設定することで、予期せぬコスト消費を防止することができます。
dbt unit tests
dbtではunit testsという単体テスト用の機能が存在しています。
unit testsはその名のとおり、モデルの単体テスト単位で設定するものであるため、ソースデータから複数の加工処理を経て更新された最終のターゲットテーブルの期待値比較するようなITレベルには向かないため、今回のような手法を検討しました。
unit testsは現在進行形で改良が重ねられている機能であるため、今後の動向を追っていきたいと思っています。
おわりに
今回はprehook,posthookを使ったUT/ITの効率化手法についてご紹介しました。
ご紹介した使い方以外にもさまざまな使い方ができますし、dbtにはその他にも様々なGeneral Configが存在しているため、ぜひ皆さんも利用してみてください。
筆者紹介
筆者はこれまでSnowflakeオンリーでデータパイプラインを構築するなどの経験をしてきて、さまざま苦労してきました。その経験もありデータパイプラインの構築を楽にできるdbtにかねてから魅力を感じており、日々勉強をしています。
今後もdbtでの開発を楽にできるようなTIPSを考えて発信していこうと思います。
仲間募集
NTTデータ テクノロジーコンサルティング事業本部 では、以下の職種を募集しています。
- クラウド技術を活用したデータ分析プラットフォームの開発・構築(ITアーキテクト/クラウドエンジニア)
- データサイエンス領域（データサイエンティスト／データアナリスト）
3.お客様のAI活用の成功を推進するAIサクセスマネージャー
4.DX／デジタルサクセスを推進するデータサイエンティスト《管理職/管理職候補》
ソリューション紹介
https://enterprise-aiiot.nttdata.com/tdf/
最新のクラウド技術を採用して弊社が独自に設計したリファレンスアーキテクチャ（Datalake+DWH+AI/BI）を顧客要件に合わせてカスタマイズして提供します。
可視化、機械学習、DeepLearningなどデータ資産を分析活用するための環境がオールインワンで用意されており、これまでとは別次元の量と質のデータを用いてアジリティ高くDX推進を実現できます。Trusted Data Foundationについて
https://enterprise-aiiot.nttdata.com/service/tdf/tdf_am
TDFⓇ-AMは、データ活用をQuickに始めることができ、データ活用の成熟度に応じて段階的に環境を拡張します。プラットフォームの保守運用はNTTデータが一括で実施し、お客様は成果創出に専念することが可能です。また、日々最新のテクノロジーをキャッチアップし、常に活用しやすい環境を提供します。なお、ご要望に応じて上流のコンサルティングフェーズからAI/BIなどのデータ活用支援に至るまで、End to Endで課題解決に向けて伴走することも可能です。TDFⓇ-AM（Trusted Data Foundation - Analytics Managed Service）について
https://enterprise-aiiot.nttdata.com/service/snowflakeNTTデータとSnowflakeについて
https://enterprise-aiiot.nttdata.com/service/informaticaNTTデータとInformaticaについて
NTTデータとDatabricksについて
https://enterprise-aiiot.nttdata.com/service/tableauNTTデータとTableauについて
https://enterprise-aiiot.nttdata.com/service/alteryxNTTデータとAlteryxについて
https://enterprise-aiiot.nttdata.com/service/datarobot