Clean Architecture aplicada na Ciência de Dados

Clean Architecture aplicada na Ciência de Dados

jun 28, 2023

A arquitetura limpa (Clean Architecture) é uma abordagem que visa a separação de preocupações em sistemas de software, permitindo maior flexibilidade, testabilidade e manutenção. A arquitetura é composta por camadas, incluindo a camada de apresentação, camada de domínio e camada de dados. A regra de dependência exige que as dependências do código-fonte só possam apontar para dentro, o que significa que nada em um círculo interno pode saber nada sobre algo em um círculo externo.

Neste artigo, apresentamos uma proposta de estruturação do Clean Architecture visando a melhorar as interações entre Cientistas de Dados e Software Engineer. A proposta feita no presente texto está baseada na identificação dos principais pontos de interação entre esses profissionais. 

Clean Architecture, divisão por camadas e equipes multidisciplinares

Equipes multidisciplinares e arquitetura de camadas são conceitos que se complementam bem. A criação de equipes multidisciplinares é essencial para o sucesso do desenvolvimento de software, pois permite que diferentes especialistas trabalhem juntos em um projeto. Por outro lado, a arquitetura de camadas é uma abordagem para dividir um sistema em diferentes camadas lógicas, cada uma com uma responsabilidade específica. A combinação desses dois conceitos pode ajudar a criar um software de alta qualidade.

Ao usar uma abordagem de camadas, é possível definir claramente as responsabilidades de cada equipe e garantir que haja uma separação clara de preocupações. Por exemplo, uma equipe de cientistas de dados pode trabalhar em camadas de dados e processamento, enquanto uma equipe de desenvolvedores de software pode trabalhar em camadas de apresentação e infraestrutura. Isso permite que cada equipe se concentre em sua área de especialização e trabalhe de forma mais eficaz.

Benefícios da arquitetura de camadas no desenvolvimento de software

Criar camadas para separar o trabalho do cientista de dados e desenvolvedor de software pode trazer vários benefícios importantes. Aqui estão alguns deles:

  • Clareza de responsabilidades: ao definir as camadas de software, fica claro qual equipe é responsável por cada camada. Isso ajuda a evitar conflitos e mal-entendidos sobre quem é responsável pelo quê.
  • Maior produtividade: ao separar as camadas, cada equipe pode se concentrar em sua área de especialização e trabalhar de forma mais produtiva. Isso pode levar a uma entrega mais rápida e eficiente do software.
  • Maior qualidade do software: separar as camadas também permite que cada equipe se concentre em seu trabalho específico. Isso pode levar a um software de melhor qualidade, pois cada equipe pode dedicar mais tempo e recursos às suas tarefas.
  • Melhor colaboração: ao separar o trabalho em camadas, as equipes podem colaborar de forma mais eficaz. Cada equipe pode se concentrar em sua área de especialização e trabalhar em estreita colaboração com a outra equipe. Isso pode levar a uma melhor comunicação e um melhor entendimento dos requisitos do projeto.
  • Facilidade de manutenção: separar as camadas também torna mais fácil manter o software a longo prazo. Cada equipe pode se concentrar em manter sua camada específica e garantir que ela esteja funcionando corretamente. Isso pode levar a uma manutenção mais fácil e eficiente do software.

Clean Architecture (Arquitetura Limpa)

Nos últimos anos, vimos toda uma gama de ideias sobre a arquitetura de sistemas, as quais incluem:

  • Hexagonal Architecture
  • Onion Architecture 
  • Screaming Architecture
  • DCI
  • BCE

Embora todas essas arquiteturas variem um pouco em seus detalhes, elas são muito semelhantes. Todas elas têm o mesmo objetivo, que é a separação de preocupações. Todas elas conseguem essa separação dividindo o software em camadas. Cada um tem pelo menos uma camada para regras de negócios e outra para interfaces.
Baseado nessas informações e com o objetivo de integrar os pontos fundamentais dessas arquiteturas, Robert C. Martin (Uncle Bob) propõe a arquitetura representada na seguinte figura 1.

Fig. 1: The Clean Architecture layers (as camadas da arquitetura limpa)
Fig. 1: The Clean Architecture layers (as camadas da arquitetura limpa)

A Camada de Apresentação contém UI (Atividades e Fragmentos), que são coordenados por Apresentadores/ViewModels que executam um ou vários casos de uso. A Camada de Apresentação depende da Camada de Domínio.

A Camada de Domínio é a parte mais interna da “cebola” (sem dependências com outras camadas) e contém entidades, casos de uso e interfaces de repositório. Os casos de uso combinam dados de 1 ou várias interfaces de repositório.

A Camada de Dados contém implementações de repositório e 1 ou várias fontes de dados. Os repositórios são responsáveis por coordenar os dados das diferentes fontes de dados. A Camada de Dados depende da Camada de Domínio.

Os círculos concêntricos representam diferentes áreas de software. Em geral, quanto mais você avança, mais alto o software se torna. 

A regra primordial que faz essa arquitetura funcionar é a regra de dependência. Essa regra diz que as dependências do código-fonte só podem apontar para dentro. Nada em um círculo interno pode saber absolutamente nada sobre algo em um círculo externo. Em particular, o nome de algo declarado em um círculo externo não deve ser mencionado pelo código no círculo interno. Isso inclui, funções, classes, variáveis ou qualquer outra entidade de software nomeada.

Da mesma forma, os formatos de dados usados em um círculo externo não devem ser usados por um círculo interno, especialmente se esses formatos forem gerados por uma estrutura em um círculo externo. Não queremos que nada em um círculo externo afete os círculos internos.

Clean Architecture é sobre acoplamento. Não há prescrição para as camadas que você define ou como você define o acoplamento. Você não precisa definir camadas por projetos. É sobre a direção das dependências entre os tipos. O acoplamento aferente e eferente é o que define a estabilidade de cada camada. Motivo pelo qual pessoas envolvidas em projetos onde a Clean Architecture é aplicada devem ter uma boa ideia dos princípios que se aplicam nessa arquitetura. 

A importância da ciência de dados 

A principal responsabilidade de cientistas de dados é trabalhar com dados para obter insights, realizar análises e criar modelos. No entanto, a qualidade do código é importante para garantir que os projetos sejam escaláveis, fáceis de manter e reutilizáveis, e que possam ser desenvolvidos com eficiência e eficácia. 

Existem muitas habilidades necessárias para realizar o trabalho desses especialistas. Na Figura 2 apresenta-se um conjunto de habilidades e processos que devem ser seguidos para o trabalho com dados. Esses processos exigem um conjunto de conhecimentos muito profundos em estatísticas, matemática, tratamento de dados, visualização de dados para comunicar os resultados da análise de dados de maneira clara e eficaz, dentre outras habilidades. 

Como a Ciência de Dados é um campo em constante evolução, é importante que os profissionais que desempenham esse trabalho estejam continuamente aprendendo e se atualizando em novas técnicas e tecnologias. Isso pode incluir a participação em cursos e treinamentos, a leitura de artigos e livros sobre Ciência de Dados e a participação em comunidades da área.

A qualidade e incerteza dos dados podem ter um impacto significativo no tempo que os cientistas de dados devem investir em cada fase do processo de análise de dados. A coleta e limpeza de dados podem ser particularmente demoradas, já que os dados podem estar em formatos diferentes e podem conter erros, valores ausentes ou dados duplicados. A análise de dados também pode ser afetada pela qualidade dos dados, pois dados de baixa qualidade podem levar a insights imprecisos ou equivocados.

Como resultado, cientistas de dados podem precisar revisitar essas fases do processo várias vezes para garantir que os dados estejam limpos e prontos para a análise. Isso pode ser especialmente desafiador em projetos de grande escala, onde há uma grande quantidade de dados para serem analisados.

No entanto, é importante lembrar que o investimento de tempo nas fases iniciais do processo de análise de dados pode economizar tempo e esforço no longo prazo, garantindo que os dados sejam limpos e precisos antes da análise. Além disso, a iteração contínua pode levar a melhorias significativas na análise de dados e na qualidade dos resultados.

Embora a programação seja uma habilidade importante para um cientista de dados, não é necessário que sejam especialistas em programação. Muitas vezes, cientistas de dados trabalham em colaboração com engenheiros de software ou desenvolvedores para garantir que o código seja escrito de maneira eficiente e eficaz. Isso pode envolver a revisão do código de outros desenvolvedores e garantir que ele siga as melhores práticas de programação e padrões de código.

Além disso, muitas organizações têm equipes dedicadas de engenharia de software que garantem a qualidade do código e a conformidade com as melhores práticas de programação. Nesses casos, os cientistas de dados podem se concentrar em suas principais responsabilidades de análise de dados e modelagem, enquanto os engenheiros de software se concentram na qualidade do código.

Fig. 2: A ciência de dados e processos que a compõem
Fig. 2: A ciência de dados e processos que a compõem

Uma boa arquitetura de software irá promover a interdependência entre cientistas de dados e engenheiros de software. Motivo pelo qual a seguir abordaremos uma proposta de uso do Clean Architecture desde a óptica de equipes multidisciplinares de cientistas de dados e engenheiros de software.

Clean Architecture na Ciência de Dados

Ao aplicar a Clean Architecture na Ciência de Dados, é importante identificar as diferentes camadas do sistema e suas responsabilidades, incluindo a camada de dados, a camada de infraestrutura, a camada de negócios e a camada de apresentação. Cada camada deve ser projetada para ser independente das outras camadas, permitindo que o sistema seja facilmente adaptável a mudanças nos requisitos de negócios ou tecnologias.

Contextos que envolvem processamento de dados tem como foco principal a lógica de negócios (business logic) encarregada dos processos de transformação ou cálculo dos dados, além do encaminhamento destes para pessoas ou software (workflow). 

As regras de negócios são expressões formais da política de negócios. Qualquer coisa que seja um processo ou procedimento é uma lógica de negócios e qualquer coisa que não seja um processo nem um procedimento é uma regra de negócios. Daí que processos tais como ETL, análise e inferência de dados sejam pertinentes à lógica de negócios e fazem parte dos casos de uso na camada de domínio. 

Uma possível subdivisão a realizar a fim de independizar o trabalho de cientistas de dados e engenheiros de software seria na camada de domínio, com um modelo segundo os seguintes tipos de Casos de Uso: 

  • Processamento dos dados provenientes das fontes de dados: a camada contempla a orquestração do fluxo de dados visando a persistência, consistência e validação dos dados. 
  • Desenvolvimento e manutenção de modelos: processo de usar o conhecimento do domínio para selecionar e transformar as variáveis mais relevantes dos dados brutos ao criar um modelo preditivo usando aprendizado de máquina ou modelagem estatística.   
  • Processos que envolvem diretamente o usuário final 

Por outro lado, a camada de dados passará a estar conformada pelos Repository, e tarefas (tasks) que conformam o fluxo de dados. 

Note-se que essa separação implica que ferramentas ETL ou ELT sejam conformadas por duas camadas. Uma delas relativa à lógica de negócios contemplando a modelação do workflow de dados e a outra com a lógica de acesso e compartilhamento de dados, sendo que na segunda camada existe espaço para aplicação de princípios de software.

No nível de armazenamento da camada de dados é possível fazer uma subdivisão dos dados segundo esquemas ou bancos de dados diferentes, refletindo a separação em camadas segundo Caso de Uso. No entanto, é importante ter em mente que a criação de esquemas ou bancos de dados separados pode aumentar a complexidade da aplicação e exigir mais recursos de gerenciamento de dados. Portanto, é importante manter bem definido e documentado o objetivo de cada uma das camadas que são criadas.

Conclusão – Clean Architecture aplicada na Ciência de Dados

Na ciência de dados, a arquitetura limpa pode ser aplicada para criar uma arquitetura de aplicação orientada a aplicações de ciência de dados. A camada de domínio pode ser subdividida em casos de uso, incluindo processamento de dados, desenvolvimento e manutenção de modelos e processos que envolvem diretamente o usuário final. 
A camada de dados pode ser conformada por Repository e tarefas (tasks) que conformam o fluxo de dados. É possível fazer uma subdivisão dos dados de acordo com esquemas ou bancos de dados diferentes, refletindo a separação em camadas de caso de uso.

Quem é a Aquarela Analytics?

A Aquarela Analytics é vencedora do Prêmio CNI de Inovação e referência nacional na aplicação de Inteligência Artificial na indústria e em grandes empresas. Por meio da plataforma Vortx e da metodologia DCIM (Download e-book gratuito), atende clientes importantes, como: Embraer (aeroespacial),  Auren (energia), Scania e Grupo Randon (automotivo), SolarBR Coca-Cola (alimentício), Hospital das Clínicas (saúde), NTS-Brasil (óleo e gás), Telefônica Vivo (Telecomunicações), dentre outros. Fique atento às novas publicações diárias da Aquarela Analytics no Linkedin e assinando a nossa Newsletter mensal!

Autor

Apache Airflow: o que é e como funciona?

Apache Airflow: o que é e como funciona?

nov 17, 2022

O orquestrador de workflow Apache Airflow é uma ferramenta que tem recebido muita aceitação nos últimos anos pela comunidade de engenheiros de dados. A ferramenta possui mecanismos que permitem a implementação de distintas abordagens de tratamento de dados. Neste artigo abordamos duas dessas variantes e levantamos alguns pontos a serem considerados para a implementação.  

O que são ETLs e ELTs?

A engenharia de dados refere-se à construção de sistemas que permitam a coleta e o uso dos dados. Usualmente, esses dados são usados para permitir análises subsequentes e para aplicação de técnicas da ciência de dados; que podem envolver aprendizado de máquina.

Para a construção desses sistemas existem diferentes tipos de ferramentas de software com distintas abordagens. Por exemplo, extração, transformação e carga (do inglês Extraction, Transformation and Load, ETL) e extração, carga e transformação (do inglês Extraction, Load and Transformation, ELT).

A diferença fundamental entre esses dois paradigmas encontra-se na ordem em que são feitas as operações. O que implica que no caso das ETL (Multistage data transformation) as operações de conciliação de dados devem ser realizadas em uma stage area separada do repositório de dados. O que implica que em alguns contextos possa existir um grande fluxo de intercâmbio de dados. Porém, ELT (In-warehouse data transformation) faz uso das capacidades dos Sistemas de Gerenciamento de Bancos de Dados (SGBD) para realizar as transformações de dados orientadas à conciliação dos dados. Cada uma destas abordagens tem vantagens e desvantagens que as tornam uma ótima escolha ou não dependendo do cenário específico de cada projeto.

Atualmente existem diversas ferramentas que implementam os paradigmas mencionados acima, mas para este artigo iremos abordar o Apache Airflow.

Apache Airflow

O Apache Airflow é uma ferramenta open source de orquestração para pipelines de dados que teve seu início como uma ferramenta desenvolvida pelo Airbnb. A ferramenta foi desenvolvida em python e a criação dos workflows é via python scripts.

Apache Airflow usa gráficos acíclicos direcionados (do inglês Directed Acyclic Graphs, DAG) para gerenciar o fluxo da orquestração e pode ser dividido nos seguintes componentes:

– airflow-scheduler: O scheduler monitora todas as tarefas e DAGs que são lançadas uma vez que as dependências são completadas

– airflow-worker: O worker é o processo encarregado da execução das tarefas. Constitui a unidade de escalonamento de airflow, sendo possível distribuirmos várias instâncias na rede.

– broker: Ferramenta que encarregada do envio de mensagem desde o scheduler para o worker

– airflow-webserver: Ferramenta que fornece a interface gráfica para interagir com o Apache Airflow.

– banco de dados: É comum utilizar um banco de dados como ferramenta para alocar informações relativas ao Apache Airflow.

Apache Airflow e ETL

A arquitetura de Apache Airflow permite que o processamento das DAGs seja distribuído em distintos workers. Isso faz com que a ferramenta seja facilmente escalável enquanto as capacidades de processamento das tarefas. E que seja uma boa opção para a construção de pipelines utilizando o paradigma de ETL. Assim, a responsabilidade de executar as transformações de dados fica para o Apache Airflow.

No contexto do paradigma das ETL, uma forma de usar o Airflow utilizando suas capacidades de processamento distribuído e multicore, consiste no uso do mecanismo XCom (do inglês, cross-comunication). Já que, por padrão, isolam-se as tarefas completamente.

O mecanismo XCom serializa os objetos devolvidos pelas tarefas como metadados dentro do backend configurado para Airflow (Postgresql, SQLite, MySQL). E assim, disponibiliza mecanismos como xcom_pull e xcom_push para interagir com esses metadados. Permitindo estabelecer um fluxo de intercâmbio de dados entre as distintas operações que integram o processo ETL.

Uma recomendação ao fazer uso dos mecanismos XCom consiste em manter pequeno o tamanho dos dados que são intercambiados. Atualmente o backend utilizado é o que define o limite dos pacotes de dados.

Alguns dos utilizados são:

– SQLite 2GB

– Postgres 1GB

– MySQL 64KB

Um dos possíveis usos do ETL no Apache Airflow, usando o XCom, consiste na estruturação das ETL para o processamento por cluster de dados. Assim, fica a critério do desenvolvedor dos pipelines de dados definir a forma em que os dados serão clusterizados para processamento. Note-se que se o cluster de dados for pequeno demais o Apache Airflow terá que inicializar mais tarefas. Isso faz com que sobrem menos recursos para atribuir para outras tarefas. Caso os cluster sejam muito grandes podem-se perder as potencialidades de processamento distribuído e concorrente do Apache Airflow. Além de possivelmente fazer com que exista um incremento no uso de memória RAM.

Um importante ponto a ser considerado na implementação de pipelines de dados no Airflow é a utilização de workers distribuidos, pois não deve-se fazer uso de recursos locais para compartilhar informações. Já que cada tarefa pode ser executada em workers diferentes. O que implica que em caso de processamento de arquivos grandes (MDE, videos, etc) deve-se compartilhar esses arquivos fazendo uso de espaços de memória compartilhada.  Um importante ponto a ser considerado na implementação de pipelines de dados no Airflow é a utilização de workers distribuidos, pois não deve-se fazer uso de recursos locais para compartilhar informações.

Apache Airflow e ETL

Por outro lado, pipelines implementados seguindo o paradigma ELT no Apache Airflow podem ser construídos usando linguagem de manipulação de dados como SQL e outros. Aproveitando que existem muitos anos de pesquisa e otimização de algoritmos para tratamento de dados nos SGBD convencionais.

No caso do uso de dados estruturados em banco de dados estruturados, a linguagem SQL tem amplo suporte, possibilitando a implementação de boa parte das operações clássicas de transformação de dados.

Os operadores do Apache Airflow e a linguagem de dados SQL podem implementar boa parte das transformações de dados estruturados. Fazendo possível a construção da abordagem ELT com Apache Airflow. Os operadores do Apache Airflow e a linguagem de dados SQL podem implementar boa parte das transformações de dados estruturados.

Neste tipo de abordagem de forma similar com a abordagem ETL sugere-se estruturar o processamento em clusters de dados mais do que no caso das ELT. Pois, os SGBD estão preparados para fazer uso de discos rígidos (do inglês, Hard Drive) podemos considerar clusters de dados com tamanho razoavelmente grande.

A abordagem ELT implica a transferência da responsabilidade do processamento para o SGBD. Fazendo com que os limites da abordagem estejam mais relacionados com os recursos do SGBD e quantidade de requisições que esteja recebendo o SGBD. Também implica que o desenvolvedor possua alguns conhecimentos em tunning de banco de dados.

Em contextos de bancos de dados distribuídos pode ser uma boa ideia o uso de bancos de dados com menores restrições de consistência e integridade transacional de dados na implementação de processos ELT.

Conclusão

O orquestrador de pipelines Apache Airflow é uma ferramenta facilmente extensível que permite a implementação de distintas alternativas de tratamento de dados. A escolha destas alternativas depende muito do contexto de implementação, dos recursos disponíveis e até do background de conhecimentos da equipe que fará o desenvolvimento.

No presente artigo expomos alguns dos principais elementos para se considerar na hora de decidir a forma em que serão implementados os pipelines usando o airflow.

Quem é a Aquarela Analytics?

A Aquarela Analytics é vencedora do Prêmio CNI de Inovação e referência nacional na aplicação de Inteligência Artificial na indústria e em grandes empresas. Por meio da plataforma Vortx e da metodologia DCIM (Download e-book gratuito), atende clientes importantes, como: Embraer (aeroespacial),  Auren (energia), Scania e Grupo Randon (automotivo), SolarBR Coca-Cola (alimentício), Hospital das Clínicas (saúde), NTS-Brasil (óleo e gás), Telefônica Vivo (Telecomunicações), dentre outros. Fique atento às novas publicações diárias da Aquarela Analytics no Linkedin e assinando a nossa Newsletter mensal!

Autor