超ざっくりマイクロパーティション紹介

本記事は、Snowflake Advent Calendar 2022 の 12 日目です。

はじめに

Snowflakeのアーキテクチャの中でも、最も特徴的なアイディアの一つであるマイクロパーティションについて、知らない人向けにイラスト多めで紹介します。また、関連の深いタイムトラベル、ゼロコピークローンにも触れます。
初めての記事投稿なので、温かい目で見守っていただけると幸いです。

以下ご了承ください。

• 2022年11月時点の情報に基づきます。最新の情報は公式ドキュメントをご参照ください
• 分かり易さのためにディフォルメしています。正確な情報は公式ドキュメントをご参照ください
• 記事の内容は個人的な見解であり、所属組織を代表するものではありません

Snowflakeのアーキテクチャのおさらい

Snowflakeのアーキテクチャは、3層構造で説明されます。

• クラウドサービス層
• コンピュート層
• ストレージ層

こちらの同心円の図を見たことある方多いかと思います。（最近、公式ではあまし見かけない気がしないでもない）

引用： S-1 Snowflake Inc. p.84

個人的に、この図は少しばかり伝わり難い気がしてて、自分で描いてみたのが下図になります。（めっちゃ僭越ですみません・・）

図：Snowflakeのアーキテクチャの理解

３層の概要は以下の通り。

• クラウドサービス層

  • 全体の司令塔
  • すべてのリクエストを窓口として引き受け、認証・権限制御・メタデータ確認・クエリコンパイルなどして、コンピュート層に処理を渡します
  • キャッシュやメタデータで答えられるクエリは、コンピュート層を呼ばずに済ませます

• コンピュート層

  • クラウドサービスの指示を受け、ストレージから必要なデータを取ってきて処理する仮想コンピュータで、VirtualWareHouse（VWH）と呼ばれます
  • ストレージと独立しており、データ保管は担いません（キャッシュはしますが）。すなわち、「データ容量が大きくなることで、ストレージ管理のために性能を上げないといけない」といったことがありません
  • 単体処理性能を上げるスケールアップ：XS～6XL（10段階）と、複数同時性能を上げるスケールアウト：1～10クラスタを自由に設定できます。これを、無停止でいつでも自由に変更が可能なのも素晴らしいところです！

• ストレージ層

  • データの実体であり、パブリッククラウドのオブジェクトストレージ（AWSだとS3）に、「マイクロパーティション」 と呼ばれる小規模なファイル群として保管されます。
  • コンピュートと独立しており、データの置き場所は１ヶ所です。すなわち、「クラスタ数を増やすために、ストレージをクラスタに分散配置しないといけない」といったことがありません
  • 構造化データだけでなく、半構造化データも扱うことができます

本記事は、このストレージ層のマイクロパーティションが主役になります。

ざっくりマイクロパーティション

Snowflakeでは、テーブルのデータはマイクロパーティションに分割されて保管されます。言い換えると、テーブルは「マイクロパーティションの集合」とも言えます。
マイクロパーティションの特徴を列挙します。

• パブリッククラウドのオブジェクトストレージに実装
  • イミュータブル（不変）
  • 容量無制限
  • ディスク障害対策のバックアップが実質不要
• 圧縮ファイルで保管される
  • マイクロパーティション１個の容量は、圧縮ファイルで約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のサポートに対応依頼が必要になります。

ざっくりゼロコピークローン

マイクロパーティションのもう一つの特徴的な使い方に、ゼロコピークローンがあります。
クラウドサービスで、テーブルとその実体であるマイクロパーティション群の「紐づけ」が管理されています。ということは、クラウドサービス上で（論理的に）テーブルを追加して、それに対し既存テーブルのマイクロパーティション群を丸ごと紐づければ、物理的なファイルコピーなしで、テーブル全体をコピーすることができます。これがゼロコピークローンです。

図：　ゼロコピークローンのイメージ

ゼロコピークローンされた元テーブルと複製テーブルは、以降は独立した存在として、お互いに影響を受けることなく更新可能です。それぞれの「紐づけ」において、それぞれの更新に応じてパーティションを追加・削除していくからです。

図：　ゼロコピークローン後にそれぞれを更新したイメージ

ゼロコピークローン直後は、元テーブルと複製テーブルの２つが存在していても、ストレージ容量は増えていないので、ストレージ課金は倍にはなりません。
その後も、クローンしたときからどちらも変更していないパーティションは、共用が続くことになります。元テーブルと複製テーブルの両方で現役でなくなったとき、そのパーティションは本当に引退したことになり、そこからタイムトラベル期間＋7日間後に物理削除されることになります。

ゼロコピークローンは、機械学習などのためにに「毎月のデータ断面を残しておきたい」といったユースケースと相性がよいかと思います。テーブル全体の複製を何面作ったとしても、変化してないパーティションはストレージ容量が増えないためです。（当然、既存レコードが頻繁に更新されるデータセットでは、この効果が薄くなります）

おわりに

本記事では、マイクロパーティションの概要と、それを利用することで、Snowflakeが自然な形で「タイムトラベル」と「ゼロコピークローン」という魅力的な機能を実現していることについて紹介しました。
マイクロパーティションについてはこの先にもっと学ぶべきことがありますが、まずはSnowflakeを知らない方や初学者の方に、興味を持ってもらえたら嬉しいです。

最後まで読んでいただき、ありがとうございました！　みなさまよいお年を！