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

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

Blazerで異常値検知を試してみる

先日の記事の続きです。

ariarijp.hatenablog.com

Blazerで異常値検知も試してみました。

検証に使用したVagrantfileは以下のものです。

github.com

vagrant up してBlazerを起動し、ブラウザでアクセスできる状態を前提にします。

サンプルを見てみる

Vagrantfileで使用している ankane/blazer-dev では、開発用のリポジトリであるためか、デフォルトで異常値検知が有効になっています。

...省略...
anomaly_checks: true
...省略...

http://localhost:3000/queries/12-check-for-anomalies にアクセスすると、以下のような画面が表示されます。

f:id:ariarijp:20180113143909p:plain

FAILING · Anomaly detected in new_ratings というメッセージが表示されており、 new_ratings の値の推移にAnomalyな値が検出されたことがわかります。

このクエリで実行されているSQLを見てみます。

http://localhost:3000/queries/12-check-for-anomalies/edit にアクセスすると、SQLの編集画面が表示され、以下のようなSQLが実行されていることがわかります。

SELECT date_trunc('week', rated_at)::date AS week, COUNT(*) AS new_ratings FROM ratings GROUP BY week ORDER BY week

SQLをいじってみる

先程は異常検知されていたので、このクエリを少し変えて、異常値が検出されないようにしてみます。

SELECT date_trunc('week', rated_at)::date AS week, COUNT(*) AS new_ratings FROM ratings GROUP BY week HAVING COUNT(*) < 5000 ORDER BY week

HAVING 句で5000件以上の行をフィルタしています。このSQLを保存し、再度クエリを実行してみると、以下のような画面が表示されます。

f:id:ariarijp:20180113144419p:plain

PASSING · No anomalies detected というメッセージが表示されており、異常値が検出されていないことがわかります。

さらにSQLを変更し、再度異常検知されるようにしてみます。

SELECT
    date_trunc('week', rated_at)::date AS week,
    CASE
        WHEN
            date_trunc('week', rated_at)::date = to_date('1998-03-09', 'YYYY-MM-DD') THEN CAST (0 AS BIGINT)
        WHEN
            date_trunc('week', rated_at)::date = to_date('1998-03-16', 'YYYY-MM-DD') THEN CAST(0 AS BIGINT)
        WHEN
            date_trunc('week', rated_at)::date = to_date('1998-03-23', 'YYYY-MM-DD') THEN CAST(0 AS BIGINT)
        ELSE COUNT(*)
    END AS new_ratings
FROM
    ratings
GROUP BY
    week HAVING COUNT(*) < 5000
ORDER BY
    week

少し長くなりましたが、もとのSQLが週単位でデータを取っているので、1998-03-09-1998-03-23週のデータを無理やり0にしてみました。 このSQLを保存し、再度クエリを実行してみると、また異常値が検知されます。

f:id:ariarijp:20180113150512p:plain

ちなみに、1週分のデータだけ0にしても異常値としては認識されませんでした。このあたりのチューニングはできるのかもしれませんが、今回はそこまで調べていません。

まとめ

データ分析などを専門にしていないエンジニアでも、Blazer(というよりRのtwitter/AnomalyDetectionパッケージ)によって異常検知が簡単に利用できました。

他のOSSのBIツールではあまり見かけた記憶がないので、異常値検知はBlazerの特徴ひとつになるかもしれません。

Rもちょっとしたパッケージを使えるぐらいには勉強しようかな。

Rではじめるデータサイエンス

Rではじめるデータサイエンス

表参道.rb #30でBlazerについて調べて発表してきた

得意の当日LT応募で参加してきました。

omotesandorb.connpass.com

発表スライドはこちら。

speakerdeck.com

通勤中にconnpassを見ていて、LTテーマがフリーだったのでRedashっぽいRubyで書かれたBIなんかがあれば話せそう。と思った矢先、Blazerを見つけたのはラッキーでした。 Star数もかなり多いわりに日本語の記事もなかったので、LTネタとしてかなり助かりました。

github.com

Redashっぽいところもありつつ、RailsアプリなのでRailsらしさのようなものも感じられて、BI/可視化ツール好きにとってはなかなかおもしろかったです。

資料には含まれていませんが、Rをインストールして何かをゴニョゴニョすると異常値検知もできるらしいので、それについてはまた調べてみるつもりです。

表参道.rbでの発表は3回目で、過去に#1#14で発表していたので、次回は#45あたりにLT参加したいと思っています。

Rubyistに囲まれたせいか、少しRuby書きたくなったので、さくらんぼ本を買うか悩む。

Redashの開発環境をあえてVagrantで構築する

はじめに

Redash は公式ドキュメントでは、開発環境には Docker を使うことを推奨されています。

Guide · Redash Help Center

以前は Redash のリポジトリVagrantfile も含まれていましたが、今ではDocker移行を推奨するためか削除されています。

Docker を使うようになったことで、環境構築がかなり気軽にできるようになりました。 Redash Meetup ハンズオンで使用している以下の資料も、Docker を使った環境構築手順になっています。

github.com

しかし、Redash のコードを追っていったり、ミドルウェア周りの調査で DB や稼働プロセスを覗き見したりするときは、VagrantVM を1台起動して、その中にRedash も PostgreSQL も Redis も入っている方が便利なことがあります。

この記事では、あえて今 Vagrant で Redash の環境構築をする方法を紹介します。

環境構築

前置きが長くなりましたが、とても簡単です。

前提条件

以下の環境で動作確認しました。

手順

Redash のバージョン v3.0.0 の環境を構築します。

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

Vagrant が使える状態になっていれば、手順は上記のコマンドだけです。

VM が起動するまで10-15分ほど時間がかかりますが、ほとんど cassandra-driver のビルド待ちです。気長に待ちましょう。

動作確認

ブラウザで http://localhost:8080/setup にアクセスすると、Redash ユーザーには見慣れた画面が表示されます。

f:id:ariarijp:20180104212003p:plain

Vagrant で環境構築をするメリットである、「全部入り」になっていることを確認するため、 VM 上で ps コマンドを実行してみます。

$ vagrant ssh -- ps axuf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...省略...
postgres 14048  0.0  1.1 293424 24424 ?        S    12:10   0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf
postgres 14050  0.0  0.3 293556  6316 ?        Ss   12:10   0:00  \_ postgres: checkpointer process   
postgres 14051  0.0  0.2 293424  5624 ?        Ss   12:10   0:00  \_ postgres: writer process   
postgres 14052  0.0  0.4 293424  8800 ?        Ss   12:10   0:00  \_ postgres: wal writer process   
postgres 14053  0.0  0.3 293852  6628 ?        Ss   12:10   0:00  \_ postgres: autovacuum launcher process   
postgres 14054  0.0  0.1 148568  3188 ?        Ss   12:10   0:00  \_ postgres: stats collector process   
postgres 17700  0.0  0.7 300764 16148 ?        Ss   12:18   0:00  \_ postgres: redash redash [local] idle
postgres 17701  0.0  0.7 300716 15868 ?        Ss   12:18   0:00  \_ postgres: redash redash [local] idle
postgres 17702  0.0  0.7 300716 15004 ?        Ss   12:18   0:00  \_ postgres: redash redash [local] idle
postgres 17704  0.0  0.7 301292 16376 ?        Ss   12:19   0:00  \_ postgres: redash redash [local] idle
postgres 17705  0.0  0.7 300716 15068 ?        Ss   12:19   0:00  \_ postgres: redash redash [local] idle
redis    14267  0.1  0.5  37228 10420 ?        Ssl  12:10   0:00 /usr/bin/redis-server 127.0.0.1:6379
root     17621  0.0  0.9  57376 19880 ?        Ss   12:18   0:00 /usr/bin/python /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
redash   17658  0.6  4.7 293576 96684 ?        S    12:18   0:01  \_ [celeryd: celery@ubuntu-xenial:MainProcess] -active- (worker --app=redash.worker --beat -c2 -Qqueries,celery --maxtasksperchild=10 -Ofair)
redash   17695  0.1  4.7 303888 97108 ?        S    12:18   0:00  |   \_ [celeryd: celery@ubuntu-xenial:Worker-2]
redash   17697  0.1  4.7 303892 96996 ?        S    12:18   0:00  |   \_ [celeryd: celery@ubuntu-xenial:Worker-3]
redash   17698  0.0  4.3 301300 90004 ?        S    12:18   0:00  |   \_ [celery beat]
redash   17659  0.0  0.9  55952 18516 ?        S    12:18   0:00  \_ gunicorn: master [redash]
redash   17682  0.4  4.9 293476 101916 ?       S    12:18   0:01  |   \_ gunicorn: worker [redash]
redash   17684  0.4  4.9 293080 101352 ?       S    12:18   0:01  |   \_ gunicorn: worker [redash]
redash   17688  0.4  4.9 293892 102296 ?       S    12:18   0:01  |   \_ gunicorn: worker [redash]
redash   17691  0.4  4.9 294152 102324 ?       S    12:18   0:01  |   \_ gunicorn: worker [redash]
redash   17660  0.6  4.7 293296 96688 ?        S    12:18   0:01  \_ [celeryd: celery@ubuntu-xenial:MainProcess] -active- (worker --app=redash.worker -c2 -Qscheduled_queries --maxtasksperchild=10 -Ofair)
redash   17694  0.0  4.6 302564 94268 ?        S    12:18   0:00      \_ [celeryd: celery@ubuntu-xenial:Worker-1]
redash   17696  0.0  4.6 302564 94476 ?        S    12:18   0:00      \_ [celeryd: celery@ubuntu-xenial:Worker-2]
root     17647  0.0  0.0 124972  1436 ?        Ss   12:18   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 17648  0.0  0.1 125348  3148 ?        S    12:18   0:00  \_ nginx: worker process
www-data 17649  0.0  0.2 125420  4844 ?        S    12:18   0:00  \_ nginx: worker process
...省略...

Redash の主要なプロセスが稼働していることがわかりました。

Redash のソースコード一式は /opt/redash 以下にあります。

$ vagrant ssh -- ls -la /opt/redash
total 16
drwxr-xr-x 3 redash root    4096 Jan  4 12:34 .
drwxr-xr-x 3 root   root    4096 Jan  4 12:34 ..
lrwxrwxrwx 1 root   root      30 Jan  4 12:34 current -> /opt/redash/redash.3.0.0.b3134
-rw-r--r-- 1 redash nogroup  191 Jan  4 12:34 .env
drwxr-xr-x 9 redash nogroup 4096 Jan  4 12:34 redash.3.0.0.b3134

あとは vagrant ssh してコードを変えてみたり、ミドルウェアの設定を変えてみたりといろいろ試せます。

まとめ

Vagrant でも、それなりに簡単に Redash の環境を構築することができるようになりました。

Docker に少し苦手意識があるけど Redash を試してみたい方にも、この記事が参考になるかもしれません。

実践 Vagrant

実践 Vagrant