Snowflakeの設計/管理/運用する上で必要となるアーキテクチャであったり、エディションごとの機能/価格を紹介しています。また性能を出すために考慮しないといけない項目についても記載しています。

1. 0
Snowflake
Architecture and Performance
本橋 峰明
Mineaki Motohashi
30 Nov. 2017

2. 1
Agenda
1. 自己紹介
2. Snowflakeとは
 最近のデータ処理基盤
 従来型DWHの限界とSnowflake
 Snowflake Computing
 DWHに求められる機能
 Snowflakeの特徴
3. Snowflakeアーキテクチャ
 アーキテクチャ概要
 ステージ
 テーブル
 ウェアハウス
 リザルトキャッシュ
 ユーザアクセス
 その他情報
4. パフォーマンスを考慮した設計
(Snowflake/BigQuery/Redshift)
 性能を引き出すための検討事項
5. 参考情報
6. まとめ

3. 2
1. 自己紹介
• Name
₋ 本橋 峰明(Mineaki Motohashi)
• Contact
₋ mineaki.motohashi@gmail.com
• Job
₋ 某データベースベンダにて、データベース、アプリケーションサーバの
コンサルティング、プリセールス、新入社員のトレーニング
₋ 某コンサルティングファームにて、セキュリティ関連のコンサルティング、ERP基盤関連を
中心に構想立案から提案、構築、運用
₋ 現職にて、ID-POSシステムの設計/開発/運用、プロジェクト/ベンダ管理、技術検証など
• Database Experience
₋ Oracle Database、Microsoft SQL Server、Postgres、MySQL、Pivotal Greenplum、
Google BigQuery/Cloud Spanner、HPE Vertica、AWS Redshift、MemSQL、Snowflake
• Contents
₋ https://www.slideshare.net/mmotohas/
 Snowflake Elastic Data Warehouse as a Service
₋ アカウント登録、データベース作成からデータロード、検索までの手順、および
Webコンソール紹介
 Snowflake Architecture and Performance(本資料)
₋ 設計/管理/運用する上で必要となるアーキテクチャ、エディションごとの機能/価格
紹介
• Residence
₋ 厚木
• Hobby
₋ ボウリング、バドミントン

4. 3
2. Snowflakeとは ～最近の大量データ処理基盤～
• 大量処理にはHadoop/Sparkベースのソリューションが向いていると分類され
ることが多いが、本当にそうなのか？
• AWS Redshift、Google BigQuery、HPE Vertica、Pivotal Greenplumを始
め、様々な分散データベースが存在するが、良し悪しや向き不向きは？
• 様々な大量データ処理基盤が存在するが、性能と使いやすさを両立する基盤は
ないのか？

5. 4
2. Snowflakeとは ～従来型DWHの限界とSnowflake ～
• 従来型DWHはダイナミックな弾力性(Elasticity)を提供できる設計がされていない。
• アプライアンス製品は、ベストプラクティスに基づいて決められた構成
• ソフトウェア製品は、かなりの運用作業を伴うため、真に弾力性を持つとは言いがたい
• クラウドサービスは、ソフトウェア製品をクラウド環境に移植しただけのものが多い
• 共有ディスクアーキテクチャ vs 非共有アーキテクチャ(昔話の再掲)
• 共有ディスクアーキテクチャは、ノード数が増えると、ストレージとネットワークがボト
ルネックとなりうる
• 非共有ディスクアーキテクチャは、複数ノードへの最適なデータ配分や、データ再分散が
ボトルネックとなりうる
• Snowflakeでは、ストレージとコンピュートリソー
スを物理的に分離しつつ、論理的に統合した新しい
アーキテクチャ「マルチクラスタ、共有データアー
キテクチャ」を実現
• 以下の独立したコンポーネントから構成
• Database storage：Snowflake DWHサービス内の
データ永続化ストレージレイヤ
• Processing：クエリに必要なデータ処理を実行するコ
ンピュートリソース
• Cloud services：メタデータ、インフラ管理、セキュ
リティ、アクセス制御などを管理する共通サービス

6. 5
2. Snowflakeとは ～Snowflake Computing～
• 2012年に創業、翌年から毎年資金調達し調達総額$215M(約258億円)
• BIツールが次々と対応(直近では、10/3にGAとなったMSTR10.9が対応)
• CEOは元MicrosoftのAzureも含むServer/Toolsビジネスを牽引していたBob
Muglia
• CTOは元OracleのRACのLead ArchitectのBenoit Dagevilleで、並列データベース
の研究で博士号を取得、80以上の特許を保有
• Founder Architectは元Oracleでオプティマイザ/並列実行のグループのLeadの
Thierry Cruanesで、データベースの研究で博士号を取得、40以上の特許を保有
• Co-FounderのMarcin Zukowskiは世界最速といわれるカラムナーデータベース
Vectorwise(現Actian Vector)を開発したデータベースアーキテクト
• VP of Engeneeringは元MicrosoftのGM、Facebookのデータインフラチームの
LeadのSameet Agarwalで、世界最大規模のHadoop環境を構築し、Hive、Presto、
Scubaなどのテクノロジーをインキュベート
• 数多くの調査会社のレポートで高評価
• ForresterWave「BigDataWarehouse Q2 2017」にて、低コスト、ハイパフォーマンス、
スケーラブルなDWHとしてStrong Performerと評価
• Gartner「Critical Capabilities for Data Management Solutions for Analytics(16
March 2017)」のVendors’ Product Scores for the Traditional Data Warehouse Use
CaseにてBigQueryよりも高評価
• Gartner「Magic Quadrant for Data Management Solution for Analytics (20
February 2017)」にてNiche Playersと評価
• Cloud Nativeなデータウェアハウスを提供しており、現状AWSでのみサービスを
展開しているが、来年Microsoft Azureでもサービス開始予定
• オフィシャルには日本での利用をサポートをしておらず実績なし(2017/9/22時点)

7. 6
2. Snowflakeとは ～DWHに求められる機能～
• すぐに簡単に始められる(Evaluating Time to Value)
• 使用した分だけ支払う(Usage-based pricing)
• 標準SQL(Standard SQL)
• スケーラビリティ(Scalability)、弾力性(Elasticity)、高性能(High Performance)
• データ共有(Data Sharing)
• 高可用性(High availability)
• バックアップ/リカバリ(Backup/Recovery)、クローン(Clone)
• セキュリティ(Security)
• 運用管理作業の低減(Self-managing services)

8. 7
2. Snowflakeとは ～Snowflakeの特徴(1/2)～
• すぐに簡単に始められる(Evaluating Time to Value)
• ETLなしでも簡単にデータをロード可能
• 半構造化データも扱えて1つのデータベースに統合可能
• 使用した分だけ支払う(Usage-based pricing)
• 秒単位の課金
• 最大ワークロードに合わせたキャパシティ不要
• アクセスがない時は自動でサスペンドさせることができ、その間は費用がかからない
• コンピューティング/ストレージリソースを自由に変更可能でき、費用を最適化可能
• 標準SQL(Standard SQL)
• SQL-99の大部分、およびSQL-2003の分析拡張部分をサポート
• スケーラビリティ(Scalability)、弾力性(Elasticity)、高性能(High Performance)
• リアルタイムに処理性能と同時実行性能を変更可能
• 処理量に応じて自動スケールアウト/ダウン
• ワークロードを分離することによる競合の回避、ボトルネックが発生しないアーキテクチャ
• 従来型のDWHと比較して、最大で200倍高速、かつ1/10のコスト

9. 8
2. Snowflakeとは ～Snowflakeの特徴(2/2)～
• データ共有(Data Sharing)
• データ/API連携ではなく、データベースの一部をアクセス制御をかけて、他組織に共有
• 他組織はコンピュートリソースを用意し、データベースアクセス(費用は他組織で負担)
• 高可用性(High availability)
• 複数データセンタにまたがって環境が構築されていて、障害発生時にも迅速な復旧が可能
• バックアップ/リカバリ(Backup/Recovery)、クローン(Clone)
• Table/Schema/Database単位でPoint-in-time Recovery
• 削除してしまったTable/Schema/Databaseの復元も可能
• 過去時点のデータに対してもクエリを実行可能
• 過去時点のTable/Schema/Databaseをクローン可能
• セキュリティ(Security)
• 全ての通信経路、およびデータを暗号化
• 多要素認証
• SAML2.0によるフェデレーションサービス
• SIEMによる監視および通知
• SOC2 Type II、PCI DSS、HIPAAといった第三者によるセキュリティ認証/認定
• 運用管理作業の低減(Self-managing services)
The Data Warehouse Build for
the Cloud

10. 9
3. Snowflakeアーキテクチャ ～アーキテクチャ概要～
• クラウドをベースに構築されたDWHサービスで、Elastic、ハイパフォーマンス、
低価格、かつストレージおよびコンピュートリソースが分離されていることにより
ボトルネックが発生しないのが特徴。
Staging Location(S3バケット)
File
s
File
s
Files
File
s
File
s
Files
File
s
File
s
Files
テーブル
(Object)
S3
EC2
ウェアハウス
SSD
(パーティ
ション
キャッシュ
・・・ SSD
(パーティ
ションキャッ
シュ)
ウェアハウス
SSD
(パーティ
ション
キャッシュ)
・・・ SSD
(パーティ
ション
キャッシュ)
・・・
リザルトキャッシュ
オンライン用
Warehouse
バッチ用
Warehouse
リザルトキャッシュ クラウド
サービス
認証、認可
インフラ
管理
Web管理
ツール
オプティマ
イザ
トランザク
ション管理
セキュリ
ティ
ステージ(Object)
メタデータ

11. 10
3. Snowflakeアーキテクチャ ～ステージ～
• ユーザ・ステージ、テーブル・ステージ、インターナル・
ネームドステージの3種類が存在
– ユーザステージ(@~)
ユーザ固有のファイルを格納するために用意されている
ステージング領域
– テーブルステージ(@<table_name>)
テーブルごとに用意されているステージング領域
– インターナルネームドステージ(@<stage_name>)
最も柔軟性があるステージング領域で、必要に応じて作成する必要があるステージ
ング領域で、複数ユーザでロードしたり、複数テーブルにロードする際に使用する
• データベースに登録したいファイルをPUTコマンドでステージング領域に格
納した後、COPY INTOコマンドでステージング領域からデータベーステーブ
ルにロード
• S3に格納されているデータであれば、COPY INTOコマンドでステージング領
域を経由して直接データベーステーブルにロード可能
• ロードファイルは10～100MBに分割しておいた方がパフォーマンスを上げる
ことが可能
• データロードだけでなく、ステージ、もしくはS3にアンロード可能
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

12. 11
3. Snowflakeアーキテクチャ ～テーブル(1/3)～
＜マイクロパーティション＞
• 従来型のデータウェアハウスでは、パフォーマンスと
スケーラビリティを実現するために、テーブルを静的
パーティショニングで分割
₋ 指定する分散キーによっては、データが不均衡になる
₋ メンテナンスに手間がかかる
• Snowflakeでは、テーブル内のデータが複数行単位で自動分割され、それぞれマイ
クロパーティションにマッピングされる
₋ ユーザが明示的にデータ分割方式を定義する必要がない
• 圧縮前で50～500MB(Snowflake内では圧縮される)に
分割されるため、クエリ高速化するためのプルーニング、
DMLの効率化が可能
• マイクロパーティション内で列ごとに個別に格納、
圧縮される
Country Product Revenue
US Camera 3,000
US TV 1,250
JP Camera 700
US Video 2,000
JP TV 500
UK TV 450
■テーブルイメージ
PRODUCT_REVENUEテーブル
Micro
Partition1
(row3,5,6)
Country
JP
JP
UK
Product
Camera
TV
TV
Revenue
700
500
450
Micro
Partition2
(row1,2,4)
Country
US
US
US
Product
Camera
TV
Video
Revenue
3,000
1,250
2,000
■マイクロパーティション
物理格納イメージ
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

13. 12
3. Snowflakeアーキテクチャ ～テーブル(2/3)～
＜クラスタリングキー＞
• データ格納時に、日付などの列は自動的にソートされて格納
されるが、クラスタリングキーを定義することで、マイクロ
パーティション内のデータの並び順を明示的に制御することが可能
₋ カーディナリティが高いWHERE句で指定される列や結合列を指定することで、クエリの
スキャン効率や列圧縮率を高めることが可能
₋ 明示的にRECLUSTER句を指定したALTER TABLEコマンドを実行することで、テーブル
を再クラスタリング可能
＜永続テーブル/トランジエントテーブル/テンポラリテーブル＞
• 永続テーブルは、ユーザが明示的に削除するまでデータが保持され、タイムトラ
ベル&リカバリが可能
• トランジエントテーブルは、ユーザが明示的に削除するまでデータが保持され、
タイムトラベルは可能だが、リカバリできない
• テンポラリテーブルは、セッション単位でデータを保持するため他のユーザは参
照できず、タイムトラベルは可能だが、リカバリはできない
Table Type Persistence Time Travel
Retention Period
(Days)
Failsafe Period
(Days)
永続(EE以上) 明示的に削除されるまで 0～90 7
永続(PE以下) 明示的に削除されるまで 0 or 1 7
トランジエント 明示的に削除されるまで 0 or 1 0
テンポラリ セッションの間 0 or 1 0
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

14. 13
3. Snowflakeアーキテクチャ ～テーブル(3/3)～
＜セキュアビュー＞
• セキュアビューを使用することで、ビュー定義、およびビュー
を構成するテーブルへのアクセスを隠蔽した状態であっても、
ユーザが必要なデータにアクセスすることが可能
₋ CURRENT_ACCOUNT、CURRENT_ROLE、CURRENT_USERファンクションを活用する
ことで、セキュアにデータシェアリング(後述)を行うことが可能
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

15. 14
3. Snowflakeアーキテクチャ ～ウェアハウス(1/2)～
• ウェアハウスは、ストレージと分離されたコンピュート
リソースで、クエリやDMLを実行する際に必ず必要
• ウェアハウスが起動している間、エディション、ウェアハウスサ
イズ、クラスタ数に応じてクレジットが消費され、費用がかかる
＜エディション＞
• エディションには、Standard Edition、Premier Edition、Enterprise Edition、
Enterprise Edition for Sensitive Data、Virtual Private Snowflakeがあり、
エディションごとにコンピュートリソースの単価が決められている
₋ 詳細は「4. 参考情報」のエディションごとの機能、サポートレベル、価格を参照
＜ウェアハウスサイズ＞
• ウェアハウスサイズは、クラスタ内のサーバ数を示していて、1サーバのスペックは
「Amazon C3.2XLarge 8 cores, 15 gigs of ram, 160 SSD」
₋ リニアな性能向上を実現 (ウェアハウスサイズを倍にすると、処理時間は1/2)
Warehouse
Size
Servers/
Cluster
Credits/
Hour
Credits/
Seconds
Additional Details
X-Small 1 1 0.0003 CREATE WAREHOUSEコマンド実行時のデフォルトサイズ
Small 2 2 0.0006
Medium 4 4 0.0012
Large 8 8 0.0024
X-Large 16 16 0.0048 Webインタフェースでウェアハウス作成時のデフォルトサイズ
2X-Large 32 32 0.0096
3X-Large 64 64 0.0192
4X-Large 128 128 0.0384
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

16. 15
3. Snowflakeアーキテクチャ ～ウェアハウス(2/2)～
＜クラスタ数＞
• ウェアハウス内でクラスタを複数作成可能(EE以上)
₋ クラスタ数は1～10を指定可能
₋ オートサスペンド(ユーザアクセスがなくなった後何秒でサスペンド
するか設定可能)/オートレジューム可能
₋ 4X-Largeで10クラスタ起動すると、1時間で1,280クレジット(EEの場合3,840ドル)かか
るため、クラスタ数を増やす場合は慎重に!
• ALTER WAREHOUSEコマンドにて、ウェアハウスのサスペンド/レジューム可能
₋ サスペンドしている間は課金されない
₋ ウェアハウスが起動している間のみ秒単位で課金される
• 例えばオンライン/夜間バッチのようにユースケースが異なる処理については、
ウェアハウスを複数作成することでウェアハウス間の競合なく処理を行うことが
可能
• ウェアハウスサイズによって単一処理時間、クラスタ数によって同時実行数を調
整することが可能
• パーティションキャッシュはマイクロパーティションのキャッシュで、ウェアハ
ウス起動後にクエリを実行することで、スキャン対象データがウェアハウスの実
体であるEC2のSSDにキャッシュされる
₋ ウェアハウスの起動/レジューム直後はデータがキャッシュされていないため、初回アク
セスから性能を出したい場合は、ウォームアップも検討する必要あり
₋ 検索対象データが大量な場合は、全てのデータがSSDに載るかも確認が必要
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

17. 16
3. Snowflakeアーキテクチャ ～リザルトキャッシュ～
• クエリの実行結果のキャッシュでS3に格納されている
• クライアントはクラウドサービス経由か直接S3からダウンロード
₋ サイズの上限はない
₋ 性能検証を行う場合はUSE_CACHED_RESULTをFALSEにすることで
リザルトキャッシュを無効化することも検討
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

18. 17
3. Snowflakeアーキテクチャ ～ユーザアクセス～
• 標準SQL
₋ SQL-99の大部分、およびSQL-2003の分析拡張部分をサポート
₋ データ型、SQL構文、事前定義関数
https://docs.snowflake.net/manuals/sql-reference/intro-
summary-sql.html
• ユーザ定義関数
₋ https://docs.snowflake.net/manuals/sql-reference/user-
defined-functions.html
• トランザクションサポート
₋ https://docs.snowflake.net/manuals/sql-
reference/transactions.html
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

19. 18
3. Snowflakeアーキテクチャ ～その他情報～
＜Data Sharing＞
• 従来のデータ連携では、ファイル出力/連携/取り込み、もしくは
APIによる連携が必要だった
• Snowflakeが以下のアーキテクチャを持っていることで、自社DB
と他社DBの一部をセキュリティを担保しつつ、最も効率的に連携することが可能
₋ コンピュートとストレージの疎結合
₋ 強固なメタデータ管理によるアクセス制御
₋ 無制限な同時実行
＜クローン＞
• テーブル、スキーマ、データベース単位でクローニング可能
• タイムトラベル機能と合わせて使用することで、EE以上であれば
最大90日前のクローンも作成可能
＜バックアップ＆リカバリ＞
• 従来型のデータベースでは、多くの場合完全バックアップと増分バックアップを
取得
₋ データストレージの増大
₋ データ再ロード、リカバリ時のビジネスダウンタイム
₋ (場合によって)最後のバックアップ以降のデータ損失
• マルチデータセンタや冗長化アーキテクチャは従来のバックアップの必要性を大
幅に軽減する
• データ破損や紛失の可能性はあるため、効率的で費用対効果の高いバックアップ
の代替手段として、7日間分の回復可能な履歴データ(Failsafe)を自動取得
Staging Location(S3バケット) F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
F
i
l
e
s
テーブル
(Object)
S3
EC2
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
ウェアハウス
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
S
S
D
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンラ
イン用
Wareh
ouse
バッチ
用
Ware
house
リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラ
ンザ
ク
ショ
ン管
理
セ
キュ
リ
ティ
ステージ
(Object)
メタ
デー
タ

20. 19
4. パフォーマンスを考慮した設計 ～性能を引き出すための検討事項(1/2)～
＜Snowflake＞
〇マイクロパーティション
• テーブル内のデータが行単位でマイクロパーティションに自動分割される
• マイクロパーティション内で列ごとに個別に格納、圧縮される
〇クラスタリングキー
• 指定しなかった場合も、日付などの列は自動的にソートされて格納されるが、明示的にカーディナリティが
高いWHERE句で指定される列や結合列を指定することで、クエリのスキャン効率や列圧縮率を高めること
が可能
• 検索効率の高い順番に複数列を指定することで、Oracle Databaseの索引構成表のようにデータが格納され
る
〇パーティションキャッシュ
• クラスタ起動時にはパーティションキャッシュにはデータがロードされず、クエリ実行によって初めてロー
ドされるため、ウォームアップの仕組みを用意しておくことが望ましい
〇リザルトキャッシュ
• 特に何も設定しなくても、リザルトキャッシュは24h有効
• サイズの制限はなし
• 性能検証を実施する際には同じSQLを複数回実行するため、無効化しておく必要あり
〇その他
• ウェアハウスごとの同時実行数(デフォルト：8)はMAX_CONCURRENCY_LEVELで変更可能
⇒ 1処理の目標時間を達成できるまでウェアハウスサイズを大きくし、同時に実行したい処理数に合わせてクラ
スタ数を変更していくことで、性能要件(単一処理性能、同時実行数)を満たすことができる。ピーク時に
ウェアハウスサイズ、およびクラスタ数をElasticに変更することが可能。データベース内でパターンの異な
る処理(軽い処理/重い処理、オンライン/バッチ)がある場合は、ウェアハウスを分けることで、競合なく処
理を共存することが可能。これらを組み合わせることで、性能要件(単一処理性能、同時実行数)に応じてシ
ステム構成を柔軟に変更することができる。価格性能比が良い。

21. 20
4. パフォーマンスを考慮した設計 ～性能を引き出すための検討事項(2/2)～
＜BigQuery＞
〇パーティション分割
• コストに影響のあるスキャン対象データ量を減らすため、ファイル分割や—time-partitioning_typeによっ
てパーティション分割することが可能
⇒ 2,000スロット未満であれば自動で必要なリソース(スロット)を確保して使用してくれるが、調整可能なパラ
メータがなく同時実行性能を出すことが難しい。軽い処理でも一定時間かかるため、マスタをDataStoreに入
れるなどの工夫が必要。大量データ集計を同時実行する場合には、スロット数が足りるかの検証も必要。
＜Redshift＞
○分散キー
• ノード間でのデータ格納方法(EVEN分散、キー分散、ALL分散)を定義
• 再分散を避けるようなデータの持ち方を検討しておくことが重要で、実行計画で再分散の状況を確認できる
が、一番つらいのはDS_BCAST_INNER(全ノードにデータをコピー)
○ソートキー
• ノード内のデータ格納方法(ソート順)を定義し、複数列を指定する場合は順番が重要
• インターリーブドソートキーは複数列を指定する場合に、どの列を検索条件にしてもそれなりの検索性能を
出すためのデータ格納方法を定義する
(データの変動に応じてVACUUM REINDXが必要となるため、多くの場合使用する必然性はない)
○列圧縮方式
• ANALYZE COMPRESSIONを実行するも、ほとんどの列でZSTDが推奨される
○ワークロード管理
• concurrency(デフォルト：5)にて同時実行数、wlm_query_slot_count(デフォルト：1)でクエリに割り当
てるメモリリソースを制御
⇒ テーブルごとに検索条件に指定する列が限られていればよいが、様々な列を指定する場合にはテーブルを非正
規化していると再分散の影響が大きくなる。また、性能を出すには各種パラメータの最適値を導き出すための
試行錯誤が必要となる。クラスタに対する同時実行数の最大が50で、ベストプラクティスとしては15以下と
も言われているため、同時実行には強くない。拡張時のダウンタイムがつらい。 2017/10/18に追加された
dc2.8xlargeはdc1.8xlargeと比べ、価格据え置きで性能2倍ということなので試してみるべき。

22. 21
5. 参考情報(1/4)
＜エディションごとの機能一覧＞

23. 22
5. 参考情報(2/4)
＜エディションごとのセキュリティ認証＞
＜エディションごとのサポートレベル＞

24. 23
5. 参考情報(3/4)
＜エディションごとの価格＞

25. 24
5. 参考情報(4/4)
• ドキュメント
https://docs.snowflake.net
• ブログ
https://www.snowflake.net/blog
https://www.snowflake.net/engineering-blog
• オンラインコミュニティ/サポートポータル
https://support.snowflake.net
• 価格
https://www.snowflake.net/product/pricing
https://docs.snowflake.net/manuals/user-guide/credits.html
https://docs.snowflake.net/manuals/user-guide/warehouses-
multicluster.html
• 各種リソース
https://resources.snowflake.net

26. 25
6. まとめ
• クラウドをベースに構築されたDWHサービスで、Elastic、ハイパフォーマンス、
低価格、かつストレージおよびコンピュートリソースが分離されていることにより
ボトルネックが発生しないのが特徴。
Staging Location(S3バケット)
File
s
File
s
Files
File
s
File
s
Files
File
s
File
s
Files
テーブル
(Object)
S3
EC2
ウェアハウス
SSD
(パーティ
ション
キャッシュ
・・・ SSD
(パーティ
ションキャッ
シュ)
ウェアハウス
SSD
(パーティ
ション
キャッシュ)
・・・ SSD
(パーティ
ション
キャッシュ)
・・・
リザルトキャッシュ
オンライン用
Warehouse
バッチ用
Warehouse
リザルトキャッシュ クラウド
サービス
認証、認可
インフラ
管理
Web管理
ツール
オプティマ
イザ
トランザク
ション管理
セキュリ
ティ
ステージ(Object)
メタデータ