はじめに
こんにちは。
レバレジーズデータ戦略室、データアーキテクトグループの鵜飼です。
今回は、データ分析基盤の再整備プロジェクトについてお話できればと思います！
こちらは、以前田代が投稿した記事『データ分析基盤再構築への道！～レバレジーズの挑戦～』に記載されているアーキテクチャを元に、実際にデータ基盤を整備してみた話になりますので、プロジェクトが始まった経緯やアーキテクチャに関しては田代の記事をご覧いただけますと幸いです。
データ分析基盤を綺麗にしたいと考えている方の参考になると嬉しいです！
プロジェクトの概要
本プロジェクトは、すでにBIツールを活用したモニタリング体制が整備されている事業のデータ活用基盤を再構築するというものです。
今回対象となった事業では、内製のSFAツールからBigQueryにデータを連携し、最終的にはTableauを使用して可視化しています。
しかし、全員が共通で見るモニタリングがなく属人化しているため、モニタリングする数値が正確でなかったり、データ活用基盤内のルールが定められておらず、様々な依存関係が起きてしまっている状態でした。
そのため、全員が見るべき指標の定義を統一し、誰もが正確な値を簡単に抽出したりモニタリグできるような環境を構築する必要がありました。
実際に行ったこと
データ分析基盤の層を細分化し、各層の役割を明確化することで、データ活用基盤内での複雑な依存関係を解消したアーキテクチャとなっております。
ここから、各層で実際に何をしていったのかをお話します。
シングルシステムDWH層
この層では、単一システムごとにデータウェアハウスを作成しています。
今回対象となった事業では、事業がスタートしてから成長に合わせて徐々にSFAツール側の機能を増やしていっていたため、データ活用観点での設計はされておらず、各テーブルに複数事業のデータが混在している状態でした。
そのため、シングルシステムDWH層の中でも最大3層に分かれており、各層で下記処理を行いました。
・第1層：マスタの結合、論理削除されたデータの除外、日時関連カラムを適切な型に変換 ・第2層：複数事業のデータが混在しているテーブルから、該当事業やサービスを絞り込む ・第3層：ユーザーが経験するプロセスを辿ることができるワイドテーブルの作成
シングルシステムDWH層は、システムに寄り添った設計方針を採用したため、弊社の開発部とのやり取りを行い、システムのデータの定義を明確にしていくことが作業の中心でした。
中にはシステム側にマスタを持たせず、case文で対応していたカラムもあったので、該当カラムを洗い出して、開発にマスタを作成してもらうような動きも必要でした。
DWH層
この層では、シングルシステムDWH層を結合して、システムを跨いだワイドテーブルを作成しました。
この段階でカラムの数が約3000個になってしまう事件が起き、どこまでの情報をワイドテーブルにもたせるかの議論を繰り返すことになってしまったのですが、最終的には1000個近くのカラムに落ち着いております。
データマート層
特定の目的やKPIに合わせてテーブルを作成する層となります。
従来から利用者が多い層だったのですが、KPIの定義が明示化されていなかったり、データマート層内での結合で新たにデータマートを作成するなど依存関係が複雑化されていたりしたため、整理して新たにデータマートを作成しました。
まず、KPIの定義を明確化し事業として統一するために、事業部の共通のKPIのビジネス定義・データ定義が一覧で見れるKPI定義一覧を作成しました。
事業部の営業やマーケティング担当に依頼して実際に普段使用しているモニタリングを提出してもらい、その中で使用されているKPIを洗い出して定義をまとめ、事業部の方にダブルチェックをしてもらうことで、定義を確定させることができました。
この定義をもとにデータマートの実装を行っていきました。
また、今回新たにデータマートを作成するにあたり、データマートのカラムの物理名を日本語に変更しました。
利用者が最も多い層のため、認知負荷を下げクエリが書きやすくなったのではないかと思うのと、私としても確定したKPIの日本語名に対して対応する英語を検索しなくて良くなったのはとても嬉しかったです(笑)
セマンティックレイヤー
この層は、従来Tableau側で行っていた集計などの計算処理を、Tableauに接続する前に行う層となっております。LookML等のセマンティックデータモデリングを採用せず、Dataformで計算処理を行いました。
従来はTableauの計算フィールドで都度集計を行っていたため、KPI算出のソースコードの管理ができておらず、KPIの定義や値がずれてしまう一因となっていましたが、セマンティックレイヤーを導入したことで、定義が統一でき、また数値がずれたときの要因特定も容易になりました。
セマンティックレイヤーを設計する際に、レコード数が将来的に逼迫してしまうことも考えて横持ちを採用していました。
しかし、Tableauでビジュアライズする際に横持ちだと実現できなかったり実装工数がかかることが多く、途中から縦持ちに変更しました。
セマンティックレイヤー作成を検討されている方には縦持ちでの設計を強くおすすめします、、
Tableau
セマンティックレイヤーで事前に集計を行っているため、Tableau側で行う処理はかなりシンプルになっており、実装はかなり楽になりました。
データマート作成時に作成したKPI定義一覧をダッシュボードに貼っておくことで、利用者がKPIの定義を確認したい際に都度確認できるようになり、データ戦略室に定義の質問が来ることも減りました。
また、今まで一部事業でしか取り入れてなかったTableau更新時間と接続しているテーブルの更新時間をダッシュボード上に表示することで、Tableauでなにか問題が起きたときの特定も行いやすくなりました。
終わりに
本アーキテクチャの導入は全社で初めての取り組みだったためかなり試行錯誤して大変だったのですが、対象だった事業がデータ戦略室に異動する前に営業として所属していた事業だったので、ドメイン知識にかなり助けられたなと思います。
営業時代はまったく気にならなかった細かい言葉の定義なども、今となってはすごく気になって統一するようになってきて、データ戦略室に染まってきたなと感じます(笑)
今後はこの設計思想に基づいてモニタリング体制を拡充していくとともに、現場により使ってもらえるモニタリングにしていくために現場浸透も行っていく予定です。
本記事が、少しでもデータ分析基盤の再整備を検討されている方の参考になれば嬉しいです！
