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

Ubieのデータ品質の検査・維持・向上への取り組み

okiyuki
August 22, 2023

 Ubieのデータ品質の検査・維持・向上への取り組み

2023-08-22 データ基盤管理の考え方 〜dbtの極意〜 Lunch LT の登壇資料です

okiyuki

August 22, 2023
Tweet

More Decks by okiyuki

Other Decks in Technology

Transcript

  1. 5 ケーススタディ:希少疾患の患者発見プロジェクトにおける実際の事例 製薬企業との協業で、実際に希少疾患の患者を適切な医療に案内できた事例も出始める ユビー利用による”適切な医療への案内 ” ユーザーのプロファイル • 30代女性 • 20歳の頃から3か月に1回程度激しい

    腹痛や下痢に悩まされていた • 手足や顔が腫れることも多く皮膚科を 受診したこともあるが原因はわからず Google検索 ユビー利用 関連病名確認 受診 治療開始 いつもの症状が 出現し不安になり 「手足 腫れる」で検索 ユビーというサービスを発見。 関連病名が調べられるらしい。 早速問診に回答してみる とある難病の可能性が出現。 専門医がいることを知る 長年原因不明だったこともあり、 早速専門医を受診。 どうやらユビーで出てきた病気らしい 薬を処方され、10年以上 悩まされていた症状が 緩和傾向。寛解を目指す
  2. 6 Ubieはデータの会社 データの価値 = 事業価値 • データ利活用によるプロダクト改善・グロース活動以外に、顧客レポーティングのようにデータ自体が顧客価値と密接 • (自分目線で)高品質なデータ基盤の構築にエンジニアのリソースを厚く投下している データ品質への思い

    • 統計情報だけでなく、一人ひとりのユーザーの行動データ分析が重要 ◦ 1件の数値ズレが情報としての価値を大きく毀損する可能性がある • レポート先が社外であり、顧客との信頼関係の構築も求められる ◦ 社内分析での利活用とは異なり、求められる品質水準が極めて高い →今日はデータ品質の検査・維持・向上の取り組みについて話します
  3. 8 データの品質の検査 ~ dbt test~ データのテスト(not_null / unique / accepted_values

    / …. ) により、期待したデータになってるか検査 Case 1: 特定の期間だけ担保したいときなど、 特定の条件下でのnot_null test ref: データ品質を支える dbt test ~Ubieの事例を添えて~
  4. 9 データの品質の検査 ~ dbt test~ データのテスト(not_null / unique / accepted_values

    / …. ) により、期待したデータになってるか検査 Case 2: 意図した数値範囲のデータか test ref: データ品質を支える dbt test ~Ubieの事例を添えて~
  5. 10 データの品質の検査 ~ dbt test~ データのテスト(not_null / unique / accepted_values

    / …. ) により、期待したデータになってるか検査 Case 3: 複数カラムで unique testにより テーブル構造の担保・理解しやすくなる ref: データ品質を支える dbt test ~Ubieの事例を添えて~
  6. 12 データの品質の維持 定常業務として、日々・週次の運用を継続して回している 日次 dbt build が毎日キックされるので、エラーがあると Slackに投稿される。エラー時に、 Analytics Engineer

    で当番制で確認・1 次対応を行う 週次 Data Engineer + Analytics Engineer の週次MTGのメトリクスとして確認 • elementary の dbt packageを利用。alerts_dbt_models / alerts_dbt_tests のデータを使って独自ダッシュボード構築 • 直近週のエラー結果から見落としないか / 改善できないかの確認 • (dbt以外にも)BigQuery コストや 不適切な利用がないかも確認
  7. 13 データの品質の維持 そもそもデータ品質を維持するダッシュボード明瞭化のために dbt exposuresを活用。運用に組み込んでいる 運用例: • ダッシュボード構築系のPBIのチケットテンプレートでサブタスクに明示的に追加 • ダッシュボードオーナーの明示化

    ◦ チームSlackメンショングループと対応させる • ダッシュボードだけでなく、データマートの変更があったら伝えてほしいチームを明瞭化 ◦ Github PRレビューに入れるなどの判断に利用 • elementary の dbt package の dbt_exposures を使って、ダッシュボードまとめダッシュボードも作れる • 四半期の最終週は、ダッシュボードの棚卸し ◦ 古くなったダッシュボードは exposuresは削除するなど
  8. 14 データの品質の向上 データ品質の向上には、データ取得の段階から手をいれるのが肝。各ドメインチームのエンジニアへの浸透が重要。 1.dbt test の エラー時に • testの各エンジニアとの認識合わせ ◦

    test実施の浸透 ◦ 別のログを条件にtestした方がよいかどうか 2.データマート開発時に • そのマートをメインで利用するチームのエンジニアへレビュー ◦ 元データが欠損するとどこのtestが落ちるかを理解・浸透 • 新規データの配置やデータ追加については、各チームのエンジニアが実施している(ドキュメント拡充) ◦ 個人情報の確認 ◦ column description ◦ 簡単なdbt testテストの実装
  9. 15 データの品質の向上 3.ログ取得の時に • ログテンプレート(Notion)を活用して、野良ログが無くなるように ◦ not null条件やaccepted values テストで制御するための情報

    ◦ 例:どの画面で発火するか / どういう操作をしたときにログが発火するか / …. • デザインレビュー時には、取得方法や保存方法についてData / Analytics Engineerとのアライン データ品質の向上には、データ取得の段階から手をいれるのが肝。各ドメインチームのエンジニアへの浸透が重要。
  10. 16 今後やっていきたいこと オーナーシップ醸成 • Analytics Engineerが初手対応せずとも、各チームが主でデータ品質の向上が進むように • 新しいデータ導入後、dbt test実装まで装着できるように データ利活用のセルフサービス化

    • dbtを中心としたデータ利活用の一貫した体験を作るために、Lightdashを用いてセルフサービス化を推し進める • データカタログやデータプライバシー周りとの接合も進行中