データ加工パイプラインに用いる dbt

estie のデータマネジメント部でソフトウェアエンジニアをしている @Ryosuke839 です。

ツール導入前の課題

estieでは、不動産の物件や募集情報を50社以上の不動産デベロッパー、管理会社、仲介会社等から取得し、匿名化や名寄せなどの処理を行ったうえでプロダクトで用いるデータを生成するデータパイプラインを構築しています。

2023 年にはデータパイプラインのデータ置き場として Snowflake を導入しました。(blog post) しかしこの段階ではデータ移送を Python スクリプトで行っており、左から右にデータを流すだけでもクラスを書きタスクを定義し…という作業が必要になっていました。ちょうどプロダクトがたくさん生まれる時期とも重なり、チームの仕事をスケールさせる障壁にもなっていました。 一方データパイプラインでは複雑なデータ加工を行う処理も混在しており、一般的に Snowflake や dbt が活用される分析基盤よりも実行できる処理に高い自由度を必要としていました。 また、Snowflake で強制されなくなったテーブル間の関係のテストは宙に浮いたままになっており、データパイプラインとしては重要な一貫性の保証ができない状態となっていました。

どのような状態を目指していたか

• シンプルなデータ移送が簡潔に書ける
• 名寄せなどの複雑な処理でも記述できる
• データモデルにテストを付随させられる

以上を満たしたツールを必要としていました。

改善したかった課題はどれくらい解決されたか

当初の目的であるシンプルな移送処理の置き換えやテストの追加はすんなり解決されました。 一方複雑なモデルについては、導入初期は循環参照があるなど dbt に置き換えられる処理は多くはなかったのですが、処理の側を dbt で表現できる形に沿わせていくことで置き換えが進み、さらに処理がシンプルになるという成果を得られました。

どのような成果が得られたか

• シンプルな処理を実装する際の速度が上がった
• （副次的に）dbt で記述できるよう処理を見直すことでパイプラインがシンプルになった
• パイプライン全体のリネージが自動生成されるようになり、運用時の調査などが楽になった
• data test や model contract といったテストによって信頼性を担保できるようになった

dbt SQL model では表現できないような複雑な処理には dbt Python model を使うことになりますが、dbt Python model を使いこなすにはデータウェアハウス製品ごとの Python 実装にあわせた実装を行う必要があります。しかし、そもそも dbt で複雑なデータパイプラインを実装するユースケースが少ないようで、dbt Python model についての知見は限られています。

estie では dbt Python model を用いる際の知見をブログで公開していますのでぜひご覧ください: blog post blog post