ラクスル株式会社のdbt導入事例(ダンボールワン編)

ツール導入前の課題

ラクスルグループには子会社も含めて複数事業が存在し、セキュリティ境界を設ける形でデータ基盤を開発・運用しています。買収によりダンボールワンがラクスルグループに加わり、データ基盤を整備した2022年当時の導入背景になります。 dbt導入以前のデータ基盤ではJenkinsを使って実行順序を制御し、SQLの本数が多く、依存関係も複雑なため、以下のような課題がありました。

• 依存関係が複雑なため、新規参画したエンジニアの学習コストが高い
• 追加・変更したSQLを自動テストする仕組みがなかったため、動作確認に時間がかかる、確認漏れが発生する恐れがある

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

ツール導入前の課題を解決することを目指していました。

• Dataform

• 容易に導入できるか
• データパイプラインを構築するための学習コストが低いか
• BigQueryの固有処理に対応しているか
  • 承認済みビューの作成
  • ポリシータグの付与

• SQLの知識があればデータパイプラインを構築できる
• SQLで定義したモデルはrefと呼ばれるテーブル間の関係性を自動的に把握できるようになる仕組みで記述することで、DAG（有向非巡回グラフ）を考慮したデプロイを実行できるため、モデルを反映させるための細かなワークフローを組む必要がない
• モデルによって生成された結果にアサーションを行うことで、各モデルのSQLの整合性を向上させる方法が提供されている
• ベンダーロックインを回避できる
  • 将来BigQuery以外のDWHを使うことになった場合、ある程度容易に移行が可能である

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

ツール導入前の課題は解決することができました。

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

• 依存関係が複雑なため、新規参画したエンジニアの学習コストが高い

SQLを書くだけで良く、SQLの知識があればパイプラインを構築できるため、学習コストが下がりました。 また、dbt docsでドキュメント生成することでデータリネージを確認することができるようになったため、依存関係のが把握しやすくなりました。 dbtの学習コストはあるものの、コストはそこまで高くはない印象です。

• 追加・変更したSQLを自動テストする仕組みがなかったため、動作確認に時間がかかる、確認漏れが発生する恐れがある

dbt testにより、モデルによって生成された結果にアサーションを行うことで、各モデルのSQLの整合性を向上させることができました。 例えば、他モデルとの行数一致をテストすることで、JOINミスによる行落ち、行膨れを防ぐことができるようになりました。

• BigQueryの固有処理ヘの対応
  • 導入当時は外部ソース（Spread, GCS）のexternalテーブル作成ができなかったため、内製スクリプトを事前実行していた
  • 現在ではdbt-external-tablesを用いてexternalテーブル作成するようになっている

dbtを導入して2年半経ちますが、データパイプラインの開発がかなり楽になったと感じています。 一部のデータ基盤については、まだdbtに移行できていませんので、2024年内に移行を完了させたいと考えています。