Uma função definida pelo utilizador executada na CPU pode interromper uma consulta Apache Spark que, de resto, é acelerada pela GPU. Em geral, o plugin cuDF não consegue traduzir código UDF arbitrário: converte dados colunares em linhas, executa a função na CPU e converte novamente o resultado. O guia da NVIDIA de 13 de outubro descreve competências de agente para reescrever uma UDF como Spark SQL, uma opção colunar RapidsUDF ou uma RapidsUDF suportada por CUDA. A pergunta útil para um engenheiro de dados é se uma reescrita produz as mesmas respostas, permanece na GPU no plano relevante e melhora o trabalho real.

Este guia baseia-se em documentação. A BIG CHANGE não executou as competências, não testou uma UDF nem mediu uma carga de trabalho do Spark.

A grande mudança

  • O que mudou: A NVIDIA publicou um fluxo de trabalho faseado de agente para gerar testes de UDF, converter uma função, avaliar a conversão, comparar versões de CPU e GPU e, opcionalmente, otimizar uma implementação cuDF.
  • A quem ajuda: Engenheiros com uma pipeline Spark RAPIDS/cuDF compatível com GPU e uma UDF de CPU específica que a interrompe.
  • O que verificar: Resultados coincidentes em casos-limite representativos, um plano de execução sem o fallback de CPU visado e desempenho repetível ao nível do trabalho no hardware previsto.

Antes de começar

Escolha uma UDF que esteja autorizado a partilhar com o agente de programação. Não inclua credenciais, linhas de entrada sensíveis nem conjuntos de dados proprietários no pedido, salvo se o agente e o respetivo ambiente estiverem aprovados para os processar. Forneça o código-fonte da UDF, o ponto de registo e chamada, os esquemas relevantes, o comportamento esperado para valores nulos e erros e um pequeno conjunto de testes autorizado. Registe o plano e o tempo do trabalho Spark atual como referência para comparação.

O README das competências é o ponto de partida versionado do fluxo de trabalho. Exige Maven e um JDK para compilar UDF, além de uma pilha Spark/RAPIDS/cuDF/CUDA compatível e uma GPU. Antes de instalar seja o que for, consulte o guia atual de compatibilidade do plugin para a sua distribuição Spark, versão Scala, controlador, compilação CUDA e GPU. Uma GPU na cloud é uma alternativa ao hardware local, mas o fornecedor cobra o tempo da instância e o armazenamento. A utilização do agente/modelo também pode ter custos. O README fornece um esqueleto de projeto e exemplos, mas não comprova a compatibilidade nem o desempenho no seu cluster.

Reescreva e verifique uma função

  1. Fixe primeiro o comportamento original. Peça ao agente que utilize udf-gen-test na UDF selecionada e inspecione pessoalmente os testes gerados. Acrescente casos reais do contrato: valores nulos, cadeias ou coleções vazias, entradas malformadas, valores-limite, precisão numérica, ordenação e comportamento perante erros, conforme aplicável. Execute a UDF original com esses casos. O resultado esperado é uma suite de testes de base aprovada, não uma reescrita ainda. O exemplo de uma função de temperatura da NVIDIA devolve explicitamente null para uma entrada null; a reescrita em SQL só é útil se esse comportamento também se mantiver com os seus tipos de dados e definições do Spark.
  2. Escolha o alvo suportado mais simples. Se a lógica puder ser expressa em Spark SQL ou expressões DataFrame, peça udf-convert-to-sql. Isto expõe a expressão ao planeador do Spark e pode permitir que o plugin substitua operações suportadas por equivalentes na GPU. Se o SQL não conseguir exprimir claramente a lógica necessária, peça udf-convert-to-cudf: o respetivo RapidsUDF.evaluateColumnar recebe vetores de colunas da GPU e compõe operações cuDF. Reserve udf-convert-to-cuda para lógica que necessite de um kernel personalizado através de JNI e cujo esforço adicional de implementação e manutenção se justifique. São opções a avaliar, não uma garantia de que todas as operações serão executadas na GPU.
  3. Reveja a conversão antes de a aceitar. Compare a implementação reescrita com a original e execute ambas nos mesmos casos de teste aprovados. O repositório também indica udf-judge-conversion para uma revisão separada de lacunas nos testes e erros de conversão. Verifique tipos, propagação de null, arredondamento, exceções, ordenação e gestão de recursos. Numa reescrita cuDF, inspecione a duração das colunas e escalares temporários; o exemplo Scala do tutorial utiliza recursos com âmbito definido e devolve a coluna resultante. Uma suite de testes gerada que passa é uma evidência útil, mas uma pessoa tem de decidir se abrange o contrato da função.
  4. Inspecione o plano executado. Execute a consulta alterada com o plugin cuDF ativado e inspecione o plano e os diagnósticos RAPIDS para o operador visado e as conversões próximas. A visão geral do plugin da NVIDIA afirma que operações SQL não suportadas recorrem à execução na CPU do Spark. Se o plano ainda mostrar a UDF ou operadores próximos na CPU, identifique a expressão ou tipo não suportado e reconsidere a escolha do alvo. Guarde os planos antes e depois com o resultado do teste. Uma classe com o nome RapidsUDF não prova, por si só, que todo o trabalho permanece na GPU.
  5. Avalie o trabalho que pretende executar. Utilize udf-benchmark para comparar as implementações original e alterada com as mesmas entradas, dimensão do cluster, configuração e método de medição. Registe o tempo decorrido do trabalho, o tamanho da entrada, a equivalência dos resultados e a utilização de recursos GPU/CPU. Repita as execuções para detetar efeitos de arranque, cache ou contenção. O resultado esperado é uma comparação reproduzível, mesmo que a reescrita perca. Se uma versão cuDF correta for lenta, o repositório disponibiliza udf-optimize-cudf para a analisar e rever; repita as verificações de correção e do plano após cada alteração.

Como é um resultado bem-sucedido

O candidato está pronto para uma revisão de código normal quando os resultados da UDF escolhida correspondem ao comportamento documentado nos casos aprovados, o plano executado já não inclui o fallback de CPU visado e um benchmark representativo mostra um resultado global vantajoso. Se alguma verificação falhar, mantenha a implementação original, limite a reescrita à expressão problemática e repita essa fase. Uma divergência semântica é mais importante do que um benchmark mais rápido; se o plano não mudar, o percurso pretendido na GPU não foi demonstrado.

A NVIDIA relata um exemplo de produção em que uma UDF com cuDF reduziu o tempo de um operador de 274,55 para 12,78 horas numa carga de trabalho com 600 mil milhões de linhas. São tempos de operador comunicados pelo fornecedor para essa carga, não uma previsão para outra UDF nem o resultado global de um trabalho. A alegação mais ampla de 22 vezes deve ser lida nesse contexto. A capacidade da GPU, a movimentação de dados, as operações não suportadas, a revisão de código e os custos da cloud podem alterar o resultado da sua pipeline.

Fontes e leituras adicionais

  • NVIDIA Technical Blog, 13 de outubro de 2026: explica o fallback para CPU, as opções SQL/cuDF/CUDA, as quatro fases do fluxo de trabalho e o único exemplo de desempenho citado pela empresa. Os valores de desempenho são comunicados pelo fornecedor.
  • Competências cuDF Spark da NVIDIA, revisão fixada do repositório: ponto de entrada versionado para o esqueleto e as competências individuais. A página fixada do GitHub não estava disponível através da nossa via de recolha; os detalhes do fluxo foram comparados com o tutorial da NVIDIA e o README de competências acessível no ramo principal do repositório.
  • Visão geral do plugin cuDF para Apache Spark: informação atual sobre configuração e compatibilidade, além da regra explícita de que operações não suportadas são executadas na CPU do Spark. Consulte a lista de compatibilidade específica da versão antes da implementação.