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
chanyou0311
November 09, 2024
Technology
6
2.2k
データの信頼性を支える仕組みと技術
「オープンセミナー2024@広島 − XRE エンジニアを支える組織」での登壇資料です。
https://osh.connpass.com/event/324736/
chanyou0311
November 09, 2024
Tweet
Share
More Decks by chanyou0311
See All by chanyou0311
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
10
3.6k
5分でわかるDuckDB
chanyou0311
11
4.2k
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
4
1.6k
Pulumi に入門してみた
chanyou0311
1
330
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
1.1k
release-please で実現する手軽で不変な Docker イメージタグ付け方法
chanyou0311
0
450
データ基盤を支える技術
chanyou0311
9
4.4k
おうちk8s入門 - すごい広島 IT初心者の会 [84]
chanyou0311
1
390
オンラインコミュニケーションの課題と、その乗り越え方
chanyou0311
0
570
Other Decks in Technology
See All in Technology
実運用で考える PGO
kworkdev
PRO
0
130
ガチな登山用デバイスからこんにちは
halka
1
200
Webアクセシビリティ入門
recruitengineers
PRO
3
1.5k
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
150
クラウドセキュリティを支える技術と運用の最前線 / Cutting-edge Technologies and Operations Supporting Cloud Security
yuj1osm
2
250
カミナシ社の『ID管理基盤』製品内製 - その意思決定背景と2年間の進化 #AWSUnicornDay / Kaminashi ID - The Big Whys
kaminashi
3
720
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
150
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
450
生成AI時代のデータ基盤
shibuiwilliam
4
2.3k
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
220
実践アプリケーション設計 ②トランザクションスクリプトへの対応
recruitengineers
PRO
4
1.2k
AIエージェントの活用に重要な「MCP (Model Context Protocol)」とは何か
masayamoriofficial
0
250
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
How STYLIGHT went responsive
nonsquared
100
5.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
284
13k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Thoughts on Productivity
jonyablonski
69
4.8k
Rails Girls Zürich Keynote
gr2m
95
14k
The Cult of Friendly URLs
andyhume
79
6.6k
Transcript
2024/11/09 Yu Nakamura - chanyou データの信頼性を⽀える仕組みと技術 @chanyou0311
Yu Nakamura - chanyou • スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 • その後、株式会社タイミーの DRE
チームにジョイン • モデリング済みのデータを各種ツールに送出する Reverse ETL の実装などを担当 • 広島在住。趣味はおうち Kubernetes クラスタ • YAPC::Hiroshima 2024 のスタッフなど • オープンセミナー2022@広島 に登壇も
タイミーとは 3 「働きたい時間」と「働いてほしい時間」を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない
タイミーの特徴 4
タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2
⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9⽉時点 ※4 2024年9⽉時点 利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 136,000企業 ワーカー数 900万⼈ ※4 ※3
目次 • タイミーにおけるデータ基盤の変遷 • dbt の概要 • データ基盤における信頼性とは • データの信頼性を⽀える仕組みと技術
• データ基盤の課題とこれから
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年頃)
アーキテクチャ(いま)
アーキテクチャ(2022年頃) Forward ETL Aggregate 活⽤ / Reverse ETL
アーキテクチャ(いま) Forward ETL Aggregate 活⽤ / Reverse ETL
2 dbt の概要
dbt とは Aggregate
dbt とは • オープンソースのデータ変換ツール • アナリスト中⼼の領域にソフトウェアエンジニアリングの⽂化を持ち込んだ ◦ バージョン管理、モジュール化、CI/CDとの統合、ドキュメント⽣成 ◦ アナリティクスエンジニアと呼ばれるロールが誕⽣したほど
• dbt によって変換処理の信頼性が⾼まった
dbt ⼊⾨ • 実際に体験してみる ◦ Repository: chanyou0311/data-reliability-engineering-demo • dbt-core と接続先に応じたアダプタを
pip でインストールする • 今回はローカル分析⽤DBの DuckDB を使う • インストール後 dbt init コマンドでプロジェクトを初期化できる
コンセプト • dbt_project.yml, profiles.yml ◦ 設定ファイル • models/*.sql ◦ モデルファイル
• models/*.yml ◦ スキーマファイル
dbt モデル • SQLファイル ◦ dbt ではモデルと呼ぶ。変換内容を定義する ◦ Jinja テンプレートで拡張されており、他のモデルの結果を参照できる
◦ dbt が依存関係を解決してくれて、SELECT の結果をテーブルやビューと して保存する • YAMLファイル ◦ モデルのメタデータを定義する
dbt を実⾏してみる • 事前にデータを DuckDB にロードしておく ◦ データウェアハウスへのデータ投⼊は dbt のスコープ外
• dbt build コマンドを実⾏するだけ ◦ DuckDB にテーブルが⽣成される • ドキュメントの⽣成もできる ◦ dbt docs generate ◦ dbt docs serve
デモ
dbt を使い込むと • ディメンショナル‧モデリングという、分析に特化したモデリング⼿法がある ◦ モデリング済みのテーブルを Looker や Tableau に接続すると、SQLが書
けなくても分析やダッシュボードの作成ができる • タイミーでは1000以上のモデルを管理している ◦ モデルをレイヤリングして秩序を保つ必要がある
dbt まとめ • SQL と YAML で変換処理をコード管理できる • 再利⽤可能なモデルでコラボレーションしやすい •
冪等な処理で CI/CD への統合も容易にできる
信頼性に話を戻します
3 データの信頼性とは何か
データの信頼性とは • 信頼できるデータ = 品質が担保されているデータ • タイミーで重視しているデータ品質の評価軸 特性 意味 完全性
データが⽋損していないか 適時性 必要な時にすぐにデータを参照できるか ⼀意性 データが重複していないか ⼀貫性 型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか
データの信頼性を損なうとどうなるか • 必要なときにデータが参照できない • 誤った意思決定や機械学習モデルの精度低下を引き起こす
データの信頼性を損なうタイミング • 転送パイプラインの障害 • 変換ロジックの誤り • 意図しないデータソースの仕様変更
転送パイプラインの障害 停⽌ • 適時性を損なう
変換ロジックの誤り • LEFT JOIN すべきところで INNER JOIN してレコードが減ってしまった • ⼀意だと思った列に重複があり、
LEFT JOIN でレコードが膨れてしまった Aggregate
意図しないデータソースの仕様変更 • ⼿⼊⼒スプレッドシートのような、壊れやすいデータソースを扱うとき ◦ 作業していてカラム名が意図せず変わってしまった ◦ 結果、dbt の SELECT で存在しないカラムを指定してコケる
• アプリケーションのテーブルやカラムが削除されてしまったとき ◦ 同様に dbt で追従できずコケてしまう 停⽌ 停⽌
4 データの信頼性を⽀える 仕組みと技術
信頼性の⾼め⽅、守り⽅ • 信頼性が低下する要因を排除しよう • 可能な限りテストをやっていこう 特性 意味 完全性 データが⽋損していないか 適時性
必要な時にすぐにデータを参照できるか ⼀意性 データが重複していないか ⼀貫性 型‧タイムゾーン‧表記揺れなど、値の書式や意味が統⼀されているか
dbt による⼀貫した指標の定義 • 例えば ワーカーの リピート率[%] の定義は? • 分析の度にクエリ書くと定義が揺れてしまうリスクがある •
dbtモデルから参照する形を取れば、再計算不要で⼀貫した値を参照できる
不安定なデータを JSON Lines 化して安全に扱う ⼿⼊⼒CSVのような、壊れやすいデータソースを扱いたいとき • 各レコードを JSON ⽂字列に変換して、ワンカラムとしてまとめる •
BigQuery にロードする • dbt モデルで JSON ⽂字列をパースして、列として抽出する 存在しない列を SELECT しても null として抽出できる
データ転送前後の⾏数⽐較で完全性を守る • RDSからBigQueryにロードするときに、⽋損がないか⾏数を⽐較する • GitHub Actions などでスクリプトを動かて監視
dbt によるテスト • データテスト • ユニットテスト • データ鮮度チェック
dbt によるデータテスト 実際のテーブルデータに対するテスト • Generic data tests ◦ スキーマファイルにテストを定義できる ◦
列に対して UNIQUE や NOT NULL の検証 ◦ 別モデルの外部キーを持つか、離散値の検証 • Singular data tests ◦ テスト⽤の任意のSQLファイルを作成して、結果が0⾏であることを検証 できる
dbt によるユニットテスト テストデータを与えて、期待する結果となるか検証する • 複雑なロジックや重要指標の定義が間違っていないか • 正規表現が間違っていないか テスト駆動開発が実践できるようになった
dbt によるデータ鮮度のチェック 1時間に1回テーブルにインサートされるはずのに、 updated_at 列が古いままだ と怪しい… 期待するテーブルの更新頻度を記述して、ちゃんと更新されているか検証できる
信頼性の⾼め⽅、守り⽅ 特性 信頼性の守り⽅ 完全性 転送前後の⾏数⽐較 dbt によるデータテスト 適時性 不安定なデータの JSON
Lines 化(パイプライン停⽌を避ける) dbt によるデータ鮮度チェック ⼀意性 dbt によるデータテスト ⼀貫性 dbt による⼀貫した指標の定義 dbt によるユニットテスト
信頼性の⾼め⽅、守り⽅
5 データ基盤の課題と これから
タイミーのデータ基盤の現状 • Good ◦ これまで紹介した⽅法により、特定のデータソースやユースケースに対 するデータの信頼性を担保しやすい環境が整っている • More ◦ データソースとユースケースが多様化する中、中央のデータチームだけ
で社内のあらゆるドメインロジックや業務で期待されるデータ品質を把 握して、維持運⽤していくのが困難になりつつある
タイミーのデータ基盤の現状 引⽤元:[Data Mesh Manager公式サイト](https://www.datamesh-manager.com/)
理想形としてデータメッシュに期待 • データメッシュとは、⼀⾔でデータ基盤のマイクロサービス化 ◦ データプロダクトと呼ばれる単位でデータ基盤と開発チームを分離 ◦ データプロダクト同⼠のインターフェイスとして、データコントラクト を定義 ◦ 横串でプラットフォームチームが⽀える体制
理想形としてデータメッシュに期待 引⽤元:[Data Mesh Manager公式サイト](https://www.datamesh-manager.com/)
データプロダクト データプロダクト 理想形としてデータメッシュに期待 データ ソース データプロダクトのオーナー 処理 いい感じの モデル インフラ
/ モニタリング環境 データプロダクト DRE インフラ インフラ
とはいえ、⼀気に進めるのは難しい 組織体制の変更とデータ基盤のプラットフォーム化を⼀気に進めるのは難しい • データプロダクトの開発‧運⽤のケイパビリティを持つ⽅が稀有 ◦ 開発部⾨はともかく、事業部にエンジニアがいることは稀 • データ基盤のプラットフォーム化も、上⼿くいくか不透明でリスクが⾼い ◦ 銀の弾丸などない
特定の重要なユースケースに絞って検証していく • データプロダクトのスコープの定義 • データプロダクトの⼊出⼒のインターフェイスの定義 • データプロダクトの開発の伴⾛ • 部分的なプラットフォーム化の実施 •
データプロダクト開発⽂化の醸成 ◦ 開発‧運⽤ガイドラインの⽂書化や勉強会の開催など
6 まとめ
まとめ • データの信頼性は地道なテストの積み重ねで⾼めることができる ◦ dbt の功績が⼤きい • 多様で複雑なデータ基盤のニーズに素早く応えるには、組織体制含めた リアーキテクチャが必要そう ◦
試⾏錯誤しながら実績を積み上げていきたい
https://hrmos.co/pages/timee/jobs/1682251404118319115 データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう! We're hiring!