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
タイミーにおけるデータの利用シーンと データ基盤の挑戦
Search
Masahiro ISHII
September 26, 2024
Programming
6
4.1k
タイミーにおけるデータの利用シーンと データ基盤の挑戦
データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜(
https://sansan.connpass.com/event/329234/
) の発表資料です
Masahiro ISHII
September 26, 2024
Tweet
Share
More Decks by Masahiro ISHII
See All by Masahiro ISHII
FivetranとGoogleCloudにより実現するセールスデータの統合と分析への活用
marufeuille
0
270
Four KeysによるDataOps改善の第一歩
marufeuille
6
1.2k
Other Decks in Programming
See All in Programming
実用的なGOCACHEPROG実装をするために / golang.tokyo #40
mazrean
1
120
🔨 小さなビルドシステムを作る
momeemt
2
620
令和最新版手のひらコンピュータ
koba789
14
8.2k
オープンセミナー2025@広島LT技術ブログを続けるには
satoshi256kbyte
0
150
Ruby Parser progress report 2025
yui_knk
1
250
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
A Gopher's Guide to Vibe Coding
danicat
0
190
Jakarta EE Core Profile and Helidon - Speed, Simplicity, and AI Integration
ivargrimstad
0
270
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
290
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
Namespace and Its Future
tagomoris
6
660
Improving my own Ruby thereafter
sisshiki1969
1
140
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
The Invisible Side of Design
smashingmag
301
51k
Visualization
eitanlees
147
16k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
We Have a Design System, Now What?
morganepeng
53
7.8k
The Pragmatic Product Professional
lauravandoore
36
6.8k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Statistics for Hackers
jakevdp
799
220k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Transcript
2024/09/26 タイミーにおけるデータの利用シーンと データ基盤の挑戦 @marufeuille データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜
自己紹介 石井 正浩 / @marufeuille 2022/8 タイミー入社 & DREチームJoin データ基盤の開発・運用やってます。最近はデータ
コントラクトの実現に悩んでます。 最近のブームはコーヒー☕を淹れたり (手鍋で)煎ったりすることです。
タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2
月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査 委託先]株式会社マクロミル ※3 2024年9月時点 ※4 2024年9月時点 利用率 ・リピート率 ※1 ※2 導入事業者数 136,000企業 ワーカー数 900万人 ※4 ※3
タイミーとは 4 「働きたい時間」と「働いてほしい時間」を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない
目次 • データ基盤の変遷と最近の課題 • データコントラクトの導入と実践 • まとめ
1 データ基盤の変遷と 最近の課題
タイミーの従業員数の増加 タイミーでは、2019年から2023年時点で、従業員数が86人→1000人規模まで増加した。
タイミーのデータ基盤の歴史 2018 アプリ リリース DWH (BigQuery)へ データ集約 2020 Looker導入 &
dbt導入 2021 2022 2023 2024 データモデリング をLookerからdbt へ移行 data streamに よるCDC導入 / exposureによる アウトプットの 管理 ガバナンスの強化 DREの数 (正社員ベース) 1 1 1 -> 2 2 -> 4 4 -> 6 AEの数 (正社員ベース) 1 -> 2 2 1
アーキテクチャ(2022くらい)
アーキテクチャ(いま)
アーキテクチャ(いま) 利用ユースケースの 増加 キワドイユースケースも 増加 データの増加と アーキテクチャの複雑化
最近 このデータってどう言う意味? うーん、わからんです。 問い合わせてみます。 データをBQに繋ぎこみたい リソースないんで待ってください 今日集計しないと顧客影響でるん だけど!! 昨日のリリース影響でした。 すぐ直します!!
ある時の社内勉強会
2 データコントラクトの 導入と実装
データプロダクト (理想的な)メッシュいいなあ データ ソース データプロダクトのオーナー 処理 いい感じの モデル インフラ データプロダクト
データプロダクト
といってもメッシュは難しい 現実問題、組織構成が合致しない - 開発部門はともかくとしても、事業部にエンジニアがいることは極々稀な ので、分担できる範囲がかなり異なりそう - 活用イメージはあるが、データについてはわからない、とか - そもそも運用なにすればいいの? -
開発部門にしてもデータに割ける人員がいるかというと・・・? - 共通プラットフォーム的な構想が必要だが、一足飛びにそれは無理 - 開発リソースがそんなにあるわけでもないし、現時点でハマるかは不 明 - そもそもユースケースも無数すぎていきなりはハードルが高すぎる
全体的な方向性 データオーナーとコラボして適切な運用ができるようにする - DRE、オーナーどちらかに運用負荷がよらずにお互いの職責として 適切な範囲になるようにする 変更に強い状態にする - データソース側の変更があっても容易に壊れない状態にする - できるだけ将来的な自動化やリソースの共通化を目指せる状態にしておく
大事なユースケースを把握できる状態にする - ユースケースを定期的に棚卸しし、必要な業務をすぐに把握できる状態 - 一定の品質モニタリングはセットで提供する
やっていきたいこと データ ソース 処理 BQ (Staging) まずはこのレベルをデータプロダクトとして捉え、 ガバナンス担保可能にしたい 利用者 Contract
Contract
事例. 社内スプシの収集業務 スプシとの格闘の歴史 - sandbox環境を用意して、そこにユーザで繋ぎ込んでもらう - 秩序が保てない(個人情報、いらないデータが残り続ける) - 期限付きにしたら、本番系ユースケースでアナリストの工数 増大
- DREが外部テーブルとして繋ぎ込んでいた - 何を約束しても変更が入るときは入っちゃうのでパイプライ ン的に守れない - DREの工数増大(ユースケースごとでスケールしにくい) - データ収集用途のサムシング検討 - AppSheetは運用面の負が大きくなり撤退 - nocodb検証中も微妙にハマらない
コントラクト駆動の実装 Output Port スプシデータ収集用 Data Product Input Port raw data
(lake) staging data スプシのコントラクト BQ上のコントラクト DRE 実装 データオーナー
DataContractの実装フォーマット 引用元:[Data Contract Specification](https://datacontract.com/) datacontract specification dataproduct specification 引用元:[Data Product
Specification](https://dataproduct-specification.com/)
参考) Data Mesh Manager 引用元:[Data Mesh Manager公式サイト](https://www.datamesh-manager.com/)
責務の整理 データオーナー DRE - データの場所 - 中身の情報 - 品質情報 -
後続のユース ケース … データコントラクトを介した合意
変更への耐性 スプシ(ソース)のコントラクト BQ上のコントラクト dataContractSpecification: 0.9.3 id: hogehoge_source servers: production: type:
spreadsheet location: https://spreadsheetのdrive header_row: 1 models: source: type: table fields: "データ取得日": type: string required: false description: データ取得日 "日付": type: string required: false description: 仕事開始日 … dataContractSpecification: 0.9.3 id: hogehoge_staging servers: production: type: bigquery models: staging: type: table fields: "obtained_date": type: datetime required: false description: データ取得日 config: mapping: data_contract_id: competitor_information/hallo_source field_name: データ取得日 "started_date": type: datetime required: false description: 仕事開始日 config: mapping: data_contract_id: competitor_information/hallo_source field_name: 日付 … シンプルな 一対一変換なのでこの形式 データオーナーにコントラクトの運用を握ってもらい、それに従い処理を ある程度機械的に生成できるように ※ 抜粋です
変更への耐性 処理上の工夫 raw data (lake) staging data jsonlに変換 SQL jsonをparseしながらSELECT
=> stagingの定義が変わって もrawからの読み込み直しで済 む
ユースケースの収集・整理 現状の実装と課題感 引用元:[Timee Product Team Blog](https://tech.timee.co.jp/entry/2024/03/18/110548) 課題感 - クリティカルなユースケースが判別できない いいところ
- 影響を及ぼす可能性がある場所は 理論上全て把握できる
ユースケースの収集・整理 こうしていきたい(願望)の話 Output Port スプシデータ収集用 Data Product Input Port raw
data (lake) staging data めっちゃクリティカルな利用 DataProduct Input Port 会社の存続に関わる利用 DataProduct Input Port
サービスレベルの明示・改善 dataContractSpecification: 0.9.3 id: hogehoge_source servers: production: type: spreadsheet location:
https://spreadsheetのdrive header_row: 1 … servicelevels: availability: description: | 可用性。データに参照できる割合。 BigQueryのUptimeに準じる https://cloud.google.com/bigquery/sla?hl=ja percentage: 99.9% retention: description: データの保持期間。無制限に保持する。 unlimited: true latency: description: データが書き込まれてから利用可能になるまでの時間 threshold: 1d sourceTimestampField: obtained_date frequency: description: データの更新頻度 type: batch interval: 24h cron: 0 17 * * * # 深夜帯の想定 • ドキュメントとして再整備し、 データオーナーと合意 • ユースケースの再チェックしつつ 再定義
その他これからのこと - SLOモニタリング、可視化 - Staging以降の定義とその運用検討 - データインシデントの可視化 - 横転・自動化 -
プロダクトのDBへの適用
3 まとめ
まとめ - 当たり前だが、世の中のプラクティスがそのまま適用可能なほど 現実は甘くないので組織の状態を見ながら試行錯誤が大事 - データエンジニアだけで全域を抑えるのはほぼ不可能なので、ビ ジネスユーザと分担しながら整備していくと本質的な改善が回る (機運を感じている)
いっしょにデータ品質を改善していきましょう!! https://hrmos.co/pages/timee/jobs/1682251404118319115 We're hiring!