Projeto Painel COVID-19 — Parte I
Olá pessoal.
Ano passado criei alguns dashboards com os dados da COVID-19 no Brasil, porém ainda eram painéis meio básicos, sem muita técnica. Nesse ano, inspirado pelo livro Storytelling com Dados, resolvi recriar meus dashboards.
Mas desta vez fui um pouco além e estruturei melhor os dados e criei efetivamente um processo de ETL, como vou descrever mais abaixo.
Todos os arquivos do projeto podem ser encontrados neste repositório do meu GitHub:
Esta primeira parte é mais técnica e vou mostrar como montei o processo de ETL. Mas não se assuste! A Parte II fica mais leve com o processo de criação dos graficos bonitinhos no PowerBI. 😁
Ainda é um MVP, mas já está bem legal. Vem junto!
O problema e as perguntas a serem respondidas
A ideia destes dashboards é responder inicialmente a 3 perguntas:
- Evolução de casos no Brasil
- Comparações entre as regiões do país
- Evolução dos casos no Paraná, aproveitando os dados de sexo e idade que são disponibilizados nesta base.
Modelo CRISP-DM
Não vou entrar muito neste modelo, pois o assunto iria longe, mas a base para a construção de todo o projeto (e também deste artigo) foi o framework CRISP-DM.
Explodindo um pouco essas fases, temos algo mais ou menos assim:
- Definição do problema e perguntas a serem respondidas
- Planejamento do processo de Data Science
- Coleta de dados
- Processamento e limpeza dos dados
- Armazenamento dos dados
- Análise de dados
- Construção e validação de algoritmos e modelos
- Data Visualization
- Disseminação da informação
- Deploy
A origem dos dados
Basicamente 2 fontes de dados são utilizadas:
- Coronavírus Brasil (saude.gov.br): Contém os dados consolidados de todo o país, com dados agrupados diariamente por: Região, Estado, Município, data, casos comprovados, recuperados e óbitos acumulados e novos e também população (informação muito importante).
- Campanha | Coronavírus (coronavirus.pr.gov.br): Contém os dados dos Municípios do Paraná. Esta base tem algumas informações diferentes, como idade e sexo que podem ser usadas para análises mais interessantes.
Além disso, também uso uma planilha com as coordenadas geográficas de todos os Municípios. Um dos próximos passos é utilizar esta informação para inserir os dados em mapas, mas isso é outra história…
Construção do ETL
Todo o processo de ETL foi feito no Pentaho Data Integration. Através dele são importadas as planilhas que, na sequência, são armazenadas em uma Stage. A partir da Stage, os dados passam por algumas transformações, como mostrarei abaixo sendo por fim armazenados em um DataWarehouse.
Importações:
- Os arquivos de casos confirmados e óbitos obtidos do site do Governo do Paraná são importados e armazenados na Stage:
- O arquivo obtido do site do Ministério da Saúde não passa pela Stage, pois era um processo muito lento e não teria um ganho aparente no processo. Neste caso ele é importado, tratado e enviado diretamente para o DW.
Transformações e Feature engineering:
As maiores transformações são feitas nos dados do Estado do Paraná, pois aproveito as informações de população vindas do arquivo do MS e também crio algumas features.
Inicialmente faço um merge com os dados de “população”, que são obtidos da mesma planilha do Ministério da Saúde.
Na sequência do processo, utilizo 2 value mappers para criar uma nova feature de “faixa etária” e outra, chamada RMC, para identificar os municípios da Região Metropolitada de Curitiba. Os municípios são categorizados de 3 formas: NUC (Núcleo Urbano Central), Vale do Ribeira e, o que não der “match”, ficou como interior.
Exportações:
No final as tabelas no MySQL ficaram assim:
Finalmente o job!
Vamos juntar tudo isso num job só? Fácil!
Em um formato serial, o job começa verificando a conectividade com os bancos de dados Stage e DW e, caso a conexão seja estabelecida com sucesso, as transformações são iniciadas a partir da importação dos arquivos CSV e XLS para a Stage e depois fazendo as transformações já citadas. E… SUCESSO!
Em casa de falha de qualquer um dos steps, o job é abortado. Muitas coisas poderaim ser feitas quando isso acontece, como: enviar uma alerta, salvar em um log ou executar um script, mas por enquanto estou apenas cancelando tudo.
E o container? Tem container?
Temos!
No meu artigo Building a Docker image, que está lá no Medium, mostrei como criar e modificar a sua própria imagem do Jupyter Notebook utilizando o Docker.
Para armazenar os dados deste projeto estou usando a imagem original e oficial do MySQL no Docker ( mysql — Docker Hub). Lembrando que todos os dados salvos no container são perdidos quando ele é desligado, então a única alteração que precisei fazer é para persistir os dados em disco. Mas para isso basta montar a pasta onde deseja salvar os bancos de dados na pasta padrão de dados do MySQL, através do parâmetro — mout do docker:
--mount type=bind, src=/CAMINHO/PARA/PERSISTIR/OS/DADOS, dst=/var/lib/mysqlWhat’s next?
No próximo artigo, além de mostrar como montei o dashboard no PowerBI, também terá um pouco de storytelling com dados e o famoso DAX.
Mas, para quem ficou curioso, já vai uma ideia de como está ficando:
Originally published at https://www.linkedin.com.