Tempos de execução do Apache Spark na malha

O Microsoft Fabric Runtime é uma plataforma integrada ao Azure baseada no Apache Spark que permite a execução e o gerenciamento de experiências de engenharia de dados e ciência de dados. Ele combina componentes-chave de fontes internas e de código aberto, fornecendo aos clientes uma solução abrangente. Para simplificar, nos referimos ao Microsoft Fabric Runtime powered by Apache Spark como Fabric Runtime.

Principais componentes do Fabric Runtime:

• Apache Spark - uma poderosa biblioteca de computação distribuída de código aberto que permite processamento de dados em grande escala e tarefas de análise. O Apache Spark fornece uma plataforma versátil e de alto desempenho para experiências de engenharia de dados e ciência de dados.

• Delta Lake - uma camada de armazenamento de código aberto que traz transações ACID e outros recursos de confiabilidade de dados para o Apache Spark. Integrado ao Fabric Runtime, o Delta Lake aprimora os recursos de processamento de dados e garante a consistência dos dados em várias operações simultâneas.

• O Native Execution Engine - é um aprimoramento transformador para cargas de trabalho do Apache Spark, oferecendo ganhos significativos de desempenho ao executar diretamente consultas do Spark na infraestrutura lakehouse. Integrado perfeitamente, ele não requer alterações de código e evita a dependência do fornecedor, suportando os formatos Parquet e Delta nas APIs do Apache Spark no Runtime 1.3 (Spark 3.5). Esse mecanismo aumenta as velocidades de consulta até quatro vezes mais rápido do que o OSS Spark tradicional, como mostra o benchmark TPC-DS de 1 TB, reduzindo os custos operacionais e melhorando a eficiência em várias tarefas de dados, incluindo ingestão de dados, ETL, análises e consultas interativas. Baseado no Velox da Meta e no Apache Gluten da Intel, otimiza o uso de recursos enquanto lida com diversos cenários de processamento de dados.

• Pacotes de nível padrão para Java/Scala, Python e R - pacotes que suportam diversas linguagens de programação e ambientes. Esses pacotes são instalados e configurados automaticamente, permitindo que os desenvolvedores apliquem suas linguagens de programação preferidas para tarefas de processamento de dados.

• O Microsoft Fabric Runtime é construído sobre um sistema operacional de código aberto robusto, garantindo compatibilidade com várias configurações de hardware e requisitos do sistema.

Abaixo, você encontra uma comparação abrangente dos principais componentes, incluindo versões do Apache Spark, sistemas operacionais suportados, Java, Scala, Python, Delta Lake e R, para tempos de execução baseados no Apache Spark dentro da plataforma Microsoft Fabric.

Visite Runtime 1.2, Runtime 1.3 ou Runtime 2.0 para explorar detalhes, novas funcionalidades, melhorias e cenários de migração para a versão específica do runtime.

Otimizações de malha

No Microsoft Fabric, tanto o mecanismo Spark quanto as implementações Delta Lake incorporam otimizações e recursos específicos da plataforma. Esses recursos são projetados para usar integrações nativas dentro da plataforma. É importante notar que todos esses recursos podem ser desativados para alcançar a funcionalidade padrão do Spark e Delta Lake. Os tempos de execução do Fabric para Apache Spark abrangem:

• A versão open-source completa do Apache Spark.
• Uma coleção de quase 100 aprimoramentos de desempenho de consulta distintos e integrados. Esses aprimoramentos incluem recursos como cache de partição (habilitando o cache de partição do Sistema de Arquivos para reduzir chamadas de metastore) e Cross Join para a projeção de subconsulta escalar.
• Cache inteligente incorporado.

Dentro do Fabric Runtime para Apache Spark e Delta Lake, existem capacidades de escrita nativas que servem a dois propósitos principais:

• Eles oferecem desempenho diferenciado para cargas de trabalho de escrita, otimizando o processo de escrita.
• Eles configuram por padrão a otimização V-Order dos ficheiros Delta Parquet. A otimização Delta Lake V-Order é crucial para garantir um desempenho de leitura superior em todos os motores Fabric. Para obter uma compreensão mais profunda de como ele opera e como gerenciá-lo, consulte o artigo dedicado sobre otimização de tabelas Delta Lake e V-Order.

Suporte a vários tempos de execução

O Fabric suporta vários tempos de execução, oferecendo aos usuários a flexibilidade de alternar perfeitamente entre eles, minimizando o risco de incompatibilidades ou interrupções.

Por defeito, todos os novos espaços de trabalho usam a versão mais recente do tempo de execução do GA, que atualmente é o Runtime 1.3.

Para alterar a versão do tempo de execução no nível do espaço de trabalho, vá para Configurações do espaço de trabalho>Configurações de Data Engineering/Science>Configurações de Spark. Na guia Ambiente, selecione a versão do ambiente de execução desejada entre as opções disponíveis. Selecione Salvar para confirmar sua seleção.

Depois de fazer essa alteração, todos os itens criados pelo sistema no espaço de trabalho, incluindo Lakehouses, SJDs e Notebooks, funcionarão usando a versão de tempo de execução no nível do espaço de trabalho recém-selecionada a partir da próxima Sessão do Spark. Se estiver a usar um notebook com uma sessão existente para um trabalho ou qualquer atividade relacionada ao Lakehouse, essa sessão do Spark continuará como está. No entanto, a partir da próxima sessão ou trabalho, a versão de tempo de execução selecionada será aplicada.

Além disso, para alterar o runtime ao Environment nível do item, crie um novo item de Ambiente ou abra um existente, no menu suspenso de Runtime , selecione a versão de runtime desejada entre as opções disponíveis, selecione Save e depois Publish as suas alterações. Em seguida, pode usar este Environment item com o seu Notebook ou Spark Job Definition.

Consequências das alterações de tempo de execução nas configurações do Spark

Em geral, nosso objetivo é migrar todas as configurações do Spark. No entanto, se identificarmos que a configuração do Spark não é compatível com o Runtime B, emitiremos uma mensagem de aviso e nos absteremos de implementar a configuração.

Consequências das alterações de tempo de execução no gerenciamento de bibliotecas

Em geral, nossa abordagem é migrar todas as bibliotecas do Runtime A para o Runtime B, incluindo Public e Custom Runtimes. Se as versões Python e R permanecerem inalteradas, as bibliotecas deverão funcionar corretamente. No entanto, para os Jars, há uma probabilidade significativa de que possam não funcionar devido a alterações nas dependências e outros fatores como alterações no Scala, Java, Spark e no sistema operativo.

O utilizador é responsável por atualizar ou substituir quaisquer bibliotecas que não funcionem com o Runtime B. Se houver um conflito, o que significa que o Runtime B inclui uma biblioteca originalmente definida no Runtime A, o nosso sistema de gestão de bibliotecas tenta criar a dependência necessária para o Runtime B com base nas definições do utilizador. No entanto, o processo de construção falha se ocorrer um conflito. No log de erros, os usuários podem ver quais bibliotecas estão causando conflitos e fazer ajustes em suas versões ou especificações.

Atualizar o protocolo Delta Lake

Os recursos do Delta Lake são sempre compatíveis com versões anteriores, garantindo que as tabelas criadas em uma versão inferior do Delta Lake possam interagir perfeitamente com versões superiores. No entanto, quando certas funcionalidades são ativadas (por exemplo, ao usar delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) o método), a compatibilidade direta com versões inferiores do Delta Lake pode ser comprometida. Nesses casos, é essencial modificar cargas de trabalho fazendo referência às tabelas atualizadas para alinhar com uma versão Delta Lake que mantenha a compatibilidade.

Cada tabela Delta está associada a uma especificação de protocolo, definindo os recursos suportados. As aplicações que interagem com a tabela, seja para leitura ou escrita, dependem desta especificação de protocolo para determinar se são compatíveis com o conjunto de funcionalidades da tabela. Se uma aplicação não tiver capacidade para lidar com uma funcionalidade listada como suportada no protocolo da tabela, não consegue ler ou escrever nessa tabela.

A especificação do protocolo divide-se em dois componentes distintos: o protocolo de "leitura" e o protocolo de "escrita". Para mais informações, visite a página "Como é que a Delta Lake gere a compatibilidade de funcionalidades?".

Os usuários podem executar o comando delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) dentro do ambiente PySpark e no Spark SQL e Scala. Este comando permite que eles iniciem uma atualização na tabela Delta.

É essencial observar que, ao executar essa atualização, os usuários recebem um aviso indicando que a atualização da versão do protocolo Delta é um processo irreversível. Isto significa que, uma vez executada a atualização, não pode ser desfeita.

As atualizações de versões do protocolo podem potencialmente afetar a compatibilidade dos leitores de tabelas Delta Lake existentes, escritores ou ambos. Portanto, é aconselhável proceder com cautela e atualizar a versão do protocolo apenas quando necessário, como ao adotar novos recursos no Delta Lake.

Além disso, os usuários devem verificar se todas as cargas de trabalho e processos de produção atuais e futuros são compatíveis com as tabelas Delta Lake usando a nova versão do protocolo para garantir uma transição perfeita e evitar possíveis interrupções.

Conteúdo relacionado

• Runtime 2.0 (Spark 4.0, Java 21, Python 3.12, Delta Lake 4.0)
• Tempo de execução 1.3 (Spark 3.5, Java 11, Python 3.11, Delta Lake 3.2)
• Tempo de execução 1.2 (Spark 3.4, Java 11, Python 3.10, Delta Lake 2.4)