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

マイベストのデータ基盤の現在と未来 / mybest-data-infra-asis-tobe

mybest
November 08, 2024

マイベストのデータ基盤の現在と未来 / mybest-data-infra-asis-tobe

株式会社マイベストのデータ基盤に関する説明資料です。

mybest

November 08, 2024
Tweet

More Decks by mybest

Other Decks in Technology

Transcript

  1. • データ組織の立ち上げに向けて採用活動にアクセル ◦ データ基盤の話以外にも、攻めのデータ活用に対する社内ニーズも非常に高まっていた(現在進行系) • その後のタイムライン ◦ 7月末: 現データサイエンスチームマネージャーと私のジョインがほぼ同時期に決定 ◦

    8月: マネージャーの入社を機に「データサイエンスチーム」が発足 → この時点で、チームメンバーはマネージャー + 2年目(他部署から合流)の2名体制 ◦ 10月: データサイエンスチームがプロダクト開発部 → 経営企画部傘下に異動 ◦ 10月中旬: 品原入社。データ基盤周りの主担当に ←今ココ 2024年に突入すると いよいよ従来体制では運用がキャパオーバー気味に
  2. Googleスイートに寄せたシンプル・ベーシックな構成 ラベル 特筆すべき特徴 • テラバイト級の巨大なテーブルがちらほら ∵ 月間3,000万UU規模のサービスのWebアクセスログ • データソースの数が多い データ基盤のざっくりプロフィール

    Transformation BI DWH Extract&Load Data Sources • サービスのDB • Webアクセスログ • 広告売上データ • etc. • TROCCO • スクラッチ実装 (Cloud Run / Cloud Functions) Dataform (Cloud) BigQuery • Looker Studio • Re:dash • Google スプレッド シート
  3. 1. データの品質担保が不十分 2. Warehouseレイヤーのカバレッジが低い 3. SQLワークスペース用途で BigQUery と Re:dash, BI用途で

    Looker Studio と Re:dash が混在している 4. BigQueryコストの肥大化 5. メタデータの不足 6. TROCCOの中がカオスに 7. メタ的に)これまでの課題を定量的にモニタリングできていない 8. BigQueryに集約できていないデータソースがある 現行データ基盤の主な課題一覧
  4. ここでいう品質は2つ • 「中身が意図した値になっているか」の品質 ◦ 具体的には、Dataformのアサーションがほとんど書けていない ◦ Primary KeyのユニークチェックやNULLチェックもまだまだ ◦ 況や、より高度なカスタムアサーションをや…

    • 「テーブルを最新化できているか」の品質 ◦ ELTバッチ処理のエラー通知が形骸化、「運用でカバー」状態 → クリティカルなエラーを見逃すリスク ◦ Cloud Loggingでサクッと作れるSlack通知は便利だがUXが悪い... 今期から経営ダッシュボードの数値等も本データ基盤より算出することに なったため、データの品質担保は最重要ミッション 1. データ品質担保が不十分 限られたテーブルにのみ アサーション設定済
  5. • WarehouseレイヤーのテーブルがMartレイヤーライクな設計になっているものが多く、 「とりあえずこのテーブルをベースにクエリ叩けばOK!」という状態が作れていない → Lakeレイヤーまで遡ってクエリを叩かないと分析・可視化ができないケースがしばしば発生 • 以下の観点でよろしくない ◦ データの正確性down 例外処理を施す前のrawデータに対して「オレオレクエリ」を書いてしまって、

    本来は除外すべきデータも含めて分析・可視化をしてしまうリスクあり ◦ 分析者の工数up select * from xxx で完結しないので、複雑なクエリを書く必要があり、試行錯誤や調査など リードタイムが発生してしまう ◦ コストup Lakeレイヤーには数百GB〜TB級のテーブルがわんさか。 無邪気にselect * from xxx を実行すると、クエリ1発で1,000円以上溶けるケースも 2. Warehouseレイヤーのカバレッジが低い
  6. • データ基盤が立ち上がるまでは Re:dash がメインのSQLワークスペース兼BIツールだった。 その名残で Re:dash を使い続けているチーム、BigQuery / Looker Studio

    にシフトしているチームが混在していて、 そこに対してデータ組織がガバナンスを効かせられていない • ツールに関するナレッジが分散して好ましくないのでどちらかに寄せたい → BigQuery / Looker Studio に寄せる想定 • Re:dash のデメリット ◦ SQL実行時にカラムdescription等のメタデータがぱっと見れない ◦ GeminiによるSQLコーディング補助や、Looker Studioからのレポート自動作成といった機能にあやかれない ◦ 共用のサービスアカウントを使っている → クエリログだけでは個人が特定できない ◦ マイベスト固有の事情 ▪ データ基盤外のDBにアクセスできてしまう ▪ VPNアカウントがないとアクセスできない 3. SQLワークスペース用途で BigQuery と Re:dash, BI用途で Looker Studio と Re:dash が混在している もともとマイベストのRe:dashは開発チームがprd/stg環境の DBを参照しにいくために使っていたもので、そこに相乗りす る形で分析用途でも利用されるようになった
  7. • 2023年末には7万円/月まで下がるも、データソース数の増加や クエリユーザー数の増加によって元の水準程度まで浮上 • ユーザー数増は嬉しい悲鳴では? → No. もっとコスト減らせる ◦ パーティショニング・クラスタリングされていない巨大テーブル

    ◦ パーティショニングはされているが、パーティション指定せずとも 叩けてしまう巨大テーブル ◦ 差分appendでなく毎日 full-refresh をかけている巨大テーブル • 「2. Warehouseレイヤーのカバレッジが低い」にも関連して、 さまざまなクエリでサブクエリとして定義されている共通処理をテーブル として切り出せていない → その中に不用意に巨大なテーブルを参照する 処理が含まれていると「金食いクエリ」になってしまう 4. BigQueryのコスト肥大化 分析基盤のコストを削減した話 (ハッカー鮨 2023)
  8. • データカタログの整備がまだ行き届いていない ◦ 特にカラムdescriptionの記入率が低い ◦ 社内で内製しているクエリ生成Bot(右図参照)も カラムdescriptionが増えないことには賢くならなりづらい • 以下の観点で好ましくない ◦

    分析者のデータ活用モチベーションdown せっかく自分でクエリ書こうと思ったのに、使い方がさっぱり分 からなくて萎える ◦ データサイエンスチームへの質問量up 「メタデータを見れば不明点解消」とならないので、 必然的に社内のデータ専門家 = 我々に質問せざるをえない 5. メタデータの不足 ※ 詳細はデータサイエンスチームの若きエースのNoteにて↓ 新卒2年目が「社内データのドメイン知識が超属人化 し、データ人材のリソースが枯渇する」危機に生成AI で立ち向かった話
  9. • 導入時から想定はしていた運用負荷の課題が具現化してきた • データソース20件、データ転送300件overの棚卸しができていない ◦ DWHに転送してはいるが、何も処理をしておらず野良テーブルと化しているもの ◦ 手軽に他の手段で代替可能なのにわざわざTROCCOを使っているケース ▪ 例:

    BigQuery → スプシへのデータ転送。それって本当にコネクテッドシート機能で代替できない? • データ転送の作成ルールや命名規則についてのガバナンスも効かせられていない 6. TROCCOの中がカオスに
  10. • これまで書いてきた内容に前任を責める意図は一切なし ◦ CTOをはじめ、データ基盤のバトンを繋いできてくれた方々には感謝とリスペクトの念しかありません ◦ 社内にデータ基盤が存在していることは決して当たり前のことではない • 課題があって当然 ◦ データサイエンスチームが発足するまでは、CTO

    + 業務委託でデータ基盤のすべてを見ていた → リソース的な限界で、対応したくてもできなかったことがたくさん あとはまかせろ!!!!!!(プレッシャー)(がんばろ)(gkbr) ただ、これだけは言わせてください!
  11. 構成図: 近未来のデータ基盤(直近半年〜1年ぐらいで目指す形) ①必要なテーブル全てに アサーション設定 ⑤データカタログ拡充 ⑥TROCCO棚卸し → 不要なデータ転送削除 ⑧対応データソース追加 ②Warehouse,

    Mart拡張 → Lake を直接叩かなくても済むように ④Warehouse整備によるコスト肥大化防止 ③Re:dash廃止 ③Re:dash廃止 ⑦データ基盤ヘルススコアのモニタリング
  12. • 事業発展に伴う新しい検討事項 ◦ 新しいパターンのデータソース(外部データ、画像データ等)への対応ニーズが出現 ◦ データセキュリティの堅牢化 • テーブル数up → データカタログのメンテナンスコストup

    ◦ ここのメンテナンスは人手で泥臭くやっていくしかない部分もある → メタデータ記入の負荷を下げるための工夫が必要になってくると予想 (cf. dbt-osmosis) • ライトユーザー目線では依然として高い分析のハードル ◦ ここまで言及してきたものがすべて完成したとしても、分析者目線ではこれでようやくスタート地点に立った状態 近未来のデータ基盤でも依然として残るであろう課題
  13. • データ基盤運用工数0.5人月down → 浮いた工数を攻めのデータ活用に ◦ メインドライバーとして、以下の類の問い合わせ・不具体に対応する時間削減を見込み ▪ 「このデータこれであってる?」 ▪ 「このデータってどのテーブル・カラム使えば出せる?」

    ▪ 「このデータ出したいんだけど、Warehouseにそれっぽいテーブルがない」 • 「エラー通知が来ないことが当たり前、エラー通知が来たらそれはすべて対応が必要なもの」という 余計なことを考えなくて済む業務環境 • Google Cloudの利用料: 〜10万円/月 未来のデータ基盤がもたらす世界
  14. 前述の世界を物語るメトリクス ???% ???件 約 50% 20% 15件 100% 5件以下 100%

    100% 30件以上 47% 100% 現在 未来 月間ETLエラー通知件数 (avg) Warehouse, Martレイヤーで のクエリカバー率 テーブル/カラムdescription 記入率 データ基盤に集約している データソース数 24h以内に更新されている テーブルの割合 利用頻度上位テーブルの Dataformアサーション カバー率
  15. 前述の世界を物語るメトリクス ???% ???件 約 50% 20% 15件 100% 5件以下 100%

    100% 30件以上 47% 100% 現在 未来 月間ETLエラー通知件数 (avg) Warehouse, Martレイヤーで のクエリカバー率 テーブル/カラムdescription 記入率 データ基盤に集約している データソース数 24h以内に更新されている テーブルの割合 利用頻度上位テーブルの Dataformアサーション カバー率 あれ?? モニタリングできてないって 書いてなかった?