Modelagem e Transformação de Dados

Prévia do material em texto

E-Book Printed Handout Modelagem, Integração e Transformação de Dados E-Book - Printed Handout This file is a static version. For a better experience, access this content through interactive media.E-Book Printed Handout Introdução Nesta segunda unidade, o foco se volta ao núcleo técnico da Engenharia de Dados: compreender como os dados são modelados, integrados e transformados para se tornarem ativos estratégicos nas organizações. Aqui, o aluno é convidado a mergulhar nas bases conceituais e práticas que sustentam a criação de estruturas de dados eficientes e a movimentação inteligente das informações desde a extração até o processamento em grande escala. A proposta é desmistificar processos que, à primeira vista, parecem complexos, como modelagem relacional e dimensional, normalização e desnormalização, além de apresentar as principais técnicas de ingestão de dados em lote, por fluxo contínuo e via Change Data Capture (CDC). Também serão exploradas as ferramentas que viabilizam essas operações, como Airbyte, dbt, Talend e Apache NiFi, e linguagens amplamente usadas em pipelines de dados, como SQL e Python (pandas e PySpark). Essa unidade marca o momento de entender a engrenagem que permite à informação fluir com qualidade, consistência e velocidade dentro de sistemas modernos. Ao final, estudante compreenderá como cada decisão técnica do modelo de dados à escolha da ferramenta de transformação impacta diretamente na performance, integridade e valor das análises produzidas em qualquer projeto de dados. Modelagem de dados A modelagem de dados é um dos pilares fundamentais da Engenharia de Dados. Trata-se do processo de criar uma representação abstrata das estruturas de dados que serão armazenadas, gerenciadas e utilizadas. Um modelo de dados eficaz não apenas define os tipos de dados, relacionamentos e restrições, mas também serve como um mapa que guia a construção de sistemas de dados robustos, escaláveis e de fácil manutenção (Takai, Italiano, Ferreira, 2005; Reis; Housley, 2023). A escolha do modelo de dados adequado é uma decisão arquitetural crítica, pois impacta diretamente desempenho das consultas, a flexibilidade para evoluções futuras e a capacidade de extrair valor dos dados. Exploraremos três paradigmas de modelagem de dados essenciais para o engenheiro de dados moderno: o modelo relacional, o modelo dimensional e o modelo orientado a documentos. Cada um possui características, vantagens e desvantagens distintas, sendo aplicáveis a diferentes contextos e objetivos, desde sistemas transacionais de alta performance até plataformas analíticas de Big Data. Modelagem RelacionalE-Book Printed Handout modelo relacional, proposto por Edgar F. Codd em 1970, representa a base dos sistemas de gerenciamento de banco de dados (SGBDs) modernos e continua sendo o paradigma dominante para sistemas de processamento de transações online (OLTP) (Takai, Italiano e Ferreira, 2005; Batista, 2025). Sua estrutura fundamental é a relação, que é informalmente entendida como uma tabela. Cada tabela é composta por linhas, chamadas de tuplas, e colunas, chamadas de atributos (Lopes, 2024). A força do modelo relacional reside em sua base matemática sólida e na sua capacidade de garantir a integridade e a consistência dos dados por meio de um conjunto de restrições formais: Chaves Primárias (Primary Keys): um ou mais atributos que identificam unicamente cada tupla dentro de uma relação. A restrição de integridade de entidade estabelece que nenhum valor da chave primária pode ser nulo (Takai, Italiano e Ferreira, 2005). Chaves Estrangeiras (Foreign Keys): um conjunto de atributos em uma relação que referencia a chave primária de outra relação. Elas são o mecanismo para estabelecer e reforçar os relacionamentos entre tabelas, garantindo a integridade referencial uma tupla que se refere a outra relação deve, obrigatoriamente, referir- se a uma tupla existente (Takai, Italiano; Ferreira, 2005). Normalização: é o processo de organizar os atributos e as relações de um banco de dados relacional para minimizar a redundância de dados e melhorar a integridade. processo envolve a decomposição de tabelas em estruturas menores e mais bem estruturadas, seguindo um conjunto de regras conhecidas como Formas Normais (1FN, 2FN, 3FN, etc.). objetivo é evitar anomalias de atualização, inserção e remoção que podem ocorrer em dados desnormalizados (Takai, Italiano; Ferreira, 2005; Reis; Housley, 2023). Para Refletir: A Onipresença do Modelo Relacional Embora novos modelos de dados tenham surgido, modelo relacional permanece como a espinha dorsal de inúmeros sistemas críticos, desde transações bancárias e sistemas de faturamento até gerenciamento de recursos de empresas (ERPs) (Lopes, 2024). Sua maturidade, confiabilidade e vasto ecossistema de ferramentas, como a linguagem SQL (Structured Query Language), garantem sua relevância contínua. A habilidade de projetar um esquema relacional normalizado é, portanto, uma competência essencial para qualquer profissional de dados. modelo relacional é ideal para aplicações que exigem alta consistência transacional e integridade de dados, características dos sistemas OLTP, que gerenciam o dia a dia operacional das organizações (Batista, 2025).E-Book Printed Handout Modelagem Dimensional Enquanto a modelagem relacional é otimizada para transações, a modelagem dimensional é a técnica preferida para projetar sistemas analíticos, como Data Warehouses (DW), cujo objetivo é apoiar a tomada de decisão gerencial (Silva, 2024; Campos, 2013). Proposta por Ralph Kimball, essa abordagem organiza os dados de uma maneira que é, ao mesmo tempo, compreensível para os usuários de negócio e otimizada para a execução de consultas analíticas complexas (OLAP) (Silva, 2024; Takai, Italiano e Ferreira, 2005). A modelagem dimensional estrutura os dados em dois componentes fundamentais: Tabelas de Fatos (Fact Tables): armazenam as medições numéricas e os eventos de um processo de negócio. Os fatos são tipicamente numéricos e aditivos, como "valor da venda" ou "quantidade de produtos". Essas tabelas costumam ser muito grandes, podendo conter bilhões de registros (Silva, 2024; Takai, Italiano e Ferreira, 2005). Tabelas de Dimensão (Dimension Tables): contêm o contexto textual e descritivo associado aos eventos da tabela de fatos. Elas descrevem o "quem, o quê, onde, quando, como e porquê" de um evento de negócio. Exemplos incluem dimensões como Cliente, Produto, Tempo e Localização (Silva, 2024). A combinação desses dois tipos de tabela dá origem a esquemas de fácil compreensão, sendo os mais comuns o Star Schema e o Snowflake Schema. Star Schema (Esquema Estrela) Star Schema é a estrutura mais simples e comum da modelagem dimensional. Consiste em uma tabela de fatos central conectada diretamente a um conjunto de tabelas de dimensão. nome "estrela" deriva da disposição das tabelas no modelo, que se assemelha a uma estrela (Takai, Italiano; Ferreira, 2005). Sua principal vantagem é a simplicidade, que facilita a execução de consultas complexas de forma eficiente e intuitiva, pois requer um número menor de junções (joins) (Silva, 2024). Snowflake Schema (Esquema Floco de Neve)E-Book Printed Handout Snowflake Schema é uma variação do Star Schema em que as tabelas de dimensão são normalizadas em múltiplas tabelas relacionadas. Por exemplo, uma dimensão Localização pode ser decomposta em tabelas para País, Estado e Cidade. Isso reduz a redundância de dados e pode economizar espaço de armazenamento, mas ao custo de uma maior complexidade nas consultas, que exigirão mais junções para reconstruir contexto dimensional (Takai, Italiano; Ferreira, 2005). Quadro 1 Modelagem Dimensional: Star Schema vs Snowflake Schema Snowflake Schema (Esquema Característica Star Schema (Esquema Estrela) Floco de Neve) Tabela de fatos central conectada Tabelas de dimensão são Estrutura diretamente às dimensões. normalizadas em hierarquias. Tabelas de dimensão são Tabelas de dimensão são Normalização desnormalizadas. normalizadas. Maior redundância de dados nas Redundância Menor redundância de dados. dimensões. Geralmente mais rápido para Potencialmente mais lento para Desempenho consultas devido a menos consultas devido a mais junções. junções. Mais simples de entender e Mais complexo devido à estrutura Complexidade implementar. normalizada. Mais complexo para manter Manutenção Mais simples de manter. devido a mais tabelas. Fonte: (Baseado em Takai, Italiano e Ferreira 2005 e Silva, 2024) Modelagem Orientada a Documentos Com o advento do Big Data, surgiu a necessidade de lidar com dados que não se encaixam facilmente no formato tabular rígido do modelo relacional. A modelagem orientada a documentos é um dos principais paradigmas dos bancos de dados NoSQL (Not Only SQL), projetada para armazenar e consultar dados como documentos, geralmente em formatos como JSON (JavaScript Object Notation) ou XML (eXtensible Markup Language) (Costa; Izumida, 2023; Moura Neto, 2022). 5 - 61E-Book Printed Handout Diferentemente do modelo relacional, que impõe um schema-on-write (esquema na escrita), onde a estrutura dos dados deve ser definida antes da inserção, os bancos de dados de documentos geralmente adotam uma abordagem de schema-on-read (esquema na leitura) ou schema-a- posteriori, oferecendo um esquema flexível (Reis e Housley, 2023; Monteiro, 2022). Isso significa que documentos dentro da mesma coleção podem ter estruturas diferentes, tornando este modelo ideal para dados semiestruturados e não estruturados. As principais características da modelagem orientada a documentos incluem: Estrutura Hierárquica: Os dados dentro de um documento são frequentemente organizados de forma aninhada ou hierárquica, permitindo que objetos complexos e seus relacionamentos sejam representados em uma única entidade, como no exemplo abaixo: json { "dados_turbina": { "velocidade": "38 rpm", "tensao_saida": "380 V", "corrente_saida": "92 A", "data": "2021-12-08", "hora": "07:54" } } Fonte: (Adaptado de Costa; Izumida, 2023). Escalabilidade Horizontal: são projetados para escalar horizontalmente, distribuindo dados por múltiplos servidores (clusters), que é essencial para aplicações de Big Data (Reis e Housley, 2023). Flexibilidade: a capacidade de adicionar novos campos a documentos sem a necessidade de alterar um esquema predefinido torna este modelo altamente adaptável a requisitos de aplicação que evoluem rapidamente (Azevedo, 2024).E-Book Printed Handout A Ascensão do e Big Data A ascensão dos bancos de dados orientados a documentos está diretamente ligada ao fenômeno do Big Data, caracterizado pelos Vs": Volume, Velocidade e Variedade. Aplicações como redes sociais, Internet das Coisas e sistemas de gerenciamento de conteúdo geram dados heterogêneos e em alta velocidade, para os quais a rigidez do modelo relacional se torna um gargalo. Os bancos de dados de documentos oferecem a flexibilidade e a escalabilidade necessárias para capturar, armazenar e processar essa vasta e diversificada gama de informações (Monteiro, 2022; Costa; Izumida, 2023). Este modelo é particularmente adequado para catálogos de e-commerce, sistemas de gerenciamento de conteúdo, perfis de usuário e dados de sensores, onde a estrutura dos dados pode variar significativamente entre as entidades. Conceitos de normalização e desnormalização para performance analítica No centro desta disciplina, encontram-se dois conceitos aparentemente antagônicos, mas que são, na verdade, duas faces da mesma moeda, aplicados em contextos distintos para otimizar objetivos diferentes: a normalização e a desnormalização. A escolha entre uma abordagem normalizada ou desnormalizada está intrinsecamente ligada à finalidade do sistema de dados. Sistemas projetados para registrar transações do dia a dia, conhecidos como OLTP (Online Transaction Processing), priorizam a integridade dos dados e a eficiência das operações de escrita (inserção, atualização, exclusão). Em contrapartida, sistemas projetados para análise de grandes volumes de dados históricos, conhecidos como OLAP (Online Analytical Processing), priorizam a velocidade e a simplicidade das consultas complexas (Batista, 2025). A compreensão desses dois paradigmas é crucial para o engenheiro de dados projetar arquiteturas de dados robustas e performáticas. Normalização: Maximizando a Integridade em Sistemas Transacionais (OLTP). A normalização é um processo sistemático de organização das colunas e tabelas em um banco de dados relacional para minimizar a redundância de dados (Campos, 2013; Takai, Italiano; Ferreira, 2005). Ao reduzir a redundância, a normalização visa eliminar anomalias de atualização, que são inconsistências de dados que podem ocorrer durante as operações de inserção, atualização ou exclusão.E-Book Printed Handout Anomalias de Atualização A redundância de dados em tabelas não normalizadas pode levar a três tipos principais de anomalias (Campos, 2013; Takai, Italiano; Ferreira, 2005): 1. Anomalia de Inserção: dificuldade ou impossibilidade de inserir um novo registro se parte da informação ainda não existir. Por exemplo, não se pode adicionar um novo departamento se ele ainda não tiver funcionários, caso as informações de ambos estejam na mesma tabela. 2. Anomalia de Exclusão: a remoção de um registro pode levar à perda não intencional de outras informações. Por exemplo, ao excluir único funcionário de um departamento, perde-se também a informação sobre a existência daquele departamento. 3. Anomalia de Modificação: para atualizar uma informação que se repete em várias linhas, é necessário modificar todas as ocorrências. Se a atualização não for feita em todas as linhas, banco de dados se torna inconsistente. A base teórica para a normalização são as dependências funcionais, que descrevem a relação entre atributos, onde o valor de um atributo determina o valor de outro (Campos, 2013). processo de normalização é realizado através da aplicação de um conjunto de regras conhecidas como Formas Normais (FN). As Formas Normais Essenciais Embora existam diversas formas normais, as três primeiras são as mais fundamentais e amplamente utilizadas na prática para o projeto de bancos de dados OLTP. Primeira Forma Normal (1FN): exige que todos os atributos de uma tabela contenham valores atômicos (indivisíveis) e que cada registro seja único. Essencialmente, proíbe colunas com múltiplos valores ou grupos de repetição (Takai, Italiano; Ferreira, 2005). Segunda Forma Normal (2FN): uma tabela está em 2FN se, e somente se, está em 1FN e todos os seus atributos não-chave são totalmente dependentes da chave primária completa. Esta forma normal elimina dependências parciais em tabelas com chaves primárias compostas (Campos, 2013). Terceira Forma Normal (3FN): uma tabela está em 3FN se, e somente se, está em 2FN e todos os seus atributos são dependentes apenas da chave primária, eliminando as dependências transitivas (quando um atributo não-chave depende de outro atributo não-chave) (Campos, 2013; Takai, Italiano; Ferreira, 2005). 8 61E-Book Printed Handout resultado de um processo de normalização, geralmente até a 3FN, é um esquema com um grande número de tabelas menores e mais coesas. Essa estrutura é otimizada para operações transacionais, pois cada "pedaço" de informação é armazenado em um único lugar, garantindo consistência. No entanto, para recuperar uma visão completa de uma entidade de negócio (como um pedido com seus produtos e cliente), é necessário realizar múltiplas operações de junção (joins), o que pode tornar as consultas analíticas complexas e lentas (Reis; Housley, 2023). Desnormalização Se a normalização visa decompor os dados para eliminar redundância, a desnormalização segue o caminho oposto: é o processo de adicionar intencionalmente redundância a um banco de dados para melhorar o desempenho das consultas. Em ambientes analíticos, como um Data Warehouse (DW), a velocidade de leitura é muito mais crítica do que a eficiência de escrita (Reis; Housley, 2023). Analistas de negócio e cientistas de dados precisam executar consultas agregadas complexas sobre grandes volumes de dados históricos, e a performance dessas consultas é primordial. A principal técnica para projetar bancos de dados desnormalizados para fins analíticos é a Modelagem Dimensional. Esta abordagem, popularizada por Ralph Kimball, organiza os dados de uma forma intuitiva que reflete os processos de negócio e é otimizada para consultas de alta performance (Silva, 2024; Reis; Housley, 2023). A modelagem dimensional estrutura os dados em dois tipos de tabelas: Fato e Dimensão. Tabelas Fato: armazenam as medições numéricas e aditivas de um processo de negócio, como valor_venda ou quantidade_itens. São tabelas geralmente muito "longas" (com bilhões de registros), mas "estreitas" (com poucas colunas) (Takai, Italiano; Ferreira, 2005; Reis; Housley, 2023). Tabelas Dimensão: contêm o contexto descritivo e textual associado aos fatos, respondendo a perguntas como "quem?", "o quê?", "onde?" e "quando?". Por exemplo, uma dimensão Produto conteria nome_produto, categoria, marca, etc. Essas tabelas são intencionalmente desnormalizadas, agrupando atributos que, em um modelo normalizado, estariam em tabelas separadas. Elas são tipicamente "largas" (muitas colunas) e "rasas" (relativamente poucos registros) (Takai, Italiano; Ferreira, 2005; Reis; Housley, 2023). Esquemas Dimensionais Comuns A combinação de tabelas fato e dimensão dá origem a esquemas de banco de dados específicos para ambientes OLAP. 9 - 61E-Book Printed Handout Esquema Estrela (Star Schema): é a estrutura mais simples e comum na modelagem dimensional. Consiste em uma tabela fato central conectada diretamente a um conjunto de tabelas de dimensão. nome deriva de sua aparência, semelhante a uma estrela. Por exigir poucas junções (geralmente apenas entre a tabela fato e as dimensões relevantes), é extremamente otimizado para a performance de consultas em ferramentas de BI (Silva, 2024; Takai, Italiano; Ferreira, 2005). Esquema Floco de Neve (Snowflake Schema): é uma variação do esquema estrela onde as tabelas de dimensão são parcialmente normalizadas. Isso significa que uma dimensão pode ter suas próprias sub-dimensões. Por exemplo, a dimensão Produto pode se conectar a uma sub-dimensão Categoria. Essa abordagem reduz a redundância e economiza espaço de armazenamento, mas ao custo de exigir mais junções nas consultas, tornando-as ligeiramente mais lentas em comparação com o esquema estrela (Reis; Housley, 2023; Takai, Italiano; Ferreira, 2005). Síntese e Aplicação no Ciclo de Vida dos Dados A normalização e a desnormalização não são mutuamente exclusivas; elas são estratégias aplicadas em diferentes estágios do ciclo de vida dos dados para atender a diferentes requisitos de sistema. A tabela a seguir resume as principais diferenças entre as duas abordagens. Quadro 2 Normalização vs. Desnormalização 10 61E-Book Printed Handout Característica Normalização Desnormalização Minimizar redundância, Objetivo Principal Maximizar performance de consulta. garantir integridade. Tipo de Sistema OLTP (Transacional) OLAP (Analítico), Data Warehouse Redundância Baixa Alta (intencional) Baixa (múltiplas cópias para Performance de Escrita Alta atualizar) Performance de Leitura Baixa (requer muitas junções) Alta (requer poucas junções) Poucas tabelas grandes Estrutura Muitas tabelas pequenas (Fato/Dimensão) Esquema Estrela, Esquema Floco de Exemplo de Esquema Forma Normal (3FN) Neve Fonte: (Núcleo Editorial). Em uma arquitetura de dados moderna, ambos os modelos coexistem: 1. Sistemas de Origem: Aplicações de negócio (CRMs, ERPs) geralmente utilizam bancos de dados normalizados (OLTP) para registrar transações de forma eficiente e consistente (Batista, 2025). 2. Processo de ETL/ELT: A migração de dados dos sistemas de origem para o ambiente analítico é realizada por processos de Extração, Transformação e Carga (ETL) ou Extração, Carga e Transformação (ELT). É durante a etapa de transformação que os dados são remodelados de um esquema normalizado para um esquema dimensional desnormalizado (Moura Neto, 2022; Lopes, 2024). 3. Ambiente Analítico (Data Warehouse e Data Lakehouse): Data Warehouse é, por definição, um repositório de dados tratados e padronizados, organizados em um modelo dimensional desnormalizado para suportar análises de BI (Costa; Izumida, 2023; Takai, Italiano; Ferreira, 2005). Em arquiteturas mais modernas como o Data Lakehouse, que seguem padrão da Arquitetura Medalhão, os dados se tornam progressivamente mais refinados e estruturados. A camada Bronze armazena dados brutos, enquanto a camada Ouro (Gold) contém dados agregados e modelados para consumo analítico, frequentemente em um formato dimensional e desnormalizado (Batista, 2025). 11 61E-Book Printed Handout A jornada dos dados desde sua criação transacional até sua utilização analítica é, em muitos casos, uma jornada de um estado altamente normalizado para um estado estrategicamente desnormalizado, garantindo que cada sistema opere com máxima eficiência para seu propósito específico. Técnicas de ingestão de dados A ingestão de dados constitui a primeira etapa do ciclo de vida da engenharia de dados, sendo responsável por movimentar os dados de seus sistemas de origem para um repositório centralizado, como um data lake ou data warehouse (Reis; Housley, 2023; Monteiro, 2022). Este processo de "adquirir, organizar e preparar dados" (Azevedo, 2024) é fundamental, pois a forma como os dados são coletados impacta diretamente todas as fases subsequentes de transformação, armazenamento e análise. A escolha da técnica de ingestão é uma decisão arquitetural crítica que depende dos requisitos de negócio, do volume de dados, da variedade das fontes e, principalmente, da velocidade com que os dados precisam ser disponibilizados para análise (Reis e Housley, 2023). As principais abordagens para a ingestão de dados podem ser classificadas em três categorias: em lote (batch), por fluxo contínuo (streaming) e por captura de dados de alteração (Change Data Capture CDC). Cada uma dessas técnicas atende a diferentes necessidades de latência e processamento, sendo componentes essenciais no repertório de um Engenheiro de Dados (Azevedo, 2024). Ingestão em Lote (Batch) A ingestão em lote, ou batch, é o método tradicional de processamento de dados, no qual as informações são coletadas, processadas e carregadas em grandes blocos ou "lotes" (Moura Neto, 2022). Esses processos "geralmente são executados em intervalos determinados de tempo" (Silva, 2024), como de hora em hora, diariamente ou mensalmente, para refletir as mudanças ocorridas nas bases de dados operacionais. Esta abordagem é caracterizada por sua alta capacidade de processamento (throughput), sendo ideal para lidar com grandes volumes de dados onde a necessidade de análise em tempo real não é um requisito primordial. processo de ingestão em lote está intrinsecamente ligado ao paradigma ETL (Extração, Transformação e Carga) ou sua variação moderna ELT (Extração, Carga e Transformação) (Moura Neto, 2022; Lopes, 2024). 12 61E-Book Printed Handout Processo de ETL (Extração, Transformação e Carga processo de ETL (Extraction, Transformation, Load) é amplamente reconhecido como a espinha dorsal de muitas arquiteturas de dados projetadas para processamento em lote. Conforme meticulosamente descrito por Campos (2013), ele se desdobra em uma sequência lógica e bem definida de três etapas cruciais, cada uma desempenhando um papel indispensável na preparação e consolidação dos dados para análise. Extração (Extraction): A Coleta de Dados Brutos A fase inicial, a Extração, concentra-se na captura dos dados brutos a partir de suas fontes originais. Este é frequentemente o ponto de maior complexidade, pois os dados são extraídos de múltiplos e diversos sistemas de origem. É comum que essas fontes tenham sido desenvolvidas de maneira independente ao longo do tempo, utilizando diferentes tecnologias, modelos de dados e convenções, resultando em um alto grau de heterogeneidade (Campos, 2013). A extração deve ser robusta o suficiente para interagir com bancos de dados relacionais, arquivos planos (como CSVs ou logs), APIs, sistemas legados e até mesmo feeds de dados em tempo real ou quase real, garantindo a integridade dos dados na origem antes de passarem para a próxima etapa. Transformação (Transformation): A Preparação e Qualificação dos Dados A Transformação é, indubitavelmente, a etapa mais intensiva em termos de processamento e lógica de negócios. Nela, os dados extraídos são submetidos a uma série rigorosa de procedimentos destinados a garantir sua qualidade, consistência e adequação ao ambiente de destino. Estes procedimentos incluem: Limpeza e Tratamento de Dados: remoção de ruídos, tratamento de valores nulos (nulos), eliminação de duplicatas e correção de erros tipográficos. Padronização: conversão de formatos de dados, unidades de medida e códigos para um padrão unificado (exemplo: garantir que todas as datas sigam o formato AAAA-MM-DD). Verificação e Validação: aplicação de regras de negócio para garantir a validade e a integridade referencial dos dados. Enriquecimento: agregação de informações complementares (exemplo: adicionar dados geográficos baseados em um CEP) ou a criação de novos campos derivados que são essenciais para a análise. Agregação e Sumarização: consolidar múltiplos registros em resumos de alto nível, preparando os dados para o modelo dimensional do destino (Campos, 2013; Reis e Housley, 2023). 13 61E-Book Printed Handout objetivo final desta fase é reparar inconsistências e modelar os dados de forma que se encaixem perfeitamente na estrutura do repositório de destino, maximizando sua utilidade a analítica. Carga (Load): A Consolidação no Destino Finalmente, na fase de Carga, os dados já transformados e qualificados são transportados e armazenados no repositório final de destino. Este destino é tipicamente um data warehouse ou um data lake, onde os dados estarão organizados, indexados e prontos para o consumo. A carga pode ser realizada de duas maneiras principais: Carga Completa (Full Load): onde todo o volume de dados transformados é carregado a cada ciclo. Carga Incremental (Incremental Load): onde apenas os dados novos ou alterados desde a última carga são adicionados ao repositório, uma prática mais eficiente para grandes volumes e dados em constante atualização (Campos, 2013). Uma vez carregados, os dados estão disponíveis para a camada de apresentação, relatórios gerenciais, dashboards e análises aprofundadas. Aplicações Práticas da Ingestão em Lote paradigma de processamento em lote e a metodologia ETL são onipresentes em grandes sistemas corporativos e governamentais, devido à sua eficiência no manuseio de vastos volumes de dados em intervalos programados. Um exemplo prático clássico é a carga mensal de arquivos da folha de pagamento de servidores públicos. Arquivos volumosos, como o "arquivo fita espelho do SIAPE" no contexto brasileiro, são processados em lote. Este processamento é fundamental para fins de auditoria, conciliação e, principalmente, para a construção de um data warehouse que permitirá análises históricas e comparativas da gestão de pessoal (Campos, 2013). Outra aplicação notável se encontra na área da saúde pública. processamento de grandes volumes de registros históricos, como a ingestão de 1,7 bilhão de registros de atendimentos ambulatoriais do SUS coletados ao longo de um período de cinco anos, é necessariamente realizado em lote. Este tipo de processamento massivo é essencial para viabilizar análises epidemiológicas de longo prazo, avaliação de políticas de saúde e gestão eficiente de recursos (Silva, 2024). 14 61E-Book Printed Handout Adicionalmente, a carga de lotes de notas fiscais eletrônicas (NF-e) para plataformas de integração de dados é um exemplo corporativo comum. A sincronização desses dados entre sistemas de vendas, contabilidade e business intelligence ocorre em intervalos programados, utilizando o ETL para garantir que os dados financeiros estejam sempre atualizados para tomada de decisão (Moura Neto, 2022). Em essência, o ETL garante que grandes conjuntos de dados heterogêneos se transformem em uma fonte única, consistente e confiável de inteligência de negócios. Ingestão por Fluxo Contínuo (Streaming) Diferentemente do processamento em lote, a ingestão por fluxo contínuo (streaming) lida com dados ilimitados, que são processados continuamente à medida que são gerados, frequentemente em tempo real ou quase real (Reis e Housley, 2023; Costa, 2023). Essa abordagem é projetada para cenários de alta velocidade e baixa latência, onde o valor da informação decai rapidamente com o tempo. A arquitetura de streaming geralmente envolve fontes que emitem eventos continuamente, uma plataforma de streaming de eventos ou fila de mensagens que atua como um buffer intermediário, e consumidores que processam esses eventos individualmente ou em pequenas janelas de tempo (Reis; Housley, 2023). A ascensão da Internet das Coisas é um dos principais impulsionadores dessa abordagem, com "sensores onipresentes" (Santos, 2023) gerando fluxos contínuos de dados sobre o ambiente físico. Exemplos de aplicação incluem: Salas de Aula Inteligentes: sensores de temperatura, umidade, ruído e câmeras podem gerar fluxos de dados em tempo real para monitorar o ambiente de aprendizagem e o engajamento dos alunos (Santos, 2023). Setor Elétrico: dispositivos loT em usinas e redes de distribuição notificam seu estado atual de forma periódica e em tempo real para um sistema em nuvem, permitindo a supervisão e o controle remoto de operações (Costa; Izumida, 2023). Redes Sociais: plataformas como o Twitter (atual X) disponibilizam APIs de streaming que permitem a coleta e análise de sentimentos de tweets em tempo real, capturando a opinião pública sobre determinados tópicos (Garcia, 2024). A ingestão por streaming é fundamental para aplicações como monitoramento em tempo real, detecção de fraudes, sistemas de recomendação e painéis analíticos que necessitam de informações atualizadas ao segundo. Arquiteturas modernas, como a Arquitetura priorizam streaming como método principal de processamento de dados (Reis e Housley, 2023). 15 61E-Book Printed Handout Captura de Dados de Alteração (Change Data Capture CDC) A Captura de Dados de Alteração, ou Change Data Capture (CDC), é uma técnica especializada de ingestão de dados que se concentra em identificar e capturar as alterações inserções, atualizações e exclusões que ocorrem em um banco de dados de origem e propagá-las para um sistema de destino em tempo real (Silva, 2024). CDC é considerado uma forma eficiente de ingestão de streaming para bancos de dados transacionais (OLTP), pois, em vez de consultar repetidamente a base de dados em busca de novidades (o que aumentaria a carga no sistema de produção), ele opera de maneira mais sutil. A abordagem mais moderna e eficiente para CDC consiste em "adquirir os dados de SGBDs relacionais por meio do seu log de mudança, Write-Ahead Log (WAL)" (Azevedo, 2024). log de transações é um registro sequencial de todas as operações realizadas no banco de dados, e sua leitura permite uma replicação fiel e de baixa latência das alterações sem impactar o desempenho do sistema de origem (Reis e Housley, 2023). principal caso de uso do CDC é a replicação de dados de um banco de dados operacional para um data warehouse ou data lake, permitindo análises quase em tempo real sobre os dados de negócio sem sobrecarregar os sistemas transacionais. Ele é essencial para manter a sincronia entre diferentes bases de dados, como em arquiteturas de microsserviços ou para alimentar painéis analíticos com dados frescos. Alguns exemplos práticos de aplicação do Change Data Capture (CDC) incluem: 1. Alimentação de Data Warehouses e Data Lakes: o CDC é usado para replicar dados transacionais (inserções, atualizações, exclusões) de um banco de dados operacional (como um MySQL ou PostgreSQL) para um ambiente de análise (como Snowflake, BigQuery ou um data lake no S3/ADLS). Isso permite que as equipes de análise tenham acesso a dados quase em tempo real para relatórios e dashboards sem sobrecarregar o sistema de produção. 2. Sincronização de Microsserviços: em uma arquitetura de microsserviços, diferentes serviços podem ter seus próprios bancos de dados. CDC pode ser usado para publicar eventos de mudança (e.g., "Cliente X atualizou seu endereço") para um message broker (como Kafka), permitindo que outros microsserviços que dependem dessa informação reajam e atualizem seus próprios dados, garantindo a consistência eventual. 3. Replicação de Banco de Dados para Alta Disponibilidade/Recuperação de Desastres: o CDC pode ser a base para manter uma cópia idêntica (réplica) do banco de dados de produção em um local diferente, que pode ser rapidamente promovida a primária em caso de falha do sistema principal. 4. Criação de Índices de Busca em Tempo Real: se uma aplicação usa um motor de busca como Elasticsearch ou Solr, o CDC pode ser configurado para capturar 16 61E-Book Printed Handout alterações no banco de dados principal e atualizar automaticamente os índices de busca em tempo real, garantindo que os resultados de pesquisa estejam sempre atualizados. Criação de Cache com Dados Frescos: CDC pode ser usado para invalidar ou atualizar dados em um sistema de cache (como Redis ou Memcached) assim que o dado original é modificado no banco de dados transacional, reduzindo a latência e garantindo que o cache não sirva informações obsoletas. Comparativo das Técnicas de Ingestão A escolha entre batch, streaming e CDC depende fundamentalmente dos requisitos do caso de uso. quadro abaixo sintetiza as principais características de cada abordagem. Quadro 3 Ingestão de Dados: Batch, Streaming e CDC 17 61E-Book Printed Handout Ingestão em Lote Ingestão por Captura de Dados de Característica (Batch) Streaming Alteração (CDC) Processamento de Processamento de Streaming de eventos de Paradigma dados limitados em dados ilimitados, alteração de um banco grandes blocos. evento a evento. de dados. Alta (minutos, horas, Baixa (sub-segundos a Baixa (sub-segundos a Latência dias). segundos). segundos). Contínua, em tempo Contínua, em tempo Frequência Agendada (periódica). real. real. Grandes volumes por Pequenos pacotes de Pequenos pacotes de Volume de Dados execução. dados (eventos). dados (alterações). Arquivos, bancos de Dispositivos logs Bancos de dados Fontes Típicas dados, sistemas de aplicação, redes transacionais (OLTP). legados. sociais. Replicação de banco de Relatórios de BI, Monitoramento em dados, sincronização de ETL/ELT para data tempo real, detecção Casos de Uso sistemas, data warehousing, análises de anomalias, painéis warehousing em tempo históricas. ao vivo. real. Fonte: (Elaborado com base em Santos, 2023; Azevedo, 2024; Campos, 2013; Costa, 2023; Lopes, 2024; Reis; Housley, 2023; Silva, 2024) As técnicas de ingestão de dados formam a base para qualquer arquitetura de dados moderna. Enquanto o processamento em lote continua sendo uma solução robusta e econômica para grandes volumes de dados históricos, as abordagens de streaming e CDC tornaram-se indispensáveis para organizações que necessitam de insights em tempo real para operar de forma competitiva. Frequentemente, arquiteturas de dados eficazes combinam as três abordagens, utilizando cada uma onde seus pontos fortes são mais bem aproveitados, para criar um ecossistema de dados completo e resiliente. Ferramentas de ETL/ELT 18 61E-Book Printed Handout A seleção de ferramentas para a integração e transformação de dados (ETL/ELT) é uma decisão arquitetural crítica que define a espinha dorsal do ciclo de vida da engenharia de dados. Tradicionalmente, o mercado de Data Warehouse (DW) foi dominado por suítes de software monolíticas e robustas, projetadas para encapsular as três fases do processo ETL (Extração, Transformação e Carga). Contudo, a evolução do cenário de Big Data, a explosão do volume e da variedade de dados, e a ascensão de novas arquiteturas, como o Data Lake e o Lakehouse, impulsionaram o surgimento de novas abordagens e ferramentas. Muitas dessas ferramentas são de código aberto (open source) e promovem filosofias distintas, com destaque para o paradigma ELT (Extract, Load, Transform). Exploraremos algumas das ferramentas de maior proeminência na indústria moderna, as quais representam diferentes paradigmas e abordagens para a movimentação, orquestração e o preparo de dados. foco será em soluções de código aberto, as quais têm se estabelecido como o novo padrão para a construção de pilhas de dados modernas (modern data stack). Paradigmas de Integração Antes de nos aprofundarmos nas ferramentas, é imperativo consolidar a distinção fundamental entre os paradigmas ETL e ELT, pois essa escolha dita a arquitetura de dados e as ferramentas a serem empregadas.E (Extract, Transform, Load). processo de ETL constitui a base para a construção de um Data Warehouse tradicional, sendo historicamente o principal consumidor de recursos de implementação e manutenção, podendo absorver até 70% do esforço total de um projeto de DW (Campos, 2013). ETL é definido como um conjunto de procedimentos rigorosos que visa: 1. Extrair dados de diversas fontes operacionais (bases de dados, logs, APIs, arquivos). 2. Transformar esses dados em uma área intermediária (staging area). Essa transformação é essencial para garantir a qualidade, consistência, conformidade com regras de negócio, desduplicação e agregação. 3. Carregar o resultado final, limpo e estruturado, em um repositório centralizado, como um DW (Lopes, 2024; Batista, 2025). A característica definidora do ETL é que a transformação ocorre antes do carregamento no destino. Isso se alinha com conceito de schema-on-write, onde a estrutura dos dados precisa ser definida e aplicada estritamente antes que os dados sejam persistidos no Data Warehouse (Reis; Housley, 2023) .ELT (Extract, Load, Transform). 19 61E-Book Printed Handout paradigma ELT inverte a ordem das duas últimas etapas, promovendo uma filosofia radicalmente diferente, impulsionada pela capacidade computacional massiva e pelo baixo custo de armazenamento das plataformas em nuvem: 1. Extrair os dados das fontes. 2. Carregar os dados em sua forma bruta (raw) diretamente no repositório de destino, que tipicamente é um Data Lake ou um Data Warehouse em nuvem (como Snowflake, BigQuery, Redshift) com alta capacidade de processamento. 3. Transformar os dados posteriormente, sob demanda, utilizando o poder computacional elástico do próprio repositório de destino (Moura Neto, 2022). ELT ganhou força com o advento do Big Data e a necessidade de ingestão rápida de grandes volumes de dados heterogêneos. Ele adota o princípio de schema-on-read, permitindo que os dados brutos sejam carregados rapidamente, e a estrutura e transformações sejam aplicadas apenas no momento da consulta ou modelagem (Reis; Housley, 2023). Quadro 4 Diferenças Técnicas entre ETL e ELT na Arquitetura de Dados ETL (Extract, Transform, Característica ELT (Extract, Load, Transform) Load) 1. Extração, 2. Transformação, 1. Extração, 2. Carga, 3. Ordem das Etapas 3. Carga Transformação Em um servidor intermediário Diretamente no Data Warehouse ou Local da Transformação (staging area), antes do Data Lake de destino, após o carregamento no destino. carregamento. Dados brutos (raw), em seu formato Formato dos Dados na Dados estruturados, limpos e original, podendo ser estruturados Carga no formato final para análise. ou não. 20 61E-Book Printed Handout Otimizado para Data Otimizado para Data Warehouses em Arquitetura de Destino Warehouses tradicionais, com nuvem e Data Lakes, com esquema esquema pré-definido flexível (schema-on-read). (schema-on-write). Menor. Novas análises podem Maior. Os dados brutos permitem Flexibilidade e Agilidade exigir a reengenharia do múltiplas transformações sob pipeline. demanda. Mais lenta, pois a transformação é um gargalo Mais rápida, pois a carga é direta e Velocidade de Ingestão de processamento sem processamento intermediário. intermediário. Complexa, com lógica de Potencialmente mais simples, com Manutenção e transformação em lógica de transformação Escalabilidade ferramentas ETL concentrada em SQL, facilitando especializadas. versionamento e colaboração. Fontes Fonte: (Elaborado com base em Campos, 2013; Reis; Housley, 2023Moura Neto, 2022; Reis; Housley, 2023). Ecossistema Moderno EL(T) A pilha de dados moderna (modern data stack) frequentemente adota uma arquitetura em que as etapas de Extração e Carga (EL) são desacopladas da Transformação (T), dando origem ao modelo EL(T). Nesse modelo, ferramentas se especializam em uma das partes, promovendo modularidade e otimização. 21 61E-Book Printed Handout Airbyte: A Reimaginação do "EL" Tornando a Ingestão uma Commodity Airbyte é uma plataforma de integração de dados de código aberto que se especializa nas etapas de Extração e Carga (EL). Sua filosofia central é simplificar radicalmente a movimentação de dados. A ferramenta propõe que a ingestão de dados de diversas fontes para um destino unificado deve ser uma commodity: padronizada, confiável e acessível, com foco na replicação eficiente de dados brutos (Moura Neto, 2022). Filosofia EL(T) em Ação. Airbyte materializa o modelo EL(T) ao focar exclusivamente em replicar dados da origem para o destino da forma mais fiel e eficiente possível. Ele busca ser o "plumbing" de dados, garantindo que os dados brutos (raw data) permaneçam sempre acessíveis no destino. Dessa forma, as transformações podem ser executadas ou refeitas a qualquer momento sem a necessidade de uma nova sincronização da fonte, delegando a etapa "T" a ferramentas mais adequadas. Arquitetura e Componentes Modulares. Construído para ser extensível, o Airbyte utiliza uma arquitetura de microsserviços e contêineres Docker, o que garante o isolamento e a flexibilidade para suportar diversas tecnologias. Os componentes chave incluem (Moura Neto, 2022): 1. Servidor Web/API: a interface de usuário e o ponto de acesso programático para configuração e gerenciamento de conexões, fontes e destinos (as Connections). 2. Scheduler: o motor que gerencia o agendamento e o acionamento das tarefas de sincronização (Jobs), com base na frequência configurada. 3. Temporal Service: um orquestrador que gerencia a fila de tarefas e os fluxos de trabalho, garantindo a execução, paralelização e o robusto tratamento de falhas dos pipelines. 4. Worker: o componente que, de fato, executa a lógica de movimentação de dados, interagindo com os conectores. 5. Conectores (Sources e Destinations): módulos independentes e isolados em imagens Docker que implementam a lógica específica para interagir com uma fonte de dados (ex: Salesforce, API Stripe) ou um destino (ex: Snowflake, S3). protocolo de conectores é aberto, incentivando a criação e o compartilhamento de novos módulos pela comunidade. Protocolo e Modos de Sincronização Flexíveis A interação entre os workers e os connectors segue um protocolo de comunicação bem definido. Um conector de origem deve implementar comandos como spec (para descrever as entradas), check (para validar a conexão) e, crucialmente, read (para ler os dados). conector de destino implementa o comando write para gravar os dados (Moura Neto, 2022). 22 61E-Book Printed Handout A flexibilidade do Airbyte se manifesta nos diversos modos de sincronização, permitindo que o usuário escolha a melhor estratégia para replicação de dados: Full Refresh Overwrite: sincroniza todo o dataset da origem e substitui completamente a tabela no destino. Full Refresh Append: sincroniza todos os dados da origem e os anexa aos dados existentes no destino (útil para logs ou dados de eventos). Incremental Append: o modo mais comum. Lê apenas os dados novos ou modificados da origem (identificados por um cursor, como uma coluna de updated_at) e os anexa no destino. Incremental Deduped History (Change Data Capture CDC): um modo incremental avançado que rastreia alterações e fornece uma visão final desduplicada, espelhando o estado atual da origem, mas também possibilitando a manutenção de um histórico de alterações (Slowly Changing Dimensions). dbt (data build tool): Engenharia de Software para a Transformação ("T") Uma vez que o Airbyte carrega os dados brutos no Data Warehouse ou Data Lake, a etapa de transformação se torna o foco para modelar, limpar e preparar esses dados para consumo analítico. dbt (data build tool) surge como a ferramenta padrão para a etapa de Transformação ("T") no ecossistema ELT moderno. Seu principal propósito é aplicar princípios consagrados da engenharia de software ao processo de transformação de dados. Ele permite que analistas e engenheiros de dados transformem dados in-place (no próprio repositório de destino) simplesmente escrevendo instruções SELECT em SQL. É crucial notar que o dbt não extrai nem carrega dados; ele se concentra exclusivamente na transformação, operando sobre os dados já persistidos no DW (Moura Neto, 2022). Principais Características e Benefícios. dbt potencializa o SQL com funcionalidades avançadas, transformando-o em um verdadeiro ambiente de desenvolvimento de software para dados: Modelos e Materializações: o coração do dbt são os models, que são arquivos SQL contendo instruções SELECT. dbt executa esses SELECTs e os materializa no destino como tabelas, visões ou tabelas incrementais. Templates com Jinja: o dbt utiliza Jinja, um poderoso mecanismo de template, para estender as capacidades do SQL. Isso permite o uso de macros (funções SQL reutilizáveis), laços (for) e condicionais (if), promovendo o princípio DRY (Don't Repeat Yourself) e tornando o código SQL mais dinâmico e reutilizável. Gerenciamento de Dependências (DAG): o dbt analisa automaticamente as referências entre os modelos (usando a função {{ }}) e constrói um Grafo Acíclico Dirigido (DAG). este DAG garante que as transformações sejam executadas na ordem correta, resolvendo automaticamente a dependência 23 61E-Book Printed Handout de que um modelo derivado só pode ser construído após suas fontes estarem prontas. Testes Automatizados: permite a criação de testes de integridade para validar a qualidade dos dados transformados. Testes schema (como not_null, unique, accepted_values) e testes data (consultas SQL complexas para validar regras de negócio) previnem a introdução de dados inconsistentes nos modelos finais. Documentação e Linhagem de Dados: o dbt gera automaticamente um site de documentação interativo. Este site inclui o código-fonte de cada modelo, descrições de colunas, e o DAG de dependências completo, fornecendo uma visão clara da linhagem (data lineage) dos dados, crucial para a governança. Controle de Versão (GitOps) e CI/CD: ao tratar as transformações como código, o dbt permite que as equipes de dados utilizem práticas consagradas de desenvolvimento de software, como controle de versão via Git, revisão de código (code review) e pipelines de Integração/Entrega Contínua (CI/CD), elevando o nível de robustez e manutenibilidade das transformações. Integração Ponto a Ponto: o dbt se integra nativamente com ferramentas de orquestração (como Airflow) e de EL (como Airbyte), que podem acionar a execução de um projeto dbt imediatamente após uma carga de dados bem-sucedida, automatizando o pipeline ELT de ponta a ponta (Moura Neto, 2022). Ferramentas de Orquestração e Pipeline Embora Airbyte e dbt dominem a pilha ELT moderna, outras ferramentas continuam a ter um papel fundamental em cenários específicos, especialmente em arquiteturas que exigem processamento stream ou em ambientes legados de ETL.Apache NiFi: Fluxos de Dados e Processamento em Tempo Real. Apache NiFi é um poderoso framework para a automação do fluxo de dados entre sistemas de software. É especialmente projetado para cenários de alto volume e processamento contínuo (stream processing) ou em lote, onde a linhagem de dados e a garantia de entrega (guaranteed delivery) são cruciais. Natureza: Plataforma de orquestração de data flows visual e orientada a eventos. Foco: Movimentação e processamento de dados em trânsito, com capacidade de transformação rudimentar (T) antes do destino. Características Principais: Design Orientado a Fluxo (Flow-Based Programming): permite a construção visual de pipelines complexos através de processadores (ex: FetchSFTP, PutHDFS, ConvertJSONToSQL). Data Provenance (Linhagem de Dados): NiFi rastreia cada Data Flow File (o dado em movimento) desde a origem até o destino, oferecendo um registro auditável deE-Book Printed Handout onde o dado veio e como foi transformado. Garantia de Entrega: utiliza um repositório interno para garantir que os dados não sejam perdidos, mesmo em caso de falhas no sistema. Back Pressure: mecanismos que evitam que fontes mais rápidas sobrecarreguem destinos mais lentos, mantendo a saúde do sistema. NiFi é ideal para ingestão contínua, roteamento complexo de mensagens e interações com sistemas on-premise e Big Data em tempo real.Talend Open Studio: Legado e a Evolução do ETL Gráfico Talend é uma suíte de integração de dados que oferece soluções de ETL, gerenciamento de qualidade de dados e integração de aplicações. Embora a versão comercial seja robusta, o Talend Open Studio é a versão de código aberto amplamente utilizada, representando a abordagem tradicional de ETL gráfico. Natureza: ferramenta gráfica (GUI-based) para ETL/ELT e integração de dados. Foco: mapeamento visual de transformações e integração com fontes de dados diversas. Características Principais: Ambiente Gráfico: permite que o usuário desenhe visualmente os jobs de ETL, conectando componentes que representam extração, transformação e carga (ex: tMap para mapeamento de colunas, tFilterRow para filtragem). Geração de Código: os jobs desenhados no Talend são convertidos em código Java, que é executado no servidor. Conectividade Extensa: possui uma vasta biblioteca de conectores para sistemas legados, ERPs, CRMs e bancos de dados. Suporte a ELT: versões mais recentes e componentes permitem que o Talend empurre a lógica de transformação para o banco de dados de destino (utilizando o tELT), adaptando-se ao paradigma ELT, mas com uma arquitetura fundamentalmente orientada ao job de ETL. Talend é frequentemente escolhido por empresas que preferem uma abordagem visual e que operam em ambientes onde a transformação é complexa e deve ocorrer em um servidor de staging dedicado antes de entrar no DW. Convergência e Escolha Arquitetural A escolha da ferramenta de integração de dados é uma reflexão direta sobre a arquitetura de dados adotada. ETL Tradicional: ferramentas como Talend e suítes proprietárias são ideais para 25 61E-Book Printed Handout Data Warehouses legados ou cenários onde a transformação intermediária é um requisito estrito (como a aplicação de regras de negócio complexas antes da exposição de dados). ELT e a Pilha Moderna: a combinação de Airbyte (para um "EL" rápido, confiável e modular) e dbt (para um "T" robusto, testável e versionado em SQL) se tornou a arquitetura predominante para Data Lakes e Data Warehouses em nuvem, aproveitando a escalabilidade e o poder computacional do destino final. Fluxos Contínuos:o Apache NiFi é a ferramenta de escolha para orquestração de dados em tempo real, roteamento complexo de eventos e garantia de entrega em fluxos contínuos. A engenharia de dados moderna converge para um ecossistema de ferramentas modulares e especializadas, muitas delas de código aberto, que juntas oferecem a flexibilidade e poder necessários para lidar com os desafios do Big Data. Transformação de dados com SQL avançado e Python A transformação de dados é uma etapa fundamental e indispensável no ciclo de vida da engenharia de dados (Reis; Housley, 2023; Azevedo, 2024). Este processo consiste em um conjunto de operações que convertem dados brutos, muitas vezes inconsistentes e desestruturados, em um formato limpo, organizado e adequado para análise. objetivo principal é agregar valor aos dados, capacitando sua transformação em informações úteis e, subsequentemente, em conhecimento que pode subsidiar a tomada de decisões informadas (Costa, 2023; Siqueira, 2012). No contexto de pipelines de dados, a transformação pode ocorrer em diferentes momentos. No modelo tradicional de ETL (Extract, Transform, Load), os dados são transformados antes de serem carregados no repositório final, como um Data Warehouse (Campos, 2013). Já no paradigma moderno de ELT (Extract, Load, Transform), os dados brutos são primeiro carregados em um repositório escalável (como um Data Lake ou Data Warehouse em nuvem) e as transformações são aplicadas posteriormente, aproveitando o poder de processamento do próprio repositório (Moura Neto, 2022). Independentemente da abordagem, a transformação abrange uma vasta gama de atividades, desde a limpeza e padronização até o enriquecimento e a agregação de dados. Para executar essas tarefas, o engenheiro de dados dispõe de um arsenal de ferramentas, sendo SQL e Python, com suas bibliotecas especializadas como pandas e PySpark, as mais proeminentes. Transformação de Dados com SQL Avançado 26 61E-Book Printed Handout A linguagem SQL (Structured Query Language) transcendeu seu propósito original de consulta para se tornar uma ferramenta robusta para a transformação de dados. Em arquiteturas de Data Warehouse e, especialmente, no paradigma ELT, o SQL é o protagonista na aplicação de regras de negócio, limpeza e modelagem de dados diretamente no ambiente de armazenamento (Moura Neto, 2022). Embora operações básicas como JOIN e GROUP BY sejam fundamentais (Takai, Italiano e Ferreira, 2005), técnicas avançadas elevam drasticamente a capacidade de manipulação de dados. Estratégias de Transformação com SQL As transformações em SQL podem ser categorizadas em diversas estratégias, conforme destacado por Moura Neto (2022): Agregação: sumarização de dados para calcular totais, médias e outras métricas. Construção de Atributos: criação de novas colunas a partir de atributos existentes para enriquecer o dado. Discretização: conversão de valores contínuos em intervalos ou categorias. Manipulação: alteração de dados para torná-los mais legíveis e organizados, como a padronização de formatos de data. Para implementar essas estratégias de forma eficiente, o engenheiro de dados recorre a recursos avançados do SQL. Técnicas Avançadas de SQL para Transformação 1. Funções de Janela (Window Functions): diferentemente das funções de agregação tradicionais que colapsam os registros, as funções de janela realizam cálculos sobre um conjunto de linhas (uma "janela") relacionado à linha atual, preservando a granularidade original dos dados. Elas são essenciais para análises complexas, como cálculo de médias móveis, rankings e comparações anuais. A sintaxe OVER (PARTITION BY ORDER BY ...) é a base para sua aplicação. Quadro 5 Funções de Janela SQL: Propósitos e Exemplos 27 61E-Book Printed Handout Função de Janela Propósito Exemplo de Aplicação Atribui um número sequencial Numerar clientes por ordem de `ROW_NUMBER()` único para cada linha dentro compra em cada região. de uma partição. Calcula o ranking de uma Classificar os produtos mais `RANK()`, `DENSE_RANK()` linha dentro de sua partição. vendidos por categoria. Acessa dados de uma linha Calcular a variação de vendas `LAG()`, `LEAD()` anterior ou posterior à linha em relação ao mês anterior. atual. Calcula uma soma ou média Acompanhar o crescimento `SUM()`, `AVG()` cumulativa (running acumulado da receita ao longo `OVER(...)` total/average). do ano. Expressões de Tabela Comuns (Common Table Expressions CTEs): As CTEs, introduzidas pela cláusula WITH, permitem criar conjuntos de resultados temporários e nomeados que podem ser referenciados dentro de uma instrução SELECT, INSERT, UPDATE ou DELETE. Elas são fundamentais para quebrar transformações complexas em etapas lógicas e sequenciais, melhorando drasticamente a legibilidade e a manutenibilidade do código SQL, alinhando-se à ideia de um pipeline de dados (Costa; Izumida, 2023). Exemplo de CTE para calcular a receita por cliente antes da agregação final Manipulação de Dados Semi-estruturados (JSON): bancos de dados modernos oferecem suporte nativo para consultar e manipular dados em formato JSON diretamente via SQL. Funções para extrair valores (JSON_VALUE, JSON_QUERY), modificar e agregar dados JSON são essenciais para lidar com a variedade de dados característica do Big Data. 28 61E-Book Printed Handout Quadro de Destaque: ETL vs. ELT A principal diferença entre os dois processos reside no local onde a transformação ocorre. ETL (Extract, Transform, Load): os dados são extraídos das fontes, transformados em um servidor intermediário (staging area) e, em seguida, carregados no destino final (Campos, 2013). Era padrão quando os Data Warehouses tinham capacidade de processamento limitada. ELT (Extract, Load, Transform): os dados brutos são extraídos e carregados diretamente no repositório de destino (um Data Lake ou Data Warehouse moderno). A transformação é executada "in-loco", utilizando poder computacional do destino. Essa abordagem é facilitada por ferramentas como dbt (data build tool), que permite aos engenheiros de dados gerenciar transformações complexas escritas em SQL (Moura Neto, 2022). Transformação de Dados com Python (pandas, PySpark) Python se consolidou como a linguagem de programação dominante para ciência e engenharia de dados, graças a um ecossistema robusto de bibliotecas que facilitam desde a limpeza de dados até a construção de modelos complexos de machine learning (Garcia, 2024). No contexto da transformação, duas bibliotecas são centrais: pandas, para manipulação de dados em memória em uma única máquina, e PySpark, a API Python para Apache Spark, projetada para processamento distribuído de grandes volumes de dados (Silva, 2024). Transformação com pandas A biblioteca Pandas é ideal para conjuntos de dados que cabem na memória de um único servidor. Sua principal estrutura, o DataFrame, oferece uma interface intuitiva e de alta performance para uma vasta gama de operações de transformação. Tarefas Comuns de Transformação com pandas: Limpeza de Dados: Tratar dados ausentes é uma tarefa primordial (Costa; Izumida, 2023). pandas oferece métodos como. fillna para preencher valores nulos com uma constante, média ou mediana, e .dropna para remover linhas ou colunas com valores ausentes. A remoção de duplicatas é igualmente simples com .drop_duplicates() (Garcia, 2024). Transformação de Tipos de Dados: Garantir que cada coluna tenha o tipo de dado correto (numérico, data, string) é crucial para a performance e a correção das 29 61E-Book Printed Handout análises. método .astype é usado para essa conversão (Batista, 2025). Manipulação de Texto: Dados textuais frequentemente requerem um pré- processamento extensivo. acessador .str do pandas permite aplicar uma infinidade de operações em strings, como converter para minúsculas (.str.lower()), remover espaços em branco (.str.strip()), e substituir padrões usando expressões regulares (.str.replace()) (Garcia, 2024). Funções de Transformação: Funções customizadas podem ser aplicadas a colunas ou linhas inteiras usando método .apply(). Isso permite a implementação de regras de negócio complexas ou a aplicação de funções de transformação, como a normalização de dados por meio de transformações logarítmicas ou a extração de informações específicas de um rótulo (Martins, 2016). Escalando Transformações com PySpark Quando o volume de dados excede a capacidade de memória de uma única máquina um cenário comum em Big Data (A. e 2020), ferramentas de processamento distribuído como o Apache Spark se tornam indispensáveis. PySpark oferece uma API que espelha muitas das funcionalidades do pandas, mas executa as transformações de forma paralela em um cluster de computadores (Silva, 2024; Batista, 2025). A transformação de dados com PySpark é frequentemente estruturada em etapas que refletem uma maior maturidade e qualidade dos dados, como na Arquitetura Medalhão. Arquitetura Medalhão A Arquitetura Medalhão é um padrão de design que organiza os dados em um Data Lake ou Lakehouse em três camadas lógicas (Batista, 2025): Camada Bronze (Bruta): armazena os dados em seu formato original, extraídos das fontes. As transformações são mínimas, focando apenas na conversão de formato e particionamento. Camada Silver (Prata): contém dados que passaram por um processo de limpeza, validação e enriquecimento. Tarefas como remoção de duplicatas, tratamento de nulos e conformidade de tipos de dados são realizadas aqui. Camada Gold (Ouro): apresenta os dados em um formato agregado e modelado para fins de negócio, prontos para análise e relatórios. Tabelas nesta camada são frequentemente desnormalizadas e otimizadas para consultas de BI. Operações de Transformação em PySpark: 30 61E-Book Printed Handout A sintaxe do PySpark é funcional e declarativa. As transformações são "preguiçosas" (lazy), ou seja, o plano de execução é construído à medida que as transformações são definidas, mas a computação só ocorre quando uma ação (como .show() ou .write()) é invocada. Seleção e Filtragem: select() e filter() (ou where()) são usadas para selecionar colunas e filtrar linhas. Em um caso de uso com dados públicos de saúde, uma das primeiras transformações foi reduzir o dataset de 60 colunas para apenas 19 que eram relevantes para a análise (Silva, 2024). Manipulação de Colunas: A função withColumn() é a principal ferramenta para adicionar ou modificar colunas. withColumnRenamed( renomeia colunas, e o método .cast() é usado para alterar tipos de dados. Agregações e Junções: groupBy() seguido de funções de agregação (agg()) e o método join() funcionam de maneira similar ao SQL, mas em um contexto de processamento distribuído. Funções Nativas (Built-in Functions): PySpark oferece um vasto repertório de funções no módulo pyspark.sql.functions para manipulação de strings, datas, arrays e operações matemáticas, que geralmente oferecem melhor performance do que Funções Definidas pelo Usuário (UDFs). Requisitos para Execução de Scripts PySpark Antes de apresentarmos alguns exemplos de utilização do PySpark, é indispensável levantarmos os requisitos técnicos e de arquitetura e dependência para a execução adequada de scripts PySpark em ambiente local, é fundamental atender aos seguintes requisitos técnicos: Quando este capítulo é escrito, para executar scripts com PySpark, é necessário atender a alguns requisitos técnicos. Primeiramente, é indispensável instalar o Java Development Kit (JDK), na versão 8 ou superior, sendo recomendadas as versões 11 ou 17 para melhor compatibilidade. Essa exigência se deve ao fato de o Apache Spark ser desenvolvido em Scala, que opera sobre a Java Virtual Machine (JVM). A verificação da instalação pode ser feita executando o comando "java version" no terminal. Certifique-se que a instalação do Python na versão 3.7 ou superior, juntamente com um gerenciador de pacotes, como pip, que geralmente acompanha as distribuições modernas da linguagem. Para instalar PySpark, basta utilizar o comando "pip install pyspark". Algumas configurações de ambiente opcionais, mas recomendadas, incluem definir a variável JAVA_HOME apontando para o caminho de instalação do JDK, ajustar as configurações de memória conforme os recursos disponíveis na máquina e, no caso de ambientes Windows, realizar configurações adicionais com o utilitário winutils para garantir compatibilidade. 31 61E-Book Printed Handout Por fim, é importante considerar os recursos de sistema necessários para uma execução adequada. Recomenda-se um mínimo de 4 GB de memória RAM, sendo ideal 8 GB ou mais, além de espaço suficiente para armazenar dados e arquivos temporários. sistema operacional pode ser Windows, Linux ou macOS. Considerações sobre Complexidade de Configuração A configuração do ambiente PySpark pode apresentar desafios técnicos, particularmente em sistemas Windows, onde dependências adicionais como o winutils.exe são necessárias para pleno funcionamento. A interoperabilidade entre Java e Python introduz camadas de complexidade que demandam atenção meticulosa às versões e configurações ambientais. Como alternativa pedagógica, caso encontrem obstáculos na configuração do ambiente PySpark ou para contextos educacionais onde a escalabilidade distribuída não é requisito fundamental, recomenda-se a utilização da biblioteca Pandas como alternativa pedagógica. Embora o Pandas opere em memória local e não ofereça os benefícios de processamento distribuído do Spark, sua sintaxe simplificada e requisitos técnicos menos complexos (apenas Python e a biblioteca Pandas) proporcionam um ambiente de aprendizagem acessível para conceitos fundamentais de transformação e análise de dados. Esta abordagem permite focar nos conceitos essenciais de manipulação de dados como limpeza, agregação e transformação sem as complexidades inerentes aos sistemas distribuídos, servindo como base conceitual para posterior migração para ecossistemas big data quando necessário. Vantagens da Abordagem com Pandas para Aprendizado: Configuração simplificada Curva de aprendizado menos íngreme Documentação extensa e comunidade ativa Transferência direta de conceitos para PySpark Adequada para conjuntos de dados de tamanho moderado. Esta estratégia equilibra a aquisição de competências técnicas com acessibilidade, garantindo que barreiras de configuração não comprometam o processo de aprendizagem dos fundamentos de engenharia de dados. Primeiramente, vamos apresentar uma versão do script utilizando o PySpark e, logo na sequência, uma utilizando Pandas e, adicionalmente, um script que deve ser executado primeiramente para criar a pasta "data" com as subpastas e os arquivos que serão utilizados. 32 61E-Book Printed Handout Script 1 Construindo a base de dados de consulta from pyspark.sql import SparkSession from pyspark.sql.functions import col, trim, lower, mean import pandas as pd import os def criar_diretorios_e_dados(): """Cria a estrutura de diretórios e dados de exemplo""" # Criar diretórios se não existirem diretorios = [ "data/bronze/vendas", "data/silver/vendas", "data/gold/vendas_aggregadas" ] for diretorio in diretorios: exist_ok=True) # Criar dados de exemplo em pandas df_exemplo = pd.DataFrame({ 'produto': [' Produto A', 'Produto B', 'produto a', 'Produto C', 'Produto B'], 'valor': [100, 150, 100, 200, 150], # valor será renomeado para receita 'data_venda': ['2023-01-05', '2023-01-06', '2023-01-05', '2023-01-07', '2023-01-06'], 'categoria': ['Eletronicos', 'Moveis', 'Eletronicos', 'Roupas', 'Moveis'] }) # Salvar como Parquet na camada Bronze index=False) print("Dados de exemplo criados em data/bronze/vendas/") def executar_pipeline_spark(): """Executa o pipeline PySpark 33 61E-Book Printed Handout # Inicializar a sessão Spark spark = SparkSession.builder \ .config("spark.sql.adaptive.enabled", "true") \ # Configurar logs para ver apenas erros print("Carregando dados da camada Bronze...") try: # Carregar dados (ex: de um Data Lake na camada Bronze) df_bronze = print(f"Schema original:") df_bronze.printSchema() print(f"Contagem inicial: {df_bronze.count()} registros") print("Primeiros registros:") df_bronze.show() # Transformações para a camada Silver print("\nAplicando transformações para camada Silver...") df_silver = lower(trim(col("produto")) \ .withColumnRenamed("valor", "receita") \ .na.drop(subset=["receita"]) \ .dropDuplicates() print(f"Contagem após limpeza: {df_silver.count()} registros") print("Dados da camada Silver:") df_silver.show() # Salvar na camada Silver 34 61E-Book - Printed Handout df_silver.write.mode("overwrite").parquet("data/silver/vendas" print("Dados salvos na camada Silver") # Exemplo de agregação para a camada Gold print("\nCriando agregações para camada Gold...") df_gold = .agg({"receita": "sum"}) .withColumnRenamed("sum(receita)", .orderBy("produto") print("Dados da camada Gold:") df_gold.show() # Salvar na camada Gold print("Dados salvos na camada Gold") # Verificar arquivos gerados print("\nPipeline executado com sucesso!") print("Estrutura de arquivos criada:") for root, dirs, files in os.walk("data"): level = root.replace("data", "").count(os.sep) indent = level subindent = (level + 1) for file in files: print(f"{subindent}{file}") except Exception as e: print(f"Erro durante a execução: {e}") finally: # Encerrar a sessão Spark 35 61E-Book Printed Handout spark.stop() print("\nSessão Spark encerrada.") if name == # Criar dados de exemplo criar_diretorios_e_dados() # Executar pipeline Spark executar_pipeline_spark() Script 2 - PySpark: operação de transformação from pyspark.sql import SparkSession from pyspark.sql.functions import col, trim, lower import os import sys # Configurar para evitar problemas no Windows os.environ['PYSPARK_PYTHON'] = sys.executable os.environ['PYSPARK_DRIVER_PYTHON'] = sys.executable def configurar_spark_windows(): """Configurações específicas para Windows""" # Configurar a sessão Spark para Windows spark = SparkSession.builder \ "true") "true") \ "org.apache.hadoop.fs.LocalFileSystem") \ .config("spark.sql.warehouse.dir", .getOrCreate() 36 - 61E-Book - Printed Handout # Configurar logs return spark def criar_dados_exemplo_spark(spark): """Criar dados de exemplo diretamente no Spark""" from pyspark.sql.types import StructType, StructField, StringType, DoubleType # Definir schema schema = StructType([ StringType(), True), StructField("valor", DoubleType(), True), StringType(), True), StructField("categoria", StringType(), True) ]) # Criar dados (" Produto 100.0, "2023-01-05", "Eletronicos"), ("Produto B", 150.0, "2023-01-06", "Moveis"), ("produto a", 100.0, "2023-01-05", "Eletronicos"), ("Produto 200.0, "2023-01-07", "Roupas"), ("Produto B", 150.0, "2023-01-06", "Moveis") ] df_bronze = spark.createDataFrame(data, schema) return df_bronze def executar_pipeline_spark_corrigido(): """Executa o pipeline PySpark corrigido para Windows""" print("Iniciando PySpark com configurações para Windows...") 37 61E-Book Printed Handout try: # Configurar Spark spark = configurar_spark_windows() print("Spark session criada com sucesso!") # Criar dados de exemplo df_bronze = criar_dados_exemplo_spark(spark) print("Dados originais (Bronze):") df_bronze.show() # Transformações para Silver df_silver = \ .withColumnRenamed("valor", "receita") \ .dropDuplicates() print("Dados transformados (Silver):") df_silver.show() # Criar diretórios se não existirem os.makedirs("data/silver/vendas", exist_ok=True) os.makedirs("data/gold/vendas_aggregadas" exist_ok=True) # Salvar Silver (usando formato alternativo se Parquet der problema) try: print("Dados salvos na camada Silver (Parquet)") except: # Fallback para CSV print("Dados salvos na camada Silver (CSV)")E-Book - Printed Handout # Agregação para Gold df_gold = .agg({"receita": "sum"}) \ .withColumnRenamed("sum(receita)", .orderBy("produto") print("Agregações (Gold):") df_gold.show() # Salvar Gold try: print("Dados salvos na camada Gold (Parquet)") except: print("Dados salvos na camada Gold (CSV)") Pipeline PySpark executado com sucesso!") return spark except Exception as e: Erro durante a execução: {e}") return None def verificar_arquivos_gerados(): """Verifica os arquivos gerados pelo Estrutura de arquivos criada:") for root, dirs, files in os.walk("data"): level = root.replace("data", "").count(os.sep) indent = levelE-Book Printed Handout subindent = 2 * (level + 1) for file in files[:5]: # Mostra apenas os primeiros 5 arquivos print(f"{subindent}{file}") if len(files) > 5: mais {len(files) 5} arquivos") # Executar pipeline Spark spark_session = executar_pipeline_spark_corrigido() # Verificar arquivos verificar_arquivos_gerados() # Encerrar Spark se estiver ativo if spark_session: spark_session.stop() print("\nSpark session encerrada.") Script 3 Pandas: operação de transformação import pandas as pd import os def """Cria a estrutura de diretórios e dados de exemplo""" diretorios = [ "data/bronze/vendas", "data/silver/vendas", "data/gold/vendas_aggregadas" ] for diretorio in diretorios: os.makedirs(diretorio, exist_ok=True) 40 61E-Book - Printed Handout # Criar dados de exemplo df_exemplo = pd.DataFrame({ 'produto': [' Produto A', 'Produto B', 'produto a', 'Produto C', 'Produto B'], 'valor': [100, 150, 100, 200, 150], 'data_venda': ['2023-01-05', '2023-01-06', '2023-01-05', '2023-01-07', '2023-01-06'], 'categoria': ['Eletronicos', 'Moveis', 'Eletronicos', 'Roupas', 'Moveis'] }) # Salvar na camada Bronze print("Dados de exemplo criados em data/bronze/vendas/") return df_exemplo def """Executa o pipeline usando Pandas (sem Spark)""" print("Carregando dados da camada Bronze...") # Carregar dados df_bronze = pd.read_parquet("data/bronze/vendas/part-0.parquet") print("Schema original:") print(df_bronze.info()) print(f"Contagem inicial: {len(df_bronze)} registros") print("Primeiros registros:") print(df_bronze.head()) # Transformações para a camada Silver print("\nAplicando transformações para camada Silver...") df_silver = df_bronze.copy() # Limpeza e padronização 41 61E-Book Printed Handout df_silver['produto'] = df_silver = df_silver.rename(columns={'valor': 'receita'}) # Remover duplicatas df_silver = print(f"Contagem após limpeza: {len(df_silver)} registros") print("Dados da camada Silver:") print(df_silver) # Salvar na camada Silver print("Dados salvos na camada Silver") # Agregação para a camada Gold print("\nCriando agregações para camada Gold...") df_gold = as_index=False)['receita'].sum() df_gold = 'receita_total'}) df_gold = print("Dados da camada Gold:") print(df_gold) # Salvar na camada Gold print("Dados salvos na camada Gold") print("\nPipeline executado com sucesso usando Pandas!") # Verificar arquivos gerados print("Estrutura de arquivos criada:") for root, dirs, files in os.walk("data"): level = root.replace("data", "").count(os.sep) indent = level 42 61E-Book Printed Handout subindent = 2 * (level + 1) for file in files: # Criar dados de exemplo df_exemplo = # Executar pipeline Pandas executar_pipeline_pandas() A transformação de dados é um campo multifacetado que combina a lógica declarativa do SQL com a flexibilidade programática do Python. A escolha entre SQL, pandas ou PySpark depende fundamentalmente da escala dos dados, da infraestrutura disponível e da complexidade das operações. Um engenheiro de dados proficiente deve dominar essas ferramentas para construir pipelines de dados robustos, eficientes e que entreguem valor real à organização. Estratégias para garantia de qualidade de dados A eficácia de qualquer sistema de dados, desde um Data Warehouse (DW) tradicional até as modernas plataformas de Big Data, é diretamente proporcional à qualidade dos dados que ele gerencia. Dados de má qualidade inevitavelmente conduzem a análises falhas, modelos preditivos ineficazes e, consequentemente, a tomadas de decisão equivocadas (Campos, 2013). Portanto, a implementação de uma estratégia robusta para a garantia da qualidade de dados não é uma etapa opcional, mas um pilar fundamental da Engenharia de Dados. Este processo visa transformar dados brutos, muitas vezes heterogêneos e inconsistentes, em um ativo informacional confiável e de alto valor (Reis; Housley, 2023). As estratégias para a garantia de qualidade de dados podem ser organizadas em três atividades centrais e interdependentes: validação, limpeza e enriquecimento. Essas atividades são tipicamente executadas no contexto de processos de Extração, Transformação e Carga (ETL) ou, em arquiteturas mais modernas, de Extração, Carga e Transformação (ELT) (Moura Neto, 2022). 43 61E-Book Printed Handout Qualidade de Dados como Recurso Estratégico A informação é um recurso estratégico essencial para a competitividade e a sobrevivência das organizações. A qualidade dos dados, portanto, depende intrinsecamente dos processos de planejamento e desenvolvimento inerentes à sua geração e tratamento (Siqueira, 2012; Campos, 2013). A implementação de sistemas de suporte à decisão (SSD), como plataformas de Business Intelligence (BI), não se sustenta com dados de qualidade inferior, pois seu caráter estratégico exige consistência e confiabilidade (Campos, 2013; Sarubbi, 2014). Validação de Dados A validação de dados é processo de assegurar que os dados estejam em conformidade com regras, restrições e lógicas de negócio predefinidas. Seu objetivo é garantir a exatidão, a consistência e a integridade dos dados antes que eles sejam utilizados em análises ou carregados em sistemas de destino. As principais técnicas de validação incluem: Restrições de Integridade em Nível de Banco de Dados: a primeira linha de defesa da qualidade dos dados ocorre no próprio sistema de gerenciamento de banco de dados (SGBD). Restrições como integridade de entidade (garantindo que chaves primárias não sejam nulas) e integridade referencial (assegurando que chaves estrangeiras se refiram a registros existentes) são mecanismos fundamentais para prevenir inconsistências estruturais (Takai, Italiano e Ferreira, 2005). Verificação de Tipos, Formatos e Domínios: consiste em verificar se cada atributo está em conformidade com seu tipo de dado esperado (ex: numérico, texto, data) e formato (ex: AAAA-MM-DD). Além disso, valida-se se os valores pertencem a um domínio predefinido de valores aceitáveis (Takai, Italiano e Ferreira, 2005). Validação de Regras de Negócio: muitas regras de qualidade são específicas do domínio da aplicação. Por exemplo, uma regra pode estipular que "o salário de um empregado não pode exceder o do seu supervisor" ou que "a data de um pedido não pode ser posterior à data de entrega". Essas restrições semânticas devem ser especificadas e verificadas para garantir a coerência dos dados com mundo real que representam (Takai, Italiano e Ferreira, 2005). Validação por Referência Externa: uma técnica poderosa consiste em confrontar os dados internos com fontes de dados externas e autoritativas. Por exemplo, um cadastro de endereços pode ser validado e corrigido utilizando como referência o Diretório Nacional N de Endereços (DNE) dos Correios. Este processo não apenas valida, mas também pode corrigir e enriquecer os dados (Campos, 2013). 44 61E-Book Printed Handout Validação Humana (Crowdsourcing): em cenários de alta complexidade ou ambiguidade, como na resolução de entidades (determinar se dois registros se referem à mesma pessoa), a validação puramente automática pode ser imprecisa. Nesses casos, a validação humana, muitas vezes orquestrada por meio de plataformas de crowdsourcing, torna-se essencial. Especialistas no domínio podem ser convocados para classificar a validade de um par de dados como "Casamento Perfeito" (Perfect Matching), "Relacionado" (Related) ou "Não Relacionado" (No Relation), garantindo um nível superior de acurácia (Martins, 2016). Limpeza de Dados A limpeza de dados (data cleaning ou data cleansing) é o processo de identificar, corrigir ou remover dados "sujos", ou seja, registros corrompidos, imprecisos, incompletos, duplicados ou mal formatados. Enquanto a validação detecta a não conformidade, a limpeza atua para remediar os problemas encontrados (Campos, 2013; Silva, 2024). Um processo sistemático de limpeza de dados pode ser estruturado conforme as etapas apresentadas no quadro a seguir. Quadro 6 Processo de Limpeza e Padronização de Dados 45 61E-Book Printed Handout Etapa Descrição Exemplo Prático Separação de um atributo Dividir o campo "Endereço Elementarização composto em seus Completo" em "Logradouro", componentes atômicos. "Número", "Bairro", "Cidade". Aplicação de um formato Converter todas as variações de Padronização padrão para cada "São Paulo", "S. Paulo", "SP" para elemento de dado. um único padrão "SP". Busca por erros em cada elemento de dado, como Verificação valores fora de um Identificar um campo "Idade" intervalo esperado. com valor "200". Detecção de elementos ou Identificar que "José da Silva" e registros que se referem à Identificação "J. Silva" no mesmo endereço mesma entidade do são a mesma pessoa. mundo real (duplicados). Agrupamento de registros que possuem Agrupar todos os clientes que House holding características em comum, residem no mesmo domicílio. como membros da mesma família. Captura dos resultados e das regras aplicadas para Registrar que a sigla "RJ" foi Documentação criar um dicionário de padronizada a partir de "Rio de dados e facilitar futuras Janeiro" e "Rio". limpezas. Fonte: Adaptado de Campos (2013). As tarefas mais comuns no processo de limpeza incluem: Tratamento de Dados Ausentes (Missing Data): Dados faltantes são um problema recorrente. As estratégias para lidar com eles incluem: 46 61E-Book Printed Handout Remoção: Descartar registros ou colunas com um volume excessivo de dados faltantes, embora essa abordagem possa levar à perda de informação valiosa (Costa; Izumida, 2023). Ressignificação (Imputação): Preencher os valores ausentes com uma medida de tendência central (média, mediana) ou o valor mais frequente (moda). Essa técnica deve ser usada com cautela para não introduzir viés nos dados (Costa; Izumida, 2023). Interpolação: Estimar valores ausentes com base em outros pontos de dados, especialmente útil em séries temporais (Costa; Izumida, 2023). Correção de Erros e Inconsistências: A correção de erros de digitação e inconsistências é um passo fundamental na preparação dos dados (A. e 2020). Para isso, algoritmos de similaridade de strings, como a Distância de Levenshtein (que mede o número de edições para transformar uma string em outra) e Coeficiente de Dice (que mede a sobreposição de bigramas), são amplamente utilizados para identificar e corrigir valores textuais semelhantes, mas não idênticos (Campos, 2013). Remoção de Outliers: outliers são observações que se desviam drasticamente de outras observações em um conjunto de dados. Eles podem ser resultado de erros de medição ou representar uma anomalia real. Ferramentas estatísticas, como o boxplot, são eficazes para identificar visualmente esses pontos discrepantes, que podem ser removidos ou tratados separadamente para não distorcer os resultados da análise (Costa; Izumida, 2023). Limpeza de Dados Não Estruturados (Texto): dados textuais, como os provenientes de redes sociais, exigem um processo de pré-processamento intensivo. As etapas incluem a remoção de elementos irrelevantes (menções a usuários, links, emojis, pontuação), a padronização do texto (conversão para minúsculas) e a remoção de duplicações, garantindo que o texto esteja pronto para análises como a de sentimento (Garcia, 2024). Normalização: no contexto de bancos de dados relacionais, a normalização é um processo de organização dos atributos e tabelas para minimizar a redundância de dados e resolver anomalias de inserção, atualização e remoção. É uma forma estrutural de limpeza e transformação de dados (Takai, Italiano;Ferreira, 2005). Enriquecimento de Dados enriquecimento de dados é o processo de agregar valor a um conjunto de dados brutos, combinando-o com informações contextuais de outras fontes, sejam elas internas ou externas. objetivo é transformar "dados" em "informação" e, subsequentemente, em "conhecimento", tornando conjunto de dados mais completo, útil e acionável para análise (Costa, 2023; Siqueira, 2012). As estratégias de enriquecimento podem ser categorizadas da seguinte forma: 47 61E-Book Printed Handout Integração com Fontes de Dados Adicionais: a forma mais direta de enriquecimento é a integração de dados de fontes heterogêneas para "agregar informações adicionais e estabelecer relações significativas entre os dados coletados" (Costa, 2023). Por exemplo, dados de produção ambulatorial do SUS podem ser enriquecidos ao serem integrados com tabelas auxiliares do Cadastro Nacional de Estabelecimentos de Saúde (CNES) ou da Classificação Internacional de Doenças (CID), adicionando contexto descritivo aos registros de atendimento (Silva, 2024). Construção de Novos Atributos: enriquecimento também pode ocorrer pela criação de novos atributos (feature engineering) a partir de dados já existentes. Isso pode envolver desde cálculos simples (ex: calcular a idade a partir da data de nascimento) até agregações complexas (Moura Neto, 2022). Enriquecimento Semântico: esta técnica consiste em adicionar uma camada de significado aos dados. Exemplos incluem: Análise de Sentimento: processar um texto bruto (ex: uma avaliação de produto) para adicionar um novo atributo, como uma pontuação de sentimento (positivo, negativo ou neutro), enriquecendo o dado original com uma interpretação emocional (Garcia, 2024). Classificação de Dados: rotular ou "tagear" dados de acordo com metadados ou regras de negócio, como classificar dados como "pessoais" ou "sensíveis" no contexto de leis de privacidade como a GDPR. Essa classificação enriquece o dado com informações sobre sua natureza e requisitos de manuseio (Monteiro, 2022). Enriquecimento Geográfico: adicionar dados geoespaciais, como coordenadas, regiões, estados ou microrregiões, a partir de um CEP ou nome de município. Essa prática é comum e de grande valor para análises de mercado e logística (Silva, 2024). Arquiteturas e Processos para Qualidade de Dados A implementação das estratégias de validação, limpeza e enriquecimento está intimamente ligada à arquitetura de dados da organização. ETL vs. ELT: em uma arquitetura ETL tradicional, as transformações, incluindo limpeza e enriquecimento, ocorrem em uma área de preparação (staging area) antes que os dados sejam carregados no Data Warehouse (Lopes, 2024). Já em arquiteturas ELT, os dados brutos são carregados primeiro em um repositório de alta performance, como um Data Lake, e as transformações são aplicadas "sob demanda" diretamente no ambiente de destino, oferecendo maior flexibilidade (Moura Neto, 2022). Arquitetura Medalhão (Medallion Architecture): é um padrão de projeto moderno 48 61E-Book Printed Handout para organizar dados em um Data Lakehouse. Os dados progridem através de três camadas de qualidade: Bronze: contém os dados brutos, ingeridos em seu formato original, servindo como um registro histórico e auditável. Silver: Armazena dados que passaram por processos de limpeza, filtragem, validação e normalização. É a camada onde a qualidade dos dados é assegurada. Gold: contém dados agregados, enriquecidos e prontos para o consumo por aplicações de BI e Machine Learning, geralmente organizados em modelos de dados específicos para o negócio (Batista, 2025). Zonas de Dados em Data Lakes: De forma análoga à Arquitetura Medalhão, os Data Lakes são frequentemente organizados em "zonas" (ex: zona crua, zona refinada, zona sensível), onde os dados são movidos e processados à medida que sua qualidade e utilidade aumentam (Monteiro, 2022). A garantia da qualidade de dados é um processo contínuo e iterativo, que exige uma combinação de técnicas automáticas, validação humana e uma arquitetura de dados bem projetada. A aplicação diligente das estratégias de validação, limpeza e enriquecimento é o que permite transformar o potencial latente do Big Data em conhecimento acionável e vantagem competitiva para as organizações. Integração de dados de múltiplas fontes A capacidade de coletar, combinar e processar dados de sistemas heterogêneos é fundamental para a construção de qualquer sistema analítico robusto, seja um data warehouse tradicional ou uma plataforma de dados moderna em nuvem. Como engenheiros de dados, nosso papel é construir os dutos (pipelines) que permitem que os dados brutos, gerados em diversas partes de uma organização ou no mundo, fluam de maneira confiável e eficiente até os sistemas onde serão transformados em informação e conhecimento. A integração de dados compreende as fases de Ingestão (Ingestion) e Transformação (Transformation) do ciclo de vida da engenharia de dados. A ingestão é o processo de extrair dados de sistemas de origem e carregá-los em um sistema de armazenamento centralizado, como um data lake ou data warehouse. A transformação, por sua vez, envolve a limpeza, modelagem e enriquecimento desses dados para prepará-los para consumo (Reis; Housley, 2023). Uma decisão arquitetural fundamental neste processo é a escolha entre os paradigmas ETL (Extract, Transform, Load) e ELT (Extract, Load, Transform). No modelo ETL, os dados são transformados antes de serem carregados no destino, geralmente um data warehouse estruturado. Já no modelo ELT, os dados brutos são primeiro carregados em um repositório escalável, como um data lake, e as transformações são aplicadas sob demanda, aproveitando o poder de processamento do sistema de destino (Moura Neto, 2022). A ascensão de tecnologias de big data e armazenamento em nuvem tornou padrão ELT cada vez mais predominante (Reis; Housley, 2023). 49 61E-Book Printed Handout Nossa análise será estruturada em torno dos quatro principais tipos de fontes de dados que encontraremos na prática: APIs, arquivos, bancos de dados e streams. Integração via APIs (Application Programming Interfaces) As APIs são interfaces que permitem a comunicação e a troca de dados entre diferentes sistemas de software de forma padronizada. No contexto da integração de dados, as APIs, especialmente as baseadas no estilo arquitetural REST (Representational State Transfer), são fontes comuns de dados externos, como os de redes sociais, serviços de mercado ou parceiros de negócio (Batista, 2025). A extração de dados via API geralmente segue dois padrões principais (Reis; Housley, 2023): 1. Polling (Sondagem): o sistema de ingestão consulta periodicamente o endpoint da API para verificar se há novos dados. Este é o padrão mais comum, utilizado para coletar dados de plataformas como o Twitter (agora X) (Garcia, 2024) ou de serviços governamentais como o IBGE (Silva, 2024). 2. Webhooks (Push): a fonte de dados notifica ativamente sistema de ingestão sempre que um novo evento ocorre, enviando os dados diretamente para um endpoint pré-configurado. Este padrão é mais eficiente para dados em tempo real, pois elimina a necessidade de sondagens constantes. A integração via APIs apresenta desafios específicos, como o tratamento de limites de taxa de requisições (rate limiting), a navegação por múltiplas páginas de resultados (paginação) e a adaptação a mudanças na estrutura dos dados retornados (evolução de esquema) (Reis e Housley, 2023). Integração a partir de Arquivos Arquivos são, talvez, a forma mais antiga e heterogênea de troca de dados. Eles podem variar desde arquivos de texto simples, como CSV (Comma-Separated Values) e TXT, até formatos semiestruturados como JSON e XML, que são amplamente utilizados em documentos fiscais eletrônicos (Moura Neto, 2022; Campos, 2013). 50 61