広告データの学習データ基盤を刷新した話

PTAのアドベントカレンダーの記事になります。

広告データの学習データ基盤を刷新しているのでその話を書きます。

広告データの学習データ基盤とは

広告配信システムではctr/cvrの予測をするために、imp,click,cvデータを使って、機械学習モデルを作り、学習させています。

今回はそのモデル学習に学習ログデータを転送、作成するシステムの刷新になります。

今までの学習データ基盤の構成

主にflumeを使ってログ転送しているのですが、前段にflume2台挟んでいたり、ignite使って、正例負例ラベルを作り、最後に学習データの加工をやって、モデルの学習を行っていました。

igniteは主に遅延してくるclick,cvデータを紐づけるために使われていました。

（大規模データの分散という意味合いもありますが）

今ままでの問題点

1. システムが複雑になりがち
   バリデーションやデータ結合システム、学習データ加工するシステムとわかれていたり、似たようなことやっているのに、ctr/cvrなどでインスタンスが分かれていたりで、共通部分の修正の場合、リリースを複数回やらないといけない

2. igneiteを使っているシステムで定期的にOOMが発生する

3. インフラコスト

新学習データ基盤の構成

刷新後はバリデーションや正例負例作成システムや学習データの加工のシステムを１つにまとめました。

ctr/cvrの学習データを作成するのも１つのシステムで担うので、コストや複雑化の回避を図っています。

また、今までigniteが担っていた役割をredisに任せ、キースペース通知でttlイベントを拾い、遅延してくるclick,cvデータを紐づけています。

（kinesisファミリーを使うプランもありましたが、コスト的に断念）

実際にリリースしてみて

完全切替えはまだできてないのですが、負荷テストやリリースしてみてですが、負荷的には大きな問題はなさそうで、コスト削減もできるのではないかと思います。

苦労している点は既存システムのデータと刷新システムのデータでそれぞれモデルを作って、オフラインのメトリクスで差分があった際の調査方法ですかね。

ここは何か良い方法を考えていきたいです。