Runtimes do Apache Spark no Fabric
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 os principais componentes de fontes internas e de software livre, fornecendo aos clientes uma solução abrangente. Para simplificar, nós nos referimos ao Microsoft Fabric Runtime da plataforma 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 habilita tarefas de processamento e análise de dados em larga escala. 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 software livre que traz transações ACID e outros recursos de confiabilidade de dados para o Apache Spark. Integrado no Microsoft 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.
Pacotes de nível padrão para Java/Scala, Python e R – Pacotes que dão suporte a diversos ambientes e linguagens de programação. Esses pacotes são instalados e configurados automaticamente, permitindo que os desenvolvedores apliquem suas linguagens de programação preferenciais para tarefas de processamento de dados.
O Microsoft Fabric Runtime é criado com base em um sistema operacional de software livre 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 com suporte, Java, Scala, Python, Delta Lake e R, para tempos de execução baseados no Apache Spark na plataforma Microsoft Fabric.
Dica
Sempre use a versão de tempo de execução GA mais recente para sua carga de trabalho de produção, que atualmente é o Tempo de execução 1.3.
| Runtime 1.1 | Runtime 1.2 | Runtime 1.3 | |
|---|---|---|---|
| Apache Spark | 3.3.1 | 3.4.1 | 3.5.0 |
| Sistema operacional | Ubuntu 18.04 | Mariner 2.0 | Mariner 2.0 |
| Java | 8 | 11 | 11 |
| Scala | 2.12.15 | 2.12.17 | 2.12.17 |
| Python | 3.10 | 3.10 | 3.11 |
| Delta Lake | 2.2.0 | 2.4.0 | 3.2 |
| R | 4.2.2 | 4.2.2 | 4.4.1 |
Visite Runtime 1.1, Runtime 1.2 ou Runtime 1.3 para explorar detalhes, novos recursos, melhorias e cenários de migração para a versão de runtime específica.
Otimizações do Fabric
No Microsoft Fabric, tanto o mecanismo Spark quanto as implementações do Delta Lake incorporam otimizações e recursos específicos da plataforma. Esses recursos são projetados para usar integrações nativas na plataforma. É importante observar que todos esses recursos podem ser desabilitados para alcançar a funcionalidade padrão do Spark e do Delta Lake. Os Runtimes do Fabric para Apache Spark abrangem:
- A versão de software livre completa do Apache Spark.
- Uma coleção de quase 100 aprimoramentos internos e distintos de desempenho de consulta. Esses aprimoramentos incluem recursos como cache de partição (habilitando o cache de partição FileSystem para reduzir chamadas metastore) e Junção Cruzada à Projeção da Subconsulta Escalar.
- Cache inteligente integrado.
No Runtime do Fabric para Apache Spark e Delta Lake, há funcionalidades de gravador nativo que atendem a duas finalidades principais:
- Eles oferecem desempenho diferenciado para cargas de trabalho de gravação, otimizando o processo de gravação.
- Eles são padrão para a otimização V-Order de arquivos Delta Parquet. A otimização de V-Order do Delta Lake é crucial para fornecer desempenho de leitura superior em todos os mecanismos do Fabric. Para obter uma compreensão mais profunda de como ele opera e como gerenciá-lo, consulte o artigo dedicado sobre Otimização de tabela Delta Lake e V-Order.
Suporte a vários runtimes
O Fabric dá suporte a vários runtimes, oferecendo aos usuários a flexibilidade para alternar perfeitamente entre eles, minimizando o risco de incompatibilidades ou interrupções.
Por padrão, todos os novos workspaces usam a versão mais recente do runtime, que atualmente é o Runtime 1.3.
Para alterar a versão do runtime no nível do espaço de trabalho, vá para Configurações do Workspace > Engenharia/Ciência de Dados > Computação do Spark > Padrão no Nível do Espaço de Trabalho e selecione o runtime desejado nas opções disponíveis.
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 runtime no nível do espaço de trabalho recém-selecionada a partir da próxima Sessão spark. Se você estiver usando 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 runtime selecionada será aplicada.
Consequências das alterações de runtime nas Configurações do Spark
Em geral, pretendemos 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, emitimos uma mensagem de aviso e evitamos implementar a configuração.
Consequências das alterações de runtime no gerenciamento de bibliotecas
Em geral, nossa abordagem é migrar todas as bibliotecas do Runtime A para o Runtime B, incluindo runtimes públicos e personalizados. Se as versões do Python e do R permanecerem inalteradas, as bibliotecas deverão funcionar corretamente. No entanto, para Jars, há uma probabilidade significativa de que eles não funcionem devido a alterações nas dependências e outros fatores, como alterações no Scala, Java, Spark e no sistema operacional.
O usuário é responsável por atualizar ou substituir as bibliotecas que não funcionam com o Runtime B. Se houver um conflito, o que significa que o Runtime B inclui uma biblioteca originalmente definida no Runtime A, nosso sistema de gerenciamento de biblioteca tentará criar a dependência necessária para o Runtime B com base nas configurações do usuário. No entanto, o processo de construção falhará se ocorrer um conflito. No log de erros, os usuários podem observar 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 mais altas. No entanto, quando determinados recursos são habilitados (por exemplo, usando o método delta.upgradeTableProtocol(minReaderVersion, minWriterVersion), a compatibilidade com versões inferiores do Delta Lake pode ser comprometida. Nesses casos, é essencial modificar cargas de trabalho que fazem referência às tabelas atualizadas para se alinharem a uma versão do Delta Lake que mantenha a compatibilidade.
Cada tabela Delta está associada a uma especificação de protocolo, definindo os recursos compatíveis. Os aplicativos que interagem com a tabela, para leitura ou gravação, dependem dessa especificação de protocolo para determinar se são compatíveis com o conjunto de recursos da tabela. Se um aplicativo não tiver a capacidade de lidar com um recurso listado como compatível com o protocolo da tabela, não será possível ler ou gravar nessa tabela.
A especificação do protocolo é dividida em dois componentes distintos: o protocolo de leitura e o protocolo de gravação. Visite a página "Como o Delta Lake gerencia a compatibilidade de recursos?" para ler detalhes sobre ele.
Os usuários podem executar o comando delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) dentro do ambiente do PySpark e no Spark SQL e Scala. Esse 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 atualizar a versão do protocolo Delta é um processo não acessível. Isso significa que, depois que a atualização é executada, ela não pode ser desfeita.
As atualizações de versão do protocolo podem afetar potencialmente a compatibilidade de leitores de tabela, gravadores ou ambos existentes do Delta Lake. Portanto, é aconselhável continuar com cuidado e atualizar a versão do protocolo somente 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 tabelas delta lake usando a nova versão de protocolo para garantir uma transição perfeita e evitar possíveis interrupções.
Alterações Delta 2.2 vs Delta 2.4
No Fabric Runtime, versão 1.3 mais recente e no Fabric Runtime, versão 1.2, o formato de tabela padrão (spark.sql.sources.default) agora é delta. Nas versões anteriores do Fabric Runtime, versão 1.1 e em todo o Synapse Runtime para Apache Spark contendo Spark 3.3 ou anteriores, o formato de tabela padrão foi definido como parquet. Verifique a tabela com os detalhes das configurações do Apache Spark para ver as diferenças entre o Azure Synapse Analytics e o Microsoft Fabric.
Todas as tabelas criadas usando Spark SQL, PySpark, Scala Spark e Spark R, sempre que o tipo de tabela for omitido, criarão a tabela como delta por padrão. Se os scripts definirem explicitamente o formato de tabela, isso será respeitado. O comando USING DELTA em comandos de criação de tabela do Spark torna-se redundante.
Os scripts que esperam ou assumem o formato de tabela parquet devem ser revisados. Não há suporte para os comandos a seguir nas tabelas Delta:
ANALYZE TABLE $partitionedTableName PARTITION (p1) COMPUTE STATISTICSALTER TABLE $partitionedTableName ADD PARTITION (p1=3)ALTER TABLE DROP PARTITIONALTER TABLE RECOVER PARTITIONSALTER TABLE SET SERDEPROPERTIESLOAD DATAINSERT OVERWRITE DIRECTORYSHOW CREATE TABLECREATE TABLE LIKE