今の現場でも話題に上がって、AWSの中の人と話をする場を設けたのだが、AWSの中の人はRedshiftの人なので、当然Redshiftをどううまく使うかの話になったわけだが、そもそも
その処理自体がRedshiftに全く向いていない
ので、Redshiftの使い方なりを最適化しても、たいして美味しくもクソもない、という結論にしかならないのだよね。
今の現場は、データ処理受託をしていて、ビッグデータでは、処理のためのデータ投入も、データの出力も、それなりに重いと、クライアントの規模が大きくなってデータも大きくなると簡単に破綻する。
ちょうどラクダの背に乗せた最後の藁一本が背骨をポキっと折るように、昨日まで大丈夫だったのに、ってレベルでも破綻する。
通常、クライアントから連携されるデータは、クライアント側の日次バッチが終わってからUploadされ始めるので、データが多い場合この日次バッチ自体が時間がかかり、Uploadも時間がかかるので、当然、×時までに処理完了必達とか言われたら、Upload完了からこちらの処理完了までの時間はどんどん削られていくことになる。
データが増えているのに！
処理にかけられる時間がどんどん削られていくんだよ！
一年前から警告を発して、数ヶ月かけてなんとか説得して設計実装開始、でつい先日、ようやく一番時間がかかっている部分をpySparkに移行、となったわけだけど、これやってなかったら、今年来るサンタはサタンになってた可能性が高い。
本当はscalaSparkでちゃんとした分散処理にしたほうがよかったんだが、処理を設計実装できる人手が足らんかった(自分は別箇所の、よりやばい部分のテコ入れをしていた)。
ただ、かなりよろしくない処理組みなので、早晩ビッグデータの呪いに見舞われて、再度移行プロジェクトとなるのは目に見えている。
そもそも、その処理にそのサービスを使うことが妥当か？
って検討は、サービス利用の最適化の前にしなきゃダメだよ、という話。