風バイアス・NARスクレイピング⑤～高速化処理への道～（更新）

色々他のファクターである、馬番個別ラップ算出コード（←恐らく興味そそられますよね？、出来ますよ！自動で！！）等を生成AIと協調作成していて、戻ってきました気象庁の風向・風速スクレイピングです。

これ処理総数的に言って、非同期スクレイピング必要だったか？と聞かれると、、そうでもなかったかもしれません（苦笑）

元々は、レース×個別の馬番に合わせて風向・風速をスクレイピングするといった、本当に無駄な手段を取っていました。
でも、、レース毎で良かった訳で。。。頭数分の無駄スクレイピング処理をしていた為に遠回りしていました(´;ω;｀)

はい、燈台下暗し、、私のミスです。
実は処理総数を鑑みた結果が「非同期しかねぇ！」という処理手段を考えるに至った理由でした。。。

では、13万件のCSVを読み込んで惰性でただ単にiterrow処理に変更するか？ということは致しません。
非同期スクレイピング処理が勿体ないのでこのまま使いたいと思い、手法は変えずに月次処理を行う事にしました。処理総数がなんと約1/10に縮小ｗ
それでも1.3万件なのですけどね。

今度こそ順調なデータ生成だと思っていて、まぁ生成されたCSVを確認しないとどうとも言えないですが、極めて画期的な方法でスクレイピング処理が出来ていると自負しています！

１．処理年度はFrom/Toで指定できる
２．月次と日時は合わせてグループ化していて、更にフィルタリング要素を
　　含めてスクレイピング処理する為の値を抽出してタスク処理へ渡す。
３．実際のスクレイピングは位置をButifulsoupから抽出し、要素に合わせた
　　値抽出を行う。（この場合は風向・風速データ）
４．非同期タスクにて実際にスクレイピング実施
　　（引数を２のmain関数より引継ぎ）
５．データフレームのtmp(pickle)/gzip圧縮保存を実施、その際にデータの
　　整合性確認（df自体と保存されているgzip）と、重複データ削除、lock
　　排他制御を行う
６．全ての処理終了後に、余計なカラムをドロップしてCSVへ保存
　　生成時に重複データ削除と処理後のtmp削除

※重複データ削除は厳格にデータ圧縮時行っていたのですが、lock＋圧縮＋
　重複削除を併用するのは、余りにも処理が遅すぎまして（苦笑）
　重複を許容した上、最終処理での削除対処としました。
　（コード修正するのに、中断しても処理継続が出来るのはスゲーっす！）

付加機能としてリソース管理は勿論、耐障害性を鑑みて強制終了や不測の事態で処理が止まっても、タスク完了済みの続きから処理を行うことが出来る。
強制終了時に予約済み未処理タスクを完了タスク数から引いた処理を完了タスク数として補完して、処理の続きを引き継げるようにしている。
又、処理時間が掛かる場合はタスクをタイマーにて管理し、再起動してメモリの開放処理を行っている。

要は、「処理遅せーーー強制終了！」でも「あーー、やらなきゃ良かった、今までの処理がパ――(´;ω;｀)」という悲しい思いが無くなるという素晴らしきスクレイピングバッチなのです！！
処理途中で止めても、次の日だろうが続きが出来るRPG(RPBatchか？)です。
復活の呪文？要りません、保存データが消えました？？バックアップを2度に渡り行っております。
この継続処理の仕組み、本当に重要。
例え処理が重くなって排他制御がデッドロックしてても、Notebookの「ポチっとな～」で解除できるし。
再開すれば続き処理も処理スピードが復活するし、引き続きの処理が動く。
我ながら有難い仕様だよなぁ。
（誰もこんな途轍もなく面倒なコーディングやって無いだろうな。）

勿論、Pandasだけに、、メモリ最適化（ガベージコレクト）と初期化も適宜行っている。

※これからも🐼さん達との戯れにて上手く付き合えるか？は微妙ですｗ
　だって、なかなか融通利かないし言う事聞いてくれないのですもの(´;ω;｀)

たかがiterrowで済む処理を、そんな複雑な処理で行っている感じです（笑）
色々悩まされたし考えた処理手法でしたが、問題解決がとても面白かったです！
まぁ、未だデータが出来上がっていないのでちゃんと出来てるか？はこれから判明するのですけどね。
DEBUGログ見た限りだと、上手い事動いているっぽいです(∩´∀｀)∩

生成AIを使えばこのようなコーディング介助もお手の物なんですよね。
勿論「こうしたい！」というアイデアは彼らにありません。

難しい処理をしたければしたいほど、知見を求めてググってから彼らに質問する一手間が必要になるかも知れませんが、実現出来たらその成果は計り知れないでしょうね！
そういった気持ちを享受出来ると技術者冥利に尽きますし、とても幸せだと思います。

ところで私が何でこんなに風に拘るのか？
そうツール・ド・フランスで言う編隊方法、「エシュロン」という事を馬で行っている騎手もいるからなのですよね！
風雨の情報を開催競馬場毎の特徴に合わせて落とし込みして、数値分析が可能となると…はい、答えは目に見えてきます。

分析に必要な特徴量をテキスト編集して、更に明示された既存の情報のみで終わらせない事、、これらにきっと正解に近付けるヒントが隠されていると思っています。

失礼を承知で、、私もそうでしたが、きっと大部分の皆様の追及はここから馬券購入への道筋として「手計算（Excelも含む）」や「勘や経験値」という些か非合理的な手段で片付けてしまっていると勘案します。
（もっと簡単にしたいなら他責思考で他の方の予想に乗っかるとか。）

又は、一歩踏み込んで機械学習AIを取り入れているとて、複雑化した計算もせずに情報をそのまま使うと言うのが一般的だと思います。
他者のソースコードを引用しているだけとかだと、例えば学習動画見てても残念ながら小手先なコーディング技法のみが、スキルとして蓄積される迄と成り得るわけです。
まるでオライリーを読んでるような、ググって答えを求めるような知見のみが習得されます。

しかしながら、鵜呑みだけでは一向に先へ進みません。
複雑化した計算と言うのは、アイデアが無いと先に進みませんからね。
幾ら優秀な生成AIであっても、何のアイデアを生む決定権が無い彼らに、人間の産み出すこの部分を担保するのは無理です。
最近の生成AIは極めて優秀なので勘違いされがちですが、彼らに人間が考えているようなインスピレーションやアイデアにクオリティを含めて結果を求めるのは、現段階では難しいのです。
しかしながら、笑点の様にお題を与えてオチを求めることは可能です。

生成AIへの質問はあれやこれやトライアンドエラーしながら、動的質問しながら根気よくデバッグを行い、ソースコードの問題解決まで導きます。
デグレートなんて日常茶飯事ですし、そこに怒りを感じる時も日常茶飯事。
リアルタイム性が多く、学習動画化するのも難しいでしょうね。
又、産み出したアイデアだけは誰・何人たりとも侵害できないのです。
私がソースコードを例え有料であっても開示・提供しないと言うのは、総合してこういった判断理由もありますね。

私の場合はここに「手動計算によるヒューマンエラー」を徹底的に無くし、飽くなき追及を自動計算と言う手段で模索しながら、この膨大な特徴量をBIGDATAとしてインプットさせて、機械学習AIにてヒューマンエラー無き予測で「最適化」したいのですよね。

解り易く言うとこの考え過ぎな逆神予想のオッサンが、予想するのと馬券買うのを楽したいのですｗ
構築するまでは物凄く大変ですけどね。
サグラダファミリアみたいに、その生涯で未完成は出来るだけ避けたいものです（苦笑）

それでは、又です！！