Pipelines de dados eficientes na AWS

9 min readApr 11, 2023

Análise de dados eficiente é uma atividade crucial para as empresas atualmente. Empresas que buscam se manter competitivas estão constantemente explorando seus dados em busca de maneiras de encantar os clientes ou melhorar seus produtos. Da mesma forma, empresas em crescimento estão em busca de diferenciais para impulsionar seus negócios com base nos dados disponíveis.

Nesse contexto, empresas consolidadas possuem a vantagem de terem uma grande quantidade de dados disponíveis para alimentar suas iniciativas de inovação. Enquanto isso, empresas mais novas podem aproveitar a agilidade na construção de pipelines de dados, muitas vezes não viável em estruturas maiores, utilizando as tecnologias disponíveis no mercado.

O que essas empresas têm em comum é a necessidade de crescimento. Uma empresa que não está se expandindo de alguma forma está, inevitavelmente, fadada à extinção, com raras exceções. Neste artigo, irei abordar dois tipos de pipelines de processamento de dados que podem ser utilizados para impulsionar a extração de conhecimento a partir dos dados, de forma escalável e fornecer insumos para a produtização das análises pelas áreas de negócio.

Entendendo pipelines de análise de dados

Os pipelines de dados são uma sequência de ações ou um conjunto de passos para transformar e enriquecer os dados, com o objetivo de torná-los úteis para os consumidores.

Vamos refletir juntos: dados incorretos são úteis? Dados incompletos são úteis? Dados cujo significado é desconhecido são úteis? Perceba que intuitivamente esperamos que os dados tenham algumas qualidades que na maioria dos casos não possuem por padrão, e é nesse contexto que os pipelines de dados são construídos para resolver essas questões de forma eficiente.

Abordagens para os pipelines de dados

Existem muitas abordagens para construir um pipeline de processamento de dados, e ao longo dos anos, várias ferramentas têm contribuído para aprimorar essa prática. Uma mudança significativa que ocorreu desde quando essa disciplina era chamada apenas de processamento de dados até hoje é a facilidade de acesso ao poder computacional e ao armazenamento sob demanda. Muitos problemas que eram complexos no passado simplesmente não existem mais, já que agora é possível subir um cluster de Hadoop com 100 máquinas em menos de 30 minutos, processar o que é necessário e destruí-lo em seguida. Por isso, não se trata de dizer que o que era feito antes estava errado ou era ineficiente, mas sim que hoje não precisamos nos preocupar com muitos aspectos graças à computação em nuvem.

Nesse contexto, existem duas maneiras distintas de construir pipelines de dados, cada uma com suas características próprias e nuances que fazem toda a diferença para uma implantação bem-sucedida nos “Novos Pipelines de Processamento de Dados”.

Pipelines de dados orquestrados

Os pipelines orquestrados buscam criar um fluxo altamente controlado de ações, com cada etapa cuidadosamente mapeada e documentada, descrevendo todas as transformações que devem ser aplicadas aos dados, incluindo notificações, desde o início até o consumo.

Exemplo de pipeline de dados com Apache Airflow — Fonte: step-by-step-build-a-data-pipeline-with-airflow

Essa abordagem permite construir e gerenciar os pipelines com o uso de ferramentas visuais, como o Apache Airflow ou o AWS Step Functions, que implementam o fluxo documentado, tornando concreta a ideia original que foi documentada. Podemos pensar nesse tipo de solução como uma linha de montagem, onde se o problema que está sendo resolvido se encaixa em uma linha de montagem, talvez possa ser adequado para um pipeline orquestrado.

Pipelines de dados orientados à eventos

Existem algumas dificuldades evidentes ao lidar com fluxos de dados implementados com a abordagem anterior de orquestração, especialmente em casos de alta complexidade.

A complexidade não se limita apenas às ações que devem ser executadas, mas também ao momento de execução. Imagine um cenário em que uma linha de montagem, que antes era bem documentada, está enfrentando problemas de disponibilidade de peças, resultando em interrupções graves. Por exemplo, se uma peça do motor não está disponível e só estará disponível daqui a 3 dias, não podemos parar toda a linha de montagem para esperar por essa peça. No entanto, gostaríamos de executar todas as ações possíveis que não dependam dessa peça, reservar o trabalho e, assim que a peça estiver disponível, desbloquear toda a montagem e o trabalho que dependiam dela. Agora, imagine que não é apenas uma peça, mas várias peças, tornando a situação ainda mais complexa. Vamos além e agora não estamos mais falando apenas de uma linha de montagem automotiva, mas sim de centenas de arquivos de parceiros que são disponibilizados a qualquer momento indefinido, sem termos controle sobre eles, e que precisamos processar assim que estiverem disponíveis. Como seria a abordagem orquestrada para resolver esse problema agora?

Esses exemplos servem apenas para refletir sobre as dificuldades de implementar pipelines de dados com esse nível de complexidade, onde a abordagem orientada a eventos pode ser uma solução.

Quando adotamos uma abordagem orientada a eventos em um pipeline de dados, construímos processamentos isolados que são acionados ou disparados de forma independente, ou seja, esses processamentos isolados, que podem ser chamados de ações, não têm conhecimento do contexto anterior, sendo assim “stateless”. O modelo almejado é que cada ação seja acionada por meio de um acordo (protocolo), realize a ação planejada e comunique que concluiu.

Para uma analogia diferente e ajudar também a enraizar esses conhecimento, leia o artigo do Clovis Chedid sobre Arquiteturas orientas a eventos

Chegamos então a um modelo capaz de lidar com esse tipo de complexidade, pois suas ações são acionadas apenas quando existem os insumos necessários para realização daquela ação e no momento adequado.

No caso do fluxo de montagem automotiva, é como se houvesse uma área dedicada para a montagem de cada componente que pudesse ficar inativa por tempo indeterminado, sem incorrer em custos relevantes, para que, quando todas as peças necessárias para montar o motor estiverem disponíveis, essa área seja simplesmente ativada, o motor seja montado e entregue no local onde outras áreas aguardam o motor como insumo para iniciar suas próprias ações, e então voltasse a ficar inativa. E, se for feito de maneira correta, utilizando computação em nuvem altamente escalável, permitirá a montagem de 1 motor ou milhares de motores ao mesmo tempo, cobrando apenas pelo tempo e recursos necessários durante a execução da ação.

Implementando um pipeline de análise de dados na AWS

Pipelines de dados orquestrados na AWS

Para implementar um pipeline de dados orquestrados na AWS, contamos principalmente com dois serviços especializados nessa função: o AWS Step Functions e o Managed Workflows for Apache Airflow (MWAA).

O AWS Step Functions é um serviço de orquestração de pipelines de trabalho visual, com geração automática de código para integração contínua e desenvolvimento low-code visual, que permite criar pipelines baseados em steps, que são as ações mencionadas anteriormente. A grande vantagem do AWS Step Functions é sua integração com o restante da estrutura da AWS e sua arquitetura serverless escalável e tolerante a falhas, que garante confiabilidade e disponibilidade dos pipelines de trabalho de dados. O AWS Step Functions cobra apenas quando é utilizado, com um preço de $0,025 por 1.000 steps, ou seja, $0,000025 por ação executada. Isso torna essa solução eficiente em termos de custo, com baixo custo operacional, sendo altamente recomendada para a maioria dos pipelines orquestrados de dados.

Por outro lado, o Managed Workflows for Apache Airflow (MWAA) é um serviço gerenciado da AWS para executar o Apache Airflow, similar ao Amazon RDS para Apache Airflow. O MWAA oferece a flexibilidade e escalabilidade do Apache Airflow, combinado com os recursos gerenciados da AWS, como escalabilidade automática, monitoramento integrado e integração com outros serviços da AWS. O Managed Workflows for Apache Airflow (MWAA) começa a partir de aproximadamente $360 mensais em sua menor configuração de hardware, o que equivale a mais de 10 milhões de execuções do AWS Step Functions. Portanto, se não tivermos muitos pipelines executando ao longo do dia, ou não estivermos migrando DAGs do Apache Airflow para a AWS, o MWAA pode se tornar caro, sem entregar a infraestrutura serverless do AWS Step Functions.

Pipelines de dados orientados à eventos na AWS

Existem alguns serviços comuns utilizados na AWS para pipelines orientadora a eventos, como o Amazon Simple Queue Service (SQS), o Amazon Simple Notification Service (SNS), o Amazon EventBridge e o Amazon Managed Streaming for Apache Kafka (MSK).

O SQS e o SNS são serviços de mensageria que possibilitam a comunicação assíncrona entre componentes de uma aplicação distribuída. O SQS é uma fila de mensagens que permite o armazenamento e processamento de mensagens em uma abordagem “ponto a ponto”, enquanto o SNS é um serviço de notificação que permite o envio de mensagens para múltiplos destinos, seguindo o padrão “publicar/assinar” (pub/sub). Juntos, o SQS e o SNS possibilitam a construção de arquiteturas de dados orientadas a eventos, em que os eventos são publicados em tópicos do SNS e consumidos por filas do SQS, garantindo escalabilidade e confiabilidade na troca de mensagens assíncronas entre os componentes do sistema.

O Amazon EventBridge é um serviço de integração de eventos que permite a centralização e roteamento de eventos em tempo real entre diferentes serviços da AWS, além de integrações com aplicativos SaaS de terceiros. Ele oferece uma maneira simples e eficiente de definir regras de roteamento de eventos com base em padrões ou regras personalizadas, facilitando a implementação de arquiteturas orientadas a eventos nos pipelines de processamento de dados.

Exemplo de fluxo de eventos com Amazon EventBridge — Fonte: Building an event-driven application with Amazon EventBridge

O Amazon Managed Streaming for Apache Kafka (MSK) é um serviço gerenciado de streaming de dados que permite a ingestão, processamento e análise de fluxos de eventos em tempo real usando o Apache Kafka, similar ao MWAA, porém para o Apache Kafka.

Quando se trata de comparar os serviços, a escolha depende do cenário específico. O SQS e o SNS são ideais para casos em que a troca de mensagens assíncronas é necessária, com a capacidade de armazenar e processar mensagens em filas de mensagens, e rotear eventos para múltiplos consumidores usando o SNS. O EventBridge é uma escolha poderosa quando a centralização e o roteamento de eventos em tempo real entre serviços da AWS e aplicativos SaaS de terceiros são necessários, com suporte a regras de roteamento. Já o MSK é mais adequado para cenários em que a ingestão, processamento e análise de fluxos de eventos em tempo real utilizando o Apache Kafka gerenciado na AWS são necessários.

Conclusão

Em resumo, os pipelines de dados eficientes na AWS têm se tornado fundamentais para as empresas que buscam alavancar seus negócios por meio da análise de dados. Com a facilidade de acesso ao poder computacional e de armazenamento na nuvem, surgiram abordagens distintas para a construção de pipelines, como os orquestrados, que permitem um fluxo altamente controlado de ações e podem ser gerenciados visualmente com ferramentas como o Apache Airflow ou o AWS Step Functions.

Por outro lado, os pipelines orientados à eventos têm se destacado pela flexibilidade em lidar com complexidades e dependências entre ações, permitindo a execução de tarefas parciais e a retomada de fluxos interrompidos, o que pode ser especialmente útil em cenários dinâmicos e em constante mudança.

Ambas as abordagens têm suas vantagens e podem ser escolhidas de acordo com a necessidade e contexto de cada empresa, proporcionando uma base sólida para a extração de conhecimento e produtização das análises de dados. Com a utilização de pipelines de dados eficientes na AWS, as empresas têm a oportunidade de obter insights valiosos e se manterem competitivas em um cenário cada vez mais orientado por dados.