はじめに
PeopleXでバックエンドエンジニアをしているchiepingこと本田です。
今回ダッシュボードを構築する機会があり、ダッシュボード構築で得た学びや苦労した点を振り返っていきたいと思います。
Redashとは
Redashはオープンソースのデータ分析・可視化ツールです。
PostgreSQLやMySQLなどのRDBを始めとした様々なデータソースに接続することができるのが特徴で、DynamoDBやElasticSearchなどのRDB以外のDBだったり、AWS AthenaやGoogle Spreadsheetにも接続することができます。
クエリ結果は見栄えのするチャートを始め多くの可視化オプションがあります。
公式ドキュメントより、チャートの可視化の例
元々はRedashは独立した会社で開発されていましたが、2020年にDatabricksにより買収されました。
その影響からDatabricksに注力するためにSaaS版のRedash提供が終了し、Redashの開発は停滞していました。（ちなみにRedashと同じようなことができるDatabricks SQLというツールがあります）
しかし2023年にコミュニティ主導のプロジェクトとしてリブートするというアナウンスがあり、活発にメンテナンスされるようになり、2021年から数年ぶりに安定版のv25.1.0が今年リリースされました。めでたいですね！
同じOSSのBIツールというカテゴリではMetabaseも人気がありますね。
また、Lightdashというdbt (data build tool) の利用が必須の後発のツールも注目されています。
dbt については多くの解説記事がありますが、個人的に以下の記事を読んで具体的イメージがつくようになりました。
RedashはBIツールの中では老舗で目新しさはありませんが、データ分析基盤を構築していなくてもアドホックにクエリを書いて調査・分析できる手軽さが魅力なのかなと思います。
今回やったこと
CSで顧客の活用度合いを知れるようにするため、顧客の会社ごとにアクティブ率や機能利用率などを可視化するダッシュボードを元々導入済みだったRedash上に構築しました。
便利だった機能
Query Results
クエリの結果自体をデータソースとみなして複数のクエリ結果を元に結合したりできる機能です。
S3上に保存されているアクセスログを対象にしたAthenaのクエリとDBのデータを結合できたり、サービスごとに別々に分かれているDBでもシームレスに結合できたりするのがとても便利でした。
以下のように query_ に続けてクエリIDを指定することでクエリ結果をテーブルのように参照できます。
SELECT
a.name,
b.count
FROM query_123 AS a
JOIN query_456 AS b
ON a.id = b.id
（余談ですが、Databricks SQLだと Query Resultsデータソースを対象としなくても別々のデータソースを直接結合したりできるようですね。）
ここで、Athenaなどのクエリ実行に料金が掛かってくる場合にダッシュボードを開く度にクエリ実行されると困る問題があります。クエリが返ってくる時間も数十秒かかるため結果が表示されるまでに時間がかかり過ぎるのも困ります。そういった時には Cached Query Results が利用できます。
SELECT
a.name,
b.count
FROM cached_query_123 AS a
JOIN query_456 AS b
ON a.id = b.id
Query Resultsのプレフィックスを cached_query_ とすることで直近の実行結果が参照され、Athenaの例だと料金発生を抑えられ、結果も即座に返ってくるので役立つ機能です。
Cached Query Results を利用する場合は利用するクエリのスケジュール設定を行っておく必要があります。頻度や実行される時間を設定できます。
表にリンクを設定
今回、顧客の会社を一望できるダッシュボードと、更に部署ごとに見られる部署別ダッシュボードを構築しました。そこで会社ダッシュボードの部署一覧から、部署を選ぶと部署別ダッシュボードにドリルダウンできると便利です。
Visualization設定において、リンクにしたいカラムで以下のようなテンプレート構文を設定することができ、ダッシュボード間の移動を簡単にできるようにしました。
https://my-redash-host/dashboards/2-department?p-department-id={{ department_id }}
Google スプレッドシートに出力する
Googleスプレッドシートをデータソースにすることもできますが、Googleスプレッドシートに出力することもできます。
GoogleスプレッドシートのIMPORTDATA関数を使うということでRedashの機能というかなんというかという感じですが、お手軽ですね。これだけだと自動化には向いていませんがGASを書けば自動化もできそうですね。
他にもアラート機能などは現在は使用していませんが普通に便利そうだなとか、ピボットテーブルなんてのもあるのかと記事を書くにあたって発見がありました。
苦労したこと
クエリの整理
DBを跨るクエリを多用していたため、Query Results機能を使った多段のクエリがいくつも作られることになりましたが、何も規律がないと管理が難しくなりそうだということで、dbt自体を採用しているわけではありませんが、dbtの3層モデル構成を参考にして分類することにしました。
staging層
生データの軽微な変換・標準化（日付フォーマット、カラム名の統一など）を行う
intermediate層
複数のstagingテーブルを結合・集計する
marts層
最終的なレポート・ダッシュボード用
このようなレイヤーに分けて整理してみました。しかしそれでもQuery Results機能を使うと query_123 など無機質な名前で指定しなければならないのでクエリが読みづらくなってしまうという問題は残りました。テーブル名のエイリアスをクエリごとに定めるなど工夫はできそうですね。
Lightdashなどdbtと統合されたBIツールだと上記の問題やクエリのバージョン管理などもうまく解決されていそうな印象を受けました。代わりにdbtの利用が必須のためエンジニアでないと扱うのが難しくなり手軽さが失われるというトレードオフはありそうですが、今後注目していきたいと思います。
AIツールの利用の落とし穴
今回Cursorエディタを使ってクエリを一気に作ってみるという進め方をしました。
AIツールを活用することで見栄えのいいそれっぽいダッシュボードができるというところまでは爆速で作れて、仕上がりのイメージが早い段階でできるなど良い面もあったのですが、それにより苦労したことも多かったです。
それっぽく表示はされているものの実は間違っていたとか、そもそも正確に取得することができないデータだった（例えば時系列で表示しているチャートだけどDB設計上時系列で過去の正確な数字が出せないなど）みたいなことが何度かあり、その度に人間が悩むことになりました。またひとつひとつのチャートが明確に「こういうチャートが必要だ」と吟味されてから作られたわけではなかったため、「今悩んでるこのチャート、そもそも必要なんだっけ？」とモヤモヤすることがあったりしました。サクッと作ってみるというところのハードルはAIツールの活用で下がったものの、実際に出ている数字が正しいことを保証して運用で使えるようにするまでのギャップは大きく、大量の複雑なSQLを相手にするのはしんどかったです。
どういう情報が知りたいか、そのうちどれが大事でどれが nice to have くらいなのかを把握した上で、必要なものから仕上げていくような動き方のほうがよかったのかなと思います。
さいごに
これまでRedash自体あまり使用経験なかったのですがダッシュボード構築での学びを語らせていただきました。
機能紹介もとても断片的ですので、Redashが気になった方はこれを機に公式ドキュメントなどもご覧になってみてはいかがでしょうか。
PeopleXのテックブログです。採用情報：hrmos.co/pages/peoplex/jobs 対話型AI面接「PeopleX AI面接」、エンプロイーサクセスPF「PeopleWork」、人事業務自動化AIエージェント「HR Operator」など、AIプロダクト多数開発しています。
Discussion