Este é um submit convidado de Valdiney Gomes, Hélio Leal, Flávia Lima e Fernando Saga da Dafiti.
À medida que as empresas se esforçam para tomar decisões informadas, a quantidade de dados gerados e necessários para análise está crescendo exponencialmente. Esta tendência não é exceção para Dafitiuma empresa de comércio eletrônico que reconhece a importância de usar dados para conduzir processos de tomada de decisão estratégica. Com o quantity cada vez maior de dados disponíveis, a Dafiti enfrenta o desafio de gerenciar e extrair insights valiosos desse vasto conjunto de informações de forma eficaz para obter uma vantagem competitiva e tomar decisões baseadas em dados que se alinhem aos objetivos de negócios da empresa.
Amazon Redshift é amplamente usado para análise de dados da Dafiti, suportando aproximadamente 100.000 consultas diárias de mais de 400 usuários em três países. Essas consultas incluem processos de extração, transformação e carga (ETL) e extração, carga e transformação (ELT) e análises únicas. A infraestrutura de dados da Dafiti depende muito de processos ETL e ELT, com aproximadamente 2.500 processos exclusivos executados diariamente. Esses processos recuperam dados de cerca de 90 fontes de dados diferentes, resultando na atualização de aproximadamente 2.000 tabelas no information warehouse e 3.000 tabelas externas no formato Parquet, acessadas por meio de Espectro Redshift da Amazon e um information lake em Serviço de armazenamento simples da Amazon (Amazon S3).
A crescente necessidade de espaço de armazenamento para manter dados de mais de 90 fontes e a funcionalidade disponível no novo Tipos de nó do Amazon Redshiftincluindo armazenamento gerenciado, compartilhamento de dadose integrações zero-ETLnos levou a migrar dos nós DC2 para RA3.
Nesta postagem, compartilhamos como lidamos com o processo de migração e fornecemos mais impressões sobre nossa experiência.
Amazon Redshift na Dafiti
O Amazon Redshift é um serviço de information warehouse totalmente gerenciado e foi adotado pela Dafiti em 2017. Desde então, tivemos a oportunidade de acompanhar muitas inovações e passamos por três tipos diferentes de nós. Começamos com 115 nós dc2.giant e com o lançamento do Redshift Spectrum e a migração de nossos dados frios para o information lake, então melhoramos consideravelmente nossa arquitetura e migramos para quatro nós dc2.8xlarge. RA3 introduziu muitos recursospermitindo-nos escalar e pagar por computação e armazenamento de forma independente. Foi isso que nos trouxe ao momento atual, onde temos oito nós ra3.4xlarge no ambiente de produção e um cluster ra3.xlplus de nó único para desenvolvimento.
Dado o nosso cenário, onde temos muitas fontes de dados e muitos dados novos sendo gerados a cada momento, nos deparamos com um problema: os 10 TB que tínhamos disponíveis em nosso cluster eram insuficientes para nossas necessidades. Embora a maioria dos nossos dados esteja atualmente no information lake, mais espaço de armazenamento period necessário no information warehouse. Isso foi resolvido pelo RA3, que dimensiona a computação e o armazenamento de forma independente. Além disso, com zero-ETL, simplificamos nossos pipelines de dados, ingerindo toneladas de dados em tempo quase actual de nossos Serviço de banco de dados relacional da Amazon (Amazon RDS), enquanto o compartilhamento de dados permite uma abordagem de malha de dados.
Processo de migração para RA3
Nosso primeiro passo para a migração foi entender como o novo cluster deveria ser dimensionado; para isso, a AWS fornece um tabela de recomendação.
Dada a configuração do nosso cluster, composto por quatro nós dc2.8xlarge, a recomendação foi mudar para ra3.4xlarge.
Nesse ponto, uma preocupação que tínhamos period em relação à redução da quantidade de vCPU e memória. Com o DC2, nossos quatro nós forneceram um whole de 128 vCPUs e 976 GiB; no RA3, mesmo com oito nós, esses valores foram reduzidos para 96 vCPUs e 768 GiB. No entanto, o desempenho foi melhorado, com o processamento de cargas de trabalho 40% mais rápido em geral.
Ofertas da AWS Teste de direção do Redshift para validar se a configuração escolhida para o Amazon Redshift é supreme para sua carga de trabalho antes de migrar o ambiente de produção. Na Dafiti, dadas as particularidades da nossa carga de trabalho, o que nos dá alguma flexibilidade para fazer alterações em janelas específicas sem afetar o negócio, não foi necessário utilizar o Redshift Check Drive.
Realizamos a migração da seguinte forma:
- Criamos um novo cluster com oito nós ra3.4xlarge a partir do snapshot do nosso cluster dc2.8xlarge de quatro nós. Esse processo levou cerca de 10 minutos para criar o novo cluster com 8,75 TB de dados.
- Desativamos nosso orquestrador interno de ETL e ELT para evitar que nossos dados fossem atualizados durante o período de migração.
- Alteramos o DNS apontando para o novo cluster de forma transparente para nossos usuários. Neste ponto, apenas consultas únicas e aquelas feitas por Visão rápida da Amazon chegou ao novo cluster.
- Após a conclusão do estágio de validação da consulta de leitura e quando ficamos satisfeitos com o desempenho, reconectamos nosso orquestrador para que as consultas de transformação de dados pudessem ser executadas no novo cluster.
- Removemos o cluster DC2 e concluímos a migração.
O diagrama a seguir ilustra a arquitetura de migração.
Durante a migração, definimos alguns checkpoints nos quais um rollback seria realizado caso algo indesejado acontecesse. O primeiro checkpoint foi no Step 3, onde a redução de desempenho nas consultas dos usuários levaria a um rollback. O segundo checkpoint foi no Step 4, caso os processos ETL e ELT apresentassem erros ou houvesse perda de desempenho em comparação com as métricas coletadas dos processos executados no DC2. Em ambos os casos, o rollback ocorreria simplesmente alterando o DNS para apontar para o DC2 novamente, porque ainda seria possível reconstruir todos os processos dentro da janela de manutenção definida.
Resultados
A família RA3 introduziu muitos recursos, permitiu dimensionamento e nos habilitou a pagar por computação e armazenamento de forma independente, o que mudou o jogo na Dafiti. Antes, tínhamos um cluster que funcionava conforme o esperado, mas nos limitava em termos de armazenamento, exigindo manutenção diária para manter o controle do espaço em disco.
Os nós RA3 tiveram melhor desempenho e as cargas de trabalho foram executadas 40% mais rápido em geral. Isso representa uma redução significativa no tempo de entrega de nossos processos críticos de análise de dados.
Essa melhoria se tornou ainda mais pronunciada nos dias seguintes à migração, devido à capacidade do Amazon Redshift de otimizar o cache, as estatísticas e aplicar recomendações de desempenho. Além disso, o Amazon Redshift é capaz de fornecer recomendações para otimizar nosso cluster com base em nossas demandas de carga de trabalho por meio de Recomendações do Amazon Redshift Advisore ofertas otimização automática de tabelaque desempenhou um papel elementary na obtenção de uma transição tranquila.
Além disso, o salto da capacidade de armazenamento de 10 TB para vários PB resolveu o principal desafio da Dafiti de acomodar volumes crescentes de dados. Esse aumento substancial nas capacidades de armazenamento, combinado com as melhorias inesperadas de desempenho, demonstrou que a migração para nós RA3 foi uma decisão estratégica bem-sucedida que abordou os requisitos de infraestrutura de dados em evolução da Dafiti.
O compartilhamento de dados vem sendo usado desde o momento da migração, para compartilhar dados entre o ambiente de produção e desenvolvimento, mas a evolução pure é habilitar o information mesh na Dafiti por meio desse recurso. A limitação que tivemos foi a necessidade de ativar a diferenciação entre maiúsculas e minúsculas, que é um pré-requisito para o compartilhamento de dados, e que nos forçou a alterar alguns processos quebrados. Mas isso não foi nada comparado aos benefícios que estamos vendo com a migração para o RA3.
Conclusão
Nesta postagem, discutimos como a Dafiti lidou com a migração para os nós Redshift RA3 e os benefícios dessa migração.
Quer saber mais sobre o que estamos fazendo na área de dados na Dafiti? Confira os seguintes recursos:
O conteúdo e as opiniões desta postagem são dos autores da Dafiti e a AWS não é responsável pelo conteúdo ou pela precisão desta postagem.
Sobre os autores
Valdiney Gomes é Coordenador de Engenharia de Dados na Dafiti. Trabalhou por muitos anos em engenharia de software program, migrou para engenharia de dados e atualmente lidera uma equipe incrível responsável pela plataforma de dados da Dafiti na América Latina.
Hélio Leal é especialista em engenharia de dados na Dafiti, responsável por manter e evoluir toda a plataforma de dados da Dafiti usando soluções da AWS.
Flávia Lima é engenheiro de dados na Dafiti, responsável por sustentar a plataforma de dados e fornecer dados de diversas fontes para clientes internos.
Fernando Saga é engenheiro de dados na Dafiti, responsável por manter a plataforma de dados da Dafiti usando soluções da AWS.