データ基盤

Snowflake マイクロパーティションとは？プルーニングとクラスタリング

2026/10/26 （更新: 2026/11/3）シリーズ「Snowflake 入門」第4回 / 全13回

🤖 AIを使用して執筆

シリーズSnowflake 入門全13回

このシリーズの紹介へシリーズ一覧へ

マイクロパーティション
プルーニング
クラスタリングキー
Snowflake
クラスタリング
自動クラスタリング
クラスタリングの深さ
再クラスタリング
メタデータ
Optima Clustering
Clustering Classic
Partitions scanned
パーティション
EXPLAIN
Query Profile
カーディナリティ
データ基盤
データ
費用
日付
条件
自動
クレジット
保存
利用者
type
保守
平均
ウェアハウス
圧縮前
最大
最小
行目
計算
タイムスタンプ
ファイル
GB
MB
処理
単位
実行
見積
請求
論文
Fail-safe
DELETE
SELECT
SYSTEM
UPDATE
MERGE
クラスタ
理想的
TB
f2
上限
位置
全行
出力
割合
効率
単価
回数
圧縮
情報
時刻
時間
番号
目安
種類
管理
設定
追加
限界

背景・問い・要点

背景

Snowflake は、表のデータを自動で小さなまとまりに分けて保存する。このまとまりを、Snowflake ではマイクロパーティションという¹。

問い合わせを速く、安くする基本の一つは、読むデータを減らすことである。Snowflake は、問い合わせの条件に合わないマイクロパーティションを、読む前に飛ばす。これをプルーニング（刈り込み）という¹。

どのマイクロパーティションを飛ばせるかは、データがどの順に並んでいるかに大きく左右される。並び方を利用者が指定するのが、クラスタリングキーである²。

問い

Snowflake のマイクロパーティションとは何で、Snowflake はそれを使って読むデータをどう減らすのか。

要点

マイクロパーティションは、Snowflake が表のデータを自動で分けて持つ、圧縮前で 50〜500 MB の単位である。Snowflake は各マイクロパーティションの列ごとの値の範囲を持ち、問い合わせの条件に合わないものを読まずに飛ばす。

データは入った順に分かれるので、問い合わせの条件がデータの入る順と関係のある列にかかるなら、設定なしでもこの読み飛ばし（プルーニング）が効く。条件がその順と関係のない列にかかる大きな表なら、利用者はクラスタリングキーで並べ直せるが、キーがあるあいだ自動クラスタリングがクレジットを使い続ける。プルーニングの効きは、利用者が、問い合わせが読んだマイクロパーティションの数と全体の数の比で確かめる。

モデル・例示

24 行の表で、読むマイクロパーティションを数える

マイクロパーティションごとの値の範囲で、問い合わせがどれを読み、どれを飛ばすかが決まる。並びを変えると、読む数が変わる。24 行の小さな表でも、日付と type でキーを付けると、同じ問い合わせが読むマイクロパーティションは 3 つから 1 つに減る¹²。24 行・4 列（type・name・country・date）の表 t1 を考え、24 行が 6 行ずつ 4 つのマイクロパーティションに分かれているとする。日付は、入った順におおむね並んでいる²。マイクロパーティションごとの日付の範囲は、次のとおりである¹。

マイクロパーティション	日付の範囲（最小〜最大）
1（1〜6 行目）	11/2〜11/2
2（7〜12 行目）	11/2〜11/3
3（13〜18 行目）	11/2〜11/4
4（19〜24 行目）	11/3〜11/5

この表に、次の問い合わせを流す²。

SELECT name, country FROM t1 WHERE type = 2 AND date = '11/2';

Snowflake は、各マイクロパーティションの日付の最小と最大を見て、11/2 を含みうるものだけを読む。マイクロパーティション 4 は最小が 11/3 なので、読まずに飛ばせる。1・2・3 は 11/2 を含みうるので、3 つとも読む²。

そこで、日付と type でクラスタリングキーを付ける²。

ALTER TABLE t1 CLUSTER BY (date, type);

クラスタリングキーに従って並べ直すこと（再クラスタリング）で、新しいマイクロパーティション 5〜8 ができ、古い 1〜4 は削除済みの扱いになる²。新しいマイクロパーティション 5 には、type が 2 で日付が 11/2 の 6 行が集まる²。6 も日付はすべて 11/2 だが、type が 3 か 4 なので type が 2 の行を含まず、飛ばせる。そのため、同じ問い合わせが読むのは 5 だけになる²。

読むマイクロパーティションは 3 つから 1 つに減った。実際のマイクロパーティションは、1 つが圧縮前で 50〜500 MB あるので、24 行の表なら全行が 1 つのマイクロパーティションに入る。この例は仕組みを見せるためのもので、Snowflake がクラスタリングキーを勧めるのは、たいていは数 TB の大きな表である¹²。

マイクロパーティション：自動で分けて、列ごとに持つ

マイクロパーティションは、圧縮する前で 50〜500 MB のデータを持つ保存の単位である。行のまとまりを一つのマイクロパーティションに入れ、その中は列ごとに分けて持つ¹。

従来のデータウェアハウスは、大きな表を静的なパーティションに分けて速さを保つ。パーティションは、利用者が専用の DDL（Data Definition Language、表の定義を扱う命令）で管理する単位である。保守の手間がかかり、データの偏りでパーティションの大きさがばらつく、という限界が知られている¹。マイクロパーティションは、この限界を避けるよう作られている¹。

分け方： すべての表で自動で行われ、データが入った（読み込まれた）順に分かれる。利用者が前もって決めたり、管理したりする必要はない¹。
大きさ： 小さいので、データの変更（DELETE・UPDATE・MERGE など）が効率よく、細かくプルーニングできる。値の範囲が重なってもよく、大きさがそろっているので、偏りが起きにくい¹。
列ごとの持ち方： 列は、マイクロパーティションの中で別々に持つ（列指向の保存）。問い合わせが使う列だけを読む。列ごとに、Snowflake が最も効率のよい圧縮の方式を選ぶ¹。
持つ情報（メタデータ）： 各列の値の範囲、異なる値の数、最適化と処理のためのそのほかの情報¹。

データの変更も、このメタデータを使う。表の全行を消すような操作は、メタデータだけを書き換えて済む¹。列を消しても、その列を持つマイクロパーティションはその場では書き直されず、列のデータは保存されたままになる¹。

Snowflake の開発者が 2016 年に発表した論文（Dageville ほか）は、表を行のまとまりごとに、書き換えないファイルに分けて持つと書いている³。

プルーニング：値の範囲で読まずに飛ばす

Snowflake は、問い合わせの条件と、各マイクロパーティションの値の範囲を比べ、条件に合う値を持ちえないものを読まない¹。論文は、この方法を「最小・最大によるプルーニング」と呼び、ファイルを例に挙げている。ある列の値がファイル f1 で 3〜5、f2 で 4〜6 なら、WHERE x >= 6 の問い合わせが読む必要があるのは f2 だけである³。

Snowflake は、プルーニングがうまく効いたときの目安を示している¹。

値の範囲の 10% に当たる条件なら、理想的にはマイクロパーティションの 10% だけを読む。
1 年分のデータが日付と時刻で均等に入っているなら、ある 1 時間を指定した問い合わせは、理想的には 8,760 分の 1 だけを読む。

プルーニングは二段で行われる。まず要らないマイクロパーティションを飛ばし、残ったマイクロパーティションの中で、要らない列を飛ばす¹。ただし、条件に副問い合わせ（SELECT の中の SELECT）を使うと、その結果が一つの値でも、マイクロパーティションは飛ばされない¹。

論文は、プルーニングが Snowflake の設計の原則に合うと書いた。利用者の入力に頼らず、大きくなってもうまく動き、保守がやさしいからである。索引を利用者に作らせる方法は、純粋なサービスという Snowflake の考え方に反するとも書いている³。

並びが崩れると、範囲が重なる

日付のように、データが入る順に増えていく列は、何もしなくても並んでいる。Snowflake は、こうした表を、日付で自然にクラスタ化されている（naturally clustered）と書く²。時系列でたまる表なら、日付やタイムスタンプ、増えていく番号は入った順に並ぶので、設定なしにプルーニングが効く。

Snowflake は、プルーニングが効くには、データの保存の順が問い合わせの条件の列と関係している必要があるとしている⁴。たとえば店の番号や商品の種類のように、入る順と関係のない列は、多くのマイクロパーティションにいろいろな値が入りやすく、値の範囲が重なりやすい。範囲が重なると、飛ばせるマイクロパーティションが減る。データの変更（INSERT・UPDATE・DELETE・MERGE・COPY）が重なると、並びが崩れることもある²。

並びの度合いは、クラスタリングの深さで測る。ある列のある値の位置で、値の範囲が重なり合うマイクロパーティションの数を深さという。表全体の深さは、マイクロパーティションごとの重なりの深さの平均で、空でない表では 1 以上の値をとり、小さいほどよく並んでいる¹⁵。Snowflake は、5 つのマイクロパーティションに A〜Z の値が入る概念の図で、重なりと深さの関係を示している。次の表の深さは、平均ではなく、範囲が最も多く重なる位置での重なりの数である¹。

5 つの値の範囲	重なりの深さ
A〜Z が 5 つ	5
A〜D、E〜J、K〜Z が 3 つ	3
A〜D、E〜J、K〜N、L〜S、Q〜Z	2
A〜D、E〜J、K〜N、O〜S、T〜Z	1

深さは関数で調べられる。SYSTEM$CLUSTERING_INFORMATION は、指定した列について、マイクロパーティションの数、平均の重なりの数（average_overlaps）、平均の深さ（average_depth）などを返す⁵。たとえば、次のような出力が返る（一部）⁵。

"cluster_by_keys" : "LINEAR(COL1, COL3)",
"version" : "CLASSIC",
"total_partition_count" : 1156,
"average_overlaps" : 117.5484,
"average_depth" : 64.0701,

よく並んだ表では、深さは 1 に近い。この出力では、1,156 のマイクロパーティションの重なりの深さが平均で 64 あり、よく並んでいない⁵。ただし Snowflake は、表がどれだけよく並んでいるかの最もよい目安は、結局は問い合わせの速さだとしている¹。

クラスタリングキーを付ける：どんな表に

クラスタリングキーは、表の中の値を同じマイクロパーティションに集めるために指定する列（または式）である。キーを付けた表を、クラスタ化された表という²。一つのクラスタリングキーには、複数の列や式を入れられる²。

Snowflake は、次の条件をすべて満たす表に付けるよう勧めている²。

マイクロパーティションが多い。たいていは数 TB のデータを持つ。
問い合わせが、条件で少しの行に絞り込むか、データを並べ替える。
多くの問い合わせで、同じキーによるプルーニングの効果が得られる。

費用を減らすことがおもな目的なら、問い合わせの回数がデータの変更の回数より十分に多い表にするよう、Snowflake は勧めている²。

キーに選ぶ列については、Snowflake は次のように勧めている²。

数： 1 つのキーに入れる列は 3〜4 までにする。
異なる値の数（カーディナリティ）： 少なすぎると飛ばせる数が少なく、多すぎると同じマイクロパーティションに集められない。新規の顧客かどうかの列は値の種類が少なすぎ、ナノ秒のタイムスタンプは多すぎる。タイムスタンプなら to_date(c_timestamp) のように日付に直した式にする。
並べる順： 異なる値の少ない列から多い列の順に並べる。

自動クラスタリング：再クラスタリングし続ける費用

キーを付けると、自動クラスタリングがバックグラウンドで再クラスタリングを続ける。ウェアハウスを用意する必要はなく、再クラスタリングの間もデータの変更は止まらない。再クラスタリングするのは、表の性能に利点があるときだけである⁶。その代わり、クレジットがかかる。計算のしかたは版で違う⁶。

自動クラスタリングには二つの版がある⁶。

Optima Clustering： 2026 年 9 月 1 日からキーを付けた表が使う新しい版。取り込んだデータの量と、そのうち再クラスタリングが要る割合に応じて請求する。入った時刻で並べる、追加だけの表なら、ほとんどかからない。キーの列の値を書き換える更新は、ふつうは割り引かれず、取り込んだ量の全部に 1 GB あたりの単価がかかる。
Clustering Classic： それより前にキーを付けた表が使い続ける、以前の版。再クラスタリングに使った計算の時間で請求し、表の変更が多いほど費用が増える。キーを変えても、Optima には移らない。

料金表では、Optima は圧縮前の 1 GB あたり 0.007 クレジット、Classic は X-Small のウェアハウス 1 時間分の計算あたり 2 クレジット（ほかにクラウドサービスの分）である⁷。SYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTS は、キーを付けるときやキーを変えるときの一度きりの計算の費用と、その後の保守の費用を前もって見積もる。Optima で見積もれるのは今は一度きりの費用だけで、Optima の保守の費用は圧縮前の 1 GB あたりの単価が上限になる⁶。たとえば、最初の再クラスタリングの上限が 98.2 クレジット、その後の保守が 1 日 10.0 クレジットだった⁸。ただし、実際の費用は見積もりと最大 100%（まれに数倍）違うことがある⁶。

再クラスタリングで保存の費用が増えることもある。キーを付けた表では、少しの行を足すだけでも、その値を含むマイクロパーティションがすべて作り直されることがあり、古いものは Time Travel と Fail-safe の期間が過ぎるまで消えない²。自動クラスタリングの頁は、多くの場合は追加の保存費用は無く、Fail-safe の保存が増えると費用がかかると書いている⁶。自動クラスタリングのクレジットは、ウェアハウスのリソースモニターでは抑えられない⁶。実際に使ったクレジットは、AUTOMATIC_CLUSTERING_HISTORY で表ごとに見られる⁹。

Snowflake の技術者 Prasanna Rajaperumal は、2022 年の講演の紹介で、データの入る順と違う列で良い並びを保とうとする素朴な方法はたいてい費用がかかり、並べ直しの費用と問い合わせの速さの釣り合いはある点から先は伸びが鈍ると書いた。近似的に並べるほうが保つ費用は安く、それでもプルーニングはよく効くとしている¹⁰。

Snowflake は、まず 1〜2 個の表で試し、クレジットの請求を見るよう勧めている⁶。Optima では、費用を抑えるために再クラスタリングを止めたり再開したりするのは、たいてい得にならず、払い続けたくなければキーを外すよう書いている⁶。

効いているかを確かめる：読んだ数と全体の数

プルーニングが効いたかは、問い合わせの実行の記録で確かめる。

Query Profile： 表を読む処理（TableScan）の「Partitions scanned（読んだ数）」と「Partitions total（全体の数）」を比べる。読んだ数が全体の小さな割合なら、プルーニングは効いている⁴。
EXPLAIN： 問い合わせを流さずに、どう処理するかの計画を出す。全体の数（partitionsTotal）と、実行の前のプルーニングの後に残る数（partitionsAssigned）を確認でき、ウェアハウスを動かさなくてよい。実行の途中のプルーニングで、さらに減ることがある¹¹。
QUERY_HISTORY： 流した問い合わせの partitions_scanned と partitions_total が残る¹²。

Snowflake は、プルーニングが効くには、データの保存の順が問い合わせの条件と関係している必要があると書いている⁴。読んだ数が全体に近いまま遅い表が、クラスタリングキーを考える候補になる。

出典12件

Snowflake「Micro-partitions & Data Clustering | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions — 表 t1 と重なりの深さの図、プルーニングの目安。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹
Snowflake「Clustering Keys & Clustered Tables | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/tables-clustering-keys — 再クラスタリングの図、付けるべき表と列の選び方。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸
Benoit Dageville ほか「The Snowflake Elastic Data Warehouse」SIGMOD 2016、2016年6月、2026年10月20日取得. https://info.snowflake.net/rs/252-RFO-227/images/Snowflake_SIGMOD.pdf — 最小・最大によるプルーニング。 ↩ ↩² ↩³
Snowflake「Monitor query activity with Query History | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/ui-snowsight-activity — Partitions scanned と Partitions total。 ↩ ↩² ↩³
Snowflake「SYSTEM$CLUSTERING_INFORMATION | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/functions/system_clustering_information ↩ ↩² ↩³ ↩⁴
Snowflake「Automatic Clustering | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/tables-auto-reclustering — Optima と Classic、費用。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Snowflake「Snowflake Service Consumption Table」2026年10月12日発効、2026年10月20日取得（アーカイブ）. https://web.archive.org/web/20261012232620/https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf ↩
Snowflake「SYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTS | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/functions/system_estimate_automatic_clustering_costs ↩
Snowflake「AUTOMATIC_CLUSTERING_HISTORY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/account-usage/automatic_clustering_history ↩
Prasanna Rajaperumal「QCon London April 4-6, 2022 | | Automatic Clustering At Snowflake」QCon London、2022年、2026年10月27日取得. https://archive.qconlondon.com/node/79247 — 講演者は Snowflake の技術者。 ↩
Snowflake「EXPLAIN | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/sql/explain ↩
Snowflake「Exploring execution times | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/performance-query-exploring ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。