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

Transcript

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

2. Yu Nakamura - chanyou • スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 • その後、株式会社タイミーの DRE

   チームにジョイン • モデリング済みのデータを各種ツールに送出する Reverse ETL の実装などを担当 • 広島在住。趣味はおうち Kubernetes クラスタ • YAPC::Hiroshima 2024 のスタッフなど • オープンセミナー2022@広島 に登壇も

3. タイミーとは 3 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない

4. タイミーの特徴 4

5. タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2

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

6. 目次 • タイミーにおけるデータ基盤の変遷 • dbt の概要 • データ基盤における信頼性とは • データの信頼性を⽀える仕組みと技術

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

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

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

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

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

11. アーキテクチャ(いま)

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

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

14. 2 dbt の概要

15. dbt とは Aggregate

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

    • dbt によって変換処理の信頼性が⾼まった

17. dbt ⼊⾨ • 実際に体験してみる ◦ Repository: chanyou0311/data-reliability-engineering-demo • dbt-core と接続先に応じたアダプタを

    pip でインストールする • 今回はローカル分析⽤DBの DuckDB を使う • インストール後 dbt init コマンドでプロジェクトを初期化できる

18. コンセプト • dbt_project.yml, profiles.yml ◦ 設定ファイル • models/*.sql ◦ モデルファイル

    • models/*.yml ◦ スキーマファイル

19. dbt モデル • SQLファイル ◦ dbt ではモデルと呼ぶ。変換内容を定義する ◦ Jinja テンプレートで拡張されており、他のモデルの結果を参照できる

    ◦ dbt が依存関係を解決してくれて、SELECT の結果をテーブルやビューと して保存する • YAMLファイル ◦ モデルのメタデータを定義する

20. dbt を実⾏してみる • 事前にデータを DuckDB にロードしておく ◦ データウェアハウスへのデータ投⼊は dbt のスコープ外

    • dbt build コマンドを実⾏するだけ ◦ DuckDB にテーブルが⽣成される • ドキュメントの⽣成もできる ◦ dbt docs generate ◦ dbt docs serve

21. デモ

22. dbt を使い込むと • ディメンショナル‧モデリングという、分析に特化したモデリング⼿法がある ◦ モデリング済みのテーブルを Looker や Tableau に接続すると、SQLが書

    けなくても分析やダッシュボードの作成ができる • タイミーでは1000以上のモデルを管理している ◦ モデルをレイヤリングして秩序を保つ必要がある

23. dbt まとめ • SQL と YAML で変換処理をコード管理できる • 再利⽤可能なモデルでコラボレーションしやすい •

    冪等な処理で CI/CD への統合も容易にできる

24. 信頼性に話を戻します

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

26. データの信頼性とは • 信頼できるデータ = 品質が担保されているデータ • タイミーで重視しているデータ品質の評価軸 特性 意味 完全性

    データが⽋損していないか 適時性 必要な時にすぐにデータを参照できるか ⼀意性 データが重複していないか ⼀貫性 型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか

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

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

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

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

    LEFT JOIN でレコードが膨れてしまった Aggregate

31. 意図しないデータソースの仕様変更 • ⼿⼊⼒スプレッドシートのような、壊れやすいデータソースを扱うとき ◦ 作業していてカラム名が意図せず変わってしまった ◦ 結果、dbt の SELECT で存在しないカラムを指定してコケる

    • アプリケーションのテーブルやカラムが削除されてしまったとき ◦ 同様に dbt で追従できずコケてしまう 停⽌ 停⽌

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

33. 信頼性の⾼め⽅、守り⽅ • 信頼性が低下する要因を排除しよう • 可能な限りテストをやっていこう 特性 意味 完全性 データが⽋損していないか 適時性

    必要な時にすぐにデータを参照できるか ⼀意性 データが重複していないか ⼀貫性 型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか

34. dbt による⼀貫した指標の定義 • 例えば ワーカーの リピート率[%] の定義は？ • 分析の度にクエリ書くと定義が揺れてしまうリスクがある •

    dbtモデルから参照する形を取れば、再計算不要で⼀貫した値を参照できる

35. 不安定なデータを JSON Lines 化して安全に扱う ⼿⼊⼒CSVのような、壊れやすいデータソースを扱いたいとき • 各レコードを JSON ⽂字列に変換して、ワンカラムとしてまとめる •

    BigQuery にロードする • dbt モデルで JSON ⽂字列をパースして、列として抽出する 存在しない列を SELECT しても null として抽出できる

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

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

38. dbt によるデータテスト 実際のテーブルデータに対するテスト • Generic data tests ◦ スキーマファイルにテストを定義できる ◦

    列に対して UNIQUE や NOT NULL の検証 ◦ 別モデルの外部キーを持つか、離散値の検証 • Singular data tests ◦ テスト⽤の任意のSQLファイルを作成して、結果が0⾏であることを検証 できる

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

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

41. 信頼性の⾼め⽅、守り⽅ 特性 信頼性の守り⽅ 完全性 転送前後の⾏数⽐較 dbt によるデータテスト 適時性 不安定なデータの JSON

    Lines 化（パイプライン停⽌を避ける） dbt によるデータ鮮度チェック ⼀意性 dbt によるデータテスト ⼀貫性 dbt による⼀貫した指標の定義 dbt によるユニットテスト

42. 信頼性の⾼め⽅、守り⽅

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

44. タイミーのデータ基盤の現状 • Good ◦ これまで紹介した⽅法により、特定のデータソースやユースケースに対 するデータの信頼性を担保しやすい環境が整っている • More ◦ データソースとユースケースが多様化する中、中央のデータチームだけ

    で社内のあらゆるドメインロジックや業務で期待されるデータ品質を把 握して、維持運⽤していくのが困難になりつつある

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

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

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

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

    / モニタリング環境 データプロダクト DRE インフラ インフラ

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

50. 特定の重要なユースケースに絞って検証していく • データプロダクトのスコープの定義 • データプロダクトの⼊出⼒のインターフェイスの定義 • データプロダクトの開発の伴⾛ • 部分的なプラットフォーム化の実施 •

    データプロダクト開発⽂化の醸成 ◦ 開発‧運⽤ガイドラインの⽂書化や勉強会の開催など

51. 6 まとめ

52. まとめ • データの信頼性は地道なテストの積み重ねで⾼めることができる ◦ dbt の功績が⼤きい • 多様で複雑なデータ基盤のニーズに素早く応えるには、組織体制含めた リアーキテクチャが必要そう ◦

    試⾏錯誤しながら実績を積み上げていきたい

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