Fabric Runtime 1.2 (EOSA)

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.

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

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 tickets do Jira. Ela introduz um cliente Python para Spark Connect, aprimora o Structured Streaming com monitoramento 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. Ele também melhora a produtividade e a capacidade de depuração do desenvolvimento com o perfilamento 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. Nossa novidade, o Algoritmo de Confirmação de Saída de Arquivo, resolve esse problema, permitindo que os clientes executem a inserção de dados paralelamente, sem problemas.

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 uma tarefa lê de uma tabela enquanto outra está inserindo dados simultaneamente na mesma tabela, a tarefa 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 facilmente com todos os metadados de tabelas na escala de petabytes, com bilhões de arquivos.
• Streaming e unificação de lote: uma tabela no Delta Lake é simultaneamente uma tabela em lotes, uma fonte de streaming e um destino de streaming. A ingestão de dados de streaming, o provisionamento histórico em lote e as consultas interativas funcionam imediatamente.
• Aplicação de esquemas: 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 aprendizado de máquina reproduzíveis.
• Upserts e deletes: oferece suporte a operações de mesclagem, atualização e exclusão para habilitar casos de uso complexos, como a captura de dados de mudanças, operações de dimensões lentamente mutáveis (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

• Leia sobre os Runtimes do Apache Spark no Fabric – Visão Geral, Versionamento, suporte para múltiplos runtimes e atualização do protocolo do Delta Lake