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
4
3.4k
タイミーにおけるデータの利用シーンと データ基盤の挑戦
データマネジメントのリアル 〜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
140
Four KeysによるDataOps改善の第一歩
marufeuille
6
1.1k
Other Decks in Programming
See All in Programming
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
360
EventSourcingの理想と現実
wenas
6
2.1k
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
d_endo
1
1k
qmuntal/stateless のススメ
sgash708
0
120
macOS でできる リアルタイム動画像処理
biacco42
7
2k
Identifying User Idenity
moro
6
8.1k
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.3k
Java ジェネリクス入門 2024
nagise
0
610
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.6k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
390
WEBエンジニア向けAI活用入門
sutetotanuki
0
310
Kubernetes for Data Engineers: Building Scalable, Reliable Data Pipelines
sucitw
1
200
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
229
18k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Writing Fast Ruby
sferik
626
61k
Done Done
chrislema
181
16k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Code Review Best Practice
trishagee
64
17k
4 Signs Your Business is Dying
shpigford
180
21k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
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!