Ler em inglês

Partilhar via

Tempo de execução da malha 1.2 (GA)

  • Artigo

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 e ciência de dados. Este documento abrange os componentes e versões do Runtime 1.2.

Os principais componentes do Runtime 1.2 incluem:

  • Apache Spark 3.4.1
  • Sistema Operacional: Mariner 2.0
  • Java: 11
  • Escala: 2.12.17
  • Píton: 3.10
  • Lago Delta: 2.4.0
  • R: 4.2.2

Sugestão

Use sempre a versão mais recente do tempo de execução do GA para sua carga de trabalho de produção, que atualmente é o Runtime 1.3.

Captura de tela mostrando onde selecionar a versão de tempo de execução.

O Microsoft Fabric Runtime 1.2 vem com uma coleção de pacotes de nível padrão, incluindo uma instalação completa do Anaconda e bibliotecas comumente usadas para Java/Scala, Python e R. Essas bibliotecas são incluídas automaticamente ao usar blocos de anotações ou trabalhos na plataforma Microsoft Fabric. Consulte a documentação para obter uma lista completa de bibliotecas. O Microsoft Fabric lança periodicamente atualizações de manutenção para o Runtime 1.2, fornecendo correções de bugs, aprimoramentos de desempenho e patches de segurança. Manter-se atualizado garante um desempenho e confiabilidade ideais para suas tarefas de processamento de dados.

Novos recursos e melhorias do Spark Release 3.4.1

Apache Spark 3.4.0 é a quinta versão na linha 3.x. Este lançamento, impulsionado pela comunidade de código aberto, resolveu mais de 2.600 tíquetes do Jira. Ele introduz um cliente Python para Spark Connect, aprimora o Structured Streaming com rastreamento de progresso assíncrono e processamento stateful Python. Ele expande a cobertura da API Pandas com suporte de entrada NumPy, simplifica a migração de armazéns de dados tradicionais por meio da conformidade com ANSI e novas funções integradas. Ele também melhora a produtividade de desenvolvimento e a capacidade de depuração com a criação de perfil de memória. Além disso, o Runtime 1.2 é baseado no Apache Spark 3.4.1, uma versão de manutenção focada em correções de estabilidade.

Destaques chave

Leia a versão completa das notas de versão para uma versão específica do Apache Spark visitando o Spark 3.4.0 e o Spark 3.4.1.

Novas otimizações de consulta personalizadas

Suporte a gravações simultâneas no Spark

Encontrar um erro 404 com a mensagem 'Falha na operação: o caminho especificado não existe' é um problema comum ao executar inserções de dados paralelos na mesma tabela usando uma consulta SQL INSERT INTO. Este erro pode resultar em perda de dados. Nosso novo recurso, o File Output Committer Algorithm, resolve esse problema, permitindo que os clientes realizem a inserção de dados paralelos sem problemas.

Para acessar esse recurso, habilite o sinalizador de recurso, que é habilitado spark.sql.enable.concurrentWrites por padrão a partir do Runtime 1.2 (Spark 3.4). Embora esse recurso também esteja disponível em outras versões do Spark 3, ele não está habilitado por padrão. Esse recurso não suporta a execução paralela de consultas INSERT OVERWRITE em que cada trabalho simultâneo substitui dados em partições diferentes da mesma tabela dinamicamente. Para isso, o Spark oferece um recurso alternativo, que pode ser ativado configurando a spark.sql.sources.partitionOverwriteMode configuração para dinâmica.

Leituras inteligentes, que ignoram arquivos de trabalhos com falha

No sistema de confirmação do Spark atual, quando uma inserção em um trabalho de tabela falha, mas algumas tarefas são bem-sucedidas, os arquivos gerados pelas tarefas bem-sucedidas coexistem com os arquivos do trabalho com falha. Essa coexistência pode causar confusão para os usuários, pois torna-se difícil distinguir entre arquivos pertencentes a trabalhos bem-sucedidos e malsucedidos. Além disso, quando um trabalho lê de uma tabela enquanto outro está inserindo dados simultaneamente na mesma tabela, o trabalho de leitura pode acessar dados não confirmados. Se um trabalho de gravação falhar, o trabalho de leitura poderá processar dados incorretos.

A spark.sql.auto.cleanup.enabled bandeira controla nosso novo recurso, abordando esse problema. Quando ativado, o Spark ignora automaticamente a leitura de arquivos que não foram confirmados quando executa spark.read ou seleciona consultas de uma tabela. Os ficheiros escritos antes de ativar esta funcionalidade continuam a ser lidos como habitualmente.

Aqui estão as mudanças visíveis:

  • Todos os arquivos agora incluem um tid-{jobID} identificador em seus nomes de arquivo.
  • Em vez do marcador normalmente criado no local de saída após a conclusão bem-sucedida do _success trabalho, um novo _committed_{jobID} marcador é gerado. Esse marcador associa IDs de trabalho bem-sucedidos a nomes de arquivos específicos.
  • Introduzimos um novo comando SQL que os usuários podem executar periodicamente para gerenciar o armazenamento e limpar arquivos não confirmados. A sintaxe para este comando é a seguinte:
    • Para limpar um diretório específico: CLEANUP ('/path/to/dir') [RETAIN number HOURS];
    • Para limpar uma tabela específica: CLEANUP [db_name.]table_name [RETAIN number HOURS]; Nesta sintaxe, path/to/dir representa o URI do local onde a limpeza é necessária e number é um valor de tipo duplo que representa o período de retenção. O período de retenção padrão é definido como sete dias.
  • Introduzimos uma nova opção de configuração chamada spark.sql.deleteUncommittedFilesWhileListing, que é definida por false padrão. Habilitar essa opção resulta na exclusão automática de arquivos não confirmados durante as leituras, mas esse cenário pode tornar as operações de leitura mais lentas. É recomendável executar manualmente o comando cleanup quando o cluster estiver ocioso em vez de habilitar esse sinalizador.

Guia de migração do Runtime 1.1 para o Runtime 1.2

Ao migrar do Runtime 1.1, alimentado pelo Apache Spark 3.3, para o Runtime 1.2, com tecnologia Apache Spark 3.4, consulte o guia oficial de migração.

Novos recursos e melhorias do Delta Lake 2.4

Delta Lake é um projeto de código aberto que permite construir uma arquitetura lakehouse em cima de data lakes. O Delta Lake fornece transações ACID, manipulação de metadados escalável e unifica streaming e processamento de dados em lotesobre os data lakes existentes.

Especificamente, Delta Lake oferece:

  • Transações ACID no Spark: os níveis de isolamento serializáveis garantem que os leitores nunca vejam dados inconsistentes.
  • Tratamento escalável de metadados: usa o poder de processamento distribuído do Spark para lidar com todos os metadados para tabelas em escala de petabytes com bilhões de arquivos à vontade.
  • Streaming e unificação de lotes : Uma tabela no Delta Lake é uma tabela em lote e uma fonte e coletor de streaming. A ingestão de dados de streaming, o backfill histórico em lote, as consultas interativas funcionam prontamente.
  • Aplicação do esquema: lida automaticamente com variações de esquema para evitar a inserção de registros incorretos durante a ingestão.
  • Viagem no tempo: o controle de versão de dados permite reversões, trilhas de auditoria históricas completas e experimentos de aprendizado de máquina reproduzíveis.
  • Upserts e deletes: Suporta operações de mesclagem, atualização e exclusão para permitir casos de uso complexos, como captura de dados de alteração, operações de dimensão de mudança lenta (SCD), upserts de streaming e assim por diante.

Leia a versão completa das notas de lançamento do Delta Lake 2.4.

Pacotes de nível padrão para bibliotecas Java, Scala, Python

Para obter uma lista de todos os pacotes de nível padrão para Java, Scala, Python e suas respetivas versões, consulte as notas de versão.

Conteúdos relacionados