トップ / 基礎知識
コードはどこで実行されるのか。遅延評価とSQLへの変換・プッシュダウンの仕組みを説明します。
Snowpark DataFrameに対して select・filter・join のような変換メソッドを呼び出しても、その時点ではSnowflakeへリクエストは送られません。Snowflake公式ドキュメントは「DataFrameは、データを取得するために評価される必要のあるクエリのようなものである」と説明しており、変換メソッドは「SQL文の組み立て方を指定するだけで、Snowflakeデータベースからデータを取得しない」と明記しています。
呼び出された変換は、クライアント側で内部的な論理プラン（実行計画）として積み上がっていきます。この間、Snowflake側では何も処理が走っていません。
実際にSnowflake側で処理が走るのは、collect()・count()・show()・save_as_table() のようなアクションメソッドを呼んだ瞬間です。ここで初めて、それまで積み上げられた変換の内容がSQL文へと変換され、Snowflakeの分散クエリエンジン（Virtual Warehouse）に送信されて実行されます。
この「変換は溜める・アクションで初めて動く」という順序を知らないと、「select や filter を書いた時点で何かが実行されているはず」という誤った直感でコードを読んでしまい、パフォーマンス上のボトルネックがどこにあるかを見誤ります。
変換をSQLへまとめて変換してからSnowflakeへ送ることで、Snowflake側のクエリオプティマイザが変換全体を見渡して最適化できます。逐次的に1行ずつ処理を送るのではなく、まとまった単位で送ることで、データを不必要にクライアントへ転送せずに済み、ペタバイト規模のデータでも同じコードで処理できます。
公式ドキュメントの記載にもとづく解説です（実行検証はしていません）。確認日：2026-08-21