[Looker22.2新機能]LookerのExploreとSQL RunnerにおいてSnowflake接続でもCost Estimateが可能になりました #looker

さがらです。

先日、Lookerの22.2がリリースされました。

このリリースノートの「その他の追加機能」に記載されていた、下記の記述に関して確認してみたのでまとめてみます。

Snowflake接続でCost Estimateオプションがサポートされるようになりました。このオプションは、ExploreクエリおよびSQL Runnerクエリのコスト見積もりを可能にします

前置き：LookerのCost Estimateとは？

これまでLookerは、BigQueryと接続した時のみ限定で、ExploreまたはSQL Runnerでクエリを発行したときに実行ボタンの左にスキャンするデータ量が表示されていました。（下図赤枠内）

これが22.2のアップデートにより、Snowflakeを用いた場合でも出来るようになりました。

事前準備：Connectionの設定変更

さて早速SnowflakeへのConnectionを使用したプロジェクトで試したいのですが、その前に対象のSnowflakeへのConnectionで設定変更が必要となります。

対象のSnowflakeへのConnectionの設定で、下図の赤枠内Cost Estimateにチェックを入れて、保存してください。

試してみた

Cost Estimateを適用させるには上記の設定変更だけでOKですので、Snowflakeの場合どのようにCost Estimateが表示されるのかを見てみます。

結論として、Cost Estimateとして表示される内容はBigQueryと同じくスキャンするデータ量です。

また、キャッシュが使用できる場合は、Will fetch ~~ rows from cacheと、BigQueryの場合と同じ表記がされますね。

この機能がどういった場面で活きるか？

改めて、この機能がどういった場面で活きるか考えてみます。

BigQueryを用いた時のCost Estimate機能は、BigQueryがオンデマンド契約の場合「スキャンしたデータ量」ベースで課金されるので、LookerのCost Estimateは事前にスキャン量を表示してユーザーへのコスト意識を持たせる意味でも有用な防止策となっていました。

一方でSnowflakeの場合は、「使用するウェアハウスの稼働時間」ベースで費用が発生するため、スキャンするデータ量を表示しても直接的なコスト削減意識につながるわけではありません。

ですが、この機能はSnowflakeの対象のテーブルに対して、無駄なスキャンを行っていないかを確認することに役立つと思います。

例えば、TB級のテーブルに対するクエリを発行し、2~3個のフィールド選択かつフィルタで条件を絞っているのにスキャン量がとても多い場合、Snowflakeのクラスタリングが適切に行われていない可能性があります。

もちろん頻繁にフィルタで条件を絞り込まれるカラムに対してクラスタリングキーの設定を行わないと逆にパフォーマンスやコストを悪化させるリスクもありますが、Snowflakeのクラスタリング関係の関数を使わずとも、Looker経由でざっとクエリコストを確認して「あれ、このExploreスキャンしすぎじゃない？」と気付けるようになったことはメリットだと考えています。

最後に

LookerがGoogle Cloud傘下になったとしても、Snowflakeとの連携機能も追加してくれるのは純粋に嬉しいですね！笑

今後もSnowflakeと連携した時に役立つアップデート期待しています！