Publicação de DataExpert.io

Uma tabela dentro de outra tabela em SQL? fazer consultas históricas sem precisar de Group By? 🤯 É mais ou menos essa a ideia que o Zach Morris Wilson (Ex Airbnb, Meta) nos apresentou na primeira etapa do seu Bootcamp de Engenharia de Dados da DataExpert.io através do conceito de Cumulative Table Design. Os objetivos desse padrão são: 1. Otimizar o armazenamento de dados aproveitando a otimização oferecida pelo Run-Lenght Encoding de formatos de dados colunares. Esse tipo de codificação é comum em arquivos do tipo .parquet e permite valores duplicados dentro da mesma coluna sejam ignorados (como nomes e telefones repetidos) no armazenamento, sem comprometer a leitura dos dados originais depois. 2. Uso de tipos complexos de dados para otimização de consultas analíticas. No exemplo, o tipo STRUCT foi utilizado para modelar os resultados de jogadores da NBA em uma dada temporada. Para cada nova temporada, um novo registro foi criado, acrescentando o histórico da temporada anterior a uma coluna de array de structs, que contém os resultados de todas as temporadas daquele jogador até aquele momento. isso permite por exemplo: calcular em cima de valores históricos dos jogadores sem a necessidade de sequer realizar joins ou agrupamentos, deixando consultas tradicionalmente custosas leves e objetivas. ------------------------------------------------------------------------------ Na primeira imagem, a declaração do tipo STRUCT personalizado para os resultados de jogadores de basquete em uma temporada e o DDL da tabela, declarando a coluna season_stats como um array do tipo personalizado. Na segunda imagem, um exemplo da estrutura de um registro com uma coluna de ARRAY de STRUCTs, contendo os resultados de cada temporada de um jogador. Na terceira imagem, um exemplo de consulta que calcula o aumento do rendimento entre a primeira e a mais recente temporada de cada jogador, criada sem o uso de nenhum join, agrupamento ou window function, apenas com o uso do tipo complexo STRUCT 😯