他の分野でもそうだろうけど、システム関係では、これは物理的障壁と同じくらい硬い壁だったりする。
一年前、Rustやりたいとこのブログに書いて、今お気楽にRustプログラムをやっているんだけど、隣の部署のバッチ処理が、やばい。
大したデータ量じゃないのに、むちゃくちゃ時間がかかってる。
あそこを小改善して十数分短縮、ここを小改善して30分短縮。
でも、本番データはその10倍とかいうデカさ。
どう考えても日次バッチが24時間で終わらない。
でも、次はどこを改善して短縮するか、って頭を捻ってる。
何故、「アプローチの仕方が間違えている」と思わないのか、さっぱり理解ができない。
学校のテストでも「うわ、計算量が爆発する!」って感じたら、別の解法がないか考えると思うのだが……。
15年以上前のバッチ処理の考え方のまま大規模化しているってのが根本原因で、それにWeb記事に書かれていた「機械学習には××」という言葉を真に受けて、ちゃんぽんにしたのが最大の間違え。
すでに開発が開始されて半年以上経っていて、アドホックな修正も結構積み上がっている気配があり、「じゃ、やって」と言われたくないので、それとなくヒントをガンガン流しまくっているのに、誰一人として「ピン」ときてくれない。
一つ目のデータは、最後のデータを待たなくてはならないのか？
これがビッグデータ処理の一番でかい分水嶺。
Noだとしたら、昔のダム(ステップ)バッチ手法はビッグデータを扱う場合、絶対に取っちゃいけない手法なんだよね。
同じ口から「マルチスレッド処理だと速くなる」という言葉が出てくると「ほんとに理解してんのかな？」と思う。
解説する。
昔ながらのバッチ処理は、田舎のワクチン接種会場みたいなものだと思って欲しい。
接種対象者が10人くらいなので、マイクロバスで接種会場に連れてきて、受付前に並ばせて、1人の医者が1人問診しては待たせて、と10人問診した後、次の机で1人ずつ注射を打つ感じだ。
10人くらいだから、ちょっとした待ち時間も大して苦にならないだろう。
が、ビッグデータが相手だとそうは言っていられない。
相手が3万人だとする。
3万人を受付前の空間に並べるのが難しい。
一度に注射を打てる医者は数人しかいないにもかかわらず、それだけ大きな箱が必要になる。
で、3万人の問診が終わらない限り、次のステップの接種が始められないという不合理。
3万人目を待つ1人目のイライラはどれほどのものだろうか？
で、問診を終わった人を滞留させる空間も必要とくる。
しかも、接種が終わっても、3万人目が接種後の観察期間が過ぎない限り解散にはならない。
どうよ、こんな仕組み？
幸い、新型コロナの接種会場はそんな馬鹿な仕組みをとっていない。
来た人、来た人をどんどん次のステップに流して行っている。
ビッグデータの処理だって同じ。
これに使うストリーム処理だってあるんだよ。
あたりまで説明してるのに、ピンとこないってどうよ？
正直、技術者廃業してくれたほうが、いろんな人を不幸にしないで済むとか思ってしまうレベル。
その他にも色々と根本的改善をしてきているのだが、どうも「本来あるべき状態になっただけ」と、大して感謝もされないどころか、「今までの投資額からすると大損だ」と思われている節があって、うんざり感がハンパない。
もっと勉強してくれ、というとWebページを探しまくるだろうから、「もっと頭を使ってくれ」と言うしかないんだろうが、どのボロボロ現場に行っても同じような技術者が同じように見当違いのことを続けていて、それが10や20じゃ効かないんだろうな、と思うと気が遠くなってくる。