![[レポート] D-4 Snowflake クエリパフォーマンスチューニング入門 – Snowflake Data Cloud World Tour Tokyo – #SnowflakeDB](https://devio2023-media.developers.io/wp-content/uploads/2023/08/snowflake-data-cloud-world-tour-tokyo-2023_1200x630.jpg)
[レポート] D-4 Snowflake クエリパフォーマンスチューニング入門 – Snowflake Data Cloud World Tour Tokyo – #SnowflakeDB
2023年09月08日(金)、ANAインターコンチネンタル東京にて、Snowflake社による日本最大級のデータイベント「Snowflake Data Cloud World Tour Tokyo」が開催されました。
「Snowflake Data Cloud World Tour」と銘打っているように、このイベントは全世界3つのリージョン(APJ, Americas, EMEA)、26の都市で継続的に開催されています。東京での開催はその一環という訳ですね。
当エントリでは、イベント内のセッション『Snowflake クエリパフォーマンスチューニング入門』の参加レポートをお届けします。
目次
セッション概要
アジェンダに記載されているセッションの概要は以下の通りです。
・Snowflake クエリパフォーマンスチューニング入門
登壇者:
・Snowflake株式会社 Global Support Principal Cloud Support Engineer Yoshi Matsuzaki
セッションの説明:
Snowflake を最大限活用する上で、クエリのパフォーマンスを改善することはとても重要なアクティビティになります。
このセッションを通して、単独のクエリのパフォーマンスの改善方法から、複数クエリからなるワークロード全体のチューニングまで、単なる作業手順ではなく関連する技術や概念から理解することで、応用が効く形で体系的にアプローチできるようになります。
セッションレポート
イントロダクション
- どのようにこの『パフォーマンス問題』アプローチしていくか。
- ドリルダウン分析：『詳解システムパフォーマンス』という書籍で言及されている有名な手法。「モニタリング」「特定」「分析」のステップをを進めていく。
- Snowflakeでは、この分析における「モニタリング」の部分において価値を提供していく。ユーザーはその部分を活かし、「特定」「分析」のステップで頑張って頂く
- Snowflakeで提供するパフォーマンスデータは大きく3つ。最初はウェアハウスアクティビティ、ラフな情報から出発し段々と深掘りしていく流れ 【画像】
- 指標の特定はパフォーマンスのスコープごとに考えていく。
ワークロードのチューニング
- そもそも「ワークロード」って何？：複数のクエリの集まり。
- 大きいスコープからナローダウンしていく
- 仮想ウェアハウス全体(ウェアハウスアクティビティ)
- 複数のクエリ(QUERY_HISTORY)
- 個別のクエリ(クエリプロファイル)
- ウェアハウスアクティビティ
- Snowsight経由で見ることが出来る：単位時間あたりの各実行時間分類が占める割合を表示(任意の粒度における期間毎の情報を表示出来る)
- (注意)ただクエリ数が増えるだけでも値は大きくなる。見方としては「過去のトレンド(波形)と異なる(例えば1日前のと)かどうか」、「"待機中"分類の負荷があるかどうか」という観点が良い
- 特徴
- 簡単に見れるが粒度は粗い。
- 原因特定というよりもヒントとして見る
- 後述するQUERY_HISTORYビューやクエリプロファイルでの追加調査が必要となる(＝QUERY_HISTORYに慣れたらここはスキップしてもOK)
- QUERY_HISTORY
- 各クエリの実行時間分類や行数等の統計情報を見ることが出来るビュー情報
- 複数のクエリをまとめて確認出来る
- 確認ポイント
- 1.フィルタ(WHERE句)でワークロードの範囲を決定：何をもって1つのワークロードと定義するか。用意されている項目群から定義しておく
-
- 実行時間は処理行数の統計を取得
- 一番大事なのは「QUEUED_OVERLOAD_TIME」(仮想ウェアハウスの負荷が高くて実行出来なかった時間)。
- これが0より大きいとクエリ数が多過ぎてウェアハウスが過負荷に(並列度の問題)、少数の重いクエリがウェアハウスを専有している(個別クエリの問題)と見ることが出来る
- 「EXECUTION_TIME」の長いクエリがあるかどうかで判断。YESであれば個別クエリの問題、NOであれば並列度の問題(+軽微な個別クエリの問題)。
-
- 過去の同一ワークロードや類似ワークロードとの比較を行う
- 並列度の問題の場合：その他のメトリクスの統計を取り、同一/類似ワークロードを比較
- 統計に有意な変化があった場合：ワークロードに影響のある変更／変化はあったか？パフォーマンスは影響範囲内か？
- ワークロードが大きくなれば自然と実行時間も長くなる!=パフォーマンス問題
- 説明可能かつ許容範囲内であるかが重要なので、必要無いチューニングに工数を掛けるべきではない
- 各クエリの実行時間分類や行数等の統計情報を見ることが出来るビュー情報
対応策
- 個別のクエリの問題でない場合：仮想ウェアハウスのサイズを上げる/最大クラスタ数を増やす/複数の仮想ウェアハウス分散/クエリ数削減
- 選択パターン
- 仮想ウェアハウスサイズvsクラスター数
- 調整検討項目
- MAX_CONCURRENCY_LEVEL(仮想ウェアハウスのクラスター毎の並列度を決定)
- 同時実行クエリの制限 | Snowflake Documentation
- ただ、この数を引き上げることで有効になるケースはあんまりない(Snowlflake側としてもデフォルト値が最適だと見ている)
- 調整検討項目
- マルチクラスターウェアハウスvsウェアハウス分散
- マルチクラスターウェアハウスのメリット：一番は「オートスケーリングしてくれる」ところ
- 複数ウェアハウスのメリット：MAX_CONCURRENCY_LEVEL未満でも分散でき、新しいクラスタの起動時間を気にしなくて良くなる
- クエリの集約(クエリ数の削減)
- SnowflakeはOLAP向けデータベースであり、複雑・長時間のクエリを想定、クエリ毎のオーバーヘッドが大きい。このため、軽いクエリを投げれば投げる程損をする状態に
- INSERT処理に関しては行数に限らずほとんど実行時間が同じ(例：1件vs100万行でも)なので、COPYやBulk Insertを使って可能な限りまとめて処理
- 仮想ウェアハウスサイズvsクラスター数
ワークロードチューニングのまとめ
- 個別クエリの問題
- 仮想ウェアハウスサイズを上げる/さらに深掘り調査
- 並列度の問題
- 自動スケールさせたい：最大クラスター数を増やす
- きっちり分離したい：複数の仮想ウェアハウスで分散
- DMLが多い：クエリ数削減
個別のクエリのチューニング
- ワークロードのチューニングよりも範囲(スコープ)は狭い
- テーブルスキャン/結合/集約/フィルタなど、個別クエリの各処理が該当
- クエリプロファイルで問題のある処理を特定：Snowsightのアクティビティから見れる。仮想ウェアハウス上で実行される各処理の詳細が確認出来る
- 最近、上記画面経由に加えてSQLからもアクセス出来るようになった。(GET_QUERY_OPERATOR_STATS関数)
- 使い方
- クエリ全体から各処理にナローダウン
- 「最も負荷の高いノード」でボトルネックとなる処理を特定→ボトルネック対象の統計情報から原因を推測→原因に対する対応策の検討と適用
- 以下、よくあるボトルネックと対策方針
- テーブルスキャン：スキャン対象データを減らす
- パーティションプルーニング
- マイクロパーティションとデータクラスタリング | Snowflake Documentation
- WHERE句に該当する行を含み得るパーティション以外スキャンしない
- クラスタリング
- クラスタリングキーとクラスタ化されたテーブル | Snowflake Documentation
- マイクロパーティションをソートし直すことでプルーニング効率を改善
- 実はクラスタリング自体ににもコストは掛かる。改善によるクレジット減がクラスタリングのコストを上回る場合、コストよりも性能が重要な場合に検討すると良い
- WHERE句が無い場合プルーニング出来ない？→結合フィルタ(JoinFilter)によるプルーニング
- 結合爆発(Join Explosion)：
- 入力に対して出力が大きい結合
- 特殊な例として「OR条件」がある：結合キーでは無くクロス結合＋フィルタとして処理されてしまう
- 結合条件を見直す(等価条件を多く含める,OR条件はUNIONに変えるなど)、結合対象行を減らす(事前に適用出来る集約やフィルタを適用)などの対応が必要
- スピル(Spill)
- 結合や集約の一時データが、メモリが足りずに溢れ出している状態のことを言う。ディスクI/Oやクラウドストレージとの通信は遅いので問題となる
- 集約や結合の対象行数・対象カラム数を削減
- より大きな仮想ウェアハウスサイズを検討
- 結合や集約の一時データが、メモリが足りずに溢れ出している状態のことを言う。ディスクI/Oやクラウドストレージとの通信は遅いので問題となる
- 結果生成
- Snowflakeでは、サイズの大きいクエリ結果はリモートストレージ(S3)に書き出される。なので、圧縮や書き出し処理に時間が掛かる
- 本当にその巨大な結果が必要なのかを確認。適切な集約・フィルタを追加する等の対応が必要。特にPoCでは「SELECT *」では無く、実際のクエリを使おう
それでも解決しないときは...？
- Snowflake Supportに相談。
まとめ
という訳で、Snowflake: Data Cloud World Tour Tokyo ブレイクアウトセッション『Snowflake クエリパフォーマンスチューニング入門』の参加レポートでした。30分という短い時間の中ではありましたが、パフォーマンス改善の大筋をつける手順が分かりやすく紹介されていた印象でした。最終手段としてSnowflake Supportを(クエリパフォーマンス改善にも)活用出来るというのはSnowflakeユーザーとしても嬉しい限りですね。
![[新機能]dbtのdata testで任意の設定をconfigで指定できるようになり、各data testでSnowflakeのウェアハウスを指定できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f846b6052d1f7b983172226c6b1ed44b/6b4729aabfb5b7a3359acc27dc6b5453/dbt-1200x630-1.jpg)
