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 de mercado em cuidados pessoais, maquiagem, F&B, pet 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 datacenter local. À medida que nosso negócio crescia, o volume de dados aumentava drasticamente.
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 os custos operacionais foram drasticamente reduzidos.
Neste artigo, compartilharemos nosso design de arquitetura para migrar o Hadoop para a nuvem, por que escolhemos 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. Ao longo do tempo, acumulamos grandes quantidades de dados brutos, intermediários e de resultado. À medida que continuamos a expandir nossas coletas 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.
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. Essas tarefas eram agendadas via Airflow e processadas em filas de tarefas.
Nossos Pontos Doloridos
Os desafios que enfrentamos foram os seguintes:
- Crescimento rápido de dados de aplicativos 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 muitas vezes excedia a planejamento de hardware, levando a frequentes escalas a cada seis meses. Isso consumiu recursos e tempo significativos.
- Acoplamento de armazenamento e computação e dificuldade em planejar capacidade: A arquitetura tradicional do Hadoop possui um acoplamento rígido de armazenamento e computação, o que dificulta a escalabilidade e o planejamento de forma independente 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 operacionais 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 armazenamento de dados 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 nossas 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 em nuvem simplificaria as operações. Por exemplo, aproveitar o armazenamento baseado em nuvem nos permite focar na aplicação enquanto evitamos tarefas de manutenção. Além disso, os recursos em nuvem permitem escalabilidade elástica sem implantações de hardware prolongadas e configurações de sistema.
- Desacoplamento de armazenamento e computação: Nossa meta era separar armazenamento e computação para alcançar maior flexibilidade e desempenho.
- Preferência por componentes de código aberto, evitando bloqueio de fornecedor: Embora utilizemos serviços em nuvem, buscamos minimizar a dependência de fornecedores específicos. Ao usar 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 computação separados e gradualmente migramos nosso datacenter local para a nuvem.
Nesta configuração, 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-gerenciada, 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 detrimento 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 custos reduzidos 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 proporciona 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 requerem instalação e implantação manual.
JuiceFS vs. JindoFS
O que é JuiceFS?
JuiceFS é um sistema de arquivos distribuído, cloud-native e de código aberto com alto desempenho. Ele oferece total compatibilidade com o POSIX, permitindo que o armazenamento de objetos seja utilizado como um disco local massivo em diferentes plataformas e regiões.
JuiceFS adota uma arquitetura separada de dados-metadados, permitindo um design de sistema de arquivos distribuído. Ao usar JuiceFS para armazenar dados, os dados são persistentes em armazenamento de objetos como o Amazon S3, enquanto os metadados podem ser armazenados em bancos de dados como Redis, MySQL, TiKV, SQLite, entre outros.
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.
Por que Optamos pelo JuiceFS em vez do JindoFS
Escolhemos o 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 em 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 do JindoFS são armazenados no disco rígido local do cluster EMR, o que torna 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. O JindoFS de dados em bloco suporta apenas o OSS.
- Suporte à comunidade open-source: JuiceFS é baseado em uma comunidade open-source, suportando todos os ambientes de nuvem pública. Isso facilita a expansão futura para uma arquitetura multi-nuvem.
Design de Arquitetura Total
Considerando que algumas aplicações ainda serão mantidas no cluster Hadoop do datacenter, na verdade estamos empregando uma arquitetura híbrida de nuvem, como mostrado na figura abaixo.
Na figura da arquitetura:
- No topo estão Airflow e OneWork, ambos suportam implantação distribuída, então 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 Cálculo
Com a implementação da desacoplagem de armazenamento e computação, nossa capacidade total de armazenamento duplicou enquanto os recursos de computação permanecem estáveis. Às vezes, 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 a fase inicial até agora, exceto por ocasionalmente ativar recursos elásticos e nós de tarefas temporárias para atender às necessidades específicas de aplicativos.
Mudanças no Desempenho
Para nosso cenário de aplicativo, 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, é desafiador interpretar os resultados com precisão 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 Hive
- Mudanças na carga do cluster
Todos estes tornam difícil tirar conclusões definitivas sobre as diferenças de desempenho em comparação com nossa implantaçã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.
Complexidade da Implementação
Em nosso cenário, os processamentos 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.
Múltiplos 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 quente/frio usando JuiceFS+OSS. Os arquivos JuiceFS são completamente desmontados no OSS, tornando desafiador implementar camadas de arquivos. Nossa abordagem atual envolve migrar dados frios do JuiceFS para o 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 no uso do Redis, podemos considerar a troca 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.
Source:
https://dzone.com/articles/migrating-hadoop-to-the-cloud-2x-storage-capacity