Lookerダッシュボードのパフォーマンスを改善した点
投稿者：鈴木
本稿は Looker Advent Calendar 2022 の20日目の記事です。
目次
- はじめに
- 前提
- 改善点
- まとめ
はじめに
ダッシュボードを開発し、お客様に利用していただいたところダッシュボードのパフォーマンスがもう少し改善できないかとご相談を受けました。
今回はその中で検討した改善点をいくつかご紹介したいと思います。
ダッシュボードの開発やパフォーマンスについて悩まれている方に少しでもお役に立てれば幸いです。
前提
まずはパフォーマンスが悪いといってもどこに原因があるのかを特定する必要があります。
パフォーマンスを改善するために確認する内容はLookerからもいくつかご紹介されていますので、ぜひご活用ください。
- Lookerのパフォーマンスの問題を解決したい！原因別解決方法
- Looker のパフォーマンスを最適化する
- 【新機能】Performance Recommendations dashboardと Query Performance Metrics Exploreについて（Lookerバージョン22.16からGA機能となったSystem Activity ダッシュボードの “パフォーマンスに関する推奨事項ダッシュボード“）
本稿では上記以外に検討した改善点についてご紹介していきます。
改善点
- キャッシュの設定を最適化
- ダッシュボードの最新結果をキャッシュで保持
- コンテンツ間の遷移では既存フィルター値を引き継ぐ
1．キャッシュの設定を最適化
目的
同一クエリであればキャッシュを持たせて、表示することで表示時間は大幅に変わると思います。
そのためにはキャッシュの設定を最適化することが重要になります。
方法
ご利用されている環境によって記載方法は変わりますが、今回はBigQueryのテーブルが1時間に1回更新されるため、最終更新時間が変更された場合キャッシュを更新するようLookMLのdatagroupに以下のような設定をしました。
・変更前：キャッシュの保持時間のみ記載
max_cache_age: "X hour"・変更後：DBのテーブルの最終更新時間が更新されたらキャッシュを更新
sql_trigger:
SELECT
FORMAT_TIMESTAMP('%Y-%m-%d %H', TIMESTAMP_MILLIS(last_modified_time), 'Asia/Tokyo')
FROM
`.データセット名.__TABLES__`
WHERE
table_id = テーブル名;;
※上記はテーブルを指定している場合
もしくは以下のように毎時更新で設定することなども可能です。
sql: select EXTRACT(HOUR FROM CURRENT_TIME()) ;;
sql_triggerで実行されるクエリはご利用のDBの料金に依存するため最適なクエリを設定することを推奨します。
また、どの程度の頻度でsql_triggerを実行するかをconnectionの「PDTとデータグループのメンテナンススケジュール」で設定することも可能です。
2．ダッシュボードの最新結果をキャッシュで保持
目的
ダッシュボードの初期表示を早くするためにダッシュボードの最新結果をキャッシュとして常に保持します。
方法
Datagroupに紐づいたスケジュールをダッシュボードに設定します。
ダッシュボードを表示し、「ダッシュボードのアクション」から「スケジュール配信」をクリックします。
※フォルダからスケジュール配信を設定する場合はデータグループが表示されないためダッシュボード上のオプションから設定が必要
「リカレンス」>「データグループの更新」をクリックし、「データグループ」で 1．で定義したdatagroupを選択します。
datagroupの更新によってトリガーされるスケジュールによって、スケジュール時にダッシュボードが実行されるため最新のデータを表示し、キャッシュを保持することが可能となります。
また、設定はしたものの本当にキャッシュで実行されているのか確認することができます。
ダッシュボードでもキャッシュが表示されている場合は、画面右上に「XX分前」のような表示がされますが、System Activity を利用して詳細を確認することも可能です。
詳細はこちらのLooker ブログを参照ください。
3．コンテンツ間の遷移では既存フィルター値を引き継ぐ
目的
コンテンツの遷移がある場合（ドリルスルー）、ユーザーのフィルター設定の手間を省くようにします。
コンテンツ間に同じフィルターがあれば既存のフィルターを引き継ぐことで、再度設定する必要がなくなるのでユーザービリティの向上が可能です。
方法
今回は linkパラメータ を用いて遷移元のダッシュボードから遷移先のダッシュボードに遷移する際、選択した値でフィルタリングして表示するダッシュボードを例に挙げてご説明します。
前提として、以下のようなダッシュボードがあるとします。
・遷移元ダッシュボード
例）地図上の「渋谷区」をクリックすると遷移先では「渋谷区」でフィルタリングされたダッシュボードを表示する
・遷移先ダッシュボード
例）遷移元ダッシュボードで「渋谷区」を選択したため、遷移先ダッシュボードの「店舗エリア」では「渋谷区」でフィルタリングされた状態で表示される
上記設定をするためには 店舗エリアdimensionにlinkパラメータを用いて以下のような設定をしております。
dimension: storearea {
label: "店舗エリア"
type: string
map_layer_name: tokyo_map
sql: ${TABLE}.storearea ;;
link: {
label: "{{value}} Analytics Dashboard"
url: "/dashboards/100?店舗エリア={{ value | encode_uri }}"
}
}
ダッシュボードには「カテゴリ」フィルターがありますが、上記設定のみの場合、「店舗エリア」のフィルターのみ遷移先に引き継がれることになります。
そのため、クリックした値以外にも同様のフィルターがある場合は既存のフィルターを引き継ぐように設定していきます。
ここでは遷移元の「カテゴリ」フィルターの設定値を遷移先のダッシュボードに引き継ぐようにします（設定手順：公式ドキュメント）。
先ほどのlinkパラメータのurlに &カテゴリ={{_filters[view_name.category’] | url_encode }} を追加します。
dimension: storearea {
label: "店舗エリア"
type: string
map_layer_name: tokyo_map
sql: ${TABLE}.storearea ;;
link: {
label: "{{value}} Analytics Dashboard"
url: "/dashboards/100?店舗エリア={{ value | encode_uri }}&カテゴリ={{_filters['view_name.category'] | url_encode }}"
}
}
遷移元のダッシュボードで「カテゴリ」フィルターをセットします。
遷移すると、以下のフィルター値を引き継いで遷移ができています。
・店舗エリア＝渋谷区
・カテゴリ＝アイス
このようにコンテンツ間に同じフィルターがある場合は遷移先のコンテンツでも既存のフィルターを引き渡すことで、再度フィルターを設定することがなくなるため少しでもユーザーの手間を省くことができます。
まとめ
元々のダッシュボードも数十秒かかるわけではなかったので、大幅に表示時間を減らすことはできませんでしたが、キャッシュを最適化し、ダッシュボード側でも常に最新の結果を保持することでダッシュボードの表示時間を数秒でも早くすることができました。
それでもフィルターを変更した場合などはすべてのパターンに対してキャッシュを保持することは難しく、クエリを実行することになるため、PDTでの定義なども必要になってくるかと思います。
まずは原因がどこにあるかを特定し改善すべき点を確認することが重要となります。
上記以外にも改善するために検討したり設定した箇所はありますが、今回はキャッシュあたりをメインにご紹介いたしました。
他にもより最適な方法があると思いますし、バージョンアップによって新機能も増えていくのでまた更新があり次第共有していきたいと思います！
