Conforme falamos em nosso texto anterior, selecionar o conjunto de ferramentas utilizado para montar um projeto não é uma tarefa nada fácil, já que é nesta etapa que serão definidas todas as capacidades e restrições do sistema que está sendo desenvolvido.

‍

Para escolher o menor conjunto possível de componentes, que também atendessem a todas as nossas necessidades, fizemos uma lista de todos os pontos que procurávamos  nas ferramentas que estavam buscando: 

‍

1. Privacidade e segurança: os dados teriam de ser armazenados de maneira segura e precisávamos ter um controle de acesso granular e inviolável;
2. Escalonamento: todos os componentes devem funcionar bem para cargas de trabalho pequenas e também suportar cargas de trabalho maiores;
3. Liberdade: como estamos hospedando nossos serviços em nuvem, gostaríamos de ter a possibilidade de transitar entre provedores com facilidade. Pensando nisso, optamos por usar software livre;
4. Possibilidades: poder usufruir por completo de uma linguagem de programação, como Python, ou de consulta, como SQL, nos permite fazer trabalhos extremamente complexos e replicáveis e é uma característica que procurávamos; 
5. Descentralização: hospedar cargas de trabalho de todos os órgãos da prefeitura em servidores separados permite um maior controle sobre os custos de cada órgão e dificulta condições em que cargas de trabalho de um órgão poderia onerar outro;
6. Simplicidade: menos é mais. Um sistema com poucos componentes é muito mais fácil de ser mantido.

‍

Com as características priorizadas, nossa seleção de componentes ficou assim: 

‍

‍

Agora, vamos para a explicação de cada item selecionado:

‍

Prefect

Para realizar a extração de dados, a ferramenta selecionada foi o Prefect. De código aberto, ela permite a automação de qualquer tarefa por meio da sua API, em Python.

‍

Por possuir uma interface simples, é extremamente fácil modificar seu código para usufruir de suas funcionalidades. Além da bela interface que ele possui, duas caraterísticas foram decisivas para a sua escolha:

‍

1. Confiança: é muito simples lidar com falhas no Prefect, o que impede de quebrar um fluxo se algum errado fora do comum acontecer. Além disso, em nossos testes preliminares, conseguimos executar mais de 10 mil pipelines por dia, consumindo poucos recursos sem problemas.
2. Modelo híbrido de execução: esse deve ser o item mais apelativo para todos que aderem ao Prefect. Seu modelo híbrido permite que a hospedagem do servidor, do código e do ambiente de execução sejam feitas em lugares diferentes, sem que isso comprometa seu funcionamento. Desta forma, garantimos a segurança da execução do código e também sua descentralização. Assim, é possível executar pipelines de um órgão em um servidor enquanto ocorre o mesmo com a pipeline de outro órgão; todas elas visíveis em uma mesma interface.

‍

DBT

Aqui é onde a galera do SQL fica animada. O DBT é uma ferramenta de código aberto que permite a definição de modelos de dados em linguagem SQL. Com ele, é possível materializar os resultados de uma query em diferentes formas e em diferentes plataformas, como o Google BigQuery, Amazon Redshift, PostgreSQL, entre outros.

‍

Assim, com a mesma query é possível criar tabelas e views em diferentes plataformas. E não só isso, as tabelas podem ser materializadas de maneiras diferentes, como, por exemplo, de forma incremental, o que consiste em adicionar novas linhas ao final de uma tabela (sem ter que usar funções de merge ou append).

‍

Além de tudo, você pode parametrizar suas queries para que elas sejam executadas com diferentes valores de entrada, coma opção de especificação de configurações de particionamento diretamente no seu modelo de dados. É uma ferramenta bem completa, ajudando muito em nossas pipelines de dados.

‍

Google Cloud Storage e Google BigQuery

Apesar de priorizarmos o software de código livre, optamos por uma iniciativa privada para nosso armazenamento de dados. Neste caso em específico, as ferramentas apresentadas pela Google atenderam todos os requisitos que havíamos levantado, além de reduzirem o número de componentes para apenas dois ao contrário dos múltiplos open-source que teríamos que manter em conjunto. Os componentes que utilizamos são:

‍

Google Cloud Storage: é um serviço de armazenamento de objetos. Por meio de API é possível fazer upload de qualquer tipo de arquivo, configurar suas permissões e, caso tenha acesso, realizar o download dos dados. Além disso, é possível utilizá-lo como um data lake, armazenando arquivos na mesma estrutura de partições Hive e obtendo seus dados particionados para consulta.

‍

Google BigQuery: um serviço de data warehouse serverless. Ele permite análises escalonáveis em petabytes de dados. Com a união dessas duas ferramentas, conseguimos manter um data lake e um data warehouse públicos e com pouco esforço.

‍

Garantindo o legado

Pensando não só no legado para o município, como também na responsabilidade de manutenção deste projeto de transparência para os próximos governos, divulgamos nossas escolhas e suas razões.

‍

Também disponibilizamos publicamente, em nosso GitHub, diversos artefatos que permitem a replicação da infraestrutura proposta com pouca ou nenhuma modificação, garantindo também o monitoramento público por qualquer cidadão.

‍

A ideia do Datalake é para o bem público, e, por isso mesmo, pensamos que todos os aspectos relativos a sua criação e manutenção também deveriam ser acessíveis a toda sociedade.

‍