🐼パンダ達の欠点と利点🐼

関東では台風来来ですね。
風雨が凄かったけど、今は一休みな感じです。

そして表題、そう「Pandas」です。
問題は本体そのものだけじゃないんですけど、こいつらのライブラリってもうバグだらけです。。。

こんな書き出しから始まっていますが、前回の投稿の約束通りで諸々分散化処理ソリューションを試したことでパンダ達でバッチ処理するに当たって「出来る事」、「出来ない事」がハッキリしました。

先ずは、何故そういったアプローチを考えるに至ったか？ですけど、、そう、今のサンプルデータから特徴量を算出に当たって、地方競馬は「年間レース出走馬として13万～14万件」の計算をしなければならない訳です。
何が言いたいか？ですが、特徴量の一つとして、、開催レース毎の着順と「走破タイム」の差分（まぁ単純に申すと秒着差なdiffです）を取る必要があります。
このレース＆着順ごとの差分データと言う扱いをするデータはこの秒着差以外に2つ、都合で3種類を総数として13～14万件で行う必要があります。
単純計算で行くと、3倍すると処理総数は40万件超となります。
さて、「そんなのレース毎でgroup byして🐼のdiffライブラリで算出すれば簡単じゃん！」と思うでしょう？？
それが以前お話しした、このライブラリの「前後差分補完バグ」のせいで1着と最下位の差分にNULL（要は空白値）が代入されるという、データ分析では有るまじきお粗末な仕様が判明した訳です(´;ω;｀)

当然、補完する為にイテラブル処理で2行目-1行目をレース毎で減算処理として行いますよね？？
はい、このイテレーションですが、、13万件の処理となると「メッチャ時間が掛かる」訳です。
正にボトルネック。
なので、以下の施策を考えました。
１．小さなチャンクに処理を分ける（処理を小分けにする。）
２．処理そのものをマルチスレッドして並列化する
３．マルチプロセッシングで3要素を分けて処理を行う。
勿論、処理はレースIDの処理が取り合いとなる為に、タスクごとの排他処理であるlockを活用することにしました。

んで、この🐼。
こと分散化に於いて難しい計算処理が物凄く苦手のようで、、単一要素でのイテレーションでは問題なく動きます。
そもそもそれでは着順やレース間の計算すらごちゃ混ぜな差分計算をすることになり、意味がありません。
パンダ野郎どもは処理分散に際し、「group by要素が増えるような横串処理と、行に対する縦串処理」を掛けると、、完全に狂った計算を行う訳です。

チャンク：lock→重複出まくり、、そもそもlockする意味を成さない→却下
マルチスレッド：こいつもlockしてて重複でまくり→却下
マルチプロセッシング：race_idってあれよね？indexよね？？
　　　　　　　　　　　同じインデなオートナンバリングで良いでしょ？
　　　　　　　　　　　race_id:1処理実行！差分の値は0代入！！
　　　　　　　　　　　あれ矛盾だわ？ほなスタックトレース出そう！
　　　　　　　　　　　→使えるかばっきゃろ―――な却下

こいつら本当揃いも揃って処理の仕方がバカ揃いだな（怒）

Dask使ったら大規模バッチもいけるだろう～→処理止まる。
よしじゃ、🐼とは一線画す軽い「Ray」で並列化だ！！

そういえば…そもそもで考えてもみろ？？
根本的なイテレーションは、🐼ちゃん処理ですけど。。。(´;ω;｀)
あ、、詰んだ（苦笑）

「はい、終了～～～～！！」

根本です、、そう、何もかも🐼起因なんです。
忌々しい🐼野郎共め。。。という訳で分散化してボトルネック解消案は
結局諦めました。
バグ改修やら処理方法を変えるやら、、それらを一つずつ潰していくと猛烈な時間が掛かり、その間に処理は勝手に終わってる。

要はこの🐼達は「複雑な計算処理＋大規模処理」が２次元的計算のように組み合わさると直ぐにドロップアウトするという何とも使えない危険要素を孕んだミドルウェアなのです。
それはnumpy使っててもです！！（←次の投稿をご覧ください<(_ _)>）

これが「使えない点」という所以でもあります。

でも、この🐼、、ゴッソリデータを引っ張っていくのに、そのインデックス処理という問題点が逆に働いて楽なんですよ！

ここが凄く「使える点」なのです。

あっちを取れば、こっちが取れない、、という私の欲しい計算処理の再現性が🐼使うとシングルプロセスでしか動かないという事に至ったわけです。

そんな特異体質を持つこの🐼さんが更に活躍できる「使える点」があります。
このインデックス処理と言うのがミソです。
それは陸専用と言うか単一処理特化型ザクな感じですが、何とこれが物凄い力を発揮するのです。

そう、嘗てのフレームリレーのオールドテクノロジ、COBOLみたいな再帰処理や深淵計算が多いバッチ処理には最高なミドルウェアだったりします。
私も再帰処理が極めて多い、2万行の分岐計算処理を「実行コマンド一発run」なソースコードを作って走らせております。
ここは頭が下がりました、この処理計算は🐼しか有り得ません。
勿論なのですが再帰回数には限界があるので、調整しながら処理をさせましょう～。

もしも中級開発者の以上の方々ならお解りかと存じますが、このカタルシスによって見事この瞬間、浄化した処理も在ったという事です。

非同期処理は以前語った通りですが、スクレイピング処理するには非常に向いています。
ただここでもidの重複が無いように排他処理なlockを掛けてタスクごとの分散化処理を設計することをお勧めします。

それでは、又です！！