現場目線でSnowflakeの魅力を語ってみた
はじめに
近年DWHとしてSnowflakeがメジャーになり、導入する企業が増えてきたことを実感します。
私もここ最近はSnowflakeを導入する案件に参画することが増え、日々Snowflakeの魅力を肌で感じているため、使ってみて気づいた現場目線での魅力を語ってみようと思います。
魅力1.GUIのシンプルさ
Snowflakeの画面って、とても分かりやすいんですよね。
必要な項目がほぼすべて画面左のメニューバーに並んでいます。直感的で分かりやすいUIなので迷子にならず操作している時のストレスがかなり少ないです。
GUI派なのでこれは個人的にはすごくポイント高いです。
Snowflakeを始めて触るお客様はもちろん、他のDWHは触ったことがあってもSnowflakeは初心者というエンジニアがアサインされたときも学習コストが少ないです。
SQLを実行する画面も、実行結果と一緒に画面右にクエリの実行時間やデータが持っている日付の可視化、カラムごとの欠損率なんかがグラフで表示されます。
Snowflakeの視覚的サポートに対する熱量を感じますよね。できるだけ分かりやすく分かりやすく・・・を突き詰めて画面を作り込んでいる感じが伝わります。
もちろんクエリを書くときのサジェスト機能もあります。
たまにこの機能がない製品もありますが、地味に助かりますよね。
魅力2.課金体系の分かりやすさ
Snowflakeは消費したクレジットに応じて課金が発生します。クラウドプラットフォーム(AWS、Azure、GCP)やリージョンによって1クレジットあたり〇円と決まっています。
クレジットは主にウェアハウス※のサイズと稼働した時間に依存します。
ウェアハウスにはXS~6XLまでのサイズあり、サイズが大きくなるほど内部で動くサーバの数が増えます。そしてサイズが大きくなるほど1時間あたりのクレジット消費量も増えます。
つまり、このウェアハウスサイズを適切なサイズに設定してあげればコスト最適化ができるわけです。
そしてこのウェアハウスはいくつも作成できて、ユースケースに応じてどのウェアハウスを使って処理を実行するかが選択できます。
例えば、開発環境でストアドプロシージャを開発するときは最低限のコンピューティングリソースでいいのでXSサイズのウェアハウスで、本番環境でETLワークロードを実行する時はLサイズのウェアハウスで、日中に多くのユーザが自由分析のためにSQLクエリを実行する時はXLサイズのウェアハウスで、といったように複数のウェアハウスを使い分けることができます。
さらにウェアハウスは処理を実行する時に自動で起動し、使われなくなったら自動で停止します。
この柔軟性とオートシャットダウン機能が個人的にポイント高いです。
開発環境ではXSサイズを使えばいいので開発中の利用コストに対する不安はありません。またオートシャットダウンなので停止し忘れてずっと課金されてしまっていたという心配がないのもGoodです。
たまーに『クラウド破綻』という言葉を見かけますが、Snowflakeは意図せず気づかないうちに課金が発生してしまっていた、というリスクが仕組み上低く、現場で使っている身としては安心感があります。
魅力3.マルチクラウド特有の拡張性
これは現場目線というよりもっと俯瞰的な目線での魅力なのですが、将来のデータ基盤の拡張性を考えた時に、クラウドロックされないソリューションは強いです。
データレイクがS3でもGCSでもData Lake Storageでも対応できるため、社内の様々なストレージからデータを吸い上げることができサイロ化を防げます。
もちろんBIツールも選択肢が広がります。例えば新しいデータレイクやBIツールが増えて拡張する場合でもデータ基盤の中心であるSnowflakeは変えずに対応が可能です。
将来のことなんて誰にもわからないからこそ、柔軟な対応ができるというのはすごく魅力的だと思います。
さいごに
まとめると、Snowflakeの魅力はUIの分かりやすさ、コスト面での安心感、将来的な安心感です。
Snowflakeの魅力は色々な方がたくさん発信していますが、今回は現場で実際に使ってみて肌で感じた魅力を語ってみました。Snowflakeが気になっている方やDWHプロダクトの導入を検討されている方の参考になれば幸いです!