Twitter Space で Snowflake 雑談会第 2 回をやった

本日、2022年9月14日、Twitter Space 上で Snowflake ユーザ向けの雑談会第2回をやりました。
これは、Snowflake ユーザが集い、みんなに聞きたいこと、みんなに紹介したいことを気軽に話し合う会です。

今回は10人くらい参加、4-5人ほどが議論に参加してくれました。ありがとうございます。
月1 くらいで開催予定ですので、都合がつけばまたご参加ください。

今回の内容

Native App Framework

• 先日、Snowvillage でも Native App Framework を紹介してくださった truestar の方が Native App Framework を紹介してくれました。
• これは App Store 経由でアプリケーションを配布することで、利用者がデータを第3社に出さずに自社のデータを操作するアプリを利用できると言うものだそうです。
• 私の所属の金融業界だと、業界特有のデータ分析処理をソフトウェアベンダーが配布する、私のような事業会社は開発コストをかけずにアプリを利用できる、ような形態を想定できました。
• Native App Framework を聞いた時は、自社開発のアプリケーションを動かす汎用的な実行基盤を想定していましたが、あくまでも App Store を通じてアプリを配布する形態とのことで、私が期待したものと想定が違うとわかりました。

Snowflake 導入して何が嬉しかったの？

• 私の体験談を紹介しました。
• 私自身は、2年前に自社に入った時、小規模に RDS でデータ分析できる環境を構築してと依頼され、 RDS と BI ツールで構築しました。
• しばらくしてチームが拡大、スケールするデータウェアハウスに本格移行しようとなり、いくつか比較した中、Snowflake を導入しました（その後、大手企業との合併はなどあり、
• よかった点は用途やプロジェクトによってウェアハウスを分けられ、水平にスケールするので、バッチで負荷が高い時に、心配せずにアナリストがクエリできること。
• また、SSO や Web UIの使い勝手が良いと評判です。

ぶっちゃけ Snowflake って安いの？高いの？

• 次にぶっちゃけ安いの？高いの？と言う話題に移りました。
• 価格モデルをダウンロードできるので、ある程度のモデルケースを置いておおよそのコストを試算できます。こちらを紹介しました。 https://www.snowflake.com/pricing/
  • ほとんどのケースでは、 XS で十分で用途やデータ量に応じて、どらくらいウェアハウスが走るかで概算できます。
• 個人的には、インフラコストだけでなく、データパイプラインの開発コストも想定する必要があると思います。一定規模のデータ量、処理負荷がかかりケースで、水平にスケールしづらいウェアハウスを作った場合、パフォーマンス問題を回避するため、パフォーマンスチューニングしたり、並列して外部でデータ処理するパイプラインを構築など、さまざまな開発が発生する場合があります。これはプロジェクトコストの肥大化、プロジェクトの遅延のリスクを伴います。水平にスケールするウェハウスを使うことで、ETL、データパイプラインをシンプルにし、余計な開発コストを削減できます。
• 処理するデータ量に比例して、インフラコストが増大してしまう可能性があるのは事実です。Snowflake を導入すればそれで終わりというわけではなく、コストやクエリヒストリを定期的にモニタリングし、クレジットを大量に消費してるクエリがあれば、外部のバッチや Snowflake 内の Task などで定期的に事前集計をする処理を入れることで、BI ツールやアナリストが参照するデータ量を減らし、コストも削減できます。
• できれば生に近いデータだけ Snowflake において、BI などコンシューマ側が参照する際にその場で集計したいという意見も出ましたが、それはETLなどの開発コストが最小化される代わりに、クエリが処理するデータ量が増大したり、クエリの処理時間が長くなるので、コストとのトレードオフでどこまでやるかを検討すると良いと思います。

以上