Compartilhar via

Diretrizes de recuperação de desastre para o Azure Data Lake Analytics

  • 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 Azure Synapse Analytics ou Microsoft Fabric.s

O Azure Data Lake Analytics é um serviço de análise sob demanda que simplifica big data. Em vez de implantar, configurar e ajustar o hardware, você escreve consultas para transformar seus dados e extrair informações importantes. O serviço de análise pode manipular trabalhos de qualquer escala de maneira instantânea, simplesmente configurando o controle para a quantidade de potência necessária. Você só paga pelo trabalho quando ele está em execução, o que o torna econômico. Este artigo fornece orientação sobre como proteger seus trabalhos contra as raras interrupções de toda a região ou contra exclusões acidentais.

Guia de recuperação de desastres

Ao usar o Azure Data Lake Analytics, é essencial preparar seu próprio plano de recuperação de desastre. Este artigo ajuda você a criar um plano de recuperação de desastre. Há mais recursos que podem ajudá-lo a criar seu próprio plano:

Práticas recomendadas e diretrizes de cenário

Você pode executar um trabalho U-SQL recorrente em uma conta do ADLA em uma região que lê e grava tabelas U-SQL e dados não estruturados. Prepare-se para um desastre seguindo estas etapas:

  1. Crie contas do ADLA e do ADLS na região secundária a ser usada durante uma interrupção.

    Observação

    Como os nomes de conta são globalmente exclusivos, use um esquema de nomenclatura consistente que indique qual conta é a secundária.

  2. Para os dados não estruturados, consulte Orientação de recuperação de desastre para dados no Azure Data Lake Storage Gen1

  3. Para os dados estruturados armazenados em tabelas e bancos de dado do ADLA, crie cópias dos artefatos de metadados, como bancos de dados, tabelas, funções com valor de tabela e assemblies. Você precisa ressincronizar periodicamente esses artefatos quando realizar alterações na produção. Por exemplo, os dados inseridos recentemente têm de ser replicados na região secundária por meio de sua cópia e inserção na tabela secundária.

    Observação

    Esses nomes de objeto têm o escopo definido para a conta secundária e não são globalmente exclusivos, portanto, podem ter os mesmos nomes da conta de produção primária.

Durante uma interrupção, você precisa atualizar seus scripts para que os caminhos de entrada apontem para o ponto de extremidade secundário. Em seguida, os usuários enviam seus trabalhos para a conta do ADLA na região secundária. A saída do trabalho será gravada em seguida nas contas do ADLA e do ADLS na região secundária.

Próximas etapas

Orientação de recuperação de desastre para dados no Azure Data Lake Storage Gen1