こんにちは、データエンジニアの中村です。
弊社ではBIツールとしてGoogle Cloudから提供されているLookerを利用しています。
Lookerの利用者も徐々に増えており、日々データ活用が進んでいることは嬉しいですが、それと比例して気になるのはダッシュボードの表示速度やクエリコスト等のパフォーマンスです。
最近AggregateAwarenessという機能を利用してパフォーマンスを改善することができたので、その機能を利用するに至った背景と、その改善効果を紹介したいと思います。
AggregateAwarenessの詳細な使い方は説明しないので、その点はご了承ください。
この記事はEnigmo Advent Calendar 2024 の19日目の記事です。
目次
背景
弊社のデータ基盤はBigQueryを採用しており、LookerからBigQueryへのクエリでどのくらいのコストが発生しているかをモニタリングしています。
今年の8月ごろからクエリコストが増加していることが判明し、原因調査から始めました。
原因はアクセス量の多いダッシュボードにスキャン量の大きいLookを追加したことによるものでした。
対策としては、Lookに対応した軽量のデータマートを用意してあげることでコストを抑えるといった方法があると思いますが、パネル毎にデータマートを用意するのは大変ですし、メンテナンスコストも高くなります。
かといって、DWH層を一から整備していくのは時間がかかりそうです。
そこで、両者のメリットを兼ね備えた方法としてAggregateAwarenessという機能に辿り着きました。
AggregateAwarenessとは
AggregateAwarenessとは、データマートに相当する、事前に集計されたテーブルを自動で作成し、クエリの際にそのテーブルを自動で認識してくれる機能です。
ざっくりとした手順を以下に記載しますが、本題ではないので詳細は割愛します。利用方法はクラスメソッドさんのこちらの記事が参考になりました。
①AggregateAwarenessを適用したいLookが参照しているExplore画面を表示 ↓ ②Explore画面より、AggregateAwareness用に自動生成されたLookMLをコピー ↓ ③コピーしたLookMLを、対象のexploreが定義されているmodelファイルのexploreブロックへコピペ ↓ ④Exploreからクエリを実行すると、BigQueryにLookMLで指定した条件で集計されたテーブルが作成される ↓ ⑤次回以降は④で作成された集計テーブルへクエリしに行ってくれるので、クエリパフォーマンスが向上する
この方法だと、テーブルの作成をLooker側で行なってくれるので、工数をかけずにマートの作成が行えてよかったです。
また、パネルが不要になったら、コピペしたLookMLと自動で作成されたテーブルを削除すればクリーニングが済むので、後片付けが楽そうだと感じました。
紹介はここまでにして、AggregateAwarenessを利用した結果の方を説明していこうと思います。
利用した結果
グラフを見ると一目瞭然ですが、適用前後で大幅にコストを削減することができています。
修正した日付が11月14日なので、11/10の週から減少傾向になり、11/17の週から一気に削減効果が現れていますね。
クエリ一回あたりのコストも連動して減少しているので、クエリ回数が減ったことによる効果ではなさそうです。
| コスト | 期間①※1 | 期間②※2 | 減少率 |
|---|---|---|---|
| クエリ全体のコスト(円) | (省略) | (省略) | 71.8% |
| クエリ1回あたりのコスト(円/クエリ) | 13.75 | 3.53 | 74.3% |
※1期間①: 10/14~11/13(修正日前日から直近1ヶ月)
※2期間②: 11/14~12/15(修正日当日から1ヶ月後まで)
具体的な数値だと、適用前後1ヶ月で全体のクエリコストを約71%、クエリ一回あたりのコストを約74%削減できました！
また、今回の対応を行うきっかけとなったパネル以外にもAggregateAwarenessを適用したことで、コスト増加前の期間よりも改善されていました。
| コスト | 期間③※3 | 期間②※2 | 減少率 |
|---|---|---|---|
| クエリ全体のコスト(円) | (省略) | (省略) | 34.0% |
| クエリ1回あたりのコスト(円/クエリ) | 7.17 | 3.53 | 50.8% |
※3期間③: 7/1~7/31(コスト増加前)
平常時と比較しても約50%のコスト削減効果を得られたので、年間を通してかなり効きそうですね。
なお、クエリパフォーマンスも改善されており、平常時の平均実行時間はは4秒程度だったものが、適用後は3秒程度まで減少していました。
コスト削減と同時にユーザビリティを向上させることもできました！
メリデメ
AggregateAwarenessを使用してみて、以下のメリットがあると感じました。
メリット
- 簡単にデータマートを作成でき、削除する際もクリーニングが簡単
- クエリのパフォーマンスが課題になっている場合、改善効果が大きい
ただし、上記のメリットはあくまで短期的な視点で見た時のものであり、中・長期的な視点で考えると以下のようなデメリットもあると感じました。
デメリット
- パフォーマンスが低下するたびに対応が必要で、イタチごっごになってしまう。（スケーラビリティの低下）
- AggregateAwarenessの利用が膨大になると、メンテナンスコストが増加しそう。(このLookMLってどのLookに対応してるんだっけ？とかが起こる)
これらのメリデメを加味してバランスよく利用していけばかなり有用な機能だと思いました。
メリットが大きすぎるので、個人的にはどんどん利用していきたいです。
まとめ
AggregateAwarenessを利用することで、Lookerのコストを約70%削減することができました。
平均クエリ実行時間も減少し、ユーザビリティの向上も同時に行えました。
「まだ利用していない&パフォーマンスを改善したい」場合は利用をお勧め！
最後に
最後までご覧いただきありがとうございました！
明日の記事の担当は、本日と同じくデータエンジニアの中村です。お楽しみに！
株式会社エニグモ すべての求人一覧
