Migrando o Hadoop para a Nuvem: Capacidade de Armazenamento 2X e Menos Custos de Operações

Yimian é um fornecedor líder de análise de dados impulsionada por IA, especializado em dados de comércio digital. Oferecemos insights em tempo real sobre estratégia de negócios, desenvolvimento de produtos e operações de comércio digital. Muitos de nossos clientes são líderes em indústrias como cuidados pessoais, maquiagem, F&B, animais de estimação e automotivo, como Procter and Gamble, Unilever e Mars.

Nossa arquitetura de tecnologia original era um cluster de big data construído com o CDH (Cloudera Distributed Hadoop) em um centro de dados local. Conforme nosso negócio crescia, o volume de dados aumentou dramaticamente.

Para enfrentar desafios como ciclos de escalonamento longos, recursos de computação e armazenamento desalinhados, e custos de manutenção elevados, decidimos transformar nossa arquitetura de dados e migrar para a nuvem, adotando uma abordagem de separação de armazenamento e computação. Após uma avaliação cuidadosa, adotamos Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Serviço de Armazenamento de Objetos da Alibaba Cloud (OSS).

Atualmente, com o JuiceFS, implementamos uma arquitetura desacoplada de computação e armazenamento, dobrando nossa capacidade total de armazenamento. Notavelmente, não observamos impacto significativo no desempenho, e nossos custos operacionais foram drasticamente reduzidos.

Neste artigo, compartilharemos nosso design de arquitetura para migrar o Hadoop para a nuvem, por que escolhemos o JuiceFS+EMR+OSS e como nos beneficiamos da nova arquitetura. Nosso objetivo é oferecer insights valiosos para aqueles que enfrentam desafios semelhantes através deste post.

Nossa Velha Arquitetura e Desafios

Para atender às nossas crescentes demandas de aplicação, temos sido capazes de coletar dados de centenas de grandes sites, com o atual número excedendo 500. Com o tempo, acumulamos grandes quantidades de dados brutos, intermediários e de resultado. À medida que continuamos a expandir nossas raspagens de sites e base de clientes, nosso volume de dados estava aumentando rapidamente. Portanto, decidimos escalar nosso hardware para acomodar os crescentes requisitos.

A Arquitetura Original

A figura a seguir mostra nossa arquitetura anterior, que envolvia um cluster de big data baseado em CDH implantado em um datacenter:

• Os componentes-chave incluíam Hive, Spark e HDFS.
• Vários sistemas de produção de dados, com Kafka sendo um deles, alimentavam o cluster.
• Utilizamos outras soluções de armazenamento, como TiDB, HBase e MySQL, além de Kafka.

Original architecture at Yimian

Os dados fluíam dos sistemas de aplicação e coleta de dados upstream, onde eram escritos no Kafka. Empregamos um cluster Kafka Connect para sincronizar os dados no HDFS.

Sobre esta arquitetura, desenvolvemos uma plataforma personalizada de desenvolvimento de dados chamada OneWork para gerenciar várias tarefas. Estas tarefas eram agendadas via Airflow e processadas em filas de tarefas.

Nossos Pontos Doloridos

Os desafios enfrentados foram os seguintes:

• Crescimento rápido dos dados das aplicações e longos ciclos de escalonamento: Nosso cluster CDH, implantado em 2016, já lidava com petabytes de dados até 2021. No entanto, o crescimento dos dados frequentemente excedia a planejamento de hardware, levando a escalas frequentes a cada seis meses. Isso consumiu recursos e tempo significativos.
• Acoplamento de armazenamento e computação e dificuldade em planejamento de capacidade: A arquitetura tradicional do Hadoop tem um acoplamento rígido de armazenamento e computação, o que dificulta a escalabilidade e planejamento independentes com base nas necessidades de armazenamento ou computação. Por exemplo, expandir o armazenamento também exigiria a compra de recursos de computação desnecessários. Isso levou a uma alocação de recursos ineficiente.
• Medo de atualizar devido à nossa versão CDH: Nossa versão CDH era antiga e hesitamos em atualizar devido a preocupações com estabilidade e compatibilidade.
• Custos de operações elevados: Com cerca de 200 funcionários, tínhamos apenas um funcionário de operações em tempo integral. Isso trouxe um grande volume de trabalho. Para aliviar isso, buscamos uma arquitetura mais estável e simples.
• Ponto de falha único do centro de dados: Todo o dados armazenados em um único centro de dados representava um risco a longo prazo. Em caso de danos a cabos ou outros problemas, ter um único centro de dados cria um único ponto de falha.

Nossas Requisitos para a Nova Arquitetura

Para enfrentar nossos desafios e atender às crescentes demandas, decidimos fazer algumas mudanças arquitetônicas. Os principais aspectos considerados para a atualização incluem o seguinte:

• Adoção de nuvem, escalabilidade elástica e flexibilidade operacional: Aderir aos serviços de nuvem simplificaria as operações. Por exemplo, aproveitar o armazenamento baseado na nuvem nos permite focar na aplicação enquanto evitamos tarefas de manutenção. Além disso, os recursos da nuvem permitem escalabilidade elástica sem implantações de hardware longas e configurações de sistema.
• Desacoplamento de armazenamento e cálculo: Nossa meta era separar armazenamento e cálculo para alcançar maior flexibilidade e desempenho.
• Preferência por componentes de código aberto, evitando bloqueio de fornecedor: Embora utilizemos serviços na nuvem, buscamos minimizar a dependência de fornecedores específicos. Enquanto usamos o AWS Redshift para serviços de clientes, preferimos componentes de código aberto para operações internas.
• Compatibilidade com soluções existentes, controlando custos e riscos: Nosso objetivo era garantir a compatibilidade com soluções atuais para minimizar custos de desenvolvimento e impacto em nossa aplicação.

Por que escolhemos o JuiceFS+EMR+OSS

Após avaliarmos várias soluções, escolhemos o EMR+JuiceFS+OSS para construir uma plataforma de big data com armazenamento e cálculo separados e gradualmente migramos nosso data center no local para a nuvem.

New architecture at Yimian

Neste cenário, o armazenamento de objetos substitui o HDFS, e o JuiceFS atua como camada de protocolo devido ao seu suporte a protocolos POSIX e HDFS. No topo, utilizamos uma solução Hadoop semi-gerida, o EMR. Ele inclui componentes como Hive, Impala, Spark, Presto/Trino, entre outros.

Alibaba Cloud vs. Outras Nuvens Públicas

Após nossa avaliação cuidadosa, escolhemos a Alibaba Cloud em vez do AWS e Azure devido aos seguintes fatores:

• Proximidade: A zona de disponibilidade da Alibaba Cloud na mesma cidade do nosso centro de dados garante baixa latência e redução de custos de rede.
• Componentes de código aberto abrangentes: O Alibaba Cloud EMR oferece uma ampla gama de componentes de código aberto relacionados ao Hadoop. Além do nosso intenso uso de Hive, Impala, Spark e Hue, também fornece integração perfeita com Presto, Hudi, Iceberg e muito mais. Durante nossa pesquisa, descobrimos que apenas o EMR inclui nativamente o Impala, enquanto o AWS e o Azure oferecem versões inferiores ou exigem instalação e implantação manual.

JuiceFS vs. JindoFS

O que é JuiceFS?

JuiceFS é um sistema de arquivos distribuído, de código aberto e voltado para a nuvem, com alto desempenho. Ele oferece compatibilidade total com o POSIX, permitindo que o armazenamento de objetos seja utilizado como um disco local em larga escala em diferentes plataformas e regiões.

JuiceFS adota uma arquitetura separada de dados-metadados, possibilitando um design de sistema de arquivos distribuído. Ao usar JuiceFS para armazenar dados, os dados são persistentes no armazenamento de objetos como o Amazon S3, enquanto os metadados podem ser armazenados no Redis, MySQL, TiKV, SQLite e outros bancos de dados.

Além do POSIX, o JuiceFS é totalmente compatível com o SDK do HDFS, permitindo a substituição perfeita do HDFS para separação de armazenamento e computação.

The JuiceFS architecture

Por que escolhemos o JuiceFS em vez do JindoFS

Optamos pelo JuiceFS em vez do JindoFS com base nas seguintes considerações:

• Design de armazenamento: JuiceFS adota uma arquitetura de armazenamento separada para dados e metadados, permitindo um design de sistema de arquivos distribuído. Os dados são persistentes no armazenamento de objetos, enquanto os metadados podem ser armazenados em vários bancos de dados como Redis, MySQL, TiKV e SQLite, proporcionando maior flexibilidade. Em contraste, os metadados de JindoFS são armazenados no disco rígido local do cluster EMR, tornando a manutenção, atualizações e migrações menos convenientes.
• Flexibilidade de armazenamento: JuiceFS oferece várias soluções de armazenamento, suportando a migração online entre diferentes esquemas e aumentando a portabilidade. JindoFS de dados em bloco suporta apenas o OSS.
• Suporte à comunidade de código aberto: JuiceFS é baseado em uma comunidade de código aberto, suportando todos os ambientes de nuvem pública. Isso facilita a expansão futura para uma arquitetura multi-nuvem.

O Design Integral da Arquitetura

Considerando que alguns aplicativos ainda serão mantidos no cluster Hadoop do centro de dados, na verdade adotamos uma arquitetura de nuvem híbrida, como mostrado na figura abaixo.

A hybrid cloud architecture

Na figura da arquitetura:

• No topo estão Airflow e OneWork, ambos suportam implantação distribuída, portanto, podem ser facilmente escalados horizontalmente.
• À esquerda está o IDC, que usa a arquitetura CDH tradicional e alguns clusters Kafka.
• À direita está o cluster EMR implantado na Alibaba Cloud.

O IDC e o cluster EMR são conectados por uma linha dedicada de alta velocidade.

Como Beneficiamos da Nova Arquitetura

Benefícios da Separação de Armazenamento e Computação

Com a implementação do desacoplamento de armazenamento e computação, nossa capacidade total de armazenamento dobrou enquanto os recursos de computação permanecem estáveis. Eventualmente, ativamos nós de tarefas temporárias conforme necessário. Em nosso cenário, o volume de dados experimenta um crescimento rápido enquanto as demandas de consulta permanecem estáveis. Desde 2021, nosso volume de dados dobrou. Fizemos mudanças mínimas nos recursos de computação desde o estágio inicial até agora, exceto por ocasionalmente ativar recursos elásticos e nós de tarefas temporárias para atender às necessidades específicas de aplicação.

Mudanças de Desempenho

Para nosso cenário de aplicação, que envolve principalmente processamentos em batch em larga escala para computação offline, não houve impacto significativo no desempenho. No entanto, durante a fase de PoC, observamos melhorias no tempo de resposta para consultas ad-hoc do Impala.

Durante a fase de PoC, realizamos alguns testes simples. No entanto, interpretar os resultados com precisão é desafiador devido a vários fatores influentes:

• A transição do HDFS para o JuiceFS
• Atualizações de versão de componentes
• Mudanças no motor do Hive
• Mudanças na carga do cluster

Todos estes fatores dificultam a conclusão definitiva sobre diferenças de desempenho em comparação com nossa configuração anterior do CDH em servidores bare metal.

Usabilidade e Estabilidade

Não enfrentamos problemas com o JuiceFS.

Ao usar o EMR, tivemos problemas menores. No geral, o CDH é percebido como mais estável e amigável ao usuário.

Complexidade de Implementação

No nosso cenário, os processos mais demorados são a escrita dual incremental e a verificação de dados. Em retrospectiva, investimos excessivamente na verificação e poderíamos simplificá-la.

Vários fatores influenciam a complexidade:

• Cenários de aplicação (offline/em tempo real, número de tabelas/tarefas, aplicações de nível superior)
• Versões de componentes
• Ferramentas de suporte e reservas

Planos Futuros

Nossos planos futuros incluem:

• Continuar a migração das aplicações restantes para a nuvem.
• Explorar uma estratégia de armazenamento em camadas frio/quente usando JuiceFS+OSS. Os arquivos JuiceFS são completamente desmontados no OSS, tornando difícil implementar a camada de arquivos. Nossa abordagem atual envolve migrar dados frios de JuiceFS para OSS, configurá-los como armazenamento de arquivamento e modificar o LOCATION das tabelas ou partições do Hive sem impactar o uso.
• Se o volume de dados aumentar e houver pressão para usar o Redis, podemos considerar trocar para o TiKV ou outros motores no futuro.
• Explorar instâncias de computação elásticas do EMR para reduzir custos de uso enquanto atende aos acordos de nível de serviço das aplicações.