Design patterns que todo engenheiro de dados deve conhecer
Se você é uma profissional de dados, o tema Design Patterns pode ser um pouco distante na sua área de atuação. No contexto de desenvolvedores, de maneira simples e direta, design patterns são padrões para solucionar problemas recorrentes em softwares.
Para dados, a temática começa a se tornar relevante atualmente. Eles são úteis para tornar processos de códigos e dados mais robustos e sustentáveis. Eles são universalmente aplicáveis e quase todo engenheiro de software ou arquiteto de sistemas está apto ao uso.
Se o direcionamento para dados pode ser uma novidade para você, venha saber mais do que vamos abordar por aqui. Saiba quais são e como utilizar padrões direcionados a data science e data engineering.
Quais os benefícios do Patterns Design para dados?
Falando de design patterns para dados, o principal objetivo da aplicação neste contexto é gerar vantagem competitiva no tratamento de grandes volumes (big data). Como o ser humano não possui a capacidade de análise de uma máquina, algumas áreas se desenvolveram com o intuito de solucionar esse problema, como data science e data analytics.
Pensando na manutenção desses sistemas, o design patterns será aplicado a fim de compartilhar melhores práticas entre o time de dados. Esse é um tema bastante atual e desde 2016 há um boom desta relação entre padrões e dados.
Muitos trabalhos de data science e analytics acabam sendo exploratórios. Com isso, a falta de padronização gera problemas de confiabilidade, veracidade e validade. Dados podem ser incertos, ser coletados de fontes diferentes, sofrer alterações ao longo do tempo.
É nessa raiz do problema que a criação de Design Patterns, padrões ou modelos de solução, vão trazer mais assertividade e ganho de tempo para os profissionais de engenharia de dados. Vamos conhecer algumas possibilidades aplicáveis.
Padrões de projetos mais conhecidos no mercado
Os design patterns já são considerados uma boa prática para desenvolvedores e conhecer os seus principais modelos podem te ajudar a agilizar trabalhos da mesma maneira com dados. Conheça (ou revisite) alguns padrões conhecidos no mercado.
Slotted Counter Pattern
Bancos de dados em sistemas operacionais são máquinas de estado, pois capturam as operações em cada ponto no tempo. Lembre-se de que parte do padrão RESTful era sobre como os serviços lidam com esse estado..
Quando uma aplicação tenta acompanhar a ocorrência de um evento, é comum incrementar uma coluna de contador inteiro em uma tabela de banco de dados. Isso pode resultar em contenção se vários serviços estiverem acessando o mesmo registro para incrementar o contador.
O Slotted Counter Pattern divide esse registro em vários registros para evitar contenção. Se a chave primária da tabela for event_id, o padrão é alterar a granulidade para event_id +slot_id, de modo que para cada event_id exlcusivo haja mais de um slot_id, reduzindo a contenção em cada event_id.
Rest vs transferência de dados GraphQL
Na maioria dos casos, o padrão REST não é feito corretamente. Esse serviço web tem a seguinte prioridade::
- permitir que o aplicativo altere o estado (dados do aplicativo) sem estar ciente dele. Por exemplo, um serviço de autenticação de usuário RESTful sempre vai retornar todo o registo do usuário e não só algumas colunas específicas para a alteração solicitada. Cada endpoint busca dados específicos. Essas propriedades resultam em alguns problemas bem conhecidos, que levaram ao desenvolvimento do GraphQL
O GraphQL apresenta uma camada de definição de esquema para ajudar os serviços da Web a fazer chamas com reconhecimento de esquema para o banco de dados. A definição do esquema é construída com JSON e obviamente reconhece o estado neste momento.
- É possível escolher elementos de dados específicos e pode-se ter vários domínios de dados com apenas um endpoint. Isso significa que as especificidades do esquema são desacopladas da interface do usuário na camada do GraphQL, reduzindo problemas quanto às vinculações dos dados.
NoSQL vs SQL
O NoSQL não é mais apresentado como uma simples substituição do SQL. É, sim, uma solução ideal para domínios de problemas de nicho, como pesquisa, streaming, cache, gráfico etc.
A escala horizontal ou o suporte nativo para JSON não devem ser os principais drivers para escolher o NoSQL, pois esses são problemas resolvidos em muitos bancos de dados modernos.
A principal ressalva ao uso do NoSQL é a falta de um modelo de dados expressivo para entender e analisar os dados. Daí o argumento de que ele deve ser usado apenas para resolver um domínio de problema específico e restrito.
Há muito espaço para novos design patterns surgirem como foco no uso para data science e analytics. O crescimento de ambas as áreas vai gerar interesse pelo assunto de padronização. Unidos pelas boas práticas, profissionais mais experientes podem ajudar iniciantes ao gerar técnicas mais eficientes para a resolução de problemas comuns.
Se você quer estar perto de profissionais com expertise acurada e que resolvem problemas atuais, aproveite e confira outros artigos em nosso blog e evolua seus conhecimentos!
