超ざっくりマイクロパーティション紹介
本記事は、Snowflake Advent Calendar 2022 の 12 日目です。
はじめに
Snowflakeのアーキテクチャの中でも、最も特徴的なアイディアの一つであるマイクロパーティションについて、知らない人向けにイラスト多めで紹介します。また、関連の深いタイムトラベル、ゼロコピークローンにも触れます。
初めての記事投稿なので、温かい目で見守っていただけると幸いです。
Snowflakeのアーキテクチャのおさらい
Snowflakeのアーキテクチャは、3層構造で説明されます。
- クラウドサービス層
- コンピュート層
- ストレージ層
こちらの同心円の図を見たことある方多いかと思います。(最近、公式ではあまし見かけない気がしないでもない)
引用: S-1 Snowflake Inc. p.84
個人的に、この図は少しばかり伝わり難い気がしてて、自分で描いてみたのが下図になります。(めっちゃ僭越ですみません・・)
図:Snowflakeのアーキテクチャの理解
3層の概要は以下の通り。
-
クラウドサービス層
- 全体の司令塔
- すべてのリクエストを窓口として引き受け、認証・権限制御・メタデータ確認・クエリコンパイルなどして、コンピュート層に処理を渡します
- キャッシュやメタデータで答えられるクエリは、コンピュート層を呼ばずに済ませます
-
コンピュート層
- クラウドサービスの指示を受け、ストレージから必要なデータを取ってきて処理する仮想コンピュータで、VirtualWareHouse(VWH)と呼ばれます
- ストレージと独立しており、データ保管は担いません(キャッシュはしますが)。すなわち、「データ容量が大きくなることで、ストレージ管理のために性能を上げないといけない」といったことがありません
- 単体処理性能を上げるスケールアップ:XS~6XL(10段階)と、複数同時性能を上げるスケールアウト:1~10クラスタを自由に設定できます。これを、無停止でいつでも自由に変更が可能なのも素晴らしいところです!
-
ストレージ層
- データの実体であり、パブリッククラウドのオブジェクトストレージ(AWSだとS3)に、「マイクロパーティション」 と呼ばれる小規模なファイル群として保管されます。
- コンピュートと独立しており、データの置き場所は1ヶ所です。すなわち、「クラスタ数を増やすために、ストレージをクラスタに分散配置しないといけない」といったことがありません
- 構造化データだけでなく、半構造化データも扱うことができます
本記事は、このストレージ層のマイクロパーティションが主役になります。
ざっくりマイクロパーティション
Snowflakeでは、テーブルのデータはマイクロパーティションに分割されて保管されます。言い換えると、テーブルは「マイクロパーティションの集合」とも言えます。
マイクロパーティションの特徴を列挙します。
- パブリッククラウドのオブジェクトストレージに実装
- イミュータブル(不変)
- 容量無制限
- ディスク障害対策のバックアップが実質不要
- 圧縮ファイルで保管される
- マイクロパーティション1個の容量は、圧縮ファイルで約16M(最大)
- データの内容・そのときの圧縮技術によるが、圧縮前ファイルサイズはおよそ50~500M
- レコードの束が収納される
- 収納されたレコードの列はすべて、そのマイクロパーティションに入る
- マイクロパーティションの中では、列指向で編成される
- マイクロパーティション毎に、レコード数、各列の最大値・最小値・カーディナリティなどが作成時に集計され、メタデータとして管理される
イミュータブル(不変)であるということは、既存マイクロパーティションに格納されたレコードが変更・削除されたとき、そのマイクロパーティションに対する「更新」は行われません。代わりに、更新後状態の新マイクロパーティションが作成されて、クラウドサービスは以後はそちらを「現役」として見るようにコントロールします。
図: マイクロパーティションのデータ更新のイメージ
このとき、更新前状態の「引退」マイクロパーティションはすぐには消されず、定められた期間、残存します。これが、タイムトラベルの基盤となります。
ざっくりタイムトラベル
データ更新が積み重なると、その分だけ引退パーティションが溜まっていきます。Snowflakeは、スタンダードエディションでは1日間、エンタープライズエディション以上ではパラメータ設定により1~最大90日間まで、引退パーティションは消されずに残ります。
ある時点のテーブルは「その時点に現役のマイクロパーティションの集合」なわけですから、クラウドサービスの持つ現役・引退の履歴と、引退パーティションが残っていれば、過去時点のテーブルを再現可能なわけです。これが、タイムトラベルです。
- タイムトラベルのクエリの例: at句で過去日時を指定
select * from TableA at (timestamp => to_timestamp_tz('2022-12-12 07:00:00'));
図: タイムトラベルのイメージ
また、undrop table はタイムトラベルの一種と言えます。drop table は、当該テーブルの現役パーティションを全部一斉に引退させることなので、クラウドサービスが全部一斉に現役復帰させれば(drop直前にタイムトラベルするのと同意)、テーブルまるごとを復活できるわけです。
ちなみに、実際にパーティションのファイルが物理的に消えるのは、タイムトラベル期間(1~90日間)が経過した後、さらに7日後になります。この最後の7日間はユーザからはアクセス不可で、Snowflakeのサポートに対応依頼が必要になります。
ざっくりゼロコピークローン
マイクロパーティションのもう一つの特徴的な使い方に、ゼロコピークローンがあります。
クラウドサービスで、テーブルとその実体であるマイクロパーティション群の「紐づけ」が管理されています。ということは、クラウドサービス上で(論理的に)テーブルを追加して、それに対し既存テーブルのマイクロパーティション群を丸ごと紐づければ、物理的なファイルコピーなしで、テーブル全体をコピーすることができます。これがゼロコピークローンです。
図: ゼロコピークローンのイメージ
ゼロコピークローンされた元テーブルと複製テーブルは、以降は独立した存在として、お互いに影響を受けることなく更新可能です。それぞれの「紐づけ」において、それぞれの更新に応じてパーティションを追加・削除していくからです。
図: ゼロコピークローン後にそれぞれを更新したイメージ
ゼロコピークローン直後は、元テーブルと複製テーブルの2つが存在していても、ストレージ容量は増えていないので、ストレージ課金は倍にはなりません。
その後も、クローンしたときからどちらも変更していないパーティションは、共用が続くことになります。元テーブルと複製テーブルの両方で現役でなくなったとき、そのパーティションは本当に引退したことになり、そこからタイムトラベル期間+7日間後に物理削除されることになります。
ゼロコピークローンは、機械学習などのためにに「毎月のデータ断面を残しておきたい」といったユースケースと相性がよいかと思います。テーブル全体の複製を何面作ったとしても、変化してないパーティションはストレージ容量が増えないためです。(当然、既存レコードが頻繁に更新されるデータセットでは、この効果が薄くなります)
おわりに
本記事では、マイクロパーティションの概要と、それを利用することで、Snowflakeが自然な形で「タイムトラベル」と「ゼロコピークローン」という魅力的な機能を実現していることについて紹介しました。
マイクロパーティションについてはこの先にもっと学ぶべきことがありますが、まずはSnowflakeを知らない方や初学者の方に、興味を持ってもらえたら嬉しいです。
最後まで読んでいただき、ありがとうございました! みなさまよいお年を!
![Snowflake Data Heroes](https://storage.googleapis.com/zenn-user-upload/avatar/5141da5e55.jpeg)
Snowlfake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd
Discussion