Criando um ambiente de dados analíticos com terraform

Published in

Creditas Tech

9 min readAug 2, 2021

Este texto tem como objetivo apresentar as vantagens e a implementação de serviços de um ambiente de dados analítico utilizando terraform.

Mas você sabe o que significa um ambiente de dados analítico? E o que é terraform?

Descrevendo o tal ambiente de dados analítico

O ambiente de dados analítico aqui descrito representa o caminho que os dados trafegam desde a extração do ambiente de produção de um produto (CRM, web app, mobile app, …) até a disponibilização destes para análises, visualizações e modelos preditivos.

A grande vantagem de ter este ambiente desenvolvido na sua empresa é habilitar a tomada de decisões de negócio baseadas em dados. Isso significa, por exemplo, que os números de novos acessos em seu serviço após aquela mudança na interface serão utilizados para avaliar se investir em modificações parecidas vale o esforço do time. Ou seja, estes números são muito valiosos para a empresa conseguir investir em caminhos que trarão maior rentabilidade e também para descobrir novos caminhos que só puderam ser idealizados devido às análises. Mas para estes números serem analisados, dependendo do volume e também da variedade de fontes de dados, é necessário migrá-los para uma estrutura específica para análises, que é o ambiente de dados analíticos!

Como já descrito, o ambiente analítico é um caminho por onde os dados passam. Mas quem faz esses dados passarem? Neste nosso caso, são os serviços que fazem processamentos destes dados e vão movendo e moldando para atingir diferentes necessidades dos usuários. Os dados extraídos são armazenados crus, adjetivo utilizado para definir um dado que está igual na origem, ou seja, igual ao ambiente de produção do produto. Estes dados crus são transformados para dar início à geração de dados para análises. Após as transformações, estes dados são formatados de forma a serem facilmente analisados. As análises são feitas por meio de ferramentas com grande capacidade de processamento de dados que possuem os dados salvos ou extraem os dados armazenados e processados.

Cada etapa deste caminho é formada por vários serviços de dados que serão descritos em conjunto com as explicações de terraform. Estes serviços são exemplos que podem ser adotados para desenvolver um ambiente analítico e representam o ambiente da Creditas de forma simplificada.

Colocando este tal de terraform na brincadeira

Os serviços descritos anteriormente estão na nuvem e precisam ser configurados e gerados. Obviamente, você pode fazer isto manualmente, utilizando o Console da AWS, por exemplo, e indo em cada serviço para configurar e gerar os recursos. Entretanto, vamos seguir o lema de automatizar tudo o que puder. E é por isso que o terraform se insere neste contexto.

Terraform é uma forma de transformar a criação manual de serviços na nuvem em código. Ele entra no conceito famoso de Infrastructure as Code (IaC) [1]. Então toda criação do serviço, desde a configuração até a geração dele, é automatizada utilizando um pedaço de código escrito em terraform.

Espero que eu não tenha já te convencido que terraform é uma boa opção somente por causa do lema que comentei. Claro que automatizar tem seus ganhos, mas vamos falar mais a favor do uso do terraform para enriquecer a argumentação.

Vantagens do Terraform

- Padronização

Todos os padrões que cada recurso deve possuir serão garantidos por código em todos os desenvolvimentos.

- Automatização

A criação dos recursos é feita por código e independe de erros manuais.

- Colaboração

Como todo código, é passível de ser desenvolvido por mais de uma pessoa e também ser revisado pelo time.

- Documentação

Todos os argumentos necessários para aplicar um recurso estão descritos no código e podem ser considerados como uma documentação em si.

- Código aberto

O terraform é mantido por uma grande comunidade engajada em manter boa qualidade e usabilidade. E você também pode fazer parte dela!

Agora sim, espero que esteja tenha te convencido! E vamos começar a demonstrar como criar o ambiente analítico com o terraform.

Construindo o ambiente analítico com terraform

É importante pontuar, novamente, que o ambiente analítico descrito aqui é uma simplificação do que temos hoje na Creditas. Há milhares de formas de construir este ambiente, com serviços diferentes, em outras nuvens (GCP, Azure) e também on-premise. Também, alguns pontos da infraestrutura não foram mencionados, como as permissões de acessos de alguns serviços aos outros, seja por rede ou por outros controles de acessos.

A extração

Começamos aqui pela extração dos dados do ambiente de produção dos produtos da Creditas para armazenamento dentro do ambiente analítico. No nosso caso, este ambiente de produção é formado por bancos de dados PostgreSQL [2] e o armazenamento é feito no serviço AWS S3 [3]. Para esta extração dos dados destes bancos utilizamos um serviço chamado Data Migration Service (DMS) [4].

Demonstração da conexão dos recursos no serviço DMS, sendo o primeiro um bloco representando o Source Endpoint. Este é ligado ao círculo que representa a Replication Task, que está dentro do bloco da Replication Instance. E por fim, a Replication Task está ligada ao Target Endpoint, que finaliza os recursos que compõem o DMS. — *FIGURA 1 — Processo de replicação do DMS (https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html*)

A figura 1 apresenta o processo de replicação com os recursos necessários ao DMS. Este serviço é representado no terraform pelos seguintes códigos.

Este pedaço de código é formado por quatro recursos, sendo eles: a tarefa de replicação, a origem da replicação, o destino da replicação e a instância de replicação. Os argumentos entre as chaves de cada um formam a configuração desejada para o recurso. No caso apresentado, temos o endpoint do tipo origem com o mecanismo postgres e outro endpoint do tipo destino com o mecanismo s3. A tarefa de replicação é do tipo “full-load-and-cdc”, conhecido como Ongoing, que é o modo incremental de extração usando as informações de Change Data Capture (CDC) [5] do banco de dados. Todos os recursos possuem o argumento tags, que é muito importante para facilitar a identificação de recursos. Adicionalmente, temos o recurso AWS Secrets Manager [6], que é indispensável para garantir segurança na utilização de senhas. Para aprofundar e entender os outros argumentos, há a documentação destes recursos no próprio site do terraform [7].

O armazenamento

Depois de extraído, os dados são salvo no serviço AWS S3 [3], um armazenador de objetos. Este armazenador faz parte de um nome famoso da área de dados: o Data Lake [8]. O Data Lake é formado por camadas, que no nosso exemplo são três: raw, refined e ready. A camada raw e refined se encontram em um recipiente do S3 chamado bucket. Já a camada ready se encontra no serviço AWS Redshift [9] que vamos comentar mais adiante. Onde os dados crus, ou seja, sem transformação, repousam depois de extraídos denomina-se camada raw. Esta camada, como também a camada refined, são pastas de objetos separadas dentro do bucket, como se fossem pastas de arquivos de um computador mesmo. Abaixo está o código para criação do bucket no S3.

A criação do bucket por terraform é simples, sendo que o argumento bucket ou bucket_prefix só é necessário caso você tenha necessidade de definir um nome ou prefixo deste nome enquanto os outros argumentos são opcionais. No nosso caso, supondo que estamos tratando do bucket do Data Lake, além de definir o nome, precisamos garantir versionamento e logging para fins de auditoria e facilitar a manutenção, replicação para facilitar o recovery e backup, e criptografia para segurança dos dados. Mais informações sobre esses argumentos e outros são encontrados na documentação [10].

O processamento

Conforme foi dito, a camada raw e camada refined são pastas separadas dentro do bucket do Data Lake. Já entendemos que a camada raw recebe os dados crus extraídos pelo DMS. Agora chegamos na parte de processamento destes dados crus que depois serão salvos na camada refined. Este processamento é feito utilizando o serviço AWS Glue [11] a partir da definição de um código para processamento do dado e algumas configurações do cluster responsável pela execução deste código. Assim, é possível criar uma receita com localização do código para processamento do dado e configurações do cluster utilizando terraform que pode ser vista abaixo.

Neste exemplo, o código para processamento do dado está salvo no S3 e a linguagem é Python3. O argumento role_arn é responsável por permitir acesso aos recursos necessários, como ao S3 para acessar o código de processamento e à origem e destino dos dados do processo. Outros argumentos podem ser encontrados na documentação [12].

A disponibilização

Finalmente chegamos na camada ready do Data Lake e na disponibilização do dado. Aqui, o dado passou novamente por processamento feito pelo Glue e está agregado e formatado conforme necessidade das unidades de negócio. O serviço presente é o AWS Redshift [9], um banco de dados feito para análises complexas nos dados.

Como definimos no bucket do S3, aqui também é importante termos criptografia, logging e, para garantia de backup e recovery, snapshots programados por padrão. Para conhecer outras opções oferecidas no recurso, dê uma olhada na documentação do terraform [13].

Aplicando os recursos

Agora temos todos os serviços com seus respectivos recursos definidos por terraform e para subir isso na nuvem?

Não é o foco aqui aprofundar em como desenvolver a infraestrutura responsável por aplicar os recursos na nuvem, mas vamos pincelar como ela funciona. Todos os códigos anteriores precisam ser salvos em um projeto com a extensão .tf e mais alguns arquivos precisam ser definidos. Primeiro, podemos falar de um arquivo chamado backend.tf. Nele, definimos a versão do terraform com o backend a ser utilizado, que no nosso caso é o S3, e também o provider, que no nosso caso é a aws. Esse backend é onde o estado dos recursos serão salvos e garantem que os desenvolvimentos acontecerão de forma incremental, sempre se referindo ao último estado salvo.

Outro arquivo importante é o backend.conf, onde vamos configurar mais algumas partes deste processo. Neste arquivo, definimos a criptografia dos dados, em qual bucket e região o estado será salvo no S3 e qual chave é usada na identificação dentro do bucket. Talvez agora você esteja pensando sobre como é controlado o conflito entre versões de estados sendo modificadas ao mesmo tempo e é aqui também neste arquivo que temos a resposta. Há também a definição de um DynamoDB [14], um bando de dados que, usando a mesma chave definida para o bucket, trava a atualização daquela linha que representa o estado da infraestrutura e só abre para novas mudanças após o processo de aplicação ter sido finalizado. Assim, ao executar processos de aplicação concorrentes, um dos processos precisa esperar pelo outro finalizar para planejar a aplicação e, se confirmado pelo usuário, aplicar as modificações. Este arquivo e também o backend.tf estão exemplificados abaixo.

Por fim, é importante comentar que há outros componentes reconhecidos pelo terraform que podem ser utilizados para simplificar o código, como as variáveis e as definições em locals. Vale se aprofundar e não ter medo de ler as documentações que são muito bem explicadas e cheias de exemplos [15].

Conclusão

O ambiente de dados analíticos é importantíssimo para que as decisões de negócio impulsionem o crescimento da empresa. Para o desenvolvimento deste ambiente de forma automatizada, a proposta deste texto é usar terraform para codificar a aplicação da infraestrutura na nuvem. Utilizando-se de código, além de automatizar a construção da infraestrutura, garantimos a padronização, documentação e colaboração.

Por meio do terraform, montamos um ambiente simples de dados analíticos iniciando da extração do ambiente de produção de um produto até a disponibilização de um dado formatado para análise. Consideramos um banco PostgreSQL como sendo o banco do produto e a extração dos dados deste banco é realizada pelo serviço AWS DMS. Os dados desta extração repousam no serviço AWS S3, um armazenador de objetos. Considerando que os dados da extração não estão formatados pensando em análise dos dados, um processo do serviço AWS Glue é utilizado para transformar os dados e salvá-los em seguida no serviço AWS Redshift. Este último é um banco de alta performance para análises complexas onde os dados são finalmente disponibilizados aos usuários. Todo este caminho do dado possui requisitos de segurança que devem ser atendidos, como criptografia e armazenamento seguro de senhas que foram incluídos no código. Um desenho resumido do que foi montado pode ser visto na figura 2.

Imagem representando o ambiente de dados demonstrado no artigo. Começando pela esquerda, temos um RDS ligado ao DMS, seguido por três buckets Amazon S3, um em cima do outro, sendo um o principal e os outro, de logging e réplica. Depois temos o serviço AWS Glue e por fim, mais à esquerda, o Amazon Redshift. Os recursos estão alinhados horizontalmente e ligados por setas, que os ligam da esquerda para direita. — Figura 2 — Ambiente analítico

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa Tripulação! Você pode conferir nossas vagas aqui.