こんにちは。インテージテクノスフィア技術ブログ担当アイダです。今回の投稿は冬にふさわしい投稿です。リサーチテクノロジー本部のKさんは現在インテージの基幹システム担当なのですが、今回導入するDWH「Snowflake」について投稿いただきました。snowflake推しの熱い投稿をどうぞ！
「Snowflake」って？
アメリカ西海岸のサンフランシスコから少し南に下ったサンマテオという所に本社を構えるSnowflake社がクラウド向けに開発したDWHです。2019年のre:Inventにもダイヤモンドスポンサーとして名を連ねており、世界的にはその名が知られているようです。
Snowflake社は2012年に設立されたスタートアップで、世界中のトップDB開発エンジニアを多数集めており、関連する特許も多数保持しているそうです。 2015年にAWS上でサービスを開始してから着実に資金調達を重ね、2019年12月時点でその企業価値は35億ドル、いわゆるユニコーンと言われる段階でした。 そして2020年2月には再度大きな投資ラウンドを成功させたようで評価額が124億ドルとなり、ユニコーンからデカコーンになったそうです！
https://news.crunchbase.com/news/snowflake-gets-479m-reaches-decacorn-status-with-12-4b-valuation/
現在はCEOが元MSの技術系の人から、いわゆるThe経営者的な人に変わり、いよいよIPO間近という雰囲気です。
そしてさらに、日本でもサービスが開始されました！（これまでは一番近くてシンガポール） これは見逃せない！
普通のDWHと何が違うの？
Snowflake社のサイトを開いてみると、トップにババーンと表示されるのがコレ。
（ref: https://www.snowflake.com/ ）
「THE DATA WAREHOUSE BUILT FOR THE CLOUD」
そうです、クラウド向けにスクラッチで構築されてるところがミソなんです。
クラウド向けで何が嬉しいかというと、とにかく豊富なリソースを必要なときに必要なだけ柔軟に活用できるということ。 クラウドの大きな特徴であるElasticity（伸縮性）ってやつです。これはオンプレでは難しいですよねー。
「あれ？クラウドのDWHといえば赤いヤツがあるじゃないですか？それじゃだめなの？」
はい、通常の三倍のスピードのアイツですね。（アイダ注：当社ではRedshift多数運用されてます。大変お世話になってます。）
あれはもともとはオンプレ向けのDWHであるParAccel（現在はActian Matrix）ってやつを改造したものなんです。 なのでクラウドのElasticityってまったく意識されてなかったんですよね。 まあどんどん機能追加されていっていますが、どうしても無理がある…というのが現状かなと。
じゃあSnowflakeのクラウド対応ってどうなっているんでしょうか？そのアーキテクチャを見てみましょう。
アーキテクチャ
そうそう、アーキテクチャの話をする前に忘れてはならない事がありました。
このSnowflakeは完全フルマネージドのクラウドサービスなのですが、そのSnowflakeのソフトウェアが載っている裏側の基盤はAWS/Azure/GCPだということ。 なので例えばAWSであればEC2やS3、AzureであればVirtual MachineやBlob Storageなどが利用されているというのを思い浮かべてみてください。
さて、まずは従来のMPP型DWHやHadoopのようなマルチクタスタ型のアーキテクチャを見ていきましょう。
（ref: https://www.snowflake.com/blog/5-reasons-to-love-snowflakes-architecture-for-your-data-warehouse/）
このアーキテクチャでは、管理ノードが数台と、数十～数百台のディスクを搭載した計算ノードを並べて分散処理させるというものでした。 これはこれで非常に高速に動作します。分散しているので当然ですね。
しかし、クエリを実行する際に必要なCPU・メモリなどのコンピュートリソースと、データを格納するストレージが強く結びついているためいくつか不都合が生じます。
- 単純にノード数を増やしただけでは性能は向上せず、格納データの再分散などが必要になる
- ストレージを増やしたいだけなのに、コンピュートリソースも一緒に増やさざるを得ず、コストがかかる（逆も同様）
- オンプレであれば、将来を見越した過剰なサイジングとなりコストがかかる
- 例えばETL処理とBIなど、異なるワークロードが同時に走ると、互いに競合しパフォーマンスが出ない
etc.
一方、Snowflakeは大きく3つのレイヤーから構成されています。
- クラウドサービスレイヤー
- コンピュートレイヤー
- ストレージレイヤー
特に注目すべきは「コンピュートレイヤー」と「ストレージレイヤー」で、これが完全に分離している点です。 これにより上記の問題を完全に解決します。
（ref: https://www.snowflake.com/blog/5-reasons-to-love-snowflakes-architecture-for-your-data-warehouse/）
どのように解決しているのか少し詳しく見てきたいと思います。
3.ストレージレイヤー
まず一番下から見てきますが、こちらはご想像どおりAWSであればS3が利用されています。 ここに全てのテーブルデータが格納されています。S3ですから容量は気になりませんね！
「え、S3なんかじゃパフォーマンス出ないよね？」
いえ、ココにはSnowflake最大と言ってもいいノウハウが注ぎ込まれております。
その名は「マイクロパーティション」！
Snowflakeではデータをテーブルにロードするタイミングで、マイクロパーティションと言われる、一つおおよそ16MBのファイルに分割し、それをS3に格納します。 16MBですから、それぞれのテーブルは膨大な数のファイルから構成されているということが分かります。
そしてこの膨大なファイルに対して並列にアクセスしなければパフォーマンス出ないわけですが、そこにはS3の持つ高いスキャン性能が大きく寄与してくるという訳です。
（S3のパフォーマンスについてはこちら→https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/optimizing-performance.html）
2.コンピュートレイヤー
ストレージレイヤーに格納された永続化データに対してクエリを実行するためにはCPUやメモリなどが必要ですが、それを提供するのがこのレイヤー。
こちらもご想像どおりAWSであればEC2が利用されています。 EC2のサーバーが複数台集まってクラスタを構成しており、これをSnowflakeの世界では「Virtual Warehouse（以下VW）」と呼んでいます。 ここにはクラウドのElasticityが最大限活かされた機能が用意されているのでそれぞれ見ていきます！
ローカルキャッシュ
S3に永続化されたテーブルデータはかなり高速に取得できるのですが、さすがに毎回S3からデータ持ってくるのは無駄が大きい…。
ということで一度持ってきたデータはVW内のSSDにキャッシュされ、再利用することが出来ます。
スケールアップ/ダウン・スケールアウト/イン
VWは縦にも横にもスケールします。 しかも稼働中にWebUIやALTER文で変更可能！
ピークタイムに合わせたサイジング運用が可能になる訳です。 縦は1台から128台まで、横は1クラスタから10クラスタまで、最大で1280台のクラスタを利用可能です。 さらにVWを複数用意すれば…
Snowflakeではこれを「Unlimited Concurrency」と言っています。 負荷に応じてクラスタを増やす「Auto Scaling」も搭載されています。
自動レジューム/サスペンド
VWは起動しているときのみ課金がされます。 ですので利用していないときはサーバーを停止したいのですが、手動でやろうとするとたまに忘れて痛い目見ますよね？（遠い目）
これを防いでくれるのが自動サスペンド。 最短60s何もしていないと自動でVWを停止してくれます。
逆の動作をしてくれるのが自動レジューム。 VWが停止している状態で何かしらクエリが投げられたら、自動でVWを起動してくれます。
１つのDBに対し複数VWからアクセス
こんなケースありませんか？
「ユーザー数が増えて、サーバー増強しなくちゃいけない。同じデータだけどA社とB社でサーバー分けて運用しよう」
こんなときSnowflakeでは1つのDBに対して、複数のVWからアクセスさせることが出来ます。 コンピュートレイヤーとストレージレイヤーが分かれている恩恵ですね。
「え、ストレージレイヤー、ボトルネックになるんじゃね？」
いえ、大丈夫です。S3ですから！ さらにローカルキャッシュも効きますしね。
1.クラウドサービスレイヤー
最後はこちら、Snowflakeの頭脳とも言うべき様々な機能が詰まったレイヤーです。
まあココはどんなDB/DWHでも似たような感じですけど、Snowflakeはココ、特にメタデータをうまく使っている印象ですねぇ。 - メタデータ - トランザクション管理 - オプティマイザー - セキュリティ - 認証／認可 etc.
ワタシのお気に入り機能トップ5！
さて、ここまででSnowflakeのことはザックリとおわかり頂けたかなと思います。
その他にも多数の機能があるのですが、その中でもワタシのお気に入りの機能をランキング形式でご紹介！
第5位 Caching
Snowflakeの世界では以下の3つのキャッシュがあります。
- メタデータキャッシュ
- 結果キャッシュ
- ローカルキャッシュ
ローカルキャッシュはVW上のSSDに格納されるデータのキャッシュでしたね。
結果キャッシュはその名の通り、クエリの実行結果がキャッシュされます。最長24時間ですが、裏技により最長30日まで延ばせます。 あと結果キャッシュをテーブルとしてクエリできる関数なんかも用意されています。ステキ。
さて残りのメタデータキャッシュですが、ココにはSnowflakeに格納されているすべてのテーブルの行数や各カラムのMIN/MAXなどが保持されています。 コレがあるおかげで下記のようにWebUI上に行数を表示してくれたり、MIN/MAXを瞬時に返してくれたりと地味に便利です。
こういう単純なクエリならば600億レコードあろうとも176msで済みます。
第4位 Zero Management
これは機能というよりはSnowflakeの全体的な特徴なんですが、「ほぼ管理ゼロ」というのを謳っています。
一般的なDWH/DBには例えばインデックスやパーティションなど、チューニングのためのオプションありますよね？あとは統計情報の更新やVACUUMなど。 Snowflakeにはこれらがほとんど存在しないんです。全部お任せ！ DBAはより上位のタスクに集中できるわけですね。
第3位 クエリプロファイル
みんな大好き実行プラン。 Snowflake自体にチューニングオプションはほぼありませんが、やはり効率的なクエリを書かないとダメです。 そんなときに頼りになるのがこのクエリプロファイル。実行したクエリの裏側をメチャ詳しく教えてくれるのです。
（ref: https://docs.snowflake.net/manuals/user-guide/ui-query-profile.html）
第2位 Zero-Copy Cloning
皆さん、テスト用にDBやスキーマ、テーブルをまるごとコピーしたいなんて場面よくありますよね？そこで登場するがコレ。
こんな感じでクローンが作れます。メチャ簡単。
create or replace database staging_sales clone sales;
そしてこいつはメチャ速いんです。なぜならメタデータだけの操作だから！ つまり元のDBとクローンしたDBでまったく同じマイクロパーティションを参照しているということなんです。ストレージコストも節約！ 一方のデータが更新されたらどうするって？更新対象のマイクロパーティションだけ参照先変えれば解決！
第1位 Time Travel
来ました未来の世界。いやSnowflakeでは過去への旅ですが。 テーブルのデータはS3にマイクロパーティションで格納されているとお話しました。 そしてこのマイクロパーティションって「イミュータブル（IMMUTABLE）」なんです。
いみゅーたぶる？
はい、「状態を変えることが出来ない」・「不変」という意味ですね。
つまり何かしらテーブルに対して更新処理をした場合、元のマイクロパーティションは「不変」のまま、新たなマイクロパーティションを「追加」する動きとなります。 ここでピン！と来た方、ハイその通り、Snowflakeのすべてのテーブルはその履歴情報を自分自身で保持しているのです。 この履歴情報を使って面白いことが出来ます。
今から5分前のt_basicを抽出
select * from t_basic at(offset => -60*5);
2019/12/02 16:20時点のt_basicを抽出
select * from t_basic at(timestamp => 'Mon, 02 Dec 2019 16:20:00 +0900'::timestamp);
2019/12/02 16:20時点のt_basicをクローン
create table restored_basic clone t_basic at(timestamp => 'Mon, 02 Dec 2019 16:20:00 +0900'::timestamp);
どうです？これすごくないですか？ まったく普通のテーブルとして扱えるのでJOINでも何でもやりたい放題。 ああ、もう長時間のリストア待たなくてもいいんですね…。（再び遠い目）
一応履歴の保持期間は決まっていて、最長で90日です（Enterprise Edition以上）。 当然保持期間が長いほどストレージのコストも掛かるのでちょっとだけ注意ですね。
未来はどうなる？
さてさてSnowflakeいかがでしたでしょうか？ 熱い気持ちが入りすぎて、1エントリにするには長文になりすぎましたね…。
とにかく運用がメチャ楽になりますよコレ。
「ん？性能系の話は？」とか「お高いんでしょ？」というツッコミがたくさんあるかと思いますが、これはまたどこかで…。いや普通に速いですよコレ。
Snowflakeは常に進化を進めていて、最短で週次でのアップデートが行われています。 大きなアップデートも今後いくつも予定しているようですし、パフォーマンスもこれからもさらに高めていくとのこと。
本当に楽しみでなりません！
一方、他社もSnowflakeと同じようなコンピュートとストレージを分離したアーキテクチャを持つサービスを展開し始めました。
マイクロソフトは「Azure SQL Database」に「Hyperscale」という新しいサービスレベルを追加してます。（ref: https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-service-tier-hyperscale）
そしてAWSは昨年のre:InventでRedshiftに新たなインスタンスタイプ「RA3」を発表しました。（ref: https://dev.classmethod.jp/cloud/aws/update-reinvent-2019-amazon-redshift-new-nodetype/） さらに「AQUA(Advanced Query Accelerator) for Amazon Redshift」なる技術で10倍速を謳っています （ref: https://pages.awscloud.com/AQUA_Preview.html）
まだどれも触ってないのでなんとも言えませんが、我々としては選択肢が増えるのは嬉しいですね。
今後もクラウドDWHから目が離せません！
