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
530
データパイプラインをなんとかした話 / 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
インフラからSREへ
mirakui
22
8.9k
Cookpad TechConf 2022 Keynote
mirakui
0
3.8k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.4k
関東積みについて/How to build Kanto-stacking
mirakui
0
700
先折りGTRについて/How to build left-GTR transitions
mirakui
3
1.1k
サービス開発速度に着目したソフトウェアアーキテクチャ/Software architecture for effective service development at Cookpad
mirakui
5
7.1k
Beyond the Boundaries
mirakui
1
1.3k
Cookpad Under a Microscope
mirakui
6
8.6k
Technical Successes and Failures in the History of Cookpad Development
mirakui
45
37k
Other Decks in Technology
See All in Technology
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
shibayu36
0
170
Bye-Bye Query Spaghetti: Write Queries You'll Actually Understand Using Pipelined SQL Syntax
tobiaslampertlotum
0
120
kubellが考える戦略と実行を繋ぐ活用ファーストのデータ分析基盤
kubell_hr
0
130
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
13
4.1k
スプリントレトロスペクティブはチーム観察の宝庫? 〜チームの衝突レベルに合わせたアプローチ仮説!〜
electricsatie
1
150
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
30k
Figma + Storybook + PlaywrightのMCPを使ったフロントエンド開発
yug1224
10
3.6k
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
160
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
0
150
絶対に失敗できないキャンペーンページの高速かつ安全な開発、WINTICKET × microCMS の開発事例
microcms
0
360
実運用で考える PGO
kworkdev
PRO
0
130
5年目から始める Vue3 サイト改善 #frontendo
tacck
PRO
2
120
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
73
5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Side Projects
sachag
455
43k
Faster Mobile Websites
deanohume
309
31k
Typedesign – Prime Four
hannesfritz
42
2.8k
Agile that works and the tools we love
rasmusluckow
330
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
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形式とかで書けるようになって欲しいし、 スケジュール削除しなくてもオンオフができるようになって欲しい
おわり