Snowflake Architecture and Performance

0
Snowflake
Architecture and Performance
本橋峰明
Mineaki Motohashi
6 Feb. 2018

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

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
₋ ボウリング、バドミントン

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

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

5
2. Snowflakeとは～Snowflake Computing～
• 2012年に創業し翌年から毎年資金調達、直近は1/25に$263M(約290億円)を調達し、
調達総額は$473M(約630億円)で、評価額は$1.5B(約1,650億円)
https://www.snowflake.net/disruption-as-stepping-stone/
https://www.snowflake.net/news-items/snowflake-closes-263-million-growth-funding/
• 過去1年で顧客ベースは300%増加し、Snowflakeに保存されている顧客データは4倍
• Looker、Tableau、Informatica、TreasureDataなど様々なツールが次々対応
• 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」にて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と評価
• これまでAWSでのみCloud NativeなDWHサービスを展開していたが、2018/2/2か
らAzure BLOB Storageとのインテグレーション機能を提供開始
• 2017/9/22時点では日本での実績なしとのことだったが、現時点ではある模様

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)

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

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)

9
2. Snowflakeとは～Snowflakeの設計思想～
データベースの在り方を根本的に変える設計思想
• 一般的なDWHに関するデータフローは、
• 複数のソースDBからデータを抽出して、何らかのストレージに転送し、そこ
からDWHにデータを取り込む
• さらに、DWHから分析用DBなど、組織外含めてさまざまなシステムにデータ
を連携(抽出、転送、取込)して、活用することになり、結局同じデータが複数
箇所に散在する
• 組織におけるデータプラットフォームの課題は、
• 組織内であればあるデータは本来1箇所にだけあれば良いが、様々なシステム
が同一DBにアクセスすると互いの処理が干渉し合って、性能が出なくなるた
め、やむを得ずデータベースを分けている
• 組織外にデータを連携するケースもデータプロバイダであればかなりの数にな
り、抽出バッチのスケジュールにも空きがなくなってくる
Single Database Platform of Truth
• Data Sharing、Secure Viewという機能を使うことでSingle Database Platform of
Truthを実現
• システムごとにコンピュートリソースを用意することで、同一データにアクセスしても
競合は発生しないアーキテクチャ

10
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
クラスタ1
SSD
(パーティ
ション
キャッシュ
・・・
クラスタn
SSD
(パーティ
ションキャッ
シュ)
クラスタ
SSD
(パーティションキャッシュ)
リザルトキャッシュ
オンライン用
Warehouse
バッチ用
Warehouse
リザルトキャッシュクラウド
サービス
認証、認可
インフラ
管理
Web管理
ツール
オプティマ
イザ
トランザク
ション管理
セキュリ
ティ
ステージ(Object)
メタデータ
ウェアハウスウェアハウス

11
3. Snowflakeアーキテクチャ～ステージ～
• ユーザ・ステージ、テーブル・ステージ、インターナル・
ネームドステージの3種類が存在
– ユーザステージ(@~)
ユーザ固有のファイルを格納するために用意されている
ステージング領域
– テーブルステージ(@<table_name>)
テーブルごとに用意されているステージング領域
– インターナルネームドステージ(@<stage_name>)
最も柔軟性があるステージング領域で、必要に応じて作成する必要があるステージ
ング領域で、複数ユーザでロードしたり、複数テーブルにロードする際に使用する
• データベースに登録したいファイルをPUTコマンドでステージング領域に格
納した後、COPY INTOコマンドでステージング領域からデータベーステーブ
ルにロード
• S3に格納されているデータであれば、COPY INTOコマンドでステージング領
域を経由して直接データベーステーブルにロード可能
• ロードファイルは10～100MBに分割しておいた方がパフォーマンスを上げる
ことが可能
• データロードだけでなく、ステージ、もしくはS3にアンロード可能
• Snowpipeを使うことで、以下の2パターンの取り込み処理をサーバレスで行
うことが可能
₋ S3バケットからAmazon SQS通知をトリガとしてのデータロード
₋ REST APIをトリガとしてのデータロード
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
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
■マイクロパーティション
物理格納イメージ
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
＜クラスタリングキー＞
• データ格納時に、日付などの列は自動的にソートされて格納
されるが、クラスタリングキーを定義することで、マイクロ
パーティション内のデータの並び順を明示的に制御することが可能
₋ カーディナリティが高い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
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
＜Secure View＞
• Secure Viewを使用することで、ビュー定義、およびビュー
を構成するテーブルへのアクセスを隠蔽した状態であっても、
ユーザが必要なデータにアクセスすることが可能
₋ CURRENT_ACCOUNT、CURRENT_ROLE、CURRENT_USERファンクションを活用する
ことで、セキュアにデータシェアリング(後述)を行うことが可能
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
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
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
3. Snowflakeアーキテクチャ～ウェアハウス(2/2)～
＜クラスタ数＞
• ウェアハウス内でクラスタを複数作成可能(EE以上)
₋ クラスタ数は1～10を指定可能
₋ オートサスペンド(ユーザアクセスがなくなった後何秒でサスペンド
するか設定可能)/オートレジューム可能
₋ 4X-Largeで10クラスタ起動すると、1時間で1,280クレジット(EEの場合3,840ドル)かか
るため、クラスタ数を増やす場合は慎重に!
• ALTER WAREHOUSEコマンドにて、ウェアハウスのサスペンド/レジューム可能
₋ サスペンドしている間は課金されない
₋ ウェアハウスが起動している間のみ秒単位で課金される
• 例えばオンライン/夜間バッチのようにユースケースが異なる処理については、
ウェアハウスを複数作成することでウェアハウス間の競合なく処理を行うことが
可能
• ウェアハウスサイズによって単一処理時間、クラスタ数によって同時実行数を調
整することが可能
• パーティションキャッシュはマイクロパーティションのキャッシュで、ウェアハ
ウス起動後にクエリを実行することで、スキャン対象データがウェアハウスの実
体であるEC2のSSDにキャッシュされる
₋ ウェアハウスの起動/レジューム直後はデータがキャッシュされていないため、初回アク
セスから性能を出したい場合は、ウォームアップも検討する必要あり
₋ 検索対象データが大量な場合は、全てのデータがSSDに載るかも確認が必要
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
3. Snowflakeアーキテクチャ～リザルトキャッシュ～
• クエリの実行結果のキャッシュでS3に24時間格納されている
• クライアントはクラウドサービス経由か直接S3からダウンロード
₋ サイズの上限はない
₋ 性能検証を行う場合はUSE_CACHED_RESULTをFALSEにすることで
リザルトキャッシュを無効化することも検討
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
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
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
3. Snowflakeアーキテクチャ～その他情報～
＜Data Sharing＞
• 従来のデータ連携では、ファイル出力/連携/取り込み、もしくは
APIによる連携が必要だった
• Snowflakeが以下のアーキテクチャを持っていることで、自社DB
と他社DBの一部をセキュリティを担保しつつ、最も効率的に連携することが可能
₋ コンピュートとストレージの疎結合
₋ 強固なメタデータ管理によるアクセス制御
₋ 無制限な同時実行
＜クローン＞
• テーブル、スキーマ、データベース単位でクローニング可能
• クローンは数秒で完了し、かつ追加のストレージコストは発生しない
• タイムトラベル機能と合わせて使用することで、EE以上であれば
最大90日前のクローンも作成可能
＜バックアップ＆リカバリ＞
• 従来型のデータベースでは、多くの場合完全バックアップと増分バックアップを
取得
₋ データストレージの増大
₋ データ再ロード、リカバリ時のビジネスダウンタイム
₋ (場合によって)最後のバックアップ以降のデータ損失
• マルチデータセンタや冗長化アーキテクチャは従来のバックアップの必要性を大
幅に軽減する
• データ破損や紛失の可能性はあるため、効率的で費用対効果の高いバックアップ
の代替手段として、7日間分の回復可能な履歴データ(Failsafe)を自動取得
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
4. パフォーマンスを考慮した設計～性能を引き出すための検討事項(1/4)～
＜Snowflake＞
〇設計のキーとなる項目
• マイクロパーティション
₋ テーブル内のデータが行単位でマイクロパーティションに自動分割される
₋ マイクロパーティション内で列ごとに個別に格納、圧縮される
• クラスタリングキー
₋ 指定しなかった場合も、日付などの列は自動的にソートされて格納されるが、
明示的にカーディナリティが高いWHERE句で指定される列や結合列を指定す
ることで、クエリのスキャン効率や列圧縮率を高めることが可能
₋ 検索効率の高い順番に複数列を指定することで、Oracle Databaseの索引構
成表のようにデータが格納される
• パーティションキャッシュ
₋ クラスタ起動時にはパーティションキャッシュにはデータがロードされず、
クエリ実行によって初めてロードされるため、ウォームアップの仕組みを用
意しておくことが望ましい
• リザルトキャッシュ
₋ 特に何も設定しなくても、リザルトキャッシュは24h有効
₋ サイズの制限はなし
₋ 性能検証を実施する際には同じSQLを複数回実行するため、無効化しておく
必要あり
• その他
₋ クラスタごとの同時実行数(デフォルト：8)はMAX_CONCURRENCY_LEVEL
で変更可能

21
〇設計のポイント
• 1処理の目標時間を達成できるまでウェアハウスサイズを大きくし、同時に実行
したい処理数に合わせてクラスタ数を変更していくことで、性能要件(単一処理
性能、同時実行数)を満たすことができる。
• ピーク時にウェアハウスサイズ、およびクラスタ数をElasticに変更することが
可能。データベース内でパターンの異なる処理(軽い処理/重い処理、オンライ
ン/バッチ)がある場合は、ウェアハウスを分けることで、競合なく処理を共存
することが可能。これらを組み合わせることで、性能要件(単一処理性能、同時
実行数)に応じてシステム構成を柔軟に変更することができる。

22
＜BigQuery＞
• パーティション分割
₋ コストに影響のあるスキャン対象データ量を減らすため、ファイル分割や—
time-partitioning_typeによってパーティション分割することが可能
• 2,000スロット未満であれば自動で必要なリソース(スロット)を確保して使用し
てくれるが、調整可能なパラメータがなく同時実行性能を出すことが難しい。
軽い処理でも一定時間かかるため、マスタをDataStoreに入れるなどの工夫が必
要。大量データ集計を同時実行する場合には、スロット数が足りるかの検証も
必要。
＜Redshift＞
• 分散キー
₋ ノード間でのデータ格納方法(EVEN分散、キー分散、ALL分散)を定義
₋ 再分散を避けるようなデータの持ち方を検討しておくことが重要で、実行計画
で再分散の状況を確認できるが、一番つらいのはDS_BCAST_INNER(全ノー
ドにデータをコピー)

23
• ソートキー
₋ ノード内のデータ格納方法(ソート順)を定義し、複数列を指定する場合は順番
が重要
₋ インターリーブドソートキーは複数列を指定する場合に、どの列を検索条件に
してもそれなりの検索性能を出すためのデータ格納方法を定義する
(データの変動に応じてVACUUM REINDXが必要となるため、多くの場合使用
する必然性はない)
• 列圧縮方式
₋ ANALYZE COMPRESSIONを実行するも、ほとんどの列でZSTDが推奨される
• ワークロード管理
₋ concurrency(デフォルト：5)にて同時実行数、wlm_query_slot_count(デ
フォルト：1)でクエリに割り当てるメモリリソースを制御
• テーブルごとに検索条件に指定する列が限られていればよいが、様々な列を指
定する場合にはテーブルを非正規化していると再分散の影響が大きくなる。
• 性能を出すには各種パラメータの最適値を導き出すための試行錯誤が必要。
• クラスタに対する同時実行数の最大が50で、ベストプラクティスとしては15以
下とも言われているため、同時実行には強くない。
• 拡張時のダウンタイムがつらい。
• 2017/10/18に追加されたdc2.8xlargeはdc1.8xlargeと比べ、価格据え置きで
性能2倍ということなので試してみるべき。

24
5. まとめ
データベースの在り方を根本的に変える設計思想
• これまで、1つのデータベースに対して異なるワークロードを実行していたため、ワーク
ロード管理が難しく性能を出すことが難しかった。
• コンピュートリソースとストレージが分離されたことで、1つのデータベースで競合しない
複数のコンピュートリソースを割り当てることができるようになった。
• 検索対象のデータはS3ではなく、コンピュートリソースのSSDにキャッシュとして保持さ
れるため、データも競合しない。Unlimited Concurrency
• 競合が発生していたために、用途ごとにデータベースを用意し、データを重複保持してい
たが、開発環境以外は1つのデータベースのみの運用とすることが可能。
• 他の組織へのデータ連携も不要となり、ライブデータをセキュアに組織を跨いで共有可能。
ぜひ試してみて下さい！
• これまでにないアーキテクチャで、性能要件に合わせて柔軟に環境を用意することができ
るのと、データベースを用途ごとに複数用意する必要がありません。また、AWS上で動作
するクラウドデータウェアハウスなので、AWSの1サービスとして他のサービスと組み合
わせて使うことが可能です。
• ベンダとしては、Azureでも使えるようにしたり、AWSの対応リージョンを増やしたり、
機能をより充実させたりしていますが、日本への進出は手探り状態のようです。皆さんに
使ってもらえれば日本市場も意識するようになると思います。期待できそうだなと思った
方は拡散だけでもお願いします！まずは、多くの人に知ってもらいたいと思っています。
• また、実際に使ってみて感想などを共有頂けるとありがたいです。頂いたコメントはベン
ダにもフィードバックしたいと思います。

25
Appendix. エディションの説明(1/3)
＜エディションごとの機能一覧＞

26
＜エディションごとのセキュリティ認証＞
＜エディションごとのサポートレベル＞

27
＜エディションごとの価格＞

28
Appendix. 参考URL
• ドキュメント
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

Snowflake Architecture and Performance

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Snowflake Architecture and Performance

Similar a Snowflake Architecture and Performance (20)

Último

Último (10)

Snowflake Architecture and Performance