この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
※本エントリは、クラスメソッド BigQuery Advent Calendar 2020の23日目のエントリです。
私が投稿した2日目のエントリに引き続き、今回もLookerと関係する内容となります。
LookerでBigQueryを接続先としたとき、使用料を抑える際の基本は「レコード数をバランス良く分けられる日付等のカラムでパーティショニングを施し、そのカラムに対してalways_filterやconditionally_filterを用いて、必ずフィルタがされるようにexploreの設計をすること」だと思います。
しかし、always_filter等のフィルタ設定はLookMLでexploreごとに記述をしないといけないため、記述を忘れてしまったり、パーティショニングをしていないカラムを設定してしまったり、人的ミスがたまに起こりうると私は考えています。
そんなとき、LookerではBigQuery専用のオプション「Max Billing Gigabytes」を用いてBigQueryに発行されるクエリのデータ探索量を強制的に抑える事ができます。
本エントリでは、この「Max Billing Gigabytes」について説明していきます。
設定について
まず、「Max Billing Gigabytes」と聞いて、この設定がどこにあるか浮かばない人もいるかと思います。
Max Billing Gigabytesは、Lookerで使用するDWHなどの接続先を設定するAdminタブの中の「Connections」で、BigQueryの接続設定を行う際に表示されるオプションの１つです。
この枠内に値を入れれば設定が可能なのですが、「数値の直接入力」と「ユーザー属性の値を引用」の2種類の方法があります。
数値の直接入力
まず、数値を直接入力する方法についてです。
こちらは、下図のように直接「3」と入れてあげると、このBigQueryのConnectionを使用する人は、探索するデータ量が3GB以下のクエリしか発行できなくなります。
このConnectionを介してBigQueryを使用する人全員に対して、クエリデータ量を制限したい場合には、この設定を行うのが良いと思います。
ユーザー属性の値を引用
続いて、ユーザー属性の値を引用する方法についてです。
こちらはどういうことかと言うと、下図の赤枠のようにMax Billing Gigabytesの設定の一番右側の人型のアイコンをクリックすると、使用可能なユーザー属性の一覧が表示されます。
ユーザー属性の値を引用する場合には、発行するクエリの探索データ量の制限をユーザーごとにかけられるようになります。
例えば、Aさんは年単位での分析でいいから1GBまで、Bさんは全データを分析してほしいから10GBまで、といったようなイメージですね。
ユーザー属性を使用する場合には、自分で作成した物を使用することが前提となります。 ユーザー属性の作り方に関しては下記の公式Docを参考にしてみてください。
実際にやってみた
実際に「ユーザー属性の値を引用」する方法で、ユーザー属性の設定から、Max Billing Gigabytesがどういった挙動を見せるのか、までを確認してみます。
ユーザー属性の作成
ユーザー属性は下図のように作成しました。
数値が入るためData Typeは”Number”にし、ユーザーに勝手に値を変えられては困るためUser Accessは”View”、と設定しています。
ユーザーへの値の設定は、下図の用に1GBで制限をかけてみました。
検証
Explore
まず、Exploreで制限となる1GB以上のデータを探索するクエリを発行しようとするとどうなるのかを見てみます。
現在1GBで制限をかけているので、クエリするデータの量が1GBを超えると、下図のようにエラーメッセージが表示されます。
SQL Runner
続いて、SQL Runnerで1GB以上のデータを探索するクエリを発行しようとするとどうなるのかを見てみます。
こちらも、Exploreと同様にRUNを押した後にエラーが表示されましたね！
Look
最後に、Lookでは制限がかかるのかどうかを確認します。
下図のように、Lookも問題なく制限がかかることが確認できました！
ただLookの場合、下手に制限をかけていると「見ることができないぞ！」という声をユーザーから頂くリスクもあると感じました…
Max Billing Gigabytesを設定したBigQueryのデータを用いてLookを作成する場合は、Lookにデフォルトでフィルタを設定しておき、ユーザーに設定したクエリデータ量の制限値以下のデータで表示出来るようにしておくことが良いかもしれませんね。
Max Billing Gigabytesの注意点
１つ注意点としては、永続的な派生テーブル(PDT)を作成する際のクエリは、Max Billing Gigabytesが良くも悪くも適用されません。
どのユーザーも永続的な派生テーブルがどんなクエリから作られていても問題なく使用できる点は良いのですが、ユーザーの権限によっては全データの探索を行う負荷の大きいクエリを使った永続的な派生テーブルを設定できてしまいます。
このため、運用時には注意が必要ですね。
私個人の考えですが、LookMLの開発者に対してはSQL Runnerを用いて永続的な派生テーブルを作る人も多いためクエリデータ量の制限はかけず、Exploreを使ってグラフを作るビジネスユーザーに対してはデータの内容に応じてクエリデータ量の制限を設定する、というのが良いのではと感じています。
最後に
Max Billing Gigabytesを用いることで、強制的にユーザーに対してクエリデータ量の制限をかけることが出来ます。
しかし、年単位で分析を行わせたいときに、2019年は全データで1GB、2020年は全データで10GBなど、年ごとにデータの容量がバラバラのときは、正直運用が難しいオプションだとも思います。
使用する場面は限られてくるかもしれませんが、多くのデータを探索するクエリばかり発行するユーザーが多くて困ったときには劇薬として使うのもありかなと思います。笑
少しマニアックな機能ですが、参考になれば幸いです！
クラスメソッド BigQuery Advent Calendar 2020、次回の24日目はみかみさんが担当します、お楽しみに！
3
