Ubieのデータ品質の検査・維持・向上への取り組み データ基盤管理の考え方 〜dbtの極意〜 Lunch LT 2023 / 08/ 22 Motoyuki Oki / @okiyuki99

2 自己紹介 Motoyuki Oki X(Twitter): @okiyuki99 今：Ubie 株式会社のアナリティクスエンジニア。 誰もが早く・正確に・安全にデータ利活用できるように、 データ整備 / データマネジメント / データガバナンス をやっています 最近の関心：引っ越し準備

3 テクノロジーで人々を 適切な医療に案内する 創業背景となる課題意識： • 患者が最適なタイミングで最適な医療機関を 受診できていない • 医師が目の前の患者の病気を熟知しているとは限らない • 医師が最新・最適な治療を知っているとは限らない ミッション

4 toC 主要プロダクト AI問診エンジンをコア技術として、一般生活者・医療機関それぞれへのプロダクトを展開 症状から受診の手がかりがわかる toB 診察事務を1/3に効率化 導入施設 47都道府県 1,400超 利用者数 月間 万人超 700

5 ケーススタディ：希少疾患の患者発見プロジェクトにおける実際の事例 製薬企業との協業で、実際に希少疾患の患者を適切な医療に案内できた事例も出始める ユビー利用による”適切な医療への案内 ” ユーザーのプロファイル • 30代女性 • 20歳の頃から3か月に1回程度激しい 腹痛や下痢に悩まされていた • 手足や顔が腫れることも多く皮膚科を 受診したこともあるが原因はわからず Google検索 ユビー利用 関連病名確認 受診 治療開始 いつもの症状が 出現し不安になり 「手足 腫れる」で検索 ユビーというサービスを発見。 関連病名が調べられるらしい。 早速問診に回答してみる とある難病の可能性が出現。 専門医がいることを知る 長年原因不明だったこともあり、 早速専門医を受診。 どうやらユビーで出てきた病気らしい 薬を処方され、10年以上 悩まされていた症状が 緩和傾向。寛解を目指す

6 Ubieはデータの会社 データの価値 = 事業価値 ● データ利活用によるプロダクト改善・グロース活動以外に、顧客レポーティングのようにデータ自体が顧客価値と密接 ● （自分目線で）高品質なデータ基盤の構築にエンジニアのリソースを厚く投下している データ品質への思い ● 統計情報だけでなく、一人ひとりのユーザーの行動データ分析が重要 ○ 1件の数値ズレが情報としての価値を大きく毀損する可能性がある ● レポート先が社外であり、顧客との信頼関係の構築も求められる ○ 社内分析での利活用とは異なり、求められる品質水準が極めて高い →今日はデータ品質の検査・維持・向上の取り組みについて話します

7 （簡単に）Ubie の データ利活用部分アーキテクチャ DWHとしてはBigQuery / dbt は OSSのdbt-coreのみ利用 / BIツールとしてLightdashを導入中

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

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

10 データの品質の検査 ~ dbt test~ データのテスト（not_null / unique / accepted_values / …. ) により、期待したデータになってるか検査 Case 3: 複数カラムで unique testにより テーブル構造の担保・理解しやすくなる ref: データ品質を支える dbt test ~Ubieの事例を添えて~

11 データの品質の維持 dbt testの結果をデータマート開発プロセス上で確認できるように、 CIを整備している 開発時 ref: Ubie Tech Talk で、「2021/12/14 dbt 運用の7つの疑問と対策」という発表をしました。

12 データの品質の維持 定常業務として、日々・週次の運用を継続して回している 日次 dbt build が毎日キックされるので、エラーがあると Slackに投稿される。エラー時に、 Analytics Engineer で当番制で確認・1 次対応を行う 週次 Data Engineer + Analytics Engineer の週次MTGのメトリクスとして確認 ● elementary の dbt packageを利用。alerts_dbt_models / alerts_dbt_tests のデータを使って独自ダッシュボード構築 ● 直近週のエラー結果から見落としないか / 改善できないかの確認 ● （dbt以外にも）BigQuery コストや 不適切な利用がないかも確認

13 データの品質の維持 そもそもデータ品質を維持するダッシュボード明瞭化のために dbt exposuresを活用。運用に組み込んでいる 運用例： ● ダッシュボード構築系のPBIのチケットテンプレートでサブタスクに明示的に追加 ● ダッシュボードオーナーの明示化 ○ チームSlackメンショングループと対応させる ● ダッシュボードだけでなく、データマートの変更があったら伝えてほしいチームを明瞭化 ○ Github PRレビューに入れるなどの判断に利用 ● elementary の dbt package の dbt_exposures を使って、ダッシュボードまとめダッシュボードも作れる ● 四半期の最終週は、ダッシュボードの棚卸し ○ 古くなったダッシュボードは exposuresは削除するなど

14 データの品質の向上 データ品質の向上には、データ取得の段階から手をいれるのが肝。各ドメインチームのエンジニアへの浸透が重要。 1.dbt test の エラー時に ● testの各エンジニアとの認識合わせ ○ test実施の浸透 ○ 別のログを条件にtestした方がよいかどうか 2.データマート開発時に ● そのマートをメインで利用するチームのエンジニアへレビュー ○ 元データが欠損するとどこのtestが落ちるかを理解・浸透 ● 新規データの配置やデータ追加については、各チームのエンジニアが実施している（ドキュメント拡充） ○ 個人情報の確認 ○ column description ○ 簡単なdbt testテストの実装

15 データの品質の向上 3.ログ取得の時に ● ログテンプレート(Notion)を活用して、野良ログが無くなるように ○ not null条件やaccepted values テストで制御するための情報 ○ 例：どの画面で発火するか / どういう操作をしたときにログが発火するか / …. ● デザインレビュー時には、取得方法や保存方法についてData / Analytics Engineerとのアライン データ品質の向上には、データ取得の段階から手をいれるのが肝。各ドメインチームのエンジニアへの浸透が重要。

16 今後やっていきたいこと オーナーシップ醸成 ● Analytics Engineerが初手対応せずとも、各チームが主でデータ品質の向上が進むように ● 新しいデータ導入後、dbt test実装まで装着できるように データ利活用のセルフサービス化 ● dbtを中心としたデータ利活用の一貫した体験を作るために、Lightdashを用いてセルフサービス化を推し進める ● データカタログやデータプライバシー周りとの接合も進行中

17 We are hiring！ データ系職種複数募集中です。データ関連職種ページ（QRコード）も最近更新しましたのでぜひご覧ください！ カジュアル面談もよければ！