株式会社タイミーのdbt導入事例
株式会社タイミー / Tsuchikawa
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
Enterprise | 11名〜50名 | 2021年10月 | B to B B to C |
利用プラン | Enterprise |
---|---|
ツールの利用規模 | 11名〜50名 |
ツールの利用開始時期 | 2021年10月 |
事業形態 | B to B B to C |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
当時、社内の様々なデータをEmbulkを中心に用いて、ETL(抽出→変換→ロード)の順番でBigQueryに転送していました。しかし、データの規模やチームが大きくなるにつれ変換処理の要件が増加し、以下の3つの課題が発生しました。
変換処理工数の増加による可用性の低下
当初は軽いマスキングなどのデータ変換のみでしたが、データ量や種類が増えるにつれ、Embulkの変換処理(T処理)にかかる時間が増加し、コードの書き換え頻度も多くなりました。その結果、データ転送の遅れや停止が頻発しました。データソースごとの変換処理による開発・管理コストの増加
元々はEmbulkのみを使ってデータ転送を行っていましたが、分析対象のデータソースが増えるにつれ、それぞれに適切なデータ転送ツールを選択する必要が生じました。 Embulk以外の転送ツールを用いることで、変換処理がデータソースごとにバラバラになり、タイムゾーンの統一など同じ処理を複数の場所で行う必要があり、これが開発・管理コストの増加につながりました。また、スタースキーマなどのモデリングも必要となり、マスキングやモデリングなどのデータ変換を統合する必要がありました。変換処理の複雑さ・不透明さによる開発生産性の低下
変換処理はEmbulkのコードで管理されていたため、分析を行うアナリストやデータ活用メンバーから変換処理内容について問い合わせが増加していました。EmbulkのコードはSQLに慣れているメンバーにとってキャッチアップしづらいものでした。また、変換処理を実装するメンバーも抽出やロードのコードと同じ場所で実装をするため、変換処理が複雑になるにつれて実装コストが上がりました。
どのような状態を目指していたか
これらの課題を解決するために、変換処理をEmbulkから切り離し、ロードの後に変換処理を行うことで、ELTの順番で転送し、変換処理を独立して実装・実行できる構成を目指しました。これにより、変換処理の実装がスケールし、品質を高く保守できる状態を目指しました。
比較検討したサービス
- dbt Cloud (core)
- Dataform
- cloud dataflow
- data fusion
- Panoply
比較した軸
- データ変換を複数stepで行うため、DAG構成が組めるかどうか
- 導入時は2人チームだったため、運用・導入コストが高くないか
- その他の要件(事例の豊富さ、機能の多様さ、将来性、価格 など)
選定理由
DAG構成やインフラの運用コストの観点から、dbt CloudとDataformに絞りました。dbt CloudはDataformに比べ価格は高かったものの、リネージュなどの機能が豊富で、コミュニティも大きく事例も豊富でした。そのため、比較要件の優先度からdbt Cloudを選定しました。
導入の成果
改善したかった課題はどれくらい解決されたか
dbt Cloudを導入することで、マネージドなインフラ環境でデータ変換処理を迅速にEmbulkから移行できました。これにより、dbt CloudでDAG構成を組むことで複雑なデータ変換処理が可能となり、複雑なデータモデリングの実装が実現しました。dbt Cloud内でのテスト記述や様々なメトリクスの監視ができるため、ジョブ管理や保守が容易になり、データの品質も向上しました。コードはSQLベースで書かれているため、アナリティクスの一部のメンバーも変換処理やモデリングに参加できました。
また、dbtの機能を活用することで、様々なデータ活用体験やデータ品質の向上が実現しました。
- Explore機能を用いて、リネージュをデータチームに広く公開し、変換処理実装や分析がしやすくなりました。
- Exposure機能を用いてダッシュボードなどのアウトプット管理ができ、データのライフサイクル管理が容易になりました。
【参考】https://tech.timee.co.jp/entry/2024/03/18/110548 - Elementary機能を用いてデータオブザーバビリティを実現し、障害対応や保守が容易になり、データ品質の向上が図れました。
【参考】https://qiita.com/marufeuille/items/10a0350e529426e6bb26
導入時の苦労・悩み
dbt自体の記法はSQLベースであり簡単でしたが、自由度が高いため適切なディレクトリ構造をチームでキャッチアップしながら作成する必要がありました。dbtの公式からベストプラクティスが提示されているため、それに従って記述することで大きな問題はありませんでした。
【参考】https://docs.getdbt.com/best-practices
導入に向けた社内への説明
上長・チームへの説明
ツール移行には一定の実装コストが発生しますが、データの変換処理が増えていくことは明白だったため、早めに取り組む必要がありました。導入にかかる費用に関しては、少人数でスピード感を持って、可用性の高いデータを提供するためのインフラ管理コストとして費用対効果が高いと判断しました。
活用方法
よく使う機能
- dbt Explore
- elemantary
- Exposures
ツールの良い点
- dbtのアップデートが早い
セマンティックレイヤーや、Meshなどデータエンジニアリング領域での最新トレンドがdbtに早く取り込まれるため、トレンドに乗りやすいです。 - dbtの機能が豊富
先ほども紹介したelementaryなどの機能が多いのに加え、airflow, fivetranなどの外部ツールとの接続性も高く、様々な機能を活用することができます。 - dbt coreと並行運用できる
dbt Cloud上だとdbtコマンド以外の利用ができなかったり、一部コード管理ができなかったりする。coreと並列利用することでこれらの問題も解決できます。
ツールの課題点
- dbt Cloudの一部のログデータが扱いづらい
dbt Cloud上でのジョブ実行を行う場合、ジョブの実行ログなど、監視などに使う一部のログがexportできなくて、elementaryで代替してます。 - dbt Cloudは少し料金高め
dbt Cloudのアカウントだけを使うことなく、coreと並列利用することで、料金対策を行なってます。
今後の展望
dbtを導入してからタイミーでは約2年半が経ちますが、振り返ってみると、早い段階で導入したおかげで多大な効果を実感しています。この2年半の間に、データ変換やデータモデリングのニーズは大幅に増加しましたが、少人数のチームでもスケールしながらデータ提供ができているのは、dbtの貢献が大きいと感じています。
今後もdbtを活用することで、データ活用における課題を多く解決できると考えています。引き続き、dbtを活用していきたいと思います。
株式会社タイミー / Tsuchikawa
よく見られているレビュー
株式会社タイミー / Tsuchikawa