Publicação de Nilton Kazuyuki U.

Bom dia Pessoal!!! Chegou o dia da nossa live de ETL, nessa aula iremos trazer um cenário muito comum no dia a dia das empresas, o processo manual de extrair diversas planilhas e começar fazer o mesmo tratamento dos dados, para gerar uma planilha única, e só depois todo um setor começa a trabalhar, imagina que este processo é feito todos os dias, é sério isso é muito mais comum do que você possa imaginar. Muitas vezes nada adianta criar um Data Warehouse para o seu cliente se a entrada de dados para este DW é totalmente manual, o impacto não será o mesmo que você imagina, pois o seu cliente estão tão ocupado, automatizando este processo que não conseguirá perceber o grande trabalho que você está realizando, então só de automatizar este processo irá te abrir muitas portas no seu projeto. Após importar os dados para o Hop, a única coisa que irá mudar é a fonte de dados e também a saída, mas todo o tratamento dos dados é exatamente o mesmo, se estivermos falando da mesma informação, não importa se estamos falando de planilhas, bancos de dados ou algum Data Lake que possua em alguma Cloud. Assim é o Apache Hop, versátil, robusto e claro Open Source da forma que gostamos, seguindo a nossa identidade de anos, agregando o máximo de valor ao cliente com o menor custo possível. E ai bora aprender ETL?? Começamos hoje as 19:00. Link nos comentários. #hopbase #pentarruda #arrudaconsulting #pentaho #pdi #apachehop

A importância da modelagem de dados em um projeto: por que essa prática continua vital em 2024? Em uma época de Big Data, IA generativa e sistemas cada vez mais integrados, a modelagem de dados segue sendo o “fator crítico de sucesso” que todo projeto precisa. Se você é um profissional de TI que trabalha com integração de sistemas, desenvolvimento ou análise de dados, sabe do que estou falando. Gostaria de destacar três motivos pelos quais uma modelagem de dados sólida ainda é a melhor amiga de qualquer projeto - e o que acontece quando ela não é seguida da forma correta: 1 - Clareza e consistência nos requisitos Quantas vezes uma mudança de última hora em uma tabela impactou seu sistema inteiro? Uma boa modelagem evita essas surpresas, ajudando a estruturar e documentar claramente as relações entre dados, assegurando que todos estejam alinhados (do time de dev até o cliente) sobre o que esperar do sistema. Isso significa que menos bugs aparecem no meio da produção e que o time tem mais agilidade para responder a mudanças. 2 - Performance e escalabilidade Quer ver sua aplicação voar? Estruturar dados de forma eficiente desde o início é o que permite que sistemas escalem sem custos desnecessários. Quando dados estão bem modelados, consultas são mais rápidas e o sistema pode suportar picos de acesso sem gargalos, especialmente crítico em projetos que envolvem milhões de usuários ou integrações com múltiplos sistemas. Pense em APIs otimizadas, banco de dados com índices bem definidos, e, claro, relacionamentos entre tabelas que facilitam o crescimento. 3 - Menos retrabalho e economia de recursos Cada hora de retrabalho custa caro! Ao priorizar a modelagem de dados no início, você está prevenindo falhas e retrabalho no futuro. Isso significa um desenvolvimento mais rápido e econômico. Empresas que investem nessa fase inicial conseguem implementar novos módulos, fazer ajustes e integrar sistemas com muito mais facilidade. Isso representa ganho direto em produtividade e menor custo de manutenção. Prática Atual: Data Mesh e Data Vault Para quem está em ambientes complexos, modelagens como Data Mesh e Data Vault estão transformando a forma como lidamos com dados. O Data Mesh, por exemplo, distribui a responsabilidade da modelagem entre as equipes de produto, aumentando a eficiência e permitindo que o dado flua com mais autonomia. Já o Data Vault traz estrutura e flexibilidade para cenários com dados históricos e variantes de sistemas. Investir em modelagem de dados não é perda de tempo; é ganhar vantagem competitiva. Profissionais e empresas que entendem isso saem na frente. E você, como tem feito a modelagem no seu projeto? Compartilhe suas experiências! 👇 #TI #ModelagemDeDados #BigData #Desenvolvimento #Analise #BancoDados

A maior sacada da Databricks foi desenvolver o SQL Warehouse para fortalecer o Lakehouse… Eu confesso que quando vi o SQL Warehouse, pensei: como assim, os caras que querem matar o warehouse desenvolveram um produto de data warehouse? Eu me lembrei do paper do Delta.io sobre lakehouse. Bom, depois de entender o produto e usá-lo na prática em um cliente da Stack Tecnologias, percebi que eles não só competem com outros modern data warehouses como também fortaleceram o lakehouse deles. Como assim? O fato é que o SQL Warehouse consegue ler os dados direto do Lakehouse com uma tecnologia proprietária. Isso permite ao usuário manter o uso das tabelas Delta centralizando tudo no Data Lake, ao mesmo tempo que pode usar o SQL Warehouse como uma interface de acesso. Incrível. Em nosso caso, centralizamos tudo no Data Lake nas camadas Lading, bronze, silver e gold.. Dessa forma, a plataforma fica super enxuta e robusta 🙂 Além disso, com uma solução de catálogo a gente controla bem as permissões no lake e no DW.. Aqui estão as principais características deste produto: - Desempenho otimizado e eficiente ao acessar dados diretamente do Lakehouse. - Integração completa com as tabelas Delta, facilitando a centralização dos dados no Data Lake. - Simplicidade, oferecendo uma interface SQL familiar que facilita a adoção pelas equipes de data engineering. - Escalabilidade para lidar com grandes volumes de dados. - Segurança e conformidade dos dados com controles robustos de acesso e gerenciamento. - Evita silos de dados, reduz a necessidade de movimentação de dados entre diferentes locais. E você já conhecia esse produto nessa ótica? Faz sentido pra você? 💡 Se você quer saber como utilizamos o SQL Warehouse em alguns de nossos clientes, basta me enviar uma mensagem aqui (DM).

Construir ou “comprar” um data pipeline? 🤔 Vamos pensar num cenário onde a empresa precisa unir no seu data warehouse informações de 8 fontes de dados, CRM, marketing email etc… Digamos que HubSpot, Google Ads, Mailchimp, Mixpanel, Asana, Atlassian Jira e um PostgreSQL. É estimado que esse processo leve entre 4 a 6 semanas para cada fonte, aproximadamente 40 semanas de desenvolvimento. 
Se considerarmos que no ano, um engenheiro de dados ganha em média ~R$144.000 no ano (sem considerar os impostos que você vai pagar em cima). Ou seja, para as 40 semanas, ~R$110.770 para construir os data pipelines. 💰 Mas, uma vez que está feito não tem mais custo né? Na verdade não. 44% do tempo dessa galera está em construir e manter data pipelines, e 39% da empresas falam que precisam refazer data pipelines com frequência. Ou seja, ~R$47.000 por ano para manter os data pipelines funcionando. 😯 Isso sem falar no custo de oportunidade e engajamento do colaborador, não conheço nenhum engenheiro que curta ficar fazendo etlzinha de API… Eai, é melhor construir ou comprar um data pipeline? Se tiver na dúvida ou avaliando soluções, me chama aqui pra trocarmos uma ideia sobre como a Erathos pode te ajudar!

Já amanheceu? 👀 👀 Nada melhor do que o silêncio da madrugada para desenvolver um projeto de #dados! 📊 😏 📉 Nesse projeto fictício, estou usando o #Snowflake, como DW e o #dbt, como ferramenta de transformação. 🧐 O trabalho de um #Analytics #Engineer é bem importante nesse processo, pois a partir de dados brutos, ele usa o dbt para criar transformações em #SQL, moldando esses dados em tabelas otimizadas, conhecidas como tabelas fato e dimensões. As #tabelas #fato capturam eventos como vendas ou acessos a sistemas, enquanto as #dimensões dão contexto, como informações sobre clientes, produtos ou períodos de tempo. Isso facilita muito as #análises, permitindo uma visão mais clara e detalhada do que está acontecendo no negócio; uma diferença enorme para o #Data #Analyst que, receberá os dados transformados e interessantes para suas análises de negócio e a criação do seu produto de dados, seja um relatório ou um #dashboard. Um dos grandes benefícios de usar o Snowflake junto com o dbt é a possibilidade de criar pipelines de dados automatizados e versionados. Isso significa que, além de transformar os dados, você consegue garantir que todo o processo seja repetível e transparente, com histórico de mudanças e facilidade para resolver problemas. Em breve apresento mais detalhes sobre esse projeto 😉

Boa tarde, A meu ver o trabalho de um arquiteto de dados moderno consiste em: 1. Mapear as fontes de dados nos sistemas de negócios 2. Identificar pontos de harmonização e melhoria nestas fontes para reduzir numero e complexidade dos pipelines (não é "DAS" pipelines, viu?) - só aqui já ajudou a empresa a reduzir despesas 3. Criar um modelo de dados de referência na organização e modos de carregar os dados a partir dos sistemas de negócios 4. Criar um modelo de referência em analytics, pois os padrões e as integrações já foram definidos 5. Revisar periodicamente os modelos e fazer ajustes 6. Ah, mas e o código para fazer isso? Vem junto com a modelagem como resultado. Não há tempo hábil para fazer mais e os seis itens acima já representam um enorme esforço, mas os resultados se pagam. A boa notícia é que dessa forma seu projeto sai pelo menos 3x mais rápido que pelos métodos atuais. "Ah, mas eu assim vou ficar sem trabalho" - tem certeza? e as manutenções do sistema, as novas necessidades dos usuários? Uma plataforma de dados é um mecanismo evolutivo, nunca para. Você apenas produziu mais rápido e criou espaço para fazer mais. É muito mais realista.

Gerando pipelines de dados de forma fácil. Pra quem tem problema para integrar dados de sistemas diferentes esse curso traz uma abordagem bem interessante para construir data warehouse com dbt e BigQuery. Ele usa inclusive uma ferramenta aqui de Curitiba,a Erathos, para orquestrar pipelines. Eles liberaram um cupom de 100% de desconto (link abaixo) 🙂. Posso por exemplo, juntar os dados do google ads, meta ads com o pipedrive (crm) para calcular a performance por produto e jogar esses dados para onde quiser. Segue curso abaixo: https://lnkd.in/dKtCEvvZ Cupom de 100% de desconto aqui: https://lnkd.in/dzXyNAgt

De 179.000 para 7.600 linhas: simplificação, eficiência e inovação em engenharia e análise de dados Como reduzi uma tabela de disponibilidade em mais de 95% do seu tamanho anterior? O cenário anterior era este: Power Query para construir uma tabela diária, que envolvia mesclar múltiplas fontes, como cadastro de funcionários, calendário, ausências, feriados e percentuais de disponibilidade. O resultado? 179.000 linhas de dados, processamento lento, dificuldades de manutenção e um custo significativo de recursos. Não havia uma camada de storage, e o processamento e tratamento dos dados eram feitas no BI. Além disso os dados estavam granulados de forma diária, o que não era necessário, apesar de ser a maneira mais fácil de montar o conjunto de dados em Power Query. Esse modelo apresentava desafios em manutenção, debug de informações e performance. Qualquer ajuste demandava muito tempo, comprometendo a agilidade do time e a confiabilidade das análises. Diante disso, trouxe uma solução eficaz e de ótimo retorno: reestruturei todo o fluxo diretamente no BigQuery, utilizando SQL. O objetivo era consolidar as regras, otimizar o processamento e transformar a análise diária em uma visão mensal e agrupada. O resultado? Reduzimos 179.000 linhas para apenas 7.600, mantendo todas as informações necessárias para tomadas de decisão estratégicas. 🚀 O pipeline roda todo em nuvem, com Airflow e DBT instanciados em uma VM na GCP. Agora vamos falar das principais vantagens dessa transformação? 1. 🔧 Governança Simplificada Centralizamos todas as regras e cálculos no SQL, garantindo maior visibilidade e rastreabilidade do processo. Alterações ou auditorias são feitas de forma simples e acessível. 2.⚡ Melhoria de Performance Processos antes executados no Power Query foram deslocados para o BigQuery, que é otimizado para grandes volumes de dados. Agora, as análises são geradas com mais rapidez e eficiência. 3. 📉 Redução de Volume de Dados Consolidamos dados diários em análises mensais, eliminando redundâncias. Isso reduziu o volume em mais de 95%, de 179.000 linhas para 7.600. 4. 💾💸 Otimização de Armazenamento e Eficiência Financeira Menos dados armazenados significam menor custo de armazenamento e maior facilidade para carregar relatórios em ferramentas como Power BI. 5. 🔍 Manutenção e Debug Facilitados Toda a lógica está documentada e consolidada em DBT, tornando o fluxo de trabalho mais claro, sustentável e escalável. Ressalto a importância do conhecimento em engenharia de dados. Ela foi essencial para enxergar a oportunidade de melhoria, implementar mudanças estruturais necessárias e criar um fluxo sustentável e escalável. 💬 E você, tem repensado como seus processos de dados estão estruturados? #dbtcore #engenheriadedados #powerbi #dados #analytics

🚀 Data Flow no Azure Data Factory! 💻 Acabei de finalizar o desenvolvimento deste fluxo de dados para um projeto utilizando o #AzureDataFactory, implementando o conceito de Slowly Changing Dimension (SCD) Tipo 2 para garantir a rastreabilidade das alterações nos dados históricos. Esse tipo de estratégia é essencial para cenários em que é necessário manter um histórico completo das mudanças ocorridas nos registros ao longo do tempo. 🔄 O que é SCD Tipo 2? Esse método permite que, ao invés de sobrescrever as informações antigas, uma nova linha seja inserida no banco de dados sempre que uma atualização ocorre, preservando os valores anteriores e possibilitando análises de histórico. 🎯 No projeto, implementei um pipeline que: Integra e transforma os dados da fonte Utiliza joins e condicionais para distribuir os registros entre novas inserções e atualizações. Aplica a estratégia SCD Tipo 2, garantindo a rastreabilidade completa das alterações nos dados. Realiza exportação para tabelas Stage, preservando histórico para análises futuras. 📊 Tecnologias e conceitos envolvidos: Azure Data Factory Azure Data Lake Azure SQL SCD Tipo 2 para manter o histórico de dados É incrível ver o impacto de um pipeline robusto. Nesse caso criamos esse fluxo para cada tabela do ModernBI, feito em 3 camadas ( Source, Stage e Presentation) Claro que cada caso tem que ser avaliado quais ferramentas serão usadas, mas nesse projeto o DataFlow atendeu muito bem e facilita bastante a manutenção. E você, já usou o DataFlow, o que achou? #DataEngineering #Azure #DataPipeline #Automation #ETL #SCDType2 #DataHistory #BigData #DataEngineer