Snowflake のクラスタリングキー検証における注意点

Snowflake では非常に大きなテーブルなどで適切にマイクロパーティションが構成されなくなった場合に、明示的にクラスタリングキーを指定することができます。
基本的な考え方はドキュメントにあるので、直面した問題点と役立ちそうな考え方をメモがてらいくつか紹介します。

テーブルが未クラスタリング状態の場合 system$clustering_information は(現時点では)参考にしない方が良い

この引数を使用して、テーブルにクラスタリングキーが定義されているかどうかに関係なく、テーブル内の任意の列のクラスタリング情報を返すことができます。
つまり、これを使用して、将来使用するクラスタリングを決定できます。
-- https://docs.snowflake.com/ja/sql-reference/functions/system_clustering_information.html

とありますが、2020年の10月末にサポートに確認をしたところ、クラスタリングされていないテーブルでは system$clustering_information やその関連関数は正しい結果を返すことができないという回答をもらいました。
つまり、未クラスタリングのテーブル t について、クラスタリングキー (trunc(item_id, -3), to_date(ts)) を検討している場合に、 select system$clustering_information('t', '(trunc(item_id, -3), to_date(ts))') の結果を参考にクラスタリングキーとして設定すべきかどうかは判断しない方が良いということになります。

clone テーブルはクラスタリングキー設定後に使用ストレージが増加する

上記の件もあり、実際にクラスタリングキーを設定して検証することにした流れで分かったことです。
元テーブルに影響を与えないために create temporary table ... clone ... などで一時テーブルを作成してそこにクラスタリングキーを設定して検証する方針にしました。
クローンについてはドキュメントに

データベース、スキーマ、およびテーブルの場合、クローンは、既存のデータを変更する、または新しいデータを追加する操作がクローンで実行されるまで、オブジェクトのデータストレージ全体に寄与 しません。

とある通り、データストレージが増加しないのですが、クラスタリングについてはキーを貼る=既存のデータを変更するということになるようです。
およそ2倍のストレージになるので、テーブル規模次第では金額に気をつける必要がありそうです。

再クラスタリングはすぐに実施されるわけではない

こちらはドキュメントにもある通り、再クラスタリングはクラスタリングキー設定後すぐに実施されるわけではないので注意が必要です。
どういうことかと言うと、クラスタリングキーを設定したからといって、直後にクエリパフォーマンスが向上したり、system$clustering_information が大きく異なる結果を返すことはない、ということです。

再クラスタリングの進捗状況はおそらく AUTOMATIC_CLUSTERING_HISTORY テーブルで見るしかないので、ある程度再クラスタリングが実施され落ち着いたと判断したタイミングでクエリパフォーマンスの検証や、system$clustering_information の確認をするのがベストです。

簡単に思いついたものをいくつか載せてみました :)