Mecanismo de execução nativa para Engenharia de Dados do Fabric

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 do Spark, executando-as diretamente em sua infraestrutura de lakehouse. A integração perfeita do mecanismo significa que ele não requer modificações de código e evita a dependência de fornecedor. Ele dá suporte a APIs do Apache Spark e é compatível com o Runtime 1.3 (Apache Spark 3.5) e o Runtime 2.0 (Apache Spark 4.1) e funciona com formatos Parquet, Delta e CSV. 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 e, ao mesmo tempo, minimiza os custos operacionais. Os resultados reais variam de acordo com as características e a configuração da carga de trabalho. O mecanismo é hábil em gerenciar uma ampla gama de cenários de processamento de dados, que vão desde a ingestão de dados de rotina, trabalhos em lote e tarefas de 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, taxa de transferência aumentada 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 pelo 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.

Os operadores com suporte são transferidos do Spark baseado em JVM para um caminho de execução C++ vetorizado, fornecendo processamento colunar, com aceleração SIMD e suporte nativo para formatos Parquet e Delta. O mecanismo nativo preserva as principais otimizações de consulta do Fabric Spark, incluindo AQE (execução de consulta adaptável), regravações baseadas em custo, podas de coluna e pushdown de predicado, de modo que esses comportamentos de otimizador permaneçam totalmente ativos quando os operadores são descarregados. O mecanismo também dá suporte ao carregamento de instantâneos Delta paralelos e acelera operações que se beneficiam da ordenação em Z e do *Liquid Clustering* em tabelas Delta, fornecendo mais ganhos de desempenho para layouts de dados organizados.

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 tradicionais do Spark. O mecanismo oferece suporte a vários operadores e tipos de dados, incluindo agregação hash de rollup, junção de laço aninhado de broadcast (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 ser processado 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 de 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 vinculadas 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.

Habilitar 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 notebooks, 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 notebooks associados ao seu ambiente:

1. Navegue até o espaço de trabalho que contém 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 do Spark, selecioneAceleração.

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

4. Salve e publique as alterações.

   

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

Habilitar para um notebook ou configuração de trabalho do Spark

Você também pode habilitar o mecanismo de execução nativo para um único notebook 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 notebooks, 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 mecanismo de execução nativo é integrado a pools dinâmicos, portanto, depois de habilitar o recurso, ele entra em vigor imediatamente sem exigir que você inicie uma nova sessão.

Controle no nível de consulta

Os mecanismos para habilitar o Mecanismo de Execução Nativo nos níveis de locatário, espaço de trabalho e ambiente, perfeitamente integrados à interface do usuário, estão em desenvolvimento ativo. Você pode desabilitar o mecanismo de execução nativo para consultas específicas, especialmente se elas envolverem operadores sem suporte no momento (consulte limitações). Para desabilitá-lo, 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á desabilitado, você deve reativá-lo para células subsequentes definindo spark.native.enabled como true. Essa 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 operações executadas pelo mecanismo

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 web do Spark, navegue até a definição do seu trabalho do Spark e execute-a. Na guia Execuções, selecione ... ao lado do Nome do aplicativo e selecione Abrir a interface do usuário da Web do Spark. Você também pode acessar a interface do usuário do Spark na guia Monitorar no workspace. Selecione o notebook ou pipeline; na página de monitoramento, há um link direto para a Interface do usuário do Spark para trabalhos ativos.

No plano de consulta exibido na interface do usuário do Spark, procure os nomes de nó 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, nós podem ser rotulados como RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer ou BroadcastNestedLoopJoinExecTransformer. Para fontes de dados CSV, as análises nativas podem aparecer como análise de arquivo nativa ou nós transformadores na interface do usuário do Spark, semelhante aos nós de análise Parquet e Delta.

Explicação de DataFrame

Como alternativa, você pode executar o comando df.explain() em seu notebook 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.

Alertas do Fabric Spark Advisor

O Assistente do Spark do Fabric fornece visibilidade de fallback em tempo real durante a execução da célula do notebook. Quando um operador ou segmento de plano volta ao Spark baseado em JVM em vez do caminho nativo, o Assistente exibe um alerta diretamente na saída da célula do notebook, ajudando você a identificar rapidamente operadores ou configurações sem suporte sem sair do notebook. Você pode usar esses alertas para diagnosticar quando o descarregamento nativo não é aplicado e decidir se deseja ajustar sua consulta ou configuração.

Mecanismo de recuperação

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

Monitorar consultas e DataFrames executados pelo mecanismo

Para entender melhor como o mecanismo de execução nativo é aplicado a consultas SQL e operações DataFrame e para analisar detalhadamente os níveis de estágio e operador, você pode consulta a interface do usuário do Spark e o servidor de histórico do Spark para obter informações mais detalhadas sobre a execução do mecanismo nativo.

Aba Motor de Execução Nativa

Você pode navegar para a nova guia “Gluten SQL / DataFrame” para exibir as informações de build do Gluten e os detalhes de execução da consulta. A tabela Consultas fornece insights sobre o número de nós em execução no mecanismo nativo e aqueles que voltam para a JVM para cada consulta.

Grafo 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 grafo de execução fornece detalhes de execução nativos entre estágios e suas respectivas operações. As cores da tela de fundo diferenciam os mecanismo de execução: verde representa o mecanismo de execução nativo, enquanto azul-claro indica que a operação está sendo executada no mecanismo JVM padrão.

Limitações

Embora o motor de execução nativo (NEE) no Fabric aumente significativamente o desempenho para trabalhos do Apache Spark, atualmente ele apresenta as seguintes limitações. Vários itens relacionados à correção que se aplicavam ao Runtime 1.3 (Apache Spark 3.5) foram resolvidos no Runtime 2.0 (Apache Spark 4.1); Cada item registra o tempo de execução ao qual se aplica.

Limitações existentes

• Recursos incompatíveis do Spark (todos os runtimes): O motor de execução nativo atualmente não suporta streaming estruturado. Se você usar recursos não suportados, seja diretamente ou por meio de bibliotecas importadas, o Spark volta ao seu motor padrão. O motor de execução nativo agora suporta UDFs em Python, UDFs Scala e tipos de dados complexos (arrays, maps, structs). Para obter mais informações, consulte Python UDFs, Scala UDFs e tipos de dados complexos no mecanismo de execução nativo.

• Formatos de arquivo não suportados (todos os tempos de execução): O motor de execução nativo não acelera consultas contra JSON e XML formata. Esses formatos retornam ao motor JVM Spark regular para execução. O parser CSV vetorizado agora suporta CSV.

• Modo ANSI (apenas Runtime 1.3): No Runtime 1.3 (Apache Spark 3.5), o motor de execução nativo não suporta o modo SQL ANSI. Se você ativar o modo ANSI SQL, a execução volta para o motor Spark padrão. No Runtime 2.0 (Apache Spark 4.1), o modo SQL ANSI é suportado: operadores descarregam para o motor nativo e a semântica de erro ANSI (por exemplo, divisão por zero e casts inválidos) é aplicada de forma consistente com o JVM Spark.

• Incompatibilidades de tipos de filtro de data (todos os tempos de execução): Para se beneficiar da aceleração do motor de execução nativo, certifique-se de que ambos os lados da comparação de data coincidam no tipo de dado. Por exemplo, em vez de comparar uma DATETIME coluna com um literal de cadeia de caracteres, converta-a explicitamente conforme mostrado:

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

Outras considerações e limitações

• Incompatibilidade de casting entre Decimal e Float (Runtime 1.3; resolvido em Runtime 2.0): Ao lançar de DECIMAL para FLOAT, o Spark preserva a precisão ao converter para uma string e analisá-la. No Runtime 1.3, o NEE (via Velox) realiza um cast direto a partir da representação interna int128_t , o que pode resultar em discrepâncias de arredondamento.

• Erros de configuração de fuso horário (Runtime 1.3; resolvidos em Runtime 2.0): No Runtime 1.3, definir um fuso horário não reconhecido no Spark faz o trabalho falhar sob NEE, enquanto a JVM do Spark lida com isso de forma eficiente. Por exemplo:

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

• Comportamento de arredondamento inconsistente (Runtime 1.3; resolvido em Runtime 2.0): No Runtime 1.3, a round() função se comporta de forma diferente no NEE devido à dependência de std::round, que não replica a lógica de arredondamento do Spark. Essa diferença pode levar a inconsistências numéricas nos resultados de arredondamento.

• Função de verificação map() de teclas duplicadas ausente (Runtime 1.3; resolvido em Runtime 2.0): Quando spark.sql.mapKeyDedupPolicy está definido como EXCEÇÃO, o Spark gera um erro para chaves duplicadas. No Runtime 1.3, o NEE pula essa verificação e permite que a consulta tenha sucesso incorreto. No Runtime 2.0, o NEE aumenta DUPLICATED_MAP_KEY consistentemente com o JVM Spark.
  Exemplo:

  SELECT map(1, 'a', 1, 'b'); -- Should fail with duplicate keys
  

• Variância de ordem em collect_list() com ordenação (Runtime 1.3; resolvida em Runtime 2.0): Ao usar DISTRIBUTE BY e SORT BY, o Spark preserva a ordem dos elementos em collect_list(). No Runtime 1.3, o NEE pode devolver valores em uma ordem diferente devido a diferenças de embaralhamento, o que pode resultar em expectativas desalinhadas para lógica sensível à ordenação.

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

• Endpoints privados gerenciados necessários para acesso ao armazenamento (todos os tempos de execução): Quando o Native Execution Engine (NEE) está ativado, e se jobs da Spark estiverem tentando acessar uma conta de armazenamento usando um endpoint privado gerenciado gerenciado, você deve configurar endpoints privados gerenciados separados para os endpoints Blob (blob.core.windows.net) e DFS / File System (dfs.core.windows.net), mesmo que apontem para a mesma conta de armazenamento. Você não pode reutilizar um único endpoint para ambos. Essa limitação pode exigir configuração adicional de rede ao ativar um motor de execução nativo em um espaço de trabalho que tenha endpoints privados gerenciados para contas de armazenamento.

Conteúdo relacionado

• Visão geral do Delta Lake em Fabric
• Python UDFs, UDFs do Scala e tipos de dados complexos no mecanismo de execução nativo
• Redução de escala eficiente e gerenciador de embaralhamento remoto
• Ambientes de execução do Apache Spark no Azure Fabric
• O que é o Autotune para configurações do Apache Spark no Fabric?