Slide 1
Slide 1 text
2024/07/20 Yu Nakamura - chanyou
What is DRE?
@chanyou0311
Slide 2
Slide 2 text
Yu Nakamura - chanyou
● スタートアップでデータエンジニアとして交通データ分析基盤
の構築‧運⽤を経験
● その後2024年3⽉に株式会社タイミーの DRE チームにジョイン
● モデリング済みのデータを各種ツールに送出する Reverse ETL
の実装などを担当
● 広島在住。趣味はおうち Kubernetes クラスタ
● YAPC::Hiroshima 2024 のスタッフなども
Slide 3
Slide 3 text
タイミーとは
3
｢働きたい時間｣と｢働いてほしい時間｣を
マッチングするスキマバイトサービス
従来の「求⼈サイト」でも「派遣」でもない
Slide 4
Slide 4 text
タイミーの特徴
4
Slide 5
Slide 5 text
タイミーの実績
スキマ
バイト
No.1
※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2 ⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査
[調査委託先]株式会社マクロミル
利⽤率 ‧リピート率
※1 ※2
導⼊事業者数
98,000企業
ワーカー数
700万⼈
Slide 6
Slide 6 text
DRE とはなにか？
Slide 7
Slide 7 text
DRE とは
● Data Reliability Engineering の略
○ データの信頼性を確保する新しいアプローチのこと
● SRE のプラクティスをデータに適⽤する試み
Slide 8
Slide 8 text
目次
● DRE チームが担う役割
● データの信頼性とは
● DRE チームで実践しているプラクティス
Slide 9
Slide 9 text
1 DRE チームが担う役割
Slide 10
Slide 10 text
DRE チームのミッション
“私たちDREは、DataOpsによる、パイプライン構築、⾃動化、監視、デプロイメントの迅速化、
データ品質の向上などの取り組みにより、信頼性（スピード、品質‧安定、ユーザビリティ）の⾼
いデータ基盤プロダクトをユーザに提供します。”
Slide 11
Slide 11 text
タイミーにおけるデータのライフサイクル
Slide 12
Slide 12 text
ワークフロー管理‧Extract / Load
Slide 13
Slide 13 text
データクレンジング
Slide 14
Slide 14 text
Reverse ETL
Slide 15
Slide 15 text
モニタリング
Slide 16
Slide 16 text
リソース管理‧IAM
Slide 17
Slide 17 text
DRE が連携する社内関係者
● データを扱うチーム
○ アナリティクスエンジニア
○ データアナリスト
○ データサイエンティスト
● プロダクト‧エンジニアリング本部
○ Dev Platform Squad
○ その他 Squad
Slide 18
Slide 18 text
DRE が連携する社内関係者
● マーケティング部⾨
○ toC toB の両⽅にアプローチ
■ ユーザーマーケティング
■ クライアントマーケティング
● 営業部⾨
○ 600名を超える営業組織
○ セールスシステム
● コーポレート部⾨
○ 法務
○ セキュリティ
Slide 19
Slide 19 text
社内の全⽅位と向き合う必要がある
● 部署で使うデータはどこから供給されるのか？
○ 外部SaaSなのか、当社プロダクトなのか
○ いつ、どのように供給されるのか
● 供給されたデータは、いつどのように使われるのか？
○ 毎⽇参照されるのか、⽉次で参照されるのか
○ システム連携したいのか、意思決定を伴うのか
データの理解も重要だが、組織と業務プロセスの理解がより重要
Slide 20
Slide 20 text
2 データの信頼性とは
Slide 21
Slide 21 text
信頼性が低下すると
● Webアプリケーションにおいて信頼性が低下すると
○ 「アクセスできないよ…」 → リクエストの可⽤性
○ 「サイト重くない？」 → リクエストのレイテンシ
● ⼀⽅、データ基盤において信頼性が低下すると
○ 「昨⽇まで⾒れてたダッシュボードが今朝から表⽰できなくなったよ…」
○ 「前⽇分のデータがまだダッシュボードに反映されてないよ…」
○ 「なんかデータ、ダブってない？」
Slide 22
Slide 22 text
DMBOK を拠り所にデータの信頼性を紐解く
● データマネジメント知識体系ガイド 第⼆版 [⽇経BP社]
○ 様々なデータ品質の評価軸が紹介されている
Slide 23
Slide 23 text
タイミーで重視しているデータ品質の評価軸
特性 定義
完全性 ⽋損したデータの割合
適時性 データ参照時と現実のデータとの時間差
⼀意性 重複したデータの割合
⼀貫性 型、タイムゾーン、表記揺れなどの値の書式が統⼀されていない割合
Slide 24
Slide 24 text
その他のデータ品質
● メタデータ
○ テーブルやカラムの意味や制約などの補⾜情報
● データガバナンス
○ 最⼩権限の原則
● データダウンタイム
○ データが⽋落したり不正確な状態の期間
Slide 25
Slide 25 text
（参考）データ品質がテーマの発表資料
https://speakerdeck.com/ttccddtoki/dmbokwocan-kao-nisitadetamanezimentonoqu-rizu-mi
Slide 26
Slide 26 text
3 DRE チームで実践している
プラクティス
Slide 27
Slide 27 text
DRE チームで実践しているプラクティス
● ワークフローのステータス監視
● データの外形監視
● dbt によるメタデータ整備とテスト
Slide 28
Slide 28 text
ワークフローのステータス監視
● ワークフローが失敗した場合にアラートを受け取る
○ 原因の切り分け、影響範囲の調査などの対応
Slide 29
Slide 29 text
データの外形監視
● 定期的に転送前後のデータセットの⽐較を⾏う
○ テーブルごとに完全性、適時性、⼀意性が満たされているか検査する
■ 満たさない場合はアラートを受け取る
○ データソースの新規テーブルやカラムの検知も⾏う
● 具体例
○ 転送元: プロダクトの RDB
○ 転送先: BigQuery
○ 検査内容: ⾏数が⼀致するか / MAX(updated_at) が条件を満たすか
Slide 30
Slide 30 text
dbt によるメタデータ整備とテスト
● dbt で宣⾔的に BigQuery 内のデータの変換を⾏う
○ タイミーでは変換内容に応じて、下図のようにレイヤリングしている
○ 各レイヤーでモデル（テーブルやビュー）が実体化される
https://tech.timee.co.jp/entry/2023/10/23/143322
Slide 31
Slide 31 text
dbt によるメタデータ整備とテスト
● モデルは Jinja で拡張された SQL で定義される
● モデルごとにメタデータを YAML で定義できる
○ カラムの型や説明
○ ⾃動テスト
https://docs.getdbt.com/docs/build/documentation
Slide 32
Slide 32 text
dbt によるメタデータ整備とテスト
● データテスト
○ 実データに対して汎⽤的な
テストを実施できる
■ unique
■ not_null
■ …
● ユニットテスト
○ ⽤意したテストデータに
対して期待する出⼒となるか
https://docs.getdbt.com/docs/build/data-tests
Slide 33
Slide 33 text
4 今後の展望
Slide 34
Slide 34 text
タイミーのデータ基盤が抱える課題
● データソースの変更による下流への影響
● ⼿⼊⼒データの品質保証
● ストリーミングデータにおける完全性の担保
Slide 35
Slide 35 text
データソースの変更による下流への影響
Slide 36
Slide 36 text
知らない間に転送元のテーブルの列が削除されたら
● 途中のデータ変換で列指定されていたら？
○ ワークフローが停⽌してしまい、適時性が損なわれる
● downstream でダッシュボードの表⽰に使われていたら？
○ 古いデータのまま表⽰したり、そもそも表⽰できなかったりする
○ 適切な意思決定ができない
● 機械学習で使われていたら？
○ 古いデータをそのまま利⽤したり、機械学習パイプラインが停⽌したりする
○ 予測精度の低下、機会損失を招く
Slide 37
Slide 37 text
データソースの意図しない変更をどう防ぐか
● モニタリングやテストにより、ある程度対処できている
○ ただし対処であって、予防ではない
● データコントラクトによって事前に防げないか模索中
Slide 38
Slide 38 text
データコントラクトとは
● 契約プログラミングの概念をデータに持ち込んだもの
○ データ版 OpenAPI のようなもの
○ 破壊的な変更を避けて改善活動が実施できる
https://datacontract.com/
Slide 39
Slide 39 text
データコントラクトとは
● データがどのような形式で供給されるかを定義した⽂書
● いくつかの標準がある
○ Open Data Contract Standard (ODCS)
○ Data Contract CLI
● データの所有者、形式などの記載ができる
● データ品質、サービスレベルの記載も⾏える
● YAML でマシンリーダブルに表現される
○ CLI で実データを参照して、
データ品質の検証ができる
https://datacontract.com/
Slide 40
Slide 40 text
データコントラクトの運⽤を⽬指す
● データ供給元と利⽤先のチーム間で、データの形式について合意を取るようにしたい
○ いくつかのプロジェクトで試験的に導⼊
● プロダクトの CI に組み込むと？
○ 「このテーブルの型を変えようとしているけど、社内のダッシュボードで使われているのでダメです⚠」
https://datacontract.com/
Slide 41
Slide 41 text
5 まとめ
Slide 42
Slide 42 text
まとめ
● DRE とは SRE のプラクティスをデータに適⽤する試みのこと
● 社内の多様なチームと連携しながら、データの供給から活⽤までを⽀えている
● 扱うデータの理解は重要だが、組織とその業務プロセスへの理解も不可⽋である
● DRE のプラクティスとして、ワークフローやデータそのもののモニタリングを通し
て、信頼性の低下にいち早く対処している
● データ基盤と組織に新しい概念を持ち込むことで、信頼性の向上を⽬指している
Slide 43
Slide 43 text
https://hrmos.co/pages/timee/jobs/1682251404118319115
積極的に採⽤中です！！
データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！