Redash Advent Calendar 2017 の18日目の記事を書かせていただきます。
Redashを使い出してそろそろ2年近くなりますが、
metadataに関する記事があまりなかったのでこれを機に書いてみたいと思います。
Redash Metadataとは
Redash MetadataとはRedashのインストール時にデフォルトで作られるDatabaseのことをさします。
AMIから環境を作った場合には、
NAME : postgres
PASS : redash
とかで接続できるはずです。
Dockerなどに起こした場合はそれぞれ設定しているかと思います。
何が見れるのか
テーブル名をざっと羅列して見ました。
バージョンは2.0.0で確認しています。
ここでは一つ一つの詳細については省略いたします。
たぶん誰かやってるよね？
metadataというくらいなので各種設定から、クエリ情報まで全て入っています。
ちなみに、usersにはユーザー情報、data_sourcesにはデータソースの接続情報が入っていますが、
前者のpassはhash化されていますが、後者のpassはそのままです笑
ちゃんと権限設定をして全ての人が見れる状態にはしないようにしましょう。
実践編
metadataを使ったサンプルをいくつか紹介したいと思います。
archiveしてしまったクエリをまた見たい
select
*
from
queries
where
is_archived = true
なんのことはないです。
archiveしても論理削除しかしていないのでqueriesテーブルには残っています。
あとはよしなにwhere句でqueryやnameを文字列検索するなどして探してあげてください。
定期実行の分布を見たい
Refresh Scheduleを設定してあげることで簡単に定期実行ができます。
ですが、特定の時間に偏ったりするとクエリ詰まりが起きたりするので、分布のチェックをしましょう。
select
q.schedule
,q.name
,ds.name as db_name
from
queries q
left outer join
data_sources ds
on
q.data_source_id = ds.id
where
schedule != ''
スケジュールは設定されてなければ空文字、設定されていれば時間が文字列で入ってくるのでそこで判定しています。
結果（Table）
| SCHEDULE | NAME | DB_NAME |
|---|---|---|
| 00:00 | 実行時間分布 | Redash Metadata |
| 01:15 | hogehogeのKPI | Redash Metadata |
| 01:30 | hugahugaのKPI | Redash Metadata |
| 02:00 | test1 | test |
| 02:40 | tst2 | test |
結果(Pivot)
こんな感じで出してあげるとわかりやすいですね。
クエリ利用チェック
全然使われていないクエリは断捨離していきましょう。
直近で実行されていないクエリを探します。
select
object_id as query_id
,q.name
,e.created_at as execute_time
from
events e
left outer join
queries as q
on
cast(e.object_id as integer) = q.id
where
action = 'execute'
order by
e.created_at
結果
| QUERY_ID | NAME | EXECUTE_TIME |
|:--|:--|:--||--:|:--|:--|
| 2 | 実行時間分布 | 18/12/17 06:34 |
| 2 | 実行時間分布 | 18/12/17 06:35 |
| 3 | test1 | 18/12/17 06:36 |
| 2 | 実行時間分布 | 18/12/17 06:37 |
| 2 | 実行時間分布 | 18/12/17 06:49 |
| 2 | 実行時間分布 | 18/12/17 06:50 |
ダッシュボードでの利用チェック
ダッシュボードからクエリに飛ぶのは簡単ですが、
クエリがどのダッシュボードで使われているかを追うのはすぐにはわかりません。
visualizationsとwidgetsを噛ませてどこで使われているかを検索します。
select
v.id as visualization_id
,v.type
,v.query_id
,d.name as dashboard_name
,w.dashboard_id
,w.id as widget_id
from
visualizations v
left outer join
widgets w
on
v.id = w.visualization_id
left outer join
dashboards d
on
w.dashboard_id = d.id
where
d.name != ''
結果
| VISUALIZATION_ID | TYPE | QUERY_ID | DASHBOARD_NAME | DASHBOARD_ID | WIDGET_ID |
|---|---|---|---|---|---|
| 6 | PIVOT | 2 | test board | 1 | 1 |
| 7 | TABLE | 6 | test board | 1 | 2 |
これで古くなったクエリを削除するときにもどこで使われているかすぐ見つけられます。
サンプルは以上になります。
最後に
Redash metadata とその使い方について紹介してきました。
今回のサンプルであげていないテーブルが他にもありますし、
こんな便利な使い方あるよとかありましたらぜひコメントから教えて頂けますと幸いです。
去年のアドベントカレンダーとか半分も埋まってなくて "re:dash" いまいちなのかなぁとか思ってましたが、
気づいたら "Redash" になり今年のカレンダーも全部埋まるくらいの盛り上がりになってきましたね。
ちなみに去年はカレンダー書いてません
とても手軽に見える化できるダッシュボードツールであり、
OSSということで活発に改善も行われているのでこれからもっと利用ケースが増えていきそうです。