Mobility Technologies & DeNA 社内勉強会での発表資料です。

1. 2020.10.29
Ryosuke Kamesawa
株式会社 Mobility Technologies
Feature Store in
DRIVE CHART

2. 2
亀澤諒亮 / Ryosuke Kamesawa
- DeNA18新卒
- AI創薬: 2018/04 ~ 2019/09
- グラフML
- CHART: 2019/10 ~ (MoT 2020/04 ~)
- エッジML、MLOps
- 趣味とか
- Rust https://github.com/emakryo/rustdef
- 竸プロ (MoT #雑談_競技プログラミング)
- ボルダリング
自己紹介

3. 3
Outline
01｜Feature Storeとは
02｜事例の紹介
03｜OSSの紹介
04｜DRIVE CHART Feature Store

4. 4
中央集約的な特徴量管理システム
- 最近の機械学習システムの多くが大規模、複雑化
- データソース、特徴量、モデルの組み合わせが複数存在
- 問題点
- 開発環境と本番環境の違いによるデグレ
- モデル開発からデプロイまでが長期間化
- デプロイ後の検証が困難
- これらを解消する手段としてFeature Storeと
呼ばれるものを用意するケースが増えてきている
Feature Store とは
https://www.featurestore.org

5. 5
- どこまでをFeature Storeと呼ぶかは結構曖昧
- APIやETL（前処理）のワーカーなどを含むこともあれば
特徴量保存のストレージだけを指すことも
- 機能、特色
- 特徴量の保存/取得/共有
- Online/Offlineで共通のAPI
- Online: 推論、本番用、高速小容量
- Offline: 学習、検証用、低速大容量
- APIを通したfeature engineering とmodel training の分離
- 共通の特徴量の再利用、再現性の担保
- Time travel: 特定の時点の特徴量の取得
Feature Store とは

6. 6
- 各社事例
- Michelangelo (Uber)
- Zipline (Airbnb)
- Comcast
- and more https://www.featurestore.org/
- OSS
- Hopsworks
- Feast (GoJek/Google)
- SaaS
- Tecton https://www.tecton.ai/blog/what-is-a-feature-store/
事例・OSS

7. 7
Uberの機械学習パイプライン
Michelangelo
https://eng.uber.com/michelangelo-machine-learning-platform/

8. 8
Uberの機械学習パイプライン
Michelangelo
https://eng.uber.com/michelangelo-machine-learning-platform/
Feature Store

9. 9
Uberの機械学習パイプライン
Michelangelo
https://eng.uber.com/michelangelo-machine-learning-platform/
特徴量取得・前処理は
専用DSLを利用

10. 10
AirBnBのデータ管理プラットフォーム（特徴量計算エンジン）
- 宣言的な特徴量計算DSL
- イベントデータ（時系列）
Zipline
https://www.topbots.com/zipline-data-management-framework-by-airbnb/

11. 11
AIアシスタントのためのMLパイプライン
- Online/Offline Feature Store
- 特徴量生成パイプライン
- Streaming / On-Demand
Comcast
https://www.slideshare.net/databricks/operationalizing-machine-learningmanaging-pro
venance-from-raw-data-to-predictions-with-nabeel-sarwar

12. 12
シンプルなFeature Store OSS
- Online/Offline
- Historical retrieval
- Python / Java / Go SDK
Feast
https://docs.feast.dev/user-guide/architecture

13. 13
For data engineer
Feast - Python example

14. 14
For data scientist
Feast - Python example

15. 15
機械学習プラットフォームOSS
- 多機能
- ユーザー管理
- クラスタ管理
- 管理UI
- Notebook管理
- Feature Store
Hopsworks
https://hopsworks.readthedocs.io/en/stable/featurestore/guides/featurestore.html

16. 16
- Online/Offline store
- On-demand/cached features
- Time travel (w/ Apache Hudi)
- Python SDK / Scale SDK / SparkSQL
Hopsworks Feature Store
https://hopsworks.readthedocs.io/en/stable/featurestore/guides/featurestore.html

17. 17
DRIVE CHART Feature Store

18. 18
- 生データ（ドライブレコーダーから取得）
- センサーデータ（加速度、GPS、etc）
- エッジ推論データ（ドライバー顔ランドマーク、前方物体検出、etc）
- AWS EFS上に生データをCSVで保存
- 特徴量（前処理済データ）生成はデータサイエンティストが都度実行
- CSV以外のデータソースにアクセスする必要があり再現が大変
- EFSによるコスト（> S3)
- 明示的なCSVのスキーマ管理はなし
- 低コストでCSV管理を置き換えるようなFeature Storeが必要
DRIVE CHARTでのデータ管理（これまで）

19. 19
方針
- 内製
- Feast: GCP (BQ, GCS) が前提（CHARTはAWS）
- Hopsworks: 必要以上に複雑、運用が大変そう
- まずは現状のCSV管理を置き換える
- Data lakeのWrapper APIという側面
- 最初はミニマルな構成でOffline (学習用）だけを実装
- 最低限のAPI
- 保存/取得/削除
- スキーマ管理（validation / versioning)
DRIVE CHARTでのFeature Store

20. 20
構成: 単純なサーバー・クライアント
- サーバー：ストレージの実体を隠蔽したい
- 将来的にOffline/Onlineでストレージを切り替えても問題がないように
- Offline
- S3: 特徴量（parquet encoding)
- MySQL: メタデータ（スキーマ、バージョン）
- Offlineといってもサーバーをボトルネックにしない
- 実装はRust（高速・安全）
DRIVE CHARTでのFeature Store
ECS

21. 21
構成: 単純なサーバー・クライアント
- クライアント：ユーザーは基本的にPython
- APIはFeastを参考
- pandas DataFrameを用いるAPI
- スキーマとデータの分離
- キャッシュの管理も行う
- S3の遅さを補う
- 内部的にはgRPCなので他言語からも利用可能
- gRPC: 高速・Streaming
DRIVE CHARTでのFeature Store
ECS

22. 22
- Web UI
- 再利用性、一覧性、検索性
- 統計量のモニタリング
- Data driftの検出
- 複雑なクエリ
- 複数entities (primary key)の join
- Time travel
- 過去の特定の時点の特徴量の取得
DRIVE CHART Feature Store - Future Direction

23. 23
- Feature Store
- 中央集約的な特徴量管理
- 大規模な機械学習システムではよく用いられる
- DRIVE CHARTでは内製
- 低コストでCSV管理を置き換えたい
- 現状はシンプルな構成、API
- 拡張の余地はある
まとめ