Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Redash 導入事例から考える OSS BI 導入チェックリスト

Takuya Arita
February 20, 2018

Redash 導入事例から考える OSS BI 導入チェックリスト

Redash Meetup #1 の発表資料です #redashmeetup

Takuya Arita

February 20, 2018
Tweet

More Decks by Takuya Arita

Other Decks in Technology

Transcript

  1. アジェンダ • 自己紹介 • Redash について • ユニトーンの Redash 導入事例

    • 導入事例を踏まえた OSS BI 導入チェックリスト • まとめ
  2. 自己紹介 • 有田 拓哉(@ariarijp) • 株式会社ユニトーン所属 • 広告 API を利用したツール開発と、Redash

    な どを用いたデータ分析基盤構築が主な仕事 • Redash は検証期間を含めると2015年から現在 まで使い続けている • 気づいたらブログが Redash の記事ばかりになっ ていました http://ariarijp.hatenablog.com/
  3. Redash について • 多くのデータソースに接続可能な OSS の BI ツール。フルマネージドの SaaS 版も提供している

    • グラフやダッシュボードでデータを可視化できる • クエリの結果を CSV や Excel でダウンロードできる • 作成したクエリは URL でアクセスできるため、データ共有が容易 • クエリパラメータによって、SQL を書けなくても動的なクエリを実行でき る
  4. Redash 導入の経緯 • 多くのデータソースに対応している • クエリエディタから SQL を直接実行でき、クエリの Fork 機能がある

    • API で集計結果などを扱うことができる(導入当初は検証程度) • OSS であるため、動作させるサーバーとデータソースがあれば使い始め ることができる • Python で書かれているため、何か合ったらソースを読めばいい。と割 り切ることができる
  5. Redash導入によって起きた変化 • SQL を使用できるため、抽出条件や集計の方法の制限がほぼなくなった • 複雑な集計クエリでも、エンジニアが一度書いたクエリを利用者はパラ メータを変えて実行するだけで、データをすぐに抽出できるようになっ た • データの集計や分析を

    Redash 起点にすることで、クエリの URL を共有 するだけでデータや分析結果を気軽に共有できるようになった • 集計結果を API で取得・加工できるため、集計結果を入力としたプログ ラムで、データを二次的に利用できるようになった
  6. Redash導入によって大変になったこと • 利用者が「いい意味で欲張り」になり、複雑な集計クエリ作成依頼が増えた • 300行を超えるクエリも多い • 今までデータベースに保存していなかったデータも集計対象にしたいという要望 が増え、データ分析基盤構築作業が増えた • Embulk

    や Digdag のありがたみを痛烈に感じる • 多くの業務が Redash 起点になっているため、Redash のパフォーマンスが落ちる と業務が止まる • モニタリング、定期的なリソース見直し、不要クエリの削除などの地道な対応
  7. 誰が使うか • 「エンジニア以外も SQL を書けるようにした」という事例があるが、 それを成功させるのは本当に難しい • クエリパラメータを使った、ある程度柔軟性があるクエリをエンジニア が書き、それを利用してもらうところから始める •

    SQL を書けなくても、チームが持っているデータの種類や、使用できる データ集計軸など、データに関わる知識の底上げについては、BI ツール 導入とセットで取り組む • エンジニア主導で導入・活用を進め、データ活用の下地を作る
  8. ユニトーンにおいて誰が Redash を使っているか • エンジニア • 利用者の要求に合わせて集計クエリを作成 • API でクエリの結果を使用し、広告自動運用やレポート自動書き出し

    • 利用者 • 主にエンジニアが作成した集計クエリを使ってデータを抽出 • SQLを書くことは稀で、抽出条件はクエリパラメータを使って変える • どんなデータを持っているか、どんな集計が可能かについての理解度アッ プについては、継続して取り組んでいる課題のひとつ
  9. 何をデータソースにするか • Redash は大抵のデータストアに対応しているため、データストアの種類は あまり問題にならない • 現状のインフラやデータストアの構成を把握した上で導入する • 本番 DB

    を参照するか?レプリカを参照するか? • ネットワーク上のどこに Redash を配置するか • 現状のインデックスは適切か • これから導入を検討する場合は、可能であれば BigQuery などのデータ ウェアハウスと組み合わせて使用することがおすすめ
  10. どうやって運用するか • Redash の運用を例にすると Ubuntu や Docker 、Python 、nginx 、

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

    の全体像を把握しながら運用することは容易だった • 設定のチューニングについては、公式ドキュメントやソースコードを参照しつ つ、試行錯誤しながら運用している • クエリのキャッシュは積極的に利用せず、原則毎回 Refresh する運用 • キャッシュが有効に使用されるケースもあるが、弊社のユースケースでは、 「最新のデータを常に取得する」と運用ルールを単純化してしまったほうが 問題が起こりにくいため • 一般的なLinuxサーバのメトリクスのみでモニタリングしている。アラートが飛 ぶのはたいていメモリ/スワップ使用量増かディスクIO負荷増
  12. まとめ • 本番環境への導入については前述のような悩み事もあるが、開発環境な どがあれば気軽に導入して手触りを確かめるというのも大事 • まだ Redash やその他の BI ツールを触ったことがない。という方は

    @kakakakakku が公開しているの Redash ハンズオンをおすすめします • https://github.com/kakakakakku/redash-hands-on • Redash Advent Calendar 2017 でも様々な知見が公開されてます • 本日お話した内容に関連するような記事もあるのでチェックしてみて ください