snowfakeハンズオンに参加したメモ

クエリベンチマーク

S3からのファイル取込み

ファイル数376、総レコード数 6,200万弱。カラム数は16？17？ぐらい

ウェアハウスSサイズ（2クレジット／hour）で約46秒
ウェアハウスMサイズ（4クレジット／hour）で約24秒

上記をSELECT *

ウェアハウスSサイズ（2クレジット／hour）で約47秒
ウェアハウスMサイズ（4クレジット／hour）で約31.3秒
ウェアハウスLサイズ（8クレジット／hour）で約20.65秒
※一度クエリしてキャッシュに乗ったあとは0.1秒

感覚的にはL（8クレジット）ぐらいでBigQueryのオンデマンド課金と同じぐらいか？

集計関数

トランザクション発生日ごとに利用者数（count）や利用時間平均（average）を取得するsqlを実行。抽出カラムは3カラム。

ウェアハウスLサイズ（8クレジット／hour）で約1.27秒

UPDATE

6,200万弱のレコードを全件一意な値でupdate。updateカラムは1カラムのみ。

ウェアハウスMサイズ（4クレジット／hour）で約13.23秒
ウェアハウスLサイズ（8クレジット／hour）で約9.55秒

結構早い。

サイジング、ウェアハウス起動時間と課金

当たり前だが、ウェアハウスがスケールアップするごとに処理性能が線形に向上するわけではない。
さらに、明示的に起動/停止しない限りは、ウェアハウスはクエリ完了後にも一定時間は起動し続けるので、サイズの大きいウェアハウスを起動すればそれだけ処理性能単価は上がる。

定石通り、リアルの処理にはレイテンシが最大化するウェエアハウスを、バッチ処理にはコスト効率とスループットのバランスが最も良いウェアハウスをサイジングするのが良い。

クーロン

データのレプリケーションのことだが、実際に物理データをコピーしているわけではない。
実データをコピーしていないので、ストレージ費用もコンピュートリソースもほぼ喰わない。

物理データファイルはそのままに、論理的にテーブルオブジェクトを分けて、さらにそれぞれの更新データだけは別々に管理することでユーザーからは透過的に別のオブジェクトとして存在しているように見せている。

マイクロパーティションとかいうsnowflake独自のデータを細かなメッシュで管理する構造ゆえにできる芸当らしい。

Variant型

JSONなどの半構造データを丸ごとブッ込めるデータ型。

当然、VarinatオブジェクトはSQLでパースして操作可能。

素敵

タイムトラベル

便利。undrop文とか素敵。