search

splor-mg / atividades

Gestão de tarefas
0 stars 0 forks source link

Estudar viabilidade de simplificar códigos repositórios ETL #148

Open gabrielbdornas opened 1 month ago

gabrielbdornas commented 1 month ago

@labanca, @hslinhares, conforme conversamos na reunião para debugar este PR, pretendo analisar a viabilidade de simplificarmos os códigos de nossos repositórios de ETL. @carloshob não estava presente, mas incluo aqui para conhecimento e acompanhamento.

Inicialmente utilizei somente o repositório dados-armazem-siafi-2024 como referência, mas espero que vocês pensem nos demais processos existentes em outros repositórios.

A conclusão que cheguei trabalhando neste PR é que hoje temos 4 tecnologias envolvidas no fluxo, a saber:

No meu entendimento, a exigência do Docker se justifica pela dificuldade de instalação de ferramentas, principalmente R, e pela utilização de diferentes tipos de sistemas operacionais. Sendo assim, eliminando os códigos R não precisaríamos de dar manutenção em Imagens Docker, assim como sua gestão no DockerHube.

Outro ponto de atenção é a facilidade de encontrarmos pessoas qualificadas para dar manutenção nestas ferramentas. Penso que encontrar uma pessoa que sabe uma tecnologia seja mais fácil do que uma pessoa que saiba 4. Não que ela não possa aprender, mas em uma situação de urgência isso ficaria mais complicado.

Refatorações exigidas

Melhorias anteriormente previstas

[^1]: Apenas uma sugestão de nome de um pacote que guardaria funções diversas para nosso trabalho.

labanca commented 1 month ago

@gabrielbdornas sou da opinião que o dpm pode absorver todas as funcionalidades que são relacionadas ao ciclo de vida dos nossos datapackages: Criar, instalar, transformar, validar, concatenar, testar, etc.

Mas outras categorias de funcionalidades, como testes de regras de negócio orçamentárias, deveriam estar em outro lugar. No caso já tivemos a ideia de criar o pacote checks para testes, mas o projeto ficou parado e muito foi feito sob demanda em outros pacotes, como checks-execucao, checks-planejamento, checks-monitoramento.

Um outro motivo para tudo não ter convergido para um pacote checks somente, era o fato de usarmos R para muitos dos testes, tanto que também existe um repositório chamado checks-r.

Com a ideia de usar somente python, um pacote único checks contendo todas as modalidades de testes de maneira modular poderia ser retomada.

Sendo assim, as funcionalidades que não sejam testes ou relacionadas a datapackages poderiam ser inseridas nesse novo pacote que você sugeriu e poderíamos ao longo do tempo ir especializando essas funcionalidades em diferentes pacotes conforme percebêssemos que os assuntos estão divergindo dentro desse mesmo pacote.

gabrielbdornas commented 1 month ago

@gabrielbdornas sou da opinião que o dpm pode absorver todas as funcionalidades que são relacionadas ao ciclo de vida dos nossos datapackages: Criar, instalar, transformar, validar, concatenar, testar, etc.

Mas outras categorias de funcionalidades, como testes de regras de negócio orçamentárias, deveriam estar em outro lugar. No caso já tivemos a ideia de criar o pacote checks para testes, mas o projeto ficou parado e muito foi feito sob demanda em outros pacotes, como checks-execucao, checks-planejamento, checks-monitoramento.

Um outro motivo para tudo não ter convergido para um pacote checks somente, era o fato de usarmos R para muitos dos testes, tanto que também existe um repositório chamado checks-r.

Com a ideia de usar somente python, um pacote único checks contendo todas as modalidades de testes de maneira modular poderia ser retomada.

Sendo assim, as funcionalidades que não sejam testes ou relacionadas a datapackages poderiam ser inseridas nesse novo pacote que você sugeriu e poderíamos ao longo do tempo ir especializando essas funcionalidades em diferentes pacotes conforme percebêssemos que os assuntos estão divergindo dentro desse mesmo pacote.

@labanca, concordo plenamente. Se entendi bem, teríamos 3 pacotes (inicialmente), o dpm para assuntos relacionados a datapackages, o checks com as validações e testes de regras de negócios e o terceiro (a definirmos um nome) para assuntos diversos como conexões com e-mail, arquivos em drive, entre outros. Seria isso?

labanca commented 1 month ago

@labanca, concordo plenamente. Se entendi bem, teríamos 3 pacotes (inicialmente), o dpm para assuntos relacionados a datapackages, o checks com as validações e testes de regras de negócios e o terceiro (a definirmos um nome) para assuntos diversos como conexões com e-mail, arquivos em drive, entre outros. Seria isso?

Sim, exatamente isso!

fjuniorr commented 4 weeks ago

No meu entendimento, a exigência do Docker se justifica pela dificuldade de instalação de ferramentas, principalmente R, e pela utilização de diferentes tipos de sistemas operacionais. Sendo assim, eliminando os códigos R não precisaríamos de dar manutenção em Imagens Docker, assim como sua gestão no DockerHube.

Eu posso estar errado, mas acho que nenhuma das opções para executar R via Python vem com o R em si instalado. Então mesmo que o pacote relatorios seja chamado via Python, ainda é necessário um ambiente propriamente configurado. Aí acaba sendo mais fácil fazer isso com Docker do que via Github Actions.

E aí se vc já vai executar as coisas com Docker de qualquer maneira, a vantagem de reescrever coisas em outra linguagem não parece tão chamativa.

gabrielbdornas commented 4 weeks ago

No meu entendimento, a exigência do Docker se justifica pela dificuldade de instalação de ferramentas, principalmente R, e pela utilização de diferentes tipos de sistemas operacionais. Sendo assim, eliminando os códigos R não precisaríamos de dar manutenção em Imagens Docker, assim como sua gestão no DockerHube.

Eu posso estar errado, mas acho que nenhuma das opções para executar R via Python vem com o R em si instalado. Então mesmo que o pacote relatorios seja chamado via Python, ainda é necessário um ambiente propriamente configurado. Aí acaba sendo mais fácil fazer isso com Docker do que via Github Actions.

E aí se vc já vai executar as coisas com Docker de qualquer maneira, a vantagem de reescrever coisas em outra linguagem não parece tão chamativa.

@fjuniorr, pelo que entendi dos testes que @labanca fez aqui, não haveria a necessidade de instalar nada. Entendi certo, @labanca?

@labanca, alguma chance de ter dado certo pelo fato de você já ter as dependências instaladas localmente?

fjuniorr commented 4 weeks ago

Talvez (acho muito difícil porque o r2py teria que ser distribuído com um binário do R) não seja necessário instalar o R, mas o pacote relatorios precisa obrigatoriamente de ser instalado.

gabrielbdornas commented 4 weeks ago

Talvez (acho muito difícil porque o r2py teria que ser distribuído com um binário do R) não seja necessário instalar o R, mas o pacote relatorios precisa obrigatoriamente de ser instalado.

@labanca, acredito que @fjuniorr está correto!

Fiz este reprex para tentar executar o primeiro snipet criado aqui. Inicialmente, tentei utilizar uma Imagem Docker sem a instalação do R. Não funcionou.

Então tive a ideia de e executar o script diretamente no GitHub actions sem a utilização de uma Imagem Docker nossa previamente configurada.

Para rodar o actions localmente utilizei a ferramenta act. Realizei a instalação/utilização em conjunto com o CLI do GitHub. Usei ações para realizar setup Python e R[^1] no próprio actions e o resultado final mostrou o 6.0 no log da execução:

| Successfully installed 70 packages in 9.3 minutes.
[Updated/all]   ✅  Success - Main Rscript -e "install.packages('renv')" && Rscript -e 'renv::install()'
[Updated/all] ⭐ Run Main python3 scripts/main.py
[Updated/all]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/8] user= workdir=
| 6.0
[Updated/all]   ✅  Success - Main python3 scripts/main.py
[Updated/all] ⭐ Run Post actions/setup-python@v5
[Updated/all]   🐳  docker exec cmd=[/opt/acttoolcache/node/18.20.4/x64/bin/node /var/run/act/actions/actions-setup-python@v5/dist/cache-save/index.js] user= workdir=
[Updated/all]   ✅  Success - Post actions/setup-python@v5
[Updated/all] Cleaning up container for job all
[Updated/all] 🏁  Job succeeded

O experimento mostra uma luz no fim do túnel no que diz respeito à utilização de uma Imagem Docker nossa, mas ainda não consigo medir impacto. Vou tentar montar alguns testes adicionais com os outros códigos que você criou.

[^1]: Não consegui instalar as bibliotecas R utilizando este action, recorri então à execução direta de Rscript -e "install.packages('renv')" && Rscript -e 'renv::install()'.

labanca commented 4 weeks ago

@fjuniorr, pelo que entendi dos testes que @labanca fez aqui, não haveria a necessidade de instalar nada. Entendi certo, @labanca?

@labanca, alguma chance de ter dado certo pelo fato de você já ter as dependências instaladas localmente?

@gabrielbdornas Na verdade o rpy2 usa o ambiente R da própria máquina, então seria necessário ter o R instalado e o pacote relatorios também (num docker ou não). Não cheguei a verificar nada relativo a automatizar essa parte do ambiente R e não acho que exista, já que o pacote envia código para um ambiente R via Python.

Quando você sugeriu de usar somente um linguagem lembrei essa opção, mas caso criar um docker ou algo semelhante para executar o pacote relatorios seja muito desvantajoso em comparação a usar somente Pyhon, não vejo problema de continuar com o modus atual que já estamos acostumados (mas que a pesquisa estava muito legal, estava 😜 )

gabrielbdornas commented 4 weeks ago

@fjuniorr, pelo que entendi dos testes que @labanca fez aqui, não haveria a necessidade de instalar nada. Entendi certo, @labanca? @labanca, alguma chance de ter dado certo pelo fato de você já ter as dependências instaladas localmente?

@gabrielbdornas Na verdade o rpy2 usa o ambiente R da própria máquina, então seria necessário ter o R instalado e o pacote relatorios também (num docker ou não). Não cheguei a verificar nada relativo a automatizar essa parte do ambiente R e não acho que exista, já que o pacote envia código para um ambiente R via Python.

Quando você sugeriu de usar somente um linguagem lembrei essa opção, mas caso criar um docker ou algo semelhante para executar o pacote relatorios seja muito desvantajoso em comparação a usar somente Pyhon, não vejo problema de continuar com o modus atual que já estamos acostumados (mas que a pesquisa estava muito legal, estava 😜 )

@labanca, conforme conversamos, a pesquisa continua! Acredito que podemos expandir o reprex para tentar rodar o pacote relatórios utilizando somente as instalações feitas no actions.