🕌

dbt Labs + AWS共催のワークショップを学ぶ

2022/12/25に公開

AWS

データ分析

dbt

tech

dbt Advent Calendar 2022 DAY 18です。
＊カレンダーが空いていたので「代わりに投稿」で作成しました

dbt: getting startedを教材とするのも良いですが、（私の場合）多少はAWSに詳しい人に向いているデータセットがあれば助かるなーと探していたらaws-samples/aws-modernization-with-dbtlabsを発見しました。

ハンズオン資料はAWSから公開されていますが、今回はワークショップ概要を紹介しつつ、気になったdbt諸機能やAWSサービスとの連携をまとめます。

ワークショップ前提

GitHubでカラのPublicリポジトリを新規作成
AWS CloudFormationによる必要リソース構築
dbt Cloudアカウント
- 機能は少し限定されるが1人で使う分には無料

ワークショップ概要

dbtを初めて触る人間でも最後まで完了してdbtの雰囲気を味わえたのでお得でした。ハンズオン資料のコードスニペットではインデントが所々崩れていたり、ファイル名の誤植があったり、理解度を試されているのかなーと思う箇所が2,3あったので座学だけでは刺激が足りたい人にもぴったりだと思います。

サンプルデータセット

TPC-Hのデータを使っています。私は今までベンチマークの文脈でしかTPCを知りませんでした。

作成するデータモデル

最終的にはこの形で終わりました、

dbtではLineage Graphと呼ばれるDAGの一種らしいです。作成したモデル間の依存関係を表す図をdbtは自動生成してくれる機能があり、dbtCloudでもdbt coreでも同様にグラフ生成できるため最高でした。

dbtのモデルデータ保存先

これは最初に浮かんだ疑問でしたが、ソース指定したDWHにdbt用のスキーマを追加してテーブルとして保存します。dbtはELTの"T"領域のツールなので何かのDWHにデータロード済みの状態が出発地点となることが仕様でした。

dbtプロジェクトのディレクトリ構成

ワークショップでは主にmodels/配下を触るだけですが、ディレクトリ構成に関してはdbtでも解説しています。
How we structure our dbt projects
Best practices: How we use the other folders

学習し始めには、まずはdbt initに沿った基本構成にならうのが良さそうです。ちなみにdbtブログではGitLab Data Teamを好事例として言及しています、かなり巨大ですがテクニックを深掘りしたい場合は良いかも。

公開リポジトリを見る限り、GitLabの規模でもtestsディレクトリを使っていなかった(Genericテストのみ使っている)ため、テストに強いというdbtの評判を見た気がします。
dbt: Tests

dbtの何がテストに強いのか？

YAMLでソースのDWHや変換するモデルデータを定義しますが、その際にtests:で制約を記述できます。dbt testをCI/CDで自動実行することで不正データがパイプラインに混ざることを防げます。

CI/CDではdbtをどう扱う？

dbtのCLIでは必要なコマンドは一通り提供されるため、それらをイベント駆動やスケジュール駆動で実行おすることが想定されます。
dbt Command reference

dbtCloudではプロジェクトをオンラインエディタで操作できる以外にもジョブ機能やGitHubとの統合も提供されているため、このまま使うならdbtCloudで完結するかもしれません（$100 / seat）。

スモールスタートするなら、コンテナや各言語の仮想環境を使ってdbt実行環境をつくるのが良いかなという感触です。

Appendix;

ワークショップは一時中断（CFnスタックを削除&再構築）しても大丈夫

自分の時間都合で途中でAWSリソースを全て削除&再構築しましたが、それでもdbtの接続情報(profile.yml相当)を新規スタックに合わせて更新すれば、dbtは正常に動作し続けました。

dbt_external_tables

AWS Glueがスキーマ管理するRedshift Spectrumが外部テーブルに相当するため、dbtからRedshiftに接続可能であればS3データをRedshiftにステージングする動きをします。これはTransformというよりLoad。

YAMLのモデル定義におけるインデントミス

"mapping values are not allowed in this context"が発生します。
StackOverflowでも質問を見かけましたがインデント起因の可能性が高そう...

モデル生成のSQLは記号も厳密に

クエリを記述する際に途中のカンマを忘れると"syntax error at or near"が発生します(JSONのようにあっても無くてもOKとはいかない)。"Database Error in ~~"とエラ〜メッセージで対象ファイルと該当箇所を教えてくれる私はこの記述ミスに気づくために30分近くかかりました...

`dbt run -m state:modified+`

何度かコミットを繰り返しているとGot a state selector method, but no comparison manifestのエラーを解消できなくなりました。

dbt runは正常終了するためビルド差分が過少評価されていることが原因らしく、dbtのドキュメントにも「dbtはあまり多くのモデルを実行しないようにします（つまり、偽陽性）」と説明されているため、テクニックが必要になる。

終わりに

実運用ではワークアラウンドなども対処が必要なので、dbtは強力さの代わりに一定の学習コストは求められますが、スモールスタートもしやすいと実感できました。データパイプラインをIaC管理する場合の解が1つの仕様になっていて、為になるツールでした。

参考情報を調べていると、2020年頃から流行っている印象なので現在では相当数の記事が出てきました。データ分析のパイプラインで使うツールの選択肢も色々あるので、BIツールと一緒にCI/CDを設計するのは必須ですね。
Automation and Continuous Delivery with Snowflake using dbt

個人的にはモデリングに関して知らない事ばかりですが、UMLとは違う目的でデータ設計する視点が面白かったです。
Ralph Kimballのディメンショナルモデリング