❄️

Snowflakeで設定した方が良いことのチェックリスト

2022/09/30に公開

data

Snowflake

データ基盤

tech

前書き

Snowflakeをデータウェアハウスとして利用し、プロダクトを開発しているソフトウェアエンジニアです。
普段はSnowflakeに関係するデータ基盤の設計から開発などの業務を行なっています。
SnowflakeのリソースはTerraformで管理したり、CIなどの設計など全般業務に取り組んでいます。

Snowflakeは非常に使いやすく優れた「データウェアハウス」だと思いますが、デフォルトで設定されているパラメータなどが自分のプロダクトに適していないものがあり、次に初期構築を行う場合に確認した方が良いと自分が思っていることをメモとして公開します。

すでに運用を始めているプロダクトでも、一度確認してみることをお勧めします。

チェックリスト

ABORT_DETACHED_QUERYの値をtrueに設定する
「Warehouse」の各種設定を変更する
デフォルトタイムゾーンの修正
data_retention_time_in_days の値の変更

`ABORT_DETACHED_QUERY`の値をtrueに設定する

アカウント全体またはユーザごとなどで設定ができます。トラブル時にWarehouseが立ち上がりっぱなしになって、無駄なコストが発生してしまうことを避けたいと思います。

セッションの突然の終了（ネットワークの停止、ブラウザの終了、サービスの中断など）により接続が失われた場合に、進行中のクエリに対してSnowflakeが実行するアクションを指定します。

「何かしらのトラブルが起きてセッションを終了した場合に、クエリを停止するか」を設定するためのパラメータですが、デフォルトではFalseになっています。
SnowSQLなどのツールを使用していて、何らかのトラブルでセッションが切れた際にWarehouseが何十時間も立ち上がりっぱなしになってしまうトラブルがありました。その時はABORT_DETACHED_QUERYというパラメータの存在を知らなかったので、そのタイミングでABORT_DETACHED_QUERY=Trueに変更しました。
アカウント全体、ユーザごと、セッションごとに設定が可能なので、使用用途に応じて設定方法を決めてもらえらば良いと思います。

パラメータの確認方法

SHOW PARAMETERS IN ACCOUNT;
SHOW PARAMETERS IN USER;
SHOW PARAMETERS IN SESSION;

のようにそれぞれのパラメータが確認できます。※ロールごとに確認できる内容が異なるので注意してください。

SHOW PARAMETERS like 'ABORT_DETACHED_QUERY' IN ACCOUNT;
SHOW PARAMETERS like 'ABORT_DETACHED_QUERY' IN USER;
SHOW PARAMETERS like 'ABORT_DETACHED_QUERY' IN SESSION;

のようにlike(%hoge%)が使えるので必要なパラメータだけに絞り込むこともできます。

設定方法
①アカウントに設定したい場合
②現在のセッションに設定したい場合
③ユーザーhogeの設定を変更したい場合

ALTER ACCOUNT SET ABORT_DETACHED_QUERY = TRUE;  - ①
ALTER SESSION SET ABORT_DETACHED_QUERY = TRUE;  - ②
ALTER USER hoge SET ABORT_DETACHED_QUERY = TRUE;  - ③

Warehouseの各種設定を変更する

ウェアハウスの設定に関する内容で、注意しておきたい内容を以下にあげてみます。サイズについては最初に確認することだと思うので特に取り上げないですが、デフォルトで最小サイズの「XSMALL」になっているので問題はないと思いますが、その他パラメータで変更するべきものがいくつかありました。

ウェアハウスが最もコストに効いてくるので、設定には注意が必要だと思います。

とりあえず、ウェアハウスを新しく作成するためのクエリの自分の理想とするテンプレートは以下になります。

use role SYSADMIN;
create or replace warehouse my_wh 
    warehouse_size=XSMALL
    auto_resume=TRUE
    auto_suspend=60  -- 1min (1分操作がないと停止する)
    initially_suspended=TRUE
    statement_timeout_in_seconds=3600  -- 60min (想定されるQueryの長さによって時間を変える)
    comment='Sample warehouse'
;

解説していきます。設定できるパラメータは以下のドキュメントにあります。

auto_resume をTRUEにする

SQLステートメント（クエリなど）の送信時にウェアハウスを自動的に再開するかどうかを指定します。

デフォルトはTRUEなので、特に変更する必要はないと思います。

auto_suspend の値を小さくする

ウェアハウスが自動的に中断されるまでの非アクティブの秒数を指定します。

使っていないウェアハウスが何秒後に停止されるかを決めることができます。デフォルトは600秒=10分となっているので、少し長いかなと感じました。

毎回最低でも10分のコストが発生してしまうことになってしまうので、ここは60秒=1分に設定を変更しました。（用途に合わせてもう少し長い方が良いなどがあるのかもしれないので、好きな値に設定して良いと思います。あくまで個人の意見です。）

initially_suspended をTRUEにする

ウェアハウスが最初に「一時停止」状態で作成されるかどうかを指定します。

この値がTRUEのとき、一時停止状態で作成されます。一方で、FALSEの場合には、ウェアハウスが起動した状態で作成されます。デフォルトはFALSEなのでウェアハウスを作成すると起動した状態になってしまいます。（つまり、お金がかかるよ。）

おそらく、WebUIで操作をするときに、「ウェアハウスを作成すること」と「クエリをすぐに実行する」ということを考えられて、このように設定されているのだと予想できますが、自分のプロダクトだとウェアハウスはTerraformで作成して、その後すぐにクエリを叩く訳ではないですから、この設定はTRUEに変更しました。

statement_timeout_in_seconds の値を小さくする

実行中のSQLステートメント（クエリ、DDL、DMLなど）がシステムによってキャンセルされるまでの時間を秒単位で指定するオブジェクトパラメーター。

実行中の SQL ステートメント（クエリ、 DDL、 DMLなど）がシステムによってキャンセルされるまでの時間です（秒単位）。

つまり、クエリ実行時間上限を設定しましょうというパラメータです。デフォルトの値は172800秒=2日となっています。さすがにこんなに時間がかかるクエリをすることは想定していないので、この値を600秒=10分、3600秒=60分のようにウェアハウスの用途に合わせて設定するようにしています。

デフォルトタイムゾーンの変更

データにとってタイムゾーンは非常に重要で、複数のテーブルを結合する際にタイムゾーンがずれているだけで不正確で意味のないデータになってしまいます。

テーブルAは日本標準時(JST)で設定されているのに、テーブルBでは協定世界時（UTC）で設定がされていて、それらを結合させれば、それはもうぐちゃぐちゃで価値のないデータができてしまいます。

そのため、データマネジメントレイヤー全体でタイムゾーンを揃えておくことをお勧めします。一番基本的なやり方としては、UTCタイムゾーンに合わせるのが良いと思います。（プロダクト全体で認識があってさえいれば、好みだと思います）

タイムゾーン自体は、基本的にはアカウントパラメーターとしてアカウント全体に設定するのが一般的かと思いますが、ユーザー、セッションごとにも設定することもできます。

UTCに設定するためには、以下のSQLで設定ができます。

alter account set timezone = 'Etc/UTC';

data_retention_time_in_days の値の変更

Snowflakeがオブジェクトに対してTime Travelアクション（SELECT、CLONE、UNDROP）を実行するための履歴データを保持する日数です。

「Time Travel」機能を使うために、何日間データを保持するかを決定するパラメータです。Enterprise Editionの場合は最大で90日間データを保管できます。必要に応じてパラメータを調整します。

alter account set data_retention_time_in_days = 90;