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
データパイプラインをなんとかした話 / Improving the Data Pipeline...
Search
Issei Naruta
December 11, 2024
Technology
1
620
データパイプラインをなんとかした話 / Improving the Data Pipeline in IVRy
2024/12/11 IVRy エンジニア忘年LT大会 2024
https://connpass.com/event/333537/
Issei Naruta
December 11, 2024
Tweet
Share
More Decks by Issei Naruta
See All by Issei Naruta
mairuでつくるクレデンシャルレス開発環境 / Credential-less development environment using Mailru
mirakui
5
700
インフラからSREへ
mirakui
32
14k
Cookpad TechConf 2022 Keynote
mirakui
0
4k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.6k
関東積みについて/How to build Kanto-stacking
mirakui
0
750
先折りGTRについて/How to build left-GTR transitions
mirakui
3
1.1k
サービス開発速度に着目したソフトウェアアーキテクチャ/Software architecture for effective service development at Cookpad
mirakui
5
7.2k
Beyond the Boundaries
mirakui
1
1.4k
Cookpad Under a Microscope
mirakui
6
8.7k
Other Decks in Technology
See All in Technology
プロポーザルに込める段取り八分
shoheimitani
1
600
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.6k
pool.ntp.orgに ⾃宅サーバーで 参加してみたら...
tanyorg
0
100
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
480
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
190
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
5
1.6k
Agent Skils
dip_tech
PRO
0
120
SREが向き合う大規模リアーキテクチャ 〜信頼性とアジリティの両立〜
zepprix
0
470
We Built for Predictability; The Workloads Didn’t Care
stahnma
0
140
インフラエンジニア必見!Kubernetesを用いたクラウドネイティブ設計ポイント大全
daitak
1
380
SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル / SRE Kaigi 2026
aeonpeople
6
2.5k
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
3
210
Featured
See All Featured
KATA
mclloyd
PRO
34
15k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.6k
Designing Experiences People Love
moore
144
24k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
450
Prompt Engineering for Job Search
mfonobong
0
160
Designing Powerful Visuals for Engaging Learning
tmiket
0
240
Designing for Timeless Needs
cassininazir
0
130
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
170
Designing for humans not robots
tammielis
254
26k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
57
50k
Transcript
データパイプラインの課題をなんとかした話 IVRyエンジニア忘年 LT大会2024 Issei Naruta / mirakui
成⽥ ⼀⽣ (なるた いっせい) / @mirakui 株式会社 IVRy / Principal
Engineer 2008-2023 クックパッド ‧インフラ, バックエンドエンジニア ‧執⾏役CTO (2016-2022) 2024/2- IVRy ‧SRE + データ基盤 趣味: パン作り、ルービックキューブ 、ボルダリング
BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL
Aurora S3 DynamoDB
これまでの データ基盤 / データパイプライン の課題
①BigQueryのコストが 異様に⾼い BigQuery
BigQueryのコストが異様に⾼い このサイズのスタートアップでなんでこんなにBQ代払ってるの??? 主な原因 • 全社ダッシュボードで創業以来の着電ログを毎回フルスキャンしており 誰かがダッシュボード開くたびに数千円が⾶ぶ状態 →地道に⽇々スロークエリを追い、データマート作成で軽量化 • 料⾦プランが初期状態(On-demand)のままだった →スロット課⾦(Editions)に切り替え
料金を1/5程度に削減成功
②転送ワークフローが 複雑でメンテナンス困難
転送ワークフローが複雑でメンテナンス困難 • Terraform で⽣成された難解な転送フロー ◦ ジョブ開始時間がハードコーディングされているため 転送頻度を上げたいのに上げられない • 実⾏状況がわかりにくく、エラーが起こっても対処が困難 BigQuery
BigQuery Data Transfer Aurora S3 DynamoDB
③スキーマ変更が⼿動 アプリ側と⼆重管理が必要 BigQuery Aurora
スキーマ変更の⼆重管理問題 • アプリケーション側でテーブルやカラムが増えたら、 BQ側のスキーマもその都度変更する必要がある →⾯倒だし、忘れる →うっかり漏れがあると転送が壊れる。つらい BigQuery Aurora
TROCCOの導入で 転送ワークフローを改善した
TROCCO • ローコードな国産 ETL サービス → UI が分かりやすく、エンジニアでなくても扱いやすい → Embulk
(OSS) ベースなので挙動がまあまあ想像しやすい • 転送時に(半)⾃動でスキーマ追従ができる →テーブルやカラムが増減しても問題ない • コード管理や dbt の実⾏もできる →ある程度規模が⼤きくなっても⼤丈夫そう
移⾏作業のようす
既存パイプラインで転送したテーブルと TROCCO で転送したテーブルを共存さ せ、データの整合性を確認したら社内にア ナウンスしてガッと置き換える ←当日の自分用手順書
None
None
BigQuery Spreadsheet BigQuery Data Transfer Before (2024/2 入社時点) BI ETL
Aurora S3 DynamoDB
Aurora S3 DynamoDB dbt Aurora BigQuery BigQuery ETL Reverse ETL
BI - test - datamart - DWH After (2024/12 現在)
What’s next?
データパイプラインやっていき • データの鮮度を上げたい → TROCCO 導⼊では結局1⽇1回転送だったのを3時間に1回転送 の改善が限度だった • テーブル転送(洗替)をやめたい
→ 遅いしエコじゃない → CDC か Data Lakehouse パターンに移⾏チャレンジしたい • Snowflake に⾏きたい…かも → なんだかんだ BQ は使いやすいが クラウドまたぎ転送にいつまで消耗するんでしょうか
Appendix: TROCCOのここがつらいよ
TROCCOつらみリスト • エラーが分かりにくい ◦ 転送エラーログが Embulk の内部エラーの⽣ログを直接⾒せられるので結局どのレコードが問題だったのか全然わからん • 通知が不⼗分 ◦
基本は失敗通知だけでよくて、失敗していたジョブが成功したときだけ成功通知が欲しいけどできない。メール通知をparseしてご にょごにょしようかと思ったけど、メール通知がhtml tableレイアウトなのでparseしてなんかするのも困難。webhook対応してほ しい • 各種コネクタの出来のばらつきが激しい ◦ 対応してはいるけど本番運⽤が困難な仕様のものもちょいちょいある。転送元SalesforceコネクタはCSVを経由するせいで⽂字エン コードのノイズに弱すぎるとか、そもそもスキーマ追従ができなかったりとか、転送元DynamoDBはテーブルをスキャンしてしま うので本番では使えないとか • コード対応が中途半端 ◦ 転送フローやデータマートはコード管理できるけど⼀番コード管理したいワークフローは未対応。というか変更履歴すらないのは 厳しい • ユーザ管理機能が不親切 ◦ 初期パスワードの⾃動⽣成くらいして欲しいし、ユーザがログイン後じゃないとリソースグループに⼊れられないのも⾯倒すぎる • スキーマ推定が中途半端 ◦ 転送元にスキーマがあっても参照されずあくまでレコードからスキーマが推定されるため、新規テーブルでまだレコードが無い場 合は推定がうまくいかず、レコードが⼊ってきたときにこける • ワークフローのスケジュール指定が扱いづらい ◦ 例えば「3時間に1回実⾏したい」というようなときはスケジュールを8個設定する必要があるが、メンテナンス作業で⼀時的に⽌め たいときは8個を消して、メンテが終わったら8個をまたポチポチ作る必要がある。cron形式とかで書けるようになって欲しいし、 スケジュール削除しなくてもオンオフができるようになって欲しい
おわり