Publicação de Alexey Honorio

Você utiliza Semantic Layer na sua Plataforma de Dados? Já se deparou com a situação de ter o mesmo indicador de negócio sendo analisado por diferentes áreas, e o indicador apresentar valores diferentes em cada uma delas? Pois bem, é raro, mas acontece com frequência 😅 O conceito de Semantic Layer é fundamental no Modern Data Stack e tem como objetivo resolver esse tipo de problema na análise de métricas de negócio. 💡 A ideia é ter uma camada central de métricas de negócio que possa alimentar as camadas de análise e consumo de dados. Alguns dos principais benefícios incluem: ✔ Aumento da confiabilidade nas métricas de negócio; ✔ Melhoria no acesso aos dados e métricas de forma centralizada; ✔ Definição facilitada das métricas, garantindo que a atualização e manutenção sejam escaláveis; ✔ Consistência das métricas em todos os aplicativos de dados. Uma das principais ferramentas com esse propósito é o dbt Labs, que possui o dbt Semantic Layer e o framework MetricFlow para implementar uma camada semântica na prática. E você, já conhecia o Semantic Layer? Tem utilizado em seus projetos? #SemanticLayer #ModernDataStack #DataArchitecture #Data #BigData #DataEngineering #AWSCommunityBuilder

Você conhece o conceito de Features Store 🛒? Isso mesmo, pensamos em construir/criar/gerar o modelo e depois de pronto dá pra reutilizar boa parte daquele processo doloroso 😣 e cansativo de ETL. Features Store economizam recursos de engenharia de dados pois mantém features prontas para novos projetos de machine learning. Nelas são concentrados dados já transformados pelo processo de ETL prontos para serem utilizados em modelos preditivos. É uma explicação básica sobre um sistema de dados complexo responsável por executar as pipelines do processo de ETL (de novo). Foi só uma pitada de conhecimento 😀, dentre tanta coisa legal que o Mago Téo Calvo mostrou essa semana, lá no Workshop Data Science com Databricks da Comunidade Mulheres em Dados. #datascience #dataanalytics #featurestore #mulheresemdados #databricks #teocalvo

O que fazer em cada uma das camadas de um Data Lake? Essa é uma pergunta que recebo com uma certa frequência em novos projetos de dados. As boas práticas na construção de uma Data Lake/Lakehouse, nos traz a divisão do armazenamento em camadas de dados, onde cada camada tem um propósito e regras específicas. A nomenclatura das camadas de um Data Lake pode variar muito, isso depende de cada projeto, empresa e arquitetura utilizada. E também vem evoluindo e surgindo novas soluções. Mas em meio a essas variações, o que não pode faltar são regras: ✔ Qual a finalidade semântica de cada camada; ✔ Quais as políticas de transformações em cada camada; ✔ Quais as regras de consumo nas camadas; ✔ Como os dados serão tratados, transformados e armazenados em cada camada. Eu gosto de trabalhar muito com a nomenclatura abaixo, seguindo algumas regras de alto nível, que podem ser detalhadas em cada projeto: ⚒ raw: nesta camada, os dados são armazenados exatamente como são coletados, sem qualquer processamento significativo. 🔨 staged: aqui os dados podem passar por processos como limpeza, normalização, deduplicação e conversão de formatos. 🔨 curated: a limpeza e a padronização dos dados são realizadas de forma mais rigorosa para garantir consistência e qualidade, aqui os dados são preparados para o negócio. 📐 analytics: esta é a camada onde os dados são consumidos para análises avançadas, relatórios e visualizações, os dados nesta camada são otimizados para consultas rápidas e eficientes. 🗃 sandbox: camada dedicada para experimentação, desenvolvimento e prototipagem de novos modelos de dados, análises e aplicações. Área flexível e menos restritiva para a exploração e inovação. E você como tem organizado as camadas em seu Data Lake? Qual modelo gosta mais? #CamadasDataLake #DataLake #ModernDataStack #DataArchitecture #LeanArchitecture #Data #BigData #DataEngineering #AWSCommunityBuilder

💡 Fala pessoal!!! Dando sequência no assunto Engenharia de dados, hoje, vamos falar sobre Data Pipeline e sua importância. Bora!!! 🚀 Dia 2: A Importância do Data Pipeline ⚙️ O que é um Data Pipeline?  Um Data Pipeline é um conjunto de processos que automatiza o movimento de dados de uma fonte até um destino, como um banco de dados, data warehouse ou data lake. Principais etapas de um pipeline de dados: Ingestão: Coleta de dados.  Processamento: Limpeza, transformação e enriquecimento dos dados.  Armazenamento: Persistência dos dados em um banco adequado.  Entrega: Envio dos dados processados para quem vai consumi-los.  🔹 Por que é importante? A eficiência de um pipeline impacta diretamente a velocidade e a qualidade das decisões baseadas em dados. Automação: Reduz erros manuais e economiza tempo.  Eficiência: Processa grandes volumes de dados de forma escalável.  Qualidade: Garante dados limpos e prontos para insights.  Agilidade: Facilita decisões rápidas em tempo real ou em batch.  💡 Ferramentas como Apache Airflow, Kafka e dbt tornam esse processo ágil, monitorável e robusto. Em um mundo movido a dados, pipelines bem estruturados são essenciais para transformar dados brutos em valor real. 💡 Ter pipelines robustos é crucial para garantir que as informações certas cheguem no momento certo. 🌎 Comente e compartilhe.  #EngenhariaDeDados #PipelineDeDados #BigData #Automação #DataScience #Tecnologia #DataPipeline #DataEngineering

O que fazer em cada uma das camadas de um Data Lake? Essa é uma pergunta que recebo com uma certa frequência em novos projetos de dados. As boas práticas na construção de uma Data Lake/Lakehouse, nos traz a divisão do armazenamento em camadas de dados, onde cada camada tem um propósito e regras específicas. A nomenclatura das camadas de um Data Lake pode variar muito, isso depende de cada projeto, empresa e arquitetura utilizada. E também vem evoluindo e surgindo novas soluções. Mas em meio a essas variações, o que não pode faltar são regras: ✅ Qual a finalidade semântica de cada camada; ✅ Quais as políticas de transformações em cada camada; ✅ Quais as regras de consumo nas camadas; ✅ Como os dados serão tratados, transformados e armazenados em cada camada. Eu gosto de trabalhar muito com a nomenclatura abaixo, seguindo algumas regras de alto nível, que podem ser detalhadas em cada projeto: ⚒ Raw: nesta camada, os dados são armazenados exatamente como são coletados, sem qualquer processamento significativo. 🔨 Staged: aqui os dados podem passar por processos como limpeza, normalização, deduplicação e conversão de formatos. 🔧 Curated: a limpeza e a padronização dos dados são realizadas de forma mais rigorosa para garantir consistência e qualidade, aqui os dados são preparados para o negócio. 📐 Analytics: esta é a camada onde os dados são consumidos para análises avançadas, relatórios e visualizações, os dados nesta camada são otimizados para consultas rápidas e eficientes. 🗃 Sandbox: camada dedicada para experimentação, desenvolvimento e prototipagem de novos modelos de dados, análises e aplicações. Área flexível e menos restritiva para a exploração e inovação. E você como tem organizado as camadas em seu Data Lake? Qual modelo gosta mais? #DataLake #Lakehouse #BigData #Semantic

O que fazer em cada uma das camadas de um Data Lake? Essa é uma pergunta que recebo com uma certa frequência em novos projetos de dados. As boas práticas na construção de uma Data Lake/Lakehouse, nos traz a divisão do armazenamento em camadas de dados, onde cada camada tem um propósito e regras específicas. A nomenclatura das camadas de um Data Lake pode variar muito, isso depende de cada projeto, empresa e arquitetura utilizada. E também vem evoluindo e surgindo novas soluções. Mas em meio a essas variações, o que não pode faltar são regras: ✅ Qual a finalidade semântica de cada camada; ✅ Quais as políticas de transformações em cada camada; ✅ Quais as regras de consumo nas camadas; ✅ Como os dados serão tratados, transformados e armazenados em cada camada. Eu gosto de trabalhar muito com a nomenclatura abaixo, seguindo algumas regras de alto nível, que podem ser detalhadas em cada projeto: ⚒ Raw: nesta camada, os dados são armazenados exatamente como são coletados, sem qualquer processamento significativo. 🔨 Staged: aqui os dados podem passar por processos como limpeza, normalização, deduplicação e conversão de formatos. 🔧 Curated: a limpeza e a padronização dos dados são realizadas de forma mais rigorosa para garantir consistência e qualidade, aqui os dados são preparados para o negócio. 📐 Analytics: esta é a camada onde os dados são consumidos para análises avançadas, relatórios e visualizações, os dados nesta camada são otimizados para consultas rápidas e eficientes. 🗃 Sandbox: camada dedicada para experimentação, desenvolvimento e prototipagem de novos modelos de dados, análises e aplicações. Área flexível e menos restritiva para a exploração e inovação. E você como tem organizado as camadas em seu Data Lake? Qual modelo gosta mais? #DataLake #Lakehouse #BigData #Semantic

Domingo também é dia de inovar! Hoje, estou mergulhado na engenharia e estruturação dos dados de um cliente. Vamos dar uma espiada nas camadas que estamos refinando no coração do processo de ETL. ETL (Extract, Transform, Load) é a espinha dorsal que sustenta um ecossistema de dados sólido e confiável. Vejamos o papel vital de cada camada: 🔍 Raw Data: A autenticidade conta! Capturamos dados na forma mais pura, sem filtros. Autenticidade é a palavra-chave. 🛠️ Stage Layer: A arte está nos detalhes. Limpeza, transformação e enriquecimento moldam os dados para a excelência. 💼 Data Warehouse: A precisão se transforma em velocidade e profundidade. Aqui, os dados são configurados para insights rápidos e decisões estratégicas. Potencialize seus dados com um processo ETL que transforma números em ação! #DataTransformation #ETLProcess #DataInsights #Analytics #DataStrategy #BusinessIntelligence #DataEngineer #DataArchitect #Azure #BigData #DataScience #InnovationSunday #DataDrivenDecision

Porque Data Lakehouse é uma abordagem que funciona muito bem? 😤 Diferente do processo de Business Intelligence & Analytics tradicional com modelagem focada em DW (Star Schema ou Snowflake), nos últimos anos pelo menos as empresas perceberam que leva-se muito tempo para de fato gerar valor na ponta. Essa imagem mostra bem o porque isso tende ser o presente e o futuro das plataformas de dados gerenciadas. Esse tipo de plataforma permite de maneira muito simplificada você criar diferentes produtos de dados como reports, dashboards, exploração analítica e também executar modelos de machine learning e inteligência artificial; uma vez que todos estes dados seguem uma abordagem conhecida como Medallion Architecture (Bronze, Silver e Gold). Essa metodologia de lakehouse que foi difundida pela Databricks, basicamente apresenta um caminho de estruturação de dados bastante eficiente, uma vez que roda em cima da engine do Spark e os dados organizados pelo motor do Delta Lake. Como plataforma de dados, temos a segurança que os dados estão sendo gerenciados por um ambiente unificado e com a governança necessária; e como usuário da ponta, realmente onde o negócio acontece, ele tem todas as ferramentas necessárias para manipulação, modelagem e análise de dados de acordo com a necessidade. Em resumo, o Lakehouse é um CONCEITO e pode ser implementado em qualquer plataforma seguindo esses moldes. Nos próximos dias, vou começar produzir mais conteúdo de Lakehouse, Spark, Delta e claro, muito Databricks. Então fiquem ligados nas próximas cenas!

O que é uma Dimensão Degenerada no dbt e por que ela importa? No mundo de analytics engineering, onde o dbt (Data Build Tool) vem ganhando cada vez mais espaço, entender os conceitos fundamentais do data modeling é essencial para construir pipelines eficientes e organizados. Um desses conceitos é o da dimensão degenerada. Vamos simplificar: imagine que você tem uma tabela de transações que registra todas as vendas feitas por um e-commerce. Cada linha da tabela pode incluir informações como a data da transação, o ID do pedido, os produtos comprados, o valor total, entre outros. Agora, o ID do pedido é único para cada venda e não tem atributos próprios além de si mesmo. Ele é um excelente exemplo de dimensão degenerada. Mas o que significa isso, na prática? A dimensão degenerada é um atributo da tabela de fatos que se comporta como uma dimensão, mas não é modelado como uma tabela separada no banco de dados. Diferente de outras dimensões — como clientes, produtos ou datas — ela não contém dados adicionais além de uma identificação única. Por que isso é útil? Simplicidade no modelo: Ao manter o ID do pedido dentro da tabela de fatos, evitamos criar uma tabela separada que seria redundante. Performance otimizada: Reduzimos o número de joins necessários, já que não precisamos buscar informações adicionais para essa dimensão. Facilidade de rastreamento: IDs únicos como os de pedidos ajudam a conectar as tabelas e identificar transações específicas com rapidez. Exemplos de Dimensões Degeneradas Além de IDs de pedidos, outros exemplos comuns incluem: Números de nota fiscal. Códigos de rastreio de envio. Identificadores de transações financeiras. No dbt, utilizamos esses conceitos para construir pipelines de dados mais eficientes, focando no que realmente importa: entregar dados claros e acionáveis. Por isso, entender dimensões degeneradas é um passo importante para quem quer dominar o data modeling. Gostou desse insight? Compartilha comigo sua experiência com dbt ou data modeling! 🚀

Na live que participei, foi abrodado temas fundamentais para a evolução da engenharia de dados. Comecamos discutindo a transformação histórica do setor, enfatizando a importância de se adaptar às mudanças tecnológicas para extrair insights valiosos. Em seguida, foi apresentado os conceitos básicos sobre data lakes, ressaltando a flexibilidade que oferecem no armazenamento de dados brutos em grande escala. Ao falar sobre silos de dados, foi explicado as diferenças entre os processos de ETL e ELT, destacando as vantagens de cada abordagem para a integração e análise de dados. No contexto dos formatos de arquivo para big data, foi explorado as opções mais comuns, como Parquet, Avro e ORC, e seus respectivos benefícios. Foi abordado também os três Vs do big data: volume, variedade e velocidade, que são cruciais para entender os desafios do gerenciamento de dados em larga escala. Foi discutido os problemas associados aos data lakes, como a falta de governança e controle de qualidade, levando à criação do paradigma do Data Lakehouse, que combina o melhor dos data lakes e data warehouses. A discussão incluiu uma análise das arquiteturas Lambda e Kappa, explicando suas aplicações na engenharia de dados em tempo real e em lote. Foi enfatizado a relevância do Apache Spark como uma ferramenta poderosa para processamento e análise de grandes volumes de dados. Finalizando, foi explorado a Medallion Architecture, uma abordagem estruturada para gerenciar dados em diferentes camadas de refinamento, garantindo eficiência e confiabilidade nos processos de análise. Essa conversa foi essencial para compreender as tendências e desafios atuais no campo da análise de dados. Obrigado Rodolfo Barbosa e parabéns ao Arthur Luz pela dinâmica e pela excelencia ao transmitir o conhecimento. #engenhariadedados #dataenginnering #apachespark #databriks 🚀🚀🚀