mozilla/redash_client を使って Redash のクエリを実行する
業務では redash-dynamic-query を使う機会が多いが、Mozilla が公開している mozilla/redash_client
も試してみることにした。
少し調べたところ、Mozilla で使われている STMO という仕組みが Redash で構築されていて、その STMO のクライアントとして開発されているっぽい。
STMO は誰でもアクセスできるものというわけではなさそうだけど、 Mozilla は内部で使っているコードもすべてオープンにするようなポリシーで運営されているのかもしれない。
使ってみる
README ではクエリを検索するサンプルが紹介されているので、それを少し改変して redash-dynamic-query
でよくやるパラメータを使ったクエリの実行をやってみる。
先に断っておくと、このコードは以下の PR に含まれる変更に依存しているので、私の手元でしか動かないことはご了承いただきたい。
from pprint import pprint import pystache from redash_client.client import RedashClient api_key = os.environ["REDASH_API_KEY"] client = RedashClient(api_key) client.BASE_URL = 'https://localhost:5000/' client.API_BASE_URL = client.BASE_URL + 'api/' query = client.get_query(1) sql = pystache.render(query['query'], { 'since': '2018-04-01', 'until': '2018-04-30', }) result = client.get_query_results(sql, query['data_source_id']) pprint(result, width=160)
上記のようなコードで、 redash-dynamic-query
と同じように、クエリにパラメータをバインドして実行することができる。
モジュール内で BASE_URL
が STMO の URL でべた書きされていたりするので、内部向けコードっぽさを強く感じるが、 Mozilla の外でも使えないことはなさそう。
redash-dynamic-query との違い
パラメータつきクエリの実行に特化している実装になっている redash-dynamic-query
に対し、 mozilla/redash_client
はすべてのAPIを網羅しているわけではないが、所謂 API クライアントとして作られている。
すべてを試したわけではないが、現時点の master
ブランチでは以下のような機能を持っている。
これらの機能を使って、Mozilla では Redash as a Code みたいな感じのことをやっているのかもしれない。
ただし、先程紹介した PR のように、ID を指定したクエリの取得など、よく使いそうな機能がまだ実装されていなかったりするので、 PR を送ったりするなどして開発に参加したり、Fork して必要な機能を足すようなことが必要になるかもしれない。
また、 .travis.yml
を見る限りでは Python 2.7 での使用を想定されているためか、 Python 3 では上記で紹介したコードを動作させることはできるものの、ユニットテストは失敗する。 個人的には Python 2 を使う機会が減っているため、このあたりは少し気になる。
Redash Meetup #0.2 - SQL 未経験者向けハンズオンを開催した
主催しているRedash Meetupの企画として SQL 未経験者向けハンズオンを開催しました。
ブログ書くのがずいぶん遅くなってしまったけど、まぁいろいろあった。
進行について
SQL 未経験者向けということで、一度でも SQL を書いたことがある人にとっては物足りなくなるレベルで内容を絞ることにした。
具体的にはイベントページの説明にも記載しているが、 WHERE
での条件指定を中心に、後半少しだけ GROUP BY
に触れるよう内容でハンズオンを構成した。
構成について気を使ったこと
コピペでほとんどの SQL を実行できるようににした
ハンズオンの大半は「ほぼコピペ」で進められるような構成にして、「何をやっても動かなくて詰まる」という状況を防ぐというのを意識した。
コピペで進めることにした理由としては、事前に社内のインターン向けにリハーサルをした際、「タイピング速度に依存して個々の進行度合いの差が大きく開く」というのが見受けられた。ということが大きい。
今回のハンズオンは「じっくり基礎を学ぶ」という特性のものではなく、「SQL を実行してみて、データベースからデータを取り出す感覚を掴んでもらう」ということを重視したため、このような形をとったが、イベントを終えてみると、参加者の方にとっては少し物足りないところもあったように思える。
このあたりは、ハンズオンイベントの難しさだなと思う。
コピペで実行する SQL の中にエラーを仕込んだ
サポート講師としてイベントをフォローというかドライブしてくれた id:kakku22 が表参道.rbで過去に発表した以下のスライドを思い出して、「SQL の中に潜むエラーを見つける」というのを、コピペ資料の中にこっそりと埋め込んだ。
これが好評だったか?というと、よくわからないというのが正直なところではあるけど、「SQL を書いていれば必ずエラーと向き合うことになる」ということを伝えることはできたと思う。
エラーを見てすぐに拒否反応するのではなく「エラーが出たってことは、どこか間違ってるんだろうな」と思ってもらえるようになっていたらうれしい。
後半は応用編として、前半のハンズオンとは全く違ったデータベースを使った演習を入れた
前半の内容は前述の通り「ほぼコピペ」で進める内容となっていて、具体的には MySQL のサンプルデータとして有名な world
データベースを使用していた。
一方、後半の内容は sakila
データベース(ビデオレンタル店を模したデータ)を使用し、以下のような課題に取り組む形をとった。
- (Redashで)テーブルの一覧、カラムの一覧を見てみる
- 顧客数をカウントする
- 店舗別の顧客数をカウントする
- 再生時間が長い映画トップ20を取得する
- タイトルに GOLD を含む映画を取得する
- (チャレンジ演習) 最も出演回数の多い俳優または女優の名前は?
前半にコピペをしながら取り組んだ SQL を参考にすれば、正解にたどり着けるような課題にしつつ、未知のデータベースにどんなテーブルやカラムがあるか、何件のデータが保持されているかなど、少し実務でも活用できそうなお題を選んだつもり。
改善点
SQL を「書く」体験をもう少し多くしてもよかった
前述の「コピペ進行」の話のとおりなので割愛
資料を公開できるように準備したかった
イベント企画時点では、イベント後に資料を公開することを計画していたが、イベント内で口頭補足する前提の資料にしてしまったことや、Redash のハンズオン環境環境がないと実感に欠ける資料になってしまったため、公開は見送ることにした。
次回開催をする場合は、この点を解決したい。
まとめ
- ハンズオンは準備と内容のレベル調整が大変
- みなさんの反応を見ながら進行できるのは面白い
- 次回開催は未定。定員を大きく超える応募をいただいたので、また開催してみたいとは思っている
次回開催、どうしようかなぁ。と思いを巡らせてみてはいるものの、まずは直近のイベントの準備・開催を終えてから考えることにしよう。
Redash Meetup についての宣伝
Redash Meetup #2 では コネヒト株式会社 の shnagai さんに登壇をお願いしました。Redash に興味があるかたは、こちらのイベントへのご参加もご検討ください。
PHPerKaigi 2018に参加したついでにアンカンファレンスで話してきた
PHPerKaigi 2018に行ってきました
今日はPHPerKaigi 2018に参加してきました。
アンカンファレンスで喋ってきました
Track Bの部屋に行ったところ、アンカンファレンスの枠がごっそり空いていたので、スッと参加表明してみました。
PHPでRedash作ったRedashぽいものの話です。華のない話になります #phperkaigi pic.twitter.com/OMgdc0fhZ6
— Takuya Arita (@ariarijp) 2018年3月10日
字が汚いですね。緊張して震えていたのかもしれません。
今見てみるとTweetも思いっきり間違えてます。きっと緊張していたのでしょう。
ちなみに、参加表明してからネタを仕込むために1時間半ほどもくもくスペースで作業してたのですが、その間に開催されていたトークがベストトーク賞だったようです。おめでとうございます。
発表したこと
Meetupを主催するぐらい気に入っているRedashっぽいものをLaravelで書いてみたので、これを元に話しました。名前はPhpedashです。
そんな私が不定期に主催しているRedash Meetupはこちらです。
発表のあと、ソース公開しないんですか的なお声がけをいただいたのですが( 参加票のアイコンを見た感じ id:uzulla さんだったかな?)、公開予定はありません。
というか、これがそのまま本番で運用されたらいろいろやばい雑な実装が多すぎて公開できませんでした。
盛り込んだネタ
作ってみましただけだとフックに欠けるので、以下のような話を盛り込みました。
上記のライブラリを組み込んだ機能は、直前で手をいれたときに作業漏れしていてデモが動かなかったという悲しいこともありましたが、発表後に直しました。
PDO便利
Phpedashではデータソースを保持するテーブルにDSNを保持する素朴な実装にしました。DSNにすれば相手がSQLiteだろうとPostgreSQLだろうと接続できて便利ですね。
league/csv 便利
CSV操作するときに便利なライブラリです。
これは業務でも使っているお気に入りライブラリのひとつでした。
phpoffice/phpspreadsheet 便利
みんなが大好きなExcelをあれこれするライブラリです。
「何気ないExcelが、PHPerを傷つけた」
元ネタわかりませんが、用法としてあっているでしょうか。
でも、PHPでExcelとかやめよう
PHPでExcelやめとけと書いてるのに一番人気の記事はこちらでした。アンカンファレンス聞いていただいたみなさまありがとうございました! #phperkaigi https://t.co/pqRofQp1pf
— Takuya Arita (@ariarijp) 2018年3月10日
PHPでExcel操作するのやめようって書いてある記事が、他のRedashの記事を押しのけて本ブログの一番人気ですという話をしました。皮肉なものです。
会場で PHPExcel / PHPSpreadsheet 使っている・知っている人に挙手をおねがいしたら結構手が上がったような気がしています。皆さん苦労してますね。
発表を終えて
正直、特に持ち帰るような知識もない発表になってしまったかなと思ってはいます。
もっと前日までに準備しておけばよかった。とは思いますが、発表しないでのこのこ家に帰ってくるよりはよかったかなと思っています。
また、小さいことですがアンカンファレンス一発目を取れたので、そこはちょっと満足しています。
最後に
PHPerKaigi 2018に関わったみなさま、おつかれさまでした!
久しぶりに休日開催のイベントに参加しましたが、楽しかったです。
Redashのユーザー削除について考える
前提知識
現状のRedashにおけるユーザー削除のTL;DR
- FK使ってるのでユーザーだけ削除するのはRedashでは難しい
- ユーザーを無効にするPRとかも出てるけど動きが止まってて今は使えない
考えたこと
前置き
Redashでユーザーを削除したい理由を「該当ユーザーをRedashにアクセスできなくしたい」に絞って考える。
気持ち悪いからきれいにしたい、クエリ作成者などに退職者の名前が出ているのを変えたい。というのも気持ちはとてもわかるけど、ビジネスに与える影響はほとんどないものと考えられるので考慮しないでおく。
「社内ルールで必ずユーザー情報を削除しないといけない」などの事情も考えられるけど、そういう会社はたぶんRedashの導入を許可しないと思うので、これも考慮しない。
オフィスからのアクセスのみに制限する
一番下のレイヤーでアクセスさせなくする方法として各社で取られているであろうアクセス制限のひとつ。
よくあるユーザーを削除したくなるシーンの一つは退職者がでたときだと思うけど、その場合も例外はあれど大抵はオフィスからのIPで制限しておけば心配が減ると思う。
パスワード認証を使わず、Google認証だけを使う
Googleのアカウントを失った時点でアクセスできなくなるので、悪くない対応だと思う。
これも退職のケースで考えると、退職後に同じ会社のメールアドレスを使い続けるのはそれなりのレアケース。
LDAPは使ったことがないけど似たようなことができると思う。
しかし、G Suiteを導入していない会社だったりすると選べない。
パスワード認証を使わないようにするには .env
あたりで以下の環境変数を設定する。
REDASH_PASSWORD_LOGIN_ENABLED=false
これを書いてて、LDAPが触ってみたいと思って触ってないものの一つだということを思い出した。
Basic認証のID/PWを変える
この辺から泥臭い系の対応になってくる。
退職者がでたときにBasic認証を変えましょうという対応。
これは退職者だけでなく、利用者全員に影響するのでそれなりに面倒な対応になる。
そういえば各社認証情報ってどうやって管理してるのか、勉強会とかでいつも聞こうと思って忘れてることのひとつだったりする。
Redashユーザーのパスワードを変える
ユーザーを無効にする機能はなくてもユーザーのパスワードを書き換える機能はある。
といっても、admin画面からは変えられないので、以下のコマンドで変える。
$ sudo -u redash ./bin/run ./manage.py users password [メールアドレス] [新しいパスワード]
redash
ユーザーじゃないとPostgreSQLに接続できなくてエラーになる。というのはRedashあるあるのひとつ。
新しいパスワードを pwgen
などで適当に作ってあげれば事実上ログインできない状態にできるはず。
Redashの所属グループをなくす
仮にログインできても何も見えなければいいよね。という対応。
雑ではあるけど、データを見せたくないということが目的であればこれでもよい。
試してみたところ、クエリやダッシュボードは見えなくなりそうだけど、アラートやスニペットは見えてしまうようだった。
該当ユーザーのメールアドレスをを変える
Twitterでいただいたご意見。
メールアドレスが残ってて、かつ、そのメールアドレスが生きているとパスワードリマインダーが使えてしまうので、これも有用。
メールアドレスは admin であれば他人のメールアドレスも変更できるためお手軽でもある。
まとめ
他にも方法はあるかもしれないけど、ぱっと思いついたのは全部書いた。
現実的には上記に列挙したような対応を各社のRedash利用スタイルやインフラ・情シス事情によって組み合わることになると思う。
ちょうど使用しなくなったユーザーをどうしようか考えていて、この記事を書くに至ったけれど、ユーザーを無効にすることができればだいぶ楽になりそうだなと改めて思った。
すっかりこのブログはRedashブログになってしまったので、「Redash User's blog」に改名したほうがいいのだろうか。
記事公開後のはなし
Twitterでメールアドレスを変えるというアイディアをいただいたので追加しました。
凍結。みたいなのを名前に含めるの、すごく時代を感じますが、やりたくなりますよねー。私はそういうファイルを社内ファイルサーバーでいくつも見てきた世代ですw
— Takuya Arita (@ariarijp) 2018年2月28日
確かにメールアドレスも変えちゃってよさそうですね。
このやり取り踏まえ、メールアドレス変えるパターンとユーザー名変えるパターンも記事に追記しようと思います😉
— Takuya Arita (@ariarijp) 2018年2月28日
「名前を変える」のくだりは「該当ユーザーをRedashにアクセスできなくしたい」とはちょっとずれるので追記しなかったけど、やりたくなりますよね。
Redash Meetup #1 を振り返る
すっかりRedashブログになってきたこのブログですが、今回もRedashについての話です。
TL;DR
楽しかった!
Redash Meetup #1 を主催した
1年以上前からやりたいと思っていたRedashの情報共有イベントをついに開催することができました。
登壇していただいたみなさま、参加していただいたみなさま、改めてありがとうございました!
開催までのはなし
構想
過去2回のハンズオンイベント、Advent Calendarの参加数などを踏まえ、Redashをテーマにしたイベントでも多くの方に参加していただけるのではないか?と思い、今年の1月ごろから具体的に計画していました。
登壇者探し
今回は発表主体のイベントなので、発表ありき、登壇者ありきです。
当然、私は発表するとして、最低でももうひとり発表していただけるかたを探したいと思っていたところ、 @kyoshida さんが快諾してくださいました。これは嬉しかった!
登壇希望です!弊社での活用事例をご紹介できればと思います。
— Katsuhiko YOSHIDA (@kyoshida) 2018年1月18日
日程の検討
運営者の 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 が一手に引き受けてくれました。
後で話を聞いたところ、参加者の受付だけでなく弊社への来客の対応までしてくれたようです。
余談ですが、当日の発表では結局使わなかったものの、「マイクがあったほうが良いんじゃないか?」とイベント当日に思い立ち、夕方にビックカメラまで走ってマイクを買いに行ったのですが、前述の通り結局使わず。自席のキャビネットの下にそっとしまってあります。
ちょっと良いの買ってしまったので、何かの機会に使いたいものです。
ソニー SONY コンデンサーマイク モノラル/PCボーカル用 USB接続対応 マイクスタンド付属 ECM-PCV80U
- 出版社/メーカー: ソニー(SONY)
- 発売日: 2011/10/10
- メディア: エレクトロニクス
- 購入: 32人 クリック: 127回
- この商品を含むブログ (13件) を見る
発表について
会場説明を前にはさみつつ、「Redash 導入事例から考える OSS BI ツール導入チェックリスト」というタイトルで発表しました。
発表で使用したスライドは以下になります。
弊社での導入事例を踏まえ、Redashのみならず、これからBIツールを導入しようと考えている方に、どんなポイントを押さえて検討・検証・運用したらよいか、個人的な経験と視点ではありますが、お話させていただきました。
発表は20分枠でしたが、最後のスライドを表示した時点でだいたい1分押しぐらいになっていたと思います。
コンパクトな会だけに、特に私の担当枠は時間ぴったりに収めたかったので、少し申し訳無さもありつつ、なんとか伝えたい事はすべて話せたかな。と思える発表でした。
実は発表についても当日の昼に同僚にリハーサルに付き合ってもらい、声を出しながら話す内容を調整することができました。リハーサルがなかったらおそらく5分以上押していたと思います。
また、発表内容には関係ありませんが「発表前・発表後に拍手をしましょう」というのを絶対に言うぞと心に決めてイベントを開始し、それが緊張で飛ぶことなく言えたのは、個人的によかったことの一つです。
せっかく貴重な時間を割いて登壇していただくので、少しでも気持ちよく話せる状況にしたいなと思ってのお願いだったのですが、それにみなさんが快く応じてくれたことが、もしかするとイベント中で一番うれしかった瞬間かもしれません。
まとめ
発表主体のイベント主催の初体験はいろいろ難しいこともあり、特に当日の夕方ぐらいからずっと緊張していたのですが、終わってみると「やってよかった」と心から思える良いイベントにすることができました。
次回以降のイベントは全く予定がないのですが、 4.0.0がリリースされるころには、もう一度ぐらいやってみたいかなと、早くも思い始めています。
(イベント開催直前までは「もう今回が最後でいい!」と思うぐらいに軽く追い込まれていました)
めずらしくサンプルコードも含まないのに長い投稿になってしまいましたが、Redash Meetup #1 を振り返ってみました。
参加していただいたみなさま、イベント後に資料を読んでいただいたみなさま、ブログでもSNSでのシェアでもなんでも構いませんので、 #redashmeetup タグなどで感想を教えていただけるとうれしいです。