マイベストのデータ基盤の現在と未来 updated November 8, 2024

● マイベストのデータ基盤（データ分析基盤）を 現在 → 近未来（直近半年〜1年ぐらいで目指す形） → 未来（1年後〜で目指す形）の3フェーズに分けて紹介します ● データエンジニアリングの基礎的な知識がある方に読んでいただく前提で、具体的な技術の話にも言及します とはいえ、そこまで踏み込んで言及している箇所は少ないので、専門知識がなくても読み進められると思います！ ● 以下の内容には言及しません ○ 現在の技術スタックの選定理由 ○ 社内でのデータ活用推進（いわゆるデータの民主化）に向けた教育や文化醸成の話 ○ データ基盤の開発運用に必要な体制や組織の話 この資料について

品原 悠杜 Yuto Shinahara データエンジニア｜経営企画部 データサイエンスチーム 九州大学大学院にてコンピュータビジョンの研究に従事。大手通信企業を経て、 2020年7月に㈱アイデミー入社。社内データ基盤の立ち上げ・運用をリードした後、 データサイエンス部部長として法人向けDXソリューション事業のデータサイエンス 領域を牽引。2024年10月より㈱マイベストにジョイン。 プロフィール

会社概要 Index 1 データ基盤のあらまし 2 現在のデータ基盤とその課題 3 未来のデータ基盤 4 さいごに 5

会社概要

No content

No content

No content

No content

データ基盤のあらまし

CTOの渡邉さんが課題提起から社内ヒアリングまでオーナーシップをもって推進 動き出しは2020年

実際の立ち上げに伴う開発のリードや、運用ルールの制定、立ち上げ後の社内向けの説明・レクチャーなどもCTO自ら推進 本格的に立ち上がったのは2021年 導入だけで終わらないために...mybestが分析基盤の運用を初めてから 1年が経ったので導入事例を共有します (Note, 2022)

本格化後もCTO + インターン + 業務委託の体制で対応（以下も含め、ここまで引用してきた資料はすべてCTOお手製…） 2023年頃からデータ基盤の利用が本格化 分析基盤のコストを削減した話 (ハッカー鮨, 2023)

● データ組織の立ち上げに向けて採用活動にアクセル ○ データ基盤の話以外にも、攻めのデータ活用に対する社内ニーズも非常に高まっていた（現在進行系） ● その後のタイムライン ○ 7月末: 現データサイエンスチームマネージャーと私のジョインがほぼ同時期に決定 ○ 8月: マネージャーの入社を機に「データサイエンスチーム」が発足 → この時点で、チームメンバーはマネージャー + 2年目（他部署から合流）の2名体制 ○ 10月: データサイエンスチームがプロダクト開発部 → 経営企画部傘下に異動 ○ 10月中旬: 品原入社。データ基盤周りの主担当に ←今ココ 2024年に突入すると いよいよ従来体制では運用がキャパオーバー気味に

現在のデータ基盤とその課題

データで見るマイベスト 5,200万 3,100万 1,700億 560万 月間ユニークユーザー数 テーブルレコード数合計 商品数 月間セッション数 ※ いずれも2024年10月時点の実績

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 スプレッド シート

構成図: 現在のデータ基盤 限られたテーブルにのみ アサーション設定済

課題感がお分かりいただけただろうか？ この図だけで全部分かったあなたはぜひ当社へ！！！

1. データの品質担保が不十分 2. Warehouseレイヤーのカバレッジが低い 3. SQLワークスペース用途で BigQUery と Re:dash, BI用途で Looker Studio と Re:dash が混在している 4. BigQueryコストの肥大化 5. メタデータの不足 6. TROCCOの中がカオスに 7. メタ的に）これまでの課題を定量的にモニタリングできていない 8. BigQueryに集約できていないデータソースがある 現行データ基盤の主な課題一覧

ここでいう品質は2つ ● 「中身が意図した値になっているか」の品質 ○ 具体的には、Dataformのアサーションがほとんど書けていない ○ Primary KeyのユニークチェックやNULLチェックもまだまだ ○ 況や、より高度なカスタムアサーションをや… ● 「テーブルを最新化できているか」の品質 ○ ELTバッチ処理のエラー通知が形骸化、「運用でカバー」状態 → クリティカルなエラーを見逃すリスク ○ Cloud Loggingでサクッと作れるSlack通知は便利だがUXが悪い... 今期から経営ダッシュボードの数値等も本データ基盤より算出することに なったため、データの品質担保は最重要ミッション 1. データ品質担保が不十分 限られたテーブルにのみ アサーション設定済

● WarehouseレイヤーのテーブルがMartレイヤーライクな設計になっているものが多く、 「とりあえずこのテーブルをベースにクエリ叩けばOK!」という状態が作れていない → Lakeレイヤーまで遡ってクエリを叩かないと分析・可視化ができないケースがしばしば発生 ● 以下の観点でよろしくない ○ データの正確性down 例外処理を施す前のrawデータに対して「オレオレクエリ」を書いてしまって、 本来は除外すべきデータも含めて分析・可視化をしてしまうリスクあり ○ 分析者の工数up select * from xxx で完結しないので、複雑なクエリを書く必要があり、試行錯誤や調査など リードタイムが発生してしまう ○ コストup Lakeレイヤーには数百GB〜TB級のテーブルがわんさか。 無邪気にselect * from xxx を実行すると、クエリ1発で1,000円以上溶けるケースも 2. Warehouseレイヤーのカバレッジが低い

● データ基盤が立ち上がるまでは 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を参照しにいくために使っていたもので、そこに相乗りす る形で分析用途でも利用されるようになった

● 2023年末には7万円/月まで下がるも、データソース数の増加や クエリユーザー数の増加によって元の水準程度まで浮上 ● ユーザー数増は嬉しい悲鳴では？ → No. もっとコスト減らせる ○ パーティショニング・クラスタリングされていない巨大テーブル ○ パーティショニングはされているが、パーティション指定せずとも 叩けてしまう巨大テーブル ○ 差分appendでなく毎日 full-refresh をかけている巨大テーブル ● 「2. Warehouseレイヤーのカバレッジが低い」にも関連して、 さまざまなクエリでサブクエリとして定義されている共通処理をテーブル として切り出せていない → その中に不用意に巨大なテーブルを参照する 処理が含まれていると「金食いクエリ」になってしまう 4. BigQueryのコスト肥大化 分析基盤のコストを削減した話 (ハッカー鮨 2023)

● データカタログの整備がまだ行き届いていない ○ 特にカラムdescriptionの記入率が低い ○ 社内で内製しているクエリ生成Bot（右図参照）も カラムdescriptionが増えないことには賢くならなりづらい ● 以下の観点で好ましくない ○ 分析者のデータ活用モチベーションdown せっかく自分でクエリ書こうと思ったのに、使い方がさっぱり分 からなくて萎える ○ データサイエンスチームへの質問量up 「メタデータを見れば不明点解消」とならないので、 必然的に社内のデータ専門家 = 我々に質問せざるをえない 5. メタデータの不足 ※ 詳細はデータサイエンスチームの若きエースのNoteにて↓ 新卒2年目が「社内データのドメイン知識が超属人化 し、データ人材のリソースが枯渇する」危機に生成AI で立ち向かった話

● 導入時から想定はしていた運用負荷の課題が具現化してきた ● データソース20件、データ転送300件overの棚卸しができていない ○ DWHに転送してはいるが、何も処理をしておらず野良テーブルと化しているもの ○ 手軽に他の手段で代替可能なのにわざわざTROCCOを使っているケース ■ 例: BigQuery → スプシへのデータ転送。それって本当にコネクテッドシート機能で代替できない？ ● データ転送の作成ルールや命名規則についてのガバナンスも効かせられていない 6. TROCCOの中がカオスに

● 「Dataformのアサーションがほとんど書けていない」、「バッチ処理の失敗頻度がぼちぼち多い」、 「Warehouseレイヤーのカバレッジが低い」、「カラムdescriptionの記入率が低い」等と課題を挙げてきた ● 具体的にどのぐらい？ → わかりません ○ 厳密には、アドホックに定量で算出することは可能だが、それをモニタリングできる状態にできていない 7. メタ的に）これまでの課題を定量的にモニタリングできていない

あります。たくさん 8. BigQueryに集約できていないデータソースがある

課題は山積み・・・

● これまで書いてきた内容に前任を責める意図は一切なし ○ CTOをはじめ、データ基盤のバトンを繋いできてくれた方々には感謝とリスペクトの念しかありません ○ 社内にデータ基盤が存在していることは決して当たり前のことではない ● 課題があって当然 ○ データサイエンスチームが発足するまでは、CTO + 業務委託でデータ基盤のすべてを見ていた → リソース的な限界で、対応したくてもできなかったことがたくさん あとはまかせろ！！！！！！（プレッシャー）（がんばろ）（gkbr） ただ、これだけは言わせてください！

未来のデータ基盤

前述の課題をつぶした先に描いている 近未来のデータ基盤の姿がこちら

構成図: 近未来のデータ基盤（直近半年〜1年ぐらいで目指す形）

構成図: 近未来のデータ基盤（直近半年〜1年ぐらいで目指す形） ①必要なテーブル全てに アサーション設定 ⑤データカタログ拡充 ⑥TROCCO棚卸し → 不要なデータ転送削除 ⑧対応データソース追加 ②Warehouse, Mart拡張 → Lake を直接叩かなくても済むように ④Warehouse整備によるコスト肥大化防止 ③Re:dash廃止 ③Re:dash廃止 ⑦データ基盤ヘルススコアのモニタリング

これでめでたしめでたし… ではない

● 事業発展に伴う新しい検討事項 ○ 新しいパターンのデータソース（外部データ、画像データ等）への対応ニーズが出現 ○ データセキュリティの堅牢化 ● テーブル数up → データカタログのメンテナンスコストup ○ ここのメンテナンスは人手で泥臭くやっていくしかない部分もある → メタデータ記入の負荷を下げるための工夫が必要になってくると予想 (cf. dbt-osmosis) ● ライトユーザー目線では依然として高い分析のハードル ○ ここまで言及してきたものがすべて完成したとしても、分析者目線ではこれでようやくスタート地点に立った状態 近未来のデータ基盤でも依然として残るであろう課題

これらを踏まえ、さらに先に描いている 未来のデータ基盤の形がこちら

構成図: 未来のデータ基盤（1年後〜で指す形） メンテナンスコストを軽 減するための仕組み導入 データセキュリティ強化 新しいデータソースへの対応 一般ユーザーも手軽に 分析ができる環境作り より高機能なデータカタログ ツールへの移行（仮）

さいごに

現在 マイベストのデータ基盤を 現在 → 近未来（直近半年〜1年ぐらいで目指す形） → 未来（1年後〜で目指す形）の3フェーズに分けて紹介 まとめ 未来（1年後〜で目指す形）

● データ基盤運用工数0.5人月down → 浮いた工数を攻めのデータ活用に ○ メインドライバーとして、以下の類の問い合わせ・不具体に対応する時間削減を見込み ■ 「このデータこれであってる？」 ■ 「このデータってどのテーブル・カラム使えば出せる？」 ■ 「このデータ出したいんだけど、Warehouseにそれっぽいテーブルがない」 ● 「エラー通知が来ないことが当たり前、エラー通知が来たらそれはすべて対応が必要なもの」という 余計なことを考えなくて済む業務環境 ● Google Cloudの利用料: 〜10万円/月 未来のデータ基盤がもたらす世界

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

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

データ基盤ヘルススコアのダッシュボード化 テーブルの鮮度、Warehouse, Martレイヤーでのクエリカバー率、 description記入率などのデータ基盤の健全度合いを表す指標を定義 し、それらの推移を時系列で追えるようにダッシュボード化 よく使われるテーブルのコスト最適化 様々なWarehouseの参照先になっている巨大なWebアクセスログの テーブルにパーティショニングを設定 & クエリ実行時のパーティショ ニング必須設定をON → 1クエリ実行あたりのコストを1/1000以下に 私の入社後、課題として取り上げたものの一部はすでに着手・解消済

とはいえ、まだ道のりは果てしない。 さらに、今回取り上げたこと以外にも やりたいことはたくさんあるので…

WE’RE HIRING! Recruiting Site