dbtとリバースETLでデータ連携の複雑さに立ち向かう

【技術選定を突き詰める】Online Conferenc​​e 2025
https://findy.connpass.com/event/349580/

Transcript

1. dbtとリバース ETLで データ連携の複雑さに立ち向かう 2025.05.14 #技術選定con_findy エムスリーキャリア株式会社 諸岡 徹(@morooka_cube)
2. 自己紹介 諸岡 徹（@morooka_cube, もろーか） エムスリーキャリア株式会社 Webアプリケーションエンジニア / チームリーダー 医療従事者・医療機関向け Webサービスの開発チームで 技術戦略や開発生産性の向上を担当
4. エムスリーキャリアのエンジニアリング 営業基幹システム （Salesforce） 医療従事者向け Webサービス （Ruby on Rails, etc.） ❗ システム間のデータ連携が 事業展開を支えるコア技術 となっている 医療機関・ 一般企業向け SaaS （Ruby on Rails, etc.）
5. 複雑なデータ連携 📄 リソース型データ • 求人情報, 求職者情報など • マスタデータとして各システムで更新・参照 📅 イベント型データ • 求職者からの求人問い合わせ , 選考の進捗状況など • 日々の業務活動で発生し、リアルタイムな連携が必要 本発表では リソース型データ の連携に焦点
6. 従来の連携方法 …営業基幹システム→Webアプリケーションの場合 営業基幹システム （Salesforce） Webアプリケーション 連携バッチをRakeタスク（Ruby）で実装し、Cronでスケジュール実行 ⚙ データ抽出 →変換→格納 （Rakeタスク） 💾 アプリDB （MySQL, etc.）
7. 組織横断した課題に 😣 個々の開発チームでペインが発生、 垣根を越えて改善の取り組みを始める ことに Web開発チーム 基幹システム開発チーム
8. 抱えていたペイン （Webエンジニア視点） 󰳐 営業基幹システムのドメイン知識が必要 • 複雑なデータ構造の理解、営業部門のプロセス理解が必要 🍝 Webアプリケーション用ロジックと営業基幹システム用ロジックの混在 • Webアプリのコードベースに 基幹システムのドメインが染み出し 、保守性が悪化 📃 手続き的なデータ変換ロジック • SQLで宣言的に書きたい
9. 抱えていたペイン （基幹システムエンジニア視点） 🔀 データの参照関係が不明瞭 • 各データがWebアプリケーションでどのように参照されているかわからない • 項目・オブジェクトの変更削除による影響範囲の把握が困難 • 変更・クリーンアップが進まず 保守性が低下
10. データ基盤 データ基盤活用の機運 事業横断的なデータ分析を目的に データ基盤構築プ ロジェクトが立ち上がる 基幹システム内の主要データが BigQueryに蓄積され た状態に 参考：https://findy-tools.io/products/trocco/17/48 💡 データ基盤をシステム間データ連携のハブとし て活用できないだろうか？ 営業基幹システム （Salesforce） ⚙ データ転送ツール （TROCCO） 💾 アプリDB （MySQL, etc.） データレイク （BigQuery）
11. データ基盤 新しい連携方法 …dbtとリバースETLの導入 TROCCOによるdbtジョブでデータ変換し、TROCCOのリバース ETLでアプリDBに転送 ⚙リバースETL TROCCO転送ジョブ 💾 アプリDB （MySQL, etc.） ⚙データ変換 TROCCO dbtジョブ データマート （BigQuery） データレイク （BigQuery） 営業基幹システ ム （Salesforce）
12. 新しい連携方法 …リバースETLとdbtの導入 ⚙ データ変換 (TROCCO dbtジョブ) • 生データをWebアプリでの活用に適した形式に変換 • dbtによってデータ変換ロジックを SQLベースで実装 • TROCCOによってdbtによる変換処理を定期実行し、データマートを構築 ⚙データ変換 TROCCO dbtジョブ データレイク （BigQuery） データマート （BigQuery）
13. 新しい連携方法 …リバースETLとdbtの導入 ⚙ データマート→アプリDBへの転送 (TROCCO転送ジョブ) • TROCCOの転送ジョブを利用 • dbtで作成したデータマートからアプリ DBへデータを転送 • 転送方式：要件に応じて全件洗い替え (Truncate & Insert) や差分更新 (Upsert) を選択 ⚙リバースETL ※ TROCCO転送ジョブ データマート （BigQuery） 💾 アプリDB （MySQL, etc.） ※業務システム →データ基盤のETL(Extract, Transform, Load)とは逆向きであることから
14. 導入メリット①： dbtによる開発プロセス改善 🚀 モダンなデータ開発体験 • SQLベースの実装 により手続き的なスクリプト実装の苦しみから解放！ • マクロ機能 で繰り返しロジックの共通化 • Gitによるバージョン管理運用 で、変更履歴の追跡やコードレビューが容易に 🧠 ドメイン知識の集約 • 基幹システムのドメイン由来の変換ルールを dbtに集約し、Webアプリから分離 • Webエンジニアは変換後データ構造の理解 に集中できるように
15. 導入メリット②：データ変換の信頼性向上 🔀 データリネージュによる参照関係の可視化 • どのデータがどのように変換されどのテーブルに出力されるか • 基幹システム側のデータ項目変更時の 影響調査が容易に • dbtロジック修正の際も見通しよく開発・保守 できる
16. （今後の展望）チーム横断したデータ基盤作りの促進 dbtでの開発体験がとても良かったので、もっと広めていきたい！ 🤝 データマート構築の役割分担 • 基幹エンジニア：全社共通データマート 構築を担当（ドメイン知識を集約） • Webエンジニア：アプリ専用データマート 構築を担当 （共通マートを活用） ⚙ dbtなら同じコードベース上で実現できる • 適切に役割分担しつつ、 チーム横断でのデータ活用を促進 していく 💪 挑戦はまだ始まったばかり！
17. まとめ 🔥 dbtとリバースETLでデータ連携の複雑さに立ち向かうことができた！ • 複雑なデータ連携のペインと、データ基盤を用いた改善のアプローチ • dbtの素晴らしい開発体験と、それが拓くチーム横断の可能性 🍕 懇親会参加します • データ連携, 基盤開発, 組織づくり…熱く語りましょう • お気軽にお声がけください 😊
18. Appendix リバースETLを使う際のデータ設計の注意点 主キーの同一性はデータ発生源または dbtで保証すること 全件洗い替え (Truncate & Insert) するテーブルの主キーが auto_incrementなInteger値だと… • 外部キー制約の不整合 ：参照先レコードが削除 →再挿入されると主キーが再採番され、既存 の外部キー参照が切れてしまう • INSERT順依存のバグ ：リバースETL側でINSERT順が保証されているとは限らない