Desmontando o ELT: quando você precisa de um grafo, não de silos

• ELT (Extract, Load, Transform) é usado para conectar os “silos” de análise de dados e desenvolvimento de software dentro das organizações, mas essa própria estrutura em silos é a raiz do problema

• ELT é apenas uma ponte entre silos. Um mundo sem silos é um “grafo (Graph)”

Limites da mentalidade ELT

• Em um mundo de silos, onde há software em um silo e análise de dados em outro, o ELT faz bastante sentido
• O ELT funciona partindo do pressuposto de uma estrutura em silos
  • Em uma situação em que a equipe de desenvolvimento de software e a equipe de análise de dados estão separadas, surge o trabalho de “extração (Extract)”
  • A equipe de software não se interessa pelo trabalho da equipe de dados, e a equipe de dados simplesmente extrai os dados usando permissões de banco de dados
  • Só depois da extração é que princípios de engenharia, como qualidade de dados e modelagem, passam a ser aplicados, mas aí já é tarde demais
• A Lei de Conway entra em ação
  • “O design de sistemas produzidos por uma organização tende a refletir a estrutura de comunicação dessa organização”
• Por causa da mentalidade de silos, ETL/ELT/Reverse ETL não são adequados para lidar com a complexidade da arquitetura de dados moderna
  • Os dados agora não estão apenas em sistemas operacionais e analíticos, mas também se expandiram para uma terceira área de dados, representada pelo SaaS
  • Os dados fluem entre regiões e nuvens, entre backend e SaaS
  • Hoje existem 100 vezes mais aplicações do que antes; as organizações estão se transformando em software, e a rede de relações entre sistemas de software está ficando cada vez mais complexa

A necessidade de uma mentalidade de grafo

• Se as equipes de software e de dados colaborarem em harmonia, é possível migrar do modelo de extração e armazenamento de dados como no ELT para um modelo de grafo
  • Imagine um grafo composto por nós que “consomem (Consume)” dados
  • Cada nó produz ou consome dados, formando naturalmente uma rede ou grafo
• Vantagens da mentalidade de grafo:
  • Menos extração de dados e mais consumo
  • Mais modelagem de dados centrada em conjuntos de dados de alta qualidade
  • Menos limpeza de dados, menos armazenamento de dados brutos e menos correção de erros de pipeline
  • Uso de processamento incremental e fontes de streaming para substituir processos em batch
  • A análise deixa de ficar limitada a ferramentas estratégicas de tomada de decisão e se expande para usos operacionais
  • Mais colaboração e alinhamento entre equipes, menos silos

Conclusão

• A mentalidade ELT é resultado da Lei de Conway, refletindo a desconexão entre equipes de software e de dados
• Não é necessário descartar todas as ferramentas existentes de ETL/ELT, mas é preciso focar em consumo de dados e construção de conjuntos de dados derivados confiáveis
• Na prática, Shift Left ainda está em um estágio aspiracional, e os problemas de integração com infraestrutura legada continuam existindo
  • Shift Left: estratégia de integrar práticas importantes de desenvolvimento nas fases iniciais do ciclo de vida de desenvolvimento de software (SDLC)
• Organizações que adotarem a mentalidade de grafo obterão os maiores benefícios em uso de dados, ROI de IA e resultados de negócios

“Não existe extração (Extract). Só existe consumo (Consume).” – Yoda dos dados

[udopeanut]

Depois de ler o livro Data Mesh, muitas partes passaram a fazer sentido.

[softer]

Tenho desenvolvido ideias de forma consistente sobre tomada de decisão baseada em grafos, e acho que seria ótimo se pessoas que pensam da mesma forma pudessem se reunir.

[kimsk]

Então é esse o termo que se usa nessas horas, ideation. Aprendi mais uma. Pessoalmente, é um tema que me interessa muito. Seria ótimo se desse para reunir todo mundo.

[jwseo]

Alguém poderia explicar um pouco mais? O método de que o autor fala significa armazenar e gerenciar separadamente todos os datasets derivados em um grafo? Se não for isso, não estou entendendo bem em que isso difere de ETL.

[rlaehdus2003]

Dizem que a estrutura em que a área operacional e a área analítica existentes estão separadas tem um problema estrutural de silo, e que, ao criar uma arquitetura de dados, essas duas áreas não devem ser consideradas separadamente, mas sim divididas entre produtores e consumidores de dados.

Agora, à medida que a fronteira entre dados operacionais e dados analíticos fica mais difusa, dizem que é preciso adotar um pensamento em grafo (graph thinking, ou graph mindset).

Na minha percepção, mais do que uma separação explícita entre dados operacionais e dados analíticos, a ideia é distinguir consumidores e produtores de dados como uma extensão dos dados operacionais e enxergar o acesso aos dados sob a perspectiva do fluxo de dados (ainda que os papéis possam estar separados).

Parece que estão falando disso do ponto de vista da arquitetura de dados: analisar com base nos dados operacionais, levar isso de volta para a operação e, então, isso voltar novamente para a análise.