Snowflake Summit 2023 全発表総まとめ ― そして語られなかった、たった1つの言葉

Summit 2022で最大の発表といえば、間違いなくNative Applications Framework(Native Apps)でした。今年、それがパブリックプレビューに移行しました。

iPhoneでアプリをダウンロードするたびに、毎回別々のウェブサイトに行き、内容を調べ、その会社にスマホへの直接アクセス権を渡さなければならない――そんな状況を想像してみてください。今、Snowflakeを利用する企業がベンダーと付き合う方法は、まさにそういう状態なのです。

Native Appsが目指すのは、iPhoneのApp Storeのような体験をSnowflake Data Cloudにもたらすこと。Snowflakeの顧客がベンダーにデータウェアハウスへの接続を許可し、データを抜き出させて別アプリケーション側で再提供してもらう(まさにSELECTがやっていること)代わりに、Native Appsを使えばベンダーは顧客のSnowflakeアカウント内で直接アプリケーションを実行できます。これには次のようなメリットがあります。

1. セキュリティの向上。データはウェアハウスから一切外に出ず、社外の誰にもアクセスされません。サードパーティアプリ用のログインやアクセス権を別途管理する必要もなくなります。Native AppsはSnowflakeアカウントと同じ認証・権限体系を利用します。
2. 法務・Procurementの簡素化。通常、ベンダーとの取引では新規契約を社内法務がレビューする必要があります。Native Appsなら、法務が確認するのはSnowflakeマーケットプレイスの利用規約だけ。アプリをインストールするたびにレビューする必要はありません。
3. 請求がぐっとシンプルに。すべてSnowflake経由で課金されるためです。さらにSnowflakeは、既存契約のキャパシティでアプリの料金を支払えるcapacity drawdownという機能も発表しました。

SELECTでは、Native Appsが秘める可能性に大きな期待を寄せています。オンボーディングとProcurementを効率化することで、より多くのSnowflake顧客がROIを最大化し、価値ある示唆を引き出すお手伝いができるようになります。また、私たちが独自に作り出しているコスト・パフォーマンスのデータセットを、より手軽に共有できるようにもなります。

Summit 2023で会場をさらったのは、Snowpark Container Services(SCS)でした。基調講演の終盤、Christian KleinermanがSCSを使ってSnowflake上でネイティブに動作するアプリケーションのライブデモを、異なるユースケースで10本立て続けに披露しました。

Snowpark Container Servicesを使えば、文字通りあらゆるworkloadやアプリケーションをSnowflake上で実行できるようになります。仕組みは? Dockerです。SCSによってDockerコンテナをSnowflakeへ直接デプロイできるようになるため、Snowflakeがサポートする言語ランタイムや実行環境にユーザーが縛られることはなくなります。

Snowpark Container Servicesは多様なworkloadに対応します。複雑なAIモデルをSCSでトレーニング・デプロイし、新しいGPUインスタンスを活用することも可能。スケジュールジョブやサービス関数をSnowparkコンテナで動かすこともできますし、Webアプリのような長時間稼働するサービスをSCS上に直接ホストし、Snowflake上で24時間365日動かすこともできます。Hexは、洗練された自社のノートブックUI(複雑なReactのWebアプリケーション)をSnowparkコンテナで直接動かすデモを披露しました。

Snowflake上で24時間365日稼働するサービスと聞くとコストが心配になりますが、ご安心を。これらのサービスをコスト効率よく運用するための新しいコンピュートインスタンスも、SCS向けに発表される予定です。

なぜIcebergなのか?

多くの企業はすでに大量のデータをクラウドストレージに保有していますが、Snowflakeにロードしているわけではありません。これらのデータセットをSnowflakeでクエリも更新もできたら、便利だと思いませんか?

Apache Icebergは、分析用データセット向けに設計されたオープンなテーブルフォーマットです。物理データファイル(たとえばParquetファイル)の上にある抽象化レイヤーで、ACID(原子性・一貫性・独立性・永続性)トランザクション、スキーマエボリューション、隠しパーティショニング、テーブルスナップショットなどをサポートします。クエリエンジンは「テーブル」を構成するファイルを把握する必要がありますが、それを提供してくれるのがIcebergです。

SnowflakeのこれまでのIcebergサポート

昨年まで、Snowflakeでデータレイクのファイルをクエリする唯一の手段は、読み取り専用の外部テーブルでした。これらのテーブルへのクエリは、さまざまな要因によって、Snowflake内に直接格納されたテーブルよりもパフォーマンスが劣るのが一般的でした。Summit 2022でSnowflakeはIceberg Tablesのサポートを発表。これにより顧客はデータレイクのカタログをIcebergで管理でき、Icebergが提供するメタデータのおかげでSnowflakeのクエリエンジンによる大幅なパフォーマンス向上も得られるようになりました。さらにIcebergのサポートにより、外部(Iceberg)テーブルを通常のSnowflakeテーブルと同じように扱い、更新・削除・挿入も行えるようになりました。

Summit 2023のIceberg関連発表

Iceberg活用で残っていた課題は、別のカタログでIcebergメタデータを継続的に書き込み・更新するシステムが必要だという点です。これを解決するため、SnowflakeはSummit 2023で「managed iceberg tables」を発表しました。Snowflakeのコンピュートリソースを使ってIcebergデータを管理できるようになります。この負担を裏側で吸収するだけでなく、パフォーマンス面での改善も期待できます。

製品ドキュメントが見当たらないため、この機能は現時点でプライベートプレビュー段階だと思われます。上の画像はLinkedInのJames Malone氏の投稿から引用しました。Icebergに初めて触れる方には、このブログ記事が良い入門になるかと思います。

私たち自身のアカウントも含め、Snowflake顧客のデータ変換コストを押し上げている最大の要因の一つが、データパイプラインを実行するたびにテーブルをフルリビルドしていることです。速くて簡単だから、ついそうなってしまいます。一方、増分でテーブルを構築する方法は、遅延到着データや、各データセットをフィルタリングするときに使うハイウォーターマークなど、考慮すべき要素が増えて手間がかかります。また、上流に新しいデータが入ってくるタイミングを考慮せず、単純なスケジュールでジョブを回すことも、不要なコスト発生の原因になります。

Snowflakeは以前からマテリアライズドビュー(MV)をサポートしており、上流に新データが到着したときだけテーブルをリフレッシュすることで、こうした課題の一部に対処してきました。ただしMVには多くの落とし穴があり、特に大きな問題として、SQLビュー定義でJOIN、UNION、集約、GROUP BY、ウィンドウ関数など、一般的な操作の多くがサポートされない点が挙げられます。

今年のSummitでSnowflakeは、Dynamic Tables(DT)がパブリックプレビューに入ったと発表しました。DTはMVに似ており、SQL式でテーブルを定義しておけば、上流に新しいデータが現れたタイミングでSnowflakeがその式をマテリアライズしてくれます。DTには、他にも多くの利点があります。

1. SQLのサポート範囲が大幅に広く、JOIN、UNION、集約、ウィンドウ関数などにも対応します。
2. 新しいデータを増分処理するため、同じデータを何度も再計算してリソースを浪費しません。
3. MVは、上流テーブルが頻繁に更新されると非常に高コストになりがちでした。DTでは、ユーザーが定義したレイテンシパラメータに基づいてSnowflakeが更新を行います。これにより、テーブルの更新頻度、ひいてはコンピュートコストをユーザー側でよりきめ細かくコントロールできます。
4. ファーストクラスのUIサポートを備えています。DTとその依存関係を簡単に可視化でき、Refresh Historyタブで実行履歴も確認できます。

Snowflakeは、Snowpipe Streaming APIがパブリックプレビューに入ったと発表しました。Snowpipe Streamingを使うと、Apache KafkaやカスタムJavaアプリケーションから直接Snowflakeにデータをロードできます。低レイテンシでのデータ取り込みが求められるworkloadを支える機能です。

また、必要なインフラさえ整えれば、Snowpipe Streamingは最もコスト効率の良いデータロード手段でもあります。Snowpipeや、セルフマネージドウェアハウス上で実行する手動のCOPY INTO文といった他のデータロード手法は、いずれもステージからSnowflakeへファイルをロードする工程を伴います。Snowpipe Streamingはこのコストのかかる読み込みステップとファイル管理のオーバーヘッドを回避できるため、より経済的な選択肢になります。

生成AIとLLMの話題で持ちきりの中、SnowflakeがAI関連の新機能を続々と発表したのも当然の流れでした。

Nvidiaとのパートナーシップ

カンファレンス初日、SnowflakeはNvidiaとの新たなパートナーシップを発表しました。SnowflakeはNvidiaと協業し、NvidiaのLLMフレームワークNeMoをSnowflakeに統合します。これによりEngineersは、すでにSnowflake内に保管しているデータを使って、大規模言語モデルをSnowflake内で直接構築できるようになります。

Snowflake Copilot(時期未定)

SnowflakeはGithub Copilotのような「コメントからSQL」機能の、なかなか痺れるデモを披露しました。-- 過去30日間のデイリーアクティブユーザー数を表示してといったコメントを書くだけで、Snowflakeが(a)あなたのデータと(b)Snowflake固有のSQL方言の知識を使って、クエリを自動生成してくれる――そんな世界を想像してみてください。Snowflakeはクエリの学習データセットとして考え得る最大級のものを保有しているため、このモデルは他社の汎用モデルを上回るものになると期待しています。

Document AI(プライベートプレビュー)

2022年4月、Snowflakeは非構造化データ分析を専門とするApplicaという会社を買収しました。Summit 2023では、Applicaの技術を活用したDocument AIという新機能が発表されました。これはSnowflake自前のLLMで、Snowflakeに保存されているドキュメントに対して質問できる機能です。

Snowflakeは気の利いたデモを披露。ドキュメントから情報が自動で抽出され、ユーザーが抽出結果にフィードバックを与えることでモデルの精度を高められる、という内容でした。学習済みモデルはそのまま簡単にデプロイし、SQLクエリ内のUDFとして実行できます。

Snowflakeのプロダクトマネジメントチームは、開発者向けに数多くのアップデートを一気に発表しました。詳細が分かり次第、順次お伝えしていきます。

• 新しいSnowflake CLIとPython REST API(既存のSnowflake Connector for Pythonを補完するもの)
• Snowpark Model Registry。データサイエンティストがMLモデルをSnowflake内で保存・公開・検索・サービングできるようになります。
• Snowparkの各種機能強化。Pythonパッケージのより細かい制御、Python 3.9および3.10のサポート、外部ネットワークアクセス、ベクトル化されたPython UDTFなど。
• 予測、異常検知、コントリビューションエクスプローラーを支援する、機械学習ベースのネイティブ関数3種。
• 新しいロギング・トレーシングAPIと、Native Apps Frameworkでの開発を支援するgitとSnowflakeステージ間の自動同期機能。
• Streamlitはどうやらパブリックプレビュー「目前」のようです。チャット体験を構築するための新しいStreamlitコンポーネントも紹介されました。

多くの方の印象とは逆に、Snowflakeは顧客がSnowflakeを効果的に使えているかを真剣に気にかけています。長期的視点でビジネスを進める必要があること、そして顧客がSnowflakeに投じる1ドルから最大の価値を引き出せるよう支援する必要があることを、Snowflakeはよく理解しています。

Budgets(パブリックプレビュー)

顧客がSnowflakeの支出をよりうまくコントロールできるよう、SnowflakeはBudgets機能のパブリックプレビュー入りを発表しました。Budgets登場以前、ユーザーが設定できたのはリソースモニターのみで、ウェアハウス単体またはウェアハウスのグループが消費できるクレジット数を指定するものでした。Budgetsはさらに踏み込み、より多くのSnowflakeリソース(ウェアハウス、テーブル、マテリアライズドビュー、Snowpipeなど)をまとめてグループ化し、そのリソースグループにクレジット上限(予算)を割り当てられます。リソースモニターと同様、クレジット上限に達したときにアラートを通知したり、対象リソースを一時停止してそれ以上の課金を防いだりすることも可能です。

詳細と下の画像を共有してくれたSonnyに感謝します。

Warehouse Utilization(プライベートプレビュー)

Snowflake顧客が直面する最大の課題の一つが、ウェアハウスのサイズが適切かどうかの判断です。これを支援するため、SnowflakeはWarehouse Utilizationという新しい指標をプライベートプレビューで発表しました。現時点で詳細は明かされていませんが、パブリックプレビューになり次第、ぜひ試してみたい機能です。

Snowflakeは、クエリエンジンに対する数々のパフォーマンス改善と、その改善を公的に測定・追跡するための新しい指標Snowflake Performance Index(SPI)を発表しました。Snowflakeらしく、これらの改善はすべて自動的に適用され、ユーザーが何かを有効化する必要はありません。

Engineersやデータ実務者は、異なるデータベースに分散したデータを扱うことに慣れきっています。1970年代に2つ目のデータベースが生まれて以来の現実であり、だからこそデータ移動を中心とした数十億ドル規模の産業(ゴホン Fivetran)が成り立っているわけです。

もちろん、これは決して望ましい状態ではありません。すべてを1つのデータベースで完結できたら最高だと思いませんか? Summit 2022でSnowflakeは、トランザクション系と分析系の両方のクエリをサポートする新しいタイプのworkloadとしてUnistoreを発表しました。これは技術的に非常に難しいことで知られる課題への、極めて野心的な挑戦でした。

残念ながらSummit 2023では、Unistoreや、その裏側で動くハイブリッドテーブルへの言及は一切ありませんでした。エンジニアリングチームがこの複雑な機能をパブリックプレビューに出す前に、まだ細部を詰めているからだろうと推測しています。

追記: 何人かの方から、Unistoreについては専用セッションで講演があったとご連絡をいただきました。見落としており失礼しました!(とはいえ、タイトルはそのままにしておきます。クリックベイトとして優秀なので 😉)

Ian Whitestone・SELECT共同創業者兼CEO

Ianは、SaaS型のSnowflakeコスト管理・最適化プラットフォームであるSELECTの共同創業者兼CEOです。SELECT創業前は、ShopifyとCapital Oneで6年間にわたりフルスタックのデータサイエンス・エンジニアリングチームを率いてきました。Shopifyでは、データウェアハウスの最適化とコスト可視化の向上を主導しました。