データマートを一から作り直した話

この記事について

この記事「FOLIO Advent Calendar 2020の11日目の記事です
直近1年くらい、FOLIOにてデータ分析基盤の開発・整備に従事してきました。いくつか印象に残っているプロジェクトはあるのですが今回は「データマートのリプレイス」について、実施したことやノウハウなどケーススタディ的にまとめていきたいと思います。

会社のデータ周りの状況についての前提

• 弊社は複数の金融商品を展開している他、マイクロサービスを採用していることもあり、データを収集するにはそれらの複数のエンドポイントからデータをマイグレーションし、当然分析するためにはそれらのDBの構造も理解していなければならない。
• 分析基盤はAWSにより構築されており、主要なパーツでいうとデータウェアハウスはRedshift、BIツールはredashというよくも悪くも枯れたオーソドックスな構成。私の所属するデータチーム以外にも、自分でクエリもかけるいわゆるパワーユーザーもいれば、ダッシュボード見る専門のメンバーもいる。

プロジェクト開始時の現状分析

私が入社するよりも以前にデータマートは前任者により作成されていたものの、人の入れ替わりに伴う知見のロスト、追加リリースされるプロダクトや本番DBの開発スピードにデータマートの改修が追いつかない、データ抽出・分析の結果が人によりブレるなどの問題が起こっていた(よくある話ですね…)ことや、また今年の7月にロボアド基盤の刷新も予定しており(参考: @matsu_chara さんの発表資料)、どちらにしてもその対応で多くのデータマートは改修を余儀なくされることも後押しとなり、今あるデータマートをリプレイスし、運用負荷が低くエンドユーザーにとってもフレンドリーなデータマートを一から作り直すことにしました。
その他、プロジェクト開始時に認識していた課題、目指すべき姿としては下記のようなものを想定しています。

As is

• データマートは存在したものの、分析担当者の作業テーブルとしての色が強かった
• アプリケーション側のDBのENUMのkey-valueを把握していなければ使えない。メタデータの管理は古くなってしまっており更新頻度はばらばらで、結局アプリケーション側のコードやドキュメントを参照してしまっている
• トランザクション系のテーブルしかなく、集計値のKPI(例えば、商品ごとの日次の預かり資産残高)などはそこからredashのクエリ上で集計された値がダッシュボードに使われていた
• 各種KPIの計算ロジックがredashのクエリに散在してしまっており、集計ロジックなどが各担当者ごとに属人化してしまっており、またアドホックなデータ抽出・分析依頼にも時間がかかってしまっていた

To be

• 主要なKPIについては適切なテーブルを参照すれば各ダッシュボードに載せるKPIはSELECT文一発で算出できる
• メタデータ管理も適切な頻度で行えている。

ただし、あくまでも「データマートのリプレイス」は「分析基盤の信頼性を向上させるための一手段」に過ぎません。今回は記載しませんが、分析基盤自体の信頼性を向上させるための取り組み(e.g. 各種バッチのエラーを減らしたり、データの鮮度を上げる、など)も並行して行いました。

実際にやったこと

前段が長くなってしまいましたが、ここからやったことはひたすら地味です。

基本的には、redashの各ダッシュボードに表示されているクエリをひとつずつ探し(FOLIOはエンジニアが多いこともあり、各プロダクト・KPIについて何かしらたたき台として使えるような、有識者が書いたクエリは「探せばある」状態でした)、各所で表示されている結果にブレがあれば有識者(多くの場合証券基盤エンジニア)にヒアリングし理由を特定し、正しい形で集計し実装、必要に応じて得られた知見をドキュメントに残していく、という非常に泥臭い作業の繰り返しです。

また、データマートをつくるにあたっては下記のような点を意識し設計・実装しました。

1. ある特定のKPI(日次の新規口座開設者数、預かり資産の変動)ごとに、できるだけスコープの狭い(=用途がひと目で理解、あるいは推測できる)ようなデータ形式であること
2. (上記とも重複しますが)ENUM値は、元のDBにはコード値で入っていたとしても、そのENUMのkey-valueの中身について知見がなくても集計できるような(e.g. 元のデータには、 product_id = 4 と格納されていた場合でも、データマートでは product_name = '<※実際の商品名>' )解釈しやすい形式に直して格納する
3. ドメイン知識が必要な集計部分にはドキュメントへのリンクをコメントに残したり、データマートを作る際のキメの部分はコメントに残すことを意識する
4. 作成するテーブルのクエリはかならずコメントつきDDLとConfluence上のドキュメントで管理する(クエリ追加のMR時に更新済みのドキュメントのリンクを貼るのを必須化しています)

実際のドキュメントの例としては、DDLの情報を記載するのは当然として、エンドユーザー向けに
簡単なユースケースや落とし穴も記載した「ざっくり仕様まとめ」も追加しています。
(下記。内容についてはマスク済み)

テーブルごとに作成している仕様まとめ※内容についてはマスク済み

また、それと並行して、redashのAPIを叩いて、旧データマートが使われているクエリを検索して新データマートに置き換えていく作業も実施しました。

結果とその振り返り

上記のような作業を経て約30個のテーブルをデータマートとして作成・提供し、以前のデータマートの更新も停止することができました。これにより、実際に自分でも分析作業がしやすくなったのはもちろん、実際に同僚(SQLがかけるビジネスサイド)からも「分析のハードルが下がりそう」とのFBを受けました。

また、redash上に存在するクエリについても、主要なダッシュボードにあるクエリについては大半をサブクエリなどを使わない、シンプルなクエリだけで記述できるようになりました。ドメイン知識が必要な集計部分については先述の通りデータマートに知見を集約するようにしているので、将来的にチームメンバーが増えたときにも知見の移転をスムーズに行える状態にできたと思います。

その他にも、データマートの開発を効率化するために、分析基盤のSTG環境を用意しCIでSQLの自動テストを行う、redash alertを用いた分析基盤上のデータ連携が上手く行っているかの監視するなどして、データマートのみにとどまらずデータ分析基盤の信頼性を高めるための取り組みも並行して行いました。

ただし、今あるもので完璧とは思っていないので、こういった工夫も含めて、日々組織の中にデータ活用が浸透するようにできることをやっていきたいと思います。