記録帳

クラウド、データ分析、ウイスキーなど。

楽にデータエンジニアリングのレベルを上げてくれるツール、dbtを触ってみた

みなさんおばんどす。夏真っ盛りのお盆ですが、皆さんいかがお過ごしでしょうか。
最近TLなどで、良くdbtというツールを目にします。
データ変換の品質を高める、などという枕詞でよく紹介されていますが、結局のところ何ができるのか?に興味がわいたので、触ってみました。
今回は、dbtの前にそもそもデータエンジニアリングって何だろう?というところから、このdbtについて、さらにはどんな人が使えるのかを考えてみました。

データエンジニアリングってなんだ?

データ分析に少しでも興味ある人なら、聞いたことがあるかもしれません。
「あぁ~、データ加工するETL処理を作ったり、データサイエンティストが欲しいデータをいろんなところから集めたり、ちょっとレベル高くなるとデータカタログ導入したり、データ変換処理のパイプラインを作ったり、ともかくデータを整理する人でしょ?」
と、こんなイメージだと思います。(これでもめっちゃ詳しい人な感じがする)

ただ、ビシッと定義するとなるとその正解はどこにも載っていません。
おそらく、「データエンジニアリングをしよう!」と決めてから誰かがやり始めたというよりは、データ分析をしていくうえでこの部分をやる必要が出てきて、後から名前が付いたからかなと思います。
そこで、まずはデータエンジニアリングとは何か?を簡単に考えてみようと思います。

手掛かりは「エンジニアリング」という言葉。エンジニアリング組織論への招待では、エンジニアリングをソフトウェアについて当てはめたとき、このように述べています。

ソフトウェアにおいても同じことがいえます。それは誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく家庭が実現で、その過程のすべてがエンジニアリングという行為です。
つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。

広木 大地『エンジニアリング組織論への招待』(技術評論社、2018年3月8日初版5刷発行)p.11

つまり、データエンジニアリングは、データにおいて「曖昧さ」を減らし、「具体性・明確さ」を増やす行為だと言えそうです。
データにおける曖昧さとは、私が考えうる限りだと
・日々変化していくデータ
・口頭伝承されていくテーブル、カラムの意味
・誰が作ったか分からない加工済みのテーブル
・ソース元不明のマスタデータ
などがありそうです。これらを減らして、具体性・明確さを増やす行為が、データエンジニアリングなのではないでしょうか。

私が触った限りだと、dbtは上記の曖昧さを「必要最低限の労力で」具体的にするツールだと思いました。
そこで、タイトルのような紹介をしたというわけです。

dbtとは?

DWHに格納されているデータを加工したいとき、SQLを書くと思います。
そのSQLを書くのを支援し、かつそのSQLで出来たテーブルのテストをし、かつカタログ的な機能(カラムにコメントや、SQLを自動で読み込んでリネージ)もあるツールです。
ただし、エンジンを持つDWH(SnowflakeやBigQueryなど)を使っていることが前提です。SQLを実際に動かすエンジンは、dbtではなくDWH側となります。
どの場所を担うかは、以下の図が分かりやすいです。

f:id:supa25:20210810230630p:plain
dbt

What, exactly, is dbt?より引用。

いつもはDWH側で書いていたSQLを、代わりにこのdbt上で書くというイメージです。
CUI版とGUI版があり、CUI版はOSSとして無料で使えます。GUI版は1人で使う分には無料ですが、チームやエンタープライズとして使うと有料です。
(1人だと無料なので、試しに動かしてみるのはデモやトライアルではなく通常版でずっと使えます)

dbtを導入した時の作業イメージ

SQLを書いて加工後データを作成する

これは、dbtを導入しなくてもやる行為です。
ただ、dbtでやることによって、よく使うSQLをマクロとして保存して使えたり、PythonのライブラリであるJinjaが使えたりします。

とりあえず、自分でSnowflakeと接続して、SQLを書いてみました。

f:id:supa25:20210810232315p:plain
sql

これは、購買履歴テーブルに顧客マスタをjoinして、顧客の年代別に売り上げの集計をしたテーブルです。
ここで注目してほしいのは、改行とかインデントとかが汚いところではなく、INNER JOINの次のref( )式です。
このref内のcustomer_masterは、dbt内で定義しているテーブル名です。つまり、実際のSnowflakeのテーブル名は知らずとも、dbt内で定義しているテーブル名を知っていればSQLが書けるということです。
これによって、元のテーブルが変わってもdbt内で定義しなおせば影響を受けないというメリットのほか、あとで紹介するリネージ機能にも使われます。

このSQLをdbt上で実行すると、裏でSnowflakeのエンジン(ウェアハウス)が実行され、以下のようにSnowflake側にテーブルができています。

f:id:supa25:20210810232920p:plain
snowflake

テストを書いてチェックする

テストをyamlファイルで簡単に定義できます。

f:id:supa25:20210810233223p:plain
yaml

5行目と14行目から、それぞれ別のテーブルに対するテストを定義しています。
先ほど見せたテーブルは14行目以降です。
テストとは関係ないですが、15行目のようにdescriptionにコメントを書いておけば、あとでドキュメントに反映されます。
17行目からは、カラム名「AGES」のテストです。
testsに「not_null」を指定することで、このカラムにnullが入らないことを定義しています。
また、「accepted_values」を指定することで、22行目に記載された値しかそのカラムが取らないことを定義しています。
ここは年代のカラムなので、0から90の10刻みの値しかとりません。
そのほかにも、そのカラムの値がユニーク値を取るかどうかのテストができます。
それ以外のテストは、自身で定義する必要があります。詳しくは以下の公式docに詳しく乗っています。
Tests | dbt Docs

さて、上記のyamlファイルを作成して、テストコマンドを実行すると実際にテストします。

f:id:supa25:20210810233932p:plain
test結果

今回は2つのカラムに対して3つのテストをして、全てOKだという結果になりました。
自動化もできるので、日次で更新される元データに対して、SQLとテストを実行すればデータに対して自動テスト実行が可能です。

dbtを導入して得られるメリット

データに対するテストを実行できる

やはりメインはこれですね。
ユニークチェック、Null値チェック、具体的な値のチェックであればyamlファイルに1行書けばできてしまうので、かなり楽です。
今回はやっていませんが、テスト内容も独自定義できるので、よくやるテストは一度書けば再利用可能です。

ETL処理の再利用というのは、意外となかなかハマらないことが多い(それぞれやりたいことが違うため)ですが、個人の経験上データに対するテストは大体同じことをやっています。
そのため、テスト処理の再利用は効果的であると思いました。

ドキュメントが自動作成される

これもかなり良いと思います。
先ほどのyamlファイルで、テーブルやカラムに対してdescriptionを記載しました。それを自動で拾ってドキュメンテーションしてくれます。

f:id:supa25:20210810234919p:plain
doc

テーブル、カラムのコメントが反映されているのが分かります。
また、カラムの型はSnowflake側の定義から勝手にとってきてます。
実行しているテストも書いてあるので、どんな品質チェックを受けてるかも確認できます。
ここでは見えていませんが、このテーブルを作成しているSQLもわかるため、なにか自分の分析に不都合な処理がされていないかも確認できます。

このドキュメントで私がすごいと思ったのは、リネージ機能です。
先ほどのdoc画面の右下の青いボタンをぽちっと押すと、リネージ画面が出てきます。

f:id:supa25:20210810235220p:plain
リネージ

これは、SQLの中のref文を拾ってグラフにしてます。
現時点では2つしかないので寂しい感じですが、実際の現場では複数のテーブルが参照されまくっているはずなので、大きな地図ができるはずです。
ここまでの機能で、ほぼデータカタログツールの代わりになります。

SQLyamlファイルの構成管理ができる

最近のツールは組み込まれていることが多いですね。Looker然り。
画面上に「commit」ボタンがあるため、変更があればすぐにコミットできてしまいます。

また、この記事を見ると、commitしたときに、自動でSQLを実行、かつtestも実行して、OKならマージするというCI構成も簡単にできるそうです。すごい。
[dbt] CI(継続的インテグレーション)を取り入れる | DevelopersIO

どんな人に向いているか?

私がdbtの利用に向いていると思うのは

クラウド型DWH(SnowflakeやBigQuery)を利用している
AND
(運用中のETLパイプラインが増えてきて、日々の障害が出始めてきたデータエンジニア
OR
人が増えてきて、そろそろ全員の分析に使うデータを見切れなくなってきたチーフデータサイエンティスト)

です。
ここまで紹介した通り、dbtはSQLを書く作業自体がめちゃくちゃ楽になるわけではありません。(マクロやJinjaで楽に書けるようにはなりそうだけど)
そのため、「いつも書いてるSQLをもっと楽にかきたいぜ!」という人には向きません。
逆に、テストやドキュメント化はかなり楽に行えるため、データや人が増えてガバナンスを効かせたくなっている人に向いています。

ここで、データや人が増えるとはどういうことかを今一度考えてみると、結局は「不確実性が増える」ということではないでしょうか。
dbtに限らず、データや人が増えると不確実性が増えるため、何かしらの対策を講じないといけなくなります。
その対策がデータエンジニアリングであり、それを楽に行えるのがこのdbtというツールであると私は思います。

まとめ

・dbtは、楽にデータエンジニアリングのレベルを上げてくれるツールである。
・実際は、DWHで書いていたSQLをdbt上で書くことになる。
・その際にyamlファイルでテストを簡単に定義して実行できる。
メタデータを自動で吸い上げてドキュメント化してくれる。特に、テーブル同士のリネージ機能がすごい。
クラウド型DWHを使っていて、人やデータが増えてきた組織への適用が向いている。

以上!