地方競馬のスクレイピング

表題の件について、週末競馬もやらずにNetkeibaさんのID引用の手段考察とPythonコーディングをしておりました。

結果的にCSVへ上手く取り込めました！嬉しい！！
データは更新で付け加えられるのでスクレイプ期間を範囲的に決めたとしても、CSVデータの取り扱いがシームレスになりました。

こんな感じです。

いやぁー、マジでやばかった(´;ω;｀)
主流のPandasと通常スクレイプの二段活用でデータ抽出を行っておりますが、嵌りまくって詰みまくりで若干諦め加減でコーディングを実施していました。

さて、嵌りの一段階目。
はい、全くデータが取り込めない事。。。
一回目の盲点で、race_resultsの辞書化。
そりゃ取り込めませんよね、初歩的なミスでした。

二段階目は言わずと知れた、Indexにrace_idを使用すること。
これは、簡単に関門通過できました。

本題は次の三段階目のスタックは、その他のID達。
実はrace_idのIndex化もそうですが、この子達の情報が一番欲しいのです！！
その為だけのPandas利用スクレイピングコーディングも採用したのは、言うまでもありません。
何なら必要なデータは、これら含む6つのcolumnデータだけで良いのです。
しかしこれがねぇ、、ご存じの方はご存じでしょうけれども、stringな文字列なんですよ。

これは本当にトラップですよ、気を付けてくださいね。
文字列データだけに、中央競馬のデータでさえも数値と勘違いしてたら数列の正規表現re検索である、(r\d/+)とか(r\d/{length値})とかの対応では、DataFlameなだけにせっかくコツコツとスクレイプしてた各IDデータについて、その個所からrace_id分だけ出走馬の各IDデータがスコンと空白になったり、インデント数値だけになったりと意味がないデータになってしまいます。
これは本当に勿体無い。

さてと、マジか―――、詰んだ、、大きな難問だｗ
はい、もういやーーーとなりました（苦笑）
気付くのとヒント探しに無茶苦茶時間が掛かりまくったので、途方に暮れていました。
何せ、これのお陰もあって事実が判明しても暫く修正できずに、遠い目をしながら現実から逃げ回ってました。。。
しかし意を決して向き合ってデバックしていたら、タプル活用で意外にあっさりと解決。

Netkeibaさんのrace_id運用方法が、中央と地方がまるで違う事は既知だと思いますが、DB登録についてもこれを活用して一意のIDでプライマリキーを生成すれば、、テーブルの一元化運用が出来るという事も判明しました。

このように各IDがDBに入っていれば、、、SQLでhorse_id毎のデータを纏めるのは勿論の事、馬主や調教師ランキングや馬の血統データからの分析や父血統成績、果て又BMSの成績からの血統相性までのSELECT文の抽出条件次第でいつでも引き出せるようになります。
これはでかいぞ！
テキストに引き出してからの機械学習させて、また箱へUPDATE/INSERTとかとかとか。
データの活用方法は自在です！
ただ、、IDの文字列検索が若干時間掛かるんだよなぁ。
複合条件なら更に、です。
使ってたIDが枯渇したから文字列化したのは解ります、けど、、これはなかなかメンドイっすねぇ。

何はさておき、この課題克服は本当に良かった(∩´∀｀)∩
データの欠損については、開催カレンダーから生成したrace_idを引っ張っております関係上、開催中止やカンパイなどのレース中止以外では無いものとこちらも整合性が取れたので、いよいよデータ活用のフェーズに移れるかな？と思っております。
勿論ですがrace_id総当たりスクレイピングでも、規則性さえ守っていれば欠損について大丈夫っちゃー大丈夫ですけどね。
その前に悪魔の総データスクレイピングが待っています。。。
これはルーティンワークなので、時間との戦いだけですね。

とはいえテストスクレイピングしてて、どうやらやはり重複データが4つずつ出てしまう様なので、DataFlame重複削除も追記、もう少しテストします。
→
やっぱ同時進行はダメでした、生成後のデータで重複削除するしか無いかな？
４つ重複が出来る理由は明確で、各ID生成分だけDataFlameが生成されてしまうからでした。
forで回すのも処理時間掛かるし、ここは今後のCSV読み出しと編集の自動化処理で巻き取ろうと思います。（処理時間短縮にはやはりNumpyか？？）

引続き頑張ります！

そういえば、スクレイプソースコードは他の方も開示していますね。
しかしその運用方法とか多岐にわたっていますし、インポートすべきPIPLISTなんかもバージョンアップなどで仕様が日常茶飯事で変わって、今まで使えたオプションが使えなくなったりとか、、動かなくなったらデバックしなきゃとかあるある事が多いわけで。。。
今後も含めて有料や無料でソースコードを開示しようとも思ったのですが、更に付け加えて個々のカスタマイズや開発環境依存にも寄りますし、、私的観点の考え方もあり、開示について一旦は止めておこうと思います。

その考え方というのは以下からですが、、、
環境依存までのフォローイングやフォローアップなんてのはとてもじゃないけど無理っす（泣）
そして全くのノープランとか考えも無しにPythonコーディングに手を出す、というのがイカンですぜ！
更に会社や学校でもないのでこうして下さい、というこちらからの開発環境提示とかいうのもなんか違う。
言うなればこんな感じです、という環境開示はアリですけど、それで何らかの原因で動かんとかのフォローは出来んということです。

しかしながら有料情報なら特にフォローが大変ですよね。
スキル習得含めてのソース開示に対価であるお金が動いています。
又はパッケージ売りとなっているなら、常にデバックに手が取られてしまうという感じです。
あくまでも予想を楽しむのがメインとするならば、ここで時間を取るなら元の木阿弥なのですよね。
そこでワンソースマルチユースをするなら、営業ベースで人的コストが必要となってしまうからですね。

一番の問題はソース開示が無料の場合。
ここで無為にソースコードをそのまま活用されている場合などで「何でか知らんけど、動かないんですけどー」とか、バグフィクス方法を尋ねられたとしても、問題個所をググって自己解決して下さいとしか言えなくなったりとか…(´;ω;｀)
そんなこんなで何か不親切で屁理屈言ってケチ臭くてすみません<(_ _)>

だがこんな奴でも、実際に稼働コストが掛かっていますから。。。
但し、この投稿のように既存開示のソースからでも修正するべき課題点などはヒントなどで指摘して、解決の糸口を公開できればと考えております！
コーディング手法を身に着けるも身に着けないもあなた次第です！
どうかご理解の程をお願い致します<(_ _)>

それでは！！