はじめに
こんにちは！レバレジーズ株式会社 データ戦略室 データアーキテクトグループ リーダー兼データアナリストの田代です。
今回は、2024年4月頃から取り組んでいるデータ分析基盤再構築プロジェクトについて、概要や苦労した点、現時点での知見などを共有したいと思います。 これからデータ分析基盤の再構築を検討している方の参考になれば幸いです！
課題
入社以来、様々な分析業務に携わる中で、大きく二つの課題を感じてきました。
1. 指標の定義が曖昧な分析が行われていること：
データ戦略室では「データ民主化」を推進しており、営業や企画職のメンバーもアドホックにデータ分析をする機会が多くあります。しかし、その際にデータ定義が曖昧になってしまうことが課題であると感じていました。 例えば、同じ指標について分析する際でも、部署や個人によって異なる定義で分析するため、似たような分析結果やアウトプットが複数存在してしまう状況が発生していました。これにより、
無駄な工数の発生: 同じ内容の分析が何度も行われている
意思決定の遅延: 結果が一致しないため判断が遅れる
といった問題が生じていました。
データ戦略室主導の分析では厳密な定義に基づいていますが、現場レベルでの分析の質を担保する仕組みが必要だと感じました。
2. システムリニューアルに伴うデータマートの改修：
既存システムのリニューアルに伴い、テーブル設計が大幅に変更することがありました。データ戦略室がモニタリングや分析に使用しているシステムは10個以上存在します。そのため、各システムがリニューアルするたびに、データマートの大規模な改修が必要となり、正直なところ頭を抱える業務の1つでした。
さらにデータマートの運用に関するルールが曖昧であったため、依存関係が整理されていないデータマートが乱立している状況でした。これにより、想定より影響範囲の特定に工数がかかりました。具体的には、システムのリニューアル時にデータマートへの影響調査と、改修対象のデータマートの数が多くて改修および確認作業に時間がかかる状況でした。 このままでは、データマートの改修負荷が増大し続け、今後の事業成長を支える上で、現行のアーキテクチャが保守運用のボトルネックになると強く感じました。
解決策：多層構造によるデータ分析基盤の再構築
これらの課題を解決するため、データ分析基盤再構築プロジェクトを立ち上げ、PMとしてアーキテクチャ設計に取り組みました。目指したのは、「システム変更の影響を最小限にすること」と「属人化を防ぐこと」です。
以下、新旧アーキテクチャの比較です。
一見複雑に見えるかもしれませんが、3層構造をさらに細分化することで、各層の役割を明確化し、保守性を高めています。
新しいアーキテクチャについてシングルシステムDWH層(single system DWH)以降の各層でどんなことをしているのか説明します。
シングルシステムDWH層(single system DWH)
この層では、他のシステムからの影響を受けないように、各システムごとに完結するデータウェアハウス（DWH）を設けています。各DWHのスキーマにはワイドテーブルを採用しました。
ワイドテーブルを採用した主な理由は以下の2点です。
1点目：データ戦略室の組織体制と会社の特徴に適した設計
レバレジーズのデータ戦略室は事業の大きさと数に対して人数が少ないです。そのため、1人のメンバーが複数事業部を担当することもあります。また、この状況で「属人化を防ぐ=認知負荷を減らす」ためにスタースキーマやスノーフレークスキーマのようなディメンションテーブルとファクトテーブルを分けることをしないワイドテーブルを採用しました。
また、レバレジーズの事業成長のスピードは速く、新規事業が毎年リリースされるようなレバレジーズの環境では、「何がディメンションで、何がファクトなのか」を1つ1つ判断して分けていくよりも、ワイドテーブルに全てを統合し、データを使用する段階で要否判断をする方が、スピード感を持って実装していくことができると判断しました。
2点目：利用者がデータ誤用を防ぐため
レバレジーズの特徴の1つとして、各チームが自分たちでデータを抽出してPDCAを回す文化があります。しかし、分析結果に誤りが生じる主な原因の1つが、「誤ったキーでテーブルを結合している」ことでした。これを解消するため、データウェアハウスおよびデータマートで可能な限り結合処理を行い、利用者がキー結合を行う必要がないワイドテーブルを採用しました。 以前であればデータベースのパフォーマンス上、ワイドテーブルの採用は難しかったかもしれませんが、現在のクラウドDWH（レバレジーズはBigQuery）のパフォーマンスを考えると、多少の冗長化は許容範囲内と判断しました。
DWH層(DWH)
シングルシステムDWH層のテーブルを結合する層です。営業や企画職の方々はDWH層以降を利用するように徹底し、ガバナンスを強化しています。これによって、システム変更時の影響をさらに軽減することを可能にしました。
データマート層(data mart)
一般的なデータマートと同じように、特定用途のためのテーブルになります。従来は乱立していたデータマートでしたが、今回を機に整理し、保守運用コストを削減するように作成しました。現在特定の事業部で導入していますが、40個以上あったデータマートのテーブルが10個程度で少なくなったのはとても保守運用しやすくなったのではと思います。
セマンティックレイヤー(semantic layer)
レバレジーズの環境では、dbtではなくDataform※を採用し、BIツールはTableauを使用しています。そのためセマンティックレイヤーのツールはレバレジーズの環境では利用できない環境にあります。そこで、テーブルとしてセマンティックレイヤーを持たせ、集計軸やKPIの定義を集中管理する層として機能させます。これにより、定義の統一性を確保し、分析の精度を高めます。
また、BIツール側での計算を極力少なくすることにより画面描画にかかる時間を削減し、ダッシュボードを見る人のストレスを軽減するような設計にしています。そして、git管理できないtableauの計算フィールドからKPIの定義を切り出してdataformに寄せることで、KPIの定義をソースコード管理できるようにしました。
※ 2024年10月現在
現時点での成果と課題
特定の事業部で導入していますが、既に効果を実感しています。層ごとに役割を明確にしたことで、データソースの変更に伴う影響範囲の調査と対応にかかる工数が少なくなり、保守運用が格段に楽になりましたし、開発スピードも向上しています。
一方で、ワイドテーブル設計により、1つのテーブルに集約した結果、テーブル作成時にかかるスキャン量が従来の10倍程度に増加しました。数百MBから数GBへの増加はインパクトがありますが、現状の分析フローと乱立していたデータマートを整理することで作成するテーブル数が減ることを考えると将来的にはスキャン量が減少し、コスト削減につながると考えています。
今後の展望
データ戦略室のリソースが限られているからこそ、最小限の運用工数で最大の効果を発揮できるデータ基盤の構築が重要だと考えています。そして今回の再構築は、データ戦略室全体のスキルアップにも繋がる挑戦だと考えています。 再構築できた後はセマンティックレイヤーをツールとして導入することも検討するなど、今後もより堅実で運用しやすいデータ分析基盤を目指し、改善を続けていきます。具体的な実装時の苦労話などは、他のメンバーに任せたいと思います！
