Apache Spark

[sshikov]

Вряд ли вам кто-то ответит на вопрос в такой постановке. Миллион строк за полчаса на одну ноду. И? Какова длина строки, если это реляционные данные — то сколько колонок и килобайт/мегабайт занимает строка? Сколько памяти у ноды, сколько ядер? Какие там диски? В чем состоит обработка? Где бутылочное горлышко — вы упираетесь в диски, память или процессор? Это вообще одна таблица, или есть скажем join?

Тут куча параметров. У нас спарк переваривает по одной из систем порядка десятков терабайт в сутки. Но никто не говорит, что это дешево — ресурсов на это уходит масса. Спарк просто позволит вам более-менее эффективно распараллелить свою задачу на все имеющиеся ресурсы — т.е. с пользой употребить скажем все ядра, и всю доступную память (скажем, если у вас есть ее терабайт на ноде).

Кроме всего прочего, Spark это не черный ящик с волшебной кнопкой. Это фреймворк для скалы/java/питона/R, и как быстро он будет работать, зависит от того, как вы его запрограммируете, в том числе. И на чем (скажем, python будет медленнее, в ряде случае — сильно).

[sshikov]

Если все уже более-менее разбито на куски, причем оптимально (т.е. нет например перекосов, когда все свалилось в одну партицию) — то вряд ли спарк вам принципиально что-то даст. Во всяком случае — даром (т.е. без того, чтобы программировать, оптимизировать и т.п.).

Ну т.е. я бы сказал, что пока ваши данные влезают в вашу память (общую память кластера) — вы можете почти ни о чем не думать (ну, при условии, что кластер у вас в монопольном пользовании), и достаточно точно прикинуть, сколько времени вы будете читать исходные данные с диска, писать обратно результаты, и переваривать их в памяти. И это будет более-менее плавно масштабироваться с наращиванием железок. А потом вы начинаете упираться в самые разные вещи, иногда совершенно неожиданные. Ну, условно, у хадупа скажем есть ограничение в миллион (1м) файлов в папке. Или еще какая-то непредсказуемая хрень.

И кстати, у нас нет насколько я знаю, ни одного кластера из 1000 нод, зато есть много размера примерно 100-200. И подозреваю я (это немного не моя работа), что есть некий предел, до которого можно легко масштабировать хадуп. И что-то похожее видимо будет и у вас — только в профиль.

[Geckelberryfinn]

В качестве эксперимента, возьмите Databricks (есть и в azure и в aws), загрузите ваш датасет и попробуйте его обработать. Сейчас датабрикс поддерживает pandas в pyspark (не всё, по моему опыту, но, возможно, вам хватит, либо обходные пути можно найти, я не знаю ваш случай). 10 стандартных нод будут стоит не так дорого, думаю, около 8-10 евро в час. Это не те же самые ноды, что будут у вас, но задешево может дать идею о масштабируемости вашего решения.

[sshikov]

Кстати хорошая идея. Проще попробовать. Насколько я помню, самые плохие (с точки зрения производительности) вещи в случае pyspark — это UDF, если их нет — то проще всего попробовать прямо в таком виде, как оно есть.

[sshikov]

Ну, смотрите — у спарка в случае питона UDF работают через два вызова между JVM и питоном — поэтому тут производительность проседает/проседала. Я не работаю с pyspark, и не слежу — вроде это пытались оптимизировать (не уверен, что в принципе возможно), но именно это место было одним из самых плохих.

[Geckelberryfinn]

В теории это так, ибо нужно как минимум сериализировать/десериализировать объекты между python и jvm. Мои тесты некоторых специфических UDF на python и scala не показывали особой разницы в производительности (databricks v10). В функцию передавался Map[String, Array[String]]. Но такие случаи вполне могут быть. Опять же, лучше протестировать. Можно комбинировать код на Питоне и UDF на scala в одном ноутбуке. Очень удобно.

[sshikov]

Ну, я исходил из того, что переписывать на скалу вот так сразу — непонятно ради чего, если уже написано на pandas, и хочется просто оценить производительность? Когда с нуля пишешь — ну я выберу скалу, не вижу у питона преимуществ, во всяком случае если ML не задействовано. Но если кому на питоне комфортнее — почему нет?