Redashでデータ活用の壁をなくす / Redash spreads data analysis culture

Transcript

1. Redashでデータ活用の壁をなくす @Udomomo 2019/02/19 Tora-lab
2. • どもも(@Udomomo) • BtoB SaaSのサーバサイド(Javaによる大規模データ処理) • 副業でRuby on Rails • 趣味でGo 自己紹介
3. 非エンジニアでもデータ活用ができる ダッシュボードツール Redashとは？
4. • 自社サービスの利用データはMySQLに蓄積されているが、 開発チーム以外アクセスする習慣がなかった • CSチームは個々のクライアントの定性的な理解は豊富だが、 データのことは分からない • NPS(顧客満足度)などは追えるが、自社サービスの 実際の利用状況をリアルタイムで追う術がなかった Redashが必要になった背景 → 誰でもデータを触れる仕組みが必要！
5. • クエリを書く • グラフ・ダッシュボードを作る • アラートで監視する Redash利用の流れ
6. • Amazon EC2 AMI • Google Compute Engine Image • Docker Image (→自社サーバで運用) • Webサービスとして利用(セットアップの必要なし・有料) セットアップ
7. DBと接続する
8. クエリを書く
9. クエリをフィルタ可能にする(Redash独自の文法)
10. グラフを作る
11. ダッシュボードを作る
12. アラートを設定する
13. • 機能・UIがシンプルでわかりやすい • クエリを触らなくても簡単にデータをフィルタできる • サービスの簡易モニタリングも可能 Redashの特徴 • 高度な統計・解析処理には不向き。日常業務における データ活用のハードルを低くするためのツール。
14. 自社での活用例
15. • 開発チーム以外でSQLを書ける人が少ない • 開発チームの人手も多くない 導入時の方針 • まずは業務サイクルに乗せることを優先 • SQLの教育・データのバックアップ体制構築などは一旦せず、 今使えるリソースだけで運用を回す • データを見るだけなら誰でもできるよう、閲覧専用権限の アカウントは希望者全員に発行
16. 運用体制 MySQL (本番環境の replication) MySQL (解析用) data import (※) CS (SQL経験者) クエリ・ ダッシュボード 作成 CSチーム等 閲覧・分析 分析の要望 ※あまりデータ量が多くないため、 日次でmysqldump & importしている
17. • クライアント別に利用中のログインID数カウント • 昨日新規発行されたログインID一覧(+アラート) • 特定の項目の設定を忘れているログインID一覧 • 1ヶ月以上ログインしていないID一覧 • ログインIDごとの新規投稿数の推移(日別) など 自社サービス(BtoB SaaS)用に実際に作られたクエリ
18. • SQLがボトルネックになっているのをどう解消するか？ ◦ SQLを書ける人が少ないため、Redashを使えば解決できる課題を抱えていても 放置されている可能性がある ◦ MySQLが8.0になっておらずwindow関数が使えないなど、DB側の都合で ハードルが高くなっている側面もある 今後の課題 • Redash自体の運用をどう回していくか？ ◦ Redashは開発速度が速く、数ヶ月に一度ペースでバージョンが上がる。 そのため、テスト用環境を別で作っておくのが望ましい ◦ 重いクエリが増えるにつれてRedash自体のパフォーマンスが下がっている。 今後各クエリのチューニング・バックアップが必要になりうる
19. • 公式フォーラム ◦ https://discuss.redash.io ◦ 日本語用カテゴリもあります！ Redash関連サイト • Redashハンズオン資料(非公式・日本語) ◦ https://github.com/kakakakakku/redash-hands-on ◦ 今日紹介しなかった機能も多く掲載されています • GitHub ◦ https://github.com/getredash/redash ◦ Issue・プルリク歓迎
20. Thank You Credit: • https://redash.io • https://github.com/kakakakakku/redash-hands-on • https://www.iconfinder.com/iconsets/IconsLandVistaPeopleIconsDemo