Livro Digital

Prévia do material em texto

E-Book - Printed Handout Armazenamento e Processamento Distribuído 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 Chegamos à nossa terceira unidade, um ponto crucial da jornada em Engenharia de Dados. Aqui, o foco se volta para os fundamentos de armazenamento e processamento distribuído, pilares que sustentam a manipulação de dados em larga escala. Em um mundo onde o volume e a velocidade das informações crescem exponencialmente, compreender como os dados são armazenados, distribuídos e processados de forma eficiente é essencial para transformar grandes massas de informação em conhecimento estratégico. Nesta unidade, você vai entender como os bancos de dados relacionais e NoSQL moldam diferentes arquiteturas de sistemas, explorando suas características, vantagens e aplicações práticas. Também veremos como processamento distribuído, representado por tecnologias como Hadoop e Spark, possibilita que dados sejam tratados de maneira simultânea em múltiplas máquinas, garantindo desempenho, escalabilidade e confiabilidade. Ao longo dos tópicos, ficará claro que a engenharia de dados vai muito além do armazenamento trata-se de projetar soluções capazes de extrair valor real das informações. Assim, esta unidade convida você a compreender como as decisões técnicas sobre armazenamento e processamento influenciam diretamente a capacidade analítica e o potencial competitivo das organizações. Bancos de dados relacionais (PostgreSQL, MySQL) e (MongoDB, Cassandra, Redis) A seleção de um sistema de gerenciamento de banco de dados (SGBD) é uma das decisões arquiteturais mais críticas na Engenharia de Dados. A forma como os dados são armazenados e recuperados impacta diretamente o desempenho, a escalabilidade, a consistência e a flexibilidade de qualquer aplicação ou sistema de análise. Historicamente, cenário foi dominado por bancos de dados relacionais, mas a emergência do Big Data impulsionou o desenvolvimento e a adoção de uma nova classe de bancos de dados, conhecidos como NoSQL. Esta unidade explora as características, os casos de uso e os principais exemplos de ambos os paradigmas. Bancos de Dados Relacionais (SQL) 2 - 40E-Book Printed Handout modelo relacional, idealizado por Edgar Frank Codd, representa os dados como uma coleção de relações, que são, informalmente, tabelas (Takai, Italiano; Ferreira, 2005; Gurrola et al., 2020). Essa abordagem, fundamentada em conceitos matemáticos da teoria dos conjuntos, estrutura os dados em tabelas compostas por linhas (tuplas) e colunas (atributos), onde cada linha representa um registro único e cada coluna armazena um atributo específico desse registro (Marquesone, 2017). A principal força do modelo relacional reside em sua estrutura rígida e na garantia da integridade dos dados. Isso é alcançado por meio de um esquema predefinido (schema-on-write), que estabelece a estrutura das tabelas, os tipos de dados de cada coluna e as restrições antes que qualquer dado seja inserido (Marquesone, 2017). A consistência é mantida por meio de mecanismos como: Chaves Primárias: atributos (ou um conjunto deles) que identificam unicamente cada tupla dentro de uma relação (Takai, Italiano; Ferreira, 2005). Chaves Estrangeiras e Integridade Referencial: atributos que estabelecem um vínculo entre duas tabelas, garantindo que uma tupla em uma relação que se refere a outra, de fato, aponte para uma tupla existente, mantendo a consistência entre os dados relacionados (Takai, Italiano; Ferreira, 2005). A manipulação e consulta dos dados em SGBDs relacionais são realizadas predominantemente através da Linguagem de Consulta Estruturada (SQL Structured Query Language), um padrão robusto e amplamente adotado no mercado (Costa; Izumida, 2023; Gurrola et al., 2020). As Propriedades ACID As transações em bancos de dados relacionais são governadas pelas propriedades ACID, que asseguram a confiabilidade das operações mesmo em cenários de falha (Duarte, 2024; Marquesone, 2017): Atomicidade: garante que uma transação seja executada em sua totalidade ou não seja executada de forma alguma. Não existem operações parciais. Consistência: assegura que cada transação leve banco de dados de um estado válido para outro, preservando as restrições de integridade. Isolamento: garante que transações concorrentes não interfiram umas nas outras, produzindo um resultado que seria mesmo se as transações fossem executadas sequencialmente. Durabilidade: uma vez que uma transação é confirmada (commit), suas alterações são permanentes e não serão perdidas, mesmo em caso de falha do sistema Exemplos de Bancos de Dados Relacionais 3 40E-Book Printed Handout PostgreSQL: é um SGBD de código aberto amplamente considerado um dos mais avançados e robustos do mercado. Destaca-se por sua aderência aos padrões SQL, alta capacidade de escalabilidade e por oferecer recursos avançados como replicação e alta disponibilidade, sendo uma escolha sólida para garantir confiabilidade e integridade dos dados (Duarte, 2024; Costa; Izumida, 2023). MySQL: um dos SGBDs relacionais de código aberto mais populares do mundo, conhecido por sua eficiência, velocidade e facilidade de uso em aplicações de diversos portes (Duarte, 2024). Embora seja robusto para muitas aplicações, pode enfrentar desafios de desempenho ao lidar com volumes de dados massivos ou consultas excessivamente complexas (Duarte, 2024). Devido à sua maturidade e foco na consistência, os bancos de dados relacionais são a escolha predominante para sistemas transacionais (OLTP), como sistemas bancários e de faturamento, e para a construção de Data Warehouses (DW) tradicionais, que exigem dados estruturados e confiáveis para análises de Business Intelligence (BI) (Silva, 2024; Campos, 2013). Bancos de Dados (Not Only SQL) crescimento exponencial no volume, variedade e velocidade dos dados, fenômeno conhecido como Big Data, expôs as limitações do modelo relacional (Marquesone, 2017; Garcia, 2024). Aplicações web de larga escala, como as de redes sociais e e-commerce, passaram a demandar maior flexibilidade de esquema, escalabilidade horizontal (adição de mais servidores ao sistema) e alta disponibilidade, características que os SGBDs relacionais tradicionais não foram projetados para oferecer com a mesma eficiência (Marquesone, 2017; Gurrola et al., 2020). Nesse contexto, surgiram os bancos de dados NoSQL (Not Only SQL), um conjunto diversificado de tecnologias de armazenamento que abandonam a estrutura rígida de tabelas em favor de modelos mais flexíveis (Costa; Izumida, 2023). Suas principais características incluem: Esquema Flexível: em vez de um esquema predefinido (schema-on-write), muitos bancos NoSQL utilizam um esquema dinâmico ou schema-on-read, onde a estrutura dos dados pode variar entre os registros e evoluir ao longo do tempo sem a necessidade de migrações complexas (Marquesone, 2017). Escalabilidade Horizontal: são projetados desde o início para escalar horizontalmente, distribuindo os dados e a carga de trabalho por múltiplos servidores em um cluster, o que os torna mais adequados para lidar com grandes volumes de dados (Gurrola et al., 2020; Marquesone, 2017). Alta Disponibilidade: priorizam a disponibilidade, muitas vezes replicando os dados em diferentes nós do cluster para garantir que o sistema continue operacional mesmo em caso de falha de um dos servidores (Marquesone, 2017). 4 40E-Book Printed Handout Essa flexibilidade é alcançada, em parte, pela flexibilização das garantias transacionais ACID em favor do modelo base. As Propriedades BASE Em contraste com modelo ACID, muitos sistemas NoSQL operam sob os princípios BASE, que priorizam a disponibilidade em sistemas distribuídos (Duarte, 2024): Basically Available (Basicamente Disponível): sistema garante a disponibilidade, mesmo que ocorram falhas parciais na rede. Soft State (Estado Leve): estado do sistema pode mudar ao longo do tempo, mesmo sem novas entradas, devido à consistência eventual. Eventually Consistent (Eventualmente Consistente): sistema garante que, se nenhuma nova atualização for feita em um dado item, eventualmente todas as suas réplicas convergirão para mesmo valor. A consistência não é imediata. A seguir, apresentamos um quadro comparativa que resume as principais diferenças entre os dois paradigmas. Quadro 1 Comparativo entre Bancos de Dados SQL e NoSQL 5 40E-Book Printed Handout Bancos de Dados Relacionais Característica Bancos de Dados (SQL) Estruturado e baseado em Modelos variados: documentos, Modelo de Dados tabelas (relações). chave-valor, colunas largas, grafos. Rígido e predefinido (schema- Flexível, dinâmico ou inexistente Esquema on-write). (schema-on-read). vertical Predominantemente horizontal Escalabilidade (aumento de recursos em um (distribuição em múltiplos único servidor). servidores). Consistência eventual, baseada nas Forte consistência, garantida Consistência propriedades BASE. Prioriza a pelas propriedades ACID. disponibilidade. Linguagens de consulta variadas e SQL (Linguagem de Consulta Linguagem específicas para cada modelo Estruturada) como padrão. (NoSQL). Sistemas transacionais, aplicações que exigem alta Big Data, aplicações web de larga Casos de Uso consistência, Data escala, dados não estruturados, Warehouses. Fonte: (Elaborado com base em Gurrola et al., 2020; Marquesone, 2017; Duarte, 2024; Costa; Izumida, 2023). Tipos de Bancos de Dados e Exemplos universo NoSQL não é monolítico; ele compreende diferentes modelos de dados, cada um otimizado para um tipo específico de problema. Orientado a Documentos Neste modelo, os dados são armazenados em documentos, que são estruturas de dados hierárquicas e flexíveis, comumente em formatos como JSON (JavaScript Object Notation) ou BSON (Binary JSON) (Gurrola et al., 2020; Duarte, 2024). Um conjunto de documentos forma uma "coleção", análoga a uma tabela no modelo relacional. A grande vantagem é que cada documento em uma mesma coleção pode ter uma estrutura diferente, permitindo grande flexibilidade (Marquesone, 2017). 6 40E-Book Printed Handout MongoDB: é um dos bancos de dados orientados a documentos mais populares. Desenvolvido em C++, é de código aberto e multiplataforma, conhecido por seu alto desempenho e por uma linguagem de consulta rica que permite indexação e agregações complexas (Duarte, 2024; Gurrola et al., 2020). Estudos comparativos indicam que, para grandes volumes de dados, o MongoDB tende a superar SGBDs relacionais como o MySQL em operações de inserção e atualização, processando um número significativamente maior de operações por segundo (Duarte, 2024). Orientado Colunas Também conhecido como modelo de famílias de colunas, armazena os dados em colunas em vez de linhas. Os dados são organizados em famílias de colunas, que são contêineres para linhas (Marquesone, 2017). Diferente do modelo relacional, cada linha não precisa ter o mesmo número de colunas. Esse modelo é altamente otimizado para consultas que agregam valores sobre um grande número de registros, mas que necessitam apenas de um subconjunto das colunas (Gurrola et al., 2020). Cassandra: é um SGBD NoSQL distribuído, de código aberto, projetado para gerenciar grandes volumes de dados em múltiplos servidores, garantindo alta disponibilidade sem um ponto único de falha. Foi desenvolvido originalmente pelo Facebook, com inspiração nos sistemas Dynamo da Amazon e BigTable da Google (Duarte, 2024; Marquesone, 2017). Sua arquitetura distribuída permite escalabilidade linear, onde a capacidade do sistema aumenta simplesmente adicionando novos nós ao cluster (Duarte, 2024). Chave-Valor Este é o modelo mais simples de banco de dados NoSQL. Cada item de dado é armazenado como um par consistindo de uma chave e seu valor correspondente (Marquesone, 2017). valor é tratado como um "objeto opaco" (blob), e o acesso aos dados é feito exclusivamente por meio da chave primária, o que torna as operações de leitura e escrita extremamente rápidas e eficientes. Redis: é um SGBD de código aberto que armazena dados em memória (in-memory), que lhe confere um desempenho excepcional. Além de ser usado como um banco de dados chave-valor, é frequentemente empregado como cache de alta velocidade e como intermediário de mensagens (message broker) (Duarte, 2024). Embora o armazenamento principal seja em memória, o Redis oferece mecanismos de persistência para salvar os dados em disco, minimizando risco de perda de informação. Orientado a Grafos Este modelo foi projetado para armazenar e navegar em relacionamentos. Os dados são representados como uma estrutura de grafo, com nós (entidades), arestas (relacionamentos que conectam os nós) e propriedades (atributos dos nós e das arestas) (Duarte, 2024; Marquesone, 2017). É ideal para cenários onde as conexões e os relacionamentos entre os dados são foco principal, como em redes sociais, sistemas de recomendação e detecção de fraudes (Duarte, 2024). 7 - 40E-Book Printed Handout Data Lakes e Data Warehouses Adentraremos dois dos mais importantes paradigmas de armazenamento de dados em larga escala da Engenharia de Dados moderna: o Data Warehouse e o Data Lake. Compreender suas arquiteturas, propósitos e diferenças é fundamental para a construção de sistemas de dados robustos, escaláveis e que efetivamente gerem valor para as organizações. Data Warehouse (DW) conceito de Data Warehouse (DW), ou Armazém de Dados, consolidou-se como a espinha dorsal para a tomada de decisão estratégica nas organizações, servindo como a base para o que conhecemos como Business Intelligence (BI). Conceito e Propósito Um Data Warehouse é formalmente definido como uma coleção de dados orientada por assuntos, integrada, não volátil e variante no tempo, que suporta a tomada de decisão da administração (Silva, 2024; Takai, Italiano e Ferreira, 2005). Vamos desdobrar essa definição: Orientado por Assuntos: diferente dos sistemas operacionais (transacionais) que são organizados por processos (ex: vendas, estoque, RH), o DW é organizado por assuntos de negócio (ex: clientes, produtos, receitas). Isso facilita a análise e a geração de relatórios gerenciais (Campos, 2013). Integrado: os dados em um DW provêm de múltiplas fontes heterogêneas (sistemas legados, planilhas, bancos de dados distintos). Durante o processo de carga, esses dados são limpos, padronizados e integrados para garantir consistência (Takai, Italiano e Ferreira, 2005). Por exemplo, o atributo "sexo" pode vir como "M/F" de uma fonte e "1/0" de outra; no DW, ambos seriam padronizados para "Masculino/Feminino" (Campos, 2013). Variante no Tempo: o DW armazena dados históricos, permitindo análises de tendências e comparações ao longo do tempo. Cada registro em um DW está associado a um ponto específico no tempo (ex: vendas diárias, semanais, mensais) (Takai, Italiano e Ferreira, 2005). Não Volátil: uma vez que um dado é inserido em um DW, ele não é alterado ou removido. Os dados são apenas acrescidos, criando um registro histórico fidedigno das operações da empresa (Silva, 2024). propósito central de um DW é, portanto, servir como um repositório de dados históricos e consolidados, otimizado para consulta e análise, com o objetivo de apoiar a tomada de decisões estratégicas (Gurrola et al., 2020; Silva, 2024). 8 40E-Book Printed Handout A distinção entre sistemas OLTP (Online Transaction Processing) e OLAP (Online Analytical Processing) é crucial aqui. Sistemas operacionais são OLTP, otimizados para um grande volume de transações curtas (inserções, atualizações). Data Warehouses são sistemas OLAP, otimizados para um volume menor de consultas complexas que leem uma grande quantidade de dados. Arquitetura e Modelagem Dimensional A arquitetura de um DW é tipicamente composta por quatro camadas principais (Silva, 2024): 1. Fontes de Dados: sistemas operacionais (CRMs, ERPs, etc.) que geram os dados brutos. 2. ETL (Extract, Transform, Load): um processo fundamental que extrai os dados das fontes, transforma-os (limpeza, padronização, integração) em uma área intermediária (staging area) e, por fim, carrega-os no DW. 3. Data Warehouse: o repositório central onde os dados tratados são armazenados. 4. Aplicações de Business Intelligence (BI): ferramentas de consulta, relatórios e dashboards que consomem os dados do DW para gerar insights. coração da estrutura de um DW é a modelagem dimensional. Essa abordagem organiza os dados de forma intuitiva e otimizada para consultas analíticas, utilizando um Esquema Estrela (Star Schema) ou suas variações, como o Esquema Floco de Neve (Snowflake Schema) (Takai, Italiano e Ferreira, 2005; Silva, 2024). Os componentes da modelagem dimensional são: Tabela Fato: é a tabela central do esquema e armazena as métricas e medições numéricas de um processo de negócio (ex: quantidade vendida, valor da venda). Os fatos são, em sua maioria, aditivos (Takai, Italiano e Ferreira, 2005). Tabelas de Dimensão: são tabelas que se conectam à tabela fato e fornecem o contexto descritivo para as métricas. Elas respondem às perguntas "quem, o quê, onde, quando, por quê" (ex: dimensão Cliente, dimensão Produto, dimensão Tempo) (Silva, 2024). Data Lake 9 40E-Book Printed Handout Com a ascensão do Big Data, caracterizado pelos Vs" Volume, Velocidade e Variedade os sistemas tradicionais, incluindo os SGBDs relacionais que fundamentam os DWs, mostraram-se limitados, especialmente para lidar com a variedade de dados (Marquesone, 2017). Para superar esses desafios, surgiu o conceito de Data Lake (Lago de Dados). Conceito e Propósito U m Data Lake é um repositório centralizado de grande capacidade, projetado para armazenar dados em seu formato bruto e nativo, abrangendo todo tipo de informação, seja ela estruturada, semiestruturada ou não estruturada, em qualquer escala (Campos, 2013; Costa e Izumida, 2023). Diferente do DW, o Data Lake não impõe um esquema rígido no momento da gravação dos dados (Schema-on-Write). Em vez disso, a estrutura é aplicada no momento da leitura (Schema-on-Read). Isso confere uma enorme flexibilidade, permitindo a ingestão rápida de dados de diversas fontes, como logs de servidores, dados de mídias sociais, vídeos, imagens e dados de sensores de loT (Marquesone, 2017). propósito de um Data Lake é servir como um repositório único para todos os dados de uma organização, permitindo que diferentes profissionais, como cientistas de dados e analistas, explorem, experimentem e descubram insights a partir dos dados brutos (Campos, 2013). Vantagens de um Data Lake As principais vantagens de se adotar uma arquitetura de Data Lake são (Campos, 2013; Costa e Izumida, 2023): Disponibilidade dos Dados: Todos os dados estão disponíveis em um único local, a qualquer momento. Compatibilidade de Formatos: Suporta qualquer formato de dado (estruturado, semiestruturado e não estruturado). Dados Brutos: Permite a análise dos dados em seu estado original, sem perdas ou transformações prévias, possibilitando diferentes tipos de análise sobre mesmo dado. Data Warehouse vs. Data Lake: Diferenças e Sinergias 10 40E-Book Printed Handout Embora ambos sejam repositórios de dados, DWs e Data Lakes possuem propósitos e características fundamentalmente distintos. quando a seguir resume as principais diferenças. Quadro 2 Comparativo: Data Warehouse vs. Data Lake Característica Data Warehouse (DW) Data Lake Estruturados, Brutos, em seu formato nativo Dados processados e (estruturados, semi e não estruturados). modelados. Schema-on-Write Schema-on-Read (esquema definido na Esquema (esquema definido na leitura). escrita). Business Intelligence e Exploração de dados, Data Science e Propósito Principal relatórios estratégicos. Machine Learning. Analistas de Negócio, Cientistas de Dados, Engenheiros de Usuários Típicos gestores. Dados, analistas de dados. Baixa. A estrutura é rígida Alta. Novas fontes de dados podem ser Agilidade e mudanças são custosas. adicionadas facilmente. ELT (Extract, Load, Transform). Os dados ETL (Extract, Transform, Processamento são carregados primeiro e transformados Load). depois, conforme a necessidade. Fonte: Elaborado com base em Campos (2013), Costa e Izumida (2023), Marquesone (2017) e Silva (2024). Conceito-Chave: Complementaridade É crucial entender que Data Lakes e Data Warehouses não são concorrentes, mas sim complementares. Em arquiteturas de dados modernas, é comum que o Data Lake atue como a fonte primária de dados para o Data Warehouse. Os dados brutos são ingeridos e armazenados no Data Lake, e a partir dele, processos de ETL selecionam, transformam e carregam subconjuntos de dados estruturados para um ou mais Data Warehouses, que servirão a propósitos específicos de BI (Costa e Izumida, 2023; Campos, 2013). Essa abordagem combina a flexibilidade do Data Lake com a performance e confiabilidade do Data Warehouse. 11 40E-Book Printed Handout A evolução das plataformas de dados pode ser vista como uma progressão: a primeira geração focada em Data Warehoiuses, a segunda incorporando os Data Lakes para lidar com Big Data, e uma terceira geração emergente, o Data Lakehouse, que busca unificar as melhores características de ambos em uma única plataforma (Azevedo, 2024). Casos de Uso A escolha entre um Data Warehouse e um Data Lake (ou a combinação de ambos) depende dos objetivos de negócio e dos tipos de análise a serem realizadas. Casos de Uso para Data Warehouse Por ser otimizado para dados estruturados e consultas de BI, o DW é ideal para: Relatórios Corporativos: geração de relatórios padronizados sobre vendas, finanças, desempenho de marketing e KPIs (Indicadores-Chave de Desempenho). Análise de Desempenho de Negócios: acompanhamento de métricas de negócio ao longo do tempo para identificar tendências e anomalias. Dashboards Executivos: fornecer aos tomadores de decisão uma visão consolidada e de alto nível da saúde da organização. Casos de Uso para Data Lake A capacidade de armazenar dados diversos em seu formato bruto torna o Data Lake a escolha ideal para: Análise Preditiva e Machine Learning: treinamento de modelos de aprendizado de máquina utilizando grandes volumes de dados heterogêneos. Análise de Dados de e Streaming: ingestão e processamento em tempo real de dados provenientes de sensores e dispositivos conectados. Análise de Sentimento e Mídias Sociais: armazenamento e análise de dados textuais não estruturados para entender a percepção do público sobre uma marca ou produto. Exploração de Dados: permitir que cientistas de dados "naveguem" nos dados brutos em busca de padrões e insights ainda não descobertos, sem as restrições de um esquema pré-definido. A escolha e a arquitetura de seu sistema de armazenamento de dados devem ser guiadas pelas perguntas que sua organização deseja responder e pelo valor que se espera extrair dos dados. 12 40E-Book Printed Handout Ecossistema de processamento distribuído Adentraremos universo do processamento distribuído, um pilar fundamental da Engenharia de Dados moderna. A era do Big Data, caracterizada por um volume, variedade e velocidade de dados sem precedentes, tornou os sistemas tradicionais de processamento em um único servidor insuficientes (Marquesone, 2017; Costa; Izumida, 2023). A solução para este desafio reside na escalabilidade, especificamente na escalabilidade horizontal, que consiste em distribuir a carga de processamento e armazenamento por um cluster de máquinas, em oposição à escalabilidade vertical, que se baseia em aumentar a capacidade de um único servidor (Marquesone, 2017). Dois ecossistemas se destacam como paradigmas para lidar com os desafios do Big Data: Apache Hadoop, o framework pioneiro que estabeleceu as bases do processamento em lote em larga escala, e Apache Spark, seu sucessor espiritual, que revolucionou o campo com o processamento em memória, oferecendo maior velocidade e flexibilidade. Paradigma Fundacional Apache Hadoop foi concebido para permitir o processamento distribuído de grandes conjuntos de dados em clusters de computadores. Sua arquitetura é modular e se baseia em dois componentes principais: um para armazenamento e outro para processamento (Marquesone, 2017). Distribuído com HDFS Hadoop Distributed File System (HDFS) é o componente de armazenamento do Hadoop. Trata-se de um sistema de arquivos projetado para armazenar volumes massivos de dados, dividindo-os em blocos e distribuindo-os por múltiplos nós em um cluster. Sua principal função é garantir a confiabilidade e a alta disponibilidade dos dados, replicando cada bloco de dados em diferentes máquinas, o que assegura a tolerância a falhas (Gurrola et al., 2020). HDFS é otimizado para grandes arquivos e para cargas de trabalho de leitura sequencial, características comuns em análises de Big Data. Processamento em Lote com MapReduce 13 40E-Book Printed Handout MapReduce é o modelo de programação original do Hadoop para o processamento de dados em lote (batch processing). Ele simplifica a computação paralela ao abstrair as complexidades do trabalho em um ambiente distribuído (Gurrola et al., 2020; Marquesone, 2017). modelo divide o processamento em duas fases principais: 1. Fase Map (Mapeamento): o conjunto de dados de entrada é dividido em porções menores, e uma função map é aplicada a cada porção em paralelo nos diferentes nós do cluster. Essa função é responsável por filtrar, transformar e processar os dados, gerando pares de chave-valor intermediários. 2. Fase Reduce (Redução): os resultados intermediários da fase map são agrupados por chave e processados por uma função reduce. Esta função agrega, resume ou sintetiza os dados, produzindo o resultado. MapReduce foi revolucionário por sua capacidade de processar petabytes de dados de forma escalável e tolerante a falhas. No entanto, seu modelo é inerentemente baseado em operações de leitura e escrita em disco entre as fases, o que gera alta latência. Essa característica o torna eficiente para tarefas de ETL (Extração, Transformação e Carga) em lote, mas inadequado para análises interativas, algoritmos iterativos (como os de machine learning) e processamento em tempo real (Marquesone, 2017). A Evolução para o Processamento em Memória Para superar as limitações de latência do MapReduce, surgiu o Apache Spark, um motor de processamento distribuído de propósito geral. Sua principal inovação é a capacidade de realizar o processamento em memória (in-memory computing), o que torna significativamente mais rápido que o Hadoop MapReduce para uma vasta gama de aplicações (Silva, 2024; Gurrola et al., 2020). Arquitetura e Conceitos Fundamentais A arquitetura do Spark é baseada em um modelo mestre-escravo. Uma aplicação Spark é coordenada por um programa driver, que se comunica com um gerenciador de cluster para alocar recursos. trabalho é executado em processos chamados executors, que rodam nos nós de trabalho do cluster (Silva, 2024). 14 40E-Book Printed Handout coração do Spark é sua abstração de dados fundamental, o Resilient Distributed Dataset (RDD). Um RDD é uma coleção de elementos particionada, imutável e tolerante a falhas, que pode ser operada em paralelo. A capacidade de manter RDDs em memória entre as operações é o que confere ao Spark sua alta performance, eliminando a necessidade de escrita em disco em etapas intermediárias (Silva, 2024). Para otimizar a execução das tarefas, o Spark utiliza um agendador que constrói um Grafo Acíclico Dirigido (DAG) das operações, permitindo um planejamento eficiente e a minimização do tráfego de dados na rede. Ecossistema Unificado do Spark Diferentemente do Hadoop, que se concentrava no processamento em lote, o Spark foi projetado como uma plataforma unificada para diversas cargas de trabalho de dados. Ele oferece um conjunto de bibliotecas e APIs de alto nível que expandem suas capacidades. A interface mais comum para interagir com esse ecossistema é a PySpark, a API do Spark para a linguagem Python (Garcia, 2024). Os principais componentes do ecossistema Spark são: Spark Core: fornece a funcionalidade básica de processamento distribuído, gerenciamento de memória, agendamento de tarefas e as APIs de RDD (Garcia, 2024). Spark SQL: permite a consulta de dados estruturados e semiestruturados via SQL ou através da API de DataFrames, uma abstração de dados mais otimizada e fácil de usar que os RDDs para dados tabulares (Garcia, 2024). Spark Streaming: habilita o processamento escalável e tolerante a falhas de fluxos de dados em tempo real (streaming), permitindo análises contínuas à medida que os dados chegam (Garcia, 2024). Mllib (machine learning library): é a biblioteca de aprendizado de máquina do spark, contendo algoritmos e utilitários comuns para classificação, regressão, clusterização, entre outros, otimizados para execução em um ambiente distribuído (Garcia, 2024). Destaque Didático: Formato Apache Parquet Apache Spark integra-se perfeitamente com formatos de armazenamento colunar, como Apache Parquet. Diferente do armazenamento tradicional orientado a linhas, armazenamento colunar organiza os dados por colunas, que oferece alta performance para consultas analíticas, pois permite que motor de processamento leia apenas as colunas necessárias para uma determinada consulta, otimizando as operações de (leitura/escrita). Além disso, formato Parquet oferece esquemas eficientes de compressão e codificação, reduzindo espaço de armazenamento necessário (Silva, 2024). 15 40E-Book Printed Handout Hadoop vs. Spark Embora o Spark seja frequentemente visto como um substituto do Hadoop MapReduce, é mais preciso vê-los como tecnologias complementares. Spark não possui um sistema de arquivos próprio, sendo comum executá-lo sobre um cluster Hadoop, utilizando o HDFS para armazenamento persistente dos dados. A principal diferença reside no paradigma de processamento. quadro a seguir resume as principais diferenças entre os dois ecossistemas. Quadro 3 Diferenças entre MapReduce e Spark Apache Hadoop Característica Apache Spark (MapReduce) Estritamente em lote Unificado: lote, interativo, Modelo de Processamento (batch). streaming e iterativo. Baseado em disco, com alta Primariamente em memória, com Performance latência. performance até 100x superior. API de baixo nível, exigindo APIs de alto nível (DataFrames, Facilidade de Uso codificação manual para as SQL) que abstraem a fases map e reduce. complexidade. Focado em armazenamento Plataforma unificada com Ecossistema (HDFS) e processamento em bibliotecas para SQL, streaming, lote (MapReduce). machine learning e grafos. Através da abstração de RDDs, que Replicando dados no HDFS e podem ser reconstruídos a partir Tolerância a Falhas reexecutando tarefas. de sua linhagem. ETL de grandes volumes de Análises interativas, machine Casos de Uso dados não sensíveis ao learning, processamento de tempo, arquivamento. streams, ETL rápido. Fonte: (Elaborado com base em Garcia, 2024; Silva, 2024; Marquesone, 2017) 16 40E-Book Printed Handout Enquanto Hadoop MapReduce estabeleceu os fundamentos para o processamento de Big Data em lote, o Apache Spark representa a evolução desse paradigma, oferecendo uma plataforma unificada, mais rápida e versátil, que se tornou o padrão de fato para a maioria das aplicações de Engenharia e Ciência de Dados em larga escala. Processamento em lote (batch) vs. processamento em tempo real (streaming) No campo da Engenharia de Dados, a forma como os dados são processados é um pilar fundamental na arquitetura de qualquer sistema de informação. Com o advento do Big Data, caracterizado pelos "3Vs" Volume, Velocidade e Variedade (Costa; Izumida, 2023), duas abordagens principais de processamento se consolidaram: processamento em lote (batch processing) e o processamento em tempo real (streaming processing). A escolha entre essas duas modalidades não é meramente técnica, mas estratégica, e depende intrinsecamente dos requisitos de negócio, especialmente no que tange à latência, ou seja, o tempo de resposta esperado para a análise dos dados. Ambas as abordagens são consideradas habilidades essenciais para o engenheiro de dados moderno (Azevedo, 2024). Processamento em Lote (Batch Processing) processamento em lote é o paradigma tradicional para lidar com grandes volumes de dados. Sua premissa fundamental é processar um grande conjunto de dados que foi acumulado ao longo do tempo. Nesse modelo, os dados são coletados, armazenados e, posteriormente, processados em "lotes" ou "jobs" (Campos, 2013). Os processos de batch são tipicamente executados em intervalos de tempo determinados, como diariamente ou semanalmente, para refletir as mudanças ocorridas nas bases de dados operacionais (Silva, 2024). A aplicação clássica do processamento em lote é o processo de Extração, Transformação e Carga (ETL Extract, Transform, and Load), que constitui a espinha dorsal da construção de um Data Warehouse (DW). processo de ETL consiste em extrair dados de múltiplas fontes heterogêneas, transformá-los para garantir consistência, qualidade e conformidade com o modelo de dados de destino e, finalmente, carregá-los no repositório central, como um DW (Campos, 2013; Silva, 2024). Características do Processamento em Lote: Dados em Repouso: processa conjuntos de dados finitos e estáticos que já foram armazenados. Alto Volume e Alta Taxa de Transferência (Throughput): é otimizado para lidar com volumes massivos de dados, garantindo alta eficiência no processamento de 17 40E-Book Printed Handout ponta a ponta. Alta Latência: os resultados não são imediatos. A análise só está disponível após a conclusão do processamento de todo o lote, o que pode levar de minutos a horas. Execução Agendada: as tarefas são executadas em horários pré-definidos (por exemplo, durante a noite), quando a demanda sobre os sistemas transacionais é menor. Casos de Uso: ideal para tarefas que não exigem respostas imediatas, como a geração de relatórios gerenciais, consolidação de dados para Data Warehouses, faturamento, processamento de folhas de pagamento e o treinamento de modelos complexos de machine learning que requerem um grande conjunto de dados históricos (Campos, 2013; Silva, 2024). Tecnologias: ecossistema Apache Hadoop, com seu paradigma MapReduce, é a solução seminal para processamento em lote em larga escala (Costa; Izumida, 2023). Apache Spark também é um motor de processamento poderoso que opera de forma muito eficiente em modo batch (Silva, 2024). Processo ETL processo de ETL, um exemplo canônico de processamento em lote, é fundamental para a inteligência de negócios (Business Intelligence). Ele é responsável por coletar dados de fontes operacionais diversas (como sistemas de CRM e ERPs), realizar a "limpeza" e a "integração" desses dados para resolver inconsistências e, por fim, entregá-los de forma estruturada a um Data Waehouse para análise (Campos, 2013; Silva, 2024). Cerca de 70% dos recursos para implementação de um DW são consumidos por este processo (Campos, 2013). Processamento em Tempo Real (Streaming Processing) Com a crescente necessidade de respostas imediatas, impulsionada pela "velocidade" do Big Data, surgiu processamento em tempo real, também conhecido como streaming. Diferentemente do batch, o streaming processa os dados continuamente, à medida que são gerados, tratando-os como um fluxo infinito de eventos (Costa; Izumida, 2023). Essa abordagem permite a criação de aplicações interativas e análises que podem ser realizadas tanto sobre dados em tempo real quanto sobre dados históricos (Garcia, 2024). A necessidade de processar dados em tempo real é evidente em cenários onde a análise precisa ser feita no momento da aquisição dos dados, pois seria inviável esperar que todo o teste ou evento fosse concluído antes de iniciar a análise (Arone, 2019). A comunicação em tempo real, como a que ocorre em plataformas de mídias sociais, é um exemplo de fonte de dados que se beneficia enormemente desse tipo de processamento (Garcia, 2024; Martins, 2016). 18 40E-Book Printed Handout Características do Processamento em Tempo Real: Dados em Movimento: processa fluxos de dados contínuos e, teoricamente, infinitos. Baixo Volume por Transação: lida com pequenos pacotes de dados (eventos ou micro-lotes) de cada vez. Baixa Latência: a principal vantagem é a capacidade de fornecer resultados quase instantâneos, em milissegundos ou segundos. Execução Contínua: os sistemas de streaming estão sempre ativos, processando eventos à medida que chegam. Janelas de Processamento: frequentemente utiliza "janelas de tempo" (windows) para realizar agregações e análises sobre os dados que chegam em um determinado intervalo, além de possuir estratégias para lidar com eventos que chegam fora de ordem (Azevedo, 2024). Casos de Uso: ideal para aplicações que exigem ação imediata, como detecção de fraudes em transações financeiras (Marquesone, 2017), monitoramento de redes e sistemas, análise de dados de sensores de em smart grids (Costa; Izumida, 2023), análise de sentimento em mídias sociais (Garcia, 2024) e monitoramento de sinais biológicos (Arone, 2019). Tecnologias: o Apache Storm é uma solução projetada especificamente para processamento de streaming (Costa; Izumida, 2023). Apache Spark, por meio de seu módulo Spark Streaming, também é amplamente utilizado, assim como o Apache Kafka para a ingestão e o enfileiramento de fluxos de eventos (Azevedo, 2024). Quadro Comparativo: Batch vs. Streaming quadro abaixo sintetiza as principais diferenças entre os dois paradigmas de processamento. Quadro 4 diferenças entre os dois paradigmas de processamento. 19 40E-Book Printed Handout Processamento em Lote Processamento em Tempo Real Característica (Batch) (Streaming) Dados em repouso (Data at Dados em movimento (Data in Paradigma de Dados Rest) Motion) Conjuntos de dados grandes Escopo dos Dados Fluxos de dados contínuos e infinitos e finitos (lotes) Latência Alta (minutos a horas) Baixa (milissegundos a segundos) Alta, otimizada para grandes Taxa de Transferência Foco em baixa latência por evento volumes Modo de Execução Agendada e periódica Contínua e orientada a eventos Análises complexas sobre Análises sobre janelas de tempo e Análise todo o conjunto de dados eventos individuais Data Warehousing, Monitoramento, detecção de fraudes, relatórios complexos, Casos de Uso Típicos alertas em tempo real, análise de processamento de folha de redes sociais. pagamento. Hadoop MapReduce, Apache Apache Storm, Apache Spark Tecnologias Spark (Core) (Streaming), Apache Flink. Fonte: Elaborado com base em (Azevedo, 2024; Campos, 2013; Costa; Izumida, 2023; Garcia, 2024; Silva, 2024). Arquiteturas Híbridas e Papel do Apache Spark Na prática, muitas organizações necessitam de ambas as capacidades. Por exemplo, um sistema de recomendação de um e-commerce pode usar o processamento em lote para treinar um modelo de machine learning com todo o histórico de compras (uma tarefa que leva horas) e, ao mesmo tempo, usar o processamento em tempo real para gerar recomendações instantâneas baseadas na navegação atual do usuário. 20 40E-Book Printed Handout Essa necessidade levou ao desenvolvimento de arquiteturas de dados híbridas, como a Arquitetura Lambda e a Arquitetura que combinam camadas de processamento batch e streaming. Nesse contexto, ferramentas de processamento unificado como Apache Spark ganharam grande destaque. Spark é um motor que, desde sua concepção, foi projetado para executar tanto processamento em lote quanto em tempo real (através de micro-lotes), utilizando um conjunto unificado de APIs. Isso simplifica o desenvolvimento e a manutenção de sistemas de dados complexos, permitindo que uma única base de código seja utilizada para diferentes necessidades de processamento (Garcia, 2024; Silva, 2024). processamento em lote e o processamento em tempo real são paradigmas complementares, não concorrentes. A decisão de qual utilizar, ou como combiná-los, é uma das decisões de arquitetura mais importantes em um projeto de Big Data e deve ser guiada pelas necessidades do negócio em termos de tempo de resposta e profundidade da análise. Arquiteturas de dados No contexto do Big Data, as organizações enfrentam um desafio duplo: a necessidade de processar volumes massivos de dados históricos para análises complexas e, simultaneamente, analisar fluxos de dados contínuos em tempo real para obter insights imediatos. As características de Volume, Velocidade e Variedade, que definem o Big Data, exigem arquiteturas de dados robustas e flexíveis, capazes de lidar com esses dois paradigmas de processamento: lote (batch) e tempo real (streaming) (Marquesone, 2017). Para endereçar essa dualidade, surgiram padrões arquitetônicos que combinam diferentes tecnologias e abordagens. A seguir, exploraremos duas arquiteturas fundamentais para o processamento de dados em larga escala. A Arquitetura Híbrida de Processamento de Dados A primeira arquitetura que analisaremos é um modelo híbrido que visa fornecer uma solução abrangente para o processamento de Big Data, equilibrando latência, vazão (throughput) e tolerância a falhas. Essa abordagem decompõe o problema em três camadas distintas: a camada de lote (batch layer), a camada de velocidade (speed layer) e a camada de serviço (serving layer). 21 40E-Book Printed Handout Camada de Lote (Batch Layer) A camada de lote é responsável por gerenciar o conjunto de dados mestre e realizar o pré- processamento de todos os dados que chegam ao sistema. Sua função principal é gerar visões de dados completas e precisas, que serão posteriormente disponibilizadas para consulta. "O processo de ETL realiza a extração de dados das mais diversas fontes e tipos de valores, executando assim a primeira de sua importante tarefa. Em um segundo momento a transformação destas informações devidamente extraídas são tratadas sempre no intuito de reforçar a qualidade dos dados, reparar as mais diversas inconsistências" (Campos, 2013). Esta camada opera sobre a totalidade dos dados acumulados, que podem estar armazenados em um data lake ou em um data warehouse (Costa e Izumida, 2023; Silva, 2024). processamento é realizado em lotes, o que significa que os cálculos são executados em intervalos de tempo definidos (horas ou dias), resultando em alta latência. Ferramentas como Apache Hadoop são tradicionalmente associadas a este tipo de processamento (Marquesone, 2017). resultado do processamento na camada de lote são as "visões de lote" (batch views), que representam uma visão precisa e abrangente dos dados até o momento do último processamento. A principal vantagem desta camada é a sua capacidade de lidar com volumes de dados na escala de petabytes e realizar cálculos complexos, garantindo a exatidão dos resultados. A desvantagem é a alta latência, pois os dados mais recentes não são refletidos nas visões até que o próximo ciclo de processamento em lote seja concluído. Camada de Velocidade (Speed Layer) Para compensar a alta latência da camada de lote, a camada de velocidade processa os dados em tempo real. Ela recebe os mesmos dados que a camada de lote, mas os processa imediatamente à medida que chegam. objetivo desta camada não é oferecer uma visão completa e exata como a camada de lote, mas sim fornecer "visões em tempo real" (real-time views) que contêm apenas os dados mais recentes. Essas visões são, por natureza, incrementais e, por vezes, aproximadas, mas oferecem a vantagem crucial da baixa latência (Marquesone, 2017). Tecnologias como o Apache Storm são exemplos de ferramentas projetadas para processamento de fluxos contínuos de dados (streaming) (Marquesone, 2017). A camada de velocidade garante que as consultas dos usuários possam incorporar os dados mais recentes, mesmo que estes ainda não tenham sido processados pela camada de lote. 22 40E-Book Printed Handout Camada de Serviço (Serving Layer) A camada de serviço é responsável por indexar e expor os resultados das outras duas camadas para que possam ser consultados de forma eficiente. Ela armazena as visões de lote e as atualiza quando novas versões são geradas pela camada de lote. Ao mesmo tempo, incorpora as atualizações da camada de velocidade para responder a consultas sobre dados recentes. Quando uma consulta é recebida, a camada de serviço a direciona tanto para as visões de lote quanto para as visões em tempo real. Em seguida, ela mescla os resultados de ambas as fontes para fornecer uma resposta completa e atualizada ao usuário. Bancos de dados NoSQL, como o MongoDB, são frequentemente utilizados nesta camada devido à sua flexibilidade e alto desempenho em operações de leitura (Duarte, 2024). quadro a seguir resume as principais características das camadas de lote e de velocidade. Quadro 5 principais características das camadas de lote e de velocidade. Camada de Lote (Batch Camada de Velocidade (Speed Característica Layer) Layer) Todo o conjunto de Escopo dos Dados Apenas dados recentes (em fluxo) dados mestre Latência Alta (horas a dias) Baixa (segundos a minutos) Alta (cálculos exatos e Menor (pode usar algoritmos Precisão completos) aproximados) Hadoop, Processamento Storm, Processamento de Fluxo Tecnologias em Lote. Contínuo. Visões de lote Visões em tempo real Resultado (completas e precisas) (incrementais) Fonte: (Elaborado com base em Marquesone, 2017) Esta arquitetura híbrida, portanto, oferece uma solução robusta que combina a precisão das análises em lote com a agilidade do processamento em tempo real, sendo uma abordagem poderosa para sistemas de Big Data. 23 40E-Book Printed Handout A Arquitetura Simplificada Baseada em Streaming A complexidade de manter duas bases de código distintas para o processamento em lote e em tempo real, como na arquitetura híbrida, levou ao desenvolvimento de abordagens mais simplificadas. Com a evolução das ferramentas de processamento de dados, tornou-se viável utilizar uma única tecnologia para lidar com ambos os cenários. Esta arquitetura simplificada elimina a camada de lote e a camada de velocidade, substituindo-as por uma única camada de processamento baseada em streaming. A ideia central é tratar tudo como um fluxo de dados. Os dados históricos, que na arquitetura anterior seriam processados em lote, são simplesmente "reproduzidos" através do mesmo motor de streaming que processa os dados em tempo real (Azevedo, 2024). Ferramentas modernas de processamento distribuído, como o Apache Spark, são fundamentais para viabilizar esta arquitetura. Spark é capaz de processar dados tanto em grandes lotes quanto em micro-lotes (micro-batches), permitindo que uma única ferramenta e uma única lógica de aplicação sirvam tanto para o reprocessamento de dados históricos quanto para a análise de dados em tempo real (Silva, 2024; Costa e Izumida, 2023). fluxo de funcionamento é o seguinte: 1. Ingestão de Dados: todos os dados, novos e históricos, entram no sistema através de um sistema de mensageria, como o Apache Kafka. 2. Processamento Unificado: um único motor de processamento de streaming (ex: Spark Streaming) consome os dados. Ele processa os dados à medida que chegam e atualiza as visões na camada de serviço. 3. Reprocessamento: quando é necessário reprocessar todo o histórico (por exemplo, devido a uma mudança na lógica de negócio), os dados históricos são lidos de sua fonte de (como um data lake) e enviados novamente para o tópico de ingestão, sendo processados pelo mesmo pipeline. A principal vantagem desta abordagem é a simplicidade. Ao eliminar a necessidade de gerenciar e sincronizar duas lógicas de processamento distintas, reduz-se a complexidade do sistema, os custos de desenvolvimento e a probabilidade de erros. A desvantagem é que ela depende de ferramentas de streaming que sejam maduras o suficiente para lidar com a vazão e a escala de todo o conjunto de dados. 24 40E-Book Printed Handout Os padrões arquitetônicos que acabamos de discutir são amplamente conhecidos na indústria e na literatura especializada como Arquitetura Lambda (o modelo híbrido com três camadas) e Arquitetura (o modelo simplificado baseado em streaming). Embora os conceitos fundamentais que compõem essas arquiteturas como processamento em lote (batch), processamento em tempo real (streaming), data lakes e Data Warehouses sejam abordados nas fontes de referência deste capítulo (e.g., Marquesone, 2017; Costa e Izumida, 2023; Silva, 2024), os termos específicos 'Lambda' e 'Kappa' não são mencionados. Portanto, a descrição apresentada aqui é uma síntese didática desses conceitos fundamentais para construir a compreensão de como tais arquiteturas funcionam, com base estrita no material de pesquisa fornecido. A escolha entre uma arquitetura e outra depende dos requisitos específicos de cada projeto, como latência, custo, complexidade e a maturidade das tecnologias disponíveis. Técnicas de otimização Sistemas de bancos de dados tradicionais, muitas vezes, mostram-se ineficientes para lidar com essa escala (Gurrola et al., 2020). Consequentemente, a Engenharia de Dados moderna lança mão de um arsenal de técnicas de otimização para garantir que as consultas analíticas e os processos de transformação de dados sejam executados de forma performática e com custo computacional viável. Aqui exploraremos três pilares fundamentais da otimização de dados em ambientes distribuídos: o particionamento de dados, a compressão e uso de formatos de arquivo colunares, com especial atenção ao Apache Parquet. A compreensão e aplicação dessas técnicas são indispensáveis para a construção de plataformas de dados robustas e escaláveis. Particionamento de Dados particionamento é a técnica de dividir logicamente grandes conjuntos de dados, como tabelas ou coleções, em partes menores e mais gerenciáveis, chamadas de partições (Gurrola et al., 2020). Em um sistema distribuído, essas partições podem ser armazenadas e processadas em diferentes nós (servidores) de um cluster, permitindo a paralelização de operações e melhorando drasticamente a escalabilidade e o desempenho das consultas (Duarte, 2024). A estratégia de particionamento é um conceito fundamental tanto em bancos de dados relacionais quanto NoSQL: Em Bancos de Dados Relacionais: sistemas como Microsoft SQL Server utilizam o particionamento para dividir tabelas e índices de grande volume, melhorando o 25 40E-Book Printed Handout desempenho de consultas e a manutenibilidade (Gurrola et al., 2020). Em Bancos de Dados NoSQL: este paradigma explora intensivamente o particionamento para alcançar escalabilidade horizontal. MongoDB: utiliza uma técnica chamada auto-sharding, que distribui automaticamente os documentos (dados) por múltiplos servidores em um cluster, permitindo que o sistema cresça horizontalmente com a adição de novas máquinas (Gurrola et al., 2020; Duarte, 2024). Cassandra: é projetado com base no conceito de particionamento distribuído, onde os dados são divididos e replicados entre os nós do cluster, garantindo alta disponibilidade e ausência de um ponto único de falha (Duarte, 2024). domínio de diferentes técnicas de particionamento é um conhecimento essencial na formação de um Engenheiro de Dados moderno, sendo um tópico crucial em currículos atualizados da área (Azevedo, 2024). particionamento não é apenas uma técnica de otimização de desempenho; é a fundação que permite a escalabilidade horizontal. Ao dividir dados, permitimos que trabalho de processamento seja distribuído, transformando um problema massivo em múltiplos problemas menores que podem ser resolvidos em paralelo. Formatos de Arquivo Colunares e Compressão A maneira como os dados são organizados e armazenados fisicamente em disco tem um impacto profundo no desempenho das consultas analíticas. Tradicionalmente, os bancos de dados utilizam um armazenamento orientado a linhas, onde todos os valores de uma mesma tupla (registro) são armazenados de forma contígua. Em contraste, o armazenamento colunar organiza os dados por colunas, ou seja, todos os valores de uma mesma coluna são armazenados sequencialmente (Silva, 2024; Marquesone, 2017). Essa mudança de paradigma oferece duas vantagens cruciais para cargas de trabalho analíticas (Analytics): 1. Eficiência de Leitura (I/O): consultas analíticas, como agregações (SUM, AVG, COUNT), geralmente operam sobre um subconjunto de colunas de uma tabela. Em um formato colunar, o sistema de consulta lê apenas os dados das colunas necessárias, ignorando as demais. Isso reduz drasticamente a quantidade de dados lidos do disco (I/O), resultando em um ganho de performance significativo em comparação com o modelo de linhas, que precisaria carregar registros inteiros em memória (Duarte, 2024; Gurrola et al., 2020). 26 40E-Book Printed Handout 2. Alta Taxa de Compressão: os dados dentro de uma mesma coluna são homogêneos, ou seja, são do mesmo tipo e, frequentemente, possuem um conjunto de valores com baixa cardinalidade (poucos valores distintos). Essa homogeneidade torna os dados altamente compressíveis (Silva, 2024). Formatos de arquivo colunares empregam esquemas de codificação e compressão de alta performance que reduzem significativamente o espaço de armazenamento necessário, o que, por sua vez, também acelera as leituras, pois menos dados precisam ser transferidos do disco para a memória. A principal desvantagem dos formatos colunares reside no custo mais elevado para operações de atualização de registros, pois a modificação de uma única tupla pode exigir a reescrita de múltiplos arquivos de colunas (Silva, 2024). Por essa razão, são ideais para Data Warehouses e Data Lakes, onde as cargas de trabalho são predominantemente de leitura (read-heavy). Apache Parquet Apache Parquet é um formato de arquivo de código aberto, orientado a colunas, projetado para o armazenamento e recuperação eficiente de dados. Ele se estabeleceu como um padrão de fato no ecossistema de Big Data, especialmente em arquiteturas como Data Lakes e Lakehouses (Silva, 2024; Azevedo, 2024). Suas principais características incluem: Armazenamento Colunar: organiza os dados por colunas, otimizando para consultas analíticas. Compressão e Codificação Eficientes: oferece suporte a múltiplos esquemas de compressão (como Snappy, Gzip) e técnicas de codificação avançadas que reduzem o espaço em disco (Silva, 2024). Integração com Ecossistema: é amplamente suportado por motores de processamento distribuído, como o Apache Spark, sendo uma escolha preferencial para pipelines de dados de alto desempenho (Silva, 2024). A eficiência do Parquet é notável. Em um exemplo prático com dados do Sistema Único de Saúde (SUS), um volume de 1,7 bilhão de registros ocupa aproximadamente 24GB quando armazenado em formato Parquet, demonstrando sua capacidade de compactação e eficiência (Silva, 2024). Quadro 6 Comparativo: Armazenamento Orientado a Linhas vs. Colunas 27 40E-Book Printed Handout Armazenamento Armazenamento Orientado Característica Orientado a Linhas (Ex: Colunas (Ex: Parquet) CSV, Avro) Os valores de um registro Os valores de uma única coluna são Estrutura de Dados inteiro são armazenados armazenados juntos. juntos. Transacional (OLTP), onde Analítica (OLAP), onde se agregam Carga de Trabalho Ideal se lê e escreve registros valores de poucas colunas. inteiros. Baixa para consultas Alta, pois lê apenas as colunas Eficiência de Leitura analíticas, pois lê colunas requisitadas pela consulta. desnecessárias. Menos eficiente, pois Altamente eficiente devido à Compressão agrupa dados de tipos homogeneidade dos dados por diferentes. coluna. Geralmente mais rápidas Mais lentas para atualizações, pois Operações de Escrita para inserção de novos múltiplos arquivos podem ser registros. afetados. Fonte: (Núcleo Editorial). As técnicas de particionamento e o uso de formatos de arquivo colunares como o Parquet, que intrinsecamente favorece a compressão, são estratégias complementares e essenciais na Engenharia de Dados. particionamento distribui o dado horizontalmente para permitir o processamento paralelo, enquanto o armazenamento colunar otimiza a estrutura vertical do dado para acelerar as leituras e economizar espaço. Dominar esses conceitos é, portanto, um passo decisivo para projetar e construir sistemas de dados que sejam, ao mesmo tempo, escaláveis e performáticos. Soluções de e processamento em nuvem 28 40E-Book Printed Handout A transição para a computação em nuvem (cloud computing) representa uma das mais significativas mudanças de paradigma na engenharia de dados contemporânea. A capacidade de externalizar serviços de armazenamento e processamento, utilizando infraestruturas sob demanda, escaláveis e de alta disponibilidade, permitiu que organizações de todos os portes pudessem lidar com os desafios impostos pelo Big Data (Costa e Izumida, 2023; Marquesone, 2017). A nuvem não é apenas um repositório remoto, mas um ecossistema de tecnologias que viabilizam a coleta, o armazenamento, o processamento, a análise e a visualização de dados em uma escala sem precedentes. Neste contexto, diversas soluções comerciais, como Amazon S3, Google BigQuery, Snowflake e Amazon Redshift, tornaram-se padrões de mercado. Embora a literatura acadêmica frequentemente discuta os princípios e as tecnologias subjacentes como bancos de dados NoSQL, Data Warehouses e frameworks de processamento distribuído em vez de produtos específicos, a compreensão desses fundamentos é crucial para o engenheiro de dados. As soluções comerciais são, em essência, implementações gerenciadas e otimizadas dessas tecnologias fundamentais. Paradigma da Computação em Nuvem (Cloud Computing) A computação em nuvem é definida como o fornecimento de serviços de computação incluindo servidores, armazenamento, bancos de dados, redes e software pela internet (Costa e Izumida, 2023). Essa abordagem permite que as empresas evitem o alto custo de aquisição e manutenção de uma infraestrutura de hardware própria, optando por um modelo de aluguel sob demanda. Para a engenharia de dados, os principais benefícios são: Escalabilidade: a capacidade de aumentar ou diminuir os recursos computacionais (processamento e armazenamento) de forma dinâmica, conforme a necessidade do projeto, é uma característica fundamental para lidar com a natureza variável do Big Data (Marquesone, 2017). Disponibilidade e Redundância: provedores de nuvem oferecem alta disponibilidade e sistemas de redundância geográfica, garantindo a persistência e a integridade dos dados mesmo em caso de falhas de hardware (Costa e Izumida, 2023). Custo-Benefício: a externalização dos serviços transforma o investimento de capital (CAPEX) em despesa operacional (OPEX), permitindo que as organizações paguem apenas pelos recursos que utilizam, o que é especialmente vantajoso para lidar com picos de processamento (Costa e Izumida, 2023). 29 40E-Book Printed Handout Ecossistema Integrado: as plataformas de nuvem oferecem um vasto portfólio de serviços integrados, desde armazenamento de objetos e bancos de dados gerenciados até ferramentas de ETL, Machine Learning e Business Intelligence (BI), facilitando a construção de pipelines de dados de ponta a ponta (Costa e Izumida, 2023). Arquiteturas de Armazenamento de Dados em Nuvem As plataformas de nuvem oferecem uma vasta gama de soluções de armazenamento, projetadas para atender a diferentes requisitos de estrutura, desempenho e custo. A literatura destaca uma dicotomia fundamental entre os modelos de banco de dados Relacional (SQL) e Não Relacional (NoSQL), ambos amplamente disponíveis como serviços gerenciados na nuvem (Marquesone, 2017; Duarte, 2024). Bancos de Dados Relacionais (SQL) modelo relacional, que organiza os dados em tabelas estruturadas com esquemas rígidos e predefinidos, tem sido o padrão por décadas (Marquesone, 2017). Sua principal força reside na garantia de consistência e integridade dos dados através das propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Em um ambiente de nuvem, serviços como Amazon RDS ou Google Cloud SQL oferecem instâncias gerenciadas de SGBDs populares como MySQL e PostgreSQL (Duarte, 2024; Takai, Italiano e Ferreira, 2005). No entanto, modelo relacional enfrenta desafios em cenários de Big Data, principalmente relacionados à escalabilidade. A estratégia predominante é a escalabilidade vertical, que consiste em aumentar os recursos (CPU, memória) de um único servidor, uma abordagem que se torna cara e limitada em larga escala (Marquesone, 2017). Bancos de Dados Não Relacionais (NoSQL) movimento NoSQL (Not Only SQL) surgiu para endereçar as limitações dos SGBDs relacionais em aplicações web de grande escala. As soluções NoSQL são caracterizadas pela flexibilidade de esquema, alta disponibilidade e, crucialmente, pela escalabilidade horizontal a capacidade de distribuir a carga de dados e processamento por um cluster de múltiplos servidores (Gurrola et al., 2020; Marquesone, 2017). 30 40E-Book Printed Handout Esses sistemas geralmente sacrificam parte da consistência estrita do modelo ACID em favor do modelo BASE (Basicamente Disponível, Estado Leve, Eventualmente Consistente), que prioriza a disponibilidade do sistema mesmo em caso de falhas parciais (Duarte, 2024). A variedade de dados (Variety), uma das características do Big Data, é bem acomodada pelos diversos modelos NoSQL (Marquesone, 2017). A literatura descreve quatro modelos principais de bancos de dados NoSQL, cada um otimizado para um tipo específico de carga de trabalho: Quadro 7 Tipos de Bancos NoSQL: Características, Exemplos e Casos de Uso 31 40E-Book Printed Handout Exemplos na Modelo Descrição Casos de Uso Literatura Armazena dados como um dicionário, onde cada item Caching de objetos, possui uma chave única e armazenamento de Redis, Riak, Chave-Valor um valor. É modelo mais sessões de usuário, DynamoDB. simples e oferece altíssimo carrinhos de compra em desempenho para leituras e e-commerce. escritas diretas. Armazena dados em documentos flexíveis, como Catálogos de produtos, JSON ou BSON. Cada perfis de usuário, documento é autossuficiente MongoDB, Documentos sistemas de e pode ter uma estrutura CouchDB. gerenciamento de variável, permitindo conteúdo. consultas ricas sobre o conteúdo. Organiza os dados em famílias de colunas em vez de linhas. É altamente escalável para escrita e Dados de sensores, leitura de grandes volumes registros de log, análise de dados, sendo ideal para Cassandra, de eventos em tempo Colunas Largas séries temporais e dados de HBase. real. loT. Modela os dados como nós (entidades) e arestas Redes sociais, sistemas (relacionamentos), Grafos Neo4j. de recomendação, otimizado para atravessar e detecção de fraudes. consultar relações complexas entre os dados. Fonte: (Elaborado com base em Marquesone, 2017; Gurrola et al., 2020; Duarte, 2024) 32 40E-Book Printed Handout Comparativo de Desempenho Estudos comparativos, como de (Duarte, 2024), demonstram que, à medida que volume de dados aumenta, bancos de dados NoSQL como MongoDB tendem a superar SGBDs relacionais como MySQL em operações de inserção e atualização, processando um volume significativamente maior de operações por segundo em menos tempo. No entanto, para certas operações de consulta, desempenho pode ser similar ou até favorecer modelo relacional, dependendo da carga de trabalho. Isso reforça a ideia de que a escolha da tecnologia de armazenamento deve ser guiada pelos requisitos específicos da aplicação. Soluções como o Amazon S3 (Simple Storage Service) se encaixam em uma categoria distinta, o armazenamento de objetos. Ele não é um banco de dados, mas um repositório altamente escalável e e de baixo custo para dados não estruturados (imagens, vídeos) e semiestruturados (JSON, Parquet). Em arquiteturas de Big Data, S3 frequentemente funciona como a base de um Data Lake, um repositório centralizado para dados brutos que alimentarão sistemas de processamento e análise (Costa e Izumida, 2023). Soluções de Processamento e Análise de Dados em Nuvem Para extrair valor do imenso volume de dados armazenados na nuvem, são necessárias plataformas de processamento e análise que operem de forma distribuída e paralela. Soluções como Amazon Redshift, Google BigQuery e Snowflake são implementações de Data Warehouses (DW) modernos, projetados para o ambiente de nuvem e otimizados para consultas analíticas complexas sobre petabytes de dados. conceito de Data Warehouse, definido como um repositório de dados orientados a assunto, integrados, históricos e não voláteis, é fundamental para o Business Intelligence (BI) e suporte à tomada de decisão (Campos, 2013; Takai, Italiano e Ferreira, 2005). A construção de um DW envolve um processo de ETL (Extração, Transformação e Carga), no qual dados de diversas fontes operacionais são limpos, integrados e carregados no repositório analítico (Silva, 2024; Campos, 2013). As plataformas de DW em nuvem se baseiam em duas tecnologias-chave discutidas na literatura: 1. Processamento Massivo Paralelo (MPP): a arquitetura MPP, ou "sem 33 40E-Book Printed Handout compartilhamento" (shared-nothing), distribui tanto os dados quanto a carga de processamento entre múltiplos nós em um cluster. Cada nó opera de forma independente com sua própria memória e disco, permitindo que sistema escale horizontalmente com a adição de mais nós (Costa e Izumida, 2023). Frameworks como Apache Spark são motores de processamento multilinguagem que implementam esse paradigma, sendo amplamente utilizados para engenharia de dados, ciência de dados e machine learning em clusters (Silva, 2024; Garcia, 2024). 2. Armazenamento Colunar: para otimizar o desempenho de consultas analíticas, que geralmente leem colunas inteiras em vez de linhas individuais, os DWs modernos utilizam formatos de armazenamento colunar. Formatos como o Apache Parquet oferecem compressão eficiente e recuperação otimizada de dados, acelerando significativamente as consultas (Silva, 2024). Snowflake, BigQuery e Redshift são exemplos de serviços que abstraem a complexidade de gerenciar essa infraestrutura. Eles separam a computação do armazenamento, permitindo que ambos e escalem de forma independente. Utilizam SQL como interface de consulta padrão e são capazes de consultar diretamente dados armazenados em Data Lakes (como no S3), unificando os mundos do Data Warehouse e do Big Data. Essa arquitetura moderna é frequentemente denominada Data Lakehouse (Azevedo, 2024). As soluções de armazenamento e processamento em nuvem representam a materialização dos princípios de sistemas distribuídos, bancos de dados e processamento de Big Data em serviços gerenciados, acessíveis e escaláveis. Para o engenheiro de dados, dominar os conceitos de modelos de dados (SQL e NoSQL), arquiteturas de processamento (MPP) e o ecossistema de ferramentas (Spark, Parquet) é mais fundamental do que conhecer um produto específico, pois são esses os pilares sobre os quais as tecnologias de nuvem são construídas e continuam a evoluir. Saiba Mais: Análise de dados de estresse com uso de EEG utilizando aprendizagem de máquina ? KNOW MORE Análise de dados de estresse com o uso de EEG utilizando aprendizagem de máquina 34 40E-Book Printed Handout Considerações Finais Chegamos ao final da nossa terceira unidade, e neste ponto, compreendemos como o armazenamento e processamento distribuído se tornaram elementos essenciais da Engenharia de Dados moderna. A partir da análise dos bancos relacionais e NoSQL, até o estudo das arquiteturas de Data Lakes e Data Warehouses, ficou evidente que a escolha do modelo e da tecnologia de armazenamento define a eficiência, a escalabilidade e a confiabilidade de todo o ecossistema de dados. Vimos que o verdadeiro desafio da engenharia de dados não está apenas em guardar informações, mas em garantir que elas sejam acessíveis, consistentes e úteis para a análise e para a tomada de decisão. Ao explorar o ecossistema de processamento distribuído, com destaque para o Apache Hadoop e o Apache Spark, foi possível perceber a transição da era dos sistemas centralizados para a era da computação distribuída e em memória. Essa mudança não representa apenas uma evolução tecnológica, mas uma transformação conceitual na forma como as organizações lidam com o Big Data. Assim, esta unidade nos convida a compreender que domínio do armazenamento e do processamento distribuído vai além do conhecimento técnico: ele exige uma visão estratégica sobre o fluxo e o ciclo de vida dos dados, reforçando o papel do engenheiro de dados como mediador entre a tecnologia e o valor que dela se extrai. Lista de Termos Específicos Termo / Sigla Definição resumida Linguagem padrão usada para criar, consultar e SQL (Structured Query Language) manipular dados em bancos de dados relacionais. Categoria de bancos de dados não relacionais projetada NoSQL (Not Only SQL) para lidar com dados não estruturados e escalabilidade horizontal. Abordagem em que a estrutura dos dados é definida no momento da gravação. Schema-on-Read 35 40E-Book Printed Handout Abordagem em que a estrutura dos dados é aplicada apenas no momento da leitura. ACID (Atomicity, Consistency, Conjunto de propriedades que garantem a integridade Isolation, Durability) das transações em bancos de dados relacionais. Modelo usado em bancos NoSQL que prioriza BASE (Basically Available, Soft State, disponibilidade e escalabilidade em detrimento da Eventually Consistent) consistência imediata. Conjunto de máquinas interconectadas que trabalham Cluster de forma coordenada para processar ou armazenar dados. Sistema de arquivos distribuído do Hadoop que HDFS (Hadoop Distributed File armazena dados em blocos replicados entre diferentes System) nós para garantir tolerância a falhas. Modelo de programação do Hadoop que permite o MapReduce processamento paralelo de grandes volumes de dados em duas etapas: (mapeamento) e Reduce (redução). Framework open-source para armazenamento e Apache Hadoop processamento distribuído de grandes volumes de dados. Framework de processamento distribuído em memória, Apache Spark sucessor do Hadoop MapReduce, com suporte a batch, streaming e machine learning. Estrutura de dados fundamental do Spark, imutável e RDD (Resilient Distributed Dataset) distribuída, que permite processamento paralelo e tolerante a falhas. Estrutura de grafo usada pelo Spark para otimizar a DAG (Directed Acyclic Graph) execução das operações de processamento. Módulo do Spark que permite consultas em linguagem Spark SQL SQL sobre dados estruturados e semiestruturados Componente do Spark voltado ao processamento de Spark Streaming dados em tempo real. 36 40E-Book Printed Handout Mllib (Machine Learning Library) Biblioteca de aprendizado de máquina do Spark com algoritmos otimizados para execução distribuída. Interface do Spark para a linguagem Python, PySpark amplamente usada em Engenharia e Ciência de Dados. Formato de arquivo colunar otimizado para compressão Apache Parquet e leitura eficiente em sistemas analíticos distribuídos. Processamento de dados em lotes, em intervalos Batch Processing definidos, adequado a tarefas periódicas de grande volume. Processamento contínuo de dados em tempo real à Streaming Processing medida que são gerados. Processo de extração, transformação e carregamento de ETL (Extract, Transform, Load) dados usado em Data Warehouses. Variante moderna do ETL em que a transformação é feita ELT (Extract, Load, Transform) após o carregamento dos dados. OLTP (Online Transaction Processamento transacional em tempo real usado em Processing) sistemas operacionais e bancários. Processamento analítico usado em sistemas de apoio à OLAP (Online Analytical Processing) decisão e Business Intelligence. Repositório estruturado e histórico de dados usado em Data Warehouse (DW) análises e relatórios de negócios. Armazenamento centralizado de dados brutos, Data Lake estruturados e não estruturados, em seu formato original. Arquitetura híbrida que une a estrutura e governança do Data Lakehouse Data Warehouse à flexibilidade do Data Lake. Conjunto de processos e ferramentas que transformam Business Intelligence (BI) dados em informações úteis para decisões estratégicas. 37 40E-Book Printed Handout Arquitetura Lambda Modelo de arquitetura de dados com três camadas (batch, speed e serving), que combina processamento em lote e em tempo real. Modelo simplificado que utiliza apenas o processamento Arquitetura baseado em streaming para todos os tipos de dados. Parte da arquitetura Lambda responsável por processar Camada de Lote (Batch Layer) todos os dados históricos. Parte da arquitetura Lambda responsável por processar Camada de Velocidade (Speed Layer) dados recentes em tempo real. Parte da arquitetura Lambda que combina e Camada de Serviço (Serving Layer) disponibiliza os resultados das camadas de lote e velocidade para consulta. Técnica de particionamento de dados que distribui Sharding registros entre múltiplos servidores para escalabilidade. Partitioning (Particionamento de Divisão de grandes volumes de dados em partes Dados) menores para otimizar o processamento distribuído. Auto-Sharding (Particionamento Distribuição automática de dados entre nós de um Automático) cluster (exemplo: MongoDB). Duplicação de dados entre servidores para garantir Replication (Replicação de Dados) disponibilidade e tolerância a falhas. Quantidade de dados processados por unidade de Throughput (Taxa de Transferência) tempo em um sistema. Tempo entre envio de um dado e o recebimento de sua Latency (Latência) resposta. Técnica usada pelo Spark Streaming que processa Micro-Batch Processing pequenos lotes de dados em intervalos curtos, simulando tempo real. Organização de Data Lakes em camadas (Bronze, Silver, Arquitetura Medalhão (Medallion Gold) de acordo com nível de tratamento e qualidade Architecture) dos dados. 38 40E-Book Printed Handout Arquitetura de processamento em que múltiplos nós MPP (Massively Parallel Processing) trabalham de forma independente para acelerar consultas analíticas. Cloud Computing (Computação em Modelo de prestação de serviços de TI sob demanda via Nuvem) internet, com escalabilidade e custo sob uso. Data Governance (Governança de Conjunto de políticas e práticas que asseguram Dados) qualidade, segurança e conformidade no uso de dados. Rastreamento da origem, transformação e destino de Data Lineage (Linhagem de Dados) dados dentro de um sistema. Número de cópias de cada bloco de dados mantido em HDFS Replication Factor um cluster Hadoop para tolerância a falhas. Termos que distinguem dados armazenados (em Data at Rest / Data in Motion repouso) de dados em fluxo (em movimento). Rede de dispositivos conectados que coletam e (Internet of Things) transmitem dados em tempo real. Armazenamento temporário de dados em memória para Caching acelerar o acesso futuro. Sistema intermediário que gerencia a troca de Message Broker mensagens entre aplicações (exemplo: Redis, Kafka). Canais de comunicação em que os dados são Kafka Topics organizados e distribuídos dentro do Apache Kafka. Modelos de organização de dados em Data Warehouses, Snowflake Schema / Star Schema compostos por tabelas de fatos e dimensões. Comparação entre formatos de arquivo: Parquet Parquet vs. Avro (colunar, ideal para leitura) e Avro (orientado a linha, ideal para escrita). Unidades básicas de armazenamento de dados dentro HDFS Blocks do Hadoop Distributed File System. 39 40E-Book Printed Handout Referências AZEVEDO, Tarsis Figueredo. Ensino de Engenharia de Dados nas Universidades Brasileiras e Mercado: estado atual e propostas de modernização. 2024. 337 f. Dissertação de Mestrado Universidade Federal do Amazonas, Manaus, 2024. CAMPOS, Sandir Rodrigues. Validação de dados em sistemas de data warehouse através de índice de similaridade no processo de ETL e mapeamento de trilhas de auditoria utilizando indexação ontológica. 2013. 180 f. Dissertação de Mestrado Universidade de Brasília, Brasília, 2013. ARONE, Rafael Augusto Caracciolo. Análise de dados de estresse com uso de EEG utilizando aprendizagem de máquina. São Carlos: Universidade de São Paulo, Escola de Engenharia de São Carlos, 2019. COSTA, Gabriel; IZUMIDA, Marcos. Machine learning e big data no setor elétrico: guia de conteúdo para docentes. Brasil: Profissionais do Futuro: Competências para a Economia Verde; Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH, 2023. GARCIA, Amanda de Jesus. Classificação de Sentimento sobre Agentes do Valorant, Faculdade de Tecnologia De São Paulo São Paulo, 2024. GURROLA, Rubén Pizarro et al. Ciencia de los datos: propuestas y casos de uso. 1. ed. México: D.R. Universidad Pedagógica de Durango, 2020. 550 FINOCHIETTO, Jorge; MESA, José Gutiérrez de; RODRIGUEZ, Carmen; BENGOCHEA, Luiz. ATICA2019: Aplicación de Tecnologías de la Información Comunicaciones Avanzadas: Libro de Actas. In: Congreso Internacional sobre Aplicación de Tecnologías de la Información Comunicaciones Avanzadas, Alcalá de Henares, V. 30, n. 10, 2019. MARTINS, Yasmmin Côrtes. YLINK: um processo para interligação de dados na Web Semântica. 2016. 133 f. Dissertação de Mestrado Instituto Militar de Engenharia, Rio de Janeiro, 2016. PASIAN, Mara Silvia; MENDES, Enicéia Gonçalves; CIA, Fabiana. Aspectos da organização e funcionamento do atendimento educacional especializado: um estudo em larga escala. Educação em Revista, Belo Horizonte, n. 33, p. 1-18, 2017. MARQUESONE, Rosangela de Fátima Pereira. Big Data: Técnicas e tecnologias para extração de valor dos dados: Casa do Código, São Paulo, 2017. SILVA, Danilo Gouvea. Criação de um data warehouse para dados públicos de atendimentos ambulatoriais do SUS. São Carlos, 2024. p. 114. TAKAI, Osvaldo Kotaro; ITALIANO, Isabel Cristina; FERREIRA, João Eduardo. Introdução banco de dados. s.n.], 2005. DUARTE, Leonardo Ramalho. Desenvolvimento de ferramenta para migração bidirecional e avaliação comparativa de desempenho entre bancos de dados relacionais e NoSQL. 2024. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) Universidade Tecnológica Federal do Paraná, Medianeira, 2024. 40 40