はじめに
Snowflake World Tour Tokyo からはや1ヵ月。イベントの登録者はなんと5000人超ということで、大盛況でしたね！
イベント当日、私は DATUM STUDIO ブースでデモの担当をしておりました。担当時間中はほとんどずっとデモの説明をしていたような気がしています。たくさんの方に興味を持っていただけて、ありがたい限りでした。
また、SPCS とは何か・SPCS で何ができるのか・SPCS を選ぶメリット・SPCSのコスト感… など、SPCS について オタク語りする 知っていただく機会を作れて、布教活動も大成功！ SnowVillage コンテナユーザーグループのリーダーとして SPCS の知名度アップとユーザー拡大に少しは貢献できたかな、と思いました！
DATUM STUDIO の Snowflake World Tour Tokyo イベントレポートはこちらです。
この記事では、DATUM STUDIO ブースで紹介していたデモのうち「Snowpark Container Services を活用したフルマネージドクラウドデータ基盤の構築」について解説します。
デモ
概要
まず、デモのシナリオです。次のような利用者がいるデータ基盤を想定しました。
- ユーザー①：データエンジニア
- 目的
- データ分析に利用する特徴量データを作成するために、Snowflake 上でデータ変換処理を作成する
- 利用ツール
- やること
- データを変換する処理は dbt で作成する
- dbt の実行スケジュールは Apache Airflow で管理する[1]
- Airflow では astronomer-cosmos パッケージを利用して、自動的に Airflow のタスクを dbt のモデル単位で分解し、Airflow 上でもモデルの依存関係が参照でき、リカバリもモデル単位でできる状態にする
- 目的
- ユーザー②：データアナリスト
- 目的
- Snowflake に保存された特徴量データを利用して、機械学習によるデータ分析を行う
- 利用ツール
- やること
- 分析環境として JupyterLab を利用する。Python Notebook でモデルの学習・推論・評価を実行し、分析や推論の結果を Snowflake にテーブルで保存する
- MLflow を用いて実験管理を行う。モデルのハイパーパラメータや評価指標などを記録する
- 目的
dbt、Airflow、JupyterLab、MLflow。どのツールも、データ基盤ではよく使われているものですね。
このデモでは、これら全てを SPCS を利用して Snowflake 上に構築します。dbt によるデータ変換処理を Airflow でオーケストレーションし、変換したデータを用いて JupyterLab で機械学習を行い、MLflow で実験管理する一連のプロセスを Snowflake 上で行うことが可能になります。
デモの流れ
まずはデータエンジニアの操作から始めます。
SPCS により Snowflake に構築された Airflow にアクセスし、dbt を実行する DAG を手動でトリガーします。
実行すると Snowflake にテーブルが作成されます。データアナリストが使う特徴量テーブルは JOIN_TRAIN_TARGET です。
次はデータアナリストの操作です。
JupyterLab（これももちろん SPCS）で Python Notebook を開き、JOIN_TRAIN_TARGET テーブルを取得します。
学習と推論、評価を行います。最後に、評価指標の推移をグラフで表示しています。
このとき、MLflow API を呼び出し、モデル情報の登録を行っています。コードが気になる方はこちらの記事をご参照ください。
登録したモデル情報を確認するため、MLFlow（もちろん SPCS） を開きます。
先程のモデルの情報が登録されています。使用したライブラリ（今回は lightgbm）、ハイパーパラメータ、評価指標が記録されています。
評価指標の推移グラフも、MLFlow 側に保存されています。
ということで、データエンジニアとデータアナリストの作業のすべてを Snowflake に完結した環境で実現できました！
アーキテクチャ
デモのアーキテクチャについても触れておきます。当日は、かなり簡略化した構成図で紹介していました。
ここではもう少し詳しく説明していきます。
dbt + Airflow
こちらの Quickstart を元に作成しました。
（「Running Apache Airflow on SPCS」より）
構成図で dbt + Airflow の部分では、4つのサービスが起動しています。
- Airflow Server・Scheduler
- Airflow Worker
- Redis
- PostgreSQL
コンピュートプールは、CPU_X64_S を3つ立てています（Redis と PostgreSQL が共通）。QuickStart でのインスタンスファミリー設定を流用しましたが、複数のサービスをホストすることと、ワーカーが複数起動することを考慮して、最小の XS ではなく S にしているのだと考えています。
JupyterLab、MLFlow
MLFlow については、こちらの記事が元になっています。
JupyterLab と MLFlow は1つのサービスでホストしています。コンピュートプールは CPU_X64_XS です。
コストについて
デモ全体でのコンピュートプールのランニングコストを試算すると、こんな感じでした。[2] [3] [4]
| サービス | インスタンス ファミリーの 単価 |
個数 | クレジット/日 | 料金（円）/日 | 料金（円）/月 （1ヵ月＝30日） |
|---|---|---|---|---|---|
| dbt＋Airflow | 0.11 (CPU_X64_S) |
3 | 7.92 | 3,385 ~6,771 |
101,574 ~203,148 |
| JupyterLab MLFlow |
0.06 (CPU_X64_XS) |
1 | 1.44 | 615 ~1,231 |
18,468 ~36,936 |
※小数点以下切り捨て
実際に、Snowsight にある Cost Management で確認したところ、試算通りのクレジット消費になっていました。
今回はデモのため1日のみの起動でしたが、1ヵ月稼働したとすると、だいたいコストは12万円～24万円といったところですね。
おわりに
さて、この構成を見て「どこかで見覚えがあるような？🤔」と思っている方がおられる気がするので、最後にこのデモの元ネタともいえるLTについてもお話ししておきましょう。
データエンジニアリングに関わる皆さまであれば、こちらのイベントに参加した方も多いのではないでしょうか。
このイベントでの 菱沼 雄太@ちゅらデータCTO さんによる LT「SnowVillage村長が自信を持ってオススメする最強はこれだ」で、『Snowflake の SPCS で 周辺サービスを全部 Snowflake 上で動かす』という、Snowflake 全部乗せアーキテクチャが提示され、話題になりました。
そう、今回のデモでは、ついにこの夢の構成を実現しちゃったというわけです！
夢じゃありません‥‥‥‥！ 現実です‥‥‥！ これが現実‥！Snowflake 全部乗せアーキテクチャは本当に出来るんです！
そして最後の最後に。
今回のデモは、DATUM STUDIO の亀井さん＆川口さんが実装の全てを担ってくれました。二人の経験値と爆速実装力がなければ成り立たないデモでした。本当にありがとうございました！！
宣伝
SPCS に興味を持たれた方はぜひ SnowVillage コンテナユーザーグループにご参加ください。
SnowVillage Slackワークスペース #container チャンネルで盛り上がっていきましょう！
SnowVillage への参加はこちらから：
-
デモではスケジュール実行はせず、手動実行のみ ↩︎
-
インスタンスファミリー単価はこちらを参照： https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf ↩︎
-
ドル円レート：1ドル=150円 ↩︎
-
エディション別クレジット単価：Standard 2.85ドル、Enterprise 4.3ドル、Business Critical 5.7 ドル ↩︎
Discussion