ナウキャスト: dbtの導入でデータのサイロ化解消と開発スピード向上を実現

ツール導入前の課題

ナウキャストではクレジットカード、POSデータ、求人広告データなど多種多様なデータを扱っています​。dbt導入前は、S3 + AthenaベースのPython ETLを中心としたパイプラインを構築していましたが、以下の問題がありました。

• データソースごとに別々のチームが独立したパイプラインを構築しており、知見が共有されづらく、同じような機能を別々で開発するようなことが起きる(いわゆるサイロ化)
• パイプラインごとに微妙にアーキテクチャが異なる上、データカタログやリネージュが未整備で全体像の把握が難しい
• 異なるデータソースを組み合わせた横断的な分析が非常にしづらい

これらの問題を解決するため、Snowflakeとdbtを中心としたDWHによるELTパイプラインを構築することにしました。 本基盤に関するSnowflake中心のレビューはこちら: Snowflake と dbt / Terraform を組み合わせモダンなデータ基盤を構築

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

目指したのは、データパイプラインの統一基盤と環境分離の徹底、そしてデータ品質・系統管理の強化です。これに合わせてデータ基盤開発を専門に担うプラットフォームチーム(DSPU: Data Service Platform Unit)も新設し、全社的なデータ利活用を下支えする体制を整えました​。

• dbt-core(採用)
• dbt Cloud
• Dataform

• 既存のデータ基盤(AWS)を活用できること
• アップデートされ続けており、コミュニティが活発であること
• 費用面

• 既存のデータ基盤がAWSなので、Dataformは対象外
• dbt-core vs dbt Cloudでは、OSSで利用料自体はゼロであること、データエンジニアが多くdbt-coreを使い込むことで小回りの効く開発ができるようになるであろうことから、dbt-coreを採用しました

業務面での具体的な効果として、社内の新規データプロダクト開発が格段にスピードアップしました。実際、このSnowflake×dbt環境を用いて 「HRog賃金Now」 という統計データプロダクトをゼロから開発した際には、従来比で圧倒的に迅速なサイクルで実装・改良を進めることができました​。 従来であれば各種データの加工集計に時間を要したり、断片化したパイプラインの調整に手間取ったりしていたところ、統一基盤上でコードを書くだけで一連の処理を完結できるためです。

品質面でも、データの検証が自動化された恩恵は大きく、プロダクトに組み込むデータの信頼性が向上しました。例えばdbtのテスト機能により、「このテーブルの主キーはユニークかつNULLでないか」といった制約チェックを組み込んでおけば、開発時に即座に異常値を検知できます。実運用においても常に最新データに対しテストが走るため、不整合があればすぐに発見・対処可能です​。データ品質の担保が仕組み化されたことで、分析結果や提供データへの信頼性が飛躍的に高まりました。

組織面では、データエンジニアリングの知見が集約されたことでチーム間の連携が強化されました。以前はデータソース単位で閉じた開発をしていましたが、今はプラットフォームチームを中心に横断的なノウハウ共有が進み、メンバー各自が標準化された手法で開発できています。

• Snowflake・dbt・Terraformを中心とした新たなデータ基盤を運用するノウハウの確立と普及に苦労しました。Snowflakeとdbtは多くのメンバーにとって新しいものでしたし、Terraformは利用してはいたものの、Snowflake Providerならではのハマりどころなどもあり、メンバーが新しいデータ基盤上でスムーズに開発できるようになるまで苦労していました。これらの問題については、プラットフォームチームが勉強会やドキュメントの整備に時間を割いたり、比較的余力のあったチームと一緒にユースケースを作り、他のチームはそのコードベースを参考に開発するように少しずつサポートする、といった工夫をして解決しました。