$30 off During Our Annual Pro Sale. View Details »
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
610
データパイプラインをなんとかした話 / 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
600
インフラからSREへ
mirakui
32
14k
Cookpad TechConf 2022 Keynote
mirakui
0
3.9k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.5k
関東積みについて/How to build Kanto-stacking
mirakui
0
740
先折り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
100以上の新規コネクタ提供を可能にしたアーキテクチャ
ooyukioo
0
260
ハッカソンから社内プロダクトへ AIエージェント ko☆shi 開発で学んだ4つの重要要素
leveragestech
0
210
Strands Agents × インタリーブ思考 で変わるAIエージェント設計 / Strands Agents x Interleaved Thinking AI Agents
takanorig
5
2.1k
MariaDB Connector/C のcaching_sha2_passwordプラグインの仕様について
boro1234
0
1k
「もしもデータ基盤開発で『強くてニューゲーム』ができたなら今の僕はどんなデータ基盤を作っただろう」
aeonpeople
0
250
2025-12-27 Claude CodeでPRレビュー対応を効率化する@機械学習社会実装勉強会第54回
nakamasato
4
1.1k
LayerX QA Night#1
koyaman2
0
270
New Relic 1 年生の振り返りと Cloud Cost Intelligence について #NRUG
play_inc
0
240
AI との良い付き合い方を僕らは誰も知らない
asei
0
270
[2025-12-12]あの日僕が見た胡蝶の夢 〜人の夢は終わらねェ AIによるパフォーマンスチューニングのすゝめ〜
tosite
0
180
子育てで想像してなかった「見えないダメージ」 / Unforeseen "hidden burdens" of raising children.
pauli
2
330
Next.js 16の新機能 Cache Components について
sutetotanuki
0
190
Featured
See All Featured
My Coaching Mixtape
mlcsv
0
13
The Curious Case for Waylosing
cassininazir
0
190
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
1
210
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
Are puppies a ranking factor?
jonoalderson
0
2.4k
Code Review Best Practice
trishagee
74
19k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.3k
Automating Front-end Workflow
addyosmani
1371
200k
AI: The stuff that nobody shows you
jnunemaker
PRO
1
26
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
61
41k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
71
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形式とかで書けるようになって欲しいし、 スケジュール削除しなくてもオンオフができるようになって欲しい
おわり