Este é um put up convidado co-autor de Michael Davies, da Open Universities Australia.
No Universidades abertas Austrália (OUA)Capacitamos os alunos a explorar uma vasta gama de graus de renomadas universidades australianas, todas entregues através do aprendizado on -line. Oferecemos aos alunos caminhos alternativos para alcançar suas aspirações educacionais, proporcionando a eles flexibilidade e acessibilidade para alcançar seus objetivos acadêmicos. Desde a nossa fundação em 1993, apoiamos mais de 500.000 estudantes a alcançar seus objetivos, fornecendo caminhos para mais de 2.600 disciplinas em 25 universidades da Austrália.
Como uma organização sem fins lucrativos, o custo é uma consideração essential para a OUA. Ao revisar nosso contrato para a ferramenta de terceiros que estávamos usando para nossos pipelines de extrato, transformar e carregar (ETL), percebemos que poderíamos replicar grande parte da mesma funcionalidade usando Amazon Internet Providers (AWS) Serviços como Aws colaAssim, Amazon Appflowe Funções de etapas da AWS. Também reconhecemos que poderíamos consolidar nosso código -fonte (grande parte dos quais foi armazenada na própria ferramenta ETL) em um repositório de código que poderia ser implantado usando o Package de desenvolvimento em nuvem da AWS (AWS CDK). Ao fazer isso, tivemos a oportunidade de não apenas reduzir custos, mas também aumentar a visibilidade e a manutenção de nossos pipelines de dados.
Nesta postagem, mostramos como usamos os serviços da AWS para substituir nossa ferramenta ETL de terceiros existente, melhorando a produtividade da equipe e produzindo uma redução significativa em nossos custos operacionais da ETL.
Nossa abordagem
A iniciativa de migração consistiu em duas partes principais: construindo a nova arquitetura e migrando pipelines de dados da ferramenta existente para a nova arquitetura. Muitas vezes, trabalhávamos em paralelo, testando um componente da arquitetura enquanto desenvolvemos outro ao mesmo tempo.
Desde o início de nossa jornada de migração, começamos a definir alguns princípios orientadores que aplicaríamos ao longo do processo de desenvolvimento. Estes eram:
- Simples e modular – Use padrões de design simples e reutilizáveis com o mínimo possível de peças móveis. Estruture a base de código para priorizar a facilidade de uso para os desenvolvedores.
- Econômico -Use recursos de maneira eficiente e econômica. Procure minimizar as situações em que os recursos estão sendo executados enquanto aguardam a conclusão de outros processos.
- Continuidade dos negócios – Tanto quanto possível, use o código existente em vez de reinventar a roda. Atualizações de lançamento em etapas para minimizar possíveis interrupções nos processos de negócios existentes.
Visão geral da arquitetura
O diagrama seguinte 1 é a arquitetura de alto nível para a solução.

Diagrama 1: Arquitetura geral da solução, usando funções de etapas da AWS, Amazon Redshift e Amazon S3
Os seguintes serviços da AWS foram usados para moldar nossa nova arquitetura ETL:
- Amazon Redshift -Um serviço de information warehouse de escala de petabyte totalmente gerenciado na nuvem. O Amazon Redshift serviu como nosso repositório de dados central, onde armazenaríamos dados, aplicaríamos transformações e disponibilizaríamos dados para uso em análise e inteligência de negócios (BI). Nota: O próprio cluster provisionado foi implantado separadamente da arquitetura ETL e permaneceu inalterado durante todo o processo de migração.
- Package de desenvolvimento em nuvem da AWS (AWS CDK) -O AWS Cloud Growth Package (AWS CDK) é uma estrutura de desenvolvimento de software program de código aberto para definir a infraestrutura em nuvem em código e provisionando-a através da AWS CloudFormation. Nossa infraestrutura foi definida como código usando o AWS CDK. Como resultado, simplificamos a maneira como definimos os recursos que queríamos implantar enquanto usamos nossa linguagem de codificação preferida para desenvolvimento.
- Funções de etapas da AWS – Com as funções da AWS STEP, você pode criar fluxos de trabalho, também chamados de máquinas de estado, para criar aplicativos distribuídos, automatizar processos, orquestrar microsserviços e criar dutos de dados e aprendizado de máquina. As funções da AWS Step podem ligar para mais de 200 serviços da AWS, incluindo a AWS Glue, a AWS Lambda e o Amazon Redshift. Utilizamos as máquinas de estado da função de etapa da AWS para definir, orquestrar e executar nossos pipelines de dados.
- Amazon Eventbridge -Usamos a Amazon Eventbridge, o serviço de barramento de eventos sem servidor, para definir as regras e cronogramas baseados em eventos que acionariam nossas máquinas de estado de funções de etapas da AWS.
- Aws cola – Um serviço de integração de dados, a AWS Glue consolida os principais recursos de integração de dados em um único serviço. Isso inclui descoberta de dados, ETL moderno, limpeza, transformação e catalogação centralizada. Também não tem servidor, o que significa que não há infraestrutura para gerenciar. Inclui a capacidade de executar scripts Python. Usamos para executar scripts de longa duração, como para ingerir dados de uma API externa.
- AWS Lambda – O AWS Lambda é um serviço de computação altamente escalável e sem servidor. Usamos para executar scripts simples, como para analisar um único arquivo de texto.
- Amazon Appflow – O Amazon AppFlow permite a integração simples com os aplicativos de software program como serviço (SaaS). Usamos para definir fluxos que carregassem periodicamente dados de sistemas operacionais selecionados em nosso information warehouse.
- Amazon Easy Storage Service (Amazon S3) -Um serviço de armazenamento de objetos que oferece escalabilidade líder do setor, disponibilidade de dados, segurança e desempenho. A Amazon S3 serviu como nossa área de preparação, onde armazenaríamos dados brutos antes de carregá -los em outros serviços, como o Amazon Redshift. Também o usamos como um repositório para armazenar código que poderia ser recuperado e usado por outros serviços.
Onde prático, utilizamos a estrutura de arquivos de nossa base de código para definir recursos. Configuramos nosso AWS CDK para nos referir ao conteúdo de um diretório específico e definir um recurso (por exemplo, uma máquina de estado de funções de etapa da AWS ou um trabalho de cola da AWS) para cada arquivo encontrado nesse diretório. Também fizemos uso de arquivos de configuração para que pudéssemos personalizar os atributos de recursos específicos, conforme necessário.
Detalhes sobre padrões específicos
No diagrama de arquitetura acima, mostramos vários fluxos pelos quais os dados poderiam ser ingeridos ou descarregados do nosso armazém de dados do Amazon Redshift. Nesta seção, destacamos quatro padrões específicos com mais detalhes que foram utilizados na solução remaining.
Padrão 1: Transformação, carga e descarga de dados
Vários de nossos pipelines de dados incluíram etapas significativas de transformação de dados, que foram realizadas principalmente por meio de instruções SQL executadas pelo Amazon Redshift. Outros exigiam ingestão ou descarregamento de dados do information warehouse, que poderiam ser executados com eficiência usando instruções de cópia ou descarga executadas pelo Amazon Redshift.
De acordo com nosso objetivo de usar recursos com eficiência, procuramos evitar a execução dessas declarações dentro do contexto de um trabalho de cola da AWS ou da função lambda da AWS, porque esses processos permaneceriam ociosos enquanto aguardavam a conclusão da instrução SQL. Em vez disso, optamos por uma abordagem em que as tarefas de execução do SQL seriam orquestradas por uma máquina estadual de funções de etapas da AWS, que enviaria as instruções para o Amazon Redshift e verificou periodicamente seu progresso antes de marcá -las como bem -sucedidas ou falhadas. O diagrama seguinte 2 mostra esse fluxo de trabalho.

Diagrama 2: Transformação de dados, carga e padrão de descarga usando Amazon Lambda e Amazon Redshift dentro de uma função de etapa da AWS
Padrão 2: Replicação de dados usando cola AWS
Nos casos em que precisávamos replicar dados de uma fonte de terceiros, usamos a AWS Glue para executar um script que consulteria a API relevante, analisasse a resposta e armazenaria os dados relevantes no Amazon S3. A partir daqui, usamos o Amazon Redshift para ingerir os dados usando uma instrução COPY. O diagrama a seguir 3 mostra esse fluxo de trabalho.

Diagrama 3: Copiando da API externa para o Redshift com a AWS Glue
Nota: Outra opção para esta etapa seria usar Amazon Redshift Auto-Copymas isso não estava disponível no momento do desenvolvimento.
Padrão 3: Replicação de dados usando o Amazon Appflow
Para determinadas aplicações, conseguimos usar os fluxos de fluxo de aplicativos do Amazon no lugar de trabalhos de cola da AWS. Como resultado, poderíamos abstrair parte da complexidade de consultar diretamente as APIs externas. Configuramos nossos fluxos de fluxo de aplicativos da Amazon para armazenar os dados de saída no Amazon S3 e depois usamos uma regra de eventos com base em um Evento de relatório de fluxo remaining (que é um evento publicado quando uma execução de fluxo é concluída) para acionar uma carga no Amazon Redshift usando uma instrução COPY. O diagrama seguinte 4 mostra esse fluxo de trabalho.
Ao usar o Amazon S3 como um armazenamento de dados intermediários, nos demos um controle maior sobre como os dados foram processados quando foram carregados no Amazon Redshift, quando comparados com o carregamento dos dados diretamente no information warehouse usando o Amazon Appflow.

Diagrama 4: Usando o Amazon Appflow para integrar dados externos à Amazon S3 e copiar para a Amazon Redshift
Padrão 4: ETL reverso
Embora a maioria de nossos fluxos de trabalho envolva dados sendo trazidos para o information warehouse de fontes externas, em alguns casos precisávamos que os dados fossem exportados para sistemas externos. Dessa forma, poderíamos executar consultas SQL com lógica complexa, desenhando várias fontes de dados e usar essa lógica para apoiar os requisitos operacionais, como identificar quais grupos de alunos devem receber comunicações específicas.
Nesse fluxo, mostrado no diagrama seguinte 5, começamos executando uma instrução de descarga no Amazon Redshift para descarregar os dados relevantes para os arquivos no Amazon S3. A partir daqui, cada arquivo é processado por uma função da AWS Lambda, que executa todas as transformações necessárias e envia os dados para o aplicativo externo por meio de uma ou mais chamadas de API.

Diagrama 5: fluxo de trabalho reverso ETL, enviando dados de volta para fontes de dados externas
Resultados
O processo de re-arquitetura e migração levou 5 meses para ser concluído, desde o conceito inicial até o descomissionamento bem-sucedido da ferramenta anterior de terceiros. A maior parte do esforço arquitetônico foi concluída por um único funcionário em tempo integral, com outras pessoas na equipe ajudando principalmente na migração de pipelines para a nova arquitetura.
Conseguimos reduções significativas de custos, com despesas finais nos serviços nativos da AWS representando apenas uma pequena porcentagem de custos projetados em comparação com a continuação da ferramenta ETL de terceiros. A mudança para uma abordagem baseada em código também nos deu maior visibilidade de nossos dutos e tornou o processo de mantê-los mais rápido e fácil. No geral, a transição foi perfeita para nossos usuários finais, que foram capazes de visualizar os mesmos dados e painéis durante e após a migração, com o mínimo de interrupção ao longo do caminho.
Conclusão
Usando a escalabilidade e a relação custo-benefício dos serviços da AWS, conseguimos otimizar nossos pipelines de dados, reduzir nossos custos operacionais e melhorar nossa agilidade.
Pete Allen, um engenheiro de análise da Open Universities Australia, diz: “Modernizar nossa arquitetura de dados com a AWS foi transformadora. A transição de uma plataforma externa para uma pilha de análises baseada em código interna melhorou bastante nossa escalabilidade, flexibilidade e desempenho. Com a AWS, agora podemos processar e analisar dados com uma recuperação muito mais rápida, custos mais baixos e maior disponibilidade, permitindo o rápido desenvolvimento e implantação de soluções de dados, levando a idéias mais profundas e melhores decisões de negócios. ”
Recursos adicionais
Sobre os autores
Michael Davies é um engenheiro de dados da OUA. Ele tem uma vasta experiência no setor educacional, com um foco explicit na criação de arquitetura e dutos de dados robustos e eficientes.
Emma Arrigo é um arquiteto de soluções da AWS, com foco em clientes de educação em toda a Austrália. Ela é especializada em alavancar a tecnologia em nuvem e o aprendizado de máquina para enfrentar desafios de negócios complexos no setor educacional. A paixão de Emma por dados se estende além de sua vida profissional, como evidenciado por seu cão chamado Knowledge.