Redashのmetadataから便利な情報を取ってくる話

[Redash Advent Calendar 2017](https://qiita.com/advent-calendar/2017/redash) の18日目の記事を書かせていただきます。

Redashを使い出してそろそろ2年近くなりますが、
metadataに関する記事があまりなかったのでこれを機に書いてみたいと思います。

# **Redash Metadataとは**
`Redash Metadata`とはRedashのインストール時にデフォルトで作られる`Database`のことをさします。

<img width="1099" alt="データソース" src="https://qiita-image-store.s3.amazonaws.com/0/159440/99caa2e3-79d8-e712-ccc1-0f0aeedd3973.png">

`AMI`から環境を作った場合には、
`NAME : postgres`
`PASS : redash`
とかで接続できるはずです。

`Docker`などに起こした場合はそれぞれ設定しているかと思います。

# **何が見れるのか**
<img width="375" alt="テーブル一覧" src="https://qiita-image-store.s3.amazonaws.com/0/159440/e9702c2d-bffe-3aab-8f65-54d022e1028a.png">

テーブル名をざっと羅列して見ました。
バージョンは`2.0.0`で確認しています。

ここでは一つ一つの詳細については省略いたします。
~~たぶん誰かやってるよね？~~
`metadata`というくらいなので各種設定から、クエリ情報まで全て入っています。

ちなみに、`users`にはユーザー情報、`data_sources`にはデータソースの接続情報が入っていますが、
前者の`pass`はhash化されていますが、後者の`pass`はそのままです笑
ちゃんと権限設定をして全ての人が見れる状態にはしないようにしましょう。

# **実践編**
`metadata`を使ったサンプルをいくつか紹介したいと思います。
### **archiveしてしまったクエリをまた見たい**
```sql:isArchived.sql
select
    *
from
    queries
where
    is_archived = true
```
なんのことはないです。
`archive`しても論理削除しかしていないので`queries`テーブルには残っています。
あとはよしなに`where句`で`query`や`name`を文字列検索するなどして探してあげてください。

### **定期実行の分布を見たい**
`Refresh Schedule`を設定してあげることで簡単に定期実行ができます。
ですが、特定の時間に偏ったりするとクエリ詰まりが起きたりするので、分布のチェックをしましょう。

```sql:schedule.sql
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)
<img width="501" alt="Pivot" src="https://qiita-image-store.s3.amazonaws.com/0/159440/537b606d-9f07-b989-1348-74b731581d72.png">


こんな感じで出してあげるとわかりやすいですね。

### **クエリ利用チェック**
全然使われていないクエリは断捨離していきましょう。
直近で実行されていないクエリを探します。

```sql:usedQuery.sql
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`を噛ませてどこで使われているかを検索します。

```sql:usedDashboard.sql
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ということで活発に改善も行われているのでこれからもっと利用ケースが増えていきそうです。