Editar

Compartilhar via

Migração do Apache Sqoop para o Azure

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

Apache Sqoop é uma ferramenta para transferência de dados entre clusters do Apache Hadoop e bancos de dados relacionais. Ele tem uma interface de linha de comando.

É possível utilizar o Sqoop para importação de dados de bancos de dados relacionais, como o MySQL, o PostgreSQL, o Oracle e o SQL Server, para o HDFS e para exportação de dados do HDFS para esses bancos de dados. O Sqoop pode utilizar o MapReduce e o Apache Hive para converter os dados no Hadoop. Alguns dos recursos avançados são o carregamento incremental, a formatação por meio de SQL e a atualização de conjuntos de dados. O Sqoop opera em paralelo a fim de alcançar transferência de dados de alta velocidade.

Observação

O projeto do Sqoop foi desativado. O Sqoop foi migrado para o Apache Attic em junho de 2021. O site, os downloads e o rastreador de problemas permanecem abertos. Para saber mais, consulte Apache Sqoop no Apache Attic.

Apache®, Apache Spark®, Apache Hadoop®, Apache HBase, Apache Hive, Apache Ranger®, Apache Storm®, Apache Sqoop®, Apache Kafka® 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 Sqoop

Há duas versões do Sqoop: Sqoop1 e Sqoop2. O Sqoop1 é uma ferramenta de cliente simples, enquanto o Sqoop2 tem uma arquitetura de cliente e servidor. Eles não são compatíveis entre si e são diferentes em termos de uso. O Sqoop2 não oferece todos os recursos, por isso não se destina à implantação em produção.

Arquitetura do Sqoop1

Diagrama da arquitetura do Sqoop1.

Importação e exportação no Sqoop1

  • Importaçãoação

    Lê os dados de bancos de dados relacionais e envia os dados ao HDFS. Cada registro na tabela de bancos de dados relacionais é enviado como uma única linha ao HDFS. Os formatos de arquivo que podem ser gravados no HDFS são os seguintes: texto, SequenceFiles e Avro.

  • Exportar

    Lê os dados do HDFS e os transfere para bancos de dados relacionais. Os bancos de dados relacionais de destino são compatíveis tanto com inserção quanto com atualização.

Arquitetura do Sqoop2

Diagrama da arquitetura do Sqoop2.

  • Servidor do Sqoop

    Proporciona um ponto de entrada para os clientes do Sqoop.

  • Cliente do Sqoop

    Interage com o servidor do Sqoop. O cliente pode estar em qualquer nó, desde que consiga se comunicar com o servidor. Como o cliente só precisa se comunicar com o servidor, não é necessário configurar igual ao MapReduce.

Desafios do Sqoop local

Veja a seguir alguns desafios comuns de uma implantação local do Sqoop:

  • O dimensionamento pode ser complicado, dependendo do hardware e da capacidade do datacenter.
  • Não é fácil dimensionar sob demanda.
  • Quando o suporte a uma infraestrutura antiga terminar, poderá ser necessário realizar a substituição e o upgrade.
  • Há uma escassez na oferta de ferramentas nativas:
    • Transparência de custo
    • Monitoramento
    • DevOps
    • Automação

Considerações

  • Ao realizar uma migração do Sqoop para o Azure, se a fonte de dados permanecer local, será necessário considerar a conectividade. É possível estabelecer uma conexão VPN pela Internet entre o Azure e a rede local existente, mas você também pode utilizar o Azure ExpressRoute para estabelecer uma conexão privada.
  • Ao realizar a migração do Sqoop para o Azure HDInsight, considere sua versão do Sqoop. O HDInsight só oferece suporte ao Sqoop1, portanto, se você estiver utilizando o Sqoop2 no ambiente local, precisará substituí-lo pelo Sqoop1 no HDInsight ou manter o Sqoop2 independente.
  • Ao realizar a migração do Sqoop para o Azure Data Factory, é necessário considerar os formatos dos arquivos de dados. O Data Factory não é compatível com o formato SequenceFile. A ausência de suporte poderá ser um problema se a implementação do Sqoop importar dados no formato SequenceFile. Para saber mais, consulte Formato de arquivo.

Abordagem da migração

O Azure oferece diversos destinos de migração para o Apache Sqoop. Dependendo dos requisitos e dos recursos do produto, é possível escolher entre máquinas virtuais (VMs) de IaaS do Azure, Azure HDInsight e Azure Data Factory.

Veja a seguir um gráfico de decisões para a escolha do destino de migração:

Diagrama de um gráfico de decisão para selecionar um destino de migração no Azure Apache Sqoop.

Os destinos de migração são abordados nestas seções:

Migração lift-and-shift para a IaaS do Azure

Se você optar por VMs de IaaS do Azure como destino de migração do Sqoop local, poderá fazer uma migração lift-and-shift. Utilize a mesma versão do Sqoop para criar um ambiente totalmente controlável. Portanto, não será necessário fazer nenhuma alteração no software do Sqoop. O Sqoop funciona com um cluster do Hadoop e normalmente é migrado com um cluster do Hadoop. Os artigos abaixo são guias para migrações lift-and-shift de clusters do Hadoop. Escolha o artigo aplicável ao serviço que será migrado.

Preparação para a migração

Durante a preparação para a migração, planeje-a e estabeleça uma conexão de rede.

Plano para migração

Colete as informações a seguir com o intuito de se preparar para migrar o Sqoop local. Essas informações vão ajudar na definição do tamanho da máquina virtual de destino e no planejamento dos componentes de software e das configurações de rede.

Item Tela de fundo
Tamanho de host atual Obtenha informações sobre a CPU, a memória, o disco e outros componentes do host ou da máquina virtual em que o cliente ou servidor do Sqoop está em execução. Utilize essas informações para estimar o tamanho de base necessário para a máquina virtual do Azure.
Métricas de host e aplicativo Obtenha informações sobre o uso de recursos (CPU, memória, disco e outros componentes) da máquina em que o cliente do Sqoop está em execução e faça uma estimativa dos recursos que realmente são utilizados. Caso você esteja utilizando menos recursos do que o alocado para o host, considere reduzir o tamanho na hora de migrar para o Azure. Depois de identificar a quantidade necessária de recursos, consulte Tamanho de máquina virtual do Azure para escolher o tipo de máquina virtual de destino para a migração.
Versão do Sqoop Confira a versão do Sqoop local a fim de definir qual versão do Sqoop deve ser instalada na máquina virtual do Azure. Caso esteja utilizando uma distribuição, como Cloudera ou Hortonworks, a versão do componente vai depender da versão dessa distribuição.
Execução de trabalhos e scripts Identifique os trabalhos que executam o Sqoop e os métodos utilizados para programá-los. Os trabalhos e os métodos são candidatos à migração.
Bancos de dados que devem ser conectados Identifique os bancos de dados aos quais o Sqoop se conecta, conforme especificação dos comandos de importação e exportação nos trabalhos do Sqoop. Após a identificação, verifique se você consegue se conectar a esses bancos de dados depois de realizar a migração do Sqoop para as máquinas virtuais do Azure. Se alguns dos bancos de dados aos quais você se conectar ainda estiverem no local, será necessária uma conexão de rede entre o ambiente local e o Azure. Para saber mais, consulte a seção Estabelecer uma conexão de rede.
Plug-ins Identifique os plug-ins do Sqoop utilizados e confira se é possível migrá-los.
Alta disponibilidade, continuidade dos negócios, recuperação de desastre Confira se as técnicas de solução de problemas utilizadas no local também podem ser utilizadas no Azure. Por exemplo, se você tiver uma configuração ativa/em espera em dois nós, prepare duas máquinas virtuais do Azure para os clientes do Sqoop que tenham a mesma configuração. O mesmo se aplica à configuração da recuperação de desastre.
Estabelecer uma conexão de rede

Se alguns dos bancos de dados aos quais você se conecta permanecer no local, será necessária uma conexão de rede entre o ambiente local e o Azure.

Existem duas opções principais para conexão do ambiente local ao Azure em uma rede privada:

  • Gateway de VPN

    É possível usar o Gateway de VPN do Azure para enviar tráfego criptografado entre sua rede virtual do Azure e o ambiente local pela Internet pública. Essa técnica não é cara e é fácil de configurar. No entanto, devido à conexão criptografada pela Internet, não há garantia da largura de banda de comunicação. Se você precisar assegurar a largura de banda, deverá escolher o ExpressRoute, que é a segunda opção. Para saber mais sobre a opção de VPN, consulte O que é o Gateway de VPN? e Design do Gateway de VPN.

  • ExpressRoute

    O ExpressRoute consegue conectar sua rede local ao Azure ou ao Microsoft 365 por meio de uma conexão privada oferecida por um provedor de conectividade. O ExpressRoute não passa pela Internet pública, o que o torna mais seguro e mais confiável, além de oferecer latências mais consistentes em comparação com as conexões pela internet. Além disso, as opções de largura de banda da linha adquirida podem garantir latências estáveis. Para saber mais, consulte O que é o Azure ExpressRoute?.

Se nenhum desses dois métodos de conexão privada atenderem às suas necessidades, considere usar o Azure Data Factory como destino de migração. O runtime de integração auto-hospedado no Data Factory permite que você realize a transferência de dados do ambiente local para o Azure sem precisar configurar uma rede privada.

Migrar dados e configurações

Ao realizar uma migração do Sqoop local para máquinas virtuais do Azure, não deixe de incluir os dados e as configurações a seguir:

  • Arquivos de configuração do Sqoop: dependem do ambiente, mas geralmente incluem os seguintes arquivos:

    • sqoop-site.xml
    • sqoop-env.xml
    • password-file
    • oraoop-site.xml, se você usar Oraoop

  • Trabalhos salvos: se você salvou trabalhos no metastore do Sqoop utilizando o comando sqoop job --create, vai precisar migrá-los. O destino de salvamento do metastore está definido no arquivo sqoop-site.xml. Se o metastore compartilhado não estiver definido, procure os trabalhos salvos no subdiretório .sqoop do diretório base do usuário que executa o metastore.

    É possível utilizar os comandos a seguir para conferir informações sobre os trabalhos salvos.

    • Obter a lista de trabalhos salvos:

      sqoop job --list

    • Visualizar os parâmetros dos trabalhos salvos:

      sqoop job --show <job-id>

  • Scripts: se houver arquivos de script que executam o Sqoop, você precisará migrá-los.

  • Agendador: se você programa a execução do Sqoop, é necessário identificar o agendador, como um trabalho cron do Linux ou uma ferramenta de gerenciamento de trabalhos. Depois, verifique se o agendador pode ser migrado para o Azure.

  • Plug-ins: se você estiver utilizando plug-ins personalizados no Sqoop, como um conector para um banco de dados externo, precisará migrá-los. Se você criou um arquivo de patch, aplique-o ao Sqoop migrado.

Migrar para o HDInsight

O HDInsight agrupa os componentes do Apache Hadoop com a plataforma HDInsight em um pacote que é implantado em um cluster. Em vez de migrar o Sqoop para o Azure, é mais usual executar o Sqoop em um cluster do HDInsight. Para saber mais sobre como utilizar o HDInsight com o intuito de executar estruturas de código aberto, como o Hadoop e o Spark, consulte O que é o Azure HDInsight? e Guia sobre como migrar cargas de trabalho de Big Data para o Azure HDInsight.

Consulte os artigos a seguir para conferir as versões dos componentes do HDInsight.

Migrar para o Data Factory

O Azure Data Factory é um serviço de integração de dados sem servidor totalmente gerenciado. Ele pode ser dimensionado sob demanda de acordo com alguns fatores, como o volume dos dados. Ele conta com uma GUI para edição e desenvolvimento intuitivos com modelos do Python, .NET e Azure Resource Manager (modelos do ARM).

Conexão a fontes de dados

Consulte o artigo adequado para acessar uma lista dos conectores padrão do Sqoop:

O Data Factory oferece uma grande quantidade de conectores. Para saber mais, consulte Visão geral do conector do Azure Data Factory e do Azure Synapse Analytics.

A tabela a seguir é um exemplo que mostra os conectores do Data Factory que podem ser utilizados com o Sqoop1 versão 1.4.7 e com o Sqoop2 versão 1.99.7. Consulte a documentação mais recente, pois a lista de versões compatíveis pode mudar.

Sqoop1 – 1.4.7 Sqoop2 – 1.99.7 Data Factory Considerações
Conector JDBC do MySQL Conector JDBC genérico MySQL, Banco de Dados do Azure para MySQL
MySQL Direct Connector N/D N/D O Direct Connector utiliza o utilitário mysqldump para entrada e saída de dados sem passar pelo JDBC. O método é diferente no Data Factory, mas o conector do MySQL pode ser utilizado no lugar.
Conector do Microsoft SQL Conector JDBC genérico SQL Server, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure
PostgreSQL Connector PostgreSQL, conector JDBC genérico Banco de Dados do Azure para PostgreSQL
PostgreSQL Direct Connector N/D N/D O Direct Connector não passa pelo JDBC e utiliza o comando COPY para entrada e saída de dados. O método é diferente no Data Factory, mas o conector do PostgreSQL pode ser utilizado no lugar.
Conector pg_bulkload N/D N/D Para carregar no PostgreSQL, use o pg_bulkload. O método é diferente no Data Factory, mas o conector do PostgreSQL pode ser utilizado no lugar.
Conector Netezza Conector JDBC genérico Netteza
Conector de dados para Oracle e Hadoop Conector JDBC genérico Oracle
N/D Conector FTP FTP
N/D Conector SFTP SFTP
N/D Conector do Kafka N/D Não é possível conectar o Data Factory diretamente ao Kafka. Avalie usar Spark Streaming, como o Azure Databricks ou o HDInsight, para estabelecer conexão com o Kafka.
N/D Conector Kite N/D Não é possível conectar o Data Factory diretamente ao Kite.
HDFS HDFS HDFS O Data Factory é compatível com o HDFS como origem, mas não como coletor.

Conectar-se a bancos de dados locais

Depois de realizar a migração do Sqoop para o Data Factory, se ainda for necessário copiar dados entre o armazenamento de dados da rede local e o Azure, considere usar os seguintes métodos:

runtime de integração auto-hospedada

Se estiver tentando integrar dados em um ambiente de rede privada em que não há nenhum caminho de comunicação direta partindo do ambiente de nuvem pública, você poderá fazer o seguinte para melhorar a segurança:

  • Instale um runtime de integração auto-hospedado no ambiente local, seja no firewall interno ou na rede virtual privada.
  • Crie uma conexão de saída baseada em HTTPS entre o runtime de integração auto-hospedado e o Azure a fim de estabelecer uma conexão para movimentação de dados.

O runtime de integração auto-hospedado só é compatível com Windows. Também é possível alcançar escalabilidade e alta disponibilidade por meio da instalação e associação de runtimes de integração auto-hospedados em várias máquinas. O runtime de integração auto-hospedado também é responsável por expedir atividades de transformação de dados para recursos que não estão no ambiente local ou na rede virtual do Azure.

Para mais informações sobre como configurar o runtime de integração auto-hospedado, consulte Criar e configurar um runtime de integração auto-hospedado.

Rede virtual gerenciada usando um ponto de extremidade privado

Se houver uma conexão privada entre o ambiente local e o Azure (como o ExpressRoute ou o Gateway de VPN), você poderá usar a rede virtual gerenciada e o ponto de extremidade privado no Data Factory a fim de estabelecer uma conexão privada com os bancos de dados locais. É possível utilizar redes virtuais para encaminhar o tráfego aos recursos locais, conforme mostrado no diagrama a seguir, a fim de acessar os recursos locais sem passar pela Internet.

Diagrama de uma arquitetura para acessar o SQL Server local a partir da rede virtual gerenciada do Data Factory usando um ponto de extremidade privado.

Baixe um Arquivo Visio dessa arquitetura.

Para saber mais, consulte Tutorial: Como acessar o SQL Server local da VNET gerenciada do Data Factory usando o ponto de extremidade privado.

Opções de rede

O Data Factory oferece duas opções de rede:

As duas desenvolvem uma rede privada e ajudam a proteger o processo de integração de dados. Elas podem ser usadas simultaneamente.

Rede virtual gerenciada

É possível implantar o runtime de integração, que é o runtime do Data Factory, em uma rede virtual gerenciada. Por meio da implantação de um ponto de extremidade privado, como um armazenamento de dados que se conecta à rede virtual gerenciada, é possível aumentar a segurança da integração de dados em uma rede privada fechada.

Diagrama de uma arquitetura que mostra uma rede virtual gerenciada e um ponto de extremidade privado.

Baixe um Arquivo Visio dessa arquitetura.

Para obter mais informações, confira Rede virtual gerenciada do Azure Data Factory.

Utilize o Link Privado do Azure para Azure Data Factory a fim de estabelecer conexão com o Data Factory.

Diagrama de uma arquitetura que inclui o runtime de integração, uma rede virtual gerenciada e um ponto final privado.

Baixe um Arquivo Visio dessa arquitetura.

Para saber mais, consulte O que é um ponto de extremidade privado? e a documentação do Link Privado.

Desempenho da cópia de dados

O Sqoop utiliza o MapReduce para processamento paralelo a fim de aprimorar o desempenho da transferência de dados. Depois de realizar a migração do Sqoop, o Data Factory consegue ajustar os níveis de desempenho e escalabilidade para cenários de execução de migrações de dados em grande escala.

Uma unidade de integração de dados (DIU) é uma unidade de desempenho do Data Factory. É uma combinação de CPU, memória e alocação de recursos de rede. O Data Factory consegue ajustar até 256 DIUs para atividades Copy que utilizam o runtime de integração do Azure. Para saber mais, confira Unidade de Integração de Dados.

Caso você utilize o runtime de integração auto-hospedado, poderá aprimorar o desempenho dimensionando a máquina que hospeda o runtime de integração auto-hospedado. A expansão máxima é de quatro nós.

Para saber mais sobre como realizar ajustes para atingir o desempenho desejado, consulte Guia de desempenho e escalabilidade da atividade Copy.

Aplicar SQL

O Sqoop consegue importar o conjunto de resultados de uma consulta SQL, conforme mostrado no seguinte exemplo:

$ sqoop import \
  --query 'SELECT a.*, b.* FROM a JOIN b on (a.id == b.id) WHERE $CONDITIONS' \
  --split-by a.id --target-dir /user/foo/joinresults

O Data Factory também consegue consultar o banco de dados e copiar o conjunto de resultados:

Captura de tela que mostra uma consulta MySQL no Data Factory.

Para conferir um exemplo que obtém o conjunto de resultados de uma consulta a um banco de dados MySQL, consulte Propriedades da atividade Copy.

Transformação de dados

Tanto o Data Factory quanto o HDInsight conseguem realizar diversas atividades de transformação de dados.

Transformar os dados usando atividades do Data Factory

O Data Factory consegue realizar diversas atividades de transformação de dados, como fluxo de dados e estruturação de dados. Para ambas, defina as transformações utilizando uma interface do usuário visual. Também é possível utilizar as atividades de diversos componentes do Hadoop do HDInsight, Databricks, procedimentos armazenados e outras atividades personalizadas. Considere usar essas atividades quando quiser incluir transformações de dados no processo de migração do Sqoop. Para saber mais, consulte Transformar dados no Azure Data Factory.

Transformar os dados utilizando atividades do HDInsight

As diversas atividades do HDInsight em um pipeline do Azure Data Factory, incluindo Hive, Pig, MapReduce, Streaming e Spark, são capazes de executar programas e consultas no próprio cluster ou em um cluster do HDInsight sob demanda. Se você migrar uma implementação do Sqoop que utiliza a lógica de transformação de dados do ecossistema do Hadoop, será fácil migrar as transformações para as atividades do HDInsight. Para obter detalhes, confira os seguintes artigos:

Formato de arquivo

O Sqoop é compatível com os formatos de arquivo de texto, SequenceFile e Avro ao importar dados para o HDFS. O Data Factory não é compatível com o HDFS como coletor de dados, mas utiliza o Azure Data Lake Storage ou o Armazenamento de Blobs do Azure como armazenamento de arquivos. Para saber mais sobre a migração do HDFS, consulte Migração do Apache HDFS.

Os formatos compatíveis para que o Data Factory grave no armazenamento de arquivos são texto, binário, Avro, JSON, ORC e Parquet, enquanto SequenceFile não é compatível. É possível utilizar algumas atividades, como Spark, para converter um arquivo em SequenceFile utilizando saveAsSequenceFile:

data.saveAsSequenceFile(<path>)

Agendamento de trabalhos

O Sqoop não oferece a funcionalidade de agendador. Caso você execute trabalhos do Sqoop em um agendador, vai precisar migrar essa funcionalidade para o Data Factory. O Data Factory pode utilizar gatilhos para programar a execução do pipeline de dados. Escolha um gatilho do Data Factory de acordo com a configuração de agendamento existente. Veja a seguir os tipos de gatilho.

  • Gatilho de agendamento: um gatilho de agendamento executa o pipeline segundo um agendamento de relógio.
  • Gatilho periódico: um gatilho periódico é executado periodicamente a partir de um horário inicial especificado, enquanto mantém seu estado.
  • Gatilho baseado em evento: um gatilho baseado em evento aciona o pipeline em resposta ao evento especificado. Há dois tipos de gatilhos baseados em evento:
    • Gatilho de evento de armazenamento: um gatilho de evento de armazenamento aciona o pipeline em resposta a um evento de armazenamento, como a criação, a exclusão ou a gravação em um arquivo.
    • Gatilho de evento personalizado: um gatilho de evento personalizado aciona o pipeline em resposta a um evento que é enviado a um tópico personalizado em uma grade de eventos. Para saber mais sobre os tópicos personalizados, consulte Tópicos do sistema na Grade de Eventos do Azure.

Para obter mais informações sobre gatilhos, consulte Execução e gatilhos do Pipeline no Azure Data Factory ou no Azure Synapse Analytics.

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