Ошибка бросания Pyspark: py4j.Py4JException: метод __getstate __ ([]) не существует [дубликат]

Связь с использованием шлюза Py4J по умолчанию просто невозможна. Чтобы понять, почему мы должны взглянуть на следующую диаграмму из документа PySpark Internals [1]:

Поскольку шлюз Py4J работает на драйвере он не доступен интерпретаторам Python, которые взаимодействуют с рабочими JVM через сокеты (см., например, PythonRDD / rdd.py ).

Теоретически было бы возможно создать отдельный Py4J-шлюз для каждого рабочего, но на практике это вряд ли будет полезно. Игнорирование таких проблем, как надежность Py4J, просто не предназначено для выполнения задач, требующих большой объем данных.

Есть ли какие-либо обходные пути?

1. Использование API источников данных Spark SQL для обертки JVM-кода. Плюсы: поддерживаемый, высокий уровень, не требует доступа к внутреннему API PySpark. Отношения: относительно подробные и не очень хорошо документированные, ограниченные в основном входными данными
2. Работа с DataFrames с использованием Scala UDF. Плюсы: легко реализовать (см. Искра: как сопоставить Python с определенными функциями Scala или Java? ), без преобразования данных между Python и Scala, если данные уже хранятся в DataFrame, минимальный доступ к Py4J Минусы: Требуется доступ к шлюзу Py4J и внутренним методам, ограниченным Spark SQL, трудно отлаживать, не поддерживается
3. Создание интерфейса Scala на высоком уровне аналогичным образом, как это делается в MLlib. Плюсы: гибкая, возможность выполнения произвольного сложного кода. Это можно сделать либо прямо на RDD (см., Например, MLlib model wrappers ), либо с помощью DataFrames (см. Как использовать класс Scala внутри Pyspark ). Последнее решение выглядит гораздо более дружелюбным, поскольку все данные уже обрабатываются существующим API. Минусы: Низкий уровень, требуемое преобразование данных, то же, что и UDF, требует доступа к Py4J и внутреннему API, не поддерживается Некоторые основные примеры можно найти в Преобразование PySpark RDD с помощью Scala
4. Использование внешних инструмент управления рабочим процессом для переключения между заданиями Python и Scala / Java и передачи данных в DFS. Плюсы: Простота в реализации, минимальные изменения самого кода Минусы: стоимость чтения / записи данных ( Alluxio ?)
5. Использование общих SQLContext (см., Например, Apache Zeppelin или Livy ) для передачи данных между гостевыми языками с использованием зарегистрированных временных таблиц. Плюсы: хорошо подходит для интерактивного анализа Минусы: не столько для пакетных заданий (Цеппелин), либо может потребоваться дополнительная оркестровка (Livy)

1. Джошуа Розен. (2014, август 04) Внутренние элементы PySpark . Получено из https://cwiki.apache.org/confluence/display/SPARK/PySpark+Internals