More Related Content Similar to Snowflake Architecture and Performance(db tech showcase Tokyo 2018) (20) Snowflake Architecture and Performance(db tech showcase Tokyo 2018)4. 3
1. 自己紹介
• Name
- 本橋 峰明(Mineaki Motohashi)
• Contact
- mineaki.motohashi@gmail.com
• Job
- データベースベンダにて、技術コンサルティング、プリセールス、新入社員教育
- コンサルティングファームにて、セキュリティ関連のコンサルティング、
ERP基盤関連を中心に構想立案から提案、構築、運用
- 事業会社にて、ID-POSシステムの設計/開発/運用、プロジェクト/ベンダ管理、技術検証
- 現職にて、デジタルトランスフォーメーションに関するITコンサルティング
• Database Experience
- Oracle Database、Microsoft SQL Server、Postgres、MySQL、Pivotal Greenplum、Google
BigQuery/Cloud Spanner、HPE Vertica、AWS Redshift、MemSQL、Snowflake、SAP HANA
• Contents
- https://www.slideshare.net/mmotohas/
Snowflake Elastic Data Warehouse as a Service
アカウント登録、データベース作成/ロード/検索手順、Webコンソール
Snowflake Architecture and Performance(本資料)
設計/管理/運用する上で必要となるアーキテクチャ、パフォーマンスを考慮した設計方法
• Residence
- 厚木
• Hobby
- ボウリング、バドミントン
7. 6
従来型DWHの限界
• 従来型DWHはダイナミックな弾力性(Elasticity)を提供できる設計がされていない。
- アプライアンス製品は、ベストプラクティスに基づいて決められた構成
- ソフトウェア製品は、かなりの運用作業を伴うため、真に弾力性を持つとは言いがたい
- クラウドサービスは、ソフトウェア製品をクラウド環境に移植しただけのものが多い
• 共有ディスクアーキテクチャ vs 非共有アーキテクチャ(昔話の再掲)
- 共有ディスクアーキテクチャは、ノード数が増えると、ストレージとネットワークがボトル
ネックとなりうる
- 非共有ディスクアーキテクチャは、複数ノードへの最適なデータ配分や、データ再分散がボト
ルネックとなりうる
• Snowflakeは、ストレージとコンピュートリソースを
物理的に分離しつつ、論理的に統合した新しいアーキ
テクチャを実現
• クラウドを前提として、一からデータベースを開発
- スクラッチでデータベースを開発できるエンジニアは世界中
で50人程度と言われているが、そのうち20~30人程度が
Snowflake Computingに在籍
- 経営陣だけでもデータベースに関する130以上の特許を保有
The Data Warehouse Build for the Cloud
8. 7
Snowflakeと他社DWHとのベンチマーク (1/2)
• ETLツールベンダであるFivetranが顧客からどのDWHを選択すればよいか頻繁に聞か
れることから、メジャーなDWH製品(Amazon Redshift、Snowflake、Azure SQL Data
Warehouse、Presto、Google BigQuery)のTPC-DSベンチマークを実施
• 100GBおよび1TBのデータセットに対して、99のクエリをそれぞれ実行し、実行時間とコスト
を計測
• 計測条件、結果の詳細は以下を参照
https://fivetran.com/blog/warehouse-benchmark
• ベンチマークに使用したソースコードは、GitHubに公開
https://fivetran.com/blog/warehouse-benchmark
• SnowflakeのサンプルデータベースにはTPC-DSの10TB、100TBスケールのデータセットが用意
されている
Data Warehouse
100GB Scale 1TB Scale
Configuration Cost/h Configuration Cost/h
Redshift dc2.large×8 $2.00 dc2.8xlarge×4 $19.20
Snowflake X-Small $2.00 Large $16.00
Azure
Data Warehouse
DW200 $2.42 DW1500c $18.12
Presto n1-standard-8×4 $1.23 n1-standard-8×32 $9.82
BigQuery On-demand - On-demand -
9. 8
Snowflakeと他社DWHとのベンチマーク (2/2)
• TPC-DSの99クエリをそれぞれ実行した際の実行時間、コストの相乗平均を算出
• 100GBスケール、1TBスケール双方において、Snowflakeが他のDWHと比べて価格性
能比で圧倒
Data
Warehouse
100GB Scale 1TB Scale
Query
Performance
(Geomean)
Cost
Performance
×Cost
Query
Performance
(Geomean)
Cost
Performance
×Cost
Redshift 19.54s $0.06 1.172 21.50s $0.637 13.696
Snowflake 6.12s $0.019 0.116 10.74s $0.265 2.846
Azure
Data
Warehouse
20.94s $0.078 1.633 10.13s $0.284 2.877
Presto 10.31s $0.02 0.206 14.78s $0.224 3.311
BigQuery 8.10s $0.034 0.275 14.32s $0.305 4.368
10. 9
Snowflake Computing
• 2012年に創業し翌年から毎年資金調達、調達総額は$473M(約630億円)で、評価額
は$1.5B(約1,650億円)となり、アメリカで2018年初めてのユニコーン企業
• 過去1年で顧客ベースは300%増加し、Snowflakeに保存されている顧客データは4倍
• 経営陣の顔ぶれがデータベース業界の重鎮
- CEOは元MicrosoftのAzureも含むServer/Toolsビジネスを牽引していたBob Muglia
- CTOは元OracleのRACのLead ArchitectのBenoit Dageville
- Founder Architectは元OracleでOptimizationグループのLeadのThierry Cruanes
- 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 (13 February 2018)」にて
Challengerと評価(2017年はNiche Player)
• Looker、Tableau、Informatica、TreasureDataなど様々なツールが次々対応
• アメリカではかなりの認知度で、2017年のAWS re:Inventではプラチナスポンサー
• 2018/2/21にシドニー、メルボルンにAsia Pacific and Japanオフィスを開設
• もともとAWS上でCloud NativeなDWHサービスを展開していたが、2018/7/12より
Azure上でもサービスを開始
11. 10
DWHに求められる機能と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)
- リアルタイムに処理性能と同時実行性能を変更可能
- 処理量に応じて自動スケールアウト/ダウン
- ワークロードを分離することによる競合の回避、ボトルネックが発生しない
アーキテクチャ、制限なしの同時実行性能(Unlimited Concurrency)
- 従来型のDWHと比較して、最大で200倍高速、かつ1/10のコスト
12. 11
DWHに求められる機能と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)
16. 15
ステージ
• ユーザ・ステージ、テーブル・ステージ、インターナル・
ネームドステージの3種類が存在
- ユーザステージ(@~)
ユーザ固有のファイルを格納するために用意されているステージング領域
- テーブルステージ(@%<table_name>)
テーブルごとに用意されているステージング領域
- インターナルネームドステージ(@<stage_name>)
最も柔軟性があるステージング領域で、必要に応じて作成する必要があるステージング領域
で、複数ユーザでロードしたり、複数テーブルにロードする際に使用する
• データベースに登録したいファイルをPUTコマンドでステージング領域に格納した
後、COPY INTOコマンドでステージング領域からデータベーステーブルにロード
• S3に格納されているデータであれば、COPY INTOコマンドでステージング領域を
経由して直接データベーステーブルにロード可能
• ロードファイルを10~100MBに分割した方がパフォーマンス向上可能
• データロードだけでなく、ステージ、もしくはS3にアンロード可能
• Snowpipeを使うことで、取り込み処理をサーバレスで行うことが可能
₋ 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
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンライ
ン用
Warehou
se
バッチ
用
Wareho
use リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラン
ザク
ショ
ン管
理
セ
キュ
リティ
ステージ(Object)
メタ
デー
タ
17. 16
テーブル(1/3)
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
(
パ
ー
テ
ィ
シ
ョ
ン
キ
ャ
ッ
シ
ュ
)
・
・
・
リザルトキャッシュ
オンライ
ン用
Warehou
se
バッチ
用
Wareho
use リザルトキャッシュ クラウド
サービス
認証、
認可
イン
フラ
管理
Web
管理
ツー
ル
オプ
ティ
マイ
ザ
トラン
ザク
ショ
ン管
理
セ
キュ
リティ
ステージ(Object)
メタ
デー
タ
<マイクロパーティション>
• 従来型のデータウェアハウスでは、パフォーマンスと
スケーラビリティを実現するために、テーブルを静的
パーティショニングで分割
₋ 指定する分散キーによっては、データが不均衡になる
₋ メンテナンスに手間がかかる
• 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
マイクロパーティション物理格納イメージ
26. 25
Receive $400 worth of free usage for 30-days!
• 費用がかかるのは、ウェアハウス(コンピュート)とストレージの2種類
• ウエアハウスは起動している間、ウェアハウスサイズ、クラスタ数、エディショ
ンに応じて「クレジット」が消費され、秒単位で課金される
• 1サーバのスペックは「Amazon C3.2XLarge 8 cores, 15 gigs of ram, 160 SSD」
• Enterprise Editionで利用できるマルチクラスタウェアハウスを使うと、10クラス
タまで起動することが可能
• 料金体系としては、秒単位の従量課金であるオンデマンド、事前に購入するクレ
ジット数に合わせた割引が適用されるキャパシティの2種類
• リージョンによって費用が変わるが、レイテンシと費用を考慮すると、AWS-US
Westがおすすめ
Warehouse
Size
Servers
/Cluster
Credits/h
X-Small 1 1
Small 2 2
Medium 4 4
Large 8 8
X-Large 16 16
2X-Large 32 32
3X-Large 64 64
4X-Large 128 128
Standard
Edition
Premier
Edition
Enterprise
Edition
Enterprise
Edition for
Sensitive
Data
Virtual
Private
Snowflake
オンデマンド – US
コンピュート $2.00/hr $2.25/hr $3.00/hr $4.00/hr Contact
ストレージ $40/TB/mo Contact
キャパシティ – US
コンピュート Contact Contact Contact Contact Contact
ストレージ $23/TB/mo Contact
■サーバ/クラスタ数とクレジットの関係 ■クレジットあたりの費用(USリージョンの場合)
28. 27
性能を引き出すための検討事項(Snowflake)(1/2)
〇設計のキーとなる項目
• マイクロパーティション
₋ テーブル内のデータが行単位でマイクロパーティションに自動分割される
₋ マイクロパーティション内で列ごとに個別に格納、圧縮される
• クラスタリングキー
₋ 指定しなかった場合も、日付などの列は自動的にソートされて格納されるが、
明示的にカーディナリティが高いWHERE句で指定される列や結合列を指定す
ることで、クエリのスキャン効率や列圧縮率を高めることが可能
₋ 検索効率の高い順番に複数列を指定することで、Oracle Databaseの索引構成
表のようにデータが格納される
• パーティションキャッシュ
₋ クラスタ起動時にはパーティションキャッシュにはデータがロードされず、
クエリ実行によって初めてロードされるため、ウォームアップの仕組みを用
意しておくことが望ましい
• リザルトキャッシュ
₋ 特に何も設定しなくても、リザルトキャッシュは24h有効
₋ サイズの制限はなし
₋ 性能検証を実施する際には同じSQLを複数回実行するため、無効化しておく
必要あり
• その他
₋ クラスタごとの同時実行数(デフォルト:8)はMAX_CONCURRENCY_LEVEL
で変更可能
31. 30
性能を引き出すための検討事項(Redshift)(1/2)
〇設計のキーとなる項目
• 分散キー
₋ ノード間でのデータ格納方法(EVEN分散、キー分散、ALL分散)を定義
₋ 再分散を避けるようなデータの持ち方を検討しておくことが重要で、実行計画
で再分散の状況を確認できるが、一番つらいのはDS_BCAST_INNER(全ノー
ドにデータをコピー)
• ソートキー
₋ ノード内のデータ格納方法(ソート順)を定義し、複数列を指定する場合は順番
が重要
₋ インターリーブドソートキーは複数列を指定する場合に、どの列を検索条件に
してもそれなりの検索性能を出すためのデータ格納方法を定義する
(データの変動に応じてVACUUM REINDXが必要となるため、多くの場合使用
する必然性はない)
• 列圧縮方式
₋ ANALYZE COMPRESSIONを実行するも、ほとんどの列でZSTDが推奨される
• ワークロード管理
₋ concurrency(デフォルト:5)にて同時実行数、wlm_query_slot_count(デフォ
ルト:1)でクエリに割り当てるメモリリソースを制御