はじめに

以下の記事の続きです。

このシリーズの制約

執筆(記事のたたきを含む)やまとめに生成AIは利用しません。
ただし、筆者が内容を理解するために生成AIを用いることがあります。
(まぁ普段から執筆に生成AIを使っていませんが……)

免責事項

本記事は執筆時点での情報をもとにまとめています。
そのため、読者の方が閲覧されるタイミングでは内容が変更されている可能性があります。

記事の内容と公式ドキュメントの記載に差異がある場合、または解釈にずれがある場合は、公式ドキュメントの記載を正とします。

今回読むドキュメント（超重要な章）

【対象】
Get started for users

Key concepts and architecture

Key concepts and architecture

ここではSnowflakeのアーキテクチャが記載されています。

Snowflakeはセルフマネージドサービスとして提供される高度なデータプラットフォームを基盤としています。「Snowflakeといえば、DWHだ」と思う人もいますが、DWHのみではなく、幅広い機能が統合されたデータプラットフォームです。

セルフマネージドサービスとしてのデータプラットフォーム

Snowflakeはセルフマネージドサービスのため、ハードウェアの管理をユーザーが行う必要はありません。また、メンテナンス、アップグレード、チューニングなどもユーザーの管理対象外とし、Snowflake側が行ってくれます。

さらに、Snowflakeは大規模なコンピューティングや、永続データストレージを利用するためにパブリッククラウドの基盤を利用しています。
パブリッククラウドは、現時点でAWS、Azure、Google Cloudの3つのクラウドサービスプロバイダーのいずれかを選択することができます。
この環境はユーザーが管理する必要はありません。

上記の特性より、ローカル環境でホストすることはできません。

Snowflakeアーキテクチャ

Snowflakeは、共有ディスク型データベースアーキテクチャ(Shared-disk architecture)と非共有型データベースアーキテクチャ(Shared-nothing architecture)のハイブリッドとなっています。

言葉だけ並べるとなんだそれは…となるのですが、データは一つの場所にあって、コンピューティングノードは複数台一気に動ける(分散型のアーキテクチャ)という仕組みです。
さらに、各コンピューティングノードはデータの一部をローカルに保存することができます。

これにより、データの管理性を排除しつつ、Shared-nothing型のアーキテクチャのメリットであるパフォーマンスとコンピューティングのスケールアウトを実現可能としています。

また、Snowflakeは以下の主要なレイヤーで構成されています。

データベースストレージレイヤー

Snowflakeでは、構造化データ、半構造化データ、非構造化データをそれぞれ扱うことができます。

構造化データ
表形式スキーマに従う仕組みです。
厳密にカラムとデータが一対一でマッチします。
(カラム内に複数の値を表現した場合は除く)

以下のような表をイメージすればわかりやすいと思います。

id name age

1 Jack 23

2 Sara 19

3 Mike 21

半構造化データ
JSONやXMLなどの半構造化データは、特殊なデータ型を利用することでSnowflake上で管理することができます。
主に使われるのは、VARIANT型です。
VARIANT型は半構造化データであればとりあえず放り込むことができます。
キーバリュー型や、配列などとりあえず入れておくにはいいでしょう。

後述する2つの型で利用するデータの実態はVARIANT型になります。
- OBJECT型
  OBJECT型は、キーバリュー型のデータ型です。
  つまり、キーと値が存在するデータを格納できます。
  以下のように、「thirteenというキーには、13という値が入っている」というようなマッピングされたデータを扱うことができます。
```
+-------------------+
| OBJECT_COLUMN     |
|-------------------|
| {                 |
|   "thirteen": 13, |
|   "zero": 0       |
| }                 |
+-------------------+
```
- ARRAY型
  ARRAY型は、配列を扱うことができるデータ型です。
  キーはなく、以下のように値の羅列になっていることがわかります。
```
+----------------------------------+
| [$MY_VARIABLE+1, $MY_VARIABLE+2] |
|----------------------------------|
| [                                |
|   11,                            |
|   12                             |
| ]                                |
+----------------------------------+
```

非構造化データ
画像や動画、音声などの非構造化データを直接扱うことができる固有のスキーマ形式はありません。
これらのデータは、ファイルを内部ステージまたは外部ステージという領域に格納し、Snowflakeの関数を用いて操作します。
関数の結果をFILE型というデータ型を用いて扱います。

型があるなら、管理できていることなのでは？とも思うのですが、FILE型は実際のデータは保存されておらず、ファイルへの参照データを保存します。つまり、実態を指すメタデータを保存するものです。

Snowflakeのテーブルタイプ

前述したデータの保存に利用されるテーブルは以下の3つのテーブルタイプが利用されます。
(テーブルタイプは他にも存在します。)

Snowflakeテーブル
Snowflakeテーブル内にデータがロード(取り込み)されると、Snowflakeは内部でデータを圧縮し、再編成します。
圧縮されたデータがSnowflakeのクラウドストレージへ格納されます。
これによって、データ量が減り、管理面(コストなど)や読み取り性能の向上を実現しています。

Snowflakeはデータの保存方法に関する様々な情報を管理しています。
ドキュメントに記載されているのは、「構成、ファイルサイズ、構造、圧縮、メタデータ、統計情報など」です。

また、Snowflakeテーブルのすべてのデータは、マイクロパーティションによって分割されます。マイクロパーティションとはデータを分割・保存するためのブロックと考えればOKです。

各マイクロパーティションには、非圧縮状態で50MB〜500MB程度のデータが格納されています。実際に格納される際は、圧縮された容量になるためもっと少ないデータ容量となります。

Snowflakeはクエリプルーニングという仕組みを使ってデータの取得に必要なマイクロパーティションのみを読み取るため、適切なクエリであれば大規模なデータに対しても高速にアクセスすることができます。

(引用：https://docs.snowflake.com/ja/user-guide/tables-clustering-micropartitions#what-is-data-clustering)

Apache Iceberg™ テーブル
オープンテーブルフォーマットを採用したテーブルです。
このドキュメントでは、外部のクラウドストレージを利用することが必須のように書かれていますが、Snowflakeが管理するストレージでApache Iceberg™ テーブル(以降、Icebergテーブル)が作成できるようになっています。
(執筆時点(2026/5/6)でSnowflakeのマネージドストレージを利用したIcebergテーブルはパブリックプレビュー中のため、本記事の内容とずれが生じる場合があります。)

Snowflakeでは、Parquetファイル形式を使用するIcebergテーブルをサポートしています。

このテーブルタイプを利用することで、異なるクエリエンジンであっても同じデータ形式でデータを扱うことができるようになります。例えば、Amazon AthenaやApache Sparkなどの異なるクエリエンジンであっても、データの一元管理が可能です。

Icebergテーブルは、ACID特性（原子性、一貫性、分離性、耐久性）を備えており、トランザクショナルにデータを扱うことができます。ただし、一般的なOLTP(オンライントランザクション処理)で利用するDBとは性質が異なるため、完全に同じ使い方ができるかというとそうではありません。

Icebergテーブルで管理するデータは、データカタログを利用して管理されます。データカタログとは、データを管理するためのデータを管理しているものです。(こういうと分かりづらいですが…)

簡単に言うと、データがどこにあるのか、どういう世代なのかみたいな情報を持っているポインター的な役割です。この機能により、過去のデータ断面を参照したり、データの更新を行ったりすることができるようになります。

Snowflakeでは、Snowflake側でデータカタログを管理する方法と外部のデータカタログを利用する方法の2パターンがあります。

ハイブリッドテーブル
ハイブリッドテーブルは、簡単に言うと、リレーショナルデータベースのようなテーブルを作成できる機能です。
DWHのような列指向データベースのアーキテクチャは列の属性を扱うことに長けている反面、行の扱いはやや苦手です。
そのため、オンライントランザクション処理のような1行を更新するといった処理には向きません。

さらにいうと、Snowflakeのハイブリッドテーブルを除くテーブルタイプにおいてはインデックスという概念はありません。また、大半の制約が設定できるものの制約として機能しません。

ハイブリッドテーブルを利用することで、インデックスを利用した低レイテンシかつ高スループットを実現することができます。ハイブリッドテーブルでは、RDBMSのように制約を使うことが可能です。

ハイブリッドテーブルは、Snowflakeが提唱するユニストア(Unistore)というOLTP(オンライントランザクション処理)とOLAP(オンライン分析処理)を組み合わせて提供するワークロードの中核を担う機能です。

ハイブリッドテーブル登場以前は、OLTPのデータベースからデータの移動が必須でしたが、ハイブリッドテーブルが登場したことで選択可能なアーキテクチャの幅が広がりました。

ただ、依然としてSnowflakeの環境外からのデータ移動は発生することが多いです。

コンピュートレイヤー

Snowflakeのコンピュートは、仮想ウェアハウスと呼ばれています。
仮想ウェアハウスは、Snowflake上のコンピューティングリソースのクラスタ(集合体)です。

仮想ウェアハウスには、標準ウェアハウスやSnowpark最適化ウェアハウスなど様々なタイプがあります。

仮想ウェアハウスはそれぞれ独立しているため、他のウェアハウスとコンピューティングリソースを共有しません。そのため、他のウェアハウスに影響を及ぼすことはありません。

例えば、ETL処理などで利用するウェアハウスと、分析で利用するウェアハウスを分けることでそれぞれの処理が別のウェアハウスに影響させないようにすることができます。一方で、同じウェアハウスを利用した場合は、それぞれの処理に影響を与えるため、注意が必要です。

クラウドサービスレイヤー

コンピュートレイヤーよりも上位の層で、Snowlake全体のアクティビティを調整するサービスの集合体です。
Snowflakeのアーキテクチャの中核になっています。

主にこのレイヤーで管理されているサービスは以下です。

セキュリティ、認証、およびアクセス制御
- セキュリティ
  セキュリティ関連では、ネットワークセキュリティをこのレイヤーで実装しています。
  例えば、悪意あるIPアドレスからのアクセス保護や、ネットワークポリシー/ネットワークルールによるネットワークトラフィックの制御などが挙げられます。
  
  悪意あるIPアドレスはサードパーティーのサイバーセキュリティデータソースから取得したデータに基づき、IPアドレスのリストを管理しています。ユーザー自身で更新する必要がないのはありがたいです。
  
  また、ネットワークルールではマネージドのルールが用意されており、Tableau CloudやQlikなどのグローバルネットワークを経由してアクセスする特定のBIツールはSnowflake側でIPアドレスの管理を行ってくれるため、サービスが利用するIPアドレスが変更された場合でも柔軟に対応してくれます。
  
  他にも、トラストセンターという機能でアカウント内のセキュリティリスクを定期的に監視・評価する機能もあります。
  　
- 認証
  認証においては、認証ポリシーを利用して、制御を行います。
  例えば、多要素認証やSSOによる認証など指定された認証方式でアクセスしていない場合は拒否することができます。
  　
- アクセス制御
  Snowflake内でどのような操作ができるのかなどのアクセス制御もクラウドサービスレイヤーで行われています。Snowflakeのアクセス制御フレームワークに従い、ユーザーの操作を制御しています。

Snowflake Horizon カタログ
Snowflake Horizon カタログとは、データ資産全体に関わるユニバーサルカタログと定義されています。
いまいちイメージしにくいと思うので追々詳しく解説できればと思いますが、データカタログの機能だけではなく管理・統制の部分も含めた統合サービスです。

前述したトラストセンターもSnowflake Horizon カタログの一機能です。

クラウドプラットフォームによるインフラストラクチャ管理
Snowflakeではクラウドプラットフォームプロバイダーを3つの中から選択できますが、基本的にどのクラウドを選択したとしても同じように利用することができます。
ただし、一部クラウドでは未対応の動作があったり、リージョンの制約で利用できない使い方もあります。

SNOWFLAKE データベースや Snowflake Information Schema などのメタデータ管理
Snowflakeでは、アカウントに関わる情報やマネージドで提供されている内容などは、「SNOWFLAKE」という共有DBに保存されています。

また、各データベースには「information_schema」というスキーマが自動で作成されて、各データベースレベルの情報を保存してくれます。

Query parsing and optimization
ここはSnowflakeの中で超重要な要素です。
実行されたクエリの最適化や、ウェアハウスの最適化などがこのクラウドサービスレイヤーで行われます。

規制コンプライアンス
認証や規制においてもこのレイヤーの役割です。
Snowflakeでは、業界標準の規制コンプライアンス要件を満たしています。

国際基準だけではなく、地域によっては地域特有の要件を満たすように設計されています。
日本特有のJIS規格にはフォーカスされていませんが、国際基準に則ってISO-27001なども満たしているため、ISMSなどの監査においても問題ないといえます。

また、ヘルスケア業界や金融業界特有の基準も満たしているため、幅広い用途で安心して利用できるようになっています。

ワークロード向けの統合機能

統合された機能セットを使用することで、様々なタスクをSnowflakeで処理することができるようになっています。
主にサポートされている領域は以下の4つです。

データエンジニアリング
分析
AI/ML
アプリケーションおよびコラボレーション

データエンジニアリング

Snowflakeはインフラ側がマネージドサービスになっているという特徴と、クラウドサービスレイヤーによる自動的なクエリやパフォーマンスの最適化のおかげで、エンジニアはデータパイプラインの実装に注力することができます。

データ取り込みでは、いくつかの手法がサポートされています。

COPY INTOコマンド
ファイルをテーブルにロード(データをインポート)するコマンドです。

ステージというファイルの置き場を利用して、ステージ内のファイルをテーブルにロードします。
ステージは内部ステージというSnowflake内にファイルを保持する方式と、外部ステージという外部のオブジェクトストレージ(AWSのS3などのストレージ)に配置する方式があります。

ステージについてはこちらでも解説しています。※今後読み進めていく際にも再度解説します

Snowpipe
Snowpipeは継続的にデータをロードする際の選択肢の一つです。
COPY INTOコマンドによるロードは、バルクインサート手法(一括でデータを取り込む手法)です。

Snowpipeは外部ステージへのファイル配置を契機にするか外部からのREST APIによる通知(外部ストレージへのファイル配置を契機としたREST APIの発報)のいずれかで対象のデータを継続的にロードできる仕組みです。

Snowpipe Streaming
こちらは上記のSnowpipeとほとんど名前が一緒ですが、少しユースケースが異なります。
先ほどのSnowpipeではファイルの配置が契機になっていました。

Snowpipe Streamingに関しては、ファイルではなく行レベルのデータを継続してロードする際の選択肢です。
例えば、IoTデータなどが挙げられます。
Snowflake SDKsやREST APIによるデータ連携が対象です。

Openflowコネクタ
Apache NiFi フローを定義できるコネクタです。
様々なコネクタが用意されており、他のRDBMSから変更データキャプチャ(CDC)でデータを継続的に差分連携することができます。
他にもSharepointやBoxなどのファイル共有サービスやGoogle Ads、Amazon Adsなどの広告管理サービスからの情報なども連携することができます。

Snowflakeコネクタ
Snowflake内でサードパーティ製のサービスと統合できるコネクタです。
このコネクタを利用することでAPIエンドポイントなどを手動で設定することなく、シームレスなデータの統合が可能になります。

Snowflakeでは以下のようにデータを変換する機能もあります。

ダイナミックテーブル
ダイナミックテーブルは、自動的にリフレッシュし、クエリ結果を実データで保存してくれるテーブルです。
マテリアライズドビューとの大きな違いは、リフレッシュが即時ではないことと、他テーブルとの結合に対応している点です。

ストリーム＆タスク
先ほどのSnowpipe Streamとは別物です。
ストリームは通常のテーブルやビューと同じように扱うことができるオブジェクトです。
ストリームを有効化(作成)すると、テーブルに対する変更履歴を追跡してくれるようになります。
この機能があるおかげで、過去どのようなデータがあったのか？同じような内容だけどどれが最新のデータなのか？などを追跡することができるようになります。

Snowpark
Snowparkは、Python、Java、Scalaなどのプログラミング言語を利用した大規模なデータのクエリと処理を実行するための直感的なライブラリを提供する機能です。

dbt
dbtというオープンソースのデータ変換ツールとフレームワークを利用したELT機能です。
SQLによってデータマートなどを作成したり、テストなどを容易に行うことができます。

また、他にもSnowConvert AIというマイグレーションツールで他のデータプラットフォームのDDLやデータをもとにしたSnowflakeへの移行をサポートしています。

他にもSnowpark Migration Accelerator(以下、SMA)というツールでSparkコードからSnowparkコードへの変換もサポートしています。
ただし、SMAはSnowflake Inc.の公式製品ではなく、独自の条件で提供されています。

分析

Snowflakeでは、構造化、半構造化、非構造化データなどのさまざまな型のデータを簡単に取り扱うことができます。
前述のデータを扱うための方法を複数提供しています。

システム関数およびSQL構文
- 集計関数
  集計関数は、行に含まれている値に対して演算を行うための関数です。
  単体の行でも、複数の行でも入力として受け取ることができます。
  出力は単一の行になります。
  
  例えば、テストの平均点を集計するというシチュエーションで入力が以下のデータだとします。
  
  名前点数
  
  田中 85
  
  鈴木 72
  
  佐藤 91
  
  山田 72
  
  集計関数を使って、平均点を出力すると以下の通り、単一の値が出力されます。
  
  平均点
  
  80
  
  他にも集計関数はいろいろあるので、また後日解説します。
  　
- ウィンドウ関数
  パーティション内の関連する行のセットに対して計算を実行したり、各パーティション内の行のサブセットに対してローリング処理を行う関数です。
  こう書くとわかりにくいですね。
  
  簡単に例を記載します。
  以下のようなテスト結果テーブルがあるとします。
  
  名前クラス点数
  
  田中 A 85
  
  鈴木 A 72
  
  佐藤 B 91
  
  山田 B 72
  
  ここで、ウィンドウ関数を使って、クラスごとの平均値を埋め込みます。
```
SELECT
  "名前",
  "性別",
  "点数",
  AVG("点数") OVER (PARTITION BY "クラス") AS "クラスごとの平均"
FROM "テスト結果テーブル";
```
  このように実行すると、以下のように複数の値を返すことができます。
  これがパーティション内の行セットに対する計算です。
  
  名前クラス点数クラスごとの平均
  
  田中 A 85 78.5
  
  鈴木 A 72 78.5
  
  佐藤 B 91 81.5
  
  山田 B 72 81.5
  
  次に、わかりにくいのがローリング処理です。
  累計などで利用しますが、店舗Aの売り上げの合計が日ごとに記録される売上テーブルがあったとしましょう。
  
  売上日売上
  
  2026-05-01 150
  
  2026-05-02 210
  
  2026-05-03 120
  
  2026-05-04 180
  
  それでは、各日付ごとにその日以前の過去日を含めた売上を合計して出力するとします。
```
SELECT
  "売上日",
  "売上",
  SUM("売上") OVER (
    ORDER BY "売上日"
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS "累積売上"
FROM "売上テーブル";
```
  そうすると以下のような結果が得られます。
  
  売上日売上累積売上
  
  2026-05-01 150 150
  
  2026-05-02 210 360
  
  2026-05-03 120 480
  
  2026-05-04 180 660

共通テーブル式(CTE)
共通テーブル式は、WITH句を利用した名前付きサブクエリです。
共通テーブル式と記載するとわかりにくいですが、一時ビューのようなものです。

Cortex AI
Cortex AIでは、AIを利用した関数が使用できます。
例えば、画像などの非構造化データを入力として渡すことで、画像内のデータを抽出するOCR機能も利用することができます。
Cortex AI関数にも色々な種類があるので、また次回以降で解説します。

セマンティックビュー
ビジネス的な意味をデータベース内に埋め込むことができる機能です。
ここは抽象化されたレイヤーの話なので、非常にわかりにくいと思います。

セマンティックビューは、AIアプリケーションからのText-to-SQLの精度を上げることに役立ったり、ビジネスユーザーに対して一貫した指標を提供できるといった役割を持ちます。ビジネスロジックなどを含め、人によって解釈が異なった結果、正しくない計算が生まれてしまう、ということを防止したりします。

ドキュメントを読み進めていく中で再度登場してくるので、その際に詳しく解説したいと思います。

AI/ML

Snowflakeでは、AIとML機能があるため、簡単にそれぞれの分野に触れることができます。

Cortex AI
こちらは、大規模言語モデル(LLM)を用いて、非構造化データなどを理解して自然言語などを用いてデータを扱うことができる機能を備えています。

また、他にも翻訳や要約などのテキストを処理する機能も持っているため、幅広い分野で利用することができます。
前述したとおり、Cortex AI関数にはいろいろな種類があるため、別の機会に解説します。
Snowflake ML
SnowflakeにはML関数といって簡単に機械学習を用いて予測や異常検知などが行えます。
機械学習の知識がなくても簡単に扱うことができるという特徴があります。

アプリケーションとコラボレーション

Snwoflake内でアプリケーションを構成することで、簡単にチームや外部のパートナーなどと共有することができます。
また、共有に際し、アクセス制御などを行うことができます。

Snowflakeでは、以下の手法でアプリケーションを構成することができます。

Streamlit
オープンソースのPythonライブラリを使用して、簡単なUIを備えたWebアプリケーションを構築できます。
ダッシュボードなども簡単にStreamlitで構成することもできます。

Snowparkコンテナサービス(SPCS)
SPCSを利用することでSnowflakeでコンテナ化されたアプリケーションのデプロイや、スケーリングなどが行えます。
高度なCPUとGPUを備えているため、計算負荷の高いワークロードも実行することができます。

Snowflake Native App Framework
Snowflake上で作成したアプリケーションを他のSnowflakeユーザに配布・販売できる仕組みです。
Snowflake上で作成したStreamlitアプリなどもNative Appとして外部に配布したりできます。

さらにSnowflakeではデータ共有方法も様々な種類があります。

データ共有(Secure Data Shareing)
アカウント内のデータベースにあるオブジェクトを他のSnowflakeアカウントと共有できる機能です。
共有できるオブジェクトには制限があるため注意が必要です。

リスティング
プロバイダーとして他のSnowflakeユーザにデータを交友でkる機能です。
Snowflake Marketplaceで外部のユーザに公開したり、内部Marketplaceで内部のユーザにデータを共有したりできます。

データクリーンルーム
データクリーンルームはデータをそのまま共有するのが難しい場合に利用できます。
特定のカラムのデータだけを見せずにテーブルを共有したりすることができます。
また、他アカウントなどとのコラボレーションもできるため、データを直接移動せず、セキュアな状態で外部データとの結合を行うことができます。

Snowgrid

Snowgridは、リージョンやクラウドサービスプロバイダー間をまたいで運用を可能にする技術です。
前述したリスティングによるデータ共有機能では、リージョン間やクラウドサービスプロバイダー間のデータ共有に対応していますが、後ろに構えているのはこのSnowgridという仕組みです。

Snowgridを使うことで、リージョンやクラウドをまたいで一貫したセキュリティやガバナンスポリシーを適用したり、レプリケーションを行ったりすることができます。

Snowflakeへの接続

Snowflakeでは様々な接続方法をサポートしています。

Snowsight
こちらは前回紹介したWebベースのUIです。

コマンドラインクライアント
こちらも前回紹介しましたが、Snowflake CLIなどのコマンドラインでSnowflakeの操作ができるクライアントです。

ネイティブAPIs
Snowflake Python APIsやSnowflake REST APIsなどのネイティブでサポートされているAPIを利用した接続が利用できます。

ドライバーによる接続
JDBCドライバーや、ODBCドライバーを使用した接続が利用できます。
利用できるドライバーやダウンロードリンクは以下のページから辿ることができます。

コネクタによる接続
Apache KafkaやApache Sparkからネイティブコネクタを使用して接続ができます。

サードパーティーテクノロジー
サードパーティー製品からSnowflakeに接続することができます。

おわりに

今回は、Snowflakeのアーキテクチャについて説明されている章を読みました。

抽象化された話が多いので、かなり読み応えがある章でした。
結構重かったので執筆に時間がかかりました…。

ここですべては語られていないので、後続のドキュメントで詳細を深堀できればと思います。