Editar

Compartilhar via

Migração do Sistema de Arquivos Distribuído do Apache Hadoop (HDFS) para o Azure

Azure HDInsight
Azure Cosmos DB
Armazenamento do Azure Data Lake
Azure Synapse Analytics
Stream Analytics do Azure

O Sistema de Arquivos Distribuído do Hadoop (HDFS) é um sistema de arquivos distribuído baseado em Java que oferece armazenamento de dados confiável e escalável, capaz de abranger grandes clusters de servidores de mercadorias. Este artigo oferece uma visão geral sobre o HDFS e um guia para migrá-lo para o Azure.

Apache®, Apache Spark®, Apache Hadoop®, Apache Hive e o logotipo da chama são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países O uso desta marca não implica aprovação por parte da Apache Software Foundation.

Arquitetura e componentes do HDFS

O HDFS tem um design do tipo primário/secundário. No diagrama a seguir, o NameNode é o primário e os DataNodes são os secundários.

Diagrama que mostra os componentes do HDFS: cliente, NameNode e DataNodes.

  • O NameNode gerencia o acesso aos arquivos e ao namespace do sistema de arquivos, que é uma hierarquia de diretórios.
    • Os arquivos e os diretórios são nós no NameNode. Eles têm atributos, como permissões, tempos de modificação e acesso e cotas de tamanho para namespace e espaço em disco.
    • Um arquivo consiste em vários blocos. O tamanho de bloco padrão é de 128 MB. É possível definir outro tamanho de bloco para um cluster ao modificar o arquivo hdfs-site.xml.
    • Cada bloco do arquivo é replicado de maneira independente em vários DataNodes. O valor padrão do fator de replicação é três, mas cada cluster pode ter outro valor próprio. O fator de replicação pode ser modificado a qualquer momento. Alterações causam rebalanceamento do cluster.
    • O NameNode mantém a árvore de namespaces e o mapeamento entre os blocos de arquivos e os DataNodes (os locais físicos dos dados dos arquivos).
    • Quando um cliente do HDFS lê um arquivo:
      1. Ele estabelece contato com o NameNode solicitando os locais dos blocos de dados do arquivo.
      2. Ele lê o conteúdo dos blocos do DataNode mais próximo.
    • O HDFS mantém o namespace inteiro na memória RAM.
  • Os DataNodes são nós secundários que realizam operações de leitura e gravação no sistema de arquivos e realizam operações de blocos, como criação, replicação e exclusão.
    • Um DataNode tem arquivos de metadados que contêm as somas de verificação dos arquivos armazenados. Para cada réplica de bloco que é hospedada por um DataNode, há um arquivo de metadados correspondente que contém metadados sobre a réplica, incluindo suas informações de soma de verificação. O arquivo de metadados tem o mesmo nome de base do arquivo de bloco, com a extensão .meta.
    • O DataNode tem o arquivo de dados que contém os dados do bloco.
    • Quando um DataNode lê um arquivo, ele busca os locais dos blocos e os locais das réplicas no NameNode e tenta realizar a leitura do local mais próximo.
    • Um cluster do HDFS pode ter milhares de DataNodes e dezenas de milhares de clientes HDFS. Cada DataNode consegue executar diversas tarefas de aplicativo simultaneamente.
    • Quando um bloco é gravado em DataNodes, é realizado um cálculo de soma de verificação de ponta a ponta como parte do pipeline de gravação do HDFS.
  • O cliente HDFS é o cliente utilizado pelos aplicativos para acessar os arquivos.
    • É uma biblioteca de códigos que exporta a interface do sistema de arquivos HDFS.
    • Ele é compatível com operações de leitura, gravação e exclusão de arquivos, bem como operações de criação e exclusão de diretórios.
    • Ele realiza as etapas a seguir quando um aplicativo lê um arquivo:
      • Ele obtém do NameNode uma lista de DataNodes e locais que contêm os blocos do arquivo. Essa lista inclui as réplicas.
      • Ele utiliza a lista para obter os blocos solicitados dos DataNodes.
    • O HDFS oferece uma API que expõe os locais dos blocos de arquivos. Isso possibilita que alguns aplicativos, como a estrutura MapReduce, programem tarefas para execução onde os dados estão, com o intuito de otimizar o desempenho de leitura.

Mapa de recursos

O driver do Azure Blob File System (ABFS) oferece uma interface que possibilita que o Azure Data Lake Storage opere como um sistema de arquivos HDFS. A tabela a seguir compara a funcionalidade básica do driver do ABFS e do Data Lake Storage com a funcionalidade do HDFS.

Recurso O driver do ABFS e o Data Lake Storage HDFS
Acesso compatível com o Hadoop É possível gerenciar e acessar os dados exatamente como faria no HDFS. O driver do ABFS está disponível em todos os ambientes do Apache Hadoop, incluindo o Azure HDInsight e o Azure Databricks. Um cluster do MapR consegue acessar um cluster do HDFS externo usando os protocolos hdfs:// ou webhdfs://.
Permissões de POSIX O modelo de segurança do Data Lake Gen2 oferece suporte a permissões de lista de controle de acesso (ACL) e POSIX com alguma granularidade adicional específica para o Data Lake Storage Gen2. As configurações podem ser definidas usando ferramentas administrativas ou estruturas, como o Apache Hive e o Apache Spark. Os trabalhos que requerem determinados recursos do sistema de arquivos, como renomeações de diretório estritamente atômica, permissões refinadas do HDFS ou symlinks do HDFS só funcionam no HDFS.
Custo-benefício O Data Lake Storage oferece transações e capacidade de armazenamento de baixo custo. Os ciclos de vida do Azure Blob Storage ajudam a reduzir os custos, ajustando as taxas de cobrança conforme a movimentação de dados no ciclo de vida.
Driver otimizado O driver do ABFS é otimizado para análise de Big Data. As APIs REST correspondentes são fornecidas por meio do ponto de extremidade do Sistema de Arquivos Distribuído (DFS), dfs.core.windows.net.
Tamanho do bloco Blocks é equivalente a uma única invocação da API Append (a API Append cria um bloco) e tem limite de 100 MB por invocação. No entanto, o padrão de gravação é compatível com múltiplas chamadas de Append por arquivo (mesmo em paralelo), até o máximo de 50.000, e com a chamada de Flush (equivalente a PutBlockList). É assim que o tamanho máximo dos arquivos de 4,75 TB é atingido. O HDFS armazena os dados em um bloco de dados. Você define o tamanho do bloco ajustando o valor no arquivo hdfs-site.xml que está no diretório do Hadoop. O tamanho padrão é 128 MB.
Padrão ACLS Os arquivos não têm ACLs padrão e não estão habilitados por padrão. Os arquivos não têm ACLs padrão.
Arquivos binários Os arquivos binários podem ser migrados para o Azure Blob Storage em um namespace não hierárquico. Objetos no Armazenamento de Blobs estão acessíveis por meio da API REST do Armazenamento do Azure, do Azure PowerShell, da CLI do Azure ou em uma biblioteca de clientes do Armazenamento do Azure. As bibliotecas de clientes estão disponíveis para várias linguagens, incluindo .NET, Java, Node.js, Python, Go, PHP e Ruby. O Hadoop possibilita realizar leitura e gravação de arquivos binários. O SequenceFile é um arquivo simples que consiste em uma chave binária e pares de valores. O SequenceFile oferece classes Writer, Reader e Sorter para gravação, leitura e classificação. Converta o arquivo de imagem ou de vídeo em um SequenceFile e armazene-o no HDFS. Depois, utilize os métodos SequenceFileReader e Writer do HDFS ou o comando put: bin/hadoop fs -put /src_image_file /dst_image_file
Herança de permissões O Data Lake Storage utiliza o modelo no estilo POSIX e se comporta igual ao Hadoop quando ACLs controlam o acesso a um objeto. Para saber mais, confira ACLs (listas de controle de acesso) no Data Lake Storage Gen2. As permissões para um item são armazenadas no próprio item, não herdadas depois da existência do item. As permissões serão herdadas somente se as permissões padrão forem definidas no item pai antes da criação do item filho.
Replicação de dados Os dados em uma conta do Armazenamento do Azure são replicados três vezes na região primária. O armazenamento com redundância de zona é a opção de replicação recomendada. Ele faz replicação de maneira síncrona em três zonas de disponibilidade do Azure na região primária. O fator de replicação padrão dos arquivos é três. Para arquivos críticos ou arquivos acessados com frequência, fatores de replicação mais altos melhoram a tolerância a falhas e aumentam a largura de banda de leitura.
Sticky bit No contexto do Data Lake Storage, é improvável que o sticky bit seja necessário. Em resumo, se o sticky bit estiver habilitado em um diretório, somente o usuário proprietário de um item filho poderá excluir esse item. O sticky bit não é mostrado no Portal do Azure. O sticky bit pode ser definido em diretórios com o intuito de impedir que qualquer usuário, exceto o superusuário, o proprietário do diretório ou o proprietário do arquivo, consiga excluir ou mover arquivos dentro do diretório. A definição do sticky bit para um arquivo não tem efeito.

Desafios comuns enfrentados por um HDFS local

Diagrama que mostra os desafios comuns ao implementar o HDFS.

A quantidade de desafios apresentados por uma implementação local do HDFS pode ser um motivo para considerar as vantagens da migração para a nuvem:

  • Atualizações frequentes da versão do HDFS.
  • Quantidades cada vez maiores de dados.
  • Muitos arquivos pequenos que aumentam a pressão no NameNode, que controla os metadados de todos os arquivos no cluster. Quanto mais arquivos, maior é o tráfego de leitura no NameNode quando os clientes leem os arquivos e maior é a quantidade de chamadas quando os clientes estão gravando.
  • Não é possível dividir os clusters do HDFS por caso de uso ou organização para situações em que várias equipes da organização exigem conjuntos de dados diferentes. O resultado é o aumento da duplicação dos dados, o que também aumenta os custos e reduz a eficiência.
  • O NameNode pode se tornar um gargalo de desempenho quando o cluster do HDFS passa por extensão ou ajuste vertical da escala.
  • Antes do Hadoop 2.0, todas as solicitações de clientes feitas para um cluster do HDFS passavam pelo NameNode primeiro, porque todos os metadados estavam armazenados em um único NameNode. Esse design faz com que o NameNode seja um possível gargalo e um ponto único de falha. Se o NameNode falhar, o cluster ficará indisponível.

Considerações sobre migração

Veja a seguir alguns aspectos importantes que devem ser considerados ao planejar uma migração de HDFS para o Data Lake Storage:

  • Considere agregar os dados que estão em arquivos pequenos em um único arquivo no Data Lake Storage.
  • Liste todas as estruturas de diretório no HDFS e replique um zoneamento semelhante no Data Lake Storage. É possível obter a estrutura de diretórios do HDFS utilizando o comando hdfs -ls.
  • Liste todas as funções definidas no cluster do HDFS para que consiga replicá-las no ambiente de destino.
  • Observe a política de ciclo de vida dos dados dos arquivos que estão armazenados no HDFS.
  • Lembre-se de que alguns recursos do sistema HDFS estão indisponíveis no Data Lake Storage, incluindo:
    • A renomeação estritamente atômica de diretórios
    • As permissões refinadas do HDFS
    • Os symlinks do HDFS
  • O Armazenamento do Azure oferece replicação com redundância geográfica, mas nem sempre é aconselhável utilizá-la. Ela oferece redundância de dados e recuperação geográfica, mas um failover para um local mais distante pode prejudicar drasticamente o desempenho e gerar custos adicionais. Avalie se a maior disponibilidade dos dados vale a pena.
  • Se os arquivos tiverem nomes com prefixos iguais, o HDFS tratará eles como uma única partição. Assim, se você utilizar o Azure Data Factory, todas as unidades de movimentação de dados (DMUs) gravarão em uma única partição.

Diagrama do fluxo de processo para partições e paralelismo de trabalho.

  • Se você utilizar o Data Factory para transferência de dados, verifique cada diretório, excluindo os instantâneos, e confira o tamanho do diretório utilizando o comando hdfs du. Se houver diversos subdiretórios e grandes quantidades de dados, inicialize múltiplas atividades Copy no Data Factory. Por exemplo, utilize uma atividade Copy por subdiretório em vez de transferir o diretório inteiro utilizando uma única atividade Copy.

Diagrama do fluxo do processo para o número de atividades de cópia.

  • As plataformas de dados costumam ser utilizadas para retenção de longo prazo de informações que podem ter sido removidas dos sistemas de registro. Planeje-se para criar backups em fita ou instantâneos dos dados arquivados. Considere a replicação das informações para um local de recuperação. Geralmente, os dados são arquivados para fins de conformidade ou de dados históricos. Antes de arquivar dados, é necessário ter um motivo claro para mantê-los. Decida também quando os dados arquivados deverão ser removidos e defina processos para removê-los quando esse momento chegar.
  • O baixo custo da camada de acesso aos arquivos do Data Lake Storage faz dela uma opção atraente para o arquivamento de dados. Para saber mais, consulte Camada de acesso aos arquivos.
  • Quando um cliente HDFS utiliza o driver do ABFS para acessar o Blob Storage, pode haver instâncias em que o método utilizado pelo cliente não é compatível e o AzureNativeFileSystem gera uma UnsupportedOperationException. Por exemplo, append(Path f, int bufferSize, Progressable progress) ainda não é compatível. Para conferir os problemas relacionados ao driver do ABFS, consulte Hadoop features and fixes.
  • Existe uma versão do driver do ABFS com backport para uso em clusters mais antigos do Hadoop. Para saber mais, consulte Backport for ABFS Driver.
  • Em um ambiente de sistema de rede virtual do Azure, a ferramenta DistCp não oferece suporte ao emparelhamento privado do Azure ExpressRoute com um ponto de extremidade de rede virtual do Armazenamento do Azure. Para saber mais, consulte Usar o Azure Data Factory para migrar dados de um cluster Hadoop local para o Armazenamento do Azure.

Abordagem da migração

A abordagem usual de migração do HDFS para o Data Lake Storage utiliza as seguintes etapas:

Diagrama que mostra as seis etapas para uma migração do HDFS para o Data Lake Storage.

Avaliação do HDFS

Os scripts de avaliação local oferecem informações que ajudam a determinar quais cargas de trabalho podem ser migradas para o Azure e se os dados devem ser migrados de uma só vez ou em partes. Algumas ferramentas de terceiros, como a Unravel, podem disponibilizar métricas e oferecer suporte à autoavaliação do HDFS local. Alguns fatores importantes que devem ser considerados durante o planejamento incluem:

  • Volume de dados
  • Impacto de negócios
  • Propriedade dos dados
  • Complexidade do processamento
  • Complexidade de extração, transferência e carregamento (ETL)
  • Informações de identificação pessoal (PII) e outros dados confidenciais

Com base nesses fatores, é possível elaborar um plano de migração dos dados para o Azure que minimize o tempo de inatividade e a interrupção dos negócios. Talvez os dados confidenciais possam permanecer no local. Os dados históricos podem ser migrados e testados antes da migração de uma carga incremental.

O fluxo de decisões a seguir oferece ajuda para decidir os critérios e comandos que serão executados para obter as informações corretas.

Diagrama que mostra um fluxograma de decisão para estratégia e planejamento de migração de dados.

Os comandos do HDFS para obtenção das métricas de avaliação do HDFS incluem:

  • Listar todos os diretórios de um local:

    hdfs dfs -ls books

  • Listar de maneira recursiva todos os arquivos de um local:

    hdfs dfs -ls -R books

  • Obter o tamanho do diretório e dos arquivos do HDFS:

    hadoop fs -du -s -h command

    O comando hadoop fs -du -s -h exibe o tamanho dos arquivos e do diretório do HDFS. Como o sistema de arquivos do Hadoop replica todos os arquivos, o tamanho físico real do arquivo é o número de réplicas multiplicado pelo tamanho de uma réplica.

  • Determine se as ACLs estão ativadas. Para fazer isso, obtenha o valor de dfs.namenode.acls.enabled em Hdfs-site.xml. Conhecer esse valor ajuda a planejar o controle de acesso na conta de Armazenamento do Azure. Para saber mais sobre o conteúdo desse arquivo, consulte as configurações de arquivo padrão.

Algumas ferramentas de parceiros, como a Unravel, oferecem relatórios de avaliação para o planejamento da migração dos dados. As ferramentas devem ser executadas no ambiente local ou se conectar ao cluster do Hadoop para a geração de relatórios.

  • O seguinte relatório da Unravel oferece estatísticas (por diretório) sobre os pequenos arquivos no diretório:

    Captura de tela de um relatório de arquivos pequenos.

  • O seguinte relatório oferece estatísticas (por diretório) sobre os arquivos do diretório:

    Captura de tela de um relatório de todos os arquivos.

Transferir dados

Os dados precisam ser transferidos para o Azure, conforme descrito em seu plano de migração. A transferência exige estas atividades:

  1. Identifique todos os pontos de ingestão.

    Se não for possível levar os dados diretamente para a nuvem por questões de requisitos de segurança, o ambiente local poderá servir como uma zona de destino intermediária. Você pode criar pipelines no Data Factory para extração dos dados de sistemas locais ou utilizar scripts AZCopy para enviar os dados à conta de Armazenamento do Azure.

    Fontes de ingestão comuns incluem:

    1. Servidor SFTP
    2. Ingestão de arquivos
    3. Ingestor de bancos de dados
    4. Despejo de bancos de dados
    5. captura de dados de alterações
    6. Ingestão de streaming

  2. Planeje o número de contas de armazenamento necessárias.:

    Para planejar o número de contas de armazenamento necessárias, compreenda a carga total no HDFS atual. Você pode utilizar a métrica TotalLoad, que é o número atual de acessos simultâneos aos arquivos em todos os DataNodes. Defina o limite da conta de armazenamento na região de acordo com o valor de TotalLoad local e com o crescimento esperado no Azure. Caso seja possível aumentar o limite, uma única conta de armazenamento poderá ser suficiente. No entanto, para um data lake, é melhor manter uma conta de armazenamento para cada zona, em preparação para o crescimento futuro do volume de dados. Outros motivos para isso incluem:

    • Controle de acesso
    • Requisitos de resiliência
    • Requisitos de replicação de dados
    • Exposição dos dados para uso público

    Ao habilitar um namespace hierárquico em uma conta de armazenamento, você não poderá revertê-lo de volta para um namespace simples. Algumas cargas de trabalho, como backups e arquivos de imagem de VM, não se beneficiam dos namespaces hierárquicos.

    Diagrama que mostra um fluxograma de decisão para determinar o número de contas de armazenamento.

    Para saber mais sobre como proteger o tráfego entre sua rede virtual e a conta de armazenamento através de um link privado, consulte Proteger contas de armazenamento.

    Para saber mais sobre os limites padrão das contas de Armazenamento do Azure, consulte Metas de escalabilidade e desempenho das contas de Armazenamento Standard. O limite de entrada se aplica aos dados que são enviados a uma conta de armazenamento. O limite de saída se aplica aos dados que são recebidos de uma conta de armazenamento.

  3. Decida quanto aos requisitos de disponibilidade.

    É possível especificar o fator de replicação para plataformas do Hadoop no arquivo hdfs-site.xml ou especificá-lo por arquivo. Você pode configurar a replicação no Data Lake Storage de acordo com a natureza dos dados. Se um aplicativo exigir reconstrução dos dados em caso de perda, o armazenamento com redundância de zona (ZRS) será uma opção. No ZRS do Data Lake Storage, os dados são copiados de forma síncrona em três zonas de disponibilidade na região primária. Para aplicativos que exigem alta disponibilidade e que podem ser executados em mais de uma região, copie os dados para uma região secundária. Isso caracteriza uma replicação com redundância geográfica.

    Diagrama que mostra um gráfico de decisão para requisitos de replicação.

  4. Verifique se há blocos corrompidos ou ausentes.

    Confira o relatório do scanner de blocos para verificar se não há nenhum bloco corrompido ou ausente. Se houver algum, aguarde a conclusão da restauração do arquivo antes de transferi-lo.

    Diagrama que mostra um gráfico de decisão para lidar com blocos corrompidos ou ausentes.

  5. Verifique se a NFS está habilitada.

    Consulte o arquivo core-site.xml para verificar se o NFS está ativado na plataforma local do Hadoop. Ele tem as propriedades nfsserver.groups e nfsserver.hosts.

    O recurso NFS 3.0 está em versão prévia no Data Lake Storage. Alguns recursos podem não ser compatíveis ainda. Para saber mais, consulte Suporte ao protocolo de NFS (Sistema de Arquivos de Rede) 3.0 para o Armazenamento de Blobs do Azure.

    Diagrama que mostra um fluxograma de decisão para habilitar o NFS.

  6. Verifique os formatos de arquivo do Hadoop.

    Utilize o seguinte fluxograma de decisões para obter orientações a respeito de como lidar com os formatos de arquivo. Diagrama que mostra um fluxograma de decisão para lidar com os vários tipos de arquivo.

  7. Escolha uma solução do Azure para a transferência de dados.

    A transferência de dados pode acontecer on-line, através da rede, ou off-line, utilizando dispositivos físicos. O método utilizado vai depender do volume de dados, da largura de banda da rede e da frequência de transferência de dados. Dados históricos só precisam ser transferidos uma vez. Cargas incrementais exigem transferências contínuas e repetidas.

    Os métodos de transferência de dados são discutidos na lista a seguir. Para saber mais sobre como escolher tipos de transferência de dados, consulte Escolha uma solução do Azure para transferência de dados.

    1. AzCopy

      O AzCopy é um utilitário de linha de comando capaz de copiar arquivos do HDFS para uma conta de armazenamento. Essa é uma opção para transferências com alta largura de banda (acima de 1 GBPS).

      Veja a seguir um exemplo de comando para migrar um diretório do HDFS:

      *azcopy copy "C:\local\path" "https://account.blob.core.windows.net/mycontainer1/?sv=2018-03-28&ss=bjqt&srt=sco&sp=rwddgcup&se=2019-05-01T05:01:17Z&st=2019-04-30T21:01:17Z&spr=https&sig=MGCXiyEzbtttkr3ewJIh2AR8KrghSy1DGM9ovN734bQF4%3D" --recursive=true*

    2. DistCp

      DistCp é um utilitário de linha de comando no Hadoop, capaz de realizar operações de cópia distribuída em um cluster do Hadoop. DistCp cria diversas tarefas de mapeamento no cluster do Hadoop a fim de copiar os dados da origem para o coletor. Essa abordagem push é boa quando a rede tem largura de banda adequada e não exige a provisão de recursos de computação adicionais para a migração dos dados. No entanto, se o cluster de origem do HDFS já estiver ficando sem capacidade e não for possível adicionar computação, considere utilizar o Data Factory com a atividade Copy de DistCp para extrair em vez de enviar os arquivos.

      *hadoop distcp -D fs.azure.account.key.<account name>.blob.core.windows.net=<Key> wasb://<container>@<account>.blob.core.windows.net<path to wasb file> hdfs://<hdfs path>*

    3. Azure Data Box para grandes transferências de dados

      O Azure Data Box é um dispositivo físico oferecido pela Microsoft. Ele oferece transferências de dados em grande escala e é uma opção para transferência off-line quando a largura de banda da rede é limitada e o volume de dados é alto (por exemplo, quando o volume está na faixa de alguns terabytes a um petabyte).

      Conecte um Data Box à LAN a fim de transferir dados para ele. Depois, envie-o de volta para o datacenter da Microsoft, onde engenheiros da Microsoft vão transferir os dados para a conta de armazenamento configurada.

      Existem diversas opções de Data Box que variam em termos do volume de dados que é capaz de manipular. Para saber mais sobre a abordagem de Data Box, consulte Documentação do Azure Data Box – Transferência Offline.

    4. Data Factory

      O Data Factory é um serviço de integração de dados que ajuda a criar fluxos de trabalho controlados por dados que orquestram e automatizam a movimentação e a transformação de dados. É possível utilizá-lo quando a largura de banda da rede for suficiente e houver requisitos de orquestração e monitoramento da migração dos dados. Utilize o Data Factory para carregamentos incrementais regulares de dados quando os dados incrementais chegam ao sistema local como um primeiro salto e não podem ser transferidos diretamente para a conta de armazenamento do Azure devido a restrições de segurança.

      Para obter mais informações sobre as diversas abordagens de transferência, consulte Transferência de dados para grandes conjuntos de dados com largura de banda de rede moderada a alta.

      Para saber mais sobre como utilizar o Data Factory para copiar dados do HDFS, consulte Copiar dados do servidor HDFS utilizando o Azure Data Factory ou Synapse Analytics.

    5. Soluções de parceiros, como a migração com LiveData da WANdisco

      A plataforma LiveData da WANdisco para o Azure é uma das soluções preferidas da Microsoft para migrações do Hadoop para o Azure. Acesse os recursos disponíveis utilizando o portal do Azure e a CLI do Azure. Para saber mais, consulte Migre os data lakes do Hadoop com a plataforma WANDisco LiveData para o Azure.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Apresentações dos produtos do Azure

Referência de produtos do Azure

Outro