dbtでスタブテストをできるようにデータ管理を工夫した話し

 

この記事は10Xのアドベントカレンダーです

この記事は10X アドベントカレンダー2022、16日目の投稿は10Xのデータプロダクトエンジニアの瀧本です。
好きなスーパーはライフ。最近のお気に入りはライフプレミアム 厳選素材果実畑 福岡県産あまおう苺ジャムです。たっぷりないちご果実なジャムで大満足です。
地元山梨のオギノも好きで、特に惣菜が絶品です。毎週のようにイカの唐揚げを買っています。

サマリ

  • dbtにはパッケージでdbt-datamocktoolと呼ばれるモデル処理時にrefを任意に切り替えて実行し、実行結果を特定のモデルのデータと比較して評価テストしてくれるパッケージが存在
  • ただしスタブデータと評価用データを作って管理するのが既存のdbtだとseed等を使うしかないが、seedだとデータ型を管理するのが面倒くさい(yamlで管理する必要あり)
  • スプレッドシートで管理したサンプルデータをモデルのSQLクエリとして書き出してくれるツールを実装した

dbt-datamocktoolとは?

dbt-datamocktool(略称dmt)を使うことでモデルが使用するソースやrefの代わりとなるテーブルデータを定義した上で、モデルの処理をする際に用意した別のデータで処理されるように切り替え、モデルが出力すべき期待するデータになっているのかをテストすることが出来ます。
 
詳しくは以下を御覧ください。

データを準備して、管理運用する難しさ

ワンショットで利用をする場合はあまり気にならないですが、ロジックの検証等を継続的に評価をしたい等、将来的な修正の要件に耐えられそうかが重要です。
 
dbt-datamocktoolの設定は以下のように設定します。
 
その上で「参照用のデータ(input_mapping)」と「出力期待用のデータ(exptected_output)」の2つを用意する必要があります。以下の方式でデータは用意できますが、メリットデメリットがあります。
 
seedは一見良いアプローチに見えます。ただしseedを単純に使ってしまうと、データカラムのデータ型が自動解釈され、データ型がコントロールできなくなってしまいます。
それを回避するためにyamlでseed用のデータのカラム名を制約できるのですが、これがひとくせあり、yamlで定義する必要があります。
これがやっかいで、実際のcsvデータとも違う場所で別途定義する必要があり、データを管理更新していくオペレーションとは違うところに存在する状態になり、管理のしづらさを考え、最終的にはモデル(table or view)でいくことにしました。
 
ただモデルを選択すると必然的にSQLクエリでデータを定義する必要があり、毎回手作業で作るのは大変です。

そこで考えたMockuraというツール

Mockraは社内で動いている、スプレッドシートのデータをベースにスタブ用のデータを作るツールです。
このツールを使うと以下のような流れでスタブ用のデータが作成可能です。
  • スプレッドシートにスタブ用のデータを定義
  • Mockuraでスタブ用のデータを出力する
  • 出力されたSQLをモデルとして定義する

スプレッドシートにスタブ用のデータを定義

まずはスプレッドシートに以下のようなフォーマットでデータを定義します。
  • 1行目:カラム名
  • 2行目:データ型
  • 3行目以降:実際のデータ
 

Mockuraでスタブ用のデータを出力する

Mockuraのツールにアクセスし、スプレッドシートのURLを入力し、読み込みます。
 
出力したいシート名を選択すると以下のようなクエリが生成されます。
 

出力されたSQLをモデルとして定義する

先程のSQLクエリをモデルとして定義します。
実際に実行してみると以下のようなテーブルになります。
 
 
あとは作成したモデルをdbt-datamocktoolのモデルとして定義すればOKです。
この方式だとデータカラム定義やデータの増分も差分としてレビューが可能になります。

採用募集しています

10Xが作るチェンストアECのプラットフォーム「Stailer」にとって重要なデータプロダクトを一緒に作ってくれるメンバーを募集中です。