Gt_>>если миллиарды записей и развесистая логика где хочется нормального ООП, с наследованиями и патерн матчингом то надо брать spark.
MVK>Нет, ооп совсем не нужен, более того он тут только мешать будет. Спарк уже есть, конечно, но для других задач, для этой он плохо подходит.

именно тут спарк идеален, ты просто совсем нулевый как я погляжу.


Gt_>>как бонус сумашедшая параллельность, которую клик думаю любит. ну и упомянутые struct поля думаю спарк супортит.
MVK>А каким тут это боком? Спарк просто передаст запрос в кликхауз, кликзауз изобразит параллельность. Максимум, что он сможет это правильно раскидать запросы на кластер, но когда я последний раз туда смотрел, там все было кривовато с этим.

а зрение давно проверял ? ты явно не на спарк смотрел. спарк ничего не транслиует, спарк вычитывает в свой датафрейм и вся магия происходит в его jvm. клик для спарка просто тупой сторидж, мало чем отличающийся от S3.

MVK>Но в целом, если данные лежат в каком-то паркете на S3 кластере, то спарк, конечно хорош. Ну или если есть зоопарк различных баз и файлов, и задачи хорошо ложатcя на map reduce. Ну и скала довольно выразительна для таких задач тоже.

scala умирает уже достаточно давно, может даже уже и не живая.
вобщем почитай концепции, попробуй вникнуть, где происходит магия и 100 раз подумай, прежде чем запихивать логику в тормозные udf.