CONFIDENTIAL Self-Hosted Redash 
 だからできること
 株式会社 TVer / muddydixon
 2021/10/26 Redash Meetup v8.0.0


CONFIDENTIAL CONFIDENTIAL Contents
 ● 前提条件
 ● PostgreSQL について
 ● 各種監視の用途
 ● 権限管理の用途


CONFIDENTIAL CONFIDENTIAL 前提条件
 ● TVer 社では GCP BigQuery にデータを寄せて集計・分析を行っています
 ● 用途
 ○ 日々の KPI の集計
 ○ レポート作成のための AdHoc 分析
 ○ 新しいデータサービスを生み出すための AdHoc 分析
 ○ 定期的な監視
 ● 仮テーブルや仮 View がどうしても変更されたりします
 ○ 案件系の分析の場合、社外から持ち込まれるデータとか


CONFIDENTIAL CONFIDENTIAL Redash の PostgreSQL について
 ● Redash のデータをすべて管理しています
 ○ user
 ○ group
 ○ query
 ○ query_results
 ○ など
 ● 起動時に設定した PostgreSQL 自体を Datasource として追加 できます
 ○ つまり、自分自身 (Redash) の中身を Redash で調べることができます


CONFIDENTIAL CONFIDENTIAL 各種監視: 利用テーブルのチェック
 ● 特定のデータセット・テーブルにアクセスしてい るクエリを抽出する
 ○ View の置き換え、テーブル廃棄などの調査を行う ことができます
 ■ 案件データを `my-project.partner_data.hoge_attributions` に 入れてたけど、 `my-project.partner_data.hoge_attributions_202 11026` に変更する、など 
 ■ マイグレーション時に過去テーブルを参照して いるクエリを捨てさる、など 
 ● 右のようなクエリを1つ保存しておいてスターし ておくと便利です


CONFIDENTIAL CONFIDENTIAL 各種監視: レビュー状態の監視 (1/2)
 ● 弊社ではクエリのタグにレビュー状態をつけています (これはこれで辛い)
 ○ レビュー待ち: Reviewing
 ○ 差し戻し: Retake
 ○ レビュー完了: Reviewed
 ● 合わせて Query Snippet に「__checklist」として下記のようなコメントを入れ込んでい ます
 ● これを Scheduled Query + Alert で Slack に連携して、品質向上を図っています (完 全にできているとは言っていない
 /* 下記項目をチェックし、OK なら "reviewed" / NG なら "retake" という tag をつけてください * 作成者: * 確認者: * [ ] [ ] XXX の確認 * [ ] [ ] XXX の確認 * [ ] [ ] UTC/JST の確認 * [ ] [ ] TIMESTAMP_TRUNC の確認 * [ ] [ ] 走査範囲の確認 (確認しないとお金がかかります) * [ ] [ ] OA時間の確認(番組表の時刻は実際のOAと異なる場合がある) * [ ] [ ] TABLE_SUFFIX の確認 * [ ] [ ] GROUP BY のキーの確認 * [ ] [ ] 集計値が現実的なもの(日本人の総数より多い、など)か確認 * [ ] [ ] 外部提供時に識別子を用いる場合に適切な撹拌がされていることを確認 */

CONFIDENTIAL CONFIDENTIAL 各種監視: レビュー状態の監視 (2/2)
 ● 監視クエリはこんな感じ
 ● Query Snippet の中の
 ○ 作成者
 ○ 確認者
 ● を拾ってきて「誰がたくさん依頼を出して いるか」「誰にレビューがよっているか」を 集計できます
 SELECT id, name, tags, reviewee, reviewer, link, COUNT(1) OVER() AS total_query_num FROM ( SELECT queries.id, queries.name, STRING_AGG(tag, ',') AS tags, users.name AS reviewee, REGEXP_MATCHES(query, '\*\s?確認者:\s?([^\n]*)') AS reviewer, CONCAT('LINK') AS link FROM queries CROSS JOIN UNNEST(tags) AS tag INNER JOIN users ON user_id = users.id WHERE NOT is_archived AND ( query LIKE '%reviewing%' OR tag = 'reviewing' ) GROUP BY queries.id, queries.name, reviewee, reviewer, link ) AS queries

CONFIDENTIAL CONFIDENTIAL 権限管理 (1/3)
 ● Redash は User ではなく、 Group ごとに権限が分かれています
 ● なんか細かくできるような感じに見えますが実はイマイチです (知ってた)
 ○ View Only なのに生 SQL 見られちゃう
 ○ ただし、変更したらそれは実行できない


CONFIDENTIAL CONFIDENTIAL 権限管理 (2/3)
 ● UI 上の権限と内部権限の対応むずい
 ● 確認はできます
 ○ 実装との対応は「redash/redash/handlers/queries.py」など
 class QuerySearchResource(BaseResource): @require_permission("view_query") def get(self):

CONFIDENTIAL CONFIDENTIAL 権限管理 (3/3)
 ● UI 上ではいじることはできないですが、この Postgresql を直接操作すれば変更できま す
 ● しかも、database に外部からアクセスしなくても、 Redash 内部からアクセスができます (魔改造)
 ○ ECS とか GKE とか使ってる場合は、DB に直アクセスの口を設けない
 ● ただ、この権限と操作上の対応も実は頭がよじれそう
 ● 僕らがほしかったのはこういう権限
 ○ SQL は見られない:
 ■ queries/${ID}/source に直アクセスしたらパーミションエラー
 ■ HTTP の通信上に乗らないでほしい
 ■ x view_query、x edit_query 
 ○ Query ID を指定して実行はできる➞実行結果も取り出せる: 
 ■ o execute_query
 ○ ちなみに昔 "view_source" 権限を追加してほしいという PR は出した
 ■ 放置してる。ごめんなさい 
 ■ https://github.com/getredash/redash/pull/3782 


CONFIDENTIAL CONFIDENTIAL まとめ
 ● Redash のメタテーブル、特に Query テーブルは Redash 自身で利用状況や情報の収 集ができます
 ● events というテーブルにクエリの変更履歴とか実行履歴(action=execute_query)とかが あるので集計ができます
 ○ 誰が頑張って保守しているか
 ○ 定期的に実行されているクエリはどれか
 ■ 逆に言うと、実行されておらず削除していいクエリがわかる 
 ○ 弊社では BQ の Audit を Datasource も追加し、監視しています
 ■ こっちの方が情報はリッチ (処理したバイトサイズがでる)なので繋げたい 


CONFIDENTIAL CONFIDENTIAL 時間が余ったら
 TVer は(テレビの)放送視聴データも(TVer アプリの)配信視聴データも両方あって、日 本の広告費 マス: 1兆6千500億円、ネット: 2.2兆円 (※) を改善したりできる可能性を 秘めています
 楽しいですよ！
 https://www.wantedly.com/companies/co mpany_4696980
 https://www.dentsu.co.jp/news/release/2021/0225-010340.html