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

タクシーを「希望の日時に呼ぶ」 BigQueryによるAIとAPIインフラ

タクシーを「希望の日時に呼ぶ」 BigQueryによるAIとAPIインフラ

タクシー配車アプリGOでは、担当車両を事前に割り振らないまま希望日時に車両を呼ぶ「希望日時配車」の機能を提供しています。日本全国のタクシー情報、BigQuery、MLを用いてどのようにこの機能を実現しているかご紹介します。

GO Inc. AI Tech

March 03, 2021
Tweet

More Decks by GO Inc. AI Tech

Other Decks in Technology

Transcript

  1. 3 本日の構成 l 「希望の日時に呼ぶ」におけるAI ◦ 「希望日時配車」の概要 ◦ 実現のための数理モデル ◦ BigQueryを用いた必要データの集計

    ◦ BigQuery MLを用いたリアルタイム情報の活用 ◦ BigQueryの速度と価格 l AIデータを活用するAPIインフラ
  2. BigQuery ML (BQML) SQL上でMLモデルを作成する。 BQのデータを用いた学習や、推論 結果のBQへの書き出しが容易。 線形回帰モデルやXGBoostが利用 可能。 CREATE OR

    REPLACE MODEL car_model OPTIONS( MODEL_TYPE="LINEAR_REG" ) AS ( SELECT num_cars as label, before15min_cars, before30min_cars, before45min_cars, FROM TRAIN_DATA )
  3. 特徴量の作成 (擬似コード) 過去の履歴だけでなく、 SQL上でさまざまな特徴量を作 り精度を向上させている。 l 祝日かどうか l 東京からの距離 など。

    SELECT num_cars AS label, -- feature SIN(youbi / 7 * 2 * ACOS(-1)) AS sin_youbi, COS(youbi / 7 * 2 * ACOS(-1)) AS cos_youbi, latitude, longitude, dist_tokyo, is_weekend, is_holiday, avg_cars, LAG (cars, 1) OVER (ORDER BY ts_bin ), LAG (cars, 2) OVER (ORDER BY ts_bin ),
  4. BQMLのメリット / デメリット メリット l データがBQ上にある場合、データの取得・推論結果の格納が容易 l プロジェクトで用いるサービス数が減る デメリット l

    評価関数や損失関数が選べない l 学習プロセスのカスタマイズ性が低い (e.g: イテレーション回数) l ローカルでの結果と比較した方が良い
  5. 26 料金プラン BigQueryは2つの料金プランがある。 l オンデマンド : 読み込みデータ量に対して課金される。プロジェク トあたり同時実行スロット数 2000。スロット割り当て保証なし l

    定額プラン: スロット割り当てを予約する。割り当て保証があるため、 クエリの実行時間が安定する 定額プランを使いたいが、クエリの計算量が多いため割高になる。
  6. 30 クエリ高速化 テクニック例 BQ独自の高速化がいくつもある。 右はクエリ料金と引き換えに、 処理を高速化する並列readの例 WITH ... ), MULTIPLE_READ

    AS ( SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=0 UNION ALL SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=1 UNION ALL SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=2 ) SELECT 重い処理 FROM MULTIPLE_READ
  7. 全体像 - AIデータ活用 講演の前半 データ格納 集計、学習、推論 Cloud Storage BigQuery 格納

    App Engine GOサーバ GOアプリ GKE 予測サービス Cloud Storageに保存されているAIデータを活用し、 配車成功率の予測などを行う予測サービス
  8. 予測サービス – 概要 提供する機能(API) - 配車成功率予測 (場所と希望日時と他のユーザの希望によって) - 手配料金計算 -

    配車パラメータ確定(探車開始時間、配車範囲など) 処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine
  9. 予測サービス – 課題 処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する 課題 -

    場所や日時によって、使うべきGCSデータが異なる - GCSからデータを取得するには時間がかかる - GCSデータが継続的に更新されていく(15分に一回) - データ量が多い(1kmメッシュ数 x 時間bin数) (レコード数2億以上) GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine
  10. 予測サービス – アーキテクチャ 予測サービス Cloud Storage (GCS) Redis (Memory Store)

    Cloud Function gRPC サーバ App Engine GOサーバ データ更新ジョブ GCS新規ファイル 作成トリガー 低頻度更新データの更新 高頻度更新データの更新トリガー APIリクエスト データ取得 データ更新 データ更新 GKE
  11. 予測サービス – Redisメモリ最適化 データを単純に保存してしまうと使用メモリが増大 対策 - データフォーマットを変更することでデータ量を減らす - キーを省略してなるべく短くする -

    値のエンコーディングをJSONからMessagePackに切り替える - 元々バラバラになっていたデータを同じ構造体に合体させる - キーのハッシュ化
  12. 予測サービス – Redisメモリ最適化 キーのハッシュ化 - 普通の文字列キーを「subkey」と「field」に分ける - 文字列キーからハッシュキーに切り替える (SET key

    value から HSET subkey field value に切り替える) 説明:キーと値以外、キーのメタデータが保存される。ハッシュに変更することで、キー のメタデータが共有されてオーバヘッドが減る。「field」の数が少ない場合、Redisが内部 的にデータをHashTableからArrayとして持つためメモリ使用が更に減る 変更後 HSET <prefix>:523953 56 value HGET <prefix>:523953 56 元々 SET <prefix>:52395356 value GET <prefix>:52395356
  13. パフォーマンスと安定性を保証するために… - GCSデータをRedisに同期 - gRPCサーバで高速な予測APIを提供 大量データに対応するために… - データの持ち方調整 - Redisのメモリ最適化

    まとめ - AIデータを活用したインフラ 講演の前半 データ格納 集計、学習、推論 Cloud Storage BigQuery 格納 App Engine GOサーバ GOアプリ GKE 予測サービス Redis (Memory Store)