Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Google Cloud Build とAI Platformではじめる軽量MLOps pip...

Avatar for JDSC JDSC
March 18, 2021
450

Google Cloud Build とAI Platformではじめる軽量MLOps pipelineとAlphaSQL

Google Cloudオンラインセミナーでお話したスライドです。

Avatar for JDSC

JDSC

March 18, 2021
Tweet

Transcript

  1. Proprietary + Confidential 11/25 17:00 | 18:00 Google Cloud オンライン

    セミナーシリーズ Google Cloud Build とAI Platform ではじめる 軽量 MLOps pipeline と AlphaSQL 松井 誠泰様 インターン 株式会社JDSC 杉﨑 琢人様 シニアデータサイエンティスト 株式会社JDSC 高橋 佳奈子 Google Cloud
  2. 6
  Confidential © Japan Data Science Consortium. All rights reserved. 


    本日の発表内容
 1. 本日のSpeakerとJDSCのご紹介 2. クラスタレスなMLワークフロー基盤の実装 3. 複雑な前処理SQLの依存関係解決とテスト
  3. 7
  Confidential © Japan Data Science Consortium. All rights reserved. 


    1. 本日のSpeakerとJDSCのご紹介 ▪ Speaker自己紹介 ▪ JDSCとそのミッションについて ▪ 本基盤を利用しているプロダクトについて
  4. 8
  Confidential © Japan Data Science Consortium. All rights reserved. 


    本日のSpeaker
 杉﨑 琢人(Sugisaki Takuto) 松井 誠泰(Matsui Masahiro) ▪ JDSCのインターンとして機械学習基盤の開発を 行うほか、Cybozu Lab Youth では言語処理系の 研究を行う ▪ Google Japan Search Team, Microsoft Development Windows Team, Merpay Expert Team にてソフトウェアエンジニアインターンを経 験 ▪ 東京大学大学院 学際情報学府 越塚研究室修士1年 ▪ JDSCのシニアデータサイエンティストとして PM・ モデル構築・データ基盤構築など幅広い業務を 担当 ▪ 前職は三菱商事のIT/管理部門だったが、趣味 が高じて5年間Qiitaを読み続けた結果、いつの 間にか転職していた ▪ 主な資格にGoogle Cloud Professional Data Engineer、応用情報技術者、日商簿記検定 1級 など ▪ 社会人学生として東京大学大学院越塚研究室 にも所属し、機械学習のマーケティング応用に ついて研究
  5. 14
  Confidential © Japan Data Science Consortium. All right reserved. 


    電力データ
 からの動的状態予測・
 配送最適化アルゴリズム 卸・小売向け需要予測・在庫最適 化アルゴリズム ライフラインデータを用いた 
 フレイル等、状態検知
 アルゴリズム 共著国際学会論文 4本   特許件数 3件
 2018年~
 2018年~
 2019年~
 東京大学との共同研究開発成果

  6. 15
  Confidential © Japan Data Science Consortium. All right reserved. 


    収益インパクト:小~中 収益インパクト:中~大 収益インパクト:大~特大 Zero Re-Delivery 不在配送回避ルートナビ frontconnect 製薬会社向け オンライン営業ツール Price/Flyer Insight 価格・販促商品最適化 アプリケーション Demand Insight 需要予測・在庫最適化 アプリケーション Life Context API 電力解析API (在不在・フレイル・世帯属性) Adaptive Learning 最適問題・ヒント提示アルゴリズム Data Platform ビッグデータ基盤構築 Business Data Robust Data Lake Data Mart Big Data Analytics / ML 既にトップ企業に導入中で横展開が始まっているソリューションに加えて、中長期では電力 データを活用したインパクトの大きいソリューションの展開も仕込んでいる
 業界内で展開中 業界トップ企業に導入中 (今~1年以内に横展開) 業界トップ企業とPoC中 (2年後以降に横展開) 保有するソリューション群

  7. 16
  Confidential © Japan Data Science Consortium. All rights reserved. 


    本日はそのうちresponse insightというソリューションの開発でJDSCの チームが工夫している点をご共有します
 予測なし Response予測
 Uplift予測
 デジタル
 マーケ
 DM マーケ
 一般企業
 先進企業
 一般企業
 先進企業
 ▪ 無差別にオ ファー
 Level0 ターゲティングなし
 Level1 グルーピング Level2 ML
 Level3 CI(因果推論) ▪ RFMや誕生日な ど特定条件でオ ファー
 ▪ 人力での作業 が主となる
 ▪ 反応しやすい人 を機械学習で抽 出
 ▪ One to One化を 実現
 ▪ オファーによる 純粋な効果に着 目
 ▪ 実験と活用の繰 り返し

  8. 17
  Confidential © Japan Data Science Consortium. All rights reserved. 


    2. クラスタレスなMLワークフロー基盤の実装 ▪ JDSCにおける課題・ニーズ ▪ Google Cloud Buildを用いたMLパイプラインの概要 ▪ 本基盤における実装上の工夫
  9. 18
  Confidential © Japan Data Science Consortium. All rights reserved. 


    前提
 ▪ 社内に多数のプロジェクトが存在 - それぞれ別のクライアント、パートナーが存在するため、権限やリソースを切り分ける必要があ る - 一つ一つのプロジェクトは2-4人程度の小規模なものが多く、リソースを割きづらい ▪ 殆どのプロジェクトではGoogle Cloud Platformを採用 - 一番の選定理由はBigQuery - (当時は存在しなかったが)現在であれば AI Platform Pipelinesも魅力的 ▪ 今回のプロジェクトではバッチ学習・バッチ予測のみ - ほぼ全ての前処理をBigQueryに統一できる - Feature Storeや推論APIのデプロイなどは不要
  10. 19
  Confidential © Japan Data Science Consortium. All rights reserved. 


    クラスタの常駐コストを伴わない、軽量なMLワークフロー基盤が求 められていた
 ▪ Kubernetesベースのクラスタを組む ことが多い - Cloud Composer(Apache Airflow) - AI Platform pipelines(Kubeflow) - etc. ▪ 1つのクラスタに集約する場合 - PJごとに異なるアクセス権限の切り 分けが煩雑 • データへの権限 • サービスへの権限 ▪ PJごとにクラスタを構築する場合 - クラスタごとに常駐コストが発生 • Composerの場合約10万円/月 • StagingやCI環境の切り方によって は掛け算的に増加 - メンテナンス負荷が高い 一般的なケース 今回のケースでの懸念点
  11. 20
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ワークフロー基盤開発時に考えていたこと
 ▪ 小規模PJなので、常駐コストは極力抑えたい ▪ クラスタ/サーバのメンテも最小限にしたい クラスタレス/ サーバレス 結果再現性 同時実行 Google Cloud サービスとの親和性 ▪ (当然ながら)タスクはコンテナベースで動いてほしい ▪ Jobの設定等をyaml等でバージョン管理したい ▪ 複数人で同時にJobを投げてもスケールしてほしい ▪ でもテーブル等が競合する場合は排他制御してほしい ▪ GCS、BQ、AI Platform などGoogle Cloud のサービスをカンタンに利用 したい ▪ 特に権限周り→なるべくcredentialは発行したくない
  12. 21
  Confidential © Japan Data Science Consortium. All rights reserved. 


    Cloud Buildを用いたMLワークフロー実装のコンセプト
 ① cloudbuild.yaml上で 必要なステップを記述す ることでパイプラインを定 義 ② 複雑な条件分岐は呼び 出し先のPythonで対応 (社内Package) ③ Computationが必要な場 面は基本マネージドに寄 せる 複数SQLの依存関係抽出&静的解析 依存関係付きSQLの並列実行 AIPF Jobs Training BigQuery 前処理 学習
  13. 22
  Confidential © Japan Data Science Consortium. All rights reserved. 


    - Linting - Unit Test (SQL ,python) VPC Data Layer Lake BigQuery Cloud Storage Compute Engine Container Registry AIPF Jobs Training Cloud Build DWH BigQuery Mart-LTV BigQuery Mart-ML BigQuery Prediction BigQuery Load_bq Process_query SCHEMAS Create_DHW Create_Mart Train logs Cloud Storage Github Select_target Training Validate_result Data Portal Pipeline Layer Send_household Validation_result Test Logging Cloudbuild.yaml config JDSC-Link GIS data BigQuery Market Index BigQuery Prediction/ Optimization Business Analysis Test Query MLFlow(Experiment Tracking) validate_table パイプラインの全体像
 Tableau(Dashboard) Circleci
  14. 23
  Confidential © Japan Data Science Consortium. All rights reserved. 


    パイプライン部分詳細
 Google Cloud Build ローカル実行 SQLの依存関係抽出 DAG生成 SQL静的テスト (実行時エラー回避) GCS→BQ load (DataLake作成) DAGからのBQ Job実行 (DWH、DataMart生成) SQL動的テスト (Data Validation) AI Platform にTraining Jobをデプロイ 結果確認
  15. 24
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ▪ GCS上での処理のアトミック性を保証するた めの機能である世代番号と前提条件を利用 する。 ▪ Jobのキャンセルや異常終了によってロック を削除できるとは限らないので、ロックを削 除するロジックをロック取得側に持たせる。 ▪ リソースの取得順を決定的なロジックとする ことでデッドロックも防止する。 実装上の工夫①GCSを利用したセマフォ
 Cloud Storage dataset_id_lake
 dataset_id_mart
 Job
 Job
 if_precondition_match=0 

  16. 25
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ▪ 通常リモートへの書き込みには DBが必要と なるMLFlowの実験管理を、GCSをバックエ ンドとしてホストできるプラグインを実装。 ▪ インストールしてGCSのパスを指定するだけ で使用可能。DB管理コストなし。 ▪ HTTPSコネクションやヘッダの通信コストが ボトルネックとなる特殊な状況で gsutil -mの 26.52倍高速な木構造アルゴリズムを実装 (7992オブジェクトで計測)。 ▪ セマフォと同じく前提条件とリトライによって 同時書き込みにも対応。 実装上の工夫②MLflow GCS Store Plugin
 Cloud Storage Blob Blob Blob Blob Blob Blob Composed Blob Blob Blob Blob Blob Blob Blob io.BytesIO
  17. 26
  Confidential © Japan Data Science Consortium. All rights reserved. 


    Cloud Buildベースのパイプラインを導入して良かったこと
 ▪ 基盤としてのRunning Costがほぼ無料(月数ドル) - ほぼ呼んでいるBQやAIPFのコストのみ コスト面 機能面 ▪ データ、サービス周りの権限管理がラク - ServiceAgentにロールを渡すのみでOK ▪ StagingやCIでも全く同じように動く - 起動時に向き先のデータセット/プロジェクトを変えるだけ ▪ LoggingやJobのステータス管理もラク - Cloud BuildのWEBコンソールやCloud Loggingを活用できる - ローカル実行時もログがストリームで取れる ▪ 呼び出し先のData/ServiceがOKであれば、同時に複数Job走らせても 難なくスケールする - 同じテーブルを触りにいく場合は排他制御を掛ける必要あり
  18. 27
  Confidential © Japan Data Science Consortium. All rights reserved. 


    Cloud Buildベースのパイプラインの注意点
 ▪ 単体で重たいタスクをこなすには限界がある - N1_HIGHCPU_32以上のインスタンスは指定できない ▪ AirflowのようにDAGの中身をWEB GUIで確認することができない - 特にDAGの一部が落ちた時の差分実行などは難しい ▪ AirflowのOperator相当のものはないので、自前実装になる
  19. 28
  Confidential © Japan Data Science Consortium. All rights reserved. 


    3. 複雑な前処理SQLの依存関係解決とテスト ▪ 前処理クエリの複雑な依存関係管理 ▪ AlphaSQLの概要 ▪ SQLの動的解析(テスト)
  20. 29
  Confidential © Japan Data Science Consortium. All rights reserved. 


    前処理クエリの複雑な依存関係管理
 ▪ 複雑なSQLの実行順・依存関係をどう管理するか? - ファイル名に添字で実行順を記述する? a. ~02.sql b. 並列実行の場合効果的な記述ができない。 - タスクの依存関係を手動で記述する? a. 複雑になると管理が大変。 - 巨大な1ファイルにまとめる? ▪ SQLのテストはどうする? - 単一SQLクエリの静的解析は十分されている( BigQueryの型は安心できる)ものの... - 複数ファイルとなると... a. クエリやもとのデータが変更されると、後続のクエリでエラーになることも ... i. (〇〇TBのクエリを含むパイプラインを動かして、終盤でエラーは時間的にもお財布的 にもつらい)
  21. 30
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ▪ SQL解析器の Google/ZetaSQL をライブラリとして使用し、静的解析によって SQLファイル間の依存 関係を抽出する。 - CREATE TABLEへの、それ以外のテーブル参照全てからの依存関係を自動で解決。 ▪ 各SQLクエリがCREATEするテーブルのスキーマも含めて、全体の SQLのスキーマ(型)の整合性を チェックする。 ▪ 抽出された依存関係をもとに、自動並列実行が可能。 ▪ 関連ツールを含めてOSSとして公開されている。 AlphaSQLの概要

  22. 31
  Confidential © Japan Data Science Consortium. All rights reserved. 


    依存関係の自動管理/自動並列化
 CREATE TABLE SELECT SELECT Zeta SQL テーブル名を抽出
  23. 33
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ▪ 自動でデータクオリティをチェックするツールの導入も検討したが、 ORM経由でのSQL実行がネック となりうまく動作しなかった。 - 今後の課題のひとつ ▪ 現状はunique keyを宣言的な記述で自動テストする仕組みや、 BigQueryのASSERT関数等を使っ てテストしている。 ▪ BigQueryのASSERT関数は便利 & AlphaSQLで自動的に並列テストが可能。 動的解析(テスト)

  24. 34
  Confidential © Japan Data Science Consortium. All rights reserved. 


    ▪ 全体を通して複数のコンポーネントが疎結合にパッケージ化されており、段階的に導入が可能。 - AlphaSQLのスキーマチェックから導入する、など。 - Cloud Composerと併用する事例もあった。 ▪ AlphaSQLのスキーマチェック - ほとんどの実行時エラーをCLIかCIで検知できるようになった。 a. 例外は経験上メモリエラーのみ b. 他にはlocationのズレや権限エラーも起こりうるが、それらはパイプライン側で防止できてい る。 - 失敗するまでクエリの実行を待つ時間が減ったことで開発が高速化した。 導入してみて