Migrar para os aglomerados Apache Hadoop para Azure HDInsight

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

Escolha o sistema de armazenamento certo para clusters HDInsight

A estrutura de diretório do Sistema de Ficheiros Apache Hadoop (HDFS) no local pode ser recriada no armazenamento de Azure Blob ou no Azure Data Lake Storage. Em seguida, pode eliminar com segurança os clusters HDInsight que são utilizados para a computação sem perder os dados do utilizador. Ambos os serviços podem ser utilizados tanto como o sistema de ficheiros predefinidos como um sistema de ficheiros adicional para um cluster HDInsight. O cluster HDInsight e a conta de armazenamento devem ser alojados na mesma região.

Armazenamento do Azure

Os clusters HDInsight podem utilizar o recipiente blob no Azure Storage como o sistema de ficheiros predefinido ou um sistema de ficheiros adicional. A conta de armazenamento standard tier é suportada para utilização com clusters HDInsight. O primeiro-ministro não é apoiado. O contentor de blobs predefinido armazena informações específicas do cluster, como o histórico de tarefas e os registos. A partilha de um recipiente de bolhas como o sistema de ficheiros predefinidos para vários clusters não é suportado.

As contas de armazenamento definidas no processo de criação e respetivas chaves são armazenadas nos %HADOOP_HOME%/conf/core-site.xml nós do cluster. Também podem ser acedidos na secção "Site core personalizado" na configuração HDFS na UI Ambari. A chave da conta de armazenamento é encriptada por padrão e um script de desencriptação personalizado é usado para desencriptar as chaves antes de ser passado para os daemons de Hadoop. Os trabalhos, incluindo Hive, MapReduce, Hadoop streaming, e Pig, têm consigo uma descrição das contas de armazenamento e metadados.

O Armazenamento Azure pode ser geo-replicado. Embora a geo-replicação dê recuperação geográfica e redundância de dados, uma falha na localização geo-replicada impacta severamente o desempenho, e pode incorrer em custos adicionais. A recomendação é escolher a geo-replicação com sensatez e apenas se o valor dos dados valer o custo adicional.

Um dos seguintes formatos pode ser usado para aceder a dados armazenados no Azure Storage:

Formato de Acesso a Dados Description
wasb:/// Aceder ao armazenamento predefinido utilizando uma comunicação não encriptada.
wasbs:/// Aceder ao armazenamento predefinido utilizando comunicação encriptada.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Utilizado quando comunica com uma conta de armazenamento não padrão. 

Os objetivos de escalabilidade das contas de armazenamento padrão listam os limites atuais nas contas de Armazenamento Azure. Se as necessidades da aplicação excederem os objetivos de escalabilidade de uma única conta de armazenamento, a aplicação pode ser construída para utilizar várias contas de armazenamento e, em seguida, objetos de dados de partição através dessas contas de armazenamento.

O Azure Storage Analytics fornece métricas para todos os serviços de armazenamento e o portal Azure pode ser configurado recolher métricas para serem visualizadas através de gráficos. Podem ser criados alertas para notificar quando foram atingidos limiares para métricas de recursos de armazenamento.

O Azure Storage oferece uma eliminação suave para objetos blob para ajudar a recuperar dados quando são acidentalmente modificados ou eliminados por uma aplicação ou outro utilizador de conta de armazenamento.

Pode criar instantâneos blob. Um instantâneo é uma versão só de leitura de uma bolha que é tirada em um ponto no tempo e fornece uma maneira de apoiar uma bolha. Uma vez criado um instantâneo, pode ser lido, copiado ou eliminado, mas não modificado.

Nota

Para versões mais antigas de Hadoop Distributions que não têm o certificado "wasbs", precisam de ser importadas para a loja de confiança Java.

Os seguintes métodos podem ser utilizados para importar certificados para a loja java trust:

Descarregue o Azure Blob TLS/SSL cert 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 a loja 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 cert adicionado está na loja de confiança

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

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

Armazenamento do Azure Data Lake Ger1

Azure Data Lake Storage Gen1 implementa o modelo de controlo de acesso ao estilo HDFS e POSIX. Proporciona integração de primeira classe com a Azure AD para controlo de acessos finos. Não há limites para o tamanho dos dados que pode armazenar, ou a sua capacidade de executar análises massivamente paralelas.

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

Armazenamento do Azure Data Lake Ger2

Azure Data Lake Storage Gen2 é a mais recente oferta de armazenamento. Unifica as capacidades centrais da primeira geração do Azure Data Lake Storage Gen1 com um ponto final do sistema de ficheiros compatível com Hadoop diretamente integrado no Azure Blob Storage. Esta melhoria combina a escala e os benefícios de custos do armazenamento de objetos com a fiabilidade e desempenho tipicamente associados apenas com sistemas de ficheiros no local.

O Azure Data Lake Storage Gen 2 é construído em cima do armazenamento Azure Blob e permite-lhe interagir com dados usando tanto o sistema de ficheiros como os paradigmas de armazenamento de objetos. As funcionalidades da Azure Data Lake Storage Gen1, tais como semântica do sistema de ficheiros, segurança de nível de ficheiros e escala são combinadas com armazenamento de baixo custo, tiered, alta disponibilidade/capacidade de recuperação de desastres, e um grande ecossistema SDK/ferramenta do armazenamento de Azure Blob. Na Data Lake Storage Gen2, todas as qualidades de armazenamento de objetos permanecem, adicionando as vantagens de uma interface de sistema de ficheiros otimizada para cargas de trabalho analíticas.

Uma característica fundamental do Data Lake Storage Gen2 é a adição de um espaço hierárquico de nomes ao serviço de armazenamento Blob, que organiza objetos/ficheiros numa hierarquia de diretórios para acesso a dados performantes. A estrutura hierárquica permite que operações como renomear ou eliminar um diretório sejam operações únicas de metadados atómicos no diretório, em vez de enumerar e processar todos os objetos que partilham o nome prefixo do diretório.

No passado, a análise baseada na nuvem teve de se comprometer em áreas de desempenho, gestão e segurança. As principais características do Azure Data Lake Storage (ADLS) Gen2 são as seguintes:

  • Acesso compatível com Hadoop: Azure Data Lake Storage Gen2 permite-lhe gerir e aceder a dados tal como faria com um Sistema de Ficheiros Distribuídos Hadoop (HDFS). O novo controlador ABFS está disponível em todos os ambientes Apache Hadoop que estão incluídos no Azure HDInsight. Este controlador permite-lhe aceder aos dados armazenados na Data Lake Storage Gen2.

  • Um superconjunto de permissões POSIX: O modelo de segurança para Data Lake Gen2 suporta totalmente permissões ACL e POSIX juntamente com alguma granularidade extra específica para Data Lake Storage Gen2. As definições podem ser configuradas através de ferramentas de administração ou através de estruturas como a Colmeia e a Spark.

  • Custo eficaz: Data Lake Storage Gen2 possui capacidade de armazenamento de baixo custo e transações. À medida que os dados transitam através do seu ciclo de vida completo, as taxas de faturação mudam para minimizar os custos através de funcionalidades incorporadas, como o ciclo de vida de armazenamento Azure Blob.

  • Trabalha com ferramentas de armazenamento Blob, estruturas e aplicações: Data Lake Storage Gen2 continua a trabalhar com uma grande variedade de ferramentas, estruturas e aplicações que existem hoje para armazenamento Blob.

  • Controlador otimizado: O controlador de ficheiros Azure Blob (ABFS) está otimizado especificamente para análise de big data. As APIs de REST correspondentes são emergidas através do ponto final dfs, dfs.core.windows.net.

Um dos seguintes formatos pode ser usado para aceder a dados que são armazenados na ADLS Gen2:

  • abfs:///: Aceda ao armazenamento predefinido do Data Lake para o cluster.
  • abfs://file_system@account_name.dfs.core.windows.net: Utilizado ao comunicar com um armazenamento não padrão do Lago de Dados.

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

Chaves de armazenamento Azure seguras dentro das instalações do cluster Hadoop

As teclas de Armazenamento Azure adicionadas aos ficheiros de configuração Hadoop, estabelecem conectividade entre as instalações hdfs e o armazenamento Azure Blob. Estas chaves podem ser protegidas encriptando-as com a estrutura do fornecedor de credenciais Hadoop. Uma vez encriptados, podem ser armazenados e acedidos de forma segura.

A 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 fornecedor acima ao core-site.xml ou à configuração Ambari no 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 do caminho do fornecedor também pode ser adicionada à linha de comando distcp em vez de armazenar a chave ao nível do cluster a nível core-site.xml seguintes:

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 de armazenamento Azure usando SAS

O HDInsight por padrão tem acesso total aos dados nas contas de Armazenamento Azure associadas ao cluster. As Assinaturas de Acesso Partilhado (SAS) no recipiente blob podem ser usadas para restringir o acesso aos dados, tais como fornecer aos utilizadores acesso apenas de leitura aos dados.

Usando o símbolo SAS criado com python

  1. Abra o ficheiro SASToken.py e altere os seguintes valores:

    Propriedade Token Description
    policy_name O nome a usar para a política armazenada para criar.
    storage_account_name O nome da sua conta de armazenamento.
    storage_account_key A chave para a conta de armazenamento.
    storage_container_name O recipiente na conta de armazenamento a que pretende restringir o acesso.
    example_file_path O caminho para um ficheiro que é enviado para o contentor.
  2. O ficheiro SASToken.py vem com as ContainerPermissions.READ + ContainerPermissions.LIST permissões e pode ser ajustado com base no caso de utilização.

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

  4. Apresenta o símbolo SAS semelhante ao seguinte texto quando o script termina: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Para limitar o acesso a um recipiente com Assinatura de Acesso Partilhado, adicione uma entrada personalizada à configuração do core-site para o cluster sob a propriedade Ambari HDFS Configs Advanced Custom Core-site Add.

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

    Chave: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netValor: A CHAVE SAS devolvida pela aplicação Python do passo 4 acima.

  7. Clique no botão Adicionar para guardar esta tecla e valor e, em seguida, clique no botão Guardar para guardar as alterações de configuração. Quando solicitado, adicione uma descrição da alteração ("adicionar acesso ao armazenamento SAS" por exemplo) e, em seguida, clique em Guardar.

  8. Na UI web Ambari, selecione HDFS da lista à esquerda e, em seguida, selecione Restart All Affected from the Service Actions drop down list à direita. Quando solicitado, selecione ConfirmE Reinício Tudo.

  9. Repita este processo para MapReduce2 e YARN.

Há três coisas importantes a lembrar sobre o uso de sas tokens em Azure:

  1. Quando os tokens SAS são criados com permissões "READ + LIST", os utilizadores que acedam ao recipiente Blob com esse token SAS não poderão "escrever e apagar" dados. Os utilizadores que acedam ao recipiente Blob com esse token SAS e tentem uma operação de escrita ou eliminaçã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 escrever para um \_COPYING\_ ficheiro e, em seguida, tentar renomear o ficheiro. Esta operação HDFS mapeia para um copy+delete para WASB. Como a DELETE permissão não foi dada, o "put" falharia. A \_COPYING\_ operação é uma funcionalidade Hadoop destinada a fornecer algum controlo de concordância. Atualmente não há forma de restringir apenas a operação "DELETE" sem afetar também as operações "WRITE".

  3. Infelizmente, o fornecedor de credenciais de hadoop e o fornecedor de chaves de desencriptação (ShellDecryptionKeyProvider) atualmente não funcionam com os tokens SAS e, por isso, atualmente não pode ser protegido da visibilidade.

Para obter mais informações, consulte Use Azure Storage Shared Access Signatures para restringir o acesso aos dados em HDInsight.

Utilizar encriptação e replicação de dados

Todos os dados escritos no Azure Storage são automaticamente encriptados utilizando a Encriptação do Serviço de Armazenamento (SSE). Os dados na conta de Armazenamento Azure são sempre replicados para uma elevada disponibilidade. Ao criar uma conta de armazenamento, pode escolher uma das seguintes opções de replicação:

O Azure Storage fornece armazenamento localmente redundante (LRS), mas também deve copiar dados críticos para outra conta de Armazenamento Azure noutra região com uma frequência alinhada com as necessidades do plano de recuperação de desastres. Existem diferentes métodos para copiar dados, incluindo ADLCopy, DistCp, Azure PowerShell ou Azure Data Factory. Também é recomendado para impor políticas de acesso para conta de armazenamento Azure para evitar a eliminação acidental.

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

Anexar contas adicionais de armazenamento Azure ao cluster

Durante o processo de criação de HDInsight, uma conta de armazenamento Azure, Azure Data Lake Storage Gen1 ou Azure Data Lake Storage Gen2 é escolhida como o sistema de ficheiros padrão. Além desta conta de armazenamento padrão, as contas de armazenamento adicionais podem ser adicionadas a partir da mesma subscrição Azure ou diferentes subscrições 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 formas:

  • Ambari HDFS Config Avançado Site de núcleo personalizado Adicionar o nome da conta de armazenamento e a chave Reiniciando os serviços
  • Usando a ação do Script passando o nome da conta de armazenamento e a chave

Nota

Em casos de utilização válidos, os limites do armazenamento Azure podem ser aumentados através de um pedido feito ao Suporte Azure.

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

Passos seguintes

Leia o artigo seguinte nesta série: As melhores práticas de migração de dados para a migração de Azure HDInsight Hadoop.