dely Tech Blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

推薦システムにおけるSnowparkの活用

こんにちは!クラシルバックエンドエンジニアの高松 @takarotooooooです。
今回はクラシルの推薦システムにおけるSnowparkの活用事例を経緯とともに紹介しようと思います。

Snowparkとは

DataFrame式のプログラミングを可能にする開発者向けツールで、現在はJava, Python, Scalaで利用することができます。
Snowparkを利用することで、SQLでは対応できなかったタスクがSnowflakeからデータの移動なしで実現できるようにデザインされています。

www.snowflake.com

推薦システムの概要

まずは、我々がどのように推薦システムのパイプラインを既に構築していたかをご紹介します。 下記のフローでデータの収集、加工し、ユーザーさん毎に推薦アイテムを提供しています。

推薦システムのパイプライン

  1. クライアントアプリケーションからユーザーさんの行動データをログとしてKinesis Data Firehose、S3を経由し、Snowflakeに収集される
  2. 収集されたデータを用いてユーザーさん毎に推薦アイテムのリストを生成する
  3. 生成された推薦アイテムをReverse ETLとして外部関数を経由してサーバーアプリケーションが利用するDBへ格納する
  4. サーバーアプリケーションはDBに格納された推薦アイテムをAPIのレスポンスとしてクライアントアプリケーションへ提供し、ユーザーさんへ推薦アイテムを届ける

詳しくは、こちらでもご紹介しているのでご覧ください。

tech.dely.jp

なぜSnowparkを利用するに至ったか

初期の推薦ロジックは視聴履歴を利用し、「このコンテンツを見ている人にはこのコンテンツを推薦する」といった、所謂ルールベースによる推薦を行なっていました。
「ユーザーさん毎の推薦アイテムリストを作成する」というSQLが存在し、Snowflakeのtaskが実行するとユーザーさん毎の推薦アイテムリストが抽出され、後続のtaskがそのリストを外部関数に対してリクエストすると言った具合です。

推薦ロジック初期状態

しかしながら、日々ルールベースロジックを更新していく中でルールは複雑になり、更新・デバッグの難易度が上がってきたことと、将来的に機械学習の導入を見据えるとSQLから何かしらのプログラミング言語に移行する必要性を感じてきました。

どのような構成にするかを考える上で、要件は下記で考えました。

  • 構築済みのニアリアルタイムなパイプラインは引き続き活かせること
  • データの移動は極力なしにすること
  • 機械学習を導入した際に学習、推論も同じ構成で実現可能であること
  • webアプリケーションエンジニアも理解・開発できるようにRubyまたはPythonで実装できること

この結果Snowpark for Pythonを利用してみることにしました。

導入時にしたこと

大きく二つのことを行いました。

  • SQLで書かれた既存のルールベースロジックと同じ結果を出力するプログラムをPythonで実装する
  • PythonのコードをSnowflakeのtaskから実行する方法を検討する

まずは既存のルールベースロジックをSnowpark for PythonのクライアントAPIを利用して再現できることを目指しました。

2つ目に「構築済みのニアリアルタイムなデータパイプラインは引き続き活かせること」を要件としていたので、コードで書き換えたルールベースロジックをSnowflakeのtaskから実行できる方法を検討しました。
こちらは結果として、Pythonで書かれたルールベースロジックをstored procedureとして登録し、taskから呼び出すことでデータパイプラインの構成は変えず、SQL -> Pythonへの書き換えを達成しました。

docs.snowflake.com

機械学習の導入

しばらくルールベースロジックの開発を続けた後、機械学習導入の検討を始めました。
機械学習の導入における要件は下記で考えました。

  • 引き続き構築済みのニアリアルタイムなデータパイプラインは引き続き活かせること
  • ルールベースロジックと機械学習ロジックのABテストを実現できること
  • 学習もSnowflakeのtaskによって実現できること

既存のデータパイプライン構成は引き続き変えず、ルールベースロジックとの比較を行うためにtaskから実行されるstored procedureは引き続き利用することにしました。 stored procedureで登録した処理内部にABテストの仕組みも導入し、既存のルールベースロジックと機械学習ロジックが振り分けられるようにしました。

機械学習の導入にはルールベースとは別に学習の仕組みが必要になるので、学習を実行するstored procedureを作成しモデルを学習させ、学習済みモデルをimportする形で推論のstored procedureを更新することで、次回から再学習されたモデルが推論で利用されるようにしました。

推薦ロジックのシミュレータとしての利用

ルールベース、機械学習モデルともに、推薦システムにおいて誰にどんなコンテンツが推薦されるのかを確認できるようにするため、シミュレータをSnowparkとStreamlitを利用して作りました。

Streamlitは簡単にwebアプリケーションを作成できるPython用のフレームワークです。
webのフロントエンドの知識がなくても、webアプリケーションが作れるようになっているので、分析結果の可視化などでもとても役に立つフレームワークとなっています。 streamlit.io

我々がここで作ったシミュレータはstored procedureと同様の方法でアプリケーションが推薦ロジックを呼び出す形で作りました。
シミュレータのおかげで

  • 新しい推薦ロジックを作り
  • シミュレータで確認し
  • 問題なければstored procedureを更新する

というサイクルで、事故なく開発を続けることができました。

まとめ

Snowparkを利用することで、現行のデータパイプラインを極力変更せずに推薦システムにおいて機械学習の導入をデータの入力(収集、加工)から学習、推論を通して出力までE2EでSnowflake内で完結させることができました。
つまり最初のご紹介の通り、Snowparkを利用することで、SQLでは実現できないタスクをデータの移動なく実現することができたわけです。

今後も推薦システムに限らず、いろいろな場面で活用していきたいなと思っています。

careers.dely.jp