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
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.4k
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
170
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
10
5.3k
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
510
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
760
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
2.1k
ニーリーにおけるプロダクトエンジニア
nealle
0
840
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
220
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Writing Fast Ruby
sferik
628
62k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
Practical Orchestrator
shlominoach
189
11k
A Tale of Four Properties
chriscoyier
160
23k
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!