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
5
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
250
Four KeysによるDataOps改善の第一歩
marufeuille
6
1.1k
Other Decks in Programming
See All in Programming
Perplexity Slack Botを作ってAI活用を進めた話 / AI Engineering Summit プレイベント
n3xem
0
660
Benchmark
sysong
0
210
Javaに鉄道指向プログラミング (Railway Oriented Pro gramming) のエッセンスを取り入れる/Bringing the Essence of Railway-Oriented Programming to Java
cocet33000
2
580
Development of an App for Intuitive AI Learning - Blockly Summit 2025
teba_eleven
0
120
セキュリティマネジャー廃止とクラウドネイティブ型サンドボックス活用
kazumura
1
180
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
230
Practical Tips and Tricks for Working with Compose Multiplatform Previews (mDevCamp 2025)
stewemetal
0
130
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
300
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
380
A comprehensive view of refactoring
marabesi
0
790
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
360
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
11
1.9k
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
930
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Rebuilding a faster, lazier Slack
samanthasiow
81
9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
910
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Being A Developer After 40
akosma
90
590k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Music & Morning Musume
bryan
46
6.6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
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!