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
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
250
Four KeysによるDataOps改善の第一歩
marufeuille
6
1.1k
Other Decks in Programming
See All in Programming
「MCPを使ってる人」が より詳しくなるための解説
yamaguchidesu
0
570
漸進。
ssssota
0
900
AIエージェントによるテストフレームワーク Arbigent
takahirom
0
260
技術懸念に立ち向かい 法改正を穏便に乗り切った話
pop_cashew
0
590
JSAI2025 RecSysChallenge2024 優勝報告
unonao
1
370
Investigating Multithreaded PostgreSQL
macdice
0
150
ソフトウェア品質特性、意識してますか?AIの真の力を引き出す活用事例 / ai-and-software-quality
minodriven
19
6.6k
primeNumberでのRBS導入の現在 && RBS::Traceでinline RBSを拡充してみた
mnmandahalf
0
250
AI時代のリアーキテクチャ戦略 / Re-architecture Strategy in the AI Era
dachi023
0
190
知識0からカンファレンスやってみたらこうなった!
syossan27
5
320
#QiitaBash TDDでAIに設計イメージを伝える
ryosukedtomita
2
1.6k
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
120
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.3k
GitHub's CSS Performance
jonrohan
1031
460k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.3k
KATA
mclloyd
29
14k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
620
Docker and Python
trallard
44
3.4k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Art, The Web, and Tiny UX
lynnandtonic
298
21k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
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!