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

Proprietary + Confidential 11/25 17:00 | 18:00 Google Cloud オンライン
セミナーシリーズ Google Cloud Build とAI Platform ではじめる軽量 MLOps pipeline と AlphaSQL 松井誠泰様インターン株式会社JDSC 杉﨑琢人様シニアデータサイエンティスト株式会社JDSC 高橋佳奈子 Google Cloud

画質が悪い場合は、から画質を確認してみましょう。画質 ⚙

音量を調整したい場合は、 🔈 から調整しましょう。ミュートになっていることがあります。音量

Proprietary + Confidential セッション中にご質問いただくには、「質問はこちらから」をクリック。質問は承認後、視聴ページに表示され、 Google 社員より回答されます。ライブ Q
& A G Suite のセキュリティ、デバイス管理機能を使って、社内のリスクマネジメント方法をご紹介します。

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

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

1. 本日のSpeakerとJDSCのご紹介 ▪ Speaker自己紹介 ▪ JDSCとそのミッションについて ▪ 本基盤を利用しているプロダクトについて

本日の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級など ▪ 社会人学生として東京大学大学院越塚研究室にも所属し、機械学習のマーケティング応用について研究

会社概要 

(顧問就任予定)  

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

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年後以降に横展開）保有するソリューション群 

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

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

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

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

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

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

- 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

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

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

▪ 通常リモートへの書き込みには 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

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

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

3. 複雑な前処理SQLの依存関係解決とテスト ▪ 前処理クエリの複雑な依存関係管理 ▪ AlphaSQLの概要 ▪ SQLの動的解析（テスト）

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

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

依存関係の自動管理/自動並列化  CREATE TABLE SELECT SELECT Zeta SQL テーブル名を抽出

依存関係に基づくスキーマチェック 

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

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

今後の課題/クエリの差分実行 

We are hiring! 

セッションアンケートへのご回答をぜひお願いいたします。デスクトップでご覧の場合: セッション配信ページの画面の右側に表示されているアンケートフォームよりご回答をお願いいたします。スマートフォンでご覧の場合: セッション配信ページの画面トップに表示されているアンケート
フォームよりご回答をお願いいたします。セッションアンケート

Thank you

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

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

More Decks by JDSC

Featured

Transcript