Acesse nossa Plataforma

O mundo de dados tem mudado significativamente, com isso, surgem novas tecnologias, novos métodos e abordagens mais modernas.

O desafio atual das empresas não é somente o de começar suas respectivas iniciativas de dados, mas também de manter sua stack atualizada e pronta para atender todas as expectativas das áreas de negócios.

Para entendermos essas grandes mudanças, é importante dividirmos a história em duas fases: O antes e depois do termo MDS ou Modern Data Stack.

O início da stack padrão de dados

No início da computação, o custo de armazenamento e processamento de dados era algo caro e surreal.

Histórico do custo de memória de computadores - Modern Data Stack

Nesse sentido, para manter a viabilidade econômica dos projetos, era muito importante que uma stack de dados armazenasse e processasse o mínimo de informações possíveis.

Uma stack padrão de dados era composta por ferramentas de integração, armazenamento, processamento e visualização.

Integração e ingestão de dados

Para endereçar o cenário de integração de dados, surgiu o conceito de ETL (Extract, Transform and Loading).

No ETL, a ideia é extrair o dado de uma fonte, transformá-lo e então enviá-lo para uma estrutura de armazenamento central.

Como o processo de transformação fica antes do envio, o dado acaba sendo enviado já simplificado e sintetizado, economizando assim no custo de armazenamento.

ETL (Extract, Transform and Loading)

Armazenamento

Olhando os primórdios das tecnologias de armazenamento de dados, o banco de dados relacional (RDBMS) foi projetado primariamente para cenários transacionais.

Em outras palavras, sua função é armazenar informações em tempo real do seu negócio, por exemplo, registrar quais produtos foram vendidos.

A medida em que o volume de dados cresciam, ficava cada vez mais difícil gerar relatórios e ter análises robustas.

Além disso, o número de fontes de dados também crescia significativamente nas empresas, então ficava praticamente impossível ter uma visão centralizada do dado.

Foi então que em meados dos anos 80 surgiram as tecnologias de Data Warehouses.

Um Data Warehouse funciona como um repositório central de dados, no qual, pode armazenar dados de uma ou mais fontes.

Essas tecnologias em si foram projetadas para extração de relatórios e análises robustas de dados, ou seja, toda a arquitetura foi pensada para esse tipo de tarefa computacional.

Por tudo isso e muito mais, os data warehouses entraram em ampla adoção nas empresas com necessidades de projetos robustos com dados.

É óbvio que existem particularidades em termos de arquitetura entre cada ferramenta citada, entretanto, o objetivo de armazenar e processar um grande volume de dados permanece o mesmo.

Como ferramentas famosas nessa categoria, temos: Amazon Redshift, Google BigQuery, Snowflake, Teradata, Exadata, etc.

Processamento

Em combinação com o Data Warehouse, os cubos OLAP (Online Analytical Processing) viraram uma ótima opção para processamento de volume massivo de dados, principalmente pela integração nativa com os DWs.

Em termos técnicos um cubo OLAP nada mais é que uma matriz multidimensional de dados.

Em cenários de relatórios, agregação ou sumarização de grandes volumes de dados, o OLAP tornou-se indispensável.

PS: De modo geral, o conceito de OLAP tem sido embutido nas tecnologias de armazenamento e visualização de dados.

Visualização de dados (Business Intelligence)

É claro que não adianta nada ter as melhores tecnologias de armazenamento e processamento de dados, se você não consegue gerar valor para as áreas de negócios.

Sendo que, no mundo dos dados, gerar valor para as áreas de negócios quer dizer entregar o dado no formato mais simplificado possível, apoiando então decisões orientadas a dados.

Para resolver isso, entraremos então na camada de visualização de dados.

Para endereçar questões como: construção de relátorios e dashboards, é claro que não podia faltar as boas e velhas ferramentas de self-service BIs.

Filtros, cálculos, plotagem de gráficos, exportação de relatórios, dentre outras importantes funções, tudo isso vieram nativamente nas ferramentas de BI.

Nessa categoria, surgiram players dominantes, como: Domo, Microsoft Power BI, MicroStrategy, Qlik, SAS, Tableau, etc.

Compilando a stack mencionada acima, temos o seguinte cenário:

Stack de Dados

Esse cenário foi bastante útil nos últimos anos, mas com a evolução da tecnologia e a ascensão de conceitos como big data e inteligência artificial, muitos dizem que essa stack não é mais a melhor abordagem.

Os principais motivos citados pela comunidade de dados são: complexidade de escalar o ambiente, custo, tempo de implementação e arquitetura.

O que acontecia na prática, é que a dificuldade de conseguir centralizar os dados com essa stack era tão grande, que cada área de negócio acabava fazendo sua implementação individualmente, criando ambientes analíticos em silos, comprometendo qualquer projeto composto de visão unificada de dados.

Como resposta à esses novos desafios, surgiu então uma nova abordagem, a Modern Data Stack.

A chegada de uma nova abordagem — Modern Data Stack (MDS)

Modern Data Stack trata-se de uma nova abordagem para lidar com os desafios de dados, como o próprio nome diz, uma abordagem mais moderna, ou seja, mais preparada e eficiente para os desafios do presente e do futuro.

Essa nova abordagem contém mudanças significativas comparada a anterior, como ELT e não mais ETL, estruturas de armazenamento mais dinâmicas como Data Lakes e Lake Houses, ferramentas específicas de transformação de dados, e muito mais.

Agora vamos entender como toda essa mudança funciona na prática.

De ETL para ELT

Como dito anteriormente, ETL trata-se Extrair, Transformar e Carregar dados.

Com o tempo, esse conceito começou a ser questionado, pois existia um acoplamento muito forte entre o DW e as estruturas de dados dos diferentes data sources.

Outros problemas relevantes dessa abordagem são:

  • Em caso de erros de transformações de dados, o pipeline para a execução por completo.
  • Falta de flexibilidade, pois é necessário prever todos os casos de uso e desenvolver os modelos de dados durante a criação do pipeline de ingestão.
  • Tudo exige desenvolvimento sob medida.
  • Uso restrito por áreas de TI, ou seja, usuários muito técnicos.

Dado o cenário, criaram o conceito ELT — Extrair, Carregar e Transformar.

Como mudança prática, o ELT inverte a ordem de transformar e carregar, incentivando então o envio do dado bruto a estrutura de armazenamento.

Com isso, o dado é trabalhado já dentro da estrutura de armazenamento, seja por processos de transformação, agregação, etc.

As grandes vantagens dessa abordagem são:

  • Não há acoplamento com as fontes de dados, pois os dados são carregados no formato bruto.
  • Menor tempo de carregamento dos dados, pois não há nenhum tratamento intermediário.
  • Em casos de erros de transformação, a execução do pipeline não para.
  • Flexibilidade, pois é possível a criação de novos casos de uso e modelos de dados à qualquer momento sem impactar nenhuma estrutura.
  • Self-service, pois as ferramentas de ELT já trazem conectores prontos de diversas aplicações e tipos de fontes de dados.
  • Simplicidade, devido a facilidade das ferramentas de ELT, os dados também podem ser carregados por usuários que não técnicos, reduzindo a dependência entre áreas técnicas e de negócios.

Para finalizar, nesse desenho podemos ver como fica o ELT na prática:

Ferramentas de transformação de dados

Na stack tradicional, a transformação de dados era feita diretamente em processos criados no ETL, ou então, em aplicações desenvolvidas taylor made dentro das empresas.

Existiam muitos problemas nessa abordagem, como a falta de funcionalidades para linhagem de dados, versionamento, CI/CD, documentação, etc.

Nesse cenário, ferramentas especialistas surgiram para endereçar essas e outras questões.

As mais famosas desse segmento são: dbt, DataForm.

De Data Warehouses para Data Lakes

Seguindo a história evolutiva das estruturas de armazenamento de dados, ao chegarmos nos Data Warehouses com o passar do tempo esbarramos em outro problema gerado pelo "boom" dos dados não estruturados ou semi estruturados da internet.

Além disso, toda dinâmica começou a ficar real-time.

Foi assim que junto com a revolução do mundo cloud surgiram os Data Lakes (2011).

Uma tecnologia baseada em armazenamento de objetos, muito mais moderna, flexível e com escala distribuída.

Com isso, os Data Lakes tornaram-se a estrutura mais recomendada para altos volumes de dados estruturados, semi estruturados e não estruturados.

Recentemente surgiram conceitos de arquiteturas ainda mais robustos como Lake House ou Delta Lake, uma combinação entre Data Warehouses com Data Lakes.

Em linhar gerais, a proposta é unir o melhor dos dois mundos.

Flexibilidade, escalabilidade, e consistência de transações ACID, esse é o objetivo dessa proposta de arquitetura.

Como é algo relativamente novo, não vou explorar com detalhes nesse artigo.

Por fim, uma arquitetura Modern Data Stack (MDS) fica da seguinte forma:

Modern Data Stack

É isso, como podemos ver, o mundo de tecnologia sempre está em constante evolução, portanto o mundo de dados não podia ser diferente.

As evoluções são significativas e mudam diversos paradigmas, mas, ao mesmo tempo facilitam a jornada das empresas na busca da geração de valor à partir dos dados.

Inteligência artificial, big data, analytics, e todas essas palavras da moda só são possíveis com o total entendimento das tecnologias e seus casos de uso.

Encerro aqui mais um artigo técnico, espero que impacte a sua jornada de dados e até o próximo!

Agende uma conversa e saiba como podemos te ajudar