1

シナリオ 1 と同じ方法で、Snowpark にデータをアップロードできます。

2

Snowpark では、ユーザーは環境によって事前に提供されたライブラリの使用に制限されています。サードパーティのパッケージを使用するには、ユーザーは Jupyter Notebook インターフェイスを使用して、クラスターとローカル環境間の接続を確立する必要があります, または、記事に詳述されているように、面倒な回避策をナビゲートします。

3

ワークシートは py ファイルであるためグラフィカル出力を提供しないため、ユーザーには次の選択肢が残ります。プロットを保存し、ワークシートの外で手動で表示します。ワークシートの “chart” 機能を使用します。ワークシートは、データを視覚化するための “chart” オプションを提供しますが、組み込みチャートは 4 種類のみに制限されています。

4

自動生成されたコードで新しいノートブックが作成されました

5

Snowpark では、設定に名前を貼り付けて実行することで、機能を実行するための潜在的な問題があります。この厄介な機能は開発中に問題を引き起こす可能性があり、追加するのを忘れてしまう傾向があります。データクレンジングを簡単に実行する機能があります。Databricks との主な違いは、ワークシート内でのサードパーティパッケージの利用が潜在的に問題を引き起こす可能性があることです。snowflake。ml。preprocessing 内に存在する組み込みライブラリを使用することで、snowpark データフレームを使用できます ユーザーは anaconda-python ライブラリを使用できます。多くのライブラリをインポートすることで、テストに成功しました。

6

Snowpark’s ネイティブデータフレームと pandas データフレームの違いをテストするために、多くの関数を作成してテストすることができました。2 つのコード サンプルは、スノーパークのデータフレームとパンダのデータフレーム間で同じ種類の変換を使用し、次のようにして、pandas（tempPdDf['ENGINE' のサブ設定機能の使用に若干の違いがあります'])対スノーパークデータフレーム（with_column）。UDF fix_values を使用してクリーンなモジュラーコードを取得する Snowpark データフレーム変換コード:

7

帰属 ‘na’ を ‘Empty’ として関数を作成しようとすると、同様の違いが観察されました。Snowpark のデータフレームでは、辞書を使用してパラメーターを渡す必要があります。例: cat_column_dictonary = {feature:'Empty' pandas の feature_list[0]} の機能については、さらに簡潔にすることができます 提供された置換値のデータ型が列のデータ型と一致しない場合, filna は警告を生成し、その列をスキップします。これは、辞書を使用して、各列に置換値を指定することで回避できます

8

組み込みの ‘median’ 関数を使用して中央値を加入しようとしているときに見つかったもう 1 つの違いは、最終値を抽出する前に変換を収集して使用する必要があるビューを返すことです。中央値（特徴）。as_（特徴）。collect()[0]。as_dict()。get（特徴）

9

カテゴリやフィーチャーエンジニアリングなどの機能はスムーズで、問題なく実現しました。しかし、pyspark とパンダ対スノーパークのデータセットの使用方法には違いがあります

10

11

Snowpark はリンクとリンクに基づいてフィーチャーストアをサポートしていますが、これはスノーサイト/ワークシートの一部ではなく、ローカル開発中にのみ利用可能であることがわかりました。これは、Databricks の一環として調査したものとは対照的です。

12

スノーパークでは、スノーフレーク’s ml モデリングパッケージが提供する sklearn とモデルをトレーニングできます

13

Snowpark のワークシートは hyperopt の使用に限定されていますが、これは pandas データフレームでの使用に限定されており、snowpark ネイティブデータフレームでは使用できません。OPTUNA のようなサードパーティライブラリのインストールは面倒であることがわかります。さらに、並列/分散ハイパーパラメータチューニングの組み込みサポートは存在しません。それにもかかわらず、これを達成することは、拡張されたアプローチを通じて行うことができます。このアプローチでは、pyspark で hyperopt を持つ関数を使用した Databricks と比較して、UDTF（ユーザー定義テーブル関数）を作成する必要があります。

14

このアプローチに基づいて、分散ハイパーパラメーターチューニングも試すことができましたが、スノーパークネイティブデータフレームを使用できず、1 つのモデル RandomForestRegressor であるが範囲を持つパンダに変更する必要がありました ハイパーパラメータの結果と結果は満足のいくものでした。

15

MLflow を試してみたところ、Snowpark はスノーパーク/アナコンダを介して mlflow を利用していることがわかりました。つまり、MLflow を使用して Python ストアドプロシージャからトレーニングジョブを記録できます。リンク 1 とリンク 2 への参照。ただし、実験の追跡や、モデルのアーティファクト/実行とそれに対応するメトリクスの確認には、Azure が使用されます。スノーパークのデータフレームだけを使うことに興味があったので、pyspark Mllib は MLflow をネイティブにサポートしているので、これを深く掘り下げませんでした。

16

ワークシートでは、ユーザーは SHAP ライブラリを使用して計算を実行できますが、ユーザーがプロットを保存して手動で表示する必要があるプロットを確認できます。これを回避するために、ユーザーはローカル環境との接続のサポートを使用して、VS コードで jupyter ノートブックを実行し、プロットをリアルタイムで表示できます。

17

モデルはバッチ推論にのみ展開でき、リアルタイム展開やストリーミング展開はサポートされません。バッチ展開では、次の 2 つのアプローチが発見されました:

18

モデルをローカルでトレーニングし、ステージにアップロードして、UDF が呼び出されたステージからロードできます。

19

20

スノーパークでは、スノーフレークの ml モデリングパッケージによって提供される Sklearn とモデルを訓練することができます

21

モデル出力を SPROC に変換するために使用される基礎となるコードを示す ‘procedure definition’ が利用可能であることがわかります。

22

Git サポートは snowflake’s Snowpark では利用できません。Databricks のリポジトリとは異なり、チームは環境上で git を直接サポートすることはできませんでした。スノーパークの展開では、リンクから新たに利用できる Snowpark コンテナサービスが登場しました。Snowpark コンテナサービス（SPCS）は、簡単に展開、管理、管理できる完全に管理されたコンテナサービスです, また、コンテナ化されたサービス、ジョブ、機能をすべて Snowflake のセキュリティとガバナンスの境界内で拡張し、データの移動をゼロにする必要があります。これは、プライベートビューとして顧客のサブセットにのみ利用可能であったため、それ以上探索することはできませんでした。注: VS Code などのプラットフォームでローカルの Jupyter ノートブックを使用して接続することで、この問題を克服し、ローカルマシンから GitHub にコードをプッシュできます。