Compartilhar via


Migrar clusters do Apache Hadoop local para o Azure HDInsight

Este artigo apresenta recomendações para o armazenamento de dados em sistemas do Azure HDInsight. Ele faz parte de uma série que fornece as melhores práticas para ajudar a migrar sistemas locais do Apache Hadoop para o Azure HDInsight.

Escolha o sistema de armazenamento adequado para clusters do HDInsight

A estrutura do diretório do HDFS (Sistema de Arquivos do Apache Hadoop) local pode ser criada novamente no armazenamento do Azure ou no Azure Data Lake Storage. Você pode excluir com segurança os clusters do HDInsight usados para cálculo sem perder dados do usuário. Ambos os serviços podem ser usados como o sistema de arquivos padrão e um sistema de arquivos adicionais para um cluster do HDInsight. O cluster e a conta de armazenamento do HDInsight devem ser hospedados na mesma região.

Armazenamento do Azure

Os clusters do HDInsight podem usar o contêiner de blobs no Armazenamento do Azure como o sistema de arquivos padrão ou um sistema de arquivos adicional. A conta de armazenamento da camada Standard tem suporte para uso com clusters do HDInsight. Não há compatibilidade com a camada Premier. O contêiner de blob padrão armazena informações específicas do cluster como logs e o histórico do trabalho. Não há suporte para o compartilhamento de um contêiner de blob como o sistema de arquivos padrão para vários clusters.

As contas de armazenamento definidas no processo de criação e suas respectivas chaves são armazenadas no %HADOOP_HOME%/conf/core-site.xml em nós de cluster. Também podem ser acessadas na seção "Site principal personalizado" na configuração do HDFS na interface do usuário do Ambari. A chave de conta de armazenamento é criptografada por padrão e um script personalizado de descriptografia é usado para descriptografar as chaves antes que elas sejam passadas para daemons do Hadoop. Os trabalhos incluindo Hive, MapReduce, streaming de Hadoop e Pig contêm uma descrição de contas de armazenamento e dos metadados com elas.

O Armazenamento do Azure pode ser replicado geograficamente. Embora a replicação geográfica forneça redundância de dados e recuperação geográfica, um failover para a localização replicada geograficamente afetará seriamente o desempenho e poderá gerar custos adicionais. A recomendação é escolher a replicação geográfica com sabedoria e somente se o valor dos dados compensar o custo adicional.

Um dos formatos a seguir pode ser usado para acessar dados armazenados no Armazenamento do Azure:

Formato de Acesso a Dados Descrição
wasb:/// Acessar o armazenamento padrão usando comunicação não criptografada.
wasbs:/// Acessar o armazenamento padrão usando comunicação criptografada.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Usado ao se comunicar com uma conta de armazenamento não padrão. 

As Metas de escalabilidade para contas de armazenamento Standard listam os limites atuais nas contas de Armazenamento do Azure. Se as necessidades do aplicativo excederem as metas de escalabilidade de uma única conta de armazenamento, o aplicativo poderá ser criado para usar múltiplas contas de armazenamento e fazer o particionamento dos objetos de dados nessas contas de armazenamento.

A Análise de Armazenamento do Azurefornece métricas para todos os serviços de armazenamento e o portal do Azure pode ser configurado para coletar métricas a serem visualizadas por meio de gráficos. Alertas podem ser criados para notificar quando os limites forem atingidos para métricas de recursos de armazenamento.

O Armazenamento do Azure oferece exclusão reversível para objetos de BLOB para ajudar a recuperar dados quando eles forem modificados ou excluídos temporariamente por um aplicativo ou outro usuário da conta de armazenamento.

Você pode criar instantâneos de blob. Um instantâneo é uma versão somente leitura de um blob criada em um ponto no tempo e fornece uma maneira de fazer backup de um blob. Quando um instantâneo tiver sido criado, ele pode ser lido, copiado ou excluído, mas não modificado.

Observação

Para as versões mais antigas das Distribuições do Hadoop locais que não têm o certificado "wasbs", é preciso importá-las para o armazenamento de confiança do Java.

Os métodos a seguir podem ser usados para importar certificados para o repositório de confiança Java:

Baixe o certificado TLS/SSL do Blob do Azure em um arquivo

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

Importe o arquivo acima para o repositório de confiança Java em todos os nós

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

Verifique se o certificado adicionado está no repositório de confiança

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

Para obter mais informações, confira os seguintes artigos:

Azure Data Lake Storage Gen2

O Azure Data Lake Storage Gen2 é a oferta mais avançada de armazenamento. Ele unifica os principais recursos do Azure Data Lake Storage Gen1 com um ponto de extremidade do sistema de arquivos compatível com Hadoop integrado diretamente ao Armazenamento de Blobs do Azure. Essa melhoria combina os benefícios de escala e custo do armazenamento de objeto com a confiabilidade e o desempenho normalmente associados apenas a sistemas de arquivos locais.

O Azure Data Lake Storage Gen 2 foi desenvolvido a partir do Armazenamento de Blobs do Azure e permite que você faça interface com os dados usando os paradigmas de armazenamento de objeto e sistema de arquivos. Os recursos do Azure Data Lake Storage Gen1, como semântica do sistema de arquivos, segurança e escala em nível de arquivo, são combinados com armazenamento em camadas com baixo custo, alta disponibilidade / recursos de recuperação de desastre e um grande ecossistema SDK / de ferramentas vindos do Armazenamento do Blob do Azure. No Data Lake Storage Gen2, todas as qualidades de armazenamento de objetos permanecem enquanto se adicionam as vantagens de uma interface de sistema de arquivos otimizada para cargas de trabalho de análise.

Um recurso fundamental do Data Lake Storage Gen2 é a adição de um namespace hierárquico ao serviço de armazenamento BLOB, que organiza objetos / arquivos em uma hierarquia de diretórios para acesso a dados de alto desempenho. A estrutura hierárquica permite que operações como renomear ou excluir um diretório sejam operações únicas de metadados atômicos no diretório, em vez de enumerar e processar todos os objetos que compartilham o prefixo de nome do diretório.

No passado, a análise baseada na nuvem tinha que se comprometer em áreas de desempenho, gerenciamento e segurança. Os principais recursos do ADLS (Azure Data Lake Storage) Gen2 são os seguintes:

  • Acesso compatível com Hadoop: O Azure Data Lake Storage Gen2 permite gerenciar e acessar dados do mesmo jeito que você faria com umHDFS (Sistema de Arquivos Distribuído do Hadoop). O novodriver ABFSestá disponível em todos os ambientes Apache Hadoop inclusos no Azure HDInsight. Esse driver permite que você acesse dados armazenados no Data Lake Storage Gen2.

  • Um superconjunto de permissões POSIX: o modelo de segurança para o Data Lake Gen2 é totalmente compatível com as permissões ACL e POSIX, juntamente com alguma granularidade extra específica para o Data Lake Storage Gen2. As configurações podem ser definidas por meio de ferramentas de administração ou por meio de estruturas, como Hive e Spark.

  • Econômico : Data Lake Storage O Gen2 apresenta capacidade de armazenamento e transações de baixo custo. Conforme os dados fazem a transição em todo o ciclo de vida, as taxas de cobrança são modificadas para minimizar os custos por meio de recursos internos, comoCiclo de vida de Armazenamento de Blobs do Azure.

  • Funciona com ferramentas, estruturas e aplicativos de armazenamento do Blob : Data Lake Storage O Gen2 continua a trabalhar com uma grande variedade de ferramentas, estruturas e aplicativos que existem hoje para o armazenamento do Blob.

  • Driver otimizado: o driver ABFS (Sistema de Arquivos de Blobs do Azure) éotimizado especificamentepara análise de Big Data. As APIs REST correspondentes são exibidas por meio do ponto de extremidade dfs, dfs.core.windows.net.

Um dos formatos a seguir pode ser usado para acessar dados armazenados no ADLS Gen2:

  • abfs:///: Acessar o Data Lake Storage padrão para o cluster.
  • abfs://file_system@account_name.dfs.core.windows.net: Utilizado ao se comunicar com uma conta do Data Lake Storage não padrão.

Observação

Não há suporte para a atualização da conta de armazenamento primária ou secundária de um cluster em execução com recursos do Azure Data Lake Storage Gen2. Para alterar o tipo de armazenamento de um cluster HDInsight existente para o Data Lake Storage Gen2, você precisará recriar o cluster e selecionar uma conta de armazenamento habilitada para namespace hierárquico.

Para obter mais informações, confira os seguintes artigos:

Proteja as Chaves de Armazenamento do Microsoft Azure dentro de configuração de cluster de Hadoop local

As chaves de armazenamento do Azure adicionadas aos arquivos de configuração do Hadoop estabelecem a conectividade entre o Armazenamento de Blobs do Azure e o HDFS local. Essas chaves podem ser protegidas criptografando-as com a estrutura do provedor de credenciais do Hadoop. Depois de criptografadas, podem ser armazenadas e acessadas com segurança.

Para provisionar as credenciais:

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

Para adicionar o caminho do provedor acima ao core-site.xml ou à configuração do Ambari no site central personalizado:

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Observação

A propriedade de caminho de provedor também pode ser adicionada à linha de comando distcp, em vez de armazenar a chave no nível do cluster no core-site.xml da seguinte maneira:

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

Restringir o acesso de dados do Armazenamento do Azure usando SAS

Por padrão, o HDInsight tem acesso completo aos dados nas contas de Armazenamento do Azure associadas ao cluster. SAS (Assinaturas de Acesso Compartilhado) no contêiner de blob pode ser usada para restringir o acesso aos dados, como fornecer aos usuários acesso somente leitura aos dados.

Usando o token SAS criado com Python

  1. Abra o arquivo SASToken.py e altere os valores a seguir:

    Propriedade Token Descrição
    policy_name O nome a ser usado para a política armazenada que será criada.
    storage_account_name O nome da sua conta de armazenamento.
    storage_account_key A chave da conta de armazenamento.
    storage_container_name O contêiner na conta de armazenamento para o qual você deseja restringir o acesso.
    example_file_path O caminho para um arquivo que é carregado no contêiner.
  2. O arquivo SASToken.py vem com as permissões ContainerPermissions.READ + ContainerPermissions.LIST e pode ser ajustado com base no caso de uso.

  3. Execute o script da seguinte maneira: python SASToken.py

  4. Isso exibirá o token SAS semelhante ao texto a seguir quando o script for concluído: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Para limitar o acesso a um contêiner com Assinatura de Acesso Compartilhado, adicione uma entrada personalizada à configuração do site central para o cluster na propriedade Adicionar do site central de Configurações Avançadas Personalizadas do Ambari HDFS.

  6. Use os valores a seguir para os campos Chave e Valor:

    Chave: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netValor: A SAS KEY retornada pela etapa 4 FROM do aplicativo Python acima.

  7. Clique no botão Adicionar para salvar essa chave e esse valor e clique no botão Salvar para salvar as alterações de configuração. Quando solicitado, adicione uma descrição da alteração ("adicionando acesso de armazenamento SAS", por exemplo) e clique em Salvar.

  8. Na interface do usuário da Web do Ambari, selecione HDFS na lista à esquerda e, em seguida, selecione Reiniciar Todos os Afetados na lista suspensa Ações de Serviço à direita. Quando solicitado, selecione Confirmar Reiniciar Tudo.

  9. Repita esse processo para MapReduce2 e YARN.

Há três pontos importantes a lembrar sobre o uso de Tokens de SAS no Azure:

  1. Quando tokens SAS são criados com permissões "READ + LIST", os usuários que acessam o contêiner de Blob com esse token SAS não poderão "gravar e excluir" dados. Os usuários que acessarem o contêiner de Blob com esse token SAS e tentarem realizar uma operação de gravação ou exclusão receberão uma mensagem como "This request is not authorized to perform this operation".

  2. Quando os tokens SAS são gerados com permissões READ + LIST + WRITE (para restringir DELETE apenas), comandos como hadoop fs -put primeiro gravam em um arquivo \_COPYING\_ e, em seguida, tentam renomear o arquivo. A operação HDFS é mapeada para um copy+delete para WASB. Uma vez que a DELETE permissão não foi concedida, o "put" falhará. A operação \_COPYING\_ é um recurso do Hadoop que se destina a fornecer algum controle de simultaneidade. No momento, não há nenhuma maneira de restringir apenas a operação "DELETE" sem afetar as operações "WRITE" também.

  3. Infelizmente, o provedor de credenciais do hadoop e o provedor da chave de descriptografia (ShellDecryptionKeyProvider) atualmente não funcionam com os tokens SAS, assim, atualmente não podem ser protegidos contra a visibilidade.

Para obter mais informações, confira Usar Assinaturas de Acesso Compartilhado do Armazenamento do Microsoft Azure para restringir o acesso a dados no HDInsight.

Usar criptografia de dados e replicação

Todos os dados gravados no Armazenamento do Azure são criptografados automaticamente usando a Criptografia do Serviço de Armazenamento (SSE). Os dados na conta de Armazenamento do Azure sempre são replicados para maior disponibilidade. Ao criar uma conta de armazenamento, deve selecionar uma das seguintes opções de replicação:

O armazenamento do Azure fornece LRS (armazenamento com redundância local), mas você também deve copiar dados críticos para outra conta de armazenamento do Azure em outra região com uma frequência alinhada às necessidades do plano de recuperação de desastre. Há uma variedade de métodos para copiar dados, incluindo o ADLCopy, o DistCp, o Azure PowerShell, ou o Azure Data Factory. Também é recomendável impor políticas de acesso para a conta de armazenamento do Azure para evitar a exclusão acidental.

Para obter mais informações, confira os seguintes artigos:

Anexar contas de Armazenamento do Azure adicionais ao cluster

Durante o processo de criação do HDInsight, uma conta de armazenamento do Azure, o Azure Data Lake Storage Gen1 ou o Azure Data Lake Storage Gen2 é escolhido como o sistema de arquivos padrão. Além dessa conta de armazenamento padrão, é possível adicionar mais contas de armazenamento da mesma assinatura do Azure ou de diferentes assinaturas do Azure durante o processo de criação de cluster ou após a criação de um cluster.

A conta de armazenamento extra pode ser adicionada das seguintes maneiras:

  • Site central Personalizado Avançado de Configuração do Ambari HDFS Adicione o Nome da Conta de armazenamento e digite Reiniciando os serviços
  • Usando a ação de Script passando o nome da conta de armazenamento e a chave

Observação

Em casos válidos de uso, os limites de Armazenamento do Azure podem ser aumentados por meio de uma solicitação feita aoSuporte do Azure.

Para saber mais, confira Adicionar outras contas de armazenamento ao HDInsight.

Próximas etapas

Leia o próximo artigo desta série: Melhores práticas de migração de dados para local usando a migração do Azure HDInsight Hadoop.