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

10倍スケールを見越した データモデリングのリアーキテクチャ

Avatar for Tech Leverages Tech Leverages
February 02, 2025
220

10倍スケールを見越した データモデリングのリアーキテクチャ

Avatar for Tech Leverages

Tech Leverages

February 02, 2025
Tweet

More Decks by Tech Leverages

Transcript

  1. 1 © 2025 Leverages Co., Ltd. 10倍スケールを見越した データモデリングの リアーキテクチャ 2025/01/30

    みんなの考えた最強のデータアーキテクチャ  〜2025もやってきましょうSP!
  2. 3 © 2025 Leverages Co., Ltd. 森下 研人 レバレジーズ株式会社 テクノロジー戦略室

    データエンジニアリンググループ MGR • 日系SIerでDBエンジニアを経験後、 2019年11月にレバレジーズへジョイン • データエンジニア6年目 • データ基盤構築 / データマネジメント / データガバナンス / チーム作り / 採用 などなど幅広くやってます • 3歳で5kgの猫と同居してます 自己紹介 3 機密情報・転載禁止 © 2023 Leverages Co., Ltd.
  3. 4 © 2025 Leverages Co., Ltd. Contents 自己紹介
 会社紹介
 データ活用基盤


    データモデリングのリアーキテクチャ
 リアーキテクチャの効果
 今後の展望
 さいごに
 01. 02. 03. 04. 05. 06. 07.
  4. 6 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 会社概要 検討中 オフィス⽴地や社員数等最低限の情報

    (最新の数値に更新する) デザイン調整する 社名 従業員数 代表者 資本⾦ 所在地‧拠点 グループ会社 レバレジーズ株式会社 Leverages Co.,Ltd. 2,838名(2024年4⽉現在) 岩槻 知秀 5,000万円 本社:東京都渋⾕区渋⾕2丁⽬24番12号 渋⾕スクランブルスクエア24F‧25F 国内拠点:27拠点 海外拠点:3拠点 レバテック株式会社  レバレジーズM&Aアドバイザリー株式会社 ATLIKE株式会社 レバレジーズメディカルケア株式会社 レバレジーズオフィスサポート株式会社 レバレジーズプランニングサポート株式会社 レバレジーズスタッフィング株式会社 員点動⼒(上海)⼈⼒資源有限公司 Leverages Career Mexico S.A. de C.V. Leverages Career Vietnam Co., Ltd. Leverages U.S.Inc. 会社について
  5. 7 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 10年後に ⼀兆円規模を ⽬指す

    企業の安定性と成⻑性を担保する独⾃の経営戦略のもと、 創業以来、黒字経営を継続し、 2023年度は1,149億円を達成しました。 企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、 各個⼈の成⻑を促す」を掲げ、⼈の感情と向き合いながら 次の時代を創るグローバル企業を⽬指しています。 ベンチャーを牽引する成⻑で、 次代を創る企業へ 売上推移 会社について
  6. 8 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ポートフォリオ経営とは、業界やビジネスモデルなどにこだわらず、 分散投資をしていく経営形態のこと。 この経営形態のメリットは、予測困難な外部変化に会社全体で衝撃を

    吸収しやすい点にあります。例えば、コロナ禍では海外事業などは打 撃を受けた⼀⽅で、IT事業や医療‧ヘルスケア事業は追い⾵を受け、 過去最⾼の売上を更新、黒字経営を継続しました。 経営のリスク分散を⾏うことで、未曾有の状況でも安定した成⻑を実 現しています。 ポートフォリオ経営による安定した 収益基盤で創業以来、黒字経営を継続 経営体制について 会社について
  7. 9 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 「⻑期的に市場の成⻑性が⾒込まれること」「社会や⼈の負を解決す ること」を市場参⼊軸とし、現在は、IT、医療‧介護‧ヘルスケア、 M&A、SaaS、海外、若年層などの領域で、約50の事業を展開中。

    今後、より収益が安定し、⼤規模な投資が可能になれば、エネルギー や⾷料、宇宙産業など、世界の課題を解決するための事業を展開して いきます。 世界を視野に、 国や業界にとらわれない事業展開 事業数の推移 事業展開 事業について
  8. 10 © 2025 Leverages Co., Ltd. • データサイエンティスト:2名 • データアナリスト:4名

    • データアーキテクト:8名 • データエンジニア:3名 • 機械学習エンジニア:3名 • 機械学習研究:1名 レバレジーズのデータ関連職種 社員数2,800人に対して、データ職種は 2025年1月時点で業務委託含め21名 10 © 2025 Leverages Co., Ltd.
  9. 12 © 2025 Leverages Co., Ltd. • ELT:Fivetran • DWH:BigQuery

    • Transform:Dataform • BI:Tableau, Looker Studio • Metadata:Dataplex • Quality Check:Dataplex • Reverse ETL:trocco • Orchestration:Airflow データ活用基盤 - 全体概要アーキテクチャ
  10. 13 © 2025 Leverages Co., Ltd. データ活用基盤 - 個別アーキテクチャ •

    全社で40近くのサービスを展開していることもあり ブランド単位でまとめつつデータ活用基盤を分割 • データ活用基盤の数は10ほど • BigQueryを中心としつつ、事業売上や関係者数、 実装時期によって少しずつアーキテクチャが異なる • 異なるビジネスモデルや売上規模でも 設計が変わらないよう共通利用できる技術を選定
  11. 15 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ • DWHの発展史

    • 蓄積されたつらみ • 最初に確定させたこと • 全体共通方針の策定 • 具体的なアーキテクチャ • やってみて実際どうだったか? 15 © 2025 Leverages Co., Ltd.
  12. 17 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 •

    もともとはSFAのデータのみを使用してDWH〜DM〜BIまで繋いでいた SFA データソース データレイク データウェアハウス データマート ビジュアライズ
  13. 18 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 •

    データ活用が進むにつれ、データソースが増えていった • ひとまずDWHに繋ぐという実装が進んで行った • データ活用を浸透させ、事業貢献するために、テーブルがもりもり増えて(増やして)いった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 広告データ アクセスロ グ
  14. 19 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 •

    社内のデータ活用が拡大していくなかで、DWHやDMがどんどん作られていった • 早く実装して早く事業貢献するために、各人の裁量に任せて実装が進んで行った • テーブル間の依存関係が複雑化し、テーブル重複などが度々発生するようになった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 広告データ 登録 システム アクセスロ グ
  15. 20 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 •

    Dataformのリネージ機能を使っても巨大すぎて全体像の表示で落ちるようになった • テーブル数が多すぎて認知負荷の限界を超えた • システムリプレイス時の影響調査が大変すぎた SFA データソース データレイク データウェアハウス データマート ビジュアライズ 旧登録 システム 広告データ 新登録 システム アクセスロ グ
  16. 21 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 •

    このままだとDWHが事業成長の足枷になることは明らかだった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 旧登録 システム 広告データ 新登録 システム アクセスロ グ
  17. 22 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 蓄積されたつらみ •

    DWHのつらみ ◦ 当初の設計思想を超えてデータ基盤が肥大化した結果、チームメンバーの認知の限界を超えた ◦ SFAのみを使用する想定が、10以上のデータソースを接続することになった ◦ 明確な実装方針やルールがないまま、データ活用を浸透させるためにスピード重視で実装していった ◦ 結果として似たようなテーブルが乱立し、Dataform管理のテーブルが400を超えた ◦ テーブルも多く依存関係が複雑すぎるため、Dataformのテーブルリネージで全体像を描画できなかった ◦ ドキュメントも不十分で、データ定義の意図や背景が読み取れなかった ◦ データの除外タイミングが統一されておらず、似て非なるテーブルが大量にあった • ビジュアライズ層のつらみ ◦ 実装の明文化されたルールがなかったため、ダッシュボードごとに実装が異なっていた ▪ BigQueryで計算させてから送る vs BIツールでデータ結合やデータ型変換を行う ▪ DWHでリネームする vs BIツールでリネームする ◦ 機能制限もなかったため、一定以上のスキルがないと保守運用できないダッシュボードが大量にあった ◦ ダッシュボード改修の際、BIツールだけで完結するのかテーブル改修が必要か毎回調査が必要だった
  18. 24 © 2025 Leverages Co., Ltd. テーブル結合 データの型変換 フラグ付与 複雑なデータ指標定義

    ビジュアライズ 割合の計算 カラムのリネーム • 技術要素の確定 ◦ 変えることも考えたが、リアーキテクチャとは別軸で考えることにし、既存を踏襲 ▪ DWH:BigQuery ▪ Transform:Dataform ▪ BIツール:Tableau Cloud • DWHとBIの責務を分離 ◦ BIツールでは何を行うか?何を行わないか?をディスカッションして決定 ◦ BIツールの入れ替えを容易にするため、できるだけBIツール側の責務を減らす方向でルールを決定 ▪ Github管理を推進するため、Tableauの計算フィールドを極力減らしたい ▪ BIツールに送るデータ量を削減し、画面描画の速くする ◦ あくまでも配信用ダッシュボードのルールとして策定し、探索用には幅広く使える形にする データモデリングのリアーキテクチャ - 最初に確定させたこと BIツールで行うこと BIツールで行わないこと
  19. 26 © 2025 Leverages Co., Ltd. • ワイドテーブルにする! • ビジネスモデルに依存した設計は回避する!

    • BIツールでしかできないことにBIツールは集中する! • 利用人数やデータ量が10倍になっても耐えられる形にする! データモデリングのリアーキテクチャ - 全体共通方針の策定
  20. 27 © 2025 Leverages Co., Ltd. • ワイドテーブルにする! ◦ 新規事業も多く事業成長も速いため、

    ディメンション・ファクトの切り分け難易度が高い ◦ 少人数で保守運用していくため、認知負荷の低い設計が必要 ◦ データ利用時の誤ったキー結合を防ぎ、誤ったデータ抽出を事前に防ぐ ◦ データ利用者にテーブル結合の手間を取らせない、問い合わせの工数を削減させる ▪ テーブル名やカラム名の命名は徹底的にこだわり、誰でも理解できる名前にする • ビジネスモデルに依存した設計は回避する! • BIツールでしかできないことにBIツールは集中する! • 利用人数やデータ量が10倍になっても耐えられる形にする! データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
  21. 28 © 2025 Leverages Co., Ltd. • ワイドテーブルにする! • ビジネスモデルに依存した設計は回避する!

    ◦ 技術要素とアーキテクチャを共通化させて柔軟な人的リソース配置を可能にする ◦ どの事業でデータ活用基盤が必要になっても同じ設計で実装できるようにする ◦ 事業ごとの属人化を可能な限り排除する • BIツールでしかできないことにBIツールは集中する! • 利用人数やデータ量が10倍になっても耐えられる形にする! データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
  22. 29 © 2025 Leverages Co., Ltd. • ワイドテーブルにする! • ビジネスモデルに依存した設計は回避する!

    • BIツールでしかできないことにBIツールは集中する! ◦ 保守運用をしやすくする ◦ BigQueryの計算リソースを最大限利用する ◦ BIツールの入れ替えを見越してBIツールの責務を薄くする ◦ ダッシュボード実装方法を統一して、ダッシュボードの品質を保つ • 利用人数やデータ量が10倍になっても耐えられる形にする! データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
  23. 30 © 2025 Leverages Co., Ltd. • ワイドテーブルにする! • ビジネスモデルに依存した設計は回避する!

    • BIツールでしかできないことにBIツールは集中する! • 利用人数やデータ量が10倍になっても耐えられる形にする! ◦ 人数とデータ量が3年で2倍にスケールする環境に合わせる ◦ データ職種の採用難易度が高いため、少人数で回せる設計にする データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
  24. 32 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 具体的なアーキテクチャ •

    ビジュアライズ層含めて4層から8層に分解 • 各層の役割、責任範囲、対応しないこと、してはいけないこと、保守運用担当を明文化 • データセットの命名規則を整理して決定 ◦ 『データマネジメントが30分でわかる本』を参考に決定 • テーブルリネージをシンプルにするため、手前の層のテーブルしか使用しないルールを策定
  25. 33 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データレイク層 •

    目的 ◦ データソースから無加工でBigQueryへ連携する • やること ◦ FivetranやCloudComposerを利用してローデータを取得しBigQueryを更新する • やらないこと ◦ データに対して何らかの加工を行うこと
  26. 34 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - ステージング層 •

    目的 ◦ ローデータを利用しやすい形へ最低限の加工を行う • やること ◦ 不要なカラムの削除、データ型変換、物理削除されたレコードの除外 • やらないこと ◦ テーブルの結合
  27. 35 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データレイクと層ステージング層の関係 •

    Fivetranが付与するメタデータの削除、Timestamp型からDatetime型への変更を行う • 参照データセットを変えずにデータソースの更新方法を変えるため、Viewテーブルを採用
  28. 36 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - シングルシステムデータウェアハウス層 •

    目的 ◦ テーブル同士を結合し、データ活用の最大公約数となるテーブルを作成する • やること ◦ 同一システム内でのテーブル結合、ビジネスロジックの挿入、カラム名の統一(~~日 → xx_date など) ◦ ワイドテーブルで実装 • やらないこと ◦ 他システムデータのテーブル結合を行うこと
  29. 37 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データウェアハウス層 •

    目的 ◦ 複数システム間のデータを多様な用途に耐えられる形にする • やること ◦ 複数システム間のテーブル結合、ビジネスロジックの挿入 ◦ ワイドテーブルで実装 • やらないこと ◦ 単一システムデータ内のテーブル結合を行うこと
  30. 38 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データマート層 •

    目的 ◦ 特定の目的に合わせたデータのみを保持する • やること ◦ 特定のKPIや施策に必要なデータに絞り込む ◦ 事業で使用する用語を正確に表現するため、カラム名を日本語へ変更 • やらないこと ◦ 複数の目的に合致したテーブルを作成する
  31. 39 © 2025 Leverages Co., Ltd. • 目的 ◦ 指標定義を履歴管理しGithubで管理する

    ◦ 集計処理を共通化させ、データ定義を縦持ちで1箇所に集約する • やること ◦ 指標定義をSQLで表現し、Github管理する • やらないこと ◦ データマートもしくはBIツールでKPIの管理を行うこと 具体的なアーキテクチャ - セマンティックレイヤー
  32. 40 © 2025 Leverages Co., Ltd. • 目的 ◦ BIツールへ転送するためのデータを抽出する

    • やること ◦ BIツールで必要なデータに絞り込みを行う • やらないこと ◦ セマンティックレイヤー以外のデータを接続すること 具体的なアーキテクチャ - セマンティックレイヤーtoBI
  33. 41 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - セマンティックレイヤーを2層にした理由 •

    データ定義処理の共通化を目的として、セマンティックレイヤーを2層に分割 ◦ ファクトは同じでディメンションだけ違う場合、似たような計算処理がダッシュボード毎に発生する • 1層目で全ディメンションに対してファクトを集計、縦持ちで持たせることにした • 2層目はダッシュボードに必要なデータだけをselectし、送り込むデータ量を最小限にする • 全ディメンションの組み合わせが数億あったが、ファクト集計処理が5分以内に完了したので採用
  34. 42 © 2025 Leverages Co., Ltd. • 目的 ◦ 関係者全員が同じ指標を見て意思決定を行う

    • やること ◦ 意思決定に必要なデータの可視化を行う • やらないこと ◦ セマンティックレイヤー以外からデータを繋ぐこと ◦ BIツール側で複雑な計算を行うこと 具体的なアーキテクチャ - ビジュアライズ層
  35. 44 © 2025 Leverages Co., Ltd. リアーキテクチャの効果 • 事業のスケールに耐えられる自信がついた •

    データ定義の問い合わせ数が減った • ワイドテーブルを採用したため、テーブル数が減った ◦ データマートで言うと、40から10に減った ◦ (カラムはすっごく増えた) • 責務の分割をきっちり行ったため、新規開発も既存の改修も工数が激減した ◦ 影響範囲の調査が容易 ◦ 設計時の考慮事項が少ない ◦ システムリプレイス時の影響範囲が狭い • 設計に関する全てをドキュメントに起こし、必要な議論を行ったため、関係者の認識が揃った • DWH→データマート→DWH、といった負債依存関係がなくなった
  36. 46 © 2025 Leverages Co., Ltd. 今後の展望 • 他事業部への展開 ◦

    2025年1月時点では、リアーキテクチャの適用は1事業しか完了してません ◦ 少なくとも残り10事業への展開が必要 • データウェアハウスやデータマートの現場浸透 ◦ レバレジーズは現場でSQLを書ける人材が数百人おり、 データレイクのデータを結合してデータ活用しているケースが非常に多い ◦ データ組織とデータ利用者の責務を分割するため、 データ利用はデータウェアハウス以降に限定したい • BIツールの再検討 ◦ BIツールの責務を少なくした結果、レバレジーズに必要な機能しか残らない ◦ 全社的に最適なツールを検討する • データ品質チェックエラーから対応までのフロー構築 ◦ システムエラーにならない不具合も事前に検知して対応する
  37. 48 © 2025 Leverages Co., Ltd. We Are Hiring! •

    まずはカジュアル面談からどうぞ! • 3年で2倍にスケールする環境で、データを使った変革を起こしましょう! • 募集職種 ◦ データサイエンティスト ◦ データアナリスト ◦ データアーキテクト ◦ データエンジニア ◦ 機械学習エンジニア ◦ 機械学習研究員
  38. 49 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ビジネス グロース DX

    営業 企画 SFA 開発 CRM/MA CJM スコア リング CS システム 構築 プロ モーション プロダクト UI/UX SEO プロト タイプ Web 広告 クリエイ ティブ TV CM 電⾞ 広告 仮説 設定 レバレジーズはマーケティングやセールスといった全ての組織がインハウスで機能しており、 データ戦略が事業運営上重要なハブとなる構造になっています。 データ戦略の役割 データ戦略

  39. 50 © 2025 Leverages Co., Ltd. レバレジーズ テックブログ https://tech.leverages.jp/ データ戦略ブログ(週1更新)

    https://analytics.leverages.jp/ 全社の情報発信媒体(melev) https://melev.leverages.jp/ 情報発信しています!