🐕
【Snowflake】コンピュートレイヤーと効率的なクエリ実行
このページは、親記事のうち、1.3節の内容です。
Snowflakeについてさらに学習したい方は、親記事から各ページをご参照ください。
1.4. コンピュートレイヤー
1.4.1. コンピュートレイヤーの役割
1.2.1. 3層アーキテクチャの各レイヤーの役割から転記
- コンピュートレイヤー
- 仮想ウェアハウス（あるいは、単に「ウェアハウス」）を使用してクエリを処理。
- ウェアハウスはコンピューティングリソースを他のウェアハウスと共有せず、各ウェアハウスで独立している。
1.4.2. ウェアハウス構造のイメージ
ウェアハウスは「コンピュートノード」の集合体で構成される。
ウェアハウスは、コンピュートノード（CPU、メモリ、SSD）の集合体の集合体。
- コンピュートノード＝ウェアハウスの最小単位
- クラスタ＝コンピュートノードの集合体
- XSサイズはノード1つ
- サイズを1段階上げるごとに、ノードの個数が倍になる
- ウェアハウス＝クラスタの集合体
- マルチクラスタウェアハウスであれば、複数クラスタで1つのウェアハウス
- 単一クラスタウェアハウスであれば、1つのクラスタで1つのウェアハウス
- たとえば、Mサイズで2クラスタのウェアハウスであれば、「4ノード持つクラスタが2つあるウェアハウス」という意味。
1.4.3. ウェアハウスのスケーリング
Snowflakeでは、クラウドの利点を活かして柔軟なスケーリングが可能。
| 種類 | 内容 | 効果 |
|---|---|---|
| スケールアップ | ウェアハウスサイズを大きくする | 単一クエリの処理速度向上 |
| スケールアウト | マルチクラスタウェアハウスでクラスタ数を増やす | 同時実行数の増加 |
1.4.4. 効率的なクエリ実行のために
より効率よくクエリを実行するために、コンピュートレイヤーの観点で2点考慮する
- データキャッシュの利用
- ウェアハウスを停止するまで、ウェアハウスのSSDにあるキャッシュを利用できる
- データキャッシュを利用するため、同じデータを利用するクエリは同じウェアハウスで実行するように設定するのがよい（損害／契約でウェアハウスを分けるなど）
- ウェアハウスの自動停止時間が長いと、データキャッシュを利用できる可能性は上がるが、コストはかかる
- 公式：データキャッシュの仕組み
- ステージからロードするファイルサイズ
- 大きいファイルは分割し、圧縮後のサイズで100MB～250MBに収める
- ファイルは分割しないと複数ノードでロードできない＆ノード1つ1つの性能はウェアハウスサイズに関係ないため、ウェアハウスサイズを大きくしても、単一ファイルのロードが早くなるわけではない
- 公式：ファイルサイズの推奨
Discussion