Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
dbtとリバースETLでデータ連携の複雑さに立ち向かう
Search
Toru Morooka
May 13, 2025
Technology
0
3.7k
dbtとリバースETLでデータ連携の複雑さに立ち向かう
【技術選定を突き詰める】Online Conference 2025
https://findy.connpass.com/event/349580/
Toru Morooka
May 13, 2025
Tweet
Share
More Decks by Toru Morooka
See All by Toru Morooka
AI時代のエンジニア ~Matz Keynoteに寄せて〜
morookacube
0
52
Other Decks in Technology
See All in Technology
Witchcraft for Memory
pocke
1
430
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
1
230
Lambda Web Adapterについて自分なりに理解してみた
smt7174
4
120
mrubyと micro-ROSが繋ぐロボットの世界
kishima
2
330
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
170
解析の定理証明実践@Lean 4
dec9ue
0
180
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
17
5.7k
急成長を支える基盤作り〜地道な改善からコツコツと〜 #cre_meetup
stefafafan
0
130
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
3
1.3k
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
3.9k
20250625 Snowflake Summit 2025活用事例 レポート / Nowcast Snowflake Summit 2025 Case Study Report
kkuv
1
310
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Making Projects Easy
brettharned
116
6.3k
GraphQLとの向き合い方2022年版
quramy
48
14k
Embracing the Ebb and Flow
colly
86
4.7k
Side Projects
sachag
455
42k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
The Pragmatic Product Professional
lauravandoore
35
6.7k
What's in a price? How to price your products and services
michaelherold
246
12k
Designing for Performance
lara
609
69k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
GitHub's CSS Performance
jonrohan
1031
460k
Transcript
dbtとリバース ETLで データ連携の複雑さに立ち向かう 2025.05.14 #技術選定con_findy エムスリーキャリア株式会社 諸岡 徹(@morooka_cube)
自己紹介 諸岡 徹(@morooka_cube, もろーか) エムスリーキャリア株式会社 Webアプリケーションエンジニア / チームリーダー 医療従事者・医療機関向け Webサービスの開発チームで
技術戦略や開発生産性の向上を担当
None
エムスリーキャリアのエンジニアリング 営業基幹システム (Salesforce) 医療従事者向け Webサービス (Ruby on Rails, etc.) ❗
システム間のデータ連携が 事業展開を支えるコア技術 となっている 医療機関・ 一般企業向け SaaS (Ruby on Rails, etc.)
複雑なデータ連携 📄 リソース型データ • 求人情報, 求職者情報など • マスタデータとして各システムで更新・参照 📅 イベント型データ
• 求職者からの求人問い合わせ , 選考の進捗状況など • 日々の業務活動で発生し、リアルタイムな連携が必要 本発表では リソース型データ の連携に焦点
従来の連携方法 …営業基幹システム→Webアプリケーションの場合 営業基幹システム (Salesforce) Webアプリケーション 連携バッチをRakeタスク(Ruby)で実装し、Cronでスケジュール実行 ⚙ データ抽出 →変換→格納 (Rakeタスク)
💾 アプリDB (MySQL, etc.)
組織横断した課題に 😣 個々の開発チームでペインが発生、 垣根を越えて改善の取り組みを始める ことに Web開発チーム 基幹システム開発チーム
抱えていたペイン (Webエンジニア視点) 営業基幹システムのドメイン知識が必要 • 複雑なデータ構造の理解、営業部門のプロセス理解が必要 🍝 Webアプリケーション用ロジックと営業基幹システム用ロジックの混在 • Webアプリのコードベースに
基幹システムのドメインが染み出し 、保守性が悪化 📃 手続き的なデータ変換ロジック • SQLで宣言的に書きたい
抱えていたペイン (基幹システムエンジニア視点) 🔀 データの参照関係が不明瞭 • 各データがWebアプリケーションでどのように参照されているかわからない • 項目・オブジェクトの変更削除による影響範囲の把握が困難 • 変更・クリーンアップが進まず
保守性が低下
データ基盤 データ基盤活用の機運 事業横断的なデータ分析を目的に データ基盤構築プ ロジェクトが立ち上がる 基幹システム内の主要データが BigQueryに蓄積され た状態に 参考:https://findy-tools.io/products/trocco/17/48 💡
データ基盤をシステム間データ連携のハブとし て活用できないだろうか? 営業基幹システム (Salesforce) ⚙ データ転送ツール (TROCCO) 💾 アプリDB (MySQL, etc.) データレイク (BigQuery)
データ基盤 新しい連携方法 …dbtとリバースETLの導入 TROCCOによるdbtジョブでデータ変換し、TROCCOのリバース ETLでアプリDBに転送 ⚙リバースETL TROCCO転送ジョブ 💾 アプリDB (MySQL,
etc.) ⚙データ変換 TROCCO dbtジョブ データマート (BigQuery) データレイク (BigQuery) 営業基幹システ ム (Salesforce)
新しい連携方法 …リバースETLとdbtの導入 ⚙ データ変換 (TROCCO dbtジョブ) • 生データをWebアプリでの活用に適した形式に変換 • dbtによってデータ変換ロジックを
SQLベースで実装 • TROCCOによってdbtによる変換処理を定期実行し、データマートを構築 ⚙データ変換 TROCCO dbtジョブ データレイク (BigQuery) データマート (BigQuery)
新しい連携方法 …リバースETLとdbtの導入 ⚙ データマート→アプリDBへの転送 (TROCCO転送ジョブ) • TROCCOの転送ジョブを利用 • dbtで作成したデータマートからアプリ DBへデータを転送
• 転送方式:要件に応じて全件洗い替え (Truncate & Insert) や差分更新 (Upsert) を選択 ⚙リバースETL ※ TROCCO転送ジョブ データマート (BigQuery) 💾 アプリDB (MySQL, etc.) ※業務システム →データ基盤のETL(Extract, Transform, Load)とは逆向きであることから
導入メリット①: dbtによる開発プロセス改善 🚀 モダンなデータ開発体験 • SQLベースの実装 により手続き的なスクリプト実装の苦しみから解放! • マクロ機能 で繰り返しロジックの共通化
• Gitによるバージョン管理運用 で、変更履歴の追跡やコードレビューが容易に 🧠 ドメイン知識の集約 • 基幹システムのドメイン由来の変換ルールを dbtに集約し、Webアプリから分離 • Webエンジニアは変換後データ構造の理解 に集中できるように
導入メリット②:データ変換の信頼性向上 🔀 データリネージュによる参照関係の可視化 • どのデータがどのように変換されどのテーブルに出力されるか • 基幹システム側のデータ項目変更時の 影響調査が容易に • dbtロジック修正の際も見通しよく開発・保守
できる
(今後の展望)チーム横断したデータ基盤作りの促進 dbtでの開発体験がとても良かったので、もっと広めていきたい! 🤝 データマート構築の役割分担 • 基幹エンジニア:全社共通データマート 構築を担当(ドメイン知識を集約) • Webエンジニア:アプリ専用データマート 構築を担当
(共通マートを活用) ⚙ dbtなら同じコードベース上で実現できる • 適切に役割分担しつつ、 チーム横断でのデータ活用を促進 していく 💪 挑戦はまだ始まったばかり!
まとめ 🔥 dbtとリバースETLでデータ連携の複雑さに立ち向かうことができた! • 複雑なデータ連携のペインと、データ基盤を用いた改善のアプローチ • dbtの素晴らしい開発体験と、それが拓くチーム横断の可能性 🍕 懇親会参加します •
データ連携, 基盤開発, 組織づくり…熱く語りましょう • お気軽にお声がけください 😊
Appendix リバースETLを使う際のデータ設計の注意点 主キーの同一性はデータ発生源または dbtで保証すること 全件洗い替え (Truncate & Insert) するテーブルの主キーが auto_incrementなInteger値だと…
• 外部キー制約の不整合 :参照先レコードが削除 →再挿入されると主キーが再採番され、既存 の外部キー参照が切れてしまう • INSERT順依存のバグ :リバースETL側でINSERT順が保証されているとは限らない