Lean Baseball

No Engineering, No Baseball.

PyConJP 2022「Python使いのためのスポーツデータ解析のきほん」のトーク中に来た質問全てにお答えします

Google Cloud GCP Python PySpark データ基盤

トーク中に頂いた質問に答えます

本年2回目のPyConJP 2022振り返りブログです.

※発表及び参加レポ的なふりかえりはこちらになります.

改めて, トークに起こしいただいた皆さま誠にありがとうございました！

会場はもちろん, オンラインや後日アーカイブを見てくださった方も居たみたいで感謝感激です🙏

こちらのコンテンツですが, 実は質疑応答の質問及び（自画自賛ですが）回答が非常に秀逸でして,

非常に気持ちよく楽しませてもらいました, 過去のPyConJP, 個人的にはPyConJP以外のイベント含めて質疑応答がこんなに気持ちいいのは初めてでした！*1

せっかくなので,

当日お答えした回答を改めて言語化した上で, 時間の都合上答えられなかった質問にも答えよう！

というのがこのブログエントリーの主旨となります.

なお, Slidoで頂いた質問コメントはPyConJPスタッフのおかげで無事回収できました.

残務処理もある中, ご対応頂きありがとうございました！

なお, 本日のラインナップはこんな感じです.

TL;DR

ベストプラクティスは発表者の回答にはありません. あなたのやりたいことの中に隠れています.

これは設計も料金も一緒.

「Python使いのためのスポーツデータ解析のきほん」質問への回答

質問の回答ですが,

  • データ処理（Sparkを使うかほかを使うか?みたいな話）
  • Google Cloud（サービスの選び方, コスト視点）
  • 野球
  • その他

以上に分類した上で回答します.

なおコメントは原則原文のまま載せています.

データ処理

PySparkを使う基準

この2つ言ってることがほぼ一緒なのでまとめてお答えします.

  • PySparkを使う場合の基準となるデータ量はどれぐらいでしょうか？
  • データサイズが大きくなるとsparkで実行する価値があるんじゃないか、ということでしたが、データサイズが大きくなればなるほどBigQueryでデータ加工したほうが強いイメージだったのですが、sparkの方がいい部分としてどのようなことがあるでしょうか?

ざっくり答えると,

  • 私が思う答え「今回のユースケースであればPySparkである必要性が無い」
    • ただ使いたいから使った
    • CfPも通ったし
  • 一度の処理量でPandasじゃ無理な範囲や！！！ってなったらSpark（PySpark）を検討したら良いのでは?
  • なお, Dataprocとは別に「Spark in BigQuery」というBigQuery上でSparkを使う機能がいずれ提供されるのでそっちで全然いい説ある（使い方次第ですが）.

データ量やパフォーマンスを元にしたライブラリの使い分けはこちらもすごく参考になります.

並列化の有無による変化は?

Sparkといえば並列処理なのでこの質問は確かにありますねと.

PySparkを使うことで、並列化しない場合と比較してどの程度処理時間が短縮できるか気になりました

結論から言います, 短縮できるか否かは（質問された）あなたの使い方・設計次第なので答えることができません.

まず, 今回のデータは年間で1GB未満, 一日あたりのデータ量が10MBいかないぐらい（処理するレコード数は多くて5,000前後）なので「並列化するメリット」は無いと判断しやりませんでした.

ただこれはあくまで私の使い方・解きたいISSUEがそれぐらいのデータだったので, あんまり参考にならないんじゃないかなと思います.

良質な答えとしては, まずご自分で検証してベンチマークを取ってみる.

なのかなと.

Google Cloud

大前提として, Google Cloud（に限らず大抵のPublic Cloud）は料金計算ツールが存在するのでご自分で計算が可能です！

cloud.google.com

こちらを使うことで料金は計算可能です.

という前提の元, 自分の事例を元に回答します.

月額料金

差し支えなければGCPの月額料金を教えて欲しいです。

今回の構成だと以下のとおりです.

  • Memorystore（Redis）を使わなければ$5未満
  • Memorystore（Redis）を使うと最低でも$20, 推定$50程度

質疑応答では「5ドルでMemorystoreが高かった」的な答え方をしましたが, 若干ミスリードした感あるので改めて訂正いたします🙇🏻

これの細かい話をちょっとすると,

  • APIでアクセスするBigQueryやFirestoreと異なり, Memorystoreはミドルウェアのクライアントを使ってアクセスする必要がある（今回はBackendにredisのクライアントが必要だった）.
  • MemorystoreおよびGoogle Cloudの仕様上, サーバレスVPCアクセスの構成*2が必要となるためその分のコストも重なる.

という所でコストがかかりました.

データ量が増えた場合の料金影響

今回のケースではデータサイズがそれほど大きくなかったとのことですが数TBのデータを扱うことになった場合料金がどのくらいになりそうかご存知でしたら教えて欲しいです。

（質問された方の）ユースケース次第なので答えようがありません, 申し訳ございません.

料金計算ツールでの計算を強く推奨します.

他のサービスはどうなのか?GCPの場合

GCPでサーバレスETLを実装すると今回のDataprocや他にもDataflow, Vertex AI Pipeline, Cloud function(軽いデータの場合)など色々な選択肢があってどれを選ぶべきか悩むのですが技術選定の基準などがあれば教えていただきたいです。

資料のAppendixにあるのでこちらを御覧ください.

余談ですが, こちらはGoogle Cloudの認定資格「Professional Data Engineer」の出題範囲だったりしますのでこちらも見ると良いかなと思います.

cloud.google.com

データをロードする際、GCSからBigQueryに直接ロードして使う（ETL）ことも可能かと思います。今回紹介いただいた GCS -> Dataproc -> BQの構成にする利点があれば教えていただけますでしょうか。

今回のユースケースとは離れますが,

既存のプロダクトがSparkやHadoopで構成されている場合, 段階的な移行を実施するという観点で参考になるんじゃないかなと思います.

これはトークの最後でもお話しましたが, BigQueryだけでもできちゃうので, Sparkは外すつもりです&今回はあくまでトーク・発表の対策としてこのアーキテクチャを試したというのが本音です.

野球

いくつかコメント有りましたので回答します.

エグい選手の見つけ方

エグい選手はSparkによる統計結果を分析して発見されたんでしょうか?分析前に知らなかった実はエグい選手はいましたか?

これは発表にない部分でもありましたが, 今回Sparkでは統計的な処理は施しておらず, 統計的な処理はBigQueryでSQLを書いて行いました.

（これは質疑応答でも回答しましたが）今回Sparkは単なるバッチETLとして利用しており, 統計・機械学習的な事はやりませんでした.*3

取り上げた外野手3人（ジャッジ, ロドリゲス, バクストン）はある程度当たりがついていたこと, そもそも打球速度が早くてヤバいのは知っていたので取り上げました.

余談ですが, 調べている途中に思わぬ知らない選手がいたりとかして, そういった意味ではインサイトはありました（が, あんまり面白くなかったのでネタとしてはボツにしました）.

オオタニサン

事前のブログを含めていい話ができたと思います笑

shinyorke.hatenablog.com

スライダーの件は思わずウケたので良かったです.

ビッグデータとビッグボス

センターを守る外野手3人衆を取り上げてしっかりフラグ回収したんじゃないかなと思っています.

（阪神）関係ないやろ！

実は関係ありました.

その他

Dashの話くわしく！

今回の発表のスピンアウト作品として, このブログの記事もしくはどこかのLT大会（PyLadies Tokyoの周年パーティーあたりが有力）でお披露目できたらと思っています！

裏話をすると,

  • 実は当初Dashでアプリを作る予定は無かった.
  • が, 個人運用するデータ基盤のダッシュボードとしてDashを検討したい事もあり試しに作ったら思ったよりいい感じだった.
  • PySparkの話のみで, ビジュアル的に映えるコンテンツほしい！！！...となり本格的に作成・運用に至った.

という経緯があり, 実はPySpark周りの設計・実装以上にDashアプリケーションの設計・実装が一番時間がかかりました（これの話でもう一本CfP書ける程度に）.

ノータッチでいくのは実に勿体ないので絶対LTします, 乞うご期待.

質問の回答は以上です, ありがとうございました！

*1:どの時か?という言及はしませんが, 失礼なコメント, 微妙な意見などがあったりした回があってそれ以来質疑応答はなるべく受けない（感想をツイートしてくれたら答えるスタンス）スタイルにしていました.

*2:RedisやRDBMSみたいにサーバレスに向いていないものを接続するためのプロキシ, と思ってもらえればOKです. これはCloud SQLやAlloy DBといったRDBMS系のサービスとCloud Run/Functionsを繋ぐ時にも必要となります.

*3:本当は余裕あればそういう遊びも考えたのですが, 無かったので断念しました.