Redash のクエリ名を空にしてしまうと困る
Redash Advent Calendar 7日目の記事です。
困る
Redash のデモサイトで確認しました。
再現手順
クエリを一度保存し、その後クエリ名を空にします。
空にしてクエリ名を保存してしまうと。その後クエリ名が変えられません（正確にはクエリ名をクリックできないので、テキストボックスが表示できません）
これは困りますね。デモサイトは 6.0.0-beta+b8065 なのですが、業務で使用している 5.0.2+b5486 では再現しなかったことが少し気になります。
幸いにも Redash は OSS なので、自分で直すこともできるはずです。
明日の予告
ということで、明日の記事ではこれを直してみるというのをやってみます。
直せなかったら、しれっと別のことを書くかもしれません。
Redash をアップグレードした時にメモリ使用量はどのように変わるのか？
Redash Advent Calendar 6日目の記事です。
疑問
Redash は常に多くの機能や改善を取り込みながら成長していますが、一方で対応するデータソースなどが増えることによって、使用するメモリの量は増えるのではないか？
結論
- v4 -> v5 は大差なし
- v3 -> v4(v5) では
serverプロセスが使用するメモリが 100MB 増える
確認方法
docker-compose.production.yml の redash イメージのバージョンを以下の3つで切り替え、docker-compose -f docker-compose.production.yml up で起動直後の状態を ctop で確認。
実際にクエリを実行するような確認はしていないので、簡易計測です。
3.0.0.b3147
4.0.2.b4720
5.0.2.b5486
まとめ
アップグレード後のリソース監視を忘れずに！
Redash v5 で追加されたタグ機能をさらに便利に使いたい
Redash Advent Calendar 5日目の記事です。
タグ機能が便利
Redash v5 にアップグレードするモチベーションになる機能のひとつとしてタグ機能があります。便利ですよね。
これといって新鮮味のある機能ではありませんが、クエリの命名規則などで運用でカバーしていたものがスマートに解決される感じがして、とても良い機能だと思います。
クエリ命名規則といえば去年の Advent Calendar で記事も書きました。
タグ機能の惜しいところ
タグ機能は便利ですが、（私が知る限り）現状は画面からぽちぽちしないとタグが追加・削除できません。
すでに100個以上のクエリが運用されていたりすると、タグ付けだけで半日終わってしまいます。
かゆいところに手を伸ばす
ということで、CLI からクエリのタグを追加・削除できる PR を送ってみました。
マージされたらうれしい。
Redash のデモサイトでとりあえず雰囲気を掴むための SQL
Redash Advent Calendar 4日目の記事です。
先日公開した記事のおまけ的な情報として、SQL がわからなくてもさっと Redash を試すための SQL を紹介します。
手順
クエリ作成画面を表示する
http://demo.redash.io/queries/new にアクセスしてクエリ作成画面を表示します
データソースとして BigQuery を利用する
SQL を実行する
以下の SQL を実行してみましょう。
SELECT STRFTIME_UTC_USEC(DATE(time_ts), '%Y-%m') ym, COUNT(*) cnt, MIN(score) score_min, AVG(score) score_avg, MAX(score) score_max FROM [bigquery-public-data:hacker_news.stories] WHERE time_ts IS NOT NULL GROUP BY ym ORDER BY ym
補足: 先日の記事でも軽く触れましたが Redash のデモサイトでは BigQuery の Public Datasets を利用できます。
結果をみてみる
こんな感じに結果が表示されます。
あとは結果をダウンロードしてみたり、グラフによる可視化などを試してみるとよいでしょう。
今回の記事は以上です。
このぐらいの軽いネタでも大歓迎なので、よろしければ Redash Advent Calendar にも参加してみてください。
Happy Redash-ing!
2018年12月現在における Redash のはじめかた
この記事は Redash Advent Calendar 2018 1日目の記事です。
Redash Meetup を主催しているなかで、参加者アンケートを取っているのですが「これから Redash の導入を検討している」というかたが毎回2-3割程度いらっしゃるので、今日現在 Redash をはじめるにはどのようなステップを踏むとよいのか。というのを、主に環境構築の視点でまとめてみます。
まずは手軽なデモサイトに触れてみる
Redash には公式に提供されているデモサイトがあります。
利用できるデータは BigQuery の Public datasets などがあるので、データを準備する必要もなく試してみることができるので、気軽に Redash の機能を確認したり、手触りを確かめたりすることができます。
注意点としては、デモサイトとして公開されているため、自分が書いた SQL が他者にも見えてしまいますし、クエリの作成者の名前が Google 認証から取得されたものになるということがあります。これらについて了承できない場合は、ログインして他者のクエリを眺めてみるだけにしておくのが良いかもしれません。
Redash のハンズオン資料に触れてみる
デモサイトである程度雰囲気を掴んだら、Redash Meetup のハンズオンイベントでも活用した資料に沿って、Redash の機能を幅広く体験してみることをおすすめします。
環境構築をするために Git と Docker が必要になるため、エンジニアでないとつまづくことがあるかもしれませんが、Git も Docker も多くの方が導入手順のブログなどを書かれているので、それらの記事を参考に準備することは、それほど難しくないと思います。
デモサイトと違い自分だけの環境なので、クエリやグラフの追加はもちろん、ユーザーを追加などの管理機能も試すことができるので、導入前にユーザーや権限の管理はどうなっているのか、どのようなデータソースに対応しているのかなどを試すサンドボックス環境としても利用しやすくなっています。
Redash のリポジトリにある docker-compose.yml を使わずにこのハンズオン資料をおすすめする理由としては、利用方法を広範かつ平易に説明されているというのも大きいですが、サンプルデータとして MySQL の world データベースがすぐに利用できる状態になっているため、Redash を試すためにデータを準備するというステップを踏まなくてよいというのも、大きなメリットのひとつだと考えています。
また、利用されている Redash もバージョンアップされているため、本記事の対象者とは少し異なりますが、古いバージョンから移行したら何が変わるのか？というのを検証する環境としてもなかなか便利に利用できます。
導入について考える
デモやハンズオン資料に触れ、 Redash の導入になんらかのメリットがあると感じることがあれば、いかにして導入するかということを考えることになるでしょう。
セットアップの手順は公式ドキュメントに記載があるので割愛しますが、導入の要点について軽く紹介します。
Redash 導入の前に、データ基盤を整える
Redash を導入する時点で、何をデータソースにするかということにはある程度想定しているものがあると思いますが、Redash は誰でも簡単に利用することができるという利点の裏返しで、誰でも意図せず重いクエリを実行できてしまうことがある。ということも理解しておきましょう。
具体的には Redash を活用する場合、リードレプリカの作成や、BigQuery などのデータウェアハウスに対象のデータを入れておくなどの準備が多くの場合で必要になります。
もし、Redash 導入時点でそういった環境が用意できていないのであれば、立ち止まって Redash 導入の前にデータ基盤を整えることを強くおすすめします。
Docker 上で運用することを前提に準備
Redash は2018年12月1日現在、Docker で依存するミドルウェアや Python モジュールなどを導入・管理する方式が推奨されており、公式に提供されている AMI も Docker を使用したものになっています。そのため、Docker についての基本的な知識や docker、docker-compose コマンドの使いかたを知っておく必要があります。
Redash は細かい設定や運用をしなくとも安定して動作しますが、ワーカーが詰まった場合など再起動することも運用としてはありえるので、AMI などでお手軽に導入したものの docker-compose コマンドは使ったことがなく再起動のしかたがわからないというような状態は避けるようにしましょう。
メモリは最低 2GB。IO 性能は Redash 運用上重要
マシンのスペックについても少し触れておきます。
Redash は利用要件にもよりますが、メモリは 2GB ほど確保できれば安定して利用することができます。AWS EC2 で言えば t2.small が最低要件になると考えるとよいでしょう。もちろん 2GB より多く割り当てられるのであれば、それに越したことはありません。
ストレージについては少し気にする必要があります。Redash はクエリの実行結果をキャッシュとして PostgreSQL のテーブルに書き込みます。大量のデータを Redash で扱いたい場合はキャッシュ読み書きで IO が多く発生するため、SSD など IO 性能のよいストレージを利用することがおすすめです。
特に EC2 で利用する場合 EBS の gp2 ストレージを利用する機会が多いと思いますが、先のように大量のデータを扱いたい場合には、バーストクレジットを消費しきってしまう場合もあるため、サイジングには注意が必要です。
環境変数を知っておく
Redash は環境変数で様々な設定を変更することができます。
環境変数のリストは公式ドキュメントや 、以下の記事が参考になります。
運用当初から細かなチューニングをする必要はありませんが、REDASH_DISABLED_QUERY_RUNNERS で不要なクエリランナーを無効化することでメモリ消費を減らしたり、QUERY_RESULTS_CLEANUP_MAX_AGE を適切に設定し、肥大化したキャッシュをデフォルトより短いスパンで削除できることは覚えておくとよいでしょう。
クエリが詰まった時のチェックポイントを知っておく
Redash 運用について、よく聞く困りごとのひとつに「クエリの実行が詰まる」という問題があります。
原因については状況や構成によるので一概には言えませんが、手前味噌ながら以下のスライドの16ページを見ていただくと、詰まった時にどこを調査すると良いのかというのがイメージしやすくなると思います。
運用に困ったら
Redash の運用でもし困ることがあったら、Redash のフォーラムも利用してみてください。
まだまだトピックは少ないですが、日本語でやり取りできますし、運用知見のあるかたがコメントしてくださることも多いので、困った時に頼っていただけるとうれしいです。
まとめ
Redash はオープンソースであるため、IaaS ベンダーにも依存せず利用者それぞれにあった環境で利用することができます。
これから Redash の導入を検討したい、名前は聞いたことがあるが、触ったことがないというかたにとって、この記事がちょっとしたきっかけになってくれたら嬉しいです。
Redash Advent Calendar 2018 2日目は Redash のメンテナーとしても一部ユーザーにおなじみの kyoshida さんによる記事です。お楽しみに！
