データの信頼性を支える仕組みと技術

by chanyou0311

Slide 1

Slide 1 text

2024/11/09 Yu Nakamura - chanyou データの信頼性を⽀える仕組みと技術 @chanyou0311

Slide 2

Slide 2 text

Yu Nakamura - chanyou ● スタートアップでデータエンジニアとして交通データ分析基盤の構築‧運⽤を経験 ● その後、株式会社タイミーの DRE チームにジョイン ● モデリング済みのデータを各種ツールに送出する Reverse ETL の実装などを担当 ● 広島在住。趣味はおうち Kubernetes クラスタ ● YAPC::Hiroshima 2024 のスタッフなど ● オープンセミナー2022@広島に登壇も

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 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9⽉時点 ※4 2024年9⽉時点利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 136,000企業ワーカー数 900万⼈ ※4 ※3

Slide 6

Slide 6 text

目次 ● タイミーにおけるデータ基盤の変遷 ● dbt の概要 ● データ基盤における信頼性とは ● データの信頼性を⽀える仕組みと技術 ● データ基盤の課題とこれから

Slide 7

Slide 7 text

1 タイミーにおけるデータ基盤の変遷

Slide 8

Slide 8 text

タイミーの従業員数の増加タイミーでは、2019年から2023年時点で、従業員数が86人→1000人規模まで増加した。

Slide 9

Slide 9 text

タイミーのデータ基盤の歴史 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

Slide 10

Slide 10 text

アーキテクチャ(2022年頃)

Slide 11

Slide 11 text

アーキテクチャ(いま)

Slide 12

Slide 12 text

アーキテクチャ(2022年頃) Forward ETL Aggregate 活⽤ / Reverse ETL

Slide 13

Slide 13 text

アーキテクチャ(いま) Forward ETL Aggregate 活⽤ / Reverse ETL

Slide 14

Slide 14 text

2 dbt の概要

Slide 15

Slide 15 text

dbt とは Aggregate

Slide 16

Slide 16 text

dbt とは ● オープンソースのデータ変換ツール ● アナリスト中⼼の領域にソフトウェアエンジニアリングの⽂化を持ち込んだ ○ バージョン管理、モジュール化、CI/CDとの統合、ドキュメント⽣成 ○ アナリティクスエンジニアと呼ばれるロールが誕⽣したほど ● dbt によって変換処理の信頼性が⾼まった

Slide 17

Slide 17 text

dbt ⼊⾨ ● 実際に体験してみる ○ Repository: chanyou0311/data-reliability-engineering-demo ● dbt-core と接続先に応じたアダプタを pip でインストールする ● 今回はローカル分析⽤DBの DuckDB を使う ● インストール後 dbt init コマンドでプロジェクトを初期化できる

Slide 18

Slide 18 text

コンセプト ● dbt_project.yml, proﬁles.yml ○ 設定ファイル ● models/*.sql ○ モデルファイル ● models/*.yml ○ スキーマファイル

Slide 19

Slide 19 text

dbt モデル ● SQLファイル ○ dbt ではモデルと呼ぶ。変換内容を定義する ○ Jinja テンプレートで拡張されており、他のモデルの結果を参照できる ○ dbt が依存関係を解決してくれて、SELECT の結果をテーブルやビューとして保存する ● YAMLファイル ○ モデルのメタデータを定義する

Slide 20

Slide 20 text

dbt を実⾏してみる ● 事前にデータを DuckDB にロードしておく ○ データウェアハウスへのデータ投⼊は dbt のスコープ外 ● dbt build コマンドを実⾏するだけ ○ DuckDB にテーブルが⽣成される ● ドキュメントの⽣成もできる ○ dbt docs generate ○ dbt docs serve

Slide 21

Slide 21 text

デモ

Slide 22

Slide 22 text

dbt を使い込むと ● ディメンショナル‧モデリングという、分析に特化したモデリング⼿法がある ○ モデリング済みのテーブルを Looker や Tableau に接続すると、SQLが書けなくても分析やダッシュボードの作成ができる ● タイミーでは1000以上のモデルを管理している ○ モデルをレイヤリングして秩序を保つ必要がある

Slide 23

Slide 23 text

dbt まとめ ● SQL と YAML で変換処理をコード管理できる ● 再利⽤可能なモデルでコラボレーションしやすい ● 冪等な処理で CI/CD への統合も容易にできる

Slide 24

Slide 24 text

信頼性に話を戻します

Slide 25

Slide 25 text

3 データの信頼性とは何か

Slide 26

Slide 26 text

データの信頼性とは ● 信頼できるデータ = 品質が担保されているデータ ● タイミーで重視しているデータ品質の評価軸特性意味完全性データが⽋損していないか適時性必要な時にすぐにデータを参照できるか⼀意性データが重複していないか⼀貫性型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか

Slide 27

Slide 27 text

データの信頼性を損なうとどうなるか ● 必要なときにデータが参照できない ● 誤った意思決定や機械学習モデルの精度低下を引き起こす

Slide 28

Slide 28 text

データの信頼性を損なうタイミング ● 転送パイプラインの障害 ● 変換ロジックの誤り ● 意図しないデータソースの仕様変更

Slide 29

Slide 29 text

転送パイプラインの障害停⽌ ● 適時性を損なう

Slide 30

Slide 30 text

変換ロジックの誤り ● LEFT JOIN すべきところで INNER JOIN してレコードが減ってしまった ● ⼀意だと思った列に重複があり、 LEFT JOIN でレコードが膨れてしまった Aggregate

Slide 31

Slide 31 text

意図しないデータソースの仕様変更 ● ⼿⼊⼒スプレッドシートのような、壊れやすいデータソースを扱うとき ○ 作業していてカラム名が意図せず変わってしまった ○ 結果、dbt の SELECT で存在しないカラムを指定してコケる ● アプリケーションのテーブルやカラムが削除されてしまったとき ○ 同様に dbt で追従できずコケてしまう停⽌停⽌

Slide 32

Slide 32 text

4 データの信頼性を⽀える仕組みと技術

Slide 33

Slide 33 text

信頼性の⾼め⽅、守り⽅ ● 信頼性が低下する要因を排除しよう ● 可能な限りテストをやっていこう特性意味完全性データが⽋損していないか適時性必要な時にすぐにデータを参照できるか⼀意性データが重複していないか⼀貫性型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか

Slide 34

Slide 34 text

dbt による⼀貫した指標の定義 ● 例えばワーカーのリピート率[%] の定義は？ ● 分析の度にクエリ書くと定義が揺れてしまうリスクがある ● dbtモデルから参照する形を取れば、再計算不要で⼀貫した値を参照できる

Slide 35

Slide 35 text

不安定なデータを JSON Lines 化して安全に扱う⼿⼊⼒CSVのような、壊れやすいデータソースを扱いたいとき ● 各レコードを JSON ⽂字列に変換して、ワンカラムとしてまとめる ● BigQuery にロードする ● dbt モデルで JSON ⽂字列をパースして、列として抽出する存在しない列を SELECT しても null として抽出できる

Slide 36

Slide 36 text

データ転送前後の⾏数⽐較で完全性を守る ● RDSからBigQueryにロードするときに、⽋損がないか⾏数を⽐較する ● GitHub Actions などでスクリプトを動かて監視

Slide 37

Slide 37 text

dbt によるテスト ● データテスト ● ユニットテスト ● データ鮮度チェック

Slide 38

Slide 38 text

dbt によるデータテスト実際のテーブルデータに対するテスト ● Generic data tests ○ スキーマファイルにテストを定義できる ○ 列に対して UNIQUE や NOT NULL の検証 ○ 別モデルの外部キーを持つか、離散値の検証 ● Singular data tests ○ テスト⽤の任意のSQLファイルを作成して、結果が0⾏であることを検証できる

Slide 39

Slide 39 text

dbt によるユニットテストテストデータを与えて、期待する結果となるか検証する ● 複雑なロジックや重要指標の定義が間違っていないか ● 正規表現が間違っていないかテスト駆動開発が実践できるようになった

Slide 40

Slide 40 text

dbt によるデータ鮮度のチェック 1時間に1回テーブルにインサートされるはずのに、 updated_at 列が古いままだと怪しい… 期待するテーブルの更新頻度を記述して、ちゃんと更新されているか検証できる

Slide 41

Slide 41 text

信頼性の⾼め⽅、守り⽅特性信頼性の守り⽅完全性転送前後の⾏数⽐較 dbt によるデータテスト適時性不安定なデータの JSON Lines 化（パイプライン停⽌を避ける） dbt によるデータ鮮度チェック⼀意性 dbt によるデータテスト⼀貫性 dbt による⼀貫した指標の定義 dbt によるユニットテスト

Slide 42

Slide 42 text

信頼性の⾼め⽅、守り⽅

Slide 43

Slide 43 text

5 データ基盤の課題とこれから

Slide 44

Slide 44 text

タイミーのデータ基盤の現状 ● Good ○ これまで紹介した⽅法により、特定のデータソースやユースケースに対するデータの信頼性を担保しやすい環境が整っている ● More ○ データソースとユースケースが多様化する中、中央のデータチームだけで社内のあらゆるドメインロジックや業務で期待されるデータ品質を把握して、維持運⽤していくのが困難になりつつある

Slide 45

Slide 45 text

タイミーのデータ基盤の現状引⽤元：[Data Mesh Manager公式サイト](https://www.datamesh-manager.com/)

Slide 46

Slide 46 text

理想形としてデータメッシュに期待 ● データメッシュとは、⼀⾔でデータ基盤のマイクロサービス化 ○ データプロダクトと呼ばれる単位でデータ基盤と開発チームを分離 ○ データプロダクト同⼠のインターフェイスとして、データコントラクトを定義 ○ 横串でプラットフォームチームが⽀える体制

Slide 47

Slide 47 text

理想形としてデータメッシュに期待引⽤元：[Data Mesh Manager公式サイト](https://www.datamesh-manager.com/)

Slide 48

Slide 48 text

データプロダクトデータプロダクト理想形としてデータメッシュに期待データソースデータプロダクトのオーナー処理いい感じのモデルインフラ / モニタリング環境データプロダクト DRE インフラインフラ

Slide 49

Slide 49 text

とはいえ、⼀気に進めるのは難しい組織体制の変更とデータ基盤のプラットフォーム化を⼀気に進めるのは難しい ● データプロダクトの開発‧運⽤のケイパビリティを持つ⽅が稀有 ○ 開発部⾨はともかく、事業部にエンジニアがいることは稀 ● データ基盤のプラットフォーム化も、上⼿くいくか不透明でリスクが⾼い ○ 銀の弾丸などない

Slide 50

Slide 50 text

特定の重要なユースケースに絞って検証していく ● データプロダクトのスコープの定義 ● データプロダクトの⼊出⼒のインターフェイスの定義 ● データプロダクトの開発の伴⾛ ● 部分的なプラットフォーム化の実施 ● データプロダクト開発⽂化の醸成 ○ 開発‧運⽤ガイドラインの⽂書化や勉強会の開催など

Slide 51

Slide 51 text

6 まとめ

Slide 52

Slide 52 text

まとめ ● データの信頼性は地道なテストの積み重ねで⾼めることができる ○ dbt の功績が⼤きい ● 多様で複雑なデータ基盤のニーズに素早く応えるには、組織体制含めたリアーキテクチャが必要そう ○ 試⾏錯誤しながら実績を積み上げていきたい

Slide 53

Slide 53 text

https://hrmos.co/pages/timee/jobs/1682251404118319115 データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！ We're hiring!