う〜ん、現状の正確なところが把握できてはいないのだが、実務ではやっぱり独学OJT組が多いのかな？
本番運用でPythonゴリ押し、というチームにしか当たらないのだが、大丈夫のなのか？
7、8年ほど前、「本番もHadoopとかPythonとかないっすわー。ApacheSparkでも使わないと」と言ってもプロパーの責任者に信じてもらえなくて、仕方ないので自分より権威のありそうなAWSの人に聞いてもらったところ、「海の向こうでは、プロトタイプ(分析、検証)はPython使っても、本番運用ではSpark使っているところが多いし、これからも増えるらしいよ」と報告してもらって、ようやく納得させられた。
そういう「権威」に頼らず、自分の頭で考えろよ。自明だろ？ と思うのだが、なぜそれができないんだろう？
残念ながらその時は、SparkがAWS EMRに乗るちょい前で、よそのチームがセルフホスティングのサービスで大障害を発生させてくれたおかげでセルフホスティング禁止となってSparkが使えなくなって、仕方ないので、データが溜まったところからMessageQueue駆動で順次できるところまで処理を進めておく感じで、日次バッチにかかる時間をかなり減らした(MessageQueue駆動バッチも増えてます、とAWSの人に教えてもらった。当然そうなっているはずだと考えていたので、こちらからこういう事例が増えているはずなので確認してみてくれ、と聞いたわけだが)。
HadoopもPythonバッチも、100万件のうちの1件目のデータも100万件目が処理されるまで次の工程に渡されない上、ネットワークファイルベースでのデータの受け渡しでSerDesに時間が取られるとか、「それって無駄じゃね？」、というところから開発されたのがSparkなわけで。
今の現場だと、6段くらいのPython/Pandasバッチで、データが利用できるようにするための導入処理もそのデータを作る処理も無茶時間がかかってて、ほぼ詰んでる。
んだけど、データの導入処理部分を並列化して速くしようと足掻いている。
いや、構造的にそこはそれほど劇的に速くなる部分じゃないし。
そもそもPython/Pandasってメモリを食ってしかも遅いというイメージしかないんだけど、今は速くなってんの？
こちらも構造的に速くなりそうな気がしないんだよね。
もちろん、Sparkを導入しさえすれば勝てる、というわけじゃなくて、ちゃんと考えてプログラムを組まないと遅くなる。
今の現場では「RedShiftめちゃ遅」と評価されているっぽいのだが、細かく確認してないけどまず間違いなく使い方を間違えている。
SQL文で処理が書けるからと言って、それはOracleとかMySQLとかのそれと同等というわけではなく、「MapReduce処理がSQL文で書ける」というだけの話なのを理解していないだけだと思われる(これも、以前の現場で注意を促したんだが、軽く無視されて、お披露目でサービスが落ちて、その機能自体が無かったことになるとかいう大失態を演じた、と風の噂に聞いた)。
データ連携日次バッチって、クライアントが便利に使えば使うほどデータが増えてUpload完了時間が遅くなっていくので、当然データ処理に使える時間が減っていく、ってのを理解(先読み、というほどのものでもないと思うのだが……)しないで、とにかく今のデータ量で詰め込めるだけ詰め込む、ということしか考えてなさそうで、困惑している。
今の仕組みが根本的にダメ、という判断ができないのか、どれくらい事態が切迫しているのか理解できないのか、他の選択肢(Spark)が頭に入らないのか。
なんだろ？
詰んでから考えるとか、やめてもらっていいですか？
今の現場ではそれほどもらってないので、八面六臂の活躍はしたくない……。
手柄はプロパーのものになるし、目処がついたら切られて、報われることは100%ないからね。