Redash Meetup 3.0.0 で発表した「Hidden gems in Redash」の補足説明

先日のイベントで話した内容について、スライドを公開したものの、英語で書いてしまったせいで誤解を生んでしまうことがあったようなので、改めて日本語でも解説しておきます。

発表資料

speakerdeck.com

タイトルについて

「Hidden gems in Redash」。Redash の中にある見つかりにくい機能を「Hidden gems」と例えたつもりだったのですが、ここからわかりにくかったなと反省しているところです。

Ruby の gem の話と混同してしまったかたも、もしかしたらいたのかもしれません。

Query Results Data Source

これについては、去年書いた記事があるので、そちらを見ていただくのが良いと思います。

ariarijp.hatenablog.com

上記の記事でもふれていますが、現時点でクエリパラメータを使ったクエリを使うことはできないという制約があり、それについては現在議論中です。

Thoughts on adding support for queries with parameters in query results data source - Development - Redash Discourse

ReQL query language - Feature Requests - Redash Discourse

Python Data Source

Redash 3.0.0 以前から使用できるので、Redash を長く使っているかたには馴染みがある機能の一つでもあると思います。

スライド中で紹介した記事は以下です。

Redash Python functions

re:dash Python datasource join example · GitHub

国内での活用事例もいくつか見つかりますので、興味があれば探してみてください。

Url Data Source

このあたりから知られにくい機能の話になってきます。

Url データソースは HTTP エンドポイントをデータソースとして扱える機能です。

エンドポイントの仕様としては以下のようなものがあります。

  • 結果を Redash 形式の JSONで返す
  • 対応する HTTP メソッドは GET のみ
  • リクエストボディは送信できない

上記の仕様を満たしていれば、ミドルウェアや言語に制約はないので、Web 開発に慣れているエンジニアが多いチームであれば導入を検討しやすい機能だと言えます。

発表中でも紹介しましたが、JX通信社さんでの事例が最近公開されていたので、この記事でUrl データソースを知った方もいらっしゃるかと思います。

tech.jxpress.net

Script Data Source

この機能はサーバー上に配置されているスクリプトや実行ファイルをデータソースとして扱える機能です。

スクリプトが標準出力に Redash 形式の JSON を出力することが満たされていれば、Url データソース同様にどんな言語で書くこともでき、発表時は PythonBash で実装した例をご紹介しました。

ただし、この機能は任意のスクリプトを実行することができるという点で、導入を検討する際は、使用できるユーザーを制限するなどの権限管理などには注意しましょう。

Extending Redash

最後に紹介したのは、Redash のクエリランナーを自作するという話を紹介しました。

クエリランナーの挙動をある程度把握することができれば、独自のクエリランナーを作成し、Redash 上で動作させることができるようになっています。

クエリランナーの自作については、以前書いた記事があるので、そちらを参考にしてください。

ariarijp.hatenablog.com

また、発表の中で紹介した、Redash 開発者の Arik が後悔している記事もあわせて紹介しておきます。

Creating a new query runner (data source) in Redash - Development - Redash Discourse

外部 API を使用する、CSVExcel のファイルを S3 や Google ドライブから取得して表示するなど、クエリランナーを自作できると、Redash 活用の幅を広げることができると思います。

発表のまとめ

Redash を高度に活用するためのいくつかの機能を紹介しました。

Redash は 多くのデータソースに対応しながらも、Url データソースやクエリランナーの自作など、開発者が拡張できる余地があります。

ただし、無理にこれらの機能を使おうとしなくても、よく使われる既存のデータソース(MySQLPostgreSQL, BigQuery など)だけでほとんどの問題を解決できるはずです。

あくまで、既存のデータソースでは解決できない問題に出会った場合に利用を検討する程度に、今回の発表の内容を捉えていただくと良いと思います。

With great power comes great responsibility

この記事のまとめ

当日お話した内容を思い返しつつ、解説記事を書いてみました。

正直、無理に英語で書くこともなかったかなとは思うものの、英語で書こうとすると回りくどい言い回しができなくなるため、メッセージがシンプルにできるのかなという感想を抱きました。

英語で書いた理由は、単にチャレンジしたかったというものの他に、海外の Redash ユーザーにも読んでもらえたらいいなと思ったというのがあります。

実際読んでもらえているかはわかりませんが、それはスライドの View 数や Star 数でも見ながら想像してみようと思います。

Redash Meetup 3.0.0 を開催しました

f:id:ariarijp:20180710230401j:plain

タイトルのとおりですが、7/9に Redash Meetup 3.0.0 を開催しました。

redash-meetup.connpass.com

今回は LT 枠を削って10分の登壇枠を2つ用意し、約1時間半で4本の登壇をみっちり詰め込んだイベントになりました。

発表内容振り返り

Redash の API 活用事例 / 株式会社ココラブル 井上さん

speakerdeck.com

Redash API 活用事例について、具体例を交えて発表されていました。

API を使用するシーンとして各社で利用されているであろう、Slack 通知や Google スプレッドシートへの自動書き出しだけでなく、API と Git を組み合わせたクエリのバージョン管理についても発表されていました。

発表の中でいくつかライブラリやツールを紹介していましたが、そのうちのいくつかは私が GitHub で公開しているものだったりします。

よろしければチェックしてみてください。

github.com

github.com

みんなが Redash を 気持ちよく使うやり方を 考える / コネヒト株式会社 金城さん

speakerdeck.com

前回、コネヒトの永井さんに Redash の導入について登壇していただきましたが、今回は導入後の話を中心に発表していただきました。

登壇をお願いするきっかけとなったクエリ乱立問題へたち向かう話や、今起きている問題を「データ活用のステージ」に照らし合わせて、解決のアプローチを考えるという話は、データ分析や分析基盤構築に関わるエンジニアにとって、共感のある話だったのではないかと思います。

発表の中でも触れられていたハンズオン資料ですが、今回も受付を手伝ってくれた id:kakku22 が作ったもので、実はこの資料きっかけで Redash Meetup 立ち上げたという小話があります。

まだ試したことがないかたは、ぜひ資料を見ていただき、ついでに Star もつけていただけると良いかと思います。

github.com

Hidden gems in Redash / 株式会社ユニトーン 有田 (ariarijp)

speakerdeck.com

他の登壇者様が現場感のある Redash の事例についてお話いただけることがわかっていたので、そのなかで私はちょっと変わった発表をしたいと思っていました。

今回のテーマは「Redash の高度な活用」として、様々な(一部はデフォルトでオフになっている)データソースの紹介や、Redash のクエリランナーを自作するといった話を思う存分お話させていただきました。

もちろん、ただのネタ発表ではなく Redash の開発者フレンドリーなところがみなさんに伝わったのではないかと思います。

イベント後の懇親会でもポジティブな感想をいただけたので、それなりにお楽しみいただけたのかなと思っています。

Redash運用に付きまとう課題とその解決方法 / 株式会社エウレカ 大久保さん

speakerdeck.com

エウレカにおける Redash 導入のきっかけや、導入後に発生したいくつもの課題を3つのフェーズに分けてご紹介いただきました。

「クエリ乱立」、「不正確クエリによる意思決定のミス」、「権限管理」などの Redash を運用するエンジニアにとって定番の課題だけでなく、

「キューづまりとの戦い」、「BigQuery の課金額上昇」、「便利だけど大変なことも多い定期実行」などについても、エウレカさんの事業成長のなかで日々起こったであろう課題について、事細かにお話いただきました。

現在は Tableau も併用されているとのことで、Redash 導入によってデータ活用が進んだ先に、どのように分析環境や基盤を広げていくか。という点でも参考になるお話だったかと思います。

こちらの発表については、早速エウレカさんのエンジニアブログでも記事にされていますので、そちらもぜひ読んでみてください。

medium.com

また、エウレカさんには DataManagement Engineer というポジションがあるようです。今回の発表や資料を見て興味をもたれた方は、素敵なオフィスに遊びにいってみるのもよいと思います。

eure.jp

懇親会

今回は Redash Meetup 初の懇親会も開催されました。会場だけでなく飲み物やピザを提供してくださった エウレカ様、本当にありがとうございました!

懇親会中、ふらふらと歩きながらいろいろな方とお話したのですが、Redash の導入・活用事例、悩みなど「これこそ Redash Meetup の懇親会だ!」と思うような会話が飛び交っていて、主催者としても大変うれしい気持ちになりました。

Twitter のトレンド入り

参加者数が過去最多であったり、ゲスト用のWiFiが快適に利用できたこともあるのか、Twitter への投稿が過去最多だったように思います。

一時はトレンド(おそらく東京エリア)にも入っていたようです(運営に手一杯でリアルタイムでは見られませんでした

自分が運営するイベントがトレンド入りするようなことは想像もしていなかったので、これには驚くばかりでした。

まとめ

今回はエウレカ様の会場をお借りしたり、募集枠が前回の倍以上だったり、懇親会ありだったりと多くのチャレンジや変化があったイベントになりました。

開催前はいろいろと不安を感じていたのですが、登壇者の皆様、参加者の皆様、会場設営から懇親会までお付き合いいただいたエウレカの皆様のおかげで、楽しくまじめに Redash の情報交換ができた会になったと思います。

「次回のイベントはいつですか?」という嬉しい質問もいただいていたのですが、現時点で次回の日程は決めていません。

しかし、Redash のバージョンを追い抜くまではやろうと思っているので、4.0.0 は実施する予定です。

次回については決まり次第お伝えさせていただきますので、ご興味があれば私の Twitter や connpass の Redash Meetup グループをチェックしてみてください。

twitter.com

redash-meetup.connpass.com

以上、Redash Meetup 3.0.0 の開催レポートでした。

楽しかった!!!!!

Redash の複数台構成化その3(worker を別インスタンスにする)

以下の記事の続きです。

ariarijp.hatenablog.com

前置き

前の記事の手順を実行し、Redash と PostgreSQL、Redis をそれぞれ別インスタンスで動作させる環境ができていることを前提とします。

worker を別インスタンスにする

worker のインスタンスをセットアップする

worker インスタンスは server インスタンスと同様、Redash の Ubuntu 用 bootstrap スクリプトで Redash を導入した状態になっているものとし、PostgreSQL、Redis インスタンスにそれぞれ接続できるようになっていることを前提とします

  • プライベート IP 192.168.33.11

Redash のバージョンについて

worker を別インスタンス化するには、server と同じバージョンの Redash をインストールする必要があります。

初期構築時に server と worker を分ける場合はそれほど問題にならないと思いますが、ある程度一台構成で Redash を稼働させた状態から複数台にする場合は、最新バージョンとの差異が問題になることもあります。

その場合、既存環境を最新にアップグレードしてから複数台構成にするなどの対応が必要となりますが、この記事ではアップグレード手順などについては割愛します。

不要なサービスを停止する

nginx, PosgreSQL, Redis は使用しないので、以下のコマンドで停止し、自動起動も無効にします。

$ sudo systemctl stop postgresql && sudo systemctl disable postgresql
$ sudo systemctl stop redis && sudo systemctl disable redis
$ sudo systemctl stop nginx && sudo systemctl disable nginx

Redash の設定を変更する

server インスタンスと同様に、worker インスタンス/opt/redash/.envREDASH_REDIS_URLREDASH_DATABASE_URL を以下のように変更します。

export REDASH_REDIS_URL=redis://192.168.33.101:6379/0
export REDASH_DATABASE_URL="postgresql://redash:redash@192.168.33.100/redash"

supervisor の設定を変更する

最後に、supervisor の設定を変更します。

worker インスタンスでは、server を起動する必要がないので、 /etc/supervisor/conf.d/redash.confredash_server の設定の中の autostartautorestart をそれぞれ false にします。

[program:redash_server]
command=/opt/redash/current/bin/run gunicorn -b 127.0.0.1:5000 --name redash -w 4 --max-requests 1000 redash.wsgi:app
directory=/opt/redash/current
process_name=redash_server
user=redash
numprocs=1
autostart=false
autorestart=false

/etc/supervisor/conf.d/redash.conf を変更したら、Redash と supervisor の設定を適用するため、supervisord を再起動します。

$ sudo systemctl restart supervisor

再起動を完了したら、 ps コマンドなどで Redash 関連のプロセスが Celery のみ起動されていることを確認しましょう。

これで worker の設定は完了です。

server のインスタンスの設定を変更する

worker インスタンスCelery が動作するようになったので、server インスタンスでは Celery を動作させないようにします。

/etc/supervisor/conf.d/redash.confredash_celeryredash_celery_scheduled の設定の中の autostartautorestart をそれぞれ false にします。 、

[program:redash_celery]
command=/opt/redash/current/bin/run celery worker --app=redash.worker --beat -c2 -Qqueries,celery --maxtasksperchild=10 -Ofair
directory=/opt/redash/current
process_name=redash_celery
user=redash
numprocs=1
autostart=false
autorestart=false

[program:redash_celery_scheduled]
command=/opt/redash/current/bin/run celery worker --app=redash.worker -c2 -Qscheduled_queries --maxtasksperchild=10 -Ofair
directory=/opt/redash/current
process_name=redash_celery_scheduled
user=redash
numprocs=1
autostart=false
autorestart=false

/etc/supervisor/conf.d/redash.conf を変更したら、設定を適用するため、supervisord を再起動します。

再起動を完了したら、 ps コマンドなどで Celery のプロセスが起動されていないことを確認しましょう。

動作確認

ここまでの設定が完了したら、 Redash の画面上でクエリを実行してみます。

クエリが実行できれば、worker の別インスタンス化は完了です。

まとめ

Redash の worker プロセスを別インスタンスで実行する方法を紹介しました。

Redash のミドルウェア構成を把握することができればそれほど難しくない対応ですが、大規模なデータを扱いたい場合や、クエリのキューがつまりがちな環境では、今回紹介したような方法で worker を別インスタンス化することで問題を解消できることがあると思います。

しかし、サーバ管理の手間は増えるため、ひとつのインスタンスに全部のせ担っている標準的な構成でスケールアップやミドルウェアや Redash のチューニングに限界を感じた場合の選択肢の一つ。として考えるぐらいが個人的には良いと思います。

次回は、この記事から少し派生した設定として、 redash_celery_scheduled のプロセスをさらに別インスタンスで起動し、詰まりがちなスケジュール実行をスケールアウトする方法を試してみる予定です。

Redash の複数台構成化その2(Redis を別インスタンスにする)

以下の記事の続きです。

ariarijp.hatenablog.com

前置き

前の記事で Redash と PostgreSQL を別インスタンスで動作させる環境ができていることを前提とします。

Redis を別インスタンスにする

PostgreSQL に比べ、Redis を別インスタンスにすることは性能に大きく影響を与えるものではないと思いますが、Redash に全部入り状態になっているミドルウェアから別インスタンスに切り出しやすいこともあり、この記事では Redis を別インスタンスにする方法を紹介します。

Redis のインスタンスを Redash インスタンスから参照できるネットワーク内に配置し、Redash の設定を変えていきます。

Redis インスタンスの設定は割愛しますが、Redash インスタンスからアクセスできるようになっていることを前提とします。

  • プライベート IP 192.168.33.101

Redis のバージョンは デフォルトの Ubuntu 16.04 でインストールできる 3.0.6 としています。

設定を書き換える

/opt/redash/.env で定義されている REDASH_REDIS_URL を、以下のように書き換えます。

export REDASH_REDIS_URL=redis://192.168.33.101:6379/0

これで Redis が準備できました。

Redash を再起動して、Redash にアクセスし、何かクエリを実行してみましょう。

クエリが実行できたら、Redash インスタンス上の Redis は停止しても問題ありません。

既存環境を使用する場合の注意点

既存の Redash の Redis を別インスタンスにする場合は、実行中またはキューに入っているクエリが実行されない、正常終了しないなどの問題が起きる可能性が考えられます。

作業前にキューに何も入っていない、または再実行などで問題を回避できることを確認したうえで対応するのがよいでしょう。

まとめ

簡単でしたが、Redash で使用する Redis を別インスタンスにする手順を紹介しました。

次回は Redash の worker プロセスを別インスタンスで実行する方法を紹介する予定です。

Redash の複数台構成化その1(PostgreSQL を別インスタンスにする)

Redash はある程度スペックに余裕を持たせておけば、気を使わなくても1インスタンスで十分運用できるのが良いところではありますが、大量のデータを扱ったり、大量のクエリ実行を受け付けたりするような場合は、複数台での運用を考えたくなる時もあるでしょう。

この記事では、Redash の複数台構成について考えてみます。

前置き

この記事で紹介する方法は私個人の意見や考えに基づいて書いています。

業務上実績があったり、Redash が公式にこのような構成を推奨しているというものではないので、その点を踏まえてお読みください。

また、Redash を構成するミドルウェアなどについての説明は割愛します。

Redash の構成については、先日 Redash Meetup #2 で発表したスライドにも一部記載がありますので、必要に応じで参照してください。

speakerdeck.com

環境

この記事では Vagrant で構築した VM で動作検証しています。

  • Ubuntu 16.04
  • Redash 4.0.1
  • プライベート IP 192.168.33.10

また、この VM は新規に Redash をインストールしているため、既存環境からの移行については考慮していません(既存環境からの移行の場合に影響がありそうなところは適宜コメントをいれています)

PostgreSQL を別インスタンスにする

Redash を1台で運用する場合、クエリ結果を読み書きするため PostgreSQL の負荷が高くなりがちなので、PostgreSQL を別のインスタンスにすることで負荷分散が期待できるでしょう。

PostgreSQLインスタンスを Redash インスタンスから参照できるネットワーク内に配置し、Redash の設定を変えていきます。

PostgreSQL インスタンスの設定は割愛しますが、Redash インスタンスからアクセスできるようになっていることを前提とします。

  • プライベート IP 192.168.33.100
  • ユーザ名: redash
  • パスワード: redash
  • データベース名: redash

PostgreSQL のバージョンは デフォルトの Ubuntu 16.04 でインストールできる 9.5.13 としています。

設定を書き換える

/opt/redash/.env で定義されている REDASH_DATABASE_URL を、以下のように書き換えます。

export REDASH_DATABASE_URL="postgresql://redash:redash@192.168.33.100/redash"

テーブルを生成する

以下のコマンドで、 PostgreSQL インスタンス上にテーブルを作成します。

ubuntu@ubuntu-xenial:~/$ cd /opt/redash/current
ubuntu@ubuntu-xenial:/opt/redash/current$ ./bin/run ./manage.py database create_tables

これで Redash に必要なデータベースが準備できました。

Redash を再起動して、Redash にブラウザからアクセスすると、セットアップ画面が表示されるはずです。

セットアップが完了し、Redash にログインできるようになったら、Redash インスタンス上の PostgreSQL は停止しても問題ありません。

既存環境を使用する場合の注意点

既存の Redash の PostgreSQL を別インスタンスにする場合は、上記の手順で作業してしまうと、クエリなどをイチから作り直しになってしまいます。

この記事では紹介しませんが、既存環境を使用する場合はテーブル生成の代わりに、既存環境からのダンプ、PostgreSQL インスタンスでのリストアが必要になるため注意してください。

まとめ

Redash で使用する PostgreSQL を別インスタンスにする手順を紹介しました。

次回は Redis を別インスタンスにする手順を紹介します。