inFablic | Fablic, inc. Developer's Blog.

フリマアプリ フリル (FRIL) を運営する Fablic の公式開発者ブログです。Fablic のデザイナー・エンジニア・ディレクターが情報発信していきます。

FablicでのRedash導入事例

プロダクトマネージャー兼エンジニアのid:ninjinkunです。この記事はFablic Advent Calendar 2016のエントリーです。

Fablicでは今年の9月頃からOSSのBIツールであるRedashを導入して、誰でもSQLを叩ける環境を整備しました。以下、運用してわかったRedashの良い点、悪い点、課題などについて述べていきます。

なお、接続しているのは本番データから個人情報を抜いた分析専用slaveです。他にも時系列のデータが入っている別の分析DBや、BigQueryも接続されています。

f:id:ninjinkun:20161206195338p:plain

Redashの画面例

Redashの良い点

Redashの導入により、

  • メンバーが誰でもSQLを書くようになった
    • 特にディレクターは全員、デザイナー、マーケターなどの職種でも増加
  • SQL文を共有する文化が浸透した
    • 日付を丸めてgroup byするなどのよく使うテクニックが広まった
  • 各ディレクターがダッシュボードとして使っているGoogle SpreadSheetへの数値入力が自動化された

といった効果が現れました。これはRedashに

  • Google Apps認証ですぐに使えてセットアップが不要
    • クライアント型のSequel Pro等に比べて導入が容易
  • 各クエリ毎にURLが発行されるので共有ができる
  • SQLの定期実行が可能

といった特徴があるからだと思われます。

Redashの悪い点(というか弱い点)

他方、Redashの弱い点としては

  • グラフ化機能が貧弱、特にコホートなどは微妙
  • DBのカラム名がselectするまでわからない 12/9追記 カラム名はわかるが、型とデータのプレビューがない
    • テーブルの内容を知らない場合は面倒

といった点があります。

自分は、BIツールにはユーザーの動きを探る「探索的な行動」とKPIを分解した数字を「レポーティング」の2つの用途があると考えているのですが、Redashは後者の用途に向いていると思います。

他ツールとの使い分け

こうした弱点を補うために、どのDBに何が入っているかを調べるときはホットケーキのアイコンでお馴染みのSequel Proを使っている人が多いようです。

また、Redashにはグラフ化やダッシュボードなどの機能もあるのですが、可視化の用途ではどちらかというとGoogle SpreadSheetにデータを入力してグラフ化する方が柔軟で便利ではないかと思います。RedashにはAPIからCSVやJSONを吐く機能があるので、任意のSQLをWeb API化するツールとして使うのもおすすめです。Google SpreadSheetにはIMPORTDATA関数で読み込むことができます。今のところは1時間毎に再読み込みされているようです。この機能を使って、弊社の事業責任者が今まで手動で入力していたSpreadSheetを自分で自動化していました。

課題

現在顕在化している課題としては、元々indexがないカラム(作成日、更新日など)にselectしてしまい、分析DBの負荷が上がってしまう問題があります(アプリケーション用のDBを分析に転用しているので…)。この対策として、アプリケーションからもselectするカラムでindexがない部分ついてはindexの追加を行う予定です。また、中級者向けにSQLチューニングの社内セミナーを行う計画もあります。

f:id:ninjinkun:20161206142023j:plain 写真は初心者向けSQLセミナーの様子

まとめ

色々書いてみましたが、やはり最初に挙げた誰でもSQLを書くようになったという点が、Redash導入の一番の成果であると思います。

例えば、プロダクトマネージャーやデザイナーがDBのデータ構造に詳しくなることで、バックエンドの開発見積もりへの理解が深まります。マーケターであれば、購買情報を探索することで、次のキャンペーンの対象セグメントを探したり、その結果をレポートすることができるようになります。

Redashの導入を入り口として、今後も社内の分析基盤と分析文化を充実させていきたいところです。