SnowPro Core資格への道 ~Part14：キャッシュ~
はじめに
9月のSnowflake World Tour TokyoまでにSnowPro Coreをとります！
試験を8月28日(木)に受けようと思います。あと25日。
ですが諸事情により、もう少し早める可能性が出てきました。
2周目第5回は67％、第6回が68％と似たようなギリギリアウトの正答率です。
調べずに自分でテストモードでこの正答率なので、まだ定着していないなぁと実感。
あと1周＋見直しアウトプット量を増やすことにします。
現在こちらのUdemyの問題を解いています。
Snowflake SnowPro Core Certification Practice Tests COF-C02
今日の話題はキャッシュになります。
キャッシュにもいろいろ種類がありますが、
- クエリ結果キャッシュ
- メタデータキャッシュ
- ウェアハウスキャッシュ
の3種類について復習しようかなと思います。
クエリ結果キャッシュ
検索最適化サービスを使用すると、フィルタリングに多くの述語を使用する一部の検索クエリや分析クエリのパフォーマンスを大幅に向上できます。
検索最適化サービスは、永続的なデータ構造を最適化された検索アクセス パスとして使用して、ポイントの検索を高速化します。
USE_CACHED_RESULT を使ってクエリ結果キャッシュの無効化ができます。
ストレージコストの算出において、キャッシュは考慮されません。
クエリ結果キャッシュはクラウドサービスレイヤーで実行されます。
上記の画像のように、クエリ結果キャッシュは別の人が実行ユーザーと同じロールを持っていれば実行可能ということになります。
クエリ結果キャッシュは更新されない限り、24時間で消去されます。最大で31日まで延長可能です。
メタデータキャッシュ
メタデータキャッシュとは、Snowflakeがテーブル内の実データそのものではなく、データに関する情報（メタデータ）を保持しているキャッシュ層のことです。このキャッシュは、仮想ウェアハウス（コンピューティングリソース）とは独立したクラウドサービスレイヤーで管理されています。
メタデータキャッシュについては、クラウドサービスレイヤーと関連するということで、過去記事を参照ください。
ウェアハウスキャッシュ
ウェアハウスキャッシュ（またはローカルディスクキャッシュ）は、クエリ実行時にリモートストレージから読み込まれたテーブルデータを、仮想ウェアハウスのSSDに一時的に保持する仕組みです。
一度読み込まれたデータがキャッシュに乗っていれば、次回以降のクエリでは低速なリモートストレージにアクセスすることなく、高速なローカルSSDからデータを読み取ることができます。これにより、特に大規模なテーブルを繰り返しスキャンするようなクエリのパフォーマンスが劇的に向上します。
重要なポイント
- ウェアハウスに紐づく: このキャッシュは仮想ウェアハウスごとに保持されます。ウェアハウスが異なれば、キャッシュも異なります。
- ウェアハウスの中断で破棄: 仮想ウェアハウスが中断（Suspend）されると、保持されていたキャッシュは破棄されてしまいます。再度ウェアハウスが再開（Resume）したとき、キャッシュは空の状態から始まります。
キャッシュと自動中断の最適な関係
ウェアハウスキャッシュを最大限に活用するには、「自動中断（Auto Suspend）」の設定が非常に重要になります。キャッシュの恩恵を受けたいのに、クエリの合間にウェアハウスがすぐに中断してしまっては意味がありません。
ユースケースに応じて、自動中断の時間を調整することが推奨されています。
| 用途 | 推奨される自動中断時間 | 理由 |
|---|---|---|
| タスク (Tasks) | 即時 | タスクは定期的・独立的に実行されるため、キャッシュを維持する必要性が低い。 |
| DevOps / DataOps / データサイエンス | 約5分 | アドホックでユニークなクエリが多く、キャッシュの重要性が中程度のため。 |
| BIツール / 定型クエリ | 少なくとも10分 | ユーザーが繰り返し同じような分析を行うため、キャッシュを維持する価値が高い。 |
コストを意識して自動中断を短く設定しすぎると、かえってクエリパフォーマンスが悪化し、ユーザー体験を損なう可能性があります。コストとパフォーマンスのトレードオフを考慮した設定が重要です。
キャッシュの効果を確認する方法
自分のウェアハウスでキャッシュがどれくらい効いているのかは、以下のクエリで確認できます。
QUERY_HISTORYビューを参照し、ウェアハウスごとにキャッシュからスキャンされたデータの割合（PERCENTAGE_SCANNED_FROM_CACHE）を算出します。
select
warehouse_name,
count(*) as query_count,
avg(percentage_scanned_from_cache) as avg_percentage_scanned_from_cache
from
snowflake.account_usage.query_history
where
start_time >= dateadd(day, -7, current_timestamp()) -- 過去7日間を対象
and warehouse_name is not null
group by
1
order by
3;
このクエリ結果でavg_percentage_scanned_from_cacheの値が低いウェアハウスは、キャッシュの恩恵をあまり受けられていない可能性があります。その場合は、自動中断の設定時間を見直すことで、パフォーマンスが向上するかもしれません。
ちなみに、私のSnowflake Trial環境で実行してみたらこんな感じでした。
Discussion