SnowflakeにおけるNotebooks開発

背景

SnowflakeでNotebookがPreview Featureとして公開されました。S3に対してちょっとした処理を定期的に実行したいケースがあり、Notebookを定期実行がお手軽で良いのではと思い調べ始めました。ただ仮にお手軽だとしても、GitHubで管理したりブランチ切ってプルリクを出すなどDevOpsに載せる必要はあるので、その場合どうなるのかなども合わせて検討してみました。

準備

ノートブック管理用DBの作成

画面をポチポチしてNotebookという名のDBを作成。

GitHub関連のオブジェクト作成

1. 公式のサンプルクエリを参考に、secretとGitHubのAPI統合を作成
2. git_rep_notebooksという名称のGitリポジトリオブジェクトを作成。

仕様ポイント：

• リポジトリオブジェクトはスキーマオブジェクトで、指定したスキーマに作成される（今回はnotebook.public）

Notebooksの作成

1. Notebooks名、作成先のDB.SCHEMAを指定してNotebooksを作成

仕様ポイント：

• NotebooksはWorksheetsのディレクトリのようなオブジェクトで、名前の通り複数のノートブックやファイルを管理可能
• DB.SCHEMAを指定する点からも分かるように、Notebooksはスキーマオブジェクトとして管理（ユーザーに紐づくWorksheetsとは異なる）

  https://docs.snowflake.com/en/user-guide/ui-snowsight/notebooks
  Make use of the role-based access control and other data governance functionality available in Snowflake to allow other users with the same role to view and collaborate on the notebook.

• 個々のNotebooksに対して権限を設定可能。そのため、定期実行する対象のプロダクションNotebooksは特定のユーザーのみ操作が行えるような制御が可能そう

NotebooksのCommit

1. 適当な処理を書いた後、Connect GitHub Repositoryをクリック

2. リポジトリ上のブランチとディレクトリを選択. ここではmainブランチの、予め作成しておいた procedures_s3 ディレクトリを選択.
   

3. commitが要求されるため、commitメッセージやあらかじめ作成しておいたGitHubのPersonalTokensを指定しcommit

仕様ポイント：

• commitは即座にリモートリポジトリに反映
• 指定したディレクトリに対して、{notebooks名}/notebooks配下のファイル群の構成でpushされる
  • モノレポの場合、root/snowflake/notebooks/{each_notebooks}のような構成が良さそう？

Notebooksの開発フロー

mainブランチ上のNotebooksがスケジューリングされたプロダクションノートブックと仮定し、以下のフローを追ってみます。

1. ブランチを切ってSnowflake上でNotebooksを修正しcommit
2. プルリクを作成し、mainブランチへマージ
3. プロダクションノートブックへ修正の反映

ブランチを切ってSnowflake上でNotebooksを修正しcommit

1. GitHubにてブランチを作成
2. Create from repositoryから上記ブランチと、ipynbファイルを指定してNotebooksを新規作成
   
3. Commit

Snowflakeからブランチを作成できたら便利ですが、現在はできない模様。

修正をcommitし、mainブランチへマージ

1. GitHubにてプルリクを作成
   
2. プルリクをAccept

分かっていたことですがnotebookの差分は見づらいですね、シンプルな実装じゃないとコードレビュー若干辛そう。

プロダクションノートブックへ修正の反映

1. プロダクションのNotebooksを開く
2. Pullをクリックし修正を反映
   
   ↓
   
3. 修正に利用したNotebooksを削除

Deployや修正に利用したNotebooksの削除が手動なのは少し面倒です。

まとめ

NotebooksをDevOpsやプロダクションのパイプラインに組み込んだ想定でどうなるかを検証してみました。ブランチ作成やPR作成のためにGitHubを開く必要性があったり、修正のたびにNotebooksの作成・削除が必要だったり、またNotebookである以上しょうがないですが修正差分の可読性に難があるなど、保守を想定した際に少しコストが高くつく部分がありそうです。

一方で、修正頻度が低かったり、シンプルな実装で済むケースにおいては問題なく運用できそうなイメージもつきます。また暫定的な実装として、PR無しでmainブランチを直接修正してしまうケースでは（あまりよろしくないですが）お手軽にパイプラインツールとして有望な選択肢になる可能性も感じました。