Get best of the week

Os 10 principais equívocos sobre como transportar o Hadoop para a nuvem


Muitas empresas e corporações desejam usar a nuvem para processar dados por razões óbvias: flexibilidade, escalabilidade, você só pode pagar pelo que usar e assim por diante.

De fato, transferir um projeto com um sistema de processamento de dados multicomponentes, da escala Petabyte, do ambiente local para a nuvem é um sólido “mas”. Existem muitos produtos para migração: Hadoop , Hive , Fios , Spark , Kafka , Zookeeper , Jupyter , Zeppelin . Dada a diferença fundamental no ambiente, é fácil se perder e cometer erros nessa variedade.

Neste artigo, falarei sobre equívocos comuns e darei algumas dicas sobre a migração de qualidade para a nuvem. Pessoalmente, uso a AWS , mas todos os truques são relevantes para outros provedores com soluções semelhantes, por exemplo, para Azure ou GCP .

1. Copiar dados para a nuvem é fácil


Transferir vários petabytes de dados para a nuvem pública (por exemplo, S3 ), que no nosso caso funcionará como um data lake, não é uma tarefa fácil. Isso pode consumir muito tempo e consumir muitos recursos.

Apesar do grande número de soluções, comerciais e de código aberto, não encontrei nenhuma que atendesse a todas as necessidades:

  • transmissão
  • integração de dados
  • verificação de dados
  • comunicando

Se uma certa parte dos dados é principalmente estática ou moderadamente dinâmica, você pode usar uma solução como o AWS Snowball , que permite copiar matrizes para um dispositivo físico. Os dados serão baixados da sua rede local, após o que a unidade será enviada de volta ao data center da AWS e os dados serão despejados no armazenamento S3 .

Texto oculto
, , AWS.

É uma boa prática dividir a transferência de dados em duas fases. Depois que a maioria da matriz tiver sido enviada e carregada no repositório, use uma conexão direta do provedor de nuvem para descarregar o restante. Você pode usar os métodos Hadoop DistCP ou Kafka Mirroring para isso . Ambos os métodos têm suas próprias nuances. O DistCP requer planejamento constante e ajuste profundo; além disso, nem todos os objetos podem ser colocados em listas em preto e branco. O Kafka MirrorMaker , além do ajuste profundo, precisa exportar métricas por meio da extensão de gerenciamento JMX para medir a taxa de transferência, a latência e a estabilidade geral.

Texto oculto
. — , .

2. A nuvem funciona como armazenamento local


Armazenamento local e armazenamento em nuvem não são a mesma coisa. Um bom exemplo é Zookeeper e Kafka . A biblioteca do cliente ZK armazena em cache os endereços permitidos dos servidores ZK por toda a vida útil: este é um grande problema para implantação na nuvem, o que exigirá muletas - as interfaces de rede ENI estáticas para servidores ZK .

Para o monitoramento do desempenho, seria bom executar uma série de testes NFT não funcionais na infraestrutura da nuvem para garantir que as definições e configurações atendam às suas cargas de trabalho.

Texto oculto
, , .

3. O armazenamento de objetos 100% substitui o HDFS


Separar as camadas de armazenamento e computação é uma ótima idéia, mas há uma ressalva.

Com exceção do Google Cloud the Storage , que usa uma forte consistência de dados (forte consistência) , a maioria das outras instalações de armazenamento opera no modelo de "consistência eventualmente» (eventualmente consistente) . Isso significa que eles podem ser usados ​​para inserir dados brutos e processados ​​e gerar resultados, mas não como um armazenamento temporário.

Texto oculto
, HDFS.

4. Você pode implantar a infraestrutura em nuvem a partir da interface do usuário


Para um ambiente de teste pequeno, isso pode ser fácil, mas quanto mais altos os requisitos de infraestrutura, maior a probabilidade de escrever código. Você pode querer ter vários ambientes (Dev, QA, Prod) . Isso pode ser implementado usando o CloudFormation e o Terraform , mas a cópia dos trechos de código necessários falhará, você precisará refazer muito.

Texto oculto
— CI/CD . , .

5. Para uma visibilidade correta na nuvem, você só precisa usar $ {SaaS_name}


A boa visibilidade (registro e monitoramento) do ambiente antigo e novo é uma condição crítica para uma migração bem-sucedida.

Isso pode ser difícil devido ao uso de diferentes sistemas em ambientes. Por exemplo, Prometheus e ELK para o ambiente local e NewRelic e Sumologic para a nuvem. Mesmo que uma solução SaaS seja aplicada nos dois ambientes, é difícil escalar.

Texto oculto
, ( , , JMX, , ).

6. A nuvem escala ao infinito


Os usuários geralmente se alegram quando crianças quando aprendem sobre a função de escala automática e pensam que a aplicarão imediatamente em suas plataformas de processamento de dados. É realmente fácil de configurar para nós EMR sem HDFS , mas exigirá conhecimento adicional para armazenamento persistente (por exemplo, o Kafka software broker ). Antes de alternar todo o tráfego para a infraestrutura de nuvem, você precisa verificar os limites de recursos atuais: o número de instâncias de classe, discos, também é necessário pré-aquecer os balanceadores de carga. Sem esse treinamento, o potencial de trabalho não pode ser usado como deveria.

Texto oculto
, — , — .

7. Acabei de mudar minha infraestrutura inalterada


De fato, em vez de focar apenas nos recursos de um provedor de serviços em potencial, é melhor focar em seus próprios repositórios, por exemplo, DynamoDB . Mas não se esqueça dos serviços compatíveis com a API. Como alternativa, você pode usar o serviço de nuvem Amazon RDS para o banco de dados Hive Metastore .

Outro bom exemplo é a plataforma de big data otimizada para nuvem EMR . À primeira vista, simples, requer ajuste fino usando scripts de pós-instalação. Você pode personalizar o tamanho da pilha , arquivos de terceiros JAR , UDFcomplementos de segurança. Observe também que ainda não há como fornecer alta disponibilidade (HA) para os principais nós NameNode ou YARN ResourceManager .

Texto oculto
, , .

8. Transfira tarefas do Hadoop / Spark para a nuvem - é fácil


Na verdade não. Para transferir tarefas com êxito, você precisa ter uma idéia clara da lógica e dos pipelines da sua empresa: desde o recebimento inicial de dados brutos até matrizes de alta qualidade. Tudo se torna ainda mais complicado quando os resultados dos pipelines X e Y são os dados de entrada do pipeline Z. Todos os componentes dos fluxos e relacionamentos devem ser exibidos da forma mais clara possível. Isso pode ser implementado usando o DAG .

Texto oculto
SLA.

9. Cloud reduzirá custos operacionais e orçamento da equipe


O equipamento próprio requer custos físicos e salários para os funcionários. Depois de migrar para a nuvem, todos os custos não desaparecerão: você ainda precisará reagir às necessidades da empresa e contratar pessoas que estarão envolvidas no desenvolvimento, suporte, solução de problemas e planejamento de orçamento. Você também precisará investir em software e ferramentas para a nova infraestrutura.

A equipe deve ser uma pessoa que entenda como as novas tecnologias funcionam. Isso implica um funcionário altamente qualificado. Portanto, mesmo levando em consideração a redução de pessoal, você pode gastar tanto, se não mais, com o salário de um bom especialista.

Texto oculto
— (, EMR), . , , .

10. No-Ops perto ...


No-Ops é o sonho de qualquer negócio. Um ambiente totalmente automatizado, sem a necessidade de serviços e produtos de terceiros. É possível?

Uma equipe modesta de várias pessoas é relevante apenas para pequenas empresas cujas atividades não estão diretamente relacionadas aos dados. Todos os outros precisarão de pelo menos um especialista que integre e empacote todos os sistemas, os compare, automatize, forneça visibilidade e elimine todos os bugs que surgirem ao longo do caminho.

Texto oculto
Data-Ops , .


Para resumir. Transferir pipelines de processamento de dados para a nuvem é bom. Para que a migração funcione como deveria, você precisa planejar cuidadosamente o processo, levando em consideração todas as armadilhas descritas acima. Pense em alguns passos à frente e tudo vai dar certo.

More articles:


All Articles