データ基盤

Snowflake VARIANTとは？JSONを扱う半構造化データの仕組み

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

🤖 AIを使用して執筆

CREATE OR REPLACE TABLE car_sales
(
  src variant
)
AS
SELECT PARSE_JSON(column1) AS src
FROM VALUES
('{
    "date" : "2017-04-28",
    "dealership" : "Valley View Auto Sales",
    "salesperson" : {
      "id": "55",
      "name": "Frank Beasley"
    },
    "customer" : [
      {"name": "Joyce Ridgely", "phone": "16504378889", "address": "San Francisco, CA"}
    ],
    "vehicle" : [
      {"make": "Honda", "model": "Civic", "year": "2017", "price": "20275", "extras":["ext warranty", "paint protection"]}
    ]
}'),
('{ ... }') v;
-- 2 件目は省略：Tindel Toyota、顧客 Bradley Greenbloom（New York, NY）、
-- Toyota Camry、"price": "23500"、extras は 3 つ。省略したままでは実行できない

SELECT src:customer[0].name, src:vehicle[0].price
    FROM car_sales
    ORDER BY 1;

+----------------------+----------------------+
| SRC:CUSTOMER[0].NAME | SRC:VEHICLE[0].PRICE |
|----------------------+----------------------|
| "Bradley Greenbloom" | "23500"              |
| "Joyce Ridgely"      | "20275"              |
+----------------------+----------------------+

SELECT src:vehicle[0].price::NUMBER * 0.10 AS tax
    FROM car_sales
    ORDER BY tax;

+--------+
|    TAX |
|--------|
| 2027.5 |
| 2350.0 |
+--------+

SELECT
  value:name::string as "Customer Name",
  value:address::string as "Address"
  FROM
    car_sales
  , LATERAL FLATTEN(INPUT => SRC:customer);

+--------------------+-------------------+
| Customer Name      | Address           |
|--------------------+-------------------|
| Joyce Ridgely      | San Francisco, CA |
| Bradley Greenbloom | New York, NY      |
+--------------------+-------------------+

VARIANT・ARRAY・OBJECT：値と型をいっしょに持つ

半構造化データを扱う型は三つある²。

• VARIANT： どの型の値も入る。値と、その値の型をいっしょに持つ。
• ARRAY： 値の並び。一つひとつの値は VARIANT である（値の型を決めた ARRAY は最後の節で扱う）。
• OBJECT： 名前と値の組の集まり。名前は文字列（VARCHAR）、値は VARIANT である。

一つの VARIANT の値は、圧縮する前で最大 128 MB まで持てるが、内部で管理に使う分があるため、実際にはそれより小さくなる²。JSON には日付や時刻の型がないので、日付や時刻は文字列として入る²⁴。

Snowflake は、JSON のほかに Avro、ORC、Parquet、XML の形式の半構造化データも取り込める¹。

取り込む：PARSE_JSON と COPY INTO

文字列から VARIANT を作るのが PARSE_JSON である。入力は圧縮した大きさで 64 MB まで受け付ける⁴。ファイルから読み込むときは、ステージ（読み込むファイルを置く場所）のファイルを表に読み込む命令 COPY INTO で、ファイル形式の TYPE を JSON にする⁶。読み込みの形式には、いちばん外側の角かっこ（[ ]）を外す STRIP_OUTER_ARRAY や、値が null の項目を落とす STRIP_NULL_VALUES を指定できる⁷。

Snowflake の創業者らが 2016 年の国際会議 SIGMOD で発表した論文は、VARIANT があるので、読み込むときに JSON の形を決めたり変換したりしなくてよく、先に読み込んでから変換する ELT（Extract-Load-Transform、抽出・読み込み・変換）の使い方ができると書いた⁸。Snowflake は、JSON を扱う方法として三つを挙げている⁹。

• VARIANT の列にそのまま置く。
• いったん VARIANT のまま中間の表に置き、FLATTEN で項目を別の列に取り出した表を作る。
• 読み込むときに、JSON の項目をそのまま表の列に変換する。

取り出す：パスとキャスト、FLATTEN

パスで項目をたどるとき、列の名前は大文字と小文字を区別しないが、JSON の項目の名前は区別する³。

FLATTEN は、まとまった値を複数の行に展開する関数で、次の列を返す¹⁰。

空の配列の行も残したいときは OUTER を TRUE にし、入れ子の下まですべて展開するときは RECURSIVE を TRUE にする¹⁰。FLATTEN を続けて使うときは、LATERAL を付けると、後の FLATTEN が前の FLATTEN の結果を使える¹⁰。

中での持ち方：よく出る項目を列に分ける

VARIANT の列に入れたデータは、文字の塊のまま置かれるのではない。Snowflake は、できるだけ多くの項目を列の形に取り出して持ち、残りを解析済みの一つの列に入れる⁵。Snowflake の日本語ドキュメントでは、これをサブカラム化という¹¹。

2016 年の論文は、この仕組みを説明している。Snowflake は、表を分けて持つファイル（今のマイクロパーティションにあたる）ごとに JSON を統計的に調べて型を推定し、よく出る項目を見つける。その項目を JSON から取り出し、ふつうの表と同じ圧縮した列の形で別に持つ。その列には、プルーニング（読まなくてよい部分を飛ばすこと）に使う集計の値も作る⁸。論文によれば、日付が文字列で入っている問題には、日付への変換をあらかじめ試し、元に戻せる変換でない限り、変換の結果ともとの文字列を別の列に両方持つことで対処する⁸。これは 2016 年時点の説明で、論文ではこの変換を Snowflake 自身が行う⁸。一方、今の Snowflake のドキュメントは、文字列で入った日付を利用者が別の列に展開するよう勧めている⁵。

論文は、形が比較的安定して単純なデータなら、半構造化データへの問い合わせの速さは、ふつうの表とほぼ同じだと書いた。測定では、TPC（Transaction Processing Performance Council）という団体が管理する業界の基準 TPC-H にならったデータを JSON にして読み込んだので、日付は文字列になった。項目や型の手がかりはシステムに何も与えていない。ふつうの表に入れた場合と、スキーマを決めずに入れた場合で同じ問い合わせを比べると、増えた時間は、2 つの問い合わせを除いて約 10% だったとしている。例外の 2 つ（1 TB のデータでの Q9 と Q17）について、論文は、異なる値の数を見積もる処理の既知のバグで結合の順序がまずくなったためだと書いている。ただし、この測定は 2016 年のもので、TPC の確認は受けていない⁸。

この自動の取り出しには、今の Snowflake で次の制限がある⁵。

• 取り出すのは、一つの表のマイクロパーティション（Snowflake が表を分けて持つ保存の単位）ごとに、既定で 200 項目まで。
• 値が JSON の null の要素を一つでも含む項目は、列に取り出さない（項目がないだけなら取り出される）。JSON の null は、値がないことを表す SQL（Structured Query Language）の NULL とは別の、「null」という値である。
• 値の型が混じる項目も、取り出さない。
• 列に取り出されなかった項目は、問い合わせのたびに JSON の全体を読み、行ごとにたどって値を出すので、遅くなる。

列に展開するべきとき

Snowflake は、半構造化データでどんな操作をするかまだ決まっていないなら、ひとまず VARIANT の列に置くよう勧めている⁵。形がほぼそろっていて、文字列や整数のような JSON がもともと持つ型だけを使うデータなら、表と VARIANT の列とで、保存の量も問い合わせの速さもほとんど変わらない⁵。

一方で Snowflake は、次のような値を含むなら、項目を別の列に展開するよう勧めている。プルーニングが効きやすくなり、保存の量も減るからである⁵。

• 文字列で書かれた日付や時刻（とくに ISO 8601 の形でないもの）
• 文字列の中の数値
• 配列

使い方が分かっているなら、両方の形の表を作り、ふだんの問い合わせを実行して比べるよう、Snowflake は勧めている⁵。JSON の null を含む項目は、読み込む前に別の列に取り出すよう勧めている。null が値のないことを表すだけなら、読み込みの形式で STRIP_NULL_VALUES を TRUE にして落としてもよい⁵。

null には二種類ある。SQL の NULL は値がないことを表す。JSON null は、VARIANT の列の中で「null」という値として持たれ、SQL の NULL と区別される。文字列にキャストすると、JSON null は SQL の NULL になる⁵。

展開せずに VARIANT の中の項目での絞り込みを速くする手として、Snowflake には検索最適化もある。VARIANT・OBJECT・ARRAY の中の要素に対する等値や IN、NULL を調べる条件に効き、Enterprise Edition 以上で使える¹²。

形を推定する、型を決める

読み込む前のファイルの形は、INFER_SCHEMA で推定できる。ステージ（読み込むファイルを置く場所）にある JSON や Parquet などのファイルから、列の定義を取り出す¹³。ただし、JSON と CSV ではすべての列が NULL を許す列として推定され、入れ子は 1 段目までしか扱えない¹³。推定した定義から、CREATE TABLE … USING TEMPLATE で表を作れる¹³。

データに新しい項目が増えたときに、表の列を自動で足す機能もある。これをスキーマ進化という。表の ENABLE_SCHEMA_EVOLUTION を TRUE にしておくと、列の名前で合わせる COPY INTO や Snowpipe での読み込みで列が足される。一回の COPY で足せるのは既定で 100 列までで、INSERT では表の形は自動では変わらない¹⁴。

項目の型を先に決めたい場合は、構造化データ型を使う。ARRAY、OBJECT、MAP の中の値に、決まった型を指定できる¹⁵。ふつうの表で構造化データ型が一般提供になったのは、2025 年 7 月のリリース（9.19）からである¹⁶。

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