❄️

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

2022/12/11に公開約4,500字

本記事は、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を知らない方や初学者の方に、興味を持ってもらえたら嬉しいです。

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

Discussion

ログインするとコメントできます