Upgrade to Pro — share decks privately, control downloads, hide ads and more …

タイミーにおけるデータの利用シーンと データ基盤の挑戦

Masahiro ISHII
September 26, 2024

タイミーにおけるデータの利用シーンと データ基盤の挑戦

データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜(https://sansan.connpass.com/event/329234/) の発表資料です

Masahiro ISHII

September 26, 2024
Tweet

More Decks by Masahiro ISHII

Other Decks in Programming

Transcript

  1. 自己紹介 石井 正浩 / @marufeuille 2022/8 タイミー入社 & DREチームJoin データ基盤の開発・運用やってます。最近はデータ

    コントラクトの実現に悩んでます。 最近のブームはコーヒー☕を淹れたり (手鍋で)煎ったりすることです。
  2. タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2

    月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査 委託先]株式会社マクロミル ※3 2024年9月時点 ※4 2024年9月時点 利用率 ・リピート率 ※1 ※2 導入事業者数 136,000企業 ワーカー数 900万人 ※4 ※3
  3. タイミーのデータ基盤の歴史 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
  4. といってもメッシュは難しい 現実問題、組織構成が合致しない - 開発部門はともかくとしても、事業部にエンジニアがいることは極々稀な ので、分担できる範囲がかなり異なりそう - 活用イメージはあるが、データについてはわからない、とか - そもそも運用なにすればいいの? -

    開発部門にしてもデータに割ける人員がいるかというと・・・? - 共通プラットフォーム的な構想が必要だが、一足飛びにそれは無理 - 開発リソースがそんなにあるわけでもないし、現時点でハマるかは不 明 - そもそもユースケースも無数すぎていきなりはハードルが高すぎる
  5. 事例. 社内スプシの収集業務 スプシとの格闘の歴史 - sandbox環境を用意して、そこにユーザで繋ぎ込んでもらう - 秩序が保てない(個人情報、いらないデータが残り続ける) - 期限付きにしたら、本番系ユースケースでアナリストの工数 増大

    - DREが外部テーブルとして繋ぎ込んでいた - 何を約束しても変更が入るときは入っちゃうのでパイプライ ン的に守れない - DREの工数増大(ユースケースごとでスケールしにくい) - データ収集用途のサムシング検討 - AppSheetは運用面の負が大きくなり撤退 - nocodb検証中も微妙にハマらない
  6. コントラクト駆動の実装 Output Port スプシデータ収集用 Data Product Input Port raw data

    (lake) staging data スプシのコントラクト BQ上のコントラクト DRE 実装 データオーナー
  7. 責務の整理 データオーナー DRE - データの場所 - 中身の情報 - 品質情報 -

    後続のユース ケース … データコントラクトを介した合意
  8. 変更への耐性 スプシ(ソース)のコントラクト 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: 日付 … シンプルな 一対一変換なのでこの形式 データオーナーにコントラクトの運用を握ってもらい、それに従い処理を ある程度機械的に生成できるように ※ 抜粋です
  9. 変更への耐性 処理上の工夫 raw data (lake) staging data jsonlに変換 SQL jsonをparseしながらSELECT

    => stagingの定義が変わって もrawからの読み込み直しで済 む
  10. ユースケースの収集・整理 こうしていきたい(願望)の話 Output Port スプシデータ収集用 Data Product Input Port raw

    data (lake) staging data めっちゃクリティカルな利用 DataProduct Input Port 会社の存続に関わる利用 DataProduct Input Port
  11. サービスレベルの明示・改善 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 * * * # 深夜帯の想定 • ドキュメントとして再整備し、 データオーナーと合意 • ユースケースの再チェックしつつ 再定義