1 of 42

9a Semana da Engenharia da Computação da USP São Carlos

Como construir uma pipeline de dados moderna para melhorar a saúde do Brasil

2 of 42

Quem sou Eu?

Alexsandro dos Santos

Coordenador de Dados - ImpulsoGov

Ciêntista da Computação pela UFABC, professor de programação e engenharia de dados, ex-competidor de robótica, freelancer

ETEC - Técnico em Programação

SENAI - Programador Java�Primeiro Emprego - Scripter de MMOs

Federal do ABC - BC&T e Computação

Fundador da 1a Equipe de Robótica

Fundei ONG de educação

Desenvolvi Projetos de Inovação

Stoodi - Construi do zero todo o ecossistema de dados para personalizar o estudo de milhares de alunos

Wildlife Studios - Responsável pela manutenção das tabelas mais críticas com milhões de eventos diários

E outras dezenas de Organizações e projetos nesses quase 12 anos de carreira…

3 of 42

Quem sou Eu?

Alexsandro dos Santos

Coordenador de Dados - ImpulsoGov

Ciêntista da Computação pela UFABC, professor de programação e engenharia de dados, ex-competidor de robótica, freelancer

Responsável por toda a captura e transformação de dados públicos e sensíveis dentro da ImpulsoGov.

+2 Anos apoiando em projetos e produtos em parceria com governos municipais e estaduais.

Focado em estratégias a longo prazo de arquitetura de projetos e soluções para governos.

4 of 42

Organização sem fins lucrativos e suprapartidária fundada em 2019.

Desenvolvemos soluções e programas gratuitos e de alto impacto para fortalecimento dos serviços e profissionais da Atenção primária no SUS.

Apoiamos diretamente mais de 200 municípios onde vivem 11 milhões de pessoas que dependem exclusivamente do SUS.

5 of 42

Queremos que o SUS se torne o melhor sistema de saúde pública do mundo

Apoiamos governos para que o Brasil tenha um sistema �de saúde que entrega serviços preventivos e resolutivos para toda a população e que esse sistema seja reconhecido por ser inteligente, eficiente e inovador, �além de universal, gratuito e de qualidade.

Acreditamos no uso inteligente dos dados e da tecnologia como caminho para atingir este objetivo. Trabalhamos para que todos os gestores e profissionais de saúde do SUS tenham, em suas mãos, as informações e ferramentas necessárias para agir de maneira eficiente, preventiva �e resolutiva.

6 of 42

A ImpulsoGov tem como produto Impulso Previne, uma solução focada em apoiar municípios com Busca Ativa de cidadãos enquadrados em Linhas de Cuidado. Lidando com dados de centenas de municipios.

é uma estratégia de saúde que consiste em procurar ativamente por indivíduos, como pessoas com esquemas vacinais incompletos ou casos suspeitos de doenças, para garantir que recebam o cuidado necessário.

conjunto de diretrizes e fluxos que organiza o atendimento continuo e integral do paciente, desde a atenção primária até os serviços especializados. Ela visa padronizar e integrar as ações de promoção, prevenção, diagnóstico, tratamento e reabilitação, garantindo que o percurso do paciente pela rede de saúde seja coordenado e resolutivo.

Busca Ativa

Linhas de Cuidado

7 of 42

Nosso Produto Impulso Previne apoia profissionais na ponta da Saúde Primária

Nossa ferramenta apresenta listas nominais que podem ser usadas nas buscas ativas, para priorizar diferentes secções da população a fim de trazer inteligência para o trabalho da Agente Comunitária de Saúde (ACS)

8 of 42

9 of 42

Uma primeira forma

Tudo começou com uma validação: Um script que ao rodar localmente na mesma máquina que o banco de dados extraia um excel.

Mas o excel não é dinâmico, e se múltiplos profissionais precisarem ver? Muitas vezes o computador local nem estava onde o profissional na ponta estava!

10 of 42

Conhecendo mais o Problema

Multiplas UBS enviar dados para o PEC Municipal Centralizado. Que geralmente fica na secretaria de saúde do município ou em uma nuvem contratada, sem acesso dos profissionais que atuam diretamente na UBS!��Como a nossa lista nominal que estava em um arquivo poderia chegar nesses profissionais?

11 of 42

Uma segunda forma como serviço web

12 of 42

Uma segunda forma como serviço web

13 of 42

Novos Problemas…

14 of 42

Novos Problemas…

15 of 42

Uma terceira forma: Agora com uma API de transmissão!

16 of 42

E por fim chegamos mais ou menos na estrutura desejada…

Mas Ainda havia problemas…

Problemas esses que precisavam ser resolvidos de forma mais profunda e usando conceitos de data warehousing.

Nosso banco de dados estava muito pesado, muito caro financeiramente para manter na nuvem e demorando horas para processar os dados dos municípios

17 of 42

E por fim chegamos mais ou menos na estrutura desejada…

  • Até aqui construímos a arquitetura para uma solução baseada em dados, sem se preocupar com conceitos que podem fazer toda a diferença.

  • Para conhecermos esses conceitos precisamos ir para a literatura e entender como problemas parecidos com o que chegamos

18 of 42

Nosso 3 Grandes problemas

Processamento Transacional vs Analitico

Histórico de Mudança do Dados

Observabilidade e Qualidade de Dados

19 of 42

Processamento Transacional vs Analitico

Primeiro:

20 of 42

Processamento Transacional vs Analitico

Primeiro: Nosso Banco era OLTP… Mas estávamos usando como se fosse OLAP!

OLTP: Online Transaction ProcessingOLAP: Online Analytical Processing

21 of 42

Processamento Transacional vs Analitico

Primeiro: Nosso Banco era OLTP… Mas estávamos usando como se fosse OLAP!

https://cetax.com.br/o-que-e-olap/

OLTP: Online Transaction ProcessingOLAP: Online Analytical Processing

22 of 42

Processamento Transacional vs Analitico

Designing Data Intensive Applications

OLTP: Online Transaction ProcessingOLAP: Online Analytical Processing

23 of 42

Processamento Transacional vs Analitico

Desempenho: Otimizado para consultas analíticas em grandes volumes de dados.

Escalabilidade: Lida automaticamente com grandes cargas.

Isolamento: Evita sobrecarregar o banco operacional com análises pesadas

A ferramenta escolhida foi o Google Big Query, um data warehousing serveless da Google que serve a todos os propositos de uma solução OLAP

24 of 42

Processamento Transacional vs Analitico

Ralph Kimball — The Data Warehouse Toolkit (1996)

Martin Keppmann — Design Data-Intensive Applications (2019) capítulo 3 (Storage & Retrieval)

25 of 42

Nosso 3 Grandes problemas

Trocamos um banco de dados transacional OLTP (Postgres) por uma ferramenta analitica OLAP (Google Big Query) ganhando escalabilidade, velocidade e sem onerar processos transacionais da plataforma.

Processamento Transacional vs Analitico

Transformação de Dados em Casa

Observabilidade e Qualidade de Dados

26 of 42

Transformação de Dados em Casa

Nosso transmissor era baseado no primeiro script que fizemos, logo muitas regras de negócio estavam diretamente sendo rodadas antes de serem enviadas para nós. Fazendo um processo de ETL.

Com isso, quando queríamos testar regras de negócio novas, dependíamos de uma nova transmissão de dados, dado que o dado carregado em nosso Big Query já tinha passado por um processo de transformação

Extract, Transform & Load. É o processo que se popularizou em engenharia de dados onde um processo de transformação de dados consiste em extrair da fonte de origem, processar e por fim carregar em seu destino, geralmente um banco de dados ou um sistema de arquivos.

ETL

27 of 42

Transformação de Dados em Casa

28 of 42

Transformação de Dados em Casa

Aspecto

ETL (Extract–Transform–Load)

ELT (Extract–Load–Transform)

Ordem das etapas

Os dados são transformados antes de serem carregados no destino.

Os dados são carregados primeiro e transformados dentro do destino (ex: BigQuery).

Local do processamento

Servidor intermediário (ETL Server, DataFlow, Spark etc.).

No próprio data warehouse (BigQuery, Snowflake etc.).

Complexidade operacional

Exige infraestrutura para processar e mover dados.

Simplifica o pipeline: menos movimentação e dependências.

Escalabilidade

Limitada à capacidade do servidor ETL.

Escala automaticamente com o warehouse serverless.

29 of 42

Transformação de Dados em Casa

30 of 42

Transformação de Dados em Casa

Joe Reis & Matt Housley — Fundamentals of Data Engineering (O’Reilly, 2022) Capítulo 8: Queries, Modeling, and Transformation.

31 of 42

Nosso 3 Grandes problemas

Trocamos um banco de dados transacional OLTP (Postgres) por uma ferramenta analitica OLAP (Google Big Query) ganhando escalabilidade, velocidade e sem onerar processos transacionais da plataforma.

Processamento Transacional vs Analitico

Saimos de uma estratégia ETL e migramos para o ELT, deixando todas as transformações de dados em nossa nuvem e usando o transmissor apenas para extrair esses dados

Transformação de Dados em Casa

Observabilidade e Gerenciamento

32 of 42

Observabilidade e Gerenciamento

33 of 42

Observabilidade e Gerenciamento

34 of 42

Observabilidade e Gerenciamento

35 of 42

Observabilidade e Gerenciamento

O que antes era apenas etapa de dados brutos e processados, agora vira dezenas de etapas de transformações a serem acompanhadas…

  • e se uma demorar demais?
  • E se uma falhar?
  • E se o dado vier vazio em um único município?
  • Como controlar essas falhas?
  • Como aviso o time que cuida do site?

36 of 42

Observabilidade e Gerenciamento

Gerencia a execução de DAGs, onde cada nó é uma tarefa que deve ser executada, armazena seu status, permite que aplicamos tentativas consecutivas em caso de falha e permite alertas caso tarefas ou DAGs inteiras falhem.

No Airflow, um DAG (Directed Acyclic Graph) é um fluxo de tarefas organizado em dependências e ordem de execução, representando um pipeline de dados que o Airflow executa e monitora.

DAG

37 of 42

Observabilidade e Gerenciamento

Great Expectations é uma ferramenta de validação de qualidade de dados que permite definir, testar e documentar expectativas sobre os dados (como valores nulos, faixas de datas ou tipos incorretos), garantindo confiabilidade e transparência nos pipelines de dados.

38 of 42

Observabilidade e Gerenciamento

Great Expectations é uma ferramenta de validação de qualidade de dados que permite definir, testar e documentar expectativas sobre os dados (como valores nulos, faixas de datas ou tipos incorretos), garantindo confiabilidade e transparência nos pipelines de dados.

39 of 42

Nosso 3 Grandes problemas

Trocamos um banco de dados transacional OLTP (Postgres) por uma ferramenta analitica OLAP (Google Big Query) ganhando escalabilidade, velocidade e sem onerar processos transacionais da plataforma.

Processamento Transacional vs Analitico

Saimos de uma estratégia ETL e migramos para o ELT, deixando todas as transformações de dados em nossa nuvem e usando o transmissor apenas para extrair esses dados

Transformação de Dados em Casa

Observabilidade e Qualidade de Dados

Trouxemos validação de dados e gerenciamento de tarefas, usando de ferramentas como Airflow e Great Expectations

40 of 42

3 Livros para quem quer ser arquiteto de soluções de dados

41 of 42

Obrigado!

Espero que tenha sido proveitoso!

42 of 42

Vem Trabalhar na ImpulsoGov !

Engenheiro de Software

Banco de Talentos

www.linkedin.com/in/alexsandr0x

www.linkedin.com/company/impulsogov