Snowflake Architecture and Performance(db tech showcase Tokyo 2018)
•
8 likes•12,638 views
db tech showcase Tokyo 2018の発表スライドです。以前にアップロードしている「Architecture and Performance」の内容をアップデートしています。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Snowflake Architecture and Performance(db tech showcase Tokyo 2018)
Similar to Snowflake Architecture and Performance(db tech showcase Tokyo 2018) (20)
Recently uploaded
Recently uploaded (10)
Snowflake Architecture and Performance(db tech showcase Tokyo 2018)
- 1. 2018年9月20日 株式会社シグマクシス 本橋 峰明 クラウド環境をベースに一からスクラッチで開発した Transactional SQL Data Warehouse「Snowflake」の ここがスゴい！
- 2. 1 Agenda 1. 自己紹介 2. Snowflakeとは 最近の大量データ処理基盤 従来型DWHの限界 Snowflakeと他社DWHとのベンチマーク Snowflake Computing DWHに求められる機能とSnowflakeの特長 Snowflakeの設計思想 3. Snowflakeアーキテクチャ アーキテクチャ概要 ステージ テーブル ウェアハウス リザルトキャッシュ ユーザアクセス その他情報 4. 価格 5. パフォーマンスを考慮した設計 (Snowflake/BigQuery/Redshift) 6. まとめ 7. 参考情報
- 3. 2 1. 自己紹介
- 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 - ボウリング、バドミントン
- 6. 5 最近の大量データ処理基盤 • 大量処理にはHadoop/Sparkベースのソリューションが向いていると分類される ことが多いが、本当にそうなのか？ • AWS Redshift、Google BigQuery、HPE Vertica、Pivotal Greenplumを始め、 様々な分散データベースが存在するが、良し悪しや向き不向きは？ • 様々な大量データ処理基盤が存在するが、性能と使いやすさを両立する基盤は ないのか？
- 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)
- 13. 12 Snowflakeの設計思想 データベースの在り方を根本的に変える設計思想 • 一般的なDWH周辺のデータフロー - 複数のソースDBからデータを抽出して、何らかのストレージに転送し、そこから DWHにデータを取り込む - さらに、DWHから分析用DBなど、組織外含めてさまざまなシステムにデータを 連携(抽出、転送、取込)して、活用することになり、結局同じデータが複数箇所 に散在する • 組織におけるデータプラットフォームの課題 - 組織内であればあるデータは本来1ヵ所にだけあれば良いが、様々なシステムが 同一DBにアクセスすると互いの処理が干渉し合って、性能が出なくなるため、 やむを得ずデータベースを分けている - 組織外にデータを連携するケースもデータプロバイダであればかなりの数になり、 抽出バッチのスケジュールにも空きがなくなってくる Single Database Platform of Truth • Data Sharing、Secure Viewという機能を活用することでデータを2重持ちせず、1ヵ所 で管理することが可能 • ワークロードごとにコンピュートリソースを用意することで、同一データにアクセスし ても競合は発生しないアーキテクチャ
- 15. 14 アーキテクチャ概要 • クラウド(*1)をベースに構築された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) メタデータ ウェアハウスウェアハウス (*1) Azureでも提供されているが、図はAWSの例
- 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 マイクロパーティション物理格納イメージ
- 18. 17 テーブル(2/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) メタ デー タ ＜クラスタリングキー＞ • データ格納時に、日付などの列は自動的にソートされて格納 されるが、クラスタリングキーを定義することで、マイクロ パーティション内のデータの並び順を明示的に制御することが可能 ₋ カーディナリティが高い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
- 19. 18 テーブル(3/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) メタ デー タ ＜Secure View＞ • Secure Viewを使用することで、ビュー定義、およびビュー を構成するテーブルへのアクセスを隠蔽した状態であっても、 ユーザが必要なデータにアクセスすることが可能 ₋ CURRENT_ACCOUNT、CURRENT_ROLE、CURRENT_USERファンクションを活用するこ とで、セキュアにデータシェアリング(後述)を行うことが可能
- 20. 19 ウェアハウス(1/2) 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) メタ デー タ • ウェアハウスは、ストレージと分離されたコンピュート リソースで、クエリやDMLを実行する際に必ず必要 • ウェアハウスが起動している間、エディション、ウェアハウスサ イズ、クラスタ数に応じてクレジットが消費され、費用がかかる • ウェアハウスサイズは、クラスタ内のサーバ数を示していて、1サーバのスペックは 「Amazon c3.2xLarge 8 cores, 15 gigs of ram, 160 SSD」 ₋ リニアな性能向上を実現 (ウェアハウスサイズを倍にすると、処理時間は1/2) ＜エディション＞ • エディションには、Standard Edition、Premier Edition、Enterprise Edition、 Enterprise Edition for Sensitive Data、Virtual Private Snowflakeがあり、 エディションごとにコンピュートリソースの時間あたりの単価が決められている ₋ 詳細は「4. 価格」を参照のこと Warehouse Size Servers/Cluster Credits/h Credits/s 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
- 21. 20 ウェアハウス(2/2) 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) メタ デー タ ＜クラスタ数＞ • ウェアハウス内でクラスタを複数作成可能(EE以上) ₋ クラスタ数は1～10を指定可能 ₋ オートサスペンド(ユーザアクセスがなくなった後何秒でサスペンド するか設定可能)/オートレジューム可能 ₋ 4X-Largeで10クラスタ起動すると、c3.2xLargeのEC2が1,280台起動し、1時間でEEの場 合3,840ドルもかかるため、クラスタ数を増やす場合は慎重に! • ALTER WAREHOUSEコマンドにて、ウェアハウスのサスペンド/レジューム可能 ₋ サスペンドしている間は課金されない ₋ ウェアハウスが起動している間のみ秒単位で課金される • 例えばオンライン/夜間バッチのようにユースケースが異なる処理については、 ウェアハウスを複数作成することでウェアハウス間の競合なく処理を行うことが 可能 • ウェアハウスサイズによって単一処理時間、クラスタ数によって同時実行数を調 整することが可能 • パーティションキャッシュはマイクロパーティションのキャッシュで、ウェアハ ウス起動後にクエリを実行することで、スキャン対象データがウェアハウスの実 体であるEC2のSSDにキャッシュされる ₋ ウェアハウスの起動/レジューム直後はデータがキャッシュされていないため、初回アク セスから性能を出したい場合は、ウォームアップも検討する必要あり ₋ 検索対象データが大量な場合は、全てのデータがSSDに載るかも確認が必要
- 22. 21 リザルトキャッシュ 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) メタ デー タ • クエリの実行結果のキャッシュでS3に24時間格納されている • クライアントはクラウドサービス経由か直接S3からダウンロード ₋ サイズの上限はない ₋ 性能検証を行う場合はUSE_CACHED_RESULTをFALSEにすることで リザルトキャッシュを無効化することも検討
- 23. 22 ユーザアクセス 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) メタ デー タ • 標準SQL https://docs.snowflake.net/manuals/sql-reference/intro- summary-sql.html ₋ SQL-99の大部分、およびSQL-2003の分析拡張部分をサポート ₋ データ型、SQL構文、事前定義関数 • ユーザ定義関数 https://docs.snowflake.net/manuals/sql-reference/user- defined-functions.html • トランザクションサポート https://docs.snowflake.net/manuals/sql- reference/transactions.html ₋ S3に格納されているデータの整合性担保は、メタデータを管理してい るFoundationDBで実現 ₋ サポートしている分離レベルはRead Commitedのみ
- 24. 23 その他情報 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) メタ デー タ ＜Data Sharing＞ • 従来のデータ連携では、ファイル出力/連携/取り込み、もしくは APIによる連携が必要だった • Snowflakeが以下のアーキテクチャを持っていることで、自社DB と他社DBの一部をセキュリティを担保しつつ、最も効率的に連携することが可能 ₋ コンピュートとストレージの疎結合 ₋ 強固なメタデータ管理によるアクセス制御 ₋ 無制限な同時実行 ＜クローン＞ • テーブル、スキーマ、データベース単位でクローニング可能 • クローンは数秒で完了し、かつ追加のストレージコストは発生しない • タイムトラベル機能と合わせて使用することで、EE以上であれば 最大90日前のクローンも作成可能 ＜バックアップ＆リカバリ＞ • 従来型のデータベースでは、多くの場合完全バックアップと増分バックアップを 取得 ₋ データストレージの増大 ₋ データ再ロード、リカバリ時のビジネスダウンタイム ₋ (場合によって)最後のバックアップ以降のデータ損失 • マルチデータセンタや冗長化アーキテクチャは従来のバックアップの必要性を大 幅に軽減する • データ破損や紛失の可能性はあるため、効率的で費用対効果の高いバックアップ の代替手段として、7日間分の回復可能な履歴データ(Failsafe)を自動取得
- 25. 24 4. 価格
- 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 で変更可能
- 30. 29 性能を引き出すための検討事項(BigQuery) 〇設計のキーとなる項目 • パーティション分割 ₋ コストに影響のあるスキャン対象データ量を減らすため、ファイル分割や --time-partitioning_typeオプションを使用してテーブル作成 ₋ カラムベースパーティション 〇設計のポイント • 2,000スロット未満であれば自動で必要なリソース(スロット)を確保して使用し てくれるが、調整可能なパラメータがなく同時実行性能を出すことが難しい。 • 軽い処理でも一定時間かかってしまうため、マスタをDataStoreに入れるなどの 工夫が必要。 • 大量データ集計を同時実行する場合には、スロット数が足りるかの検証も必要。 (スロット数を増やすにはお金が必要)
- 31. 30 性能を引き出すための検討事項(Redshift)(1/2) 〇設計のキーとなる項目 • 分散キー ₋ ノード間でのデータ格納方法(EVEN分散、キー分散、ALL分散)を定義 ₋ 再分散を避けるようなデータの持ち方を検討しておくことが重要で、実行計画 で再分散の状況を確認できるが、一番つらいのはDS_BCAST_INNER(全ノー ドにデータをコピー) • ソートキー ₋ ノード内のデータ格納方法(ソート順)を定義し、複数列を指定する場合は順番 が重要 ₋ インターリーブドソートキーは複数列を指定する場合に、どの列を検索条件に してもそれなりの検索性能を出すためのデータ格納方法を定義する (データの変動に応じてVACUUM REINDXが必要となるため、多くの場合使用 する必然性はない) • 列圧縮方式 ₋ ANALYZE COMPRESSIONを実行するも、ほとんどの列でZSTDが推奨される • ワークロード管理 ₋ concurrency(デフォルト：5)にて同時実行数、wlm_query_slot_count(デフォ ルト：1)でクエリに割り当てるメモリリソースを制御
- 32. 31 性能を引き出すための検討事項(Redshift)(2/2) 〇設計のポイント • テーブルごとに検索条件に指定する列が限られていればよいが、SQL内に複数の CTE(共通テーブル式)があり、様々な列を指定されている場合には、テーブルが 非正規化されていると再分散の影響が大きくなる。 • 性能を出すには各種パラメータの最適値を導き出すための試行錯誤が必要。 • クラスタに対する同時実行数の最大が50で、ベストプラクティスとしては15以 下とも言われているため、同時実行には強くない。 • 拡張時のダウンタイムがつらい。
- 33. 32 6. まとめ
- 34. 33 データベースの在り方を根本的に変える設計思想 • これまで、1つのデータベースに対して異なるワークロードを実行していたため、 ワークロード管理が難しく性能を出すことが難しかった。 • コンピュートリソースとストレージが分離されたことで、1つのデータベースで競 合しない複数のコンピュートリソースを割り当てることが可能になった。 • 検索対象のデータはS3ではなく、コンピュートリソースのSSDにキャッシュとし て保持されるため、データも競合しない。Unlimited Concurrency • 競合が発生するために、用途ごとにデータベースを用意し、データを重複保持し ていたが、開発環境以外は1つのデータベースのみの運用とすることが可能。 • 他の組織へのデータ連携も不要となり、ライブデータをセキュアに組織を跨いで 共有可能。 ぜひ試してみて下さい！ • 性能要件(単一実行性能、同時実行性能)に合わせて柔軟に環境を用意することが 可能。データベースを用途ごとに複数用意する必要なし。AWS/Azure上で動作す るため、AWS/Azureの1サービスとして他サービスと組み合わせることが可能。 • アカウント登録、データベース作成/ロード/検索手順は以下に記載あり。 https://www.slideshare.net/mmotohas/snowflake-elastic-data-warehouse-as- a-service-81459451 • これまで20年間データベースに関わってきたが、実際に使ってみて、機能、性能、 価格全てにおいて、素晴らしいと感じた。 • ベンダとしては、日本への進出は手探りのようだが、使ってもらえれば日本市場 をより強く意識するようになると思われる。
- 35. 34 7. 参考情報
- 36. 35 参考URL • ドキュメント https://docs.snowflake.net • Snowflakeアーキテクチャ詳細 https://www.snowflake.net/resource/sigmod-2016-paper-snowflake-elastic- data-warehouse/ • Snowflakeをデータベースではなく、データウェアハウスと呼んでいる理由 https://www.snowflake.com/what-makes-snowflake-data-warehouse/ • ブログ 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