Snowflake とは
クラウドデータプラットフォーム。
よく知られている似た他社サービスとして AWS の Redshift，GCP の BigQuery が挙げられます。
Snowflakeのアーキテクチャは3つの重要なレイヤーで構成されており、各レイヤーにそれぞれの役割をもたせることにより様々な機能を提供し、高いコストパフォーマンスで利用できるのが特徴です。
Redshift, BigQuery, Snowflake どれをつかえばいいの？
| サービス | 課金モデル | スケーラビリティ |
|---|---|---|
| Redshift | インスタンスの起動時間 | インスタンスサイズなどユーザ自身で指定 |
| BigQuery | クエリのデータスキャンボリューム | オートスケール (ユーザ指定不可) |
| Snowflake | 仮想データウェアハウスの起動時間 (1分以上・秒単位) | 仮想ウェアハウスサイズの指定 (XS~6XL) |
Redshift
Redshiftはパフォーマンスチューニングを正しく行えばパフォーマンスは高いですが、非計算時間もインスタンスが起動していれば課金されるため、BI・集計・分析と様々なタスクが実行される環境では一般的にコストが高く付きます。充実している他のAWSサービスとの連携は強みとなり、常に同じような負荷がかかり続けるケースや契約によってはオトクな場合もあります。
※ Redshift Serverless が2021/11/30 に Public Preview になりました。クエリ実行の観点で Snowflake と同様の使い勝手になっています。
BigQuery
BigQueryは自動でスケーリングが指定されるためユーザで何か設定を変更することはできません。処理速度は高速かつクエリを回していないときはコストがかからないため（ストレージ料金はかかります）、とっつきやすさでは優れた選択肢の一つです。ただし、コストがクエリのデータスキャンボリュームによって算出されるため、大きなデータを扱うプロジェクトなどではデータの保管方法やクエリの回し方を適切に扱わないとコストが非常に高くなるリスクがあります。
Snowflake
Snowflake は仮想ウェアハウスの起動時間による課金モデルとなっていて、仮想ウェアハウスのサイズによってパフォーマンスを指定できます。また、処理を行う際に仮想ウェアハウスが逐次起動して処理を行うため、必要なときに必要な分だけ課金される使い勝手のいい設計（ストレージ料金は別途かかります）になっています。また、スケールアップ・スケールアウトがしやすく、一つのウェアハウスに対して様々な処理が行われる環境でもコストと性能を両立できます。
Snowflake の特徴
Snowflakeは6つのワークロードという概念で成り立っていて、それぞれが持つ役割が全体としてのサービスを構成しています。
ここでは、それぞれのワークロード別に雑感を記します。
各ワークロードについての詳細はオフィシャルの参考リンクも下部に載せてあるので参照ください。
Data Warehouse
- 用途に応じてスケールアップ・スケールアウトが簡単。プロビジョニングも速いので使いたいときに使いたい用途ですぐ使える。
- 半構造化データをそのまま扱えるので便利。非構造化データの対応も進めているらしい。
- クエリのキャッシュを持つので繰り替えし実行するクエリングが速い。
- ダウンタイムなし。
- マイクロパーティショニングすごい。
tips
- クエリキャッシュは24時間保持されるので、BIなど繰り返し同じクエリが実行される環境では落とさず起動し続けたほうがいいことも。環境によるので実験して見ると良い。
- データに対して、どのテーブルの何がいつだれにどのぐらい使われたのかモニターできるので、一度も使われてないテーブルリスト（nullひっぱってきて削除依頼だすなど）だしてコスト削減とかもできる。無駄なデータマネジメントしなくてよくて楽。
- 中間テーブルには TRANSIENT/TEMPORARY TABLEつかうと良い。無駄にフェイルセーフで課金されないように。
- Query profiler で spill がでたらメモリに乗り切らなくて溢れてるので、scale up かクエリ最適化を検討すべし。spill to remote は防ぎましょう。
- default clustered table -> 入ってきた順のマイクロパーティショニング。
- 日付とかユーザーID とかでまとまったデータの使い方の方が決まっていてプルーニングうまくいかないときは Explicitly clustering table つかうとよさそう。
- パラメータは <4 になるように。
- IDより日付のようなカーディナリティが大きいものからクラスタリングすると良い。
- 再クラスター化の注意点として、マイクロパーティションの並びがデフォルトのものと変わってしまう。多く実行するとその分コストはかさむので洗い替えの多いデータなどは注意が必要。
Data Lake
- 圧縮がすごい効く。場合によっては他のストレージサービスの2-3倍の圧縮率を誇るのでストレージコストが安くなることも。
- 外部テーブルを使うことでデータの移動を伴わず直接クエリを実行できる。
- セキュアなデータシェアリング機能により、データを安全・素早く共有可能。
- Snowflakeユーザー間はもちろん、非ユーザーに対してもリーダーアカウントを発行することで共有可能。
- snowpipeやtaskといった使いやすいデータパイプラインが内包されていて、データの持続性も高くスケールアップ処理も即時。
- アクセス権限付与が柔軟でデータシェアの際も含めセキュア。
- データマスキングと外部トークン化で共有時の機密情報漏れを防止できる。
- Snowflake Data Marketplace で必要に応じてデータを入手、買ったり売ったりもできる。
- メタデータレイヤーが全てのマイクロパーティションを保持し追い続けてゼロコピークローンを実現している。
tips
- 外部テーブルはストレージコストはかからないが、マイクロパーティションなどのstorage層のサービスは使えないので使う場を選ぶ。
- failsafeは無し。
- マテリアライズド・ビュー
- 外部テーブルからの〜マテリアライズド・ビューはゴールデンコンビ。
- マテリアライズド・ビューはビューといいつつデータを物理でSnowflake上に保持するため、ストレージコストがかかるがマイクロパーティショニングされ高速。
- 外部テーブル比較でコンピュートクレジットは削減。
- 取り込みするか外部テーブルのまま使うかの検討方法
- Snowflakeへの取り込み費用*ストレージコスト+参照するときの費用
- 外部：ストレージコスト0取り込み不要＋参照するときの費用と時間
- ※何人も何度も使われるものになっていくならば切り替え推奨。
- 一時的にチェックするなどは外部テーブル推奨。
- 入れるのは一回きり→毎回のコスト考えると取り込み推奨。
- 他、永続テーブルは7日間のfailsafe有り・一時テーブルはfailsafeは無し・仮テーブルはセッション中のみ保持。
Data Engineering
- 半構造化データ型をネイティブでサポートしていてスキームの定義が不要。
- Snowflakeのマルチクラスタ共有データアーキテクチャにより、ほぼ無数の同時実行ワークロードにおいて性能を維持できる。
- 専用コンピュートクラスタのサイズを瞬時に変更することで、パイプライン性能と価格が最適化され使用した分だけ料金を支払うことが可能。
- 数回のクリックだけで、コンピューティングリソースをほぼ無限にスケールアップ/ダウンできる。
- パイプラインを拡張して、エクスターナルファンクション、JavaScript関数、ストアドプロシージャを包含させることも可能。
tips
- データロードに関する推奨ファイルサイズは100-250MB。
- 例えばXLだと128スレッドなので、1TB1ファイルよりも、細分化されたファイルのほうが並列処理されるため。
- 半構造化データの1行のVARIANT型の場合の制限は16MB。
- COPYコマンド
- 並び替えなど基本的なものサポート。
- join, filter, aggregationは不可。
- snowflakeはETLを推奨していないため。まず入れてしまうことを推奨する仕様（ELT)。まず入れたほうがmicro partitionなどされて処理しやすい。
- join, filter, aggregationは不可。
- 並び替えなど基本的なものサポート。
- load_history information schemaでモニタリング可能。
- CREATE TASK
- ACTION（バッチ、スケジュール、小タスクデイジーチェーン）
- STREAMでのメタデータ参照する形で組み合わせれば、◯◯したらどんなACTIONするっていうのを指定できる。
Data Science
- 前処理なしで、半構造化データをネイティブに格納し、クエリを実行することが可能。
- ストリーミングとバッチローディングにより、データを最新の状態に保つ。
- Snowflake Data Marketplaceやユーザ独自のプライベートデータエクスチェンジから、すぐに利用可能なサードパーティのデータにアクセスできる。
- 個々のデータサイエンスシナリオに合わせて、コンピュートリソースをオンデマンドで拡張・縮小可能。
- データサイエンスと他のデータワークロードとの競合を避けるために、専用のコンピュートリソースを使用可能。
- ゼロコピークローニングを活用して、パーソナライズされたデータサンドボックスを作成できる。
- API経由のスコアリングとデータ拡張をサポートするエクスターナルファンクションが使える。
Data Application
- 1秒単位のコンピュート料金により無駄なコストを支払わずに済む。
- キャパシティプランニングやコストのかさむオーバープロビジョニングが不要。
- JSONをリレーショナルテーブルに直接挿入することで、速やかにインサイトを得ることができて便利。
- 標準SQLを使って、構造化および半構造化データのクエリを実行できる。
- ゼロコピークローニングと、分離されたコンピューティングリソースにより、サンドボックスを瞬時に作成できる。
- SnowflakeのTime Travelテクノロジにより、手動でのバックアップなしに履歴データへのアクセスやロールバックが容易に行える。
- 事故でデータを消去してしまっても戻せる。何が起きるかわからない現場ではこれはありがたいし、実際に救われた場面に遭遇している。
- 高可用性、データ永続性、障害回復の組み込み機能によって、煩わしい作業から開放され業務効率が向上する。
Data Exchange
- 顧客、サプライヤー、他のビジネスパートナとの間で独自のデータエクスチェンジを作成できるので、従来の共有手法と比較してリスク、コスト、問題を削減できる。
- 抽出・変換・ロード（ETL）やデータパイプラインのメンテナンスコストを削減できる。
- そのままの場所にあるライブデータセットに対するアクセスを許可して、データをコピー、変換、移動する必要性を排除できる。
- いわゆるDXプロジェクトなどで頻繁に発生するデータの連携、意外とここが大変で時間がかかるがここをスキップできる可能性を秘めているのでビジネスゴールに素早くアプローチできる。
参考
https://docs.snowflake.com/ja/user-guide/intro-key-concepts.html
https://www.snowflake.com/data-warehouse-workloads/?lang=ja
https://www.snowflake.com/workloads/data-lake/?lang=ja
https://www.snowflake.com/workloads/data-engineering-workloads/?lang=ja
https://www.snowflake.com/data-science-workloads/?lang=ja
https://www.snowflake.com/workloads/data-applications/?lang=ja
https://www.snowflake.com/workloads/data-sharing/?lang=ja