kubell（旧Chatwork）のデータ分析基盤でのdbt活用について

ツール導入前の課題

制御を自前のshellスクリプト+αで行っていたため、以下のような課題がありました。

• データモデルが追加される度に、制御の仕組みも実装する必要がある。
• モデル間の依存関係による実行順序の制御や開発・テスト・本番などの環境差異などの全てを、自前スクリプトで制御していたため、構造が大きくなると制御スクリプトの改修のコストが増大してしまう。
• 開発・運用ともに属人化が進行しやすく、スケールが難しい要因となる。

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

次世代のデータ分析基盤を立ち上げるにあたって、開発・運用ともに小さく始め、スケールできる仕組みを目指しました。

• 少リソースで開発を始められ、スケールも見込めること。
• 少ない労力で運用が可能になること。
• データ品質をテストする仕組みがあること。

• 自前のshellスクリプト
• digdag

主要なところとしては以下のような点でした。

• ストレスなく開発を進められること（できれば楽しく！）。
• 運用がツラくならないこと。
• スムーズにスケールできるかどうか。

• データ処理に必要な一般的な基本機能（incremental, snapshot）をフレームワークで実装する仕組みを持っていたこと。
• データモデルの依存関係を自動解決する仕組み（run, build）があり、運用がツラくならない見通しが立てられたこと。

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

開発・運用を始めてから2年以上が経過しましたが、基本レベルの課題は全て解消できています。 それにより今は、より高レベルなスケールする構造・実装への対応や生産性を高める自動化、テストの導入に取り組んでいます。

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

プロジェクトの立ち上げ当初は想定していなかった、以下のような利用拡大にも対応できる開発体制を構築できました。

• データ基盤を利用する側のアナリストも開発に参加するようになった。（アナリストが自ら必要なデータモデル（意味層）をdbtで実装するように）
• 別ドメイン（他会社、事業）のデータ基盤構築に対して、素早く横展開できた。

cf. 我が社のデータエンジニアリング現場

これからデータ基盤構築を始める場合は、検証しておいて損はないと思います。

特にSQLで色々な設定を適用できるSnowflakeと合わせると、環境まわり（外部ストレージ/table構築、タグベースマスキングの設定...etc）もコード化できて、生産性を向上させる実装ができるようになるのでオススメです！