SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

スマキャンが新データ分析基盤のBIツールにLookerを選んだ理由

こんにちは!スマートキャンプエンジニアの井上(エース)です!

皆さんは自社プロダクトに対してどのようにデータ分析をされていますか?

データ分析基盤は構築されているものの、少なからず課題を抱えている企業も多いかと思います。

今回は弊社のBOXIL SaaS新しいデータ分析基盤を導入することになったので、その背景や導入にあたって課題だったこと、その対策などを書いていこうと思います。同じようにデータ分析基盤を導入しようとしている方の参考になれば幸いです。

元の基盤の課題

まずもともとのBOXIL SaaSのデータ分析基盤を見てみます。

かなり簡素化して書いていますが、大まかにはこのとおりです。注目して欲しいのは下記のような点です。

  • 定期処理サーバーであるdigdagによってDBのレプリカからBigQueryにデータが流れている
  • ログ集約サーバーからBigQueryにデータが流れている
  • それをRedashで分析している

そして今回問題にしているのは右下のRedash部分です。この部分をリプレイスしたというのが今回の記事の要旨となります。

さて、概略を書いたところで、実際の運用に落としてみたときの問題点を整理していきます。

クエリの乱立とデータ定義のバラつき

Redashをヘビーに使われている方々は共感していただけるかと思いますが、社内でRedashユーザーが増えてくると、各々が見たいデータを見たいように見るためにクエリやダッシュボードが乱立することになります。弊社についても、営業職のメンバーもクエリを叩いてデータを出したりするので(これは良いカルチャーなのですが)、多くのユーザーによって非常に多くのクエリが生み出されていました。

加えて弊社BOXIL SaaSのデータ構造は複雑で、後述するようにデータを使いやすいように加工などもしていませんでした。そのため集計ミスや条件漏れによって誤ったデータが使われたり、各事業部ごとにデータの定義がバラバラだったりして、それぞれのデータがどれくらい正しいのかの判断がしづらい状況にありました。

Redashのページネーション。合計でだいたい1000件くらいクエリがある計算。

クエリ作成依頼についてのエンジニアの対応コストが高い

RedashはSQLベースで、データ抽出にも一定のスキルが必要なこともあり、各事業部から「こういうデータが見たい」と開発へ依頼が投げられることがよくありました。

しかし前述するようにデータが使いやすい状況になかったこともあって、毎回複雑なクエリを書く必要があり、エンジニアの作業コストがかかっていました。

データ分析ツールの統一

GA, Redash, DataStudioなど、弊社では多くのデータ分析ツールが使われています。それぞれの部署で異なるデータ分析ツールが使われることによって数値のズレやツール活用の属人化が進む恐れがありました。

パフォーマンス

DBから流れてきたデータは、個人情報などのマスキングはしているものの、冗長化のためのテーブルジョインなどパフォーマンス向上のためのデータ加工はしておらず、ほとんどが未加工のデータとなっていました。つまりRedashからデータを閲覧するときには毎回JOINコストなどが発生することになります。

新しいデータ分析(BI)ツールに求められたもの

上記の課題をまとめた結果、新しいデータ分析(BI)ツールに求められるのは下記のような点となりました。

  • ユーザーがデータを正しく分析できる
    • 集計ミスや条件漏れが起こらない
    • 事業部ごとにデータの定義のバラつきが起きない
  • クエリの依頼によるエンジニアの作業コストを減らせる
    • できるだけ各ユーザーに集計をしてもらう

Lookerの選定理由

さて、このような条件でスマートキャンプがLookerを選定した理由を挙げていきます。

LookMLによる統一的な管理

LookerはLookMLという独自の書き方でDB内のデータを定義します。公式サイトから例を拝借します。

##########################################################
# FILE: orders.view.lkml                                 #
# Define the dimensions and measures for the ORDERS view #
##########################################################
view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
  dimension: customer_id {      # field: orders.customer_id
    sql: ${TABLE}.customer_id ;;
  }
  dimension: amount {           # field: orders.amount
    type: number
    value_format: "0.00"
    sql: ${TABLE}.amount ;;
  }
  dimension_group: created {                # generates fields:
    type: time                              # orders.created_time, orders.created_date
    timeframes: [time, date, week, month]   # orders.created_week, orders.created_month
    sql: ${TABLE}.created_at ;;
  }
  measure: count {             # field: orders.count
    type: count                # creates a sql COUNT(*)
    drill_fields: [drill_set*] # list of fields to show when someone clicks 'ORDERS Count'
  }
  measure: total_amount {
    type: sum
    sql: ${amount} ;;
  }
  set: drill_set {
    fields: [id, created_time, customers.name, amount]
  }
}

SQLに慣れ親しんだエンジニアからすると「なにこれぇ?」となると思うのですが、実際に触ってみるとそこまで難しいものではありません。むしろSQLを知っていればすぐに理解できるかと思いますし、今まで苦労して毎回書いていたGROUP BY句が不要になり感動するかと思います。

LookerではこのLookMLによって統一的にデータ定義を管理します。ユーザーはこのLookMLに書かれた定義に従ってデータを抽出します。例えば上記の例で言うと、total_amountというmeasureを指定するとSQLをユーザーが定義することなくamountの合計が出ます。

これの何が良いかと言うと、SQLを書くのはユーザーではなくLookMLを管理するエンジニアだということです。RedashではSQLを各々が書くことによって圧倒的にデータ出しに自由度がありましたが、その反面データ定義が各々のSQLに依存することになっていました。その点Lookerではユーザーは出したいデータ項目をポチポチして組み合わせるだけで、SQLを意識することなく出したい表を作ることができます。SQLを触らないので、SQLの誤りによる集計ミスや条件漏れが発生することもありません。これによって、ユーザーのデータ定義は統一的に管理しつつ、エンジニアの対応コストを減らすことができます。

LookerのExploreイメージ 公式から拝借。

ドキュメントの充実度

そしてこのLookMLの学習を補助するものとして公式のリファレンスがあるのですが、これがかなり充実しています。プロジェクトの概念から派生テーブルまで、丁寧に説明してくれています。エンジニアとしてはこの手のリファレンスが充実しているのは開発する際に助かります。ただ日本語で利用できるリファレンスが限られているのが玉にキズです。

プルリクベースでの開発

LookerはデフォルトでGitによるバージョン管理が利用できます。つまり上記のようなLookMLをGitで管理ができるということです。これによって不毛な先祖返りなどがなくなり、安全に開発できます。LookMLを管理するのは主にエンジニアなので、Gitとの相性も良いです。

個人的に良かった点として、Lookerではまず自分のブランチ上で一通りの要素が壊れてないかどうかチェックしてからプッシュできるということが挙げられます。例えばデータ定義を変更したことによってダッシュボードが壊れてないかどうかをチェックできます。既存のものを編集するのは誰だって怖いですからね。こういうのはありがたいです。

実際のアーキテクチャの紹介

さて、新しいデータ分析基盤を紹介します。といっても、変更点は右下だけなので、そのあたりに注目してもらえればと思います。

  1. まずデータレイクとなるBigQueryからELTツールであるdbtがデータを抽出します。
  2. dbtは内部でデータのジョインやデータをまとめたりしてデータ分析しやすいように加工します。
  3. 加工したあと再びBigQueryにそのデータを流します。
  4. Lookerはその加工したデータをクエリ実行時に抽出します。

主なプロセスは上記のとおりです。

dbtというツールが新しく出てきましたね。これはELTツールの一種で、主にデータ加工を担当します。SQLでテストを書くことができたりマクロを組むことができたり色々と便利なツールです。ここではあまり紹介しませんが、いつか機会があれば中で具体的に何をやっているのか紹介したいです。dbtについて詳しくはこちら。

こちらの新基盤の作成にあたって必要だったのはdbtとLookerの開発でした。開発者はほとんど私一人だけという感じでしたが、先輩エンジニアの瀧川さんの補助もあり、およそ二ヶ月ほどで実装は完成しました。

特筆したいのは、私自身はLookerを一度も触っていなかったことです。SQLの経験はあるものの、BIツールを触ることすら初めての私が二ヶ月でこの基盤を作れたのはLookMLの分かりやすさやドキュメント性に助けられたことが大きいかと思います。

変なところがあればすぐに教えてくれる。

導入にあたって課題だったこと

データ定義のバラつきへの対処

LookMLによってデータ定義が一元管理できるというのがLookerのいいところです。

しかしLooker導入にあたってはそれが問題となることがありました。

それぞれのデータの定義について調査していくと、こっちの部署ではカウントするのにこっちの部署ではカウントしないというような定義のブレが見られたことです。これはもともとRedash上で各々の部署がデータ定義をしていたのが原因としてあります。

例えばBOXIL SaaSでは資料請求をしたユーザーの流入を分析して見ており、オーガニックや広告、メルマガなどの流入源の切り分けが存在します。しかしながら、特にオーガニックの定義については各部署間で違ったデータ定義をしていて、数の相違が生じていました。

しかしLookerに移行するうえでは、データ定義はできるだけ統一したいというのがエンジニア側の意見です。ただ一方的にデータ定義をしてしまうと事業のデータ分析に混乱をきたすことになるので、最適な落とし所を見極める必要がありました。

その対応として私が実行した手順が下記です。

  1. 既存の各部署のオーガニックリードの分析に使っているSQLを洗い出す
  2. その違いをドキュメントにまとめる
  3. 上記ドキュメントで各部署の責任者に現状把握をしてもらう
  4. Lookerでどうデータ定義するかについて各部署の責任者と合意を得る

特に気を使ったのが4でした。異なるデータ定義をしている以上、それには理由があるはずです。そこをヒアリングしてしっかりデータ定義に落としていきました。

クエリに直接手入れしてメンテしているパターンへの対処

スマートキャンプ社内のRedash上には特別多くの人から使われているクエリがありました。それはリードの流入元の切り分けから課金リードの絞りこみまで一元的に行っているいわば神のようなクエリでした。

この神クエリ、実は月一回程度更新が入りまして、例えばリードの流入源として新しい切り分けが追加されたときなどは、ビジネスサイドの人が直接CASE文をいじって更新をするということをしていました。

これが定期的に人の手によって手入れされているという辛さ。

さて、これをLookerに移行するとなると問題があります。それは、そのままの運用をするとビジネスサイドのユーザーがLookMLを触る必要があるということです。

エンジニアではない方にLookMLを管理してもらうのは、定義の信頼性担保などの観点で懸念があるので、私達が考えたのはスプレッドシートで管理してもらうというやり方でした。

BigQueryにはGoogle Spread Sheetを直接、表として読み込むという機能があります。それを使って、BQ上に保存されたテーブルをLookerで読み込むという方法を取りました。

スプシにCASE文の内容を移植して、ビジネスサイドの人も簡単に編集ができるようになりました。

utm_sourceなどのパラメータに流入源を判断するvalueが入っているような感じです。

Lookerの社内での活用事例

早速社内でもLookerは活用され始めています。例えば毎週のBOXIL SaaSのスプリントレビューではLookerのダッシュボードを使って状況が共有されています。

毎週共有されているダッシュボード(参考程度に)。

ダッシュボードに対してフィルターがかけられたり、ダッシュボードからExploreに移行してさらに詳細に分析したりなどができるので、データ分析体験として非常に良いものだと感じています。

導入して良かったこと

「クエリを書く」という概念がなくなった

クエリを書かずにデータ分析を行える。これが当たり前にできるのが何よりLookerの凄さだなと感じました。これまでRedash上で分析したいデータごとにクエリを書いていたのが、dimensionを組み合わせるだけで思ったとおりのデータが出せるのはデータ分析の体験としてはとても良いです。

細かいところに手の届くLooker

開発をしているとJOINによってテーブルが膨らんで、でもその中でidでDISTINCTしつつ平均や合計を求めたいときなどがあると思います。そういうときはLookerのavg_distinctsum_distinctを使えばすぐにできたりします。

あと私のお気に入りの機能はpdt(persistent derived table))です。これは一時テーブルを永続化できる機能です。例えば集計用のテーブルや不要な列や行をフィルターしたテーブルを保存しておけます。これによって複雑なJOINを毎回することなく、すぐにデータを取り出すことができたりします。

さらにincremental pdtという機能もあります。例えばテーブル更新時にレコード作成日が最新日の行だけ追加することで、テーブルをまるごとDELETEしてINSERTする必要がなくなる、というような機能です。BOXIL SaaSの分析ではこれをログ用のテーブルを保存するために使っています。

このようにLookerの開発体験はすごく良く、とても細かいところに手が届くなあという印象です。

現状の課題

Redashを脱しきれていない

脱Redashができたかのようなタイトルなのですが、現状、Redashを完全に脱してLookerに移行できているわけではありません。

これはビジネスサイドの活用が進んでいないことが原因としてあります。一部の人にはLookerのアカウントを渡しているのですが、すべての人にアカウントを渡しているわけではないので、まだまだRedashユーザーが多いです。

この原因としては下記のようなことが挙げられるかと思います。

  1. ユーザーがLookerの使い方に慣れていない
  2. Lookerの中で使えるデータ項目がどういうデータなのかユーザーに分かってもらえていない
  3. Lookerが高い

1は定期的にLooker講座を社内で開いてLookerの使い方をビジネスユーザーに周知しています。

2は現状の課題としてあります。こちらはこれまでバラバラに定義していたり、ドメイン言語が統一されていなかったことによる弊害かと思います。このあたりの課題の解決策は検討中です。やるとするなら、ビジネスユーザー向けにLookerデータ項目について勉強会を開催したり、ドキュメントにまとめたりといった対策でしょうか。

3についてなのですが、Lookerは高機能ゆえか料金が高めです。これもLookerがビジネスユーザーにまだまだ使ってもらえていないことの原因としてあるかと思います。

まとめ

いかがだったでしょうか。今回脱Redashを目指す意思決定をしたスマートキャンプですが、まだまだLookerへの完全移行までは時間がかかると見込んでいます。

実はLookerに移行しようと社内で考え始めたのは去年の今頃ぐらいで、実際にここに来るまでには1年ほどかかっています。それほどデータ分析基盤の移行はハードで時間のかかるものだということですね。

これからもスマートキャンプはデータドリブンな会社を目指していきます。私達の事業に興味があれば下のリンクから採用ページも見てみてくださいね!