Пользовательская функция на CPU может прервать запрос Apache Spark, который в остальном ускоряется GPU. Плагин cuDF обычно не умеет преобразовывать произвольный код UDF: он превращает столбцовые данные в строки, выполняет функцию на CPU, а затем преобразует результат обратно. Руководство NVIDIA от 13 октября описывает навыки агента для переписывания UDF на Spark SQL, в столбцовый RapidsUDF или в RapidsUDF с поддержкой CUDA. Главный вопрос для инженера данных: дает ли переписывание те же ответы, остается ли на GPU в нужном плане и улучшает ли реальную задачу.

Это руководство основано на документации. BIG CHANGE не запускала эти навыки, не тестировала UDF и не измеряла нагрузку Spark.

Главное изменение

  • Что изменилось: NVIDIA опубликовала поэтапный рабочий процесс агента: создание тестов UDF, преобразование функции, оценка преобразования, сравнение версий для CPU и GPU и, при желании, оптимизация реализации на cuDF.
  • Кому это поможет: Инженерам с конвейером Spark RAPIDS/cuDF, поддерживающим GPU, и конкретной CPU UDF, которая его прерывает.
  • Что проверить: Совпадение результатов на репрезентативных граничных случаях, отсутствие целевого перехода на CPU в плане выполнения и воспроизводимую производительность задачи на предполагаемом оборудовании.

Перед началом

Выберите UDF, которой вы вправе поделиться с агентом для программирования. Не включайте в запрос учетные данные, чувствительные входные строки или закрытые наборы данных, если агент и его среда не одобрены для работы с ними. Предоставьте исходный код UDF, место ее регистрации и вызова, соответствующие схемы, ожидаемое поведение для null и ошибок, а также небольшой разрешенный тестовый набор. Зафиксируйте план и время выполнения текущей задачи Spark как базу для сравнения.

Этот README навыков — версионированная отправная точка рабочего процесса. Для сборки UDF нужны Maven и JDK, а также совместимый стек Spark/RAPIDS/cuDF/CUDA и GPU. До установки проверьте актуальное руководство по совместимости плагина с вашей дистрибуцией Spark, версией Scala, драйвером, сборкой CUDA и GPU. Облачный GPU — альтернатива локальному оборудованию, но провайдер тарифицирует время экземпляра и хранилище. Использование агента/модели тоже может стоить денег. README содержит каркас проекта и примеры, но не доказывает совместимость или производительность вашего кластера.

Перепишите и проверьте одну функцию

  1. Сначала зафиксируйте исходное поведение. Попросите агента использовать udf-gen-test для выбранной UDF и сами изучите созданные тесты. Добавьте реальные случаи из контракта: при необходимости null, пустые строки или коллекции, некорректные входные данные, граничные значения, числовую точность, порядок и поведение при ошибках. Запустите на них исходную UDF. Ожидаемый результат — успешно пройденный базовый набор тестов, а не уже переписанная функция. Пример температурной функции NVIDIA явно возвращает null при null-входе; вариант на SQL полезен лишь в том случае, если это поведение сохраняется с вашими типами данных и настройками Spark.
  2. Выберите наиболее простой поддерживаемый вариант. Если логику можно выразить через Spark SQL или выражения DataFrame, запросите udf-convert-to-sql. Так выражение становится доступно планировщику Spark, и плагин может заменить поддерживаемые операции эквивалентами для GPU. Если нужную логику трудно выразить на SQL, запросите udf-convert-to-cudf: его RapidsUDF.evaluateColumnar получает векторы столбцов GPU и комбинирует операции cuDF. Используйте udf-convert-to-cuda только для логики, которой требуется собственное ядро через JNI и для которой оправданы дополнительные затраты на разработку и сопровождение. Это варианты для оценки, а не обещание, что каждая операция будет выполняться на GPU.
  3. Проверьте преобразование до принятия. Сравните переписанную реализацию с исходной и запустите обе на одних и тех же одобренных тестовых случаях. В репозитории также указан udf-judge-conversion для отдельной проверки пробелов в тестах и ошибок преобразования. Проверьте типы, распространение null, округление, исключения, порядок и управление ресурсами. Для варианта на cuDF проверьте срок жизни временных столбцов и скаляров; пример Scala из руководства использует ресурсы с ограниченной областью действия и возвращает столбец результата. Успешный запуск сгенерированного набора тестов — полезное свидетельство, но человек должен решить, покрывает ли он контракт функции.
  4. Проверьте выполненный план. Запустите измененный запрос с включенным плагином cuDF и изучите план и диагностику RAPIDS для целевого оператора и соседних преобразований. В обзоре плагина NVIDIA говорится, что неподдерживаемые операции SQL переходят на выполнение Spark на CPU. Если в плане UDF или соседние операторы все еще выполняются на CPU, найдите неподдерживаемое выражение или тип и пересмотрите выбор цели. Сохраните планы до и после вместе с результатом теста. Один лишь класс с названием RapidsUDF не доказывает, что вся задача остается на GPU.
  5. Проверьте на задаче, которую собираетесь запускать. Используйте udf-benchmark для сравнения исходной и измененной реализаций при одинаковых входных данных, размере кластера, конфигурации и методе измерения. Зафиксируйте длительность задачи, размер входных данных, эквивалентность результатов и использование ресурсов GPU/CPU. Повторите запуски, чтобы выявить эффекты старта, кэша или конкуренции. Ожидается воспроизводимое сравнение, даже если переписанная версия проиграет. Если правильная версия на cuDF работает медленно, репозиторий предлагает udf-optimize-cudf для профилирования и доработки; после каждого изменения повторяйте проверки корректности и плана.

Как выглядит успешный результат

Кандидат готов к обычной проверке кода, если выходные данные выбранной UDF соответствуют описанному поведению в одобренных случаях, выполненный план больше не содержит целевого перехода на CPU, а репрезентативный бенчмарк показывает значимый результат на всем пути. При любой неудачной проверке оставьте исходную реализацию, ограничьте переписывание проблемным выражением и повторите этот этап. Семантическое несовпадение важнее более быстрого бенчмарка; неизменившийся план означает, что предполагаемый путь через GPU не подтвержден.

NVIDIA сообщает об одном производственном примере: UDF с cuDF сократила время оператора с 274,55 до 12,78 часа на нагрузке в 600 миллиардов строк. Это заявленное поставщиком время оператора для той нагрузки, а не прогноз для другой UDF и не результат сквозного выполнения задачи. Более широкое заявление об ускорении в 22 раза следует рассматривать в этом контексте. Результат вашего конвейера могут изменить емкость GPU, перемещение данных, неподдерживаемые операции, проверка кода и расходы на облако.

Источники и дополнительное чтение

  • NVIDIA Technical Blog, 13 октября 2026 года: объясняет переход на CPU, выбор между SQL/cuDF/CUDA, четыре этапа рабочего процесса и единственный приведенный компанией пример производительности. Показатели производительности сообщены поставщиком.
  • Навыки NVIDIA cuDF Spark, закрепленная ревизия репозитория: версионированная отправная точка для каркаса и отдельных навыков. Закрепленная страница GitHub была недоступна через наш способ получения; детали процесса сверены с руководством NVIDIA и доступным README навыков в основной ветке репозитория.
  • Обзор плагина cuDF для Apache Spark: актуальные сведения об установке и совместимости, а также прямое указание, что неподдерживаемые операции выполняются на CPU Spark. Перед внедрением проверьте список совместимости для конкретного выпуска.