Documentação de orientação de recuperação após desastre para Data Lake Analytics do Azure

>[! IMPORTANTE] > O Azure Data Lake Analytics descontinuado a 29 de fevereiro de 2024. Saiba mais com este anúncio. >>Para análise de dados, a sua organização pode utilizar Azure Synapse Analytics ou Microsoft Fabric.s

O Azure Data Lake Analytics é um serviço de tarefa de análise no local que simplifica os macrodados. Em vez de implementar, configurar e otimizar hardware, escreve consultas para transformar os dados e extrair informações valiosas. O serviço de análise pode processar tarefas de qualquer dimensionamento instantaneamente definindo a quantidade de potência necessária. Só paga o seu trabalho quando está em execução, tornando-o rentável. Este artigo fornece orientações sobre como proteger os seus trabalhos contra falhas raras em toda a região ou eliminações acidentais.

Documentação de orientação da recuperação após desastre

Ao utilizar o Azure Data Lake Analytics, é fundamental que prepare o seu próprio plano de recuperação após desastre. Este artigo ajuda-o a criar um plano de recuperação após desastre. Existem mais recursos que podem ajudá-lo a criar o seu próprio plano:

Melhores práticas e orientações de cenários

Pode executar uma tarefa U-SQL periódica numa conta do ADLA numa região que lê e escreve tabelas U-SQL e dados não estruturados. Prepare-se para um desastre ao seguir estes passos:

  1. Crie contas ADLA e ADLS na região secundária que serão utilizadas durante uma indisponibilidade.

    Nota

    Uma vez que os nomes de conta são globalmente exclusivos, utilize um esquema de nomenclatura consistente que indique que conta é secundária.

  2. Para dados não estruturados, veja Orientações de recuperação após desastre para dados no Azure Data Lake Storage Gen1

  3. Para dados estruturados armazenados em tabelas e bases de dados do ADLA, crie cópias dos artefactos de metadados, tais como bases de dados, tabelas, funções com valor de tabela e assemblagens. Tem de ressincronizar periodicamente estes artefactos quando ocorrem alterações na produção. Por exemplo, os dados recentemente inseridos têm de ser replicados para a região secundária ao copiar os dados e inserir na tabela secundária.

    Nota

    Estes nomes de objetos estão no âmbito da conta secundária e não são globalmente exclusivos, pelo que podem ter os mesmos nomes que na conta de produção primária.

Durante uma indisponibilidade, tem de atualizar os scripts para que os caminhos de entrada apontem para o ponto final secundário. Em seguida, os utilizadores submetem as suas tarefas para a conta do ADLA na região secundária. Em seguida, o resultado da tarefa será escrito na conta do ADLA e do ADLS na região secundária.

Passos seguintes

Documentação de orientação de recuperação após desastre para dados no Azure Data Lake Storage Gen1