Snowflakeの不思議・マイクロパーティションがもたらす柔軟性〜ゼロコピークローンのストレージは０？クラスター化したら一体どうなるの？

もう開発環境の構築などに頭を悩ますことのない、Snowflakeの画期的な機能ゼロコピークローンについて見てきました。最終回です。

ゼロコピークローンは複製したかのようにコピー元のデータの変化に影響を受けず、独立した道を歩み始めるわけですが、そのくせ本当にデータをコピーしているわけではないのでデータのストレージ容量を食いません。

その秘密はSnowflakeのデータがマイクロパーティションという小さなパーティションで自動的にデータが格納されているからなのです。

Snowflakeの特徴としてコンピュートリソースとストレージが分離しているんだよとか、ワークロードを分離できるんだよとか、分離できる系がよく取り沙汰されますし実際その通りではありますが、そん分離して効率よく動かすことのできるアーキテクチャの根幹は実はこのマイクロパーティションなんですね。

データをSnowflakeに入れるとき、データはすべてマイクロパーティションという小さなパーティションに分けて入れられていきます。つぶつぶがいっぱい入っている姿でもイメージしていただくといいと思います。Snowflakeのテーブルはたくさんつぶつぶの集まりによって構成されているのです。

そしてこのマイクロパーティションは不変（Immutable）であり、上書きされることがないんですね。

上書きされるとどうなるかというとその分だけ新しいマイクロパーティションが作られて、上書きされた分の古いマイクロパーティションが捨てられていきます。

ゼロコピークローンが何をしているかというと、クローンを作成した時点のクローン元のテーブルのマイクロパーティションを見にいく枠だけを作成するのです。だから、データ自体はコピーされない。
前回の記事でクローン元のテーブルにどれだけ変化を加えても影響がない姿を見てもらったと思いますが、作成するときはあるマイクロパーティションを指しにいくポインターだけを複製しましたが、元テーブルがそのマイクロパーティションを見に行かなくなったとしても、名前が変わったとしても、クローンされたときのままのマイクロパーティションを引き続き見続けているので、特に何も影響が起こらないわけですね。
というわけで、クローンされたテーブルは、最初に作成された元テーブル自体のデータが変化したとすると、変化する前の分のストレージ量だけをクローンのために使用する、何も変化がなければストレージは使わない、ということがわかります。

実際にその様子をSNOWFLAKEデータベース内ACCOUNT_USAGE.TABLESテーブルで確認してみましょう。

ソーステーブルであるTRIPSテーブルとそのクローンであるTRIPS_DEVテーブルは全く同じバイト数であることを示していて、間違いなく同じテーブルが複製されているように見えます。しかしこれはテーブルの大きさを示しているだけで実際のストレージ容量を示しているものではありません。

実際のストレージ容量を確認するにはSNOWFLAKEデータベース内ACCOUNT_USAGE.TABLE_STORAGE_METRICSテーブルを参照します。

するとTRIPSではテーブルサイズと同じである1763667456 BYTES消費していますが、TRIPS_DEVは0 BYTESの消費であることがわかりました。

このマイクロパーティションは元々入ってきた順に構成されるもので、基本的にはその順で高速に動くはずなのであまり意識しなくてもいいのですが、稀に入ってきた順でない項目でマイクロパーティションを構成した方がパフォーマンスがよくなるケースがあり、マイクロパーティションを再構成することができます。
これをクラスター化と呼んでいます。このネタはこれはこれで別記事にまとめたいと思いますが、ここでお伝えしたいのは、クローンテーブルをクラスターかするとどうなってしまうのか？ということです。

元のテーブルは入ってきた順のマイクロパーティション、クローンテーブルは別のキーでマイクロパーティションを再構成する…となった場合は、同じデータを見ているようでもマイクロパーティションを再構成するので、それぞれにストレージ量がかかります。

TRIPS_CLUSTEREDテーブルはクローンした後クラスターキーを設定したテーブルです。（TRIPSはデモで頻繁に使うため、TRIPS_DEVを作った後に再度作り直してしまったので若干バイト数が違うのはご容赦ください）

TRIPS_CLUSTEREDはACTIVE_BYTESを消費しているのがわかります。このように、同じ値でもマイクロパーティションを再構成するクラスターキーを付加すると、裏側で全マイクロパーティションが作り直しになるので、通常のように変化した分だけのストレージ量とならない点は気をつけておきましょう。

まあ、通常は本体のテーブルをクラスター化してそれをクローンする方が多いと思いますが…
ただし、開発用にクローンしてクラスター化した検証したテーブルをそのまま放置していたりするとストレージ料金が余計にかかってしまうので気をつけたいですね。

それでは冬のクローンシリーズはこちらで終えたいと思います。