Redash Meetup #1 を振り返る

すっかりRedashブログになってきたこのブログですが、今回もRedashについての話です。

TL;DR

楽しかった!

Redash Meetup #1 を主催した

1年以上前からやりたいと思っていたRedashの情報共有イベントをついに開催することができました。

redash-meetup.connpass.com

登壇していただいたみなさま、参加していただいたみなさま、改めてありがとうございました!

開催までのはなし

構想

過去2回のハンズオンイベント、Advent Calendarの参加数などを踏まえ、Redashをテーマにしたイベントでも多くの方に参加していただけるのではないか?と思い、今年の1月ごろから具体的に計画していました。

登壇者探し

今回は発表主体のイベントなので、発表ありき、登壇者ありきです。

当然、私は発表するとして、最低でももうひとり発表していただけるかたを探したいと思っていたところ、 @kyoshida さんが快諾してくださいました。これは嬉しかった!

日程の検討

運営者の id:kakku22 と私、 @kyoshida さんの予定を勘案しつつ、結局は2/20(火) に決めました。なぜかRedash Meetupは火曜開催が多いです。

イベントの長さについても少し考えたのですが、ハンズオンイベントを過去懇親会無しで実施しており、「終わったら片付けをしてサクッと帰る」というスタイルを残したかったので、かなりコンパクトに纏めました。

この時点では未定だったLT枠を含めても19:30開始、20:45終了というのは、界隈のイベントの中ではトップクラスのあっさり仕様だと自負しています。

イベントの告知とLTの募集

開催を決定したのでイベントを告知する段階になったのですが、少し悩んだのは参加者数です。過去回と同様、私が所属している会社の関連会社である 株式会社ココラブル を会場とすることは決めていたのですが、どれぐらい参加してもらえるか、何人ぐらいならそれなりに快適に発表を聞いていただけるか、当日キャンセルをどれぐらい考慮すべきかなど、ハンズオンとはまた違った悩みがありました。

結局最初は24人+LT枠2人の、計26人で募集開始し、前日に当日キャンセルを想定して参加者枠を6枠増やし、最終的に32人の募集をしたことになります。

正直にいって、LTの募集は勇気がいりました。

1人も枠が埋まらなかったら5分ネタを2本私が用意するか、 id:kakku22 にお願いしようかとも思っていたところ、 @dyuju_you さん、 @manabusakai さんがLT枠での参加を表明してくださいました。

これもかなり嬉しかったですし、「なんかイベントっぽくなってきた!」と、早くも実感と、なんとなくの成功イメージが湧いてきました。

当日の準備などについて

会場設営は過去2回行っているため、多少手慣れたものではありますが、今回も過去回に引き続き、設営は同僚に手伝ってもらいました。

この場を借りて改めてお礼をしますが、いつもサポートありがとうございます!

また、受付は id:kakku22 が一手に引き受けてくれました。

後で話を聞いたところ、参加者の受付だけでなく弊社への来客の対応までしてくれたようです。

余談ですが、当日の発表では結局使わなかったものの、「マイクがあったほうが良いんじゃないか?」とイベント当日に思い立ち、夕方にビックカメラまで走ってマイクを買いに行ったのですが、前述の通り結局使わず。自席のキャビネットの下にそっとしまってあります。

ちょっと良いの買ってしまったので、何かの機会に使いたいものです。

発表について

会場説明を前にはさみつつ、「Redash 導入事例から考える OSS BI ツール導入チェックリスト」というタイトルで発表しました。

発表で使用したスライドは以下になります。

speakerdeck.com

弊社での導入事例を踏まえ、Redashのみならず、これからBIツールを導入しようと考えている方に、どんなポイントを押さえて検討・検証・運用したらよいか、個人的な経験と視点ではありますが、お話させていただきました。

発表は20分枠でしたが、最後のスライドを表示した時点でだいたい1分押しぐらいになっていたと思います。

コンパクトな会だけに、特に私の担当枠は時間ぴったりに収めたかったので、少し申し訳無さもありつつ、なんとか伝えたい事はすべて話せたかな。と思える発表でした。

実は発表についても当日の昼に同僚にリハーサルに付き合ってもらい、声を出しながら話す内容を調整することができました。リハーサルがなかったらおそらく5分以上押していたと思います。

また、発表内容には関係ありませんが「発表前・発表後に拍手をしましょう」というのを絶対に言うぞと心に決めてイベントを開始し、それが緊張で飛ぶことなく言えたのは、個人的によかったことの一つです。

せっかく貴重な時間を割いて登壇していただくので、少しでも気持ちよく話せる状況にしたいなと思ってのお願いだったのですが、それにみなさんが快く応じてくれたことが、もしかするとイベント中で一番うれしかった瞬間かもしれません。

まとめ

発表主体のイベント主催の初体験はいろいろ難しいこともあり、特に当日の夕方ぐらいからずっと緊張していたのですが、終わってみると「やってよかった」と心から思える良いイベントにすることができました。

次回以降のイベントは全く予定がないのですが、 4.0.0がリリースされるころには、もう一度ぐらいやってみたいかなと、早くも思い始めています。

(イベント開催直前までは「もう今回が最後でいい!」と思うぐらいに軽く追い込まれていました)

めずらしくサンプルコードも含まないのに長い投稿になってしまいましたが、Redash Meetup #1 を振り返ってみました。

参加していただいたみなさま、イベント後に資料を読んでいただいたみなさま、ブログでもSNSでのシェアでもなんでも構いませんので、 #redashmeetup タグなどで感想を教えていただけるとうれしいです。

Redash を PyCharm Community Edition でデバッグする

OS X での自分用作業メモ。

ターミナルでの作業

virtualenv で Redash 用の環境を作って、必要な Python モジュールを一通りインストールする。

$ pip2.7 install -U virtualenv
$ brew install python --with-berkeley-db4
$ brew unlink python && brew link python
$ brew install mysql
$ brew install freetds@0.91
$ brew link --force freetds@0.91
$ git clone git@github.com:getredash/redash.git
$ cd redash
$ virtualenv .venv
$ source .venv/bin/activate
$ pip install -r requirements.txt
$ pip install -r requirements_dev.txt
$ pip install -r requirements_all_ds.txt

メモ

  • pymssql のインストールが freetds@0.91 に依存している
  • celery を起動する時にエラーが出るのを brew install python --with-berkeley-db4 で解決する

参考

PostgreSQL と Redis の環境構築

docker-compose.development.yml として以下のファイルを作成。

docker-compose.production.yml から serverworkernginx を除いたものに近い。

version: '2'
services:
  redis:
    image: redis:3.0-alpine
    ports:
      - "6379:6379"
    restart: always
  postgres:
    image: postgres:9.5.6-alpine
    ports:
      - "5432:5432"
    volumes:
      - postgres:/var/lib/postgresql/data
    restart: always
volumes:
  postgres:
    driver: local

その後、以下のコマンドでコンテナを起動。

$ docker-compose -f docker-compose.developmens.yml up

Redash の設定

.env を以下のように作成する。PostgreSQL 、 Redash ともに Docker のコンテナを使うようにする。

export REDASH_LOG_LEVEL=INFO
export REDASH_REDIS_URL=redis://localhost:6379/0
export REDASH_DATABASE_URL=postgresql://postgres@localhost/postgres

次に、必要なテーブルを作成する。

$ ./bin/run ./manage.py database create_tables

次に、JavaScriptをビルドする。

$ npm install
$ npm run build

PyCharm での作業

Python Interpreter

virtualenv で作った環境の python を使うように設定する。

f:id:ariarijp:20180218212206p:plain

server の実行時設定

f:id:ariarijp:20180218212301p:plain

worker の実行時設定

f:id:ariarijp:20180218212310p:plain

serverworker環境変数

.env で設定している値を環境変数として設定しておく。

f:id:ariarijp:20180218212316p:plain

動作確認

server , workerDebug で実行すればブレークポイントを設定できる。

f:id:ariarijp:20180218213413p:plain

便利。

この記事では PyCharm Community Edition を使ったけれど、 Professional Edition であれば Docker 上の Pythonデバッグできるようなので、 Redash の場合はその方がよさそう。

PyCharm を雰囲気で使っているので、もっと便利な使い方を知りたい。

RedashのQuery Resultsデータソースでクエリパラメータを使用したクエリを使用する

なんとなく動いたので作業メモついでの記事。

やりたかったこと

Redash 3.0.0の大きな変更点の一つであるQuery Resultsデータソースは現時点でクエリパラメータを使用したクエリを実行できない。

ariarijp.hatenablog.com

しかし、業務で使っているRedashでは、ほとんどのクエリがクエリパラメータを必要とするため、クエリパラメータを指定してQuery Resultsデータソースを使用できるか検証してみたいと思った。

VagrantでRedashを起動

個人的に開発用途ではDockerよりVagrantのほうが何かと楽なので、Vagrantを使用する。

github.com

$ mkdir redash
$ cd redash
$ wget https://raw.githubusercontent.com/ariarijp/vagrantfiles/master/redash/Vagrantfile
$ vagrant up

VMが起動したら、 http://localhost:8080 でRedashにアクセスできる。

Query Results Exデータソースを導入

現状のQuery Results データソースはクエリパラメータに対応していないため、Query Resultsをもとにクエリパラメータ対応を入れたQuery Results Exというクエリランナーを作成した。

github.com

かなり雑なコードや、整理したら不要になるコードが含まれているので、気が向いたら書き換えるかもしれない。

これを先の手順で作成したRedash環境に導入する。

$ vagrant ssh
$ # 以下はVM内で実行
$ sudo wget -O /opt/redash/current/redash/query_runner/query_results_ex.py https://raw.githubusercontent.com/ariarijp/redash-query-runners/master/query-results-ex/query_results_ex.py
$ echo 'export REDASH_ADDITIONAL_QUERY_RUNNERS="redash.query_runner.query_results_ex"' | sudo tee -a /opt/redash/.env
$ sudo service supervisor restart

なお、このデータソースはあくまで技術的に可能かどうかの検証で作成したものなので、本番環境では使用しないことを強くおすすめする。

動作確認

adminアカウントの初期設定などは割愛。

テストデータの準備

検証でデータソースとして使用するデータソースとクエリを以下のように作成する。

データソース

パスに :memory: を指定すると、SQLiteをインメモリで実行できる。これはQuery Resultsデータソースのソースを読んで知った。

In-Memory Databases

クエリ

検証の準備を省略するため、テーブルを使用せず以下のようなクエリで動作確認する。

SELECT * FROM (
  SELECT 1 a, 'foo' b, 0.1 c
  UNION SELECT 2 a, 'bar' b, 0.2 c
  UNION SELECT 3 a, 'baz' b, 0.3 c
)
WHERE a = {{a}} AND b LIKE '%{{b}}%';

Query Results Exデータソースでクエリを実行する

データソース

  • Type: Query Results Ex (Unofficial)
  • Name: Query Results Ex

クエリ

テストデータとして作成したクエリのIDが1である場合、以下のようなクエリを実行する

SELECT * FROM query_1(a=2,b=ba);

f:id:ariarijp:20180212171558p:plain

query_[クエリID](パラメータ名1=値1,パラメータ名2=値2) のように、パラメータはカッコ内にカンマ区切りで列挙できる。

値にカンマを含むものが使用できない、文字列をシングルクォーテーションなどでくくって表記できないなどの問題はあるが、検証なのであまり気にしないでおく。

まとめ

クエリパラメータを使用したクエリでもQuery Resultsデータソースで実行できる可能性があることがわかった。

今後のアップグレードで対応されるかもしれないので、4.0.0のリリースを気にしておきたい。

Redashを2.0.0から3.0.0にアップグレードした

つい先程、社内で使っているRedashを 2.0.0.b2990 から 3.0.0.b3134 へアップグレードした。

実作業時間は15分ぐらい。作業前リハーサルは1時間ぐらいでできた気がする。

手順は公式ドキュメントのとおり。

How to Upgrade Redash · Redash Help Center

$ cd /opt/redash/current
$ sudo bin/upgrade

リハーサルはVagrantで環境を作って実施。

バックアップはディスクイメージをスナップショット取って対応。

オンプレであればPostgreSQLのダンプを取る感じになるのかなと思う。

sudo bin/upgrade を実行すると、ドキュメントにも記載がある以下のエラーが起きた。

AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

これはリハーサルでも発生したものだったので、ドキュメントに従って pyOpenSSLをアップグレードして解決。

$ sudo pip install pyOpenSSL -U

pyOpenSSLをアップグレードしたら、再度 sudo bin/upgrade を実行するとアップグレードは完了。

アップグレードすると /opt/redash/redash.[新しいバージョン] ができて、 /opt/redash/current が最新バージョンのディレクトリにシンボリックリンクになるのだけれど、 settings.py をいじっている場合は旧バージョンのディレクトリ内のファイルを見ていい感じに移行する必要がある。

うちの場合は主にメモリ使用量節約のため settings.py をいじっているため対応が必要だった。

ariarijp.hatenablog.com

3.0.0 にしたモチベーションはQuery Resultsなんだけど、パラメータつきクエリを多用しているので適用が難しい。

適当にパラメータが渡せるように改造してみようかと思いつつ、Google Spreadsheetデータソースとの合わせ技でなんかできないかなとも考えているところ。

このあたりはブログネタとしてちょうどいいんだけど、Googleのサービスアカウントがどうとか説明するのが億劫になって、なかなか書く気になれない。

ariarijp.hatenablog.com

そんなことを考えるまえに、そろそろRedash Meetup #1の資料を書かないと、あっという間に2/20になってしまいそうだ。

redash-meetup.connpass.com

Redash Meetup #0.1 ハンズオン振り返り

前回のProblemを中心に簡単に振り返り。

ariarijp.hatenablog.com

前回のProblemと、それに対するアクション

  • ハンズオンの成功を第一の目標にしたため、募集人数を少なめに設定した
    • -> ちょっと増やしたものの、当日不参加も目立った
  • 募集から開催までの時間が約2週間と短めだった
    • -> 約1ヶ月前に告知できた
  • 募集を先着順にしたため、あとからイベントを知った人が参加できなかった
    • -> 増枠したので先着順のままにした
  • Advent Calendarなどで告知をしたが、すでにキャンセル待ちになっていた
    • -> ほぼ公開後に2日で埋まったので、状況それほど変わらず。当日不参加が痛い
  • ハンズオン環境構築で想定外のトラブルがいくつかあった
  • -> ハンズオンの進行方法にばらつきがあった
    • -> 今回はサポートありのもくもく会スタイルに統一した
    • -> 時間が余り気味になってしまったため、その場で小ネタを用意して発表したりもした

その他

  • Metabaseも話題になっていて、少しRedashのムーブメントが落ち着いてきた?
  • 参加者のみなさまに会場の撤収を手伝っていただけてありがたかった
  • キャンセル理由でインフルエンザの流行をより身近に感じた
  • 懇親会無しでサクッと終わるスタイルは良い。寿司ネタが消失する問題なども気にしなくて良い
  • 当日不参加はつらい、せめてキャンセルしてほしかった

まとめ

ハンズオンイベントは一区切りでいいかなと id:kakku22 と話したりしていますが、ハンズオン資料のバージョンアップや、なんらかのきっかけでまた実施するかもしれません。

ハンズオンイベントがなくても、資料に沿って進められるようになっていますので、これからRedashを使ってみようと考えているかたは是非お試しください!

github.com

次回は2/20に kyoshidajp さんと私がRedashの導入・活用事例などについてお話しする、Redash Meetup #1を開催します。

redash-meetup.connpass.com

すでにキャンセル待ちとなっていますが、ご興味があれば参加登録をお願いします。