Dados: Arquitetura, Engenharia e SQL
Entenda do zero · Dados, Engenharia e SQL
Pense no caminho de uma informação: ela nasce em um sistema, é guardada, preparada e consultada. Os nomes técnicos descrevem partes desse caminho.
1. O que é um banco de dados?
É uma coleção organizada de dados. Em um banco relacional, uma tabela pode guardar contribuintes: cada linha representa um registro e cada coluna, uma característica. A chave primária identifica cada registro sem duplicidade; uma chave estrangeira faz referência a uma chave de outra tabela, ou da própria tabela, ajudando a manter os relacionamentos válidos.
2. Por que separar tabelas?
Imagine repetir o nome e o endereço de um contribuinte em todas as suas notas fiscais. Uma mudança de endereço exigiria várias atualizações. A normalização organiza as informações para reduzir redundâncias e anomalias. Uma tabela de notas pode guardar o identificador do contribuinte, e a consulta combina os dados por meio de um JOIN.
3. SQL é uma forma de fazer perguntas aos dados
SELECT indica o que mostrar; FROM, de onde vêm os registros; WHERE filtra linhas; GROUP BY reúne linhas em grupos; SUM soma valores. Leia a consulta como uma pergunta, não como uma sequência de palavras para decorar.
SELECT municipio, SUM(valor) AS total
FROM arrecadacao
WHERE ano = 2026
GROUP BY municipio;A consulta considera os registros de 2026 e retorna uma linha para cada município, com a soma de seus valores. Não retorna cada pagamento individual.
4. Operar o dia a dia é diferente de analisar o histórico
Um sistema OLTP registra operações, como um pagamento. Uma solução OLAP favorece análises, como comparar arrecadação ao longo dos anos. O Data Warehouse (DW) integra dados para análise; o Data Lake aceita dados em formatos variados. ETL extrai, transforma e carrega; ELT carrega antes de transformar no ambiente de destino.
Confira se entendeu: para trazer também contribuintes sem notas, basta um INNER JOIN?
Não. O INNER JOIN mantém apenas as correspondências. Um LEFT JOIN partindo de contribuintes pode manter todos eles, com NULL nos campos sem correspondência; filtros posteriores precisam preservar essa intenção.
A seguir, compare as arquiteturas e aprofunde a leitura de SQL.
Tipos de dados e Big Data
| Tipo | Característica | Exemplos |
|---|---|---|
| Estruturado | Esquema rígido e prévio (linhas e colunas), schema-on-write | Tabelas de SGBD relacional, planilha bem formada |
| Semiestruturado | Esquema embutido/autodescritivo (tags, chaves), flexível | JSON, XML, YAML, CSV com cabeçalho, logs com campos, NF-e em XML |
| Não estruturado | Sem modelo de dados predefinido | Texto livre, PDF digitalizado, imagem, áudio, vídeo, e-mail (corpo) |
Os Vs do Big Data
- Volume (quantidade), Velocidade (taxa de geração/processamento), Variedade (formatos) — os 3 Vs originais (Doug Laney).
- Veracidade (confiabilidade/qualidade) e Valor (utilidade para o negócio) completam os 5 Vs.
Processamento distribuído: Hadoop
- HDFS: sistema de arquivos distribuído. NameNode guarda metadados (onde está cada bloco); DataNodes guardam os blocos. Blocos grandes (padrão 128 MB no Hadoop 2+) e replicação padrão 3.
- MapReduce: fase map (gera pares chave-valor) → shuffle/sort (agrupa por chave) → reduce (agrega). Grava resultados intermediários em disco (por isso é lento frente ao Spark).
- YARN: gerenciador de recursos (ResourceManager + NodeManagers).
- Princípio-chave: levar o processamento até o dado (localidade de dados), e não o dado até o processamento.
Apache Spark e PySpark
- Motor de processamento distribuído em memória, muito mais rápido que MapReduce em cargas iterativas.
- Arquitetura: Driver (programa principal, cria o plano/DAG, SparkSession) + Executors (executam tarefas nos nós) + Cluster Manager (standalone, YARN, Kubernetes).
- Abstrações: RDD (Resilient Distributed Dataset — imutável, particionado, tolerante a falhas pela linhagem) → DataFrame (colunas nomeadas, otimizado pelo Catalyst) → Dataset (tipado, Scala/Java).
- Módulos: Spark SQL, Structured Streaming, MLlib, GraphX.
| Transformação | Ação |
|---|---|
| Preguiçosa (lazy): só registra no plano, não executa | Dispara a execução do DAG |
| Retorna novo RDD/DataFrame | Retorna valor ao driver ou grava |
select, filter/where, withColumn, groupBy, join, map | count, collect, show, take, write, first |
- Narrow (estreita): cada partição de saída depende de uma partição de entrada (
filter,map) — sem shuffle. - Wide (larga): exige shuffle entre nós (
groupBy,join,distinct) — cria novo estágio, é a operação cara.
from pyspark.sql import SparkSession, functions as F
spark = SparkSession.builder.appName("icms").getOrCreate()
df = spark.read.parquet("/lake/silver/nfe") # transformação (lazy)
res = (df.filter(F.col("uf") == "SP") # narrow
.groupBy("cnae") # wide (shuffle)
.agg(F.sum("valor").alias("total")))
res.show() # AÇÃO: aqui executa
df.filter(...) o Spark processa imediatamente os dados" — errado. Nada roda até uma ação. Outra: collect() traz todos os dados para o driver — em base grande, estoura memória; para espiar, use show() ou take(n).cache()/persist() guardam em memória um resultado reutilizado.Arquiteturas: DW, Data Mart, Data Lake, Lakehouse
Data Warehouse (Inmon)
| Inmon | Kimball | |
|---|---|---|
| Abordagem | Top-down | Bottom-up |
| Núcleo | EDW corporativo normalizado (3FN) | Data marts dimensionais (estrela) |
| Data marts | Dependentes, derivados do EDW | São o próprio DW, integrados pelo barramento (bus) com dimensões conformadas |
| Entrega | Mais lenta, mais integrada desde o início | Mais rápida, incremental |
Data Mart
- Subconjunto do DW focado em um departamento/assunto (ex.: mart de ITCMD).
- Dependente: alimentado pelo DW. Independente: alimentado direto das fontes (risco de "silos" e números divergentes).
Comparativo das arquiteturas
| Data Warehouse | Data Lake | Data Lakehouse | |
|---|---|---|---|
| Dados | Estruturados, tratados | Todos os tipos, brutos (formato nativo) | Todos os tipos |
| Esquema | Schema-on-write | Schema-on-read | Ambos (com imposição e evolução de esquema) |
| Armazenamento | SGBD analítico (custo maior) | Object storage barato (S3, ADLS, HDFS) | Object storage + formato de tabela aberto (Delta Lake, Apache Iceberg, Apache Hudi) |
| Transações ACID | Sim | Em geral não | Sim (via camada de metadados/log de transações) |
| Usuário típico | Analista de negócio, BI | Cientista/engenheiro de dados | Ambos: BI e ciência de dados na mesma cópia |
| Risco | Rigidez, custo | Virar data swamp (pântano) sem governança/catálogo | Complexidade de plataforma |
Arquitetura medalhão (medallion)
- Bronze: dado bruto, como chegou (ingestão, histórico, reprocessável).
- Prata (silver): limpo, deduplicado, tipado, conformado.
- Ouro (gold): agregado e modelado para consumo (BI, indicadores, modelos estrela).
Engenharia de dados: pipelines, ETL e ELT
| ETL | ELT | |
|---|---|---|
| Ordem | Extrai → Transforma (servidor/ferramenta intermediária, área de staging) → Carrega | Extrai → Carrega bruto no destino → Transforma dentro do destino |
| Onde transforma | Fora do destino (motor de ETL) | No próprio DW/Lakehouse (poder de processamento escalável, SQL) |
| Combina com | DW tradicional on-premises, dados sensíveis que precisam ser tratados antes | Nuvem, Data Lake/Lakehouse, big data |
| Dado bruto | Normalmente não fica disponível | Fica disponível para reprocessar |
- Staging area: área intermediária onde os dados extraídos ficam para limpeza/integração.
- Carga full x incremental (só o que mudou: por data de alteração, watermark ou CDC — Change Data Capture, que lê o log de transações da fonte).
- Orquestração: agenda e encadeia tarefas como um DAG (ex.: Apache Airflow, Azure Data Factory).
- Idempotência: rodar o pipeline duas vezes não duplica nem corrompe o resultado.
Tratamento, limpeza e preparação
| Técnica | O que faz |
|---|---|
| Limpeza | Tratar ausentes (remover, imputar média/mediana/moda), corrigir erros de digitação, padronizar formatos (datas, CPF) |
| Deduplicação | Eliminar registros repetidos (garante unicidade) |
| Tratamento de outliers | Detectar (IQR, z-score) e decidir: corrigir, remover, limitar (winsorizar) ou manter |
| Enriquecimento | Agregar informação externa/complementar (ex.: CNPJ → CNAE e município) |
| Normalização (escala) | Min-max: leva a [0,1]; padronização z-score: média 0, desvio 1 |
| Discretização / codificação | Faixas (binning); one-hot para categóricas |
| Integração | Unir fontes resolvendo conflitos de nomes, chaves e unidades |
Qualidade de dados (dimensões)
| Dimensão | Pergunta | Exemplo de falha |
|---|---|---|
| Completude | Está tudo preenchido? | CNPJ em branco |
| Unicidade | Existe uma só vez? | Contribuinte cadastrado duas vezes |
| Validade | Obedece à regra/formato/domínio? | Data 31/02; UF "XX" |
| Acurácia | Corresponde à realidade? | Endereço válido, mas errado |
| Consistência | Bate entre sistemas/campos? | Total da nota diferente da soma dos itens |
| Tempestividade/atualidade | Está disponível a tempo/atualizado? | Cadastro desatualizado há 2 anos |
Batch x Streaming
| Lote (batch) | Fluxo (streaming) | |
|---|---|---|
| Dados | Conjunto limitado (bounded), acumulado | Fluxo contínuo e ilimitado (unbounded) |
| Latência | Alta (minutos a horas) | Baixa (milissegundos a segundos) |
| Uso | Cargas noturnas do DW, fechamento mensal | Detecção de fraude, monitoramento, IoT, alertas |
| Ferramentas | Spark batch, MapReduce, SQL agendado | Apache Kafka (mensageria/log de eventos), Spark Structured Streaming (micro-batch), Apache Flink |
Janelas em streaming
- Tumbling (fixa/em cascata): tamanho fixo, sem sobreposição (ex.: a cada 5 min).
- Sliding/Hopping (deslizante/saltitante): tamanho fixo, com sobreposição (10 min, avançando a cada 1 min).
- Session (sessão): fecha após um período de inatividade (gap).
- Event time (quando ocorreu) x processing time (quando chegou). Watermark: limite de tolerância para eventos atrasados.
| Arquitetura Lambda | Arquitetura Kappa |
|---|---|
| Duas trilhas: batch layer (precisão) + speed layer (tempo real) + serving layer | Uma trilha só: tudo é streaming; reprocessa reproduzindo o log de eventos |
| Desvantagem: duas bases de código | Mais simples de manter |
Modelagem relacional e normalização
- Modelo conceitual (MER/DER, independente de SGBD) → lógico (tabelas, chaves) → físico (tipos, índices, particionamento do SGBD específico).
- Superchave: identifica unicamente. Chave candidata: superchave mínima. Primária: a candidata escolhida (não nula, única). Alternativa: candidata não escolhida. Estrangeira: referencia a PK de outra tabela (integridade referencial).
- Integridade de entidade (PK não nula) x integridade referencial (FK aponta para registro existente ou é nula).
- Cardinalidade 1:1, 1:N, N:N (N:N vira tabela associativa no modelo lógico).
| Forma normal | Regra |
|---|---|
| 1FN | Valores atômicos; sem grupos repetitivos/atributos multivalorados |
| 2FN | 1FN + sem dependência parcial (atributo não chave depende de toda a chave composta) |
| 3FN | 2FN + sem dependência transitiva (não chave dependendo de outro não chave) |
| FNBC (Boyce-Codd) | Todo determinante é chave candidata |
| 4FN | FNBC + sem dependência multivalorada não trivial |
| 5FN | 4FN + sem dependência de junção não trivial |
Modelagem dimensional
- Fato: evento/processo de negócio mensurável; guarda métricas numéricas + FKs das dimensões. Tabela longa e estreita.
- Dimensão: contexto descritivo (quem, o quê, onde, quando); atributos textuais para filtrar e agrupar. Tabela larga e curta.
- Granularidade (grão): o nível de detalhe de uma linha da fato (ex.: "um item de NF-e"). É a decisão mais importante.
- Surrogate key (chave substituta): inteiro sem significado gerado no DW; desacopla da chave natural da fonte e viabiliza SCD tipo 2.
- Hierarquias: Ano → Trimestre → Mês → Dia; País → UF → Município (base do drill-down/roll-up).
Estrela x Floco de neve x Constelação
| Estrela (star) | Floco de neve (snowflake) | Constelação (galáxia) | |
|---|---|---|---|
| Dimensões | Desnormalizadas, ligadas direto à fato | Normalizadas em subdimensões | Várias fatos compartilhando dimensões conformadas |
| Junções | Poucas | Mais junções | — |
| Desempenho/simplicidade | Melhor | Pior consulta, economiza espaço | — |
Tipos de métricas e de fatos
- Aditiva: soma em todas as dimensões (valor do ICMS). Semiaditiva: soma em algumas, não no tempo (saldo, estoque). Não aditiva: não soma (percentual, preço unitário, razão).
- Fato transacional (um evento por linha), snapshot periódico (foto em intervalos: saldo mensal), snapshot acumulado (marcos de um processo com várias datas: pedido → faturado → entregue), fato sem fato (factless) (registra ocorrência sem métrica: presença, cobertura).
Tipos especiais de dimensão
- Conformada: mesma dimensão compartilhada por várias fatos/marts (integra o barramento).
- Degenerada: atributo de dimensão sem tabela própria, guardado na fato (número da NF).
- Junk (lixo): agrupa flags e indicadores de baixa cardinalidade.
- Role-playing: mesma dimensão com papéis diferentes (Data de emissão, Data de pagamento).
SCD — Slowly Changing Dimensions
| Tipo | Técnica | Histórico |
|---|---|---|
| 0 | Mantém o valor original, ignora mudança | Só o original |
| 1 | Sobrescreve | Nenhum |
| 2 | Nova linha com nova surrogate key + datas de vigência / flag de atual | Completo |
| 3 | Nova coluna (valor anterior / atual) | Limitado (só o anterior) |
| 4 | Mini-dimensão / tabela de histórico separada | Separado |
| 6 | Híbrido 1 + 2 + 3 | Completo + valor atual em todas as linhas |
OLTP x OLAP e operações OLAP
| OLTP (transacional) | OLAP (analítico) | |
|---|---|---|
| Objetivo | Operação do dia a dia | Análise e decisão |
| Operações | INSERT/UPDATE/DELETE curtos e frequentes | Leituras complexas, agregações sobre grande volume |
| Modelo | Normalizado (3FN) | Dimensional (estrela), desnormalizado |
| Dados | Atuais | Históricos |
| Usuários | Muitos, operacionais | Poucos, analistas/gestores |
| Operação | O que faz |
|---|---|
| Drill-down | Desce na hierarquia (ano → mês): mais detalhe |
| Roll-up (drill-up) | Sobe na hierarquia / agrega: menos detalhe |
| Slice | Fixa um valor de uma dimensão (fatia: só 2025) |
| Dice | Seleciona faixas em duas ou mais dimensões (subcubo) |
| Pivot (rotação) | Gira os eixos da visualização |
| Drill-across | Navega entre cubos/fatos diferentes por dimensões conformadas |
| Drill-through | Vai do cubo até o dado detalhado de origem |
| MOLAP | ROLAP | HOLAP | DOLAP |
|---|---|---|---|
| Cubo multidimensional pré-calculado: rápido, menos escalável | Sobre banco relacional (SQL): escalável, mais lento | Híbrido: agregados em MOLAP, detalhe em ROLAP | Desktop: cubo baixado para a máquina do usuário |
Bancos relacionais, colunares e NoSQL
| ACID (relacional) | BASE (muitos NoSQL) |
|---|---|
| Atomicidade: tudo ou nada | Basically Available: basicamente disponível |
| Consistência: transação leva de um estado válido a outro válido | Soft state: estado pode mudar sem nova entrada (replicação) |
| Isolamento: transações concorrentes não se enxergam pela metade | Eventually consistent: converge com o tempo |
| Durabilidade: confirmado (commit) não se perde |
Teorema CAP (Brewer)
- Durante uma partição de rede, um sistema distribuído não pode garantir simultaneamente Consistência no sentido de linearizabilidade e Availability/Disponibilidade para todas as requisições aos nós não falhos. Partition tolerance diz respeito à operação apesar dessa separação de comunicação; o atalho “escolha quaisquer duas letras” precisa dessa ressalva.
- Como partição de rede é inevitável em sistema distribuído, na prática a escolha é entre CP e AP quando ocorre a partição.
Tipos de NoSQL
| Tipo | Modelo | Uso típico | Exemplos |
|---|---|---|---|
| Chave-valor | Chave → valor opaco | Cache, sessão, carrinho | Redis, Amazon DynamoDB, Riak |
| Documento | Documentos JSON/BSON aninhados, esquema flexível | Catálogos, cadastros variáveis, APIs | MongoDB, CouchDB |
| Família de colunas (wide-column) | Linhas com conjuntos variáveis de colunas agrupadas em famílias | Escrita massiva, séries temporais, IoT | Apache Cassandra, HBase |
| Grafo | Nós, arestas e propriedades | Redes de relacionamento, fraude (laranjas, grupos econômicos) | Neo4j, Amazon Neptune |
Banco colunar (analítico)
- Armazena os dados coluna a coluna no disco (e não linha a linha). Lê só as colunas da consulta e comprime muito bem (valores repetidos na mesma coluna).
- Ótimo para OLAP/agregações; ruim para inserir/atualizar registros individuais.
- Exemplos: Amazon Redshift, Google BigQuery, ClickHouse, Vertica, índice columnstore do SQL Server; formatos de arquivo Parquet e ORC (colunares) x CSV/Avro (orientados a linha).
SQL: sublinguagens e comandos
| Sublinguagem | Comandos |
|---|---|
| DDL (definição) | CREATE, ALTER, DROP, TRUNCATE, RENAME |
| DML (manipulação) | INSERT, UPDATE, DELETE, MERGE |
| DQL (consulta) | SELECT (muitos autores o põem na DML) |
| DCL (controle) | GRANT, REVOKE (DENY no SQL Server) |
| TCL (transação) | COMMIT, ROLLBACK, SAVEPOINT |
| DELETE | TRUNCATE | DROP | |
|---|---|---|---|
| Categoria | DML | DDL | DDL |
| Remove | Linhas (todas ou com WHERE) | Todas as linhas, sem WHERE | A tabela inteira (estrutura + dados + índices) |
| Estrutura | Mantém | Mantém | Some |
| Triggers de DELETE | Disparam | Não disparam | — |
| Desempenho | Mais lento (registra linha a linha) | Rápido (desaloca páginas) | Rápido |
Restrições (constraints)
PRIMARY KEY, FOREIGN KEY ... REFERENCES (com ON DELETE CASCADE / SET NULL / NO ACTION), UNIQUE (aceita NULL, conforme SGBD), NOT NULL, CHECK, DEFAULT.
SQL: consulta (DQL), agregação e filtros
Ordem lógica de execução
| Escrita | Execução lógica |
|---|---|
| 1. SELECT 2. FROM / JOIN 3. WHERE 4. GROUP BY 5. HAVING 6. ORDER BY 7. LIMIT/TOP | 1. FROM / JOIN 2. WHERE 3. GROUP BY 4. HAVING 5. SELECT (e DISTINCT) 6. ORDER BY 7. LIMIT/OFFSET/TOP |
| WHERE | HAVING |
|---|---|
| Filtra linhas, antes do agrupamento | Filtra grupos, depois do GROUP BY |
| Não aceita função de agregação | Aceita agregação (HAVING SUM(v) > 1000) |
SELECT c.uf, COUNT(*) AS qtd, SUM(n.valor_icms) AS total
FROM nfe n
JOIN contribuinte c ON c.id = n.id_contrib
WHERE n.dt_emissao >= '2026-01-01' -- filtra linhas
GROUP BY c.uf
HAVING SUM(n.valor_icms) > 1000000 -- filtra grupos
ORDER BY total DESC; -- alias permitido aqui
Funções de agregação e NULL
COUNT(*)conta linhas (inclusive com NULL);COUNT(coluna)ignora NULL;COUNT(DISTINCT coluna)conta valores distintos não nulos.SUM,AVG,MIN,MAXignoram NULL. AVG de (10, NULL, 20) = 15, não 10.- Na regra padrão, toda coluna do SELECT que não estiver em função de agregação deve estar no GROUP BY.
NULL = NULLnão é verdadeiro (resulta em desconhecido): useIS NULL/IS NOT NULL.COALESCE(a, b)devolve o primeiro não nulo.
WHERE x NOT IN (SELECT y FROM t): se a subconsulta retornar algum NULL, o resultado é vazio. NOT EXISTS não sofre esse efeito.Filtros e operadores lógicos
BETWEEN a AND bé inclusivo nos dois extremos.LIKE:%= qualquer sequência (inclusive vazia);_= exatamente um caractere.'_A%'= segundo caractere é A.IN (lista),EXISTS (subconsulta),ANY/ALL.- Precedência: NOT > AND > OR. Sem parênteses,
A OR B AND C=A OR (B AND C). ORDER BYpadrão é ASC; posição de NULL na ordenação varia conforme o SGBD.CASE WHEN ... THEN ... ELSE ... ENDpara lógica condicional.
SQL: junções, conjuntos, subconsultas e janelas
| JOIN | Retorna |
|---|---|
| INNER JOIN | Só as linhas com correspondência nas duas tabelas |
| LEFT (OUTER) JOIN | Todas da esquerda + correspondentes da direita (NULL onde não há par) |
| RIGHT (OUTER) JOIN | Todas da direita + correspondentes da esquerda |
| FULL (OUTER) JOIN | Todas de ambas, com NULL onde não há par |
| CROSS JOIN | Produto cartesiano (m × n linhas) |
| SELF JOIN | Tabela unida a ela mesma (ex.: servidor e chefe) |
| NATURAL JOIN | Junção automática pelas colunas de mesmo nome |
-- Anti-join: contribuintes SEM nenhuma nota emitida
SELECT c.id, c.razao
FROM contribuinte c
LEFT JOIN nfe n ON n.id_contrib = c.id
WHERE n.id_contrib IS NULL;
WHERE n.ano = 2026) elimina as linhas com NULL e transforma o resultado, na prática, em INNER JOIN. Para preservar o "left", ponha a condição no ON.Operações de conjunto
UNION= união sem duplicatas;UNION ALL= mantém duplicatas (mais rápido).INTERSECT= interseção;EXCEPT(no Oracle,MINUS) = diferença.- Exigem o mesmo número de colunas, com tipos compatíveis, na mesma ordem.
Subconsultas e CTE
- Correlacionada: referencia a consulta externa e é avaliada para cada linha dela.
- CTE:
WITH nome AS (SELECT ...) SELECT ... FROM nome— legibilidade;WITH RECURSIVEpara hierarquias. - View: consulta armazenada (tabela virtual). View materializada: guarda o resultado fisicamente e precisa de refresh.
Funções de janela (window functions)
SELECT uf, municipio, arrecadacao,
ROW_NUMBER() OVER (PARTITION BY uf ORDER BY arrecadacao DESC) AS rn,
RANK() OVER (PARTITION BY uf ORDER BY arrecadacao DESC) AS rk,
DENSE_RANK() OVER (PARTITION BY uf ORDER BY arrecadacao DESC) AS drk,
LAG(arrecadacao) OVER (ORDER BY mes) AS mes_anterior
FROM arrecadacao_municipio;
| Valores empatados | ROW_NUMBER | RANK | DENSE_RANK |
|---|---|---|---|
| 100, 90, 90, 80 | 1, 2, 3, 4 | 1, 2, 2, 4 (pula) | 1, 2, 2, 3 (não pula) |
LAG olha a linha anterior; LEAD, a próxima. GROUP BY ROLLUP gera subtotais hierárquicos; CUBE gera subtotais de todas as combinações.Variações (dialetos) do SQL
| Recurso | SQL Server (T-SQL) | Oracle (PL/SQL) | PostgreSQL / MySQL |
|---|---|---|---|
| Limitar linhas | SELECT TOP 10 | FETCH FIRST 10 ROWS ONLY (ou ROWNUM) | LIMIT 10 |
| Diferença de conjuntos | EXCEPT | MINUS | EXCEPT (PostgreSQL) |
| Linguagem procedural | T-SQL | PL/SQL | PL/pgSQL (PostgreSQL) |
No ecossistema big data: Spark SQL, HiveQL (Hive sobre Hadoop) e SQL em motores distribuídos (Presto/Trino) — SQL sobre arquivos do lago.
Análise de dados: EDA, mineração e analytics
- EDA (análise exploratória): entender os dados antes de modelar — estatísticas descritivas, distribuições (histograma, boxplot), correlações, ausentes e outliers.
- Medidas de posição (média, mediana, moda) e de dispersão (amplitude, variância, desvio-padrão, IQR = Q3 − Q1). Mediana é robusta a outliers; média não.
- Outlier pelo boxplot: abaixo de Q1 − 1,5·IQR ou acima de Q3 + 1,5·IQR.
- Assimetria: cauda à direita (positiva) → média > mediana.
KDD e mineração de dados
- KDD (Fayyad): seleção → pré-processamento → transformação → mineração de dados → interpretação/avaliação. A mineração é uma etapa do KDD.
- Tarefas: classificação e regressão (preditivas, supervisionadas); agrupamento, regras de associação e detecção de anomalias (descritivas).
- Associação (market basket, ex.: Apriori): suporte = frequência do conjunto; confiança = P(B | A); lift > 1 indica associação positiva.
Governança técnica: metadados, catálogo e MDM
- Metadados: técnicos (tipos, esquemas, tabelas), de negócio (definições, glossário) e operacionais (cargas, logs, horários).
- Catálogo de dados: inventário pesquisável dos ativos de dados (o que existe, onde, quem é dono, qualidade). Evita o data swamp.
- Linhagem (lineage): rastreia origem e transformações do dado até o relatório — essencial para auditoria e análise de impacto.
- MDM — Master Data Management: "registro de ouro" (golden record) dos dados mestres (contribuinte, produto, município). Dados de referência: listas de domínio (UF, CFOP, NCM).
- DAMA-DMBOK: referência de gestão de dados com 11 áreas de conhecimento e a governança de dados no centro da "roda".
- Papéis: data owner (dono, responde pelo dado no negócio), data steward (curador, cuida de definições e qualidade), data custodian (custodiante técnico: TI que armazena, protege, faz backup).
Teste rápido
1. Segundo Inmon, o Data Warehouse é orientado por assunto, integrado, volátil e variante no tempo.
Errado. É não volátil: dados carregados não sofrem atualização transacional; são carregados e consultados (TINO).
2. Em um Data Lake, adota-se tipicamente schema-on-read, armazenando os dados em formato bruto.
Certo. O esquema é aplicado na leitura; schema-on-write é característica do DW.
3. No SCD tipo 3, preserva-se o histórico completo inserindo-se uma nova linha com nova chave substituta.
Errado. Isso é o tipo 2. O tipo 3 cria coluna para o valor anterior (histórico limitado).
4. Tabela com valores (10, NULL, 20, 30) na coluna v: COUNT(*), COUNT(v) e AVG(v) retornam, respectivamente:
4, 3 e 20. COUNT(*) conta linhas; COUNT(v) ignora NULL; AVG = 60/3 = 20 (NULL fora do numerador e do denominador).
5. A cláusula HAVING pode ser usada para filtrar linhas antes do agrupamento, substituindo o WHERE com melhor desempenho.
Errado. HAVING filtra grupos, após o GROUP BY. Filtro de linhas é no WHERE (e filtrar cedo costuma ser mais eficiente).
6. No Apache Spark, transformações como filter e select são avaliadas de forma preguiçosa e só executadas quando uma ação, como count, é chamada.
Certo. Lazy evaluation: o Spark monta o DAG e otimiza antes de executar na ação.
7. Na abordagem ELT, os dados são transformados em um servidor intermediário antes de serem carregados no destino.
Errado. Isso descreve ETL. No ELT carrega-se primeiro e transforma-se dentro do destino (DW/Lakehouse).
8. Selecionar no cubo apenas o ano de 2025, mantendo as demais dimensões, é uma operação de:
Slice. Fixar um valor de uma única dimensão. Filtros em várias dimensões = dice.
9. Pelo teorema CAP, havendo partição de rede, um sistema distribuído deve optar entre consistência e disponibilidade.
Certo. Como a tolerância a partição é obrigatória em sistemas distribuídos, a escolha prática é CP ou AP.
10. Bancos NoSQL orientados a grafos são os mais indicados para cache de sessão com acesso por chave.
Errado. Cache/sessão é caso clássico de chave-valor (Redis). Grafo serve para relacionamentos (redes, fraude).
11. Em valores 100, 90, 90, 80 ordenados de forma decrescente, RANK() atribui ao valor 80 a posição 3.
Errado. RANK pula posições após empates: 1, 2, 2, 4. Quem dá 3 é o DENSE_RANK.
12. Uma tabela na 1FN com chave primária formada por uma única coluna pode apresentar dependência parcial, violando a 2FN.
Errado. Dependência parcial só existe quando a chave é composta por mais de um atributo.