Zenn
❄️

実践 Zero to Snowflake #4：仮想ウェアハウス(Virtual Warehouses)の設定

に公開
Snowflake
tech

個人的取り組みで始めた『実践 Zero to Snoflake』シリーズ。

当エントリは『#4：仮想ウェアハウス(Virtual Warehouses)の設定』について実践を進めていきます。

はじめに

このエントリで言及するチュートリアルで実践しているのは仮想ウェアハウスに関する設定・準備です。

Snowflakeにおける仮想ウェアハウスは単に「ウェアハウス」と呼ばれることが多く「Snowflakeの計算リソースのクラスター」を指します。仮想ウェアハウスには「標準」と「Snowpark用に最適化」の2つのタイプが存在します。

仮想ウェアハウスの仕組みを用いることでSnowflakeデータの分析を可能にする、動的でスケーラブル、かつ費用対効果の高いコンピューティングパワーをあらゆるデータ処理ニーズに対して活用することができるようになります。

その他仮想ウェアハウスに関する概要：
https://docs.snowflake.com/ja/user-guide/warehouses

1. コンテキスト設定

実践エントリ#3で紹介していたSQLファイルのうち、下記部分を実行。

ALTER SESSION SET query_tag = '{"origin":"sf_sit-is","name":"tb_zts","version":{"major":1, "minor":1},"attributes":{"is_quickstart":1, "source":"tastybytes", "vignette": "getting_started_with_snowflake"}}';

USE DATABASE tb_101;
USE ROLE accountadmin;

1つめのALTER SESSION SETコマンドでは、現在のセッションの動作を変更するパラメーターを設定しています。「セッション内のすべてのクエリに対して、由来・名前・バージョン情報・属性などを含む構造化タグを一括付与」しているようですね。項目詳細までは把握しきれていませんが、後述パートで何等か使う機会があるのでしょうか。期待しましょう。
https://docs.snowflake.com/ja/sql-reference/sql/alter-session

2. ウェアハウスの作成

次いで「ウェアハウスの作成」。
SHOW WAREHOUSESコマンドで現行環境のウェアハウス一覧を確認したうえで、

SHOW WAREHOUSES;

所定の設定値でmy_whというウェアハウスをCREATE OR REPLACE WAREHOUSEコマンドで作成。

CREATE OR REPLACE WAREHOUSE my_wh
    COMMENT = 'My TastyBytes warehouse'
    WAREHOUSE_TYPE = 'standard'
    WAREHOUSE_SIZE = 'xsmall'
    MIN_CLUSTER_COUNT = 1
    MAX_CLUSTER_COUNT = 2
    SCALING_POLICY = 'standard'
    AUTO_SUSPEND = 60
    INITIALLY_SUSPENDED = true
    AUTO_RESUME = false;

3.ウェアハウスの利用と再開

早速このウェアハウスを使ってクエリしてみましょう。USE WAREHOUSEコマンドでウェアハウス:my_whの利用を宣言し、SELECT文でクエリを掛けてみます。

USE WAREHOUSE my_wh;
SELECT * FROM raw_pos.truck_details;

ですが以下のようにエラーが出てしまいました。これはウェアハウスが設定により一時停止されており、AUTO_RESUMEが有効になっていないため発生したものです。

確かに該当のウェアハウスにおけるAUTO_RESUME列を見るとfalseになっています。

ALTER WAREHOUSEコマンドで設定を有効化し、

ALTER WAREHOUSE my_wh RESUME;
ALTER WAREHOUSE my_wh SET AUTO_RESUME = TRUE;

改めて設定を確認。有効化されていますね。

改めて先程のSELECT文を実行。

SELECT * FROM raw_pos.truck_details;

今度は結果が表示されました。

4. ウェアハウスの拡張

Snowflakeのウェアハウスは弾力性を重視して設計されており、より負荷の高いワークロードに対応するために、ウェアハウスをリアルタイムでスケールアップすることが可能です。

試しにウェアハウスをX-Largeサイズにスケールアップしてみます。ちなみに当エントリで扱っているウェアハウス: my_whは先述SQLで指定した通り、x-smallサイズとなっています。

ウェアハウスサイズを変更する前に、既存のx-smallサイズでこれから実行するクエリを動かしてみたらどれくらい掛かるか試してみましょう。

SELECT
    o.truck_brand_name,
    COUNT(DISTINCT o.order_id) AS order_count,
    SUM(o.price) AS total_sales
FROM analytics.orders_v o
GROUP BY o.truck_brand_name
ORDER BY total_sales DESC;

結果、1分少々掛かりました。

以下のSQLを実行。

ALTER WAREHOUSE my_wh SET warehouse_size = 'XLarge';

改めてサイズを確認。x-largeに変更されています。(※ここで設定変更したウェアハウスサイズは次のステップでもとに戻します)

そして検証用クエリを再実行。x-smallサイズで1分掛かっていたクエリが、x-largeサイズのウェアハウスで実行したところ7秒で実行できました！これは明らかにウェアハウス変更の効果が効いていますね。

Snowflakeの「ウェアハウス設定」に関する有用情報

後学のために、Snowflakeにおけるウェアハウス設定で有用そうな情報をまとめておこうと思います。

まとめ

という訳で、実践『Zero to Snowflake』第4弾、『仮想ウェアハウス(Virtual Warehouses)の設定』の紹介でした。

エントリ終盤でウェアハウスの性能そのものを変更してその効果を実感することができましたが、このように用途状況に応じて柔軟に実行性能を変更できるというのはとても便利ですね。

次は『#5：Query Result Cache(クエリリザルトキャッシュ)』について実践していきます。

Discussion