dbt Core + dbt-athena で低コストにデータ基盤のパフォーマンス改善

ツール導入前の課題

前提として、dbt導入前の弊社のデータ基盤では、データの変換部分は内製開発したワークフローを利用していました。しかし、その内製ワークフローは暫定対応として構築されたものであり、以下の課題を抱えていました。

• 挙動が不安定
  • データ基盤の障害は、内製ワークフローに起因するものが大部分を占めていた
  • 10件/月程度のアラートが飛び、その度に開発者が確認していた
• 予期せぬ挙動が残っている
  • テーブルの依存関係解消に、予期せぬ挙動がのこっており、対応が必要ない場合でもアラートが飛んできていた
• 属人化
  • 短期的な対応を優先した結果、特定のメンバーに運用・保守の知識が集中し、属人化してしまっていた
  • アルゴリズム的な複雑度が高く、ドキュメントも未整備だったため、キャッチアップに時間がかかっていた

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

内製システムから外部ツールへの移行によって、安定性と効率を高め、より価値の高い領域にリソースを割くことができる状態を目指していました。具体的には以下の3点です。

• 安定稼働している状態
  • システム障害の大部分を占める内製ワークフローがdbtにリプレイスされ、データ基盤全体の障害発生率が下がっている状態
  • テーブルの依存関係解消時に起こる既存のバグを解消し、ディメンショナルモデリングが推進しやすい状態
• デファクトスタンダードに乗り副次的効果を享受できる状態
  • 世の中で最も使われているアプリケーションなので安定性が高い状態
  • ドキュメントが整備されており、ユーザーコミュニティもあるため、知見の獲得が容易な状態
  • データ分析環境業界でよく使われているアプリケーションであるため、即戦力となる新規メンバーの獲得がしやすい状態
• 自社開発→外部ツール利用により、人的リソースをより良く配分できる状態
  • 内製ワークフローの管理・保守に利用していた人的リソースを別のプロジェクトに活用可能な状態
  • 具体的には以下のような業務に力を割きたいと考えていた
    • ディメンショナルモデリングの推進
    • 事業部でのデータ活用推進サポート
    • 機械学習環境の構築

• dbt Core
• dbt Cloud

• 費用
• ニーズに合っているか

• dbt Coreの方が費用を気にせずに小さく始めやすかったため
• dbt Cloudは弊社のニーズに対してオーバークオリティだったため

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

• dbt導入前にあった3つの課題は、全て解決できました

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

• これまでエンジニアが障害対応に使っていた時間を、別のプロジェクトに使えるようになった
• テーブルの依存関係の予期せぬ挙動を解消し、ディメンショナルモデリングの推進に取り掛かることができた
• dbt testとdbt elementaryの活用により、データ品質を向上させることができた

• データ基盤のトレンドが変化する中で、無料で始めることができ、多様なサービスとのアダプターが充実しているdbt Coreは、検討初期に「まず導入してみる」ができるおすすめのツールです。
• 弊社では、解決したい課題とツール導入費用を考慮した上で、dbt Coreを選択しました。
• 単純なデータ変換のみであれば、dbtを導入せずにAWS Glue等の他のサービスの変換機能で十分かもしれません。しかし、データ基盤の利用の拡大により、複雑な依存関係をもつテーブルの管理・更新や、ドキュメントの整備が必要になってきた段階で、データ変換の「管理」を得意とするdbtを検討すると良いと思います。
• また、データ変換をすべてSQLで扱えるようになるので、これまでデータアナリストがデータエンジニアに依頼していた内容を、データアナリスト自身ができるようになることも魅力だと思います。

• 弊社の「ツール導入前の課題」は、dbt導入によりいずれも解決することができました。
• 今後は、ディメンショナルモデリング推進に取り組み、社内のデータ活用をさらに促進していきます。その過程で、dbt packageも活用しながら、ドキュメントやメタデータの整備も進め、よりデータを扱う人にとって易しい状態を作っていきたいです。
• また、今年度末にSnowflakeを導入し、dbt-athenaからdbt-snowflakeへ移行予定です。既にdbt-athena導入によりdbtのインフラは構築されているため、dbt-athenaとdbt-snowflakeの仕様の違いの部分を調整していきます。