見出し画像

分析基盤の変遷 - 横断系データ組織での改良と事業部への分散化 -

こんにちは。マネーフォワード 分析推進部の yuu_kimy です。

今年の4月から部となり、気持ち新たに日々データ活用に奮闘していますが、この機会に、分析推進室の時代から今に至るまでの分析基盤がどう変遷してきたかを整理してみたいと思います。

以下、忙しい方向けの3行まとめです。

3行まとめ

  • 分析推進室の時代には、AirflowにてDWH/Martを運用してきたが、現在ではAirflow & dbtの両方を利用している

  • 2022年から、事業部サイドでの分析基盤の整備をスタートさせ、現在では、複数の事業部でDataformを活用して、データの基盤整備を行っている。

  • 様々なデータ系ツールを活用し、横断系データ組織としての基盤改良と事業部での分散化に取り組んできたが、より良い分析基盤に向けた動きはまだまだこれから。横断系データ組織としての取組みと事業部での取組みを加速させる2軸で考えていく必要がある。


これまでから現在までの変遷

分析推進室は初代室長がチームを2020年に立ち上げてから、経営層と現場メンバーの利用を想定した分析基盤の整備を行ってきました。*1
その時に構築された基本構成は、今でも踏襲しているのですが、以下のような構成になります。現在でもデータ界隈でよく見かけるELT方式で、データをBQへ一元的に集約させ、KPIモニタリングや分析に必要なテーブル群(DWH/Mart)を更新するアプローチで運用していました。

初期の分析基盤の構成

補足: 分析基盤で重要なパイプラインであるDB→DWH環境(BQ)へのデータ連携については、ここでは割愛させて頂きます。弊社の場合、対象のプロダクト数も多く、DWH環境へ連携するだけでもかなりの労力が必要なため、ELTに関して、データエンジニア(EL担当)とアナリティクスエンジニア(T担当)で役割を分割しています。*2

この分析基盤の構成で定常運用が確立され、必要なデータを定常的に更新し、然るべき社内関係者へデリバリーされていたのですが、年月が過ぎるにつれ、課題も見えてきました。

  • BQ上でDWH/Martを開発するには、Airflowはtoo much感が強過ぎる

    • 様々なことができるのはAirflowのメリットであるが、やりたきことは、Martの更新のみであり、機能過多である。

  • データ系メンバーと言えども、Airflowでの開発に慣れているわけではなく、今後も適切に開発、運用ができるとは限らない。

    • できる限り、SQLのみでMartを実装することができ、それ以外のことを覚えなくて良い状態にしたい。

2022年を境に、アナリティクスエンジニアが徐々にジョインし始め、分析基盤の整備の見直し・改良に着手し始めました。(筆者もこのタイミングでジョインしています。)

その頃には、既にdbtがデータ界隈で盛り上がりを見せており、弊社も、新たなMart開発プロジェクトの立ち上げにより、導入の機運が高まってきました。Airflowとdbtを比較して、どちらを選択するか?という定番の調査から開始するスタイルも考えられましたが、弊社の場合は、そういったことは実施せずに、一気に導入を進めました。理由は以下の通りです。

  • Airflowとdbtは担っている機能が異なっており、また、弊社の場合には、Martの開発・運用のみにフォーカスできるツールを欲しているので、dbt導入は必然である。

  • Airflowによる経営向けのMartの定常運用フローが一定以上確立しており、それをdbtに置き換える方が工数がかかり、新しいMart開発のスピードを損なってしまうため、既存のAirflowには一旦手をつけずに、Airflowとは別にdbtを導入し、新たなMart用のデータパイプラインを構築したほうが現実的である。

そういう背景があり、分析推進部では、2022年以降は、以下のような構成で分析基盤の開発、構成を行っています。

dbt と Airflowによる並行的な構成

ただ、Airflowとdbtは全く別のデータパイプラインとして開発、運用していますが、それだけだと単なる並行運用になってしまうので、dbt導入の際には、以下に留意していました。

  • Airflowが更新しているMartが格納されているデータセットに、dbtで更新するMartを更新・保存しない。

    • テーブルの保存先を独立させることで、dbt / Airflowの更新を同じデータセットに混在させない。

  • Airflowで更新しているMartをdbt側のデータパイプラインからは極力参照しないようにする。

    • 異なるデータパイプライン間のデータの依存関係があると、開発・デバッグがかなりし辛くなるのを回避するため。

dbtを導入したことにより、Mart開発の取り回しが非常に良くなり、Mart開発に集中できるようになったこと、dbtのコミュニティで議論されるナレッジを吸収・活用しやすくなったというMartの開発者体験の向上が実現できたと感じています。

現在は、更にdbtの恩恵を受けるべく、dbt Cloudへの導入を進めております。更に、モダンな分析基盤環境が整備できると期待しており、今から楽しみにしています。

中央組織から事業組織への分散化

分析推進室(当時)の基盤整備の動きとは別に、各事業部におけるデータの分析環境の整備にも課題が見え始めました。
下記の記事で紹介しているように、分析推進部では、メンバーを事業部へ送り出す人材輩出を推進しており、各事業部内でのデータ活用の支援にも取り組んでいます。

ちょうど、2022年後半から人材輩出の施策が始まり、データ系組織のメンバーが事業部内へ入り込み、データの整備開発・活用推進の動きが活発化しました。そうした中で、既存の体制・環境の課題が見え始め、今後の大きなボトルネックを発生させるのでは?と問題意識を持つようになりました。

  • 事業部への人材輩出が実施されることで、事業部におけるデータ活用は一気に加速するが、必要なデータ整備開発を横断系データ組織が行うことは工数的にかなり厳しい。

    • これまでにも、社内におけるデータ活用に関わっていたと言え、事業部の外と中では見える景色も異なり、新たに見えてきたこと(≒ドメイン知識)を横断系データ組織がキャッチアップすることには限界がある。

  • 既存の分析基盤の環境は、横断的なデータ系組織が開発、運用することを想定しており、事業部がそれぞれ必要なMartを保存する場所がなく、自分達が必要とする開発・運用の形態を採用することができない。

そういった背景を踏まえて、事業部が、自分達が独自に取り組みたいことができるような分析基盤の開発環境が必要となりました。その時に導入したのが、Dataform(2022年当時なので、Google Cloudに統合化されたPreview版)でした。

既に分析推進室(当時)で導入しているdbtを事業部にも展開しても良かったのですが、以下のようなことを整理・検討した結果、Dataformを選択することにしました。

  • 事業部でもBQを利用している方は一定存在しており、BQのコンソール画面でのSQLの実装には慣れている。

  • 事業部にアナリティクスエンジニアが在籍しているとは限らず、dbtのようなMartの開発環境に慣れているとは限らない。むしろ慣れているほうが稀である。*3

  • 事業部にはなるべく新しいことを覚える必要がないようにしたい。

    • 個人の環境構築に関する時間は可能な限りゼロにしたい

    • コマンドを実行することなく、画面UIで極力完結することが望ましい。

BQのコンソール画面と大きく変わることなく、SQLで実装することができ、また、コンソール画面からGitHubへコミット・プッシュすることができ、ソースの一元管理ができる環境が揃っている点で、Dataformは必要十分な機能が揃っていました。
もちろん、独自の.sqlxでの実装の仕方、Dataformの使い方は習得いただく必要があるので、それは別途レクチャー等を実施してサポートを行いました。

結果として、事業部側の基盤環境も含めると、現在は以下のような構成になっています。また、赤枠と青枠で各組織の責務を明確に分けています。

横断系組織と事業組織の基盤開発の責務

この構成により、横断系データ組織と事業部の分析基盤を明確に分けることができ、それぞれが取り組みたいことに集中できることを実現できました。また、事業部におけるデータ活用・データ整備開発の取組みは、これから更に拡大することを想定していますが、これにより、事業部ごとの分析基盤の整備をスケールさせることができると思っています。

分散化までは実現できてきたが、今後の道のりは遠い..

2022年以降、横断系データ組織としての基盤改良と事業部での分散化に取り組んできました。一定、分析基盤としての型になってきたと思いつつ、まだまだ取り組むべきことは多々あると感じています。
その時その時で必要な選択をしてきたとは思いつつ、全体として見れば、開発ツールが増えてしまったことは否めず、横断系データ組織(特にアナリティクスエンジニア)は、複数の開発環境へのキャッチアップが必要な状態になってしまったことは事実です。

今後、横断系データ組織としては、過去の負債(特にAirflowで更新しているMart)の更なる解消、汎用性の高いMartのデータモデリング/運用管理に取り組む必要があると考えています。
一方で、事業部が、Mart更新の運用をよりスムーズに行えるように、DataOpsのガイドラインを整備していく必要もあると感じています。

おわりに

最後までお読み頂き、ありがとうございました。

この記事を読んで、少しでもマネーフォワードの分析推進部に興味を持って頂けたら幸いです。また、よろしければ、記事にスキをつけて頂けたら、今後の励みになります。

他にもメンバーの紹介や日々の取組みに関する記事が多数ありますので、ぜひご覧ください。


参考

*1 初期の取組みに関しては、初代室長の以下の記事をご覧ください。

*2 DB→DWH環境(BQ)の連携の課題に対するデータエンジニアリングの取組みは以下をご覧ください。


この記事が気に入ったらサポートをしてみませんか?