Compartilhar via

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

O Microsoft Fabric Runtime 1.2 é a versão de runtime de GA mais recente. Os principais componentes do Runtime 1.2 incluem:

  • Apache Spark 3.4.1
  • Sistema operacional: Mariner 2.0
  • Java: 11
  • Scala: 2.12.17
  • Python: 3.10
  • Delta Lake: 2.4.0
  • R: 4.2.2

Captura de tela mostrando onde selecionar a versão do runtime.

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 notebooks ou trabalhos na plataforma Microsoft Fabric. Consulte a documentação para obter uma lista completa de bibliotecas. O Microsoft Fabric distribui 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 o desempenho e a confiabilidade ideais para suas tarefas de processamento de dados.

Novos recursos e melhorias do Spark versão 3.4.1

O Apache Spark 3.4.0 é a quinta versão da linha 3.x. Esta versão, impulsionada pela comunidade de software livre, resolveu mais de 2.600 tíquetes Jira. Ela apresenta um cliente Python para Spark Connect, aprimora o fluxo estruturado com acompanhamento de progresso assíncrono e processamento com estado do Python. Ela expande a cobertura da API do Pandas com suporte de entrada NumPy, simplifica a migração de data warehouses tradicionais por meio de conformidade ANSI e apresenta novas funções internas. Ela também melhora a produtividade e a depuração do desenvolvimento 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.

Principais destaques

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

Novas otimizações de consulta personalizadas

Suporte de 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 paralelas na mesma tabela usando uma consulta SQL INSERT INTO. Esse erro pode resultar em perda de dados. Nosso novo recurso, o Algoritmo de Confirmação de Saída de Arquivo, resolve esse problema, permitindo que os clientes executem a inserção de dados paralela perfeitamente.

Para acessar esse recurso, habilite o sinalizador de recurso spark.sql.enable.concurrentWrites, que está habilitado 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 dá suporte à execução paralela de consultas INSERT OVERWRITE em que cada trabalho simultâneo substitui dados em partições diferentes da mesma tabela dinamicamente. Para essa finalidade, o Spark oferece um recurso alternativo, que pode ser ativado definindo a configuração spark.sql.sources.partitionOverwriteMode como 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 arquivos do trabalho com falha. Essa coexistência pode causar confusão para os usuários, pois torna-se desafiador 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.

O sinalizador spark.sql.auto.cleanup.enabled controla nosso novo recurso, resolvendo esse problema. Quando habilitado, o Spark ignora automaticamente a leitura de arquivos que não foram confirmados quando ele executa spark.read ou seleciona consultas de uma tabela. Os arquivos gravados antes de habilitar esse recurso continuam a ser lidos normalmente.

Aqui estão as alterações visíveis:

  • Todos os arquivos agora incluem um identificador tid-{jobID} em seus nomes de arquivo.
  • Em vez do marcador _success normalmente criado no local de saída após a conclusão bem-sucedida do trabalho, um novo marcador _committed_{jobID} é gerado. Esse marcador associa IDs de trabalho bem-sucedidas a nomes de arquivo 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 deste 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 em que 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 como false por 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 atrasar as operações de leitura. É recomendável executar manualmente o comando de limpeza 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, alimentado pelo Apache Spark 3.4, examine o guia oficial de migração.

Novos recursos e melhorias do Delta Lake 2.4

O Delta Lake é um projeto de software livre que permite a construção de uma arquitetura de lakehouse com base em data lakes. O Delta Lake fornece transações ACID e tratamento de metadados escalonável, além de unificar o processamento de dados de streaming e em lote com base nos data lakes existentes.

Especificamente, o Delta Lake oferece:

  • Transações ACID no Spark: os níveis de isolamento serializáveis asseguram que os leitores nunca vejam dados inconsistentes.
  • Tratamento escalonável de metadados: usa o poder de processamento distribuído do Spark para lidar com todos os metadados de tabelas em escala petabyte com bilhões de arquivos à vontade.
  • Streaming e unificação em lote: uma tabela no Delta Lake é uma tabela em lotes e uma fonte de streaming e um coletor. A ingestão de dados de streaming, o provisionamento histórico em lote e as consultas interativas funcionam imediatamente.
  • Imposição de esquema: trata automaticamente as variações de esquema para evitar a inserção de registros inválidos durante a ingestão.
  • Viagem no tempo: o controle de versão de dados permite reversões, trilhas de auditoria de histórico completas e experimentos de machine learning reproduzíveis.
  • Upserts e deletes: dá suporte a operações de mesclagem, atualização e exclusão para habilitar casos de uso complexos, como a captura de dados de alteração, operações de dimensão de alteração lenta (SCD), upserts de streaming e assim por diante.

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

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

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

Conteúdo relacionado