お盆休みをしっかりいただけたので、徐々に通常運転に戻すべく今日は Snowflake 絡みの記事を3つ取り上げてみます。
Best practices to optimize Snowflake spend
Snowflake のコストが高いと最近耳にしますが、便利で高性能なサービスがゆえに利用目的などを精査していない結果、仮想ウェアハウスの利用金額が高くなってしまったり（Tableau などの BI サービスから接続するときに顕著？）、Snowflake が用意する様々な機能を知らずに損をしている、ということがある気がしています。
上記記事は Snowflake のプロダクトマネージャによる投稿で、Snowflake のコストを最適化するためのノウハウが紹介されています。ノウハウといっても基本的なもので、以下の4ステップに分けて具体的な方法が紹介されていました：
- コストの可視化を行い、各部門やチームへの費用按分を決定する
- 予算に対してのアラートを設定する
- RoI に基づいたワークロードの分割を行う
- リソースを大きく消費する行動を制限する
コストの可視化については Snowflake はすでにダッシュボードを用意していますし、それで足らなければコストに関する様々なビューが提供されています。最近では Streamlit と連携して、Snowflake のデータを使ったダッシュボードが Python で簡単に構築できるようになりました。
3, 4番目は Snowflake の機能紹介の色が強い気がしましたが（自動クラスタリング, Query Acceleration Service, 検索最適化サービス, マテリアライズドビュー）、こういった機能を闇雲に使うのではなく、RoI を加味して使い分けたり、必要であればアーキテクチャ再構築も実施するべきとも書かれていました。
パフォーマンス改善の役に立つ 知っていてほしい Snowflake の仕様 2 選
こちらは以前同僚に教えていただいた Snowflake のパフォーマンス改善に関するスライドです。カラム数とパーティションを読み込むサーバの特性について検証を交えながら紹介されています。
特にカラムに関して、100列と10000列によるパフォーマンス差異が検証されていました。実際には各環境／データで検証するべきでしょうが、メタデータ読み込みのオーバーヘッドが顕著になるカラム数の目安を知ることができます。
When To Use Iceberg Tables in Snowflake
2023年の Snowflake Summit で、Iceberg フォーマットの連携が強化されると発表がありました（現在はプライベートプレビュー）。公式発表によると、外部テーブルとして Parquet データを読むよりも外部の Iceberg テーブルを読む方が早く、さらに Snowflake 管理の Iceberg テーブルはネイティブフォーマットと同等のパフォーマンスが得られるとのことです。
Iceberg フォーマット自体の解説も上記記事で紹介されていますが、誤解を恐れずに一言で言えばACID特性を持たせて更新可能にした Parquet フォーマットです。
これで Snowflakeで扱えるフォーマットは以下の4種類になりました：
- ネイティブ: 多くの場合、最適なフォーマット
- Snowflake 管理の Iceberg フォーマット: Snowflake のデータを外部ツールから読み込む場合など
- Snowflake 非管理の Iceberg フォーマット: AWS Glue など、外部のETLツールが生成したデータを Snowflake 上で利用する場合など
- 外部テーブル: CSVファイルなど外部にホストされているデータを読む場合にのみ利用
この Iceberg 連携により、オープンフォーマットでデータを管理したい場合でも Snowflake を利用する選択肢が増えました。Iceberg フォーマットでデータを（例えば S3 に）一元管理しておくことで、データの重複を防ぐことはできそうです。その場合 アーキテクチャ的に Athena と重複しそうですが、Snowflake には Snowpark などの機械学習向けの機能などもありますし、ユースケースを整理した上で、用途によってクエリレイヤを使い分けるのも一案かもしれません。
