Comments 16
Про медленные функции на Python интересно — это баг Catalyst?
Это точно лень?
«очень легко отстрелить себе ноги по самые уши – многие конструкции могут вести себя не так, как можно было бы ожидать с позиции здравого смысла, а некоторые простые операции вызывать ненужные копирования и попытки материализации огромных датасетов в памяти.»
«очень легко отстрелить себе ноги по самые уши – многие конструкции могут вести себя не так, как можно было бы ожидать с позиции здравого смысла, а некоторые простые операции вызывать ненужные копирования и попытки материализации огромных датасетов в памяти.»
Это если начать заигрывать с лютой функциональщиной. Если держаться в рамках «понятных среднему пользователю» конструкций то все ± безопасно. В Python, кстати, ничем не лучше в этом плане — одно неловкое движение и у тебя в памяти лишняя копия данных да еще и с адским боксингом.
Да, python — не Scala, да у python есть GIL. Но мне по ответу в интервью кажется, что автор не до конца понимает, как работает интерпретатор в python и почему же все-таки большинство успешно использует Spark API в связке с python, а у него возникают проблемы, где «питоновский код превращает многотысячеядерный кластер в тыкву и начинает сжигать киловатт/часы на совершенно непродуктивную деятельность». Без более конктреных примеров подобные высказывания — это все не более, чем дилетанство
Из недавнего — считали per-user AUC, нужно было пройтись по датафрейму, сгруппировать по пользователю записи, собрать списки и скормить roc_auc из scikit (для Python) или своей реализации на Scala. В одной партиции ~1М юзеров. Scala работает за секунды, Python за минуты.
С удовольствием прочитаю статью, где будет строго спрофилированы одни и те же задачи на одном и том же железе на python и на scala :)
Попробую. Spark в режиме master=local[*] подойдет? В кластерном режиме Python еще гемора с дистрибуцией пакетов докидывает и другие задачи будут интерферировать.
Пока не статья, но воспроизвел кейс: www.zepl.com/viewer/notebooks/bm90ZTovL2RtaXRyeWJ1Z2F5Y2hlbmtvLzQ4ODM3YzlmYzMzNzRlNWRhMjdjZWIzMmVkOTk1MGFlL25vdGUuanNvbg
Пока идет процесс подсчета Python честно жжет киловаты на всех 4-х ядрах, в GIL не упирается:
В итоге — PySpark 1 минута 38 секунд, обычный Spark — 2 секунды:
«Доктор, что я делаю не так?»
UPD: Если убрать использования sklearn, то скорость сопоставима. При этом производительность sklearn самого по себе в этом аспекте на уровне.
Вывод такой — Spark умеет UDF до определнной сложности (пока не появляется дополинетльных пакетов) умеет транслировать и запускать почти без оверхеда. Но при появлении использования расширенных пакетов фолбэчится на Python.
Пока идет процесс подсчета Python честно жжет киловаты на всех 4-х ядрах, в GIL не упирается:
В итоге — PySpark 1 минута 38 секунд, обычный Spark — 2 секунды:
«Доктор, что я делаю не так?»
UPD: Если убрать использования sklearn, то скорость сопоставима. При этом производительность sklearn самого по себе в этом аспекте на уровне.
Вывод такой — Spark умеет UDF до определнной сложности (пока не появляется дополинетльных пакетов) умеет транслировать и запускать почти без оверхеда. Но при появлении использования расширенных пакетов фолбэчится на Python.
скорее дилетантство сомневаться. спарк читает данные в jvm, что бы отдать интерпретатору питона придется каждый байт прокачать через не быстрый интерфейс, распарсить, превратить в объект. глупо сомневаться что этот бесполезный труд не затормозит процесс во многие разы.
Python vs Scala в данном контексте это скорее культурный, нежели технический конфликт. Так уж сложилось, что мир JVM настолько ушел в сторону от условного мира PHP/Python/Ruby/Go, что разработчики друг друга с трудом понимают вообще. И когда в BigData рядом оказались Java/Scala и Python/R у обоих сторон вышел культурный шок.
Нет тут никакого культурного конфликта. Вот я постоянно пишу на Java, немножко на скала. Но при этом у имею примерно 10 лет опыта Python. И когда мне начинают рассказывать, как там все удобно, уж позвольте мне не верить — потому что я реально знаю, что как язык, к примеру, тот же groovy (а сегодня котлин) ни в чем питону не уступают, а во многом его и превосходят. И они мне все при использовании спарка доступны. И тот же юпитер (или Zeppelin) поддерживают по большому счету что скалу, что питон одинаково. Разница есть, ясное дело, как не быть — но она по большому счету в библиотеках.
Ну или посмотрите на недавнюю статью про то, как все клево можно делать в пандас. При этом речь идет о примерно 15Gb наборе данных. Откуда у меня должен быть культурный шок, если мои задачи на работе выглядят примерно как «обработать вон тот 30Tb набор за час, и не выжрать при этом больше 1000 ядер»?
Ну или посмотрите на недавнюю статью про то, как все клево можно делать в пандас. При этом речь идет о примерно 15Gb наборе данных. Откуда у меня должен быть культурный шок, если мои задачи на работе выглядят примерно как «обработать вон тот 30Tb набор за час, и не выжрать при этом больше 1000 ядер»?
Так еще относительно недавно это был технический аспект, ибо поддержка Питона там была такая, что только обнять и плакать.
Sign up to leave a comment.
«Не вижу ни одного резона использовать Python для работы со Spark, кроме лени»