Partilhar via


Migrar clusters Apache Hadoop locais para o Azure HDInsight

Este artigo fornece recomendações para armazenamento de dados em sistemas Azure HDInsight. Faz parte de uma série que fornece práticas recomendadas para ajudar na migração de sistemas Apache Hadoop locais para o Azure HDInsight.

Escolha o sistema de armazenamento certo para clusters HDInsight

A estrutura de diretórios do Apache Hadoop File System (HDFS) local pode ser recriada no armazenamento de Blob do Azure ou no Armazenamento do Azure Data Lake. Em seguida, você pode excluir com segurança os clusters HDInsight usados para computação 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 adicional para um cluster HDInsight. O cluster HDInsight e a conta de armazenamento devem estar hospedados na mesma região.

Armazenamento do Azure

Os clusters HDInsight podem usar o contêiner de blob no Armazenamento do Azure como o sistema de arquivos padrão ou um sistema de arquivos adicional. A conta de armazenamento de nível Standard é suportada para uso com clusters HDInsight. A camada Premier não é suportada. O contentor de blobs predefinido armazena informações específicas do cluster, como o histórico de tarefas e os registos. 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 respetivas chaves são armazenadas nos %HADOOP_HOME%/conf/core-site.xml nós do cluster. Eles também podem ser acessados na seção "Site principal personalizado" na configuração do HDFS na interface do usuário do Ambari. A chave da conta de armazenamento é criptografada por padrão e um script de descriptografia personalizado é usado para descriptografar as chaves antes de serem passadas para daemons Hadoop. Os trabalhos, incluindo Hive, MapReduce, streaming Hadoop e Pig, carregam uma descrição de contas de armazenamento e metadados com eles.

O Armazenamento do Azure pode ser replicado geograficamente. Embora a replicação geográfica proporcione recuperação geográfica e redundância de dados, um failover para o local replicado geograficamente afeta gravemente o desempenho e pode incorrer em custos adicionais. A recomendação é escolher a replicação geográfica com sabedoria e somente se o valor dos dados valer o custo adicional.

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

Formato de acesso aos dados Description
wasb:/// Acesse o armazenamento padrão usando comunicação não criptografada.
wasbs:/// Acesse 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. 

Destinos de escalabilidade para contas de armazenamento padrão lista os limites atuais nas contas de Armazenamento do Azure. Se as necessidades do aplicativo excederem os destinos de escalabilidade de uma única conta de armazenamento, o aplicativo poderá ser criado para usar várias contas de armazenamento e, em seguida, particionar objetos de dados entre essas contas de armazenamento.

O Azure Storage Analytics fornece 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. Os 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 suave para objetos de blob para ajudar a recuperar dados quando eles são acidentalmente modificados ou excluídos por um aplicativo ou outro usuário de conta de armazenamento.

Você pode criar instantâneos de blob. Um instantâneo é uma versão somente leitura de um blob que é tirado em um determinado momento e fornece uma maneira de fazer backup de um blob. Depois que um instantâneo é criado, ele pode ser lido, copiado ou excluído, mas não modificado.

Nota

Para versões mais antigas de distribuições Hadoop locais que não têm o certificado "wasbs", elas precisam ser importadas para o armazenamento confiável Java.

Os seguintes métodos podem ser usados para importar certificados para o armazenamento confiável Java:

Transferir o certificado TLS/SSL de Blob do Azure para um ficheiro

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 armazenamento confiável 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 armazenamento confiável

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

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

Azure Data Lake Storage Gen2

O Azure Data Lake Storage Gen2 é a oferta de armazenamento mais recente. Ele unifica os principais recursos da primeira geração do Azure Data Lake Storage Gen1 com um ponto de extremidade do sistema de arquivos compatível com Hadoop diretamente integrado ao Armazenamento de Blobs do Azure. Esse aprimoramento combina os benefícios de escala e custo do armazenamento de objetos com a confiabilidade e o desempenho normalmente associados apenas a sistemas de arquivos locais.

O Azure Data Lake Storage Gen 2 foi criado com base no armazenamento de Blobs do Azure e permite que você interaja com dados usando paradigmas de sistema de arquivos e armazenamento de objetos. Os recursos do Azure Data Lake Storage Gen1, como semântica do sistema de arquivos, segurança em nível de arquivo e escala, são combinados com armazenamento hierárquico de baixo custo, recursos de alta disponibilidade/recuperação de desastres e um grande ecossistema de SDK/ferramentas do armazenamento de Blob do Azure. No Data Lake Storage Gen2, todas as qualidades do armazenamento de objetos permanecem, adicionando 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 de 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 de metadados atômicos únicos 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 de comprometer as áreas de desempenho, gestão e segurança. Os principais recursos do Azure Data Lake Storage (ADLS) Gen2 são os seguintes:

  • Acesso compatível com Hadoop: o Azure Data Lake Storage Gen2 permite gerenciar e acessar dados da mesma forma que faria com um HDFS (Hadoop Distributed File System). O novo driver ABFS está disponível em todos os ambientes Apache Hadoop incluídos no Azure HDInsight. Este driver permite que você acesse dados armazenados no Data Lake Storage Gen2.

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

  • Custo-benefício: o Data Lake Storage Gen2 apresenta capacidade de armazenamento e transações de baixo custo. À medida que os dados transitam pelo seu ciclo de vida completo, as taxas de cobrança mudam para minimizar os custos por meio de recursos internos, como o ciclo de vida do armazenamento de Blob do Azure.

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

  • Driver otimizado: o driver do Sistema de Arquivos de Blob do Azure (ABFS) é otimizado especificamente para análise de big data. As APIs REST correspondentes são exibidas através do dfs ponto de extremidade, dfs.core.windows.net.

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

  • abfs:///: Acesse o armazenamento Data Lake padrão para o cluster.
  • abfs://file_system@account_name.dfs.core.windows.net: Usado ao se comunicar com um armazenamento Data Lake não padrão.

Nota

Não há suporte para a atualização da conta de armazenamento primária ou secundária de um cluster em execução com os recursos do Azure Data Lake Storage Gen2. Para alterar o tipo de armazenamento de um cluster HDInsight existente para 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, consulte os seguintes artigos:

Proteja as chaves de armazenamento do Azure na configuração de cluster Hadoop local

As chaves de Armazenamento do Azure que são adicionadas aos arquivos de configuração do Hadoop estabelecem a conectividade entre o HDFS local e o armazenamento de Blob do Azure. Essas chaves podem ser protegidas criptografando-as com a estrutura do provedor de credenciais Hadoop. Uma vez encriptados, podem ser armazenados e acedidos de forma segura.

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 em core-site 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>

Nota

A propriedade caminho do provedor também pode ser adicionada à linha de comando distcp em vez de armazenar a chave no nível do cluster 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 aos dados do Armazenamento do Azure usando o SAS

Por padrão, o HDInsight tem acesso total aos dados nas contas de Armazenamento do Azure associadas ao cluster. As Assinaturas de Acesso Compartilhado (SAS) no contêiner de blob podem ser usadas 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 seguintes valores:

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

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

  4. Ele exibe o token SAS semelhante ao seguinte texto quando o script é 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 principal para o cluster em Ambari HDFS Configs Advanced Custom core-site Add propriedade.

  6. Use os seguintes valores para os campos Chave e Valor :

    Chave: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netValor: A CHAVE SAS retornada pelo aplicativo Python DA etapa 4 acima.

  7. Clique no botão Adicionar para salvar essa chave e valor e, em seguida, clique no botão Salvar para salvar as alterações de configuração. Quando solicitado, adicione uma descrição da alteração ("adicionando acesso ao 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 este processo para MapReduce2 e YARN.

Há três coisas importantes a serem lembradas sobre o uso de Tokens SAS no Azure:

  1. Quando os 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 Blob com esse token SAS e tentarem 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 READ + LIST + WRITE permissões (para restringir DELETE apenas), comandos como hadoop fs -put primeiro gravam em um \_COPYING\_ arquivo e, em seguida, tentam renomear o arquivo. Esta operação HDFS é mapeada para um copy+delete para WASB. Como a DELETE permissão não foi fornecida, o "put" falharia. A \_COPYING\_ operação é um recurso do Hadoop destinado a fornecer algum controle de simultaneidade. Atualmente, não há como restringir apenas a operação "DELETE" sem afetar também as operações "WRITE".

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

Para obter mais informações, consulte Usar assinaturas de acesso compartilhado do Armazenamento do Azure para restringir o acesso a dados no HDInsight.

Usar criptografia e replicação de dados

Todos os dados gravados no Armazenamento do Azure são automaticamente criptografados usando a Criptografia do Serviço de Armazenamento (SSE). Os dados na conta de Armazenamento do Azure são sempre replicados para alta disponibilidade. Ao criar uma conta de armazenamento, você pode escolher 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 do Armazenamento do Azure em outra região com uma frequência alinhada às necessidades do plano de recuperação de desastres. Há diferentes métodos para copiar dados, incluindo ADLCopy, DistCp, Azure PowerShell ou Azure Data Factory. Também é recomendável aplicar políticas de acesso para a conta de Armazenamento do Azure para evitar a exclusão acidental.

Para obter mais informações, consulte 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, Azure Data Lake Storage Gen1 ou Azure Data Lake Storage Gen2 é escolhida como o sistema de arquivos padrão. Além dessa conta de armazenamento padrão, contas de armazenamento adicionais podem ser adicionadas da mesma assinatura do Azure ou de diferentes assinaturas do Azure durante o processo de criação do cluster ou após a criação de um cluster.

Uma conta de armazenamento adicional pode ser adicionada de uma das seguintes maneiras:

  • Ambari HDFS Config Advanced Core-site personalizado Adicionar o armazenamento Nome da conta e chave Reiniciar os serviços
  • Usando a ação Script passando o nome e a chave da conta de armazenamento

Nota

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

Para obter mais informações, veja Adicionar mais contas de armazenamento ao HDInsight.

Próximos passos

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