はじめに
レバレジーズでデータエンジニアやってます、ゲンシュンと申します〜。
データエンジニアリングチームとデータアーキテクトチーム合同で「アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド」の勉強会とワークショップを開催しました。
ディメンショナルモデリングって現代のDWH開発において必須の概念だと思いますが、レバレジーズではワイドテーブル構成を採用していたため実践する機会がありませんでした。せっかく良い書籍が出たので、事業がたくさんあるレバレジーズのデータ分析基盤なら各事業を実装や課題感を踏まえた議論が出来てより理解が深まりやすいんじゃないか？と思い、みんなに声を掛けて開催するに至りました。
ちなみに現在の構成の背景などは過去のこちらの記事で紹介されているので、良かったら読んでみてください。
今回は勉強会開催にあたり意識したこと、得られた学び、最後にどんなワークショップをやったのか？を紹介します。
勉強会の進め方
参加者はデータエンジニアとデータアーキテクト、合わせて8名程です。
毎週1枠60分、前半30分は各自で読み、後半30分でお互いの学びや疑問点、感想を喋り合うという緩めの形式でやりました。自分がモデレーターしながら話を振りつつ、自由に議論してもらう感じですね〜。担当している事業や経験年数もバラバラなので、それぞれの視点から意見が出て面白かったです。
勉強会のスタイルは様々ですが、ディメンショナルモデリングを知っている人が少ないことを踏まえ「参加者が事前準備をせず継続して最後まで参加出来ること」「各メンバーがたくさん発話出来る場を作ること」の2点を意識して、上記のような形式にしてみました。
（ちなみにレバレジーズでは、毎月1人あたり1万円まで書籍購入支援される制度があるのでこの手の勉強会が盛んなんですよ！非常にありがたい〜〜）
勉強会の学び
たくさんの学びがあったのですが、参加者の感想や議論内容を一部抜粋します。
- イベントマトリクスを作るという過程を通して、業務を全部可視化するのが大事なんじゃないか？
- BIツールでどう見たいか？から考えるのは逆で、本来はビジネスプロセスから考えて、何をみたいんだっけ？を明らかにする、という順序が大事なのは納得感ありました
- スタースキーマは、イベントや属性がテーブル単位でまとまっているので、オンボーディング時の業務フローの理解に使えそう
- ミニディメンションについてカーディナリティの高低で判断するというのはわかるが、都度判断が人に寄りそう。BigQueryだとストレージコスト安いし最初から縦持ちテーブルで良いのでは？
- HV(履歴データ)があればCV(最新データ)出せるのでHVを基本的に持たせましょうは正しそうだが、使われないことによる運用コストを考えると悩ましい。BigQueryに閉じていればストレージコスト的には高くないが、外部連携を考えるとデータ量多すぎてコスト肥大化が懸念
- タイムゾーンは今は日本時間固定になっているけど、海外系事業が増えていくと「N営業日以内X率」という指標がタイムゾーンに寄るので、標準時間ディメンションとかが必要になるのかな？
- 現在は各事業部ごとに営業日カレンダーを現場で管理しているが、ある事業部Aの営業日カレンダーを事業部BがSQLで参照しているのを見たことがある。。データマネジメント的には中央集権にした方がいいが、データ戦略室が各事業の営業日を管理するのってなんか変じゃね？会社で一元管理されて欲しいが、その責務を自分達が持つのは辛いよ
ワークショップの進め方
書籍を一通り読み終え、この書籍が言いたいことは何となーくわかったけど具体的にどう実装していくのか？のイメージが見えづらいという声が多かったので、複数の事業の実際のデータを使ってワークショップもやってみました！
経験年数や担当事業などを踏まえデータエンジニアとデータアーキテクト混合でチームを作り「ある事業のデータ分析基盤の最終生成物であるdatamartのテーブルAを、既存の実装フル無視して、dimensionテーブルとfactテーブルから作るようにしよう」というお題をやってもらいました。お題は以下の段取りで、3~4回に渡り開催しました。
- この事業についてのイベントマトリックスを自分たちが知っている範囲で書く
- BigQueryにある実際のデータやテーブル定義書を見ながら、アジャイルデータプロファイリングをしてみる
- モデリングをし、dimensionテーブルとfactテーブルをDataformで作る
- 最終的にテーブルjoinして、最終生成物であるdatamartのテーブルを作る
お題を用意した自分もそうですが、事業や業務フローの解像度が低いメンバーが業務理解とシステム仕様のキャッチアップで時間を潰す可能性があります。dimensionとfactの切り分けやテーブル設計に集中させたかったので何点か工夫しました。
まずシステム都合で複雑な前処理が必要なものについては、前処理済みの簡易版なものをデータソースとして用意しました。要件については、datamartのカラム数が非常に多いため年度・場所・経路などの単位でGROUP BYして◯◯数を出すだけのシンプルなものにしました。
またテーブル定義書（レバレジーズではスプレッドシートを使っています）を見るのが辛かったので、自分が大好きなdbtを使ってdbt docsをGAEにホスティングし、細かいデータの使用やリレーションなどワークショップに必要な情報を全て参照できるようにしてみました。
ワークショップの学び
今までは「欲しいテーブルをどうやったら作れる？」という思考だったが、分析の属性ってなんだっけ？計測したいファクトってなんだっけ？を明らかにする過程でビジネスプロセスの解像度を上げることが大事じゃん！という気付きの声が多かったです。
また今回は、システム側のテーブル設計が分析基盤にとって扱いづらくなってしまう程よいものを用意してみました。実際はこんなテーブル設計ではないですがこの記事の説明を楽するため、ものすごく簡略化して以下紹介します。以下4つのテーブルがあります。
- 求職者の流入履歴テーブル
- 求職者の面談履歴テーブル
- 求職者マスターテーブル
- 学校マスターテーブル
これらを用いてディメンションテーブルはdim求職者とdim学校、ファクトテーブルはfact流入とfact面談が作れそう。ファクトに対して、求職者IDで求職者属性を、学校IDで学校属性の切り口で分析できそうですよね。ただ困ったことに「求職者マスターが学校IDを持たない」「面談履歴が学校IDを持たない」という制約がありました。これだと流入ファクトに関しては困らないかもですが、面談ファクトに関しては学校属性切り口で分析出来ないです。
求職者と学校の関係情報は「求職者の流入履歴テーブル」から得られないのでこの情報をどのようにもたせるか？がちょっとした議論ポイントになります。雑ですが、以下３種類ぐらいあるのかなーと思います。
- dim_求職者に学校IDのFKを追加する
- fact_面談に学校IDのFKを追加する
- 求職者と学校のBridge Tableを作る
上記は履歴を考慮していないやり方ですが、履歴をもたせるとSCD Type2でどこまで作るかも議論ポイントになりますね！実際の業務では、事業的な重要度、分析頻度、データの変更頻度など様々な材料と合わせて判断することにはなりますが、ワークショップという前提であれば皆さんならどう実装しますか？
実際に手を動かしたほうが理解が深まったので、ワークショップやっててよかったです！
We are hiring!
50以上のサービスを持つレバレジーズで、大量データを扱ったデータエンジニアリングに興味がある方はぜひご応募ください！
コメント