Mecanismo de execução nativo para engenharia de dados de malha

O mecanismo de execução nativo é um aprimoramento inovador para execuções de trabalho do Apache Spark no Microsoft Fabric. Esse mecanismo vetorizado otimiza o desempenho e a eficiência de suas consultas Spark, executando-as diretamente em sua infraestrutura lakehouse. A integração perfeita do mecanismo significa que ele não requer modificações de código e evita a dependência do fornecedor. Ele suporta APIs do Apache Spark e é compatível com o Runtime 1.3 (Apache Spark 3.5), e funciona com os formatos Parquet e Delta. Independentemente da localização dos seus dados no OneLake, ou se você acessar os dados por meio de atalhos, o mecanismo de execução nativo maximiza a eficiência e o desempenho.

O mecanismo de execução nativo eleva significativamente o desempenho da consulta enquanto minimiza os custos operacionais. Ele oferece um notável aprimoramento de velocidade, alcançando um desempenho até quatro vezes mais rápido em comparação com o OSS (software de código aberto) tradicional Spark, conforme validado pelo benchmark TPC-DS de 1 TB. O mecanismo é hábil em gerenciar uma ampla gama de cenários de processamento de dados, desde ingestão de dados de rotina, trabalhos em lote e tarefas ETL (extrair, transformar, carregar), até análises complexas de ciência de dados e consultas interativas responsivas. Os usuários se beneficiam de tempos de processamento acelerados, maior taxa de transferência e utilização otimizada de recursos.

O Native Execution Engine é baseado em dois componentes OSS principais: Velox, uma biblioteca de aceleração de banco de dados C++ introduzida pela Meta, e Apache Gluten (incubação), uma camada intermediária responsável por descarregar a execução de mecanismos SQL baseados em JVM para mecanismos nativos introduzidos pela Intel.

Quando usar o mecanismo de execução nativo

O mecanismo de execução nativo oferece uma solução para executar consultas em conjuntos de dados de grande escala; ele otimiza o desempenho usando os recursos nativos das fontes de dados subjacentes e minimizando a sobrecarga normalmente associada à movimentação e serialização de dados em ambientes Spark tradicionais. O mecanismo suporta vários operadores e tipos de dados, incluindo agregação hash com rollup, junção de ciclo aninhado de transmissão (BNLJ) e formatos precisos de timestamp. No entanto, para se beneficiar totalmente dos recursos do mecanismo, você deve considerar seus casos de uso ideais:

• O mecanismo é eficaz ao trabalhar com dados nos formatos Parquet e Delta, que pode processar de forma nativa e eficiente.
• As consultas que envolvem transformações e agregações complexas se beneficiam significativamente dos recursos de processamento colunar e vetorização do mecanismo.
• O aprimoramento do desempenho é mais notável em cenários em que as consultas não acionam o mecanismo de fallback, evitando recursos ou expressões sem suporte.
• O mecanismo é adequado para consultas que são computacionalmente intensivas, em vez de simples ou ligadas a E/S.

Para obter informações sobre os operadores e funções suportados pelo mecanismo de execução nativo, consulte a documentação do Apache Gluten.

Habilite o mecanismo de execução nativo

Para usar todos os recursos do mecanismo de execução nativo durante a fase de visualização, configurações específicas são necessárias. Os procedimentos a seguir mostram como ativar esse recurso para blocos de anotações, definições de trabalho do Spark e ambientes inteiros.

Habilitar no nível do ambiente

Para garantir um aprimoramento uniforme do desempenho, habilite o mecanismo de execução nativo em todos os trabalhos e blocos de anotações associados ao seu ambiente:

1. Navegue até ao espaço de trabalho que contém o seu ambiente e selecione o ambiente. Se você não tiver um ambiente criado, consulte Criar, configurar e usar um ambiente no Fabric.

2. Em Computação de faísca , selecione Aceleração.

3. Marque a caixa Ativar mecanismo de execução nativo.

4. Salve e publique as alterações.

   

Quando habilitado no nível do ambiente, todos os trabalhos e blocos de anotações subsequentes herdam a configuração. Essa herança garante que quaisquer novas sessões ou recursos criados no ambiente se beneficiem automaticamente dos recursos de execução aprimorados.

Habilitar para uma definição de trabalho do bloco de anotações ou do Spark

Você também pode habilitar o mecanismo de execução nativo para um único bloco de anotações ou definição de trabalho do Spark, você deve incorporar as configurações necessárias no início do script de execução:

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
   } 
} 

Para cadernos, insira os comandos de configuração necessários na primeira célula. Para definições de trabalho do Spark, inclua as configurações na linha de frente da definição de trabalho do Spark. O Native Execution Engine é integrado com pools ao vivo, portanto, uma vez que você habilite o recurso, ele entra em vigor imediatamente sem exigir que você inicie uma nova sessão.

Controle ao nível da consulta

Os mecanismos para habilitar o Native Execution Engine nos níveis de locatário, espaço de trabalho e ambiente, perfeitamente integrados à interface do usuário, estão em desenvolvimento ativo. Enquanto isso, você pode desativar o mecanismo de execução nativo para consultas específicas, especialmente se elas envolverem operadores que não são suportados no momento (consulte limitações). Para desativar, defina a configuração do Spark spark.native.enabled como false para a célula específica que contém sua consulta.

%%sql 
SET spark.native.enabled=FALSE; 

%%pyspark
spark.conf.set('spark.native.enabled', 'false')   

%%spark  
spark.conf.set("spark.native.enabled", "false")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "false")

Depois de executar a consulta na qual o mecanismo de execução nativo está desativado, você deve reativá-lo para as células subsequentes definindo spark.native.enabled como true. Esta etapa é necessária porque o Spark executa células de código sequencialmente.

%%sql 
SET spark.native.enabled=TRUE; 

%%pyspark
spark.conf.set('spark.native.enabled', 'true')   

%%spark  
spark.conf.set("spark.native.enabled", "true")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "true")

Identificar as operações executadas pelo motor

Há vários métodos para determinar se um operador em seu trabalho do Apache Spark foi processado usando o mecanismo de execução nativo.

Interface do usuário do Spark e servidor de histórico do Spark

Acesse a interface do usuário do Spark ou o servidor de histórico do Spark para localizar a consulta que você precisa inspecionar. Para acessar a interface do usuário da Web do Spark, navegue até a definição de trabalho do Spark e execute-a. Na guia Executa, selecione o ... ao lado de Nome do aplicativo e selecione Abrir interface do utilizador da Web do Spark. Você também pode aceder à UI do Spark no separador Monitor no espaço de trabalho. Selecione o notebook ou pipeline, na página de monitorização, há um link direto para o Spark UI para trabalhos ativos.

No plano de consulta exibido na interface do utilizador do Spark, procure os nomes dos nós que terminam com o sufixo Transformer, *NativeFileScan ou VeloxColumnarToRowExec. O sufixo indica que o mecanismo de execução nativo executou a operação. Por exemplo, os nós podem ser rotulados como RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer ou BroadcastNestedLoopJoinExecTransformer.

Explicação de DataFrame

Como alternativa, você pode executar o df.explain() comando em seu bloco de anotações para exibir o plano de execução. Na saída, procure os mesmos sufixos Transformer, *NativeFileScan ou VeloxColumnarToRowExec. Esse método fornece uma maneira rápida de confirmar se operações específicas estão sendo manipuladas pelo mecanismo de execução nativo.

Mecanismo de contingência

Em alguns casos, o mecanismo de execução nativo pode não ser capaz de executar uma consulta devido a razões como recursos sem suporte. Nestes casos, a operação recai sobre o motor Spark tradicional. Esse mecanismo de fallback automático garante que não haja interrupção no seu fluxo de trabalho.

Monitorar consultas e DataFrames executados pelo mecanismo

Para entender melhor como o mecanismo de execução nativa é aplicado a consultas SQL e operações DataFrame, e para detalhar os níveis de estágio e operador, você pode consultar a interface do usuário do Spark e o Spark History Server para obter informações mais detalhadas sobre a execução do mecanismo nativo.

Guia Mecanismo de Execução Nativa

Você pode navegar até a nova guia 'Gluten SQL / DataFrame' para visualizar as informações de compilação do Gluten e os detalhes de execução da consulta. A tabela Consultas fornece informações sobre o número de nós em execução no mecanismo nativo e aqueles que retornam à JVM para cada consulta.

Gráfico de execução de consulta

Você também pode selecionar na descrição da consulta para a visualização do plano de execução de consulta do Apache Spark. O gráfico de execução fornece detalhes de execução nativos em todos os estágios e suas respetivas operações. As cores de plano de fundo diferenciam os mecanismos de execução: o verde representa o Mecanismo de Execução Nativo, enquanto o azul claro indica que a operação está sendo executada no Mecanismo JVM padrão.

Limitações

Embora o NEE (Native Execution Engine) no Microsoft Fabric aumente significativamente o desempenho para trabalhos do Apache Spark, ele atualmente tem as seguintes limitações:

Limitações existentes

• Funcionalidades incompatíveis do Spark: o mecanismo de execução nativo atualmente não suporta funções definidas pelo usuário (UDFs), a função array_contains, ou streaming estruturado. Se essas funções ou recursos sem suporte forem usados diretamente ou por meio de bibliotecas importadas, o Spark retornará ao mecanismo padrão.

• Formatos de arquivo não suportados: consultas em formatos com JSON, XML e CSV não são aceleradas pelo mecanismo de execução nativo. Estes reverterão para o mecanismo regular da JVM do Spark para execução.

• Modo ANSI não suportado: O mecanismo de execução nativo não suporta o modo ANSI SQL. Caso esteja ativado, a execução recai no mecanismo Vanilla Spark.

• Incompatibilidades de tipo no filtro de datas: Para tirar proveito da aceleração do mecanismo de execução nativo, assegure-se de que os tipos de dados de ambos os lados de uma comparação de datas sejam compatíveis. Por exemplo, em vez de comparar uma DATETIME coluna com um literal de cadeia de caracteres, lance-a explicitamente como mostrado:

  CAST(order_date AS DATE) = '2024-05-20'
  

Outras considerações e limitações

• Incompatibilidade de conversão de decimal para flutuante: ao converter de DECIMAL para FLOAT, o Spark preserva a precisão ao converter para uma cadeia de caracteres e analisá-la. NEE (via Velox) executa uma conversão direta da representação interna int128_t, o que pode resultar em discrepâncias de arredondamento.

• Erros de configuração de fuso horário : definir um fuso horário não reconhecido no Spark faz com que o trabalho falhe no NEE, enquanto o Spark JVM o lida normalmente. Por exemplo:

  "spark.sql.session.timeZone": "-08:00"  // May cause failure under NEE
  

• Comportamento de arredondamento inconsistente: A função comporta-se de forma diferente no NEE devido à dependência de round(), o que não replica a lógica de arredondamento do Spark. Isso pode levar a inconsistências numéricas nos resultados de arredondamento.

• Ausência de verificação de chave duplicada na função map(): Quando spark.sql.mapKeyDedupPolicy está definido como EXCEPTION, o Spark gera um erro para chaves duplicadas. NEE atualmente ignora essa verificação e permite que a consulta seja bem-sucedida incorretamente.
  Exemplo:

  SELECT map(1, 'a', 1, 'b'); -- Should fail, but returns {1: 'b'}
  

• Variação da ordem com collect_list() a classificação: Ao usar DISTRIBUTE BY e SORT BY, o Spark preserva a ordem dos elementos em collect_list(). NEE pode retornar valores numa ordem diferente devido a diferenças de ordenação aleatória, o que pode resultar em expectativas incompatíveis para a lógica sensível à ordem.

• Incompatibilidade de tipo intermediário para collect_list() / collect_set(): Spark usa BINARY como o tipo intermediário para essas agregações, enquanto NEE usa ARRAY. Essa incompatibilidade pode levar a problemas de compatibilidade durante o planejamento ou a execução da consulta.

Conteúdos relacionados

• Ambientes de execução do Apache Spark no Fabric
• O que é o autotune para configurações do Apache Spark no Fabric?