gokartの運用と課題について

 gokartの運用と課題について

以下の『MLOps勉強会』 の資料です
https://m3-engineer.connpass.com/event/159721/

620c94b3affc3376c62540a64ce7ba36?s=128

vaaaaanquish

February 05, 2020
Tweet

Transcript

  1. 5.

    gokart
 • エムスリーが作成している luigi wrapper ◦ 簡易でテストの行い易い class設計 ◦ パラメータhashによるデータ管理

    ◦ 自動ログによる再現性 ◦ InstanceをPrameterとして扱えるようサポート ◦ 外部ライブラリ ▪ cookiecutter-gokart : gokartプロジェクトテンプレート ▪ redshells : 機械学習モデル task群 ▪ thunderbolt : データ管理 ▪ luigi_completion : CLI補完ツール • 現状どの機械学習ワークフローライブラリより扱い易く 機械学習プロジェクトの事を考えて作られたライブラリ(だと思っている)
  2. 7.

    本当にベストか調べた • 技術書展8 ◦ Day2 お-46 ◦ エムスリーテックブック 2 ◦

    『機械学習ワークフローライブラリ選定と運用事例』 ◦ ワークフロー比較と選定のコツとか 20ページ書きました
  3. 9.

    機械学習ワークフローの分類 • 主目的で概ね以下のどこかに分類される ◦ 機械学習モデリング ◦ モデルバージョニング ◦ クラウド、データストレージ管理、規格化 ◦

    特徴量生成自動化、学習自動化 ◦ パラメータ最適化 ◦ 機械学習モデル本番運用 ◦ 分散処理、インフラオーケストレーション ◦ クラウドサービス、Function as a Service ◦ データサイエンス、ETLプラットフォーム • luigi, gokart, metaflow, kedro, mlflow, sklearn pipline ...等
  4. 11.

    gokartがサポートしている所 • データ、特徴量加工の冪等性、再現性 ◦ 全てのタスクをパラメータから生成した hash値を付けて保存 ◦ ログにも情報保存して実行を再現可能に ◦ pandasのcolumn型チェック、入出力フォーマットの制約などの機能

    • MLモデルの保守性 ◦ cookiecutterによるプロジェクト構成共通化 ◦ 拡張パラメータによる管理と実験結果の保持 ◦ Thunderboltによるデータ管理 ◦ Redshellsによる学習アルゴリズムの共通化 ◦ Gitリポジトリとデータを自動保存している作業ディレクトリ ($TASK_WORKSPACE_DIRECTORY) を共有すれば他メンバーがすぐ再現できる高い保守性
  5. 12.

    gokartがサポートしていない所 • MLモデル間の依存性 ◦ Feature Store管理ツールのような、ある MLモデルが生成した特徴量の管理等は強く行っていない ◦ 複数プロジェクトで複数 $TASK_WORKSPACE_DIRECTORYが更新されるような状態は考慮していない

    ◦ 1プロジェクト1モジュール • MLモデルのスケーラビリティ ◦ 本番環境でpredictの度にオンライン学習といった状態には不向き ◦ batchでもhadoop, spark等の分散学習サポートは強くない ▪ luigiが一部サポートはしている • MLモデルの説明可能性 ◦ DAG可視化ツールは luigiのものは使える ◦ 特徴量の可視化や EDAは別途必要
  6. 13.

    外部評価 • 先日公開されたPipeline比較記事 でも良い評価 • nishikaコンペで入賞(審査中) ◦ 自然言語処理とMLのコンペ ◦ コードも公開予定

    • (GitHub Star数が少ない…) PythonのPipelineパッケージ比較:Airflow, Luigi, Gokart, Metaflow, Kedro, PipelineX
 @Minyus86 2020/2/4 - https://qiita.com/Minyus86/items/70622a1502b92ac6b29c より引用

  7. 18.

    gokartタスクを走らせる • python hoge.py [task_namespace].[ClassName] --local-scheduler ◦ luigi_completionを使うと補完してくれるので便利 • モジュールバージョン、実行時間、ログ、パラメータ

    TaskA、TaskB、TaskCの結果がパラメータに応じた ハッシュ値付きで ./resource 配下に全て保存されている • パラメータ変えれば勝手に保存してくれるので 手を加えてunittest書いて実行を繰り返すだけ! DDD!
  8. 22.

    redshellsがサポートしているモデル • XGBoost • LightGBM (#PR 49) • CatBoost (#PR

    49) • Factorization Machine • Graph Convolutional Neural Network • pairwise similarity • GCMC • LDA • SCDV • TF-IDF • doc2vec • fasttext • word2vec たくさん
  9. 24.

    エムスリーにおけるgokart開発 • 基本的には1人1プロジェクト ◦ gokartでMLモデルと結果を生成する Batchを書く ◦ AWS ECS Batch

    / GCE / GKE ◦ BigQuery / GCS / S3 • cookiecutter-m3gokart, 共通タスクライブラリ を別途独自に作成 ◦ 各プロジェクトのディレクトリ構成が同じ ◦ GCPやAWS周りの社内向けタスク、 SQLなど共通化
  10. 26.

    エムスリーにおけるgokart開発の前提 • Dailyでの学習・推論Batchがメイン ◦ オンライン学習、分散処理、画像認識などの大規模 Taskはない ◦ 利用クラウドサービスも増えているが現状多くはない ▪ 今後Elasticsearch等をサポートしていく事になるとは思われるが

    ◦ ターゲットユーザが医療業界に絞られている ▪ サービス要件が急激に増減しない ▪ ドメイン、データ分布が急変しない • 全員がgokartを利用し、周辺のツールをメンテしていく ◦ プロジェクト、class設計、unittestが統一的に ◦ 機械学習モデルのオフライン評価、 KPIのためのデータ出力まで gokartで通す ▪ メンテナンス、reviewがかなり楽
  11. 27.

    gokartにおける課題 • タスクごとにリソースがスケールしない ◦ gokartのタスク粒度の設計が難しい ◦ 例: ▪ あるTaskA:メモリは1GBしか使わないが長時間かかる前処理タスク ▪

    あるTaskB:メモリを10GB使うモデル学習タスク ▪ gokartのrequiresで接続するとTaskAとTaskBが同じDaily Batchに含まれる • Airflowなどで適切なクラウドサービスを使えれば良いが … • 可視化が個人に委ねられている ◦ 他ワークフローライブラリのようなタスク入出力、統計量の可視化はサポートしていない ◦ あくまでThunderboltのようなツールでのコード管理を徹底 ◦ タスク結合の結果壊れている事に気付きにくい ▪ 一応pandasのcolumn型チェックが最近入りました
  12. 28.

    • 中間ファイル、キャッシュの取り扱いが難しい ◦ batchのrerun ≠ gokart task rerun ◦ 例:日割りのデータ

    ▪ 前日分のデータは前日の batchがgokartで生成したファイルで良い • パラメータが同じであれば結果は冪等 ▪ 前日分がバグで空のデータになっている • hash値付データの存在で task.completeと認識されgokart的には動作 • 気付きにくい ◦ 例:他PJで生成されたデータやコード変更の反映 ▪ キャッシュのhash値が変化しない ▪ モデリングした人とデプロイした人の認識があってないと事故 ◦ モデリング時嬉しくても本番で「キャッシュ」のように扱い始めたら注意! ▪ rerunの確認 ▪ versionなどのParameterの設定 gokartにおける課題 2019/2/1 2019/2/2 2019/2/3 データ破損, rerun必要 ファイル自体は存在し gokartは動作
  13. 31.

    買ってね! • 技術書展8 ◦ Day2 お-46 ◦ エムスリーテックブック 2 ◦

    『機械学習ワークフローライブラリ選定と運用事例』 ◦ ワークフロー比較と選定のコツとか 20ページ書きました