Redash Meetup #1 発表資料 Redash 導入事例から考える OSS BI 導入チェックリスト @ariarijp

アジェンダ • 自己紹介 • Redash について • ユニトーンの Redash 導入事例 • 導入事例を踏まえた OSS BI 導入チェックリスト • まとめ

自己紹介 • 有田 拓哉(@ariarijp) • 株式会社ユニトーン所属 • 広告 API を利用したツール開発と、Redash な どを用いたデータ分析基盤構築が主な仕事 • Redash は検証期間を含めると2015年から現在 まで使い続けている • 気づいたらブログが Redash の記事ばかりになっ ていました http://ariarijp.hatenablog.com/

Redash について • 多くのデータソースに接続可能な OSS の BI ツール。フルマネージドの SaaS 版も提供している • グラフやダッシュボードでデータを可視化できる • クエリの結果を CSV や Excel でダウンロードできる • 作成したクエリは URL でアクセスできるため、データ共有が容易 • クエリパラメータによって、SQL を書けなくても動的なクエリを実行でき る

ユニトーンの Redash 導入事例

Redash 導入以前の課題 • データ抽出は社内ツール、またはエンジニアがデータベースにクエリを 実行していた • 社内ツールは細かい条件や集計に対応できず、データの利用者はExcel などでデータを加工する必要があった • データベースから直接データ抽出をする場合はエンジニアが作業しなく てはならないため、データ抽出のリードタイムに課題があった

Redash 導入の経緯 • 多くのデータソースに対応している • クエリエディタから SQL を直接実行でき、クエリの Fork 機能がある • API で集計結果などを扱うことができる(導入当初は検証程度) • OSS であるため、動作させるサーバーとデータソースがあれば使い始め ることができる • Python で書かれているため、何か合ったらソースを読めばいい。と割 り切ることができる

Redash導入によって起きた変化 • SQL を使用できるため、抽出条件や集計の方法の制限がほぼなくなった • 複雑な集計クエリでも、エンジニアが一度書いたクエリを利用者はパラ メータを変えて実行するだけで、データをすぐに抽出できるようになっ た • データの集計や分析を Redash 起点にすることで、クエリの URL を共有 するだけでデータや分析結果を気軽に共有できるようになった • 集計結果を API で取得・加工できるため、集計結果を入力としたプログ ラムで、データを二次的に利用できるようになった

Redash導入によって大変になったこと • 利用者が「いい意味で欲張り」になり、複雑な集計クエリ作成依頼が増えた • 300行を超えるクエリも多い • 今までデータベースに保存していなかったデータも集計対象にしたいという要望 が増え、データ分析基盤構築作業が増えた • Embulk や Digdag のありがたみを痛烈に感じる • 多くの業務が Redash 起点になっているため、Redash のパフォーマンスが落ちる と業務が止まる • モニタリング、定期的なリソース見直し、不要クエリの削除などの地道な対応

大変なこともありますが 便利に Redash を使っています

ユニトーンの Redash 導入事例を踏まえた OSS BI 導入チェックリスト

導入チェックリスト □導入後に期待することは何か □誰が使うか □何をデータソースにするか □どうやって運用するか

導入後に期待することは何か • データ抽出を誰にでもできるようにしたい、データを一元的に可視化し たいなど、導入のモチベーションはチームによって様々 • 何を期待するかによって、事前に何を検証すべきかが決まる • データ抽出を主な目的にするのであれば、クエリパラメータや自動更 新などの機能を検証 • データ可視化であれば、複数データソース接続の検証や、使用できる 可視化パターンの検証

ユニトーンが Redash 導入時に期待していたこと • 誰でもデータ抽出をできるようにして、データ抽出のレイテンシーを減 らす • エンジニアがクエリを一度だけ書き、利用者はクエリパラメータを使っ て条件を変化させながら何度でもデータ抽出できる • コストを大きくかけずに BI ツールを導入する

誰が使うか • 「エンジニア以外も SQL を書けるようにした」という事例があるが、 それを成功させるのは本当に難しい • クエリパラメータを使った、ある程度柔軟性があるクエリをエンジニア が書き、それを利用してもらうところから始める • SQL を書けなくても、チームが持っているデータの種類や、使用できる データ集計軸など、データに関わる知識の底上げについては、BI ツール 導入とセットで取り組む • エンジニア主導で導入・活用を進め、データ活用の下地を作る

ユニトーンにおいて誰が Redash を使っているか • エンジニア • 利用者の要求に合わせて集計クエリを作成 • API でクエリの結果を使用し、広告自動運用やレポート自動書き出し • 利用者 • 主にエンジニアが作成した集計クエリを使ってデータを抽出 • SQLを書くことは稀で、抽出条件はクエリパラメータを使って変える • どんなデータを持っているか、どんな集計が可能かについての理解度アッ プについては、継続して取り組んでいる課題のひとつ

何をデータソースにするか • Redash は大抵のデータストアに対応しているため、データストアの種類は あまり問題にならない • 現状のインフラやデータストアの構成を把握した上で導入する • 本番 DB を参照するか？レプリカを参照するか？ • ネットワーク上のどこに Redash を配置するか • 現状のインデックスは適切か • これから導入を検討する場合は、可能であれば BigQuery などのデータ ウェアハウスと組み合わせて使用することがおすすめ

ユニトーンでは何をデータソースにしているか • 社内システムの本番 DB • データ量やデータの増加量を見積もれるため • しかし、Redash の活用が進むに従い、利用者が「いい意味で欲張 り」になってきた • 複雑な集計や、粒度の細かい集計が必要になる機会が増えたため、 BigQuery を併用する環境を準備中

どうやって運用するか • Redash の運用を例にすると Ubuntu や Docker 、Python 、nginx 、 PostgreSQL 、Redis の知識が必要になる • Redash の設定を環境に合わせてチューニングすることもある • クエリの実行モデルやキャッシュの仕組みを知らないと、落とし穴に落 ちることがある • データへのアクセス権限管理 • Redash の導入によってサーバが増えるため、サーバの運用・監視など も発生する

ユニトーンでの Redash 運用 • Ubuntu 、Python など Redash で使用している技術の運用経験があったため、 Redash の全体像を把握しながら運用することは容易だった • 設定のチューニングについては、公式ドキュメントやソースコードを参照しつ つ、試行錯誤しながら運用している • クエリのキャッシュは積極的に利用せず、原則毎回 Refresh する運用 • キャッシュが有効に使用されるケースもあるが、弊社のユースケースでは、 「最新のデータを常に取得する」と運用ルールを単純化してしまったほうが 問題が起こりにくいため • 一般的なLinuxサーバのメトリクスのみでモニタリングしている。アラートが飛 ぶのはたいていメモリ/スワップ使用量増かディスクIO負荷増

(再掲)導入チェックリスト □導入後に期待することは何か □誰が使うか □何をデータソースにするか □どうやって運用するか

まとめ • 誰が使うかをイメージして導入する。ツール導入は使われてこそ意味が ある • BI ツールの導入は利用シーンを意識して、エンジニア主導で利用者を巻 き込んで進めることが必要 • データ活用が進むことで、派生的にデータ基盤の整備も必要になること を想定する • データ基盤は一度動き始めると、それなしでは業務が回らない状況にな るため、安定運用できるように事前知識・周辺知識も忘れずに押さえて おく

まとめ • 本番環境への導入については前述のような悩み事もあるが、開発環境な どがあれば気軽に導入して手触りを確かめるというのも大事 • まだ Redash やその他の BI ツールを触ったことがない。という方は @kakakakakku が公開しているの Redash ハンズオンをおすすめします • https://github.com/kakakakakku/redash-hands-on • Redash Advent Calendar 2017 でも様々な知見が公開されてます • 本日お話した内容に関連するような記事もあるのでチェックしてみて ください

Thank you 引き続き Redash Meetup をお楽しみください