ETL/ELT

O objetivo de realizar ETL (Extract, Transform, Load) ou ELT (Extract, Load,

Transform) é integrar e preparar dados provenientes de diversas fontes, garantindo que
estejam organizados, limpos e acessíveis para análises e tomada de decisão. Esses
processos permitem centralizar informações em um único repositório, como um Data
Warehouse ou Data Lake, melhorando a qualidade e consistência dos dados, além de
otimizar a performance de consultas e análises. Com isso, empresas podem consolidar
suas informações e apoiar estratégias baseadas em dados, criando pipelines escaláveis
que atendam às demandas crescentes de volume e diversidade de fontes.

ETL (Extract, Transform, Load)

1. Extração (Extract)
A extração é o primeiro passo do ETL e tem como objetivo coletar dados brutos de
diversas fontes. Essas fontes podem ser sistemas transacionais, bancos de dados, APIs,
arquivos, ou qualquer outro local onde os dados estejam armazenados.
Identificação das fontes:
• Você precisa saber de onde os dados virão, como: sistemas ERP (ex.: SAP), bancos
de dados transacionais (ex.: MySQL, PostgreSQL), arquivos CSV ou APIs.
2. Transformação (Transform)
Depois que os dados são extraídos, eles são preparados e transformados para
atender aos requisitos da análise ou do sistema de destino. Essa etapa é onde acontece a
maior parte do trabalho de "limpeza" e adaptação dos dados.
3. Carga (Load)
Após os dados estarem preparados, a última etapa é transferi-los para o sistema de
destino, como um Data Warehouse (Snowflake, BigQuery, Redshift) ou arquiteturas mais
modernas.

ELT (Extract, Load, Transform)

No processo ELT (Extract, Load, Transform), a ordem das etapas é alterada em
relação ao ETL. Aqui, os dados brutos são extraídos e carregados diretamente no sistema
de armazenamento de dados, onde a transformação acontece posteriormente. Essa
abordagem é ideal para ambientes modernos com grande capacidade de processamento,
especialmente em nuvem.
1. Extração (Extract)
Assim como no ETL, a extração no ELT envolve coletar dados brutos de várias
fontes, como bancos de dados, APIs, arquivos CSV, sistemas ERP, entre outros. O objetivo
é extrair rapidamente grandes volumes de dados para serem processados posteriormente
no destino. Não há limpeza nem transformação nesta etapa, garantindo que os dados sejam
transferidos na íntegra.
2. Carga (Load)
No ELT, os dados são carregados no sistema de destino logo após a extração, sem
nenhuma transformação prévia. O destino geralmente é um Data Lake ou um Data
Warehouse em nuvem, como Snowflake, Google BigQuery, ou Amazon Redshift.

3. Transformação (Transform)
Depois que os dados estão no destino, começa a transformação, que geralmente é feita
diretamente no sistema de armazenamento usando SQL ou ferramentas especializadas,
como dbt (Data Build Tool). Isso elimina a necessidade de transformar os dados antes de
carregá-los, permitindo que os sistemas modernos lidem com grandes volumes de dados.

Quando usar ETL ou ELT?

A escolha entre ETL (Extract, Transform, Load) e ELT (Extract, Load, Transform)
depende de vários fatores, incluindo o tipo de dados, o ambiente tecnológico, os requisitos
do projeto e as preferências da equipe.
O ETL é mais adequado em cenários onde os dados precisam ser transformados
antes de serem carregados no sistema de destino. Ele é uma escolha tradicional em
ambientes locais (on-premise) e para sistemas que não suportam grandes volumes de
dados brutos. Exemplos: Ambientes legados que utilizam Data Warehouses tradicionais,
como Teradata ou Oracle, onde o processamento de dados brutos pode ser caro e
demorado no destino. Quando há cenários com requisitos de qualidade imediata, onde
dados limpos e estruturados devem estar disponíveis imediatamente após o carregamento,
como em relatórios diários ou sistemas que não podem processar dados brutos, etc.
Já o ELT é ideal para ambientes modernos baseados em nuvem, onde a
escalabilidade e a capacidade de processamento distribuído são fundamentais. Ele é mais
flexível e eficiente para grandes volumes de dados e processos iterativos. O ELT é indicado
para lidar fluxos de dados em tempo real, em que mover os dados brutos para o destino é
mais eficiente antes de realizar as transformações necessárias. Além disso, ao reduzir a
complexidade inicial do processo e permitir o carregamento de dados brutos diretamente
no destino, o ELT ajuda a reduzir custos, tornando-o uma escolha eficiente para projetos
em que as transformações podem ser adiadas para o ambiente de destino, garantindo
maior agilidade e capacidade de adaptação às necessidades analíticas.
Fonte de dados
As fontes de dados são os sistemas, plataformas ou dispositivos que geram ou
armazenam informações que podem ser utilizadas para análise e tomada de decisões.
Essas fontes podem ser de diversos tipos e formatos, dependendo do contexto
organizacional e das necessidades do projeto. Alguns exemplos:
• Os bancos de dados são uma das fontes mais comuns de dados. Eles
podem ser relacionais ou não relacionais. Ex.: MySQL, PostgreSQL,
MongoDB.
 • Sistemas de CRM (Customer Relationship Management) é uma plataforma
usada para gerenciar interações com clientes e leads, oferecendo dados
sobre comportamento, vendas e suporte. Ex.: Salesforce, Pipedrive
• ERP (Enterprise Resource Planning) integram os processos de negócios
em uma única plataforma, oferecendo acesso aos dados de estoques,
finanças, logística, etc. Ex.: SAP, Oracle ERP.

APIs (Application Programming Interfaces)

API é a sigla para Application Programming Interface (Interface de Programação

de Aplicações). Trata-se de um conjunto de regras e protocolos que permite que diferentes
softwares se comuniquem entre si, compartilhando funcionalidades e dados. As APIs
funcionam como uma ponte entre sistemas, facilitando a integração e a troca de
informações. Sua utilização facilita a forma que sistemas compartilham dados entre si e
boa parte dos sites, aplicativos ou sistemas usam esse recurso.
Um tipo muito conhecido de API são as chamadas REST API (Representational
State API). Elas fornecem uma forma padronizada de fazer as principais operações entre
sistemas. São elas:
Tipos de requisição:
• GET: Utilizado quando o requisitante solicita dados do servidor.
• POST: Utilizado quando o requisitante envia/cria dados no servidor.
• PUT: Utilizado quando o requisitante atualiza dados no servidor.
• DELETE: Utilizado quando o requisitante remove dados do servidor.
Geralmente o dado recebido ou postado segue a estrutura de arquivos JSON.

Estrutura de uma chamada de API:

1. Header: Utilizado para passar informações gerais da requisição, como por exemplo
as credenciais de acesso (segurança).
2. Tipos de Requisição: Informa se vamos obter dados (GET), enviar dados (POST)
e assim por diante.
3. End Point: Tipo de dado que o requisitante busca.
4. Parameters/Body: São os parâmetros que cada End Point necessita para filtrar as
informações buscadas. Dependendo do End Point, nenhum parâmetro é necessário.
 Data Warehouse
Após a extração dos dados, o processo usual envolve a transferência desses dados
para um sistema de armazenamento e gerenciamento de dados. Neste sistema, ocorre
a integração de dados, um processo essencial para combinar informações de diferentes
fontes em um local único e centralizado. Essa integração permite combinar dados de
diferentes fontes em um local único e centralizado. O objetivo é fornecer um conjunto de
dados completo, preciso e atualizado para análise, inteligência de negócios e outras
aplicações.
Um dos sistemas de armazenamento e gerenciamento de dados mais amplamente
utilizados é o Data Warehouse (DW).
Um data warehouse é um hub central de dados usado para relatórios e análises. Os
dados em um data warehouse geralmente são altamente formatados e estruturados para
casos de uso analíticos. É uma das arquiteturas de dados mais antigas e bem estabelecidas.
O data warehouse reúne e organiza dados de várias fontes (sistemas transacionais, APIs,
etc.) em um formato otimizado para consultas analíticas.
A arquitetura organizacional de data warehouse tem uma característica principal:
• Separar o processamento analítico online (OLAP) dos bancos de dados
de produção (processamento de transações online - OLTP)
Essa separação é fundamental à medida que as empresas crescem. Mover os dados
para um sistema físico separado direciona a carga para longe dos sistemas de produção e
melhora o desempenho das análises.
Desta forma, a separação entre o OLAP (Online Analytical Processing) e o OLTP (Online
Transaction Processing) na arquitetura de um data warehouse é essencial porque eles
servem a propósitos diferentes dentro de uma organização.
• OLTP (Processamento de Transações Online): é responsável por lidar com as
transações diárias de uma empresa. Ele envolve o armazenamento e gerenciamento
dos dados gerados por atividades de produção, como registrar uma venda, atualizar
um inventário, ou gerenciar cadastros. Esse tipo de sistema é otimizado para
transações rápidas e frequentes, com inserções, atualizações e consultas simples,
como buscas de registros específicos. É o tipo de processamento que ocorre no banco
de dados. Sistemas OLTP são frequentemente chamados de bancos de dados
transacionais
• OLAP (Processamento Analítico Online): é responsável por executar consultas
mais complexas para análise de dados e relatórios estratégicos. Diferente do OLTP, o
OLAP é otimizado para consultas longas e complexas, que envolvem o
processamento de grandes volumes de dados, agregações, e cálculos analíticos,
como sumarizar vendas por região ao longo de vários anos.
Quando separamos os processamentos OLAP e OLTP, evitamos que o sistema de
produção, que lida com as operações diárias (OLTP), fique sobrecarregado com consultas
analíticas complexas (OLAP), o que poderia impactar negativamente a velocidade e a
estabilidade das transações diárias.
Ao mover os dados para um sistema físico separado (data warehouse), você cria um
ambiente dedicado à análise de dados. Isso melhora o desempenho das consultas analíticas
porque o sistema de data warehouse pode ser otimizado especificamente para esse tipo de
processamento sem afetar a performance do sistema de transações.
 Arquitetura de dados baseada no processo ETL:

- Os dados são extraídos de fontes, processados e transformados por um sistema ETL,

armazenados em um Data Warehouse centralizado e, depois, organizados em Data Marts
para atender a análises específicas de diferentes áreas de negócio.
Arquitetura de dados baseada no processo ELT:

- Com a arquitetura de data warehouse ELT, os dados são movidos mais ou menos
diretamente dos sistemas de produção para uma área de preparação no data Warehouse.
Em vez de usar um sistema externo, as transformações são feitas diretamente no data
warehouse. A intenção é aproveitar o poder computacional massivo dos data warehouses
na nuvem e das ferramentas de processamento de dados.
Os data warehouses na nuvem representam uma evolução significativa da arquitetura
de data warehouse local e, por isso, trouxeram mudanças consideráveis para a arquitetura
organizacional.
Data Mart
Um data mart é um subconjunto mais refinado de um data warehouse, projetado para
atender às análises e relatórios, focado em uma única suborganização, departamento ou
linha de negócios; cada departamento tem seu próprio data mart, específico para suas
necessidades. Isso contrasta com o data warehouse completo, que atende a toda a
organização ou negócio.
Um data mart tem uma etapa adicional de transformação além da que ocorre no data
warehouse. Isso acontece porque, no data mart, os dados são organizados e processados
de forma mais específica para atender às necessidades de um departamento ou área de
negócios. Os data marts existem por duas razões. Primeiro, um data mart torna os dados
mais facilmente acessíveis para analistas e desenvolvedores de relatórios. Segundo, os data
marts fornecem uma etapa adicional de transformação além daquela realizada pelos
pipelines iniciais de ETL ou ELT. Isso pode melhorar significativamente o desempenho se
relatórios ou consultas analíticas exigirem junções e agregações complexas de dados,
especialmente quando os dados brutos são volumosos. Os processos de transformação
podem preencher o data mart com dados já unidos e agregados, melhorando o desempenho
para consultas em tempo real.

O processo de ETL/ELT com DW

1 - Área de Staging
Em um Data Warehouse (DW), a área de staging (ou camada de staging) é uma área
temporária onde os dados são armazenados e preparados antes de serem transformados e
carregados nas camadas finais do DW, como a área de dados integrados ou a camada de
apresentação; A área de staging é uma etapa anterior ao back room em um Data Warehouse
(DW). É a primeira camada onde os dados são carregados diretamente das fontes de
dados.
Principais características da área de staging:
1. Armazenamento Temporário: Dados são carregados na área de staging apenas
temporariamente, geralmente vindos de várias fontes.
2. Transformações Iniciais: Aqui podem ocorrer algumas transformações básicas, como
limpeza de dados, remoção de duplicatas e padronização de formatos.
3. Segurança e Qualidade: Permite uma camada extra de segurança para validar e tratar
os dados antes que eles cheguem à área de análise.
4. Isolamento: A área de staging geralmente não está disponível para usuários finais; é
destinada apenas para o processo de ETL/ELT.
Por que a gente precisa usar a staging area?
• Alivia os sistemas de origem ao realizar limpezas básicas durante a conexão
ativa com as fontes de dados, e, após a liberação do data source, permite
transformações complexas, maximizando os recursos computacionais
disponíveis.
• Os sistemas de origem têm janelas específicas para extração, e suas
frequências de atualização nem sempre coincidem com o carregamento no
Data Warehouse.

Não é necessário criar relacionamentos (joins) na etapa de stage. Por exemplo, ao

integrar dois sistemas de origem com cadastros de clientes, as tabelas de cada sistema são
carregadas separadamente na área de stage. A unificação e o ajuste são realizados
posteriormente no Data Warehouse. Fazer a junção direto na carga pode ser problemático.
Por exemplo, se o sistema A libera dados às 21h e o sistema B somente à 0h, a carga
dependeria de ambos. Na abordagem recomendada, você traz todas as informações para a
stage e realiza a junção após a disponibilidade de todos os dados.
2. Back Room

Após a área de staging, os dados passam para o back room, também conhecido
como Data Integration Layer. Nessa camada, os dados são integrados, transformados em
um formato comum e estruturados para que possam ser utilizados de forma mais consistente
em relatórios e análises.

Nele ocorre a preparação e o processamento dos dados antes de serem

disponibilizados para o uso analítico. Aqui, os dados são coletados, integrados e
transformados. Ele é focado na preparação e processamento dos dados. É onde ocorre
a transformação dos dados brutos em dados prontos para análise.

3. Front Room

O "front room" é a camada onde os dados já processados e preparados são

acessados por usuários para fins de análise e tomada de decisão. Neste ambiente, os dados
estão organizados de forma a facilitar o acesso e a análise, e são apresentados em
estruturas de fácil leitura, como Data Marts e tabelas dimensionais, que permitem consultas
rápidas e específicas. Ele é focado no consumo dos dados para análise, onde os dados
estão prontos e organizados para serem acessados pelos usuários finais de forma
eficiente e intuitiva.

A separação entre ambientes e o isolamento dos dados em diferentes camadas

(como staging, back room e front room) é essencial para garantir a integridade,
segurança e confiabilidade dos dados.

Data Warehouses na nuvem como Snow Flake e Google Big Query podem
assumir outro tipo de arquitetura em camadas.

Modelo Relacional/ Modelo Dimensional

As diferenças entre o modelo relacional e o modelo dimensional estão diretamente

relacionadas aos tipos de sistemas que eles suportam, como Data Warehouse (DW), OLAP
(Processamento Analítico Online) e OLTP (Processamento de Transações Online).
Cada modelo é otimizado para atender necessidades específicas de armazenamento,
consulta e processamento de dados

Modelo Relacional

• Estrutura normalizada, geralmente até a 3ª Forma Normal (3FN), onde os dados são
divididos em várias tabelas para reduzir redundância e garantir consistência.
• Mais usado em sistemas de OLTP (como sistemas bancários e ERP), que precisam
de alto desempenho em transações diárias e garantir a integridade dos dados: Focado
em operações de escrita rápidas.
• A estrutura normalizada exige várias junções entre tabelas para consultas
analíticas, tornando o modelo ineficiente para análise de grandes volumes de
dados, comum em ambientes de Data Warehouse.
• No modelo relacional, os relacionamentos são definidos com o objetivo de
garantir a integridade e consistência dos dados em operações transacionais.
• Chaves Primárias e Estrangeiras: As tabelas se conectam através de chaves
primárias e chaves estrangeiras. Cada tabela armazena um único tipo de entidade
(ex.: clientes, produtos, pedidos), e os relacionamentos permitem unir essas entidades
de forma controlada.
 • As tabelas no modelo OLTP frequentemente se relacionam para permitir a consulta
de informações integradas. Por exemplo, uma tabela Pedidos pode se relacionar com
uma tabela Clientes para buscar informações do cliente associado ao pedido.

• O modelo Entidade-Relacionamento (ER) é uma ferramenta de modelagem conceitual

usada para representar graficamente as entidades, atributos e relacionamentos que
existem no domínio de dados de um sistema.
• O resultado da modelagem ER é geralmente um Diagrama Entidade-Relacionamento
(DER), que mostra entidades (ex.: Cliente, Pedido, Produto) e relacionamentos (ex.:
Cliente faz Pedido).
• O modelo relacional implementa o modelo ER: Uma vez que o modelo ER está
definido, ele é traduzido para um modelo relacional, que é implementado
fisicamente no sistema de banco de dados.

Modelo Dimensional

• Estrutura desnormalizada, com tabelas de fatos e tabelas de dimensões. A tabela de

fatos armazena as medidas numéricas, enquanto as dimensões guardam os
contextos (como data, produto, cliente).
• É amplamente usado em sistemas de OLAP e Data Warehouses, onde as consultas
são mais analíticas e complexas, e o desempenho para leitura é essencial.
• Otimiza consultas analíticas, facilitando a navegação e a interpretação dos dados.
• O modelo dimensional, sendo desnormalizado, não é eficiente para operações
transacionais e pode introduzir redundância de dados e inconsistência se usado em
um sistema OLTP.
• No modelo dimensional, os relacionamentos também existem, mas têm uma
estrutura simplificada e desnormalizada com o objetivo de facilitar consultas
rápidas e eficientes.

Tabelas Fato

É onde estão armazenados os dados numéricos e quantitativos que representam

eventos ou transações ocorridas em uma organização. Ela é o núcleo do modelo dimensional
e contém informações que podem ser medidas e analisadas, como valores de vendas,
quantidade de itens vendidos, custo, lucro, etc. Elas contêm chaves estrangeiras que
apontam para as tabelas de dimensão.

Tabelas de Dimensão

Contém dados descritivos que dão contexto às medidas na tabela fato. Em vez de
números ou métricas, ela armazena informações qualitativas, como nomes, categorias,
descrições e atributos detalhados sobre entidades do negócio.

Esquemas

Os modelos dimensionais usam esquemas em estrela ou esquemas em floco de neve

para representar esses relacionamentos de forma que as consultas analíticas sejam rápidas
e fáceis de interpretar.

Modelo Estrela (Star Schema)

O modelo estrela é o mais simples e amplamente utilizado. Ele organiza os dados em uma
tabela central (tabela de fatos), que é cercada por tabelas menores (tabelas de dimensões).

Modelo Floco de Neve (Snowflake Schema)

É uma extensão do modelo estrela, mas com as dimensões normalizadas em várias tabelas.
Isso reduz redundâncias ao dividir as dimensões em várias tabelas menores relacionadas.
.
 Do Data Warehouse ao Data Lake
Os data warehouses introduziram a necessidade de um modelo de dados abrangente
para integrar diferentes áreas temáticas dentro de uma empresa. Para atingir esse objetivo,
foi amplamente adotada a técnica de modelagem dimensional. Esse modelo facilita a análise
de processos específicos de negócios, como vendas, oferecendo uma estrutura organizada e
eficiente. No entanto, apesar de sua eficácia inicial, os data warehouses enfrentaram sérias
limitações, especialmente com o avanço do big data e os desafios relacionados aos quatro
Vs:
• Volume: As arquiteturas de data warehouse tradicionais não foram projetadas
para lidar com o crescimento exponencial dos dados. O armazenamento de
petabytes de informações tornou-se caro e difícil de escalar, já que essas
soluções não utilizam tecnologias modernas, como processamento paralelo e
em memória. Isso resultou em dificuldades para acompanhar a escalabilidade
exigida.
• Velocidade: Os data warehouses não oferecem suporte adequado para
processar dados em tempo real, sendo incapazes de lidar com a velocidade de
fluxos de dados contínuos (streaming). A execução de processos de ETL em
janelas reduzidas acaba comprometendo a infraestrutura com o aumento da
carga.
• Variedade: Enquanto são excelentes para dados estruturados, os data
warehouses falham ao armazenar e consultar dados semiestruturados e não
estruturados, como logs, imagens ou dados de sensores, que são cada vez mais
comuns em ambientes de big data.
• Veracidade: A rastreabilidade e a confiabilidade dos dados são pontos fracos
nos data warehouses. Metadados são limitados ao esquema e pouco focados
na qualidade e na linhagem dos dados, o que compromete análises baseadas
em dados confiáveis.
Além disso, os formatos proprietários dessas arquiteturas restringem a integração
com ferramentas modernas, como as de ciência de dados e aprendizado de máquina, que
demandam maior flexibilidade e escalabilidade. Esses fatores tornam os data warehouses não
apenas caros de construir e manter, mas também inadequados para responder às rápidas
mudanças do cenário atual de negócios e tecnologia. Diante dessas limitações, surgiu o
conceito de data lake.
Essa nova abordagem foi projetada para lidar com os desafios do big data, oferecendo
uma solução moderna e flexível. Diferentemente dos data warehouses, os data lakes
permitem armazenar todos os tipos de dados estruturados, semiestruturados e não
estruturados em um único repositório centralizado, com custos mais baixos e escalabilidade
quase ilimitada. Essa arquitetura também permite maior liberdade para integrar ferramentas
avançadas de análise e processamento, atendendo às demandas de empresas modernas que
buscam se adaptar ao ritmo acelerado de crescimento e inovação no uso de dados.
Data Lake
Entre as arquiteturas mais populares que emergiram na era do big data, destaca-se o
data lake. Em vez de impor limitações rígidas à estrutura dos dados, a proposta do data lake
é simples: consolidar todos os dados estruturados, semiestruturados e não
estruturados em qualquer escala em um único repositório centralizado.
O termo “data lake” vem da analogia com um rio ou lago real, que retém a água, ou
neste caso, os dados, com vários afluentes que fluem para o lago em tempo real. Essa
abordagem prometeu transformar o acesso e a utilização de dados, funcionando como uma
força democratizadora ao permitir que empresas explorem, de maneira flexível, uma fonte
inesgotável de informações para tomadas de decisão e inovação.

O conceito de data lake teve início com o HDFS (Hadoop Distributed File System). Com
o avanço e a popularização da computação em nuvem, os data lakes evoluíram para soluções
baseadas em armazenamento de objetos na nuvem, caracterizadas por custos extremamente
baixos e uma capacidade de expansão praticamente ilimitada. Diferentemente de um data
warehouse monolítico, onde o armazenamento e o processamento estão fortemente
acoplados, o data lake permite centralizar grandes volumes de dados de qualquer tamanho
ou tipo, sem restrições rígidas de estrutura.
Quando há necessidade de consultar ou transformar esses dados, é possível aproveitar
o poder computacional escalável da nuvem, criando clusters sob demanda e selecionando a
ferramenta de processamento mais adequada para cada tarefa. Tecnologias como
MapReduce, Spark, Ray, Presto e Hive, entre outras, tornam essa abordagem flexível e
eficiente, atendendo a uma ampla gama de casos de uso e necessidades analíticas.
Componentes dos Data Lakes
1. Armazenamento: Data lakes utilizam sistemas de armazenamento escaláveis e
duráveis, geralmente baseados na nuvem. Esses sistemas permitem a ingestão
de grandes volumes de dados em lote ou em fluxo contínuo (ex.: IoT, streaming).
A separação entre armazenamento e computação possibilita escalabilidade
independente e ajustes sob demanda, tornando a solução mais eficiente.
 2. Computação: O processamento de dados é realizado por mecanismos como o
Apache Spark, que utilizam clusters de computação para lidar com tarefas de
análise e transformação.
3. Formatos de Dados: Os data lakes adotam formatos abertos e otimizados para
diferentes casos de uso, como Parquet (eficiência analítica), Avro (serialização),
JSON e CSV, garantindo compatibilidade e flexibilidade.
4. Metadados: Metadados fornecem informações contextuais sobre os dados,
como timestamps (registro de uso), esquemas (estrutura dos dados) e tags
(proprietário e classificação). Esses dados adicionais tornam a gestão e a análise
mais eficientes.
Apesar de toda a promessa e o hype, o conceito de data lake enfrentou sérias limitações:
• Embora projetados para análises OLAP, data lakes armazenam dados
brutos que frequentemente são desorganizados e difíceis de consultar
diretamente. Isso exige ferramentas adicionais de processamento e
análise, além de etapas de transformação e carga para data warehouses,
prolongando o tempo necessário para gerar valor. Esse modelo híbrido
de data lake + warehouse, amplamente adotado, tem perdido espaço
com o surgimento dos lakehouses.
• Apesar do armazenamento em nuvem ser barato, construir e manter um
data lake eficiente requer habilidades especializadas, elevando os custos
de pessoal ou consultoria.
• Operações básicas de SQL, como atualizar ou excluir dados, são muito
limitadas em data lakes e, geralmente, exigem recriar tabelas inteiras, o
que torna o processo lento e ineficiente. Além disso, como não há
garantias transacionais, atualizações simples podem exigir reescritas
completas dos dados já armazenados, aumentando custos e esforço,
• Com a abordagem de "esquema na leitura", os data lakes permitem ingerir
dados sem um esquema predefinido, mas essa flexibilidade pode resultar
em problemas de qualidade, transformando o repositório em um
verdadeiro "pântano de dados".
Diante dessas limitações dos data lakes de primeira geração, diversas empresas
buscaram maneiras de superar esses desafios e liberar todo o potencial dessa abordagem.
Um exemplo marcante foi a introdução do conceito de data lakehouse pela Databricks,
combinando o melhor dos mundos dos data lakes e data warehouses em uma solução mais
eficiente e integrada.
Data Lakehouse
O lakehouse incorpora os controles, a gestão de dados e as estruturas de dados
encontradas em um data warehouse, enquanto ainda armazena dados em armazenamento
de objetos e suporta uma variedade de mecanismos de consulta e transformação. Em
particular, o data lakehouse suporta transações com atomicidade, consistência, isolamento
e durabilidade (ACID), uma grande mudança em relação ao data lake original, onde os dados
eram apenas despejados, sem a possibilidade de atualizá-los ou excluí-los. O termo "data
lakehouse" sugere uma convergência entre data lakes e data warehouses.
• Atomicidade: Garante que uma transação seja tratada como uma única unidade
indivisível. Isso significa que ou toda a transação é concluída com sucesso, ou
nenhuma de suas partes é aplicada.
 • Consistência: Uma transação cria um novo estado válido dos dados ou retorna
todos os dados ao seu estado anterior em caso de falha.
• Isolamento: Garante que as transações simultâneas sejam executadas como se
fossem independentes, sem interferir umas nas outras.
• Durabilidade: Garante que, uma vez confirmada, uma transação será
permanentemente registrada no banco de dados, mesmo em caso de falhas no
sistema ou desligamento.
Assim como os data lakes, a arquitetura de lakehouse utiliza sistemas de
armazenamento em nuvem de baixo custo, com a flexibilidade e escalabilidade horizontal
inerentes a esses sistemas. O objetivo de um lakehouse é utilizar formatos de dados de alto
desempenho já existentes, como o Parquet, enquanto também permite transações ACID e
outros recursos.

A Camada de Metadados, Cache e Indexação transforma o Data Lake em um

Lakehouse, adicionando governança, transações ACID, e otimizações que tornam o
armazenamento pronto para análises avançadas, sem a necessidade de manter cópias
redundantes de dados no data lake e em um data Warehouse.
Para que um lakehouse ofereça governança de dados, transações ACID, e outros
controles avançados, é necessário utilizar sistemas ou frameworks adicionais que são
responsáveis por implementar essas funcionalidades. Frameworks como Delta Lake,
Apache Iceberg ou Apache Hudi são adicionados como uma camada de gerenciamento
sobre o data lake.
As três tecnologias (Delta Lake, Apache Iceberg e Apache Hudi) são as principais
"camadas de tabela" (table formats) que permitem essa transformação. Cada uma tem suas
particularidades:
 • Delta Lake:
o Desenvolvido pela Databricks, muito integrado com Spark
o Fornece suporte completo para transações ACID, versionamento e
governança de dados.
• Apache Iceberg:
o Criado pela Netflix, projetado para análise em larga escala, é altamente
eficiente para consultas analíticas distribuídas.
o Oferece transações ACID e controle de esquemas.
• Apache Hudi:
o Criado pelo Uber, focado em operações transacionais incrementais
(atualizações e deleções).
o Ideal para fluxos de dados contínuos e dados de mudança (CDC).
Esses frameworks atuam como o "motor" que transforma um data lake simples em um
lakehouse robusto e funcional. Sem eles, a arquitetura lakehouse perde muitos de seus
benefícios e se aproxima mais de um data lake tradicional. Esses frameworks são chamados
de "camadas de tabela" porque organizam e tratam os dados armazenados no data lake bruto
(em arquivos como Parquet ou JSON) como se fossem tabelas estruturadas, oferecendo
funcionalidades que antes eram exclusivas de bancos de dados ou data warehouses.
Delta Lake
O Delta Lake é um formato de tabela aberto que se sobrepõe ao armazenamento de
data lakes existentes (como Amazon S3, ADLS ou GCS). Ele combina a flexibilidade e
escalabilidade dos data lakes com funcionalidades transacionais e analíticas avançadas
típicas de um data warehouse. Essa fusão possibilita a implementação da arquitetura
lakehouse com mais eficiência, confiabilidade e capacidade de análise.
 Uma arquitetura lakehouse é estruturada em três camadas principais:
• Camada de Armazenamento: A camada base do lakehouse utiliza tecnologias
de armazenamento em nuvem padrão, como Azure Data Lake Storage (ADLS),
Google Cloud Storage (GCS) ou Amazon S3, para fornecer uma infraestrutura
escalável e econômica. Esses serviços permitem o armazenamento de grandes
volumes de dados em um formato bruto ou semiestruturado, garantindo alta
disponibilidade e custo reduzido.
• Camada Transacional: A camada intermediária é alimentada por tecnologias
como o Delta Lake, que introduz garantias ACID ao lakehouse. Isso possibilita
transformar dados brutos em tabelas prontas para análises avançadas. Além
disso, o Delta Lake oferece: Suporte para operações DML (como UPDATE,
DELETE, MERGE). Processamento eficiente e escalável de metadados.
Integração com fluxos de dados em streaming. Um log de auditoria detalhado,
que permite rastrear todas as alterações nos dados, além de oferecer
versionamento e recursos como "time travel".
• Camada de Consulta de Alto Desempenho: Na camada superior, encontram-
se os mecanismos de consulta e processamento, responsáveis por análises
rápidas e eficientes. Esses mecanismos aproveitam os recursos de computação
em nuvem subjacentes e são compatíveis com diversas ferramentas, incluindo:
o Apache Spark: Para processamento distribuído e análise em larga escala.
o Apache Hive: Para consultas SQL em grandes volumes de dados.
o Presto e Trino: Para execução de consultas SQL interativas e análises
rápidas.
Arquitetura Medallion
O padrão arquitetural conhecido como Medallion Architecture, com as camadas
Bronze, Silver e Gold, é amplamente utilizado em lakehouses para organizar e estruturar os
dados. Embora seja apenas uma das várias abordagens possíveis, essa arquitetura é ideal
para soluções como data warehouses modernos, data marts e outras iniciativas de análise de
dados.

A Medallion Architecture organiza os dados em camadas lógicas que refletem diferentes

estágios de processamento e qualidade dos dados. Essa abordagem incremental facilita a
limpeza, organização e preparação dos dados para consumo final. Cada camada tem um
propósito específico:
• Camada Bronze: É a zona de aterrissagem para os dados ingeridos dos
sistemas de origem. Os dados são armazenados "como estão" (dados brutos),
sem processamento inicial, mas podem ser enriquecidos com metadados, como
data e hora de carregamento ou identificadores de processamento. O formato
da fonte de dados é mantido: arquivos CSV são armazenados como CSV, dados
JSON são armazenados como JSON, e dados extraídos de tabelas de banco de
dados geralmente chegam à camada Bronze como arquivos Parquet ou AVRO.
O objetivo do processo de ingestão é armazenar rapidamente e de forma simples
os dados da fonte na camada Bronze, com auditoria e metadados mínimos para
permitir rastreabilidade e reprocessamento.

• Camada Silver: Aqui, os dados da camada Bronze passam por processos de

limpeza, normalização e conformação. É nessa camada que a visão corporativa
dos dados em diferentes áreas temáticas começa a se formar. É nessa camada
que começamos a aplicar esquemas (schemas), permitindo que eles evoluam
nas etapas subsequentes. Por ser a primeira camada onde a qualidade dos
dados é garantida e a visão empresarial é criada, a camada Silver serve como
uma fonte de dados útil para a empresa, especialmente para análises de
autoatendimento e relatórios ad hoc. Além disso, a camada Silver é uma
excelente fonte de dados para casos de uso de aprendizado de máquina e
inteligência artificial. Esses algoritmos geralmente funcionam melhor com os
dados "menos refinados" da camada Silver, em vez dos formatos prontos para
consumo encontrados na camada Gold.

• Camada Gold: Contém dados prontos para consumo, otimizados para análises
e relatórios. Os dados podem estar em um formato de esquema em estrela (com
tabelas de dimensões e fatos) ou qualquer outro modelo adaptado ao caso de
uso. Nesta camada final, são aplicadas as transformações de dados e as regras
de qualidade de dados finais, resultando em dados de alta qualidade e confiáveis
que servem como a única fonte de verdade dentro da organização. Essa camada
é especialmente ajustada para consumo otimizado por ferramentas de BI,
relatórios, aplicativos e usuários de negócios. Torna-se a camada principal para
leitura de dados utilizando motores de consulta de alto desempenho.
 Resumo da Arquitetura Medallion:
Camada Bronze Silver Gold
Valor de - Auditoria exata do que - Primeira camada útil - Dados em um formato
negócios foi recebido da fonte. para o negócio. fácil para os usuários de
- Capacidade de negócios navegarem.
reprocessar sem voltar à- Permite descoberta de
fonte. dados, autoatendimento, - Altíssimo
relatórios ad hoc, análises desempenho.
avançadas e ML.
Propriedades - Sem regras de negócios - Prioriza velocidade para - Prioriza casos de uso
ou transformações de o mercado e desempenho de negócios e
qualquer tipo. de escrita, apenas experiência do usuário.
transformações mínimas.
- Deve ser rápido e fácil - Transformações pré-
trazer novos dados para - Espera-se dados de calculadas e específicas
esta camada. qualidade. para negócios.

- Pode ter visões

separadas dos dados
para diferentes casos
de consumo.

Como é feito - Deve incluir uma cópia - Mesclagem Delta (Delta - Prioriza modelos de
do que foi recebido. merge). dados desnormalizados
e otimizados para
- Normalmente, os dados - Pode incluir modelagem leitura.
são armazenados em leve (3NF, Vaulting).
pastas com base na data - Totalmente
de recebimento. - Devem ser incluídas transformado.
verificações de qualidade
de dados. - Agregado.

Ilustração do Lakehouse completo:

Banco de Dados Relacionais e Não Relacionais
Bancos de Dados Relacionais
Um banco de dados relacional (ou RDB, do inglês Relational Database) é um tipo
de banco de dados que organiza e armazena informações em tabelas estruturadas.
• Os dados são armazenados em tabelas, compostas por linhas e colunas.
• Cada linha representa uma instância ou registro, enquanto cada coluna
representa um atributo ou característica do dado.
• Podemos pensar neles como uma planilha Excel.
Exemplo: Tabela Clientes

Design de Bancos de Dados Relacionais

Modelo Conceitual:
• É a etapa inicial e mais abstrata do design de banco de dados.
• Focado em representar os dados e suas relações de maneira
independente de qualquer sistema ou tecnologia específica.
• Representa o que será armazenado no banco de dados, com base
nos requisitos do negócio.
• Ao criar um modelo conceitual, é frequentemente útil visualizá-lo
em um diagrama de entidade-relacionamento (ER), uma
ferramenta padrão para visualizar as relações entre várias
entidades.

o MER (Modelo Entidade-Relacionamento):

▪ É a base do modelo conceitual.
▪ Define as entidades, atributos, relacionamentos e
cardinalidades de forma abstrata e alinhada aos
requisitos do negócio.
▪ Não se preocupa com detalhes técnicos ou
implementação, mas com o que será armazenado e
como esses elementos se conectam.
▪ Esse modelo ajuda a organizar a estrutura do banco
de dados.

o DER (Diagrama Entidade Relacionamento):

▪ É a representação gráfica do MER, usada para ilustrar
o modelo conceitual.
▪ Representa o relacionamento entre entidades em um
banco de dados.
 ▪ Facilita a compreensão visual das entidades, atributos e
relacionamentos.

• Elementos do DER
o Entidades: São os principais componentes do modelo conceitual e
aparecem no DER como retângulos. Representam os objetos ou
conceitos do mundo real que precisam ser modelados no banco de
dados.
o Atributos: Representam as características ou propriedades das
entidades. São exibidos como elipses no DER, conectadas à
entidade correspondente.
o Relacionamentos: Definem as associações entre duas ou mais
entidades e são representados como losangos no DER.

• Cardinalidades:
o Representam a quantidade de ocorrências de uma entidade
associadas a outra. Elas são definidas durante a criação do modelo
conceitual
▪ 1:1 (um para um): Cada registro de uma entidade está
associado a exatamente um registro de outra. Por exemplo, um
aluno tem apenas um cartão de identificação e um cartão de
identificação é dado a uma pessoa.

▪ 1:N (um para muitos): Um registro de uma entidade está

associado a mais de um elemento da outra. Por exemplo, um
cliente pode fazer muitos pedidos.
 ▪ N:1 (muitos para um): Quando mais de um elemento de uma
entidade está relacionado a um único elemento de outra
entidade. Por exemplo, os alunos têm que optar por um único
curso, mas um curso pode ter muitos alunos

▪ N:N (muitos para muitos): Quando mais de um elemento de uma

entidade é associado a mais de um elemento de outra entidade. Por
exemplo, você pode atribuir um funcionário a muitos projetos e um
projeto pode ter muitos funcionários.

Modelo Lógico:
• É a segunda etapa no processo de design de banco de dados, que
traduz o modelo conceitual em uma estrutura mais detalhada e
próxima da implementação prática, mas ainda independente de um
SGBD específico.
• Elementos do Modelo Lógico:
o Tabelas: As entidades do modelo conceitual são
transformadas em tabelas no modelo lógico. Cada tabela é
composta por linhas e colunas.
o Chaves: As chaves são essenciais no modelo lógico para
garantir a unicidade dos registros e as relações entre as
tabelas.
▪ Chaves Candidatas: Colunas (ou combinações de
colunas) que podem identificar de forma única os
registros de uma tabela. Exemplo: Em uma tabela de
pessoas, tanto o CPF quanto a CNH podem ser chaves
candidatas.
▪ Chave Primária: Entre as chaves candidatas, uma é
escolhida como chave primária (Primary Key). Ela
identifica de forma única cada registro da tabela.
▪ Chaves Alternadas: São as chaves candidatas não
selecionadas como chave primária. Continuam sendo
únicas, mas não são usadas como principal
identificador.
▪ Chave Estrangeira: É uma coluna que estabelece um
relacionamento entre duas tabelas. Refere-se à chave
primária de outra tabela.
 Modelo Físico:
• O modelo físico é a última etapa no design de um banco de dados e
define como o modelo lógico será implementado em um sistema de
gerenciamento de banco de dados (SGBD) específico. Ele se
concentra nos detalhes técnicos e práticos, como tipos de dados,
índices, configurações de armazenamento e segurança.
• Ele traduz as tabelas e relacionamentos definidos no modelo lógico
para um banco de dados real em um SGBD específico, como MySQL,
PostgreSQL, Oracle, SQL Server, etc

Normalização em Banco de Dados

A normalização é um processo utilizado na modelagem de dados em bancos
de dados relacionais para eliminar redundâncias, garantir integridade referencial e
minimizar anomalias de inserção, atualização e exclusão. Esse processo divide os
dados em tabelas menores e bem estruturadas, utilizando chaves primárias e
estrangeiras para estabelecer relacionamentos entre elas.
Dependências Funcionais: são o fundamento central para compreender e
aplicar a normalização em bancos de dados relacionais. Representam uma relação
entre os atributos de uma tabela, na qual o valor de um atributo (ou de um conjunto
de atributos) determina de forma única o valor de outro atributo (ou conjunto de
atributos). Essa relação é essencial para garantir a integridade dos dados e eliminar
redundâncias, facilitando a organização e o gerenciamento das informações no
banco de dados.

CPF → Nome: Neste caso, nome depende funcionalmente de CPF, porque cada
CPF único corresponde a um único Nome.
• Dependência Funcional Parcial: Ocorre em tabelas com chave
composta, quando um atributo depende apenas de uma parte da chave
e não da chave inteira.
o Chave Composta: (VendaID, ProdutoID)

o NomeProduto depende apenas de ProdutoID, não da chave

composta (VendaID, ProdutoID).
o Isso significa que NomeProduto não precisa de VendaID para ser
identificado unicamente, pois ProdutoID já determina unicamente
NomeProduto.
o Isso é o que caracteriza uma dependência funcional parcial:
NomeProduto depende parcialmente apenas de ProdutoID e não
de toda a chave composta (VendaID, ProdutoID).

• Dependência Funcional Transitiva: Ocorre quando um atributo

depende de outro atributo indiretamente através de um terceiro.

o EmpregadoID: é a chave primária, e determina unicamente todos

os outros atributos.
o A dependência funcional transitiva ocorre aqui porque:
▪ NomeDepartamento e LocalDepartamento são
dependentes de DepartamentoID, e não diretamente de
EmpregadoID.
▪ No entanto, como DepartamentoID é determinado por
EmpregadoID, temos uma dependência indireta (transitiva)
de NomeDepartamento e LocalDepartamento com
EmpregadoID.

• Atributos Multivalorados e Compostos:

o Atributos Multivalorados: Atributos que podem conter mais de
um valor para uma única entidade. Exemplo: Um aluno pode ter
múltiplos números de telefone.
 o Atributos Compostos: São atributos que podem ser divididos em
subcomponentes menores que representam informações mais
detalhadas. Exemplo: EnderecoCompleto pode ser dividido em
Rua, Número, Cidade, Estado, CEP.

Formas Normais
O processo de normalização é dividido em etapas chamadas formas normais (NF
- Normal Forms). Cada forma normal tem critérios específicos:
• Primeira Forma Normal (1NF):
o Cada coluna deve conter apenas valores indivisíveis (sem atributos
compostos ou multivalorados).
▪ Atributos multivalorados:

▪ Após a 1NF:
 ▪ Atributos compostos:

• Segunda Forma Normal (2NF):

▪ Eliminar dependências funcionais parciais.
▪ A tabela deve estar na 1NF
▪ Exemplo: Separar NomeProduto de uma tabela (VendaID,
ProdutoID) para colocá-lo em uma tabela de Produtos, já que
NomeProduto depende apenas de ProdutoID.

▪ Após a 2NF:
 • Terceira Forma Normal (3NF):
▪ Eliminar dependências funcionais transitivas.
▪ A tabela deve estar na 2NF.
▪ Exemplo: Mover NomeDepartamento e LocalDepartamento
para uma tabela separada de Departamentos, já que essas
colunas dependem de DepartamentoID e não diretamente de
EmpregadoID.

▪ Após a 3NF:

Bancos de Dados Não Relacionais: NoSQL

NoSQL, que significa "não apenas SQL", representa uma classe de bancos
de dados que se distanciam do paradigma relacional tradicional, oferecendo maior
flexibilidade e escalabilidade. Ele não usa o esquema de tabela de linhas e colunas
encontrado na maioria dos sistemas de banco de dados tradicionais. Em vez disso,
os bancos de dados não relacionais usam um modelo de armazenamento otimizado
para os requisitos específicos do tipo de dados que está sendo armazenado. Na
prática, "NoSQL" significa "banco de dados não relacionais", mesmo que muitos
desses bancos de dados deem suporte a consultas compatíveis com SQL. Vamos
explorar os principais tipos de bancos de dados NoSQL: chave-valor, documento,
coluna larga e grafo.
 1. Armazenamento Chave-Valor
Um banco de dados chave-valor armazena dados como pares de chave e
valor, onde a chave é única e usada para localizar rapidamente os dados
correspondentes. Esses bancos são ideais para cenários de alto desempenho e
baixa complexidade. Exemplo: DynamoDB (AWS): Oferece armazenamento chave-
valor escalável, amplamente utilizado para aplicações web.

2. Armazenamento de Documentos
O armazenamento de documento é um modelo de banco de dados NoSQL
que organiza os dados como documentos, em vez de linhas e colunas (como nos
bancos relacionais). Os dados armazenados são estruturas semelhantes a JSON
(ou BSON), permitindo uma organização flexível e hierárquica. Cada registro é um
documento que pode conter objetos aninhados.
Vantagens:
• Elimina a necessidade de normalização.
• Ideal para aplicações que exigem estruturação de dados flexível.
Exemplo: MongoDB: Muito popular para aplicações web, permite que dados
estruturados e semiestruturados sejam armazenados e consultados com eficiência.
 3. Bancos de Dados de Coluna Larga
Os bancos de dados de coluna larga (ou wide-column databases) são
uma categoria de bancos de dados NoSQL projetados para armazenar grandes
volumes de dados de forma distribuída e escalável. Eles são baseados em tabelas,
mas diferem dos bancos de dados relacionais tradicionais porque organizam os
dados em colunas em vez de linhas. Essa abordagem oferece alta eficiência para
consultas que requerem leitura ou agregação de valores específicos em colunas. Os
bancos de dados de coluna larga armazenam os dados em um formato onde:
• Famílias de colunas são coleções de colunas relacionadas que
compartilham características semelhantes.
• Não é obrigatório que todas as linhas tenham o mesmo conjunto de colunas.
A estrutura é altamente flexível porque não exige que todas as linhas de uma
tabela tenham as mesmas colunas. Exemplo: Apache Cassandra, excelente para
armazenar dados em larga escala.

4. Bancos de Dados de Grafo

Bancos de dados de grafo são uma categoria especializada de bancos de
dados projetada para armazenar, gerenciar e consultar informações estruturadas
em forma de grafos. Os bancos de dados de grafos são desenvolvidos
especificamente para facilitar a criação e execução de aplicações que funcionam
com conjuntos de dados altamente conectados. Eles usam nós para armazenar
entidades de dados e bordas para armazenar os relacionamentos entre as
entidades. Esses bancos são especialmente úteis para modelar e explorar dados
interconectados, como redes sociais, sistemas de recomendação, análise de
fraudes e redes de transporte. Exemplo: Neo4j e Amazon Neptune.