Compartilhar via

Saiba como solucionar problemas de falhas de runtime U-SQL provocadas por alterações de runtime

  • Artigo

Importante

O Azure Data Lake Analytics desativado em 29 de fevereiro de 2024. Saiba mais nesse comunicado.

Para análise de dados, sua organização pode usar o Azure Synapse Analytics ou o Microsoft Fabric.

O runtime U-SQL do Azure Data Lake, incluindo o compilador, o otimizador e o gerenciador de trabalhos, é o que processa seu código U-SQL.

Como escolher sua versão do runtime U-SQL

Quando você envia trabalhos do U-SQL do Visual Studio, do SDK do ADL ou do portal do Azure Data Lake Analytics, seu trabalho usa o runtime padrão disponível no momento. Novas versões do runtime do U-SQL são lançadas regularmente e incluem atualizações secundárias e correções de segurança.

Você também pode escolher uma versão de runtime personalizada; quer porque você deseja experimentar uma nova atualização, precisa permanecer em uma versão mais antiga de um runtime ou foi fornecido com um hotfix para um problema relatado em que você não pode esperar pela nova atualização regular.

Cuidado

A escolha de um runtime diferente do padrão apresenta o potencial de interromper seus trabalhos do U-SQL. Use essas outras versões somente para teste.

Em casos raros, Suporte da Microsoft pode fixar uma versão diferente de um runtime como o padrão para sua conta. Verifique se você reverter esse pino assim que possível. Se você permanecer fixado a essa versão, ela vai expirar em alguma data posterior.

Como monitorar as versões de runtime U-SQL dos seus trabalhos

Você pode ver o histórico das versões de runtime usadas pelos seus trabalhos anteriores no histórico da sua conta no navegador de trabalho do Visual Studio ou no histórico de trabalhos do portal do Azure.

  1. No portal do Azure, acesse sua conta do Data Lake Analytics.
  2. Selecione Exibir todos os trabalhos. Uma lista de todos os trabalhos ativos e concluídos recentemente na conta é exibida.
  3. Opcionalmente, selecione Filtrar para ajudá-lo a encontrar os trabalhos por Intervalo de Tempo, Nome do Trabalho e Valores de Autor .
  4. Você pode ver o runtime usado nos trabalhos concluídos.

Como exibir a versão de runtime de um trabalho anterior

As versões de runtime disponíveis mudam com o passar do tempo. O runtime padrão é sempre chamado de "padrão" e mantemos pelo menos o runtime anterior disponível por algum tempo e disponibilizamos runtimes especiais por vários motivos. Runtimes explicitamente nomeados geralmente seguem o seguinte formato (os itálicos são usados para partes variáveis e [] indicam partes opcionais):

release_YYYYMMDD_adl_buildno[_modifier]

Por exemplo, release_20190318_adl_3394512_2 significa a segunda versão do build 3394512 da versão de runtime de 18 de março de 2019, e release_20190318_adl_3394512_private significa um build particular da mesma versão. Observação: a data está relacionada ao último check-in nessa versão, e não necessariamente à data de lançamento oficial.

Como solucionar problemas de versão do runtime U-SQL

Há dois possíveis problemas de versão de runtime que você pode encontrar:

  1. Um script ou algum código de usuário está alterando o comportamento de uma versão para outra. Essas alterações interruptivas costumam ser comunicadas antecipadamente com a publicação de notas sobre a versão. Se você encontrar uma alteração tão significativa, entre em contato com Suporte da Microsoft para relatar esse comportamento de falha (caso ainda não tenha sido documentado) e envie seus trabalhos para a versão de runtime mais antiga.

  2. Você tem usado um runtime não padrão explicitamente ou implicitamente quando ele foi fixado em sua conta e esse runtime foi removido após algum tempo. Se você encontrar runtimes ausentes, atualize seus scripts para executar com o runtime padrão atual. Se precisar de mais tempo, entre em contato com Suporte da Microsoft

Problemas conhecidos

  1. Referenciar o arquivo Newtonsoft.Json 12.0.3 ou posterior em um script USQL provoca a seguinte falha de compilação:

    "Os trabalhos em execução na sua conta do Data Lake Analytics provavelmente ficarão mais lentos ou não serão concluídos. Um problema inesperado está nos impedindo de restaurar automaticamente essa funcionalidade para sua conta do Azure Data Lake Analytics. Os engenheiros do Azure Data Lake foram contatados para investigação."

    Onde a pilha de chamadas conterá:
    System.IndexOutOfRangeException: Index was outside the bounds of the array.
    at Roslyn.Compilers.MetadataReader.PEFile.CustomAttributeTableReader.get_Item(UInt32 rowId)
    ...

    Solução: use o arquivo Newtonsoft.Json v12.0.2 ou inferior.

  2. Os clientes podem ver arquivos e pastas temporários no armazenamento. Eles são produzidos na execução normal do trabalho, mas geralmente são excluídos antes que os clientes as vejam. Em certas circunstâncias, que são raras e aleatórias, elas podem permanecer visíveis. Eles eventualmente são excluídos e nunca são contados como parte do armazenamento do usuário ou geram qualquer forma de encargos. Dependendo da lógica de trabalho dos clientes, eles podem causar problemas. Por exemplo, se o trabalho enumerar todos os arquivos na pasta e, em seguida, comparar as listas de arquivos, ele poderá falhar devido à presença dos arquivos temporários inesperados. Da mesma forma, se um trabalho downstream enumerar todos os arquivos de uma determinada pasta para processamento adicional, ele também poderá enumerar os arquivos temporários.

    Solução: uma correção é identificada no runtime em que os arquivos temporários serão armazenados na pasta temporária no nível da conta, em vez da pasta de saída atual. Os arquivos temporários serão gravados nessa nova pasta temporária e serão excluídos no final da execução do trabalho.
    Como essa correção está tratando os dados do cliente, é importante que essa correção seja bem validada no MSFT antes de ser lançada. Espera-se que essa correção esteja disponível como runtime beta no meio do ano de 2021 e como runtime padrão no segundo semestre do ano de 2021.

Confira também