Big Data

Folha de revisão · 17 temas · Engenharia de Analytics

Feita para a véspera. Imprimir esta página tira o menu e as abas.

O que é Big Data

É a primeira pergunta de quase toda sabatina e serve de termômetro. Quem responde só 'muitos dados' entrega que decorou; quem separa o problema da ferramenta mostra que entende por que a arquitetura mudou.

Como cai: Todo problema com muitos dados é um problema de Big Data?

Erros comuns

Tratar Big Data como sinônimo de Hadoop ou Spark. Os Vs descrevem o problema; a ferramenta é a resposta, e ela muda com a década.
Achar que volume sozinho define Big Data. Um terabyte parado num arquivo é só um arquivo grande; o que quebra é volume com velocidade e variedade juntos.
Esquecer veracidade e valor. São os dois Vs que ligam a discussão técnica ao negócio, e é neles que a banca separa quem já trabalhou com dado sujo.
Usar arquitetura distribuída onde um Postgres bem indexado resolveria. Custo e complexidade sobem, e a banca pergunta justamente isso.

OLAP, OLTP e ETL

É o tema que separa quem entende arquitetura de quem só escreve SQL. A banca usa a pergunta do relatório no banco transacional para ver se você raciocina sobre lock, contenção e modelo, ou se responde só 'porque é lento'.

Como cai: Por que não fazer o relatório direto no banco transacional?

Erros comuns

Dizer que a diferença é só desempenho. Desempenho é consequência; a causa é propósito diferente, que leva a modelo diferente, carga diferente e garantia diferente.
Achar que OLAP significa obrigatoriamente cubo. Cubo foi a implementação dominante nos anos 2000; hoje OLAP é o tipo de carga, servida por warehouse colunar, lakehouse ou motor MPP.
Confundir normalizado com bom. Terceira forma normal serve para escrever com integridade; para ler agregado ela cobra dezenas de joins por consulta.
Tratar staging como se fosse camada de consumo. Staging é área de pouso, volátil, espelho da origem; quem consulta staging herda o modelo do sistema fonte e todos os defeitos dele.
Esquecer o grão da tabela fato. Sem definir a que corresponde uma linha, a soma duplica e ninguém descobre até o número chegar errado na diretoria.
Responder ETL como 'três scripts'. O que a banca quer ouvir é o processo: extração incremental, tratamento de qualidade, conformação de dimensão e carga idempotente.

Vocabulário

tabela fato: — tabela que guarda os eventos mensuráveis do negócio, com métricas e chaves para as dimensões
tabela dimensão: — tabela que descreve o contexto do evento e fornece filtros e agrupamentos

Data Centric e Data Driven

A banca usa este tema para ver se você enxerga além do pipeline. Engenheiro de dados que só fala de ferramenta não convence; quem liga arquitetura, governança e decisão mostra que entende para que o pipeline existe.

Como cai: Como você tornaria um time data-driven?

Erros comuns

Tratar os dois termos como sinônimo. Centric é arquitetura e propriedade do dado; driven é comportamento na hora de decidir. Dá para ser um sem o outro, e é aí que a banca aperta.
Achar que dashboard resolve. Painel sem métrica acordada, sem confiança no número e sem alguém com poder de decidir vira decoração cara.
Confundir data-driven com decidir só por número. Contexto, risco regulatório e restrição de negócio continuam valendo; data-driven é o dado entrar antes da decisão, não substituir julgamento.
Ignorar acesso. Se o analista espera duas semanas por um chamado para ver o dado, o time decide por intuição e chama de agilidade.
Usar o dado para justificar decisão já tomada. É o erro mais comum e o mais fácil de detectar: o número aparece depois da escolha, não antes.
Separar governança de cultura. Sem catálogo, dono e definição de métrica, cada área traz um número diferente para a mesma pergunta e a discussão morre no 'meu Excel diz outra coisa'.

Hadoop: conceito e arquitetura

Hadoop é o pano de fundo de quase todo conceito de engenharia de dados moderna. A banca pergunta menos 'o que é' e mais 'ainda faz sentido', porque essa é a pergunta que revela se você entende separação de armazenamento e computação.

Como cai: HDFS ainda faz sentido se a empresa está na AWS?

Erros comuns

Dizer que Hadoop é um banco de dados. Hadoop é um framework de armazenamento e processamento distribuído; quem oferece semântica de tabela é o Hive por cima dele.
Confundir HDFS com YARN. HDFS guarda arquivo em blocos replicados; YARN reparte CPU e memória entre aplicações. São responsabilidades separadas desde o Hadoop 2.
Achar que replicação substitui backup. Réplica protege contra falha de disco e de nó; ela copia fielmente o comando de exclusão e a corrupção lógica.
Tratar o NameNode como detalhe. Ele guarda os metadados de todo o sistema de arquivos; sem alta disponibilidade, é ponto único de falha e limita o número de arquivos pequenos.
Dizer que Hadoop morreu. O que perdeu espaço foi o HDFS como camada de armazenamento primária; YARN, Hive e o modelo de processamento distribuído deixaram herança direta no que se usa hoje.
Explicar a queda do Hadoop só por 'Spark é mais rápido'. A razão estrutural é separar armazenamento de computação, o que permite escalar e pagar cada um por conta.

MapReduce

É o exercício clássico de raciocínio distribuído: a banca pede o contador de palavras não para ver se você sabe contar, mas para ver se você identifica shuffle e escrita em disco como os pontos caros, e se sabe explicar por que Spark ganhou.

Como cai: Explique um contador de palavras e diga onde está o gargalo.

Erros comuns

Esquecer o shuffle. Map e reduce são as duas fases que todo mundo cita; o shuffle entre elas é onde o trabalho pesado acontece e é o que a banca quer ouvir.
Dizer que o combiner sempre pode ser usado. Ele só é seguro quando a agregação é associativa e comutativa: soma e máximo sim, média direta não.
Confundir combiner com reducer. O combiner roda no lado do map, sobre a saída parcial daquele mapper, e é opcional — o framework pode chamá-lo zero, uma ou várias vezes.
Achar que a lentidão do MapReduce é da CPU. O custo dominante é I/O: gravar a saída do map em disco, transferir pela rede no shuffle e gravar o resultado de cada job antes do próximo começar.
Explicar que Spark é rápido só porque usa memória. A outra metade é o DAG: o Spark planeja a cadeia inteira e evita materializar resultado intermediário entre estágios.
Ignorar a chave enviesada. Se uma chave concentra a maior parte dos registros, um reducer trabalha sozinho enquanto os outros terminam, e o job fica refém dele.

Processamento batch e stream

É a pergunta de cenário mais frequente da sabatina: dado um caso do banco, batch ou stream? Quem responde 'stream porque é tempo real' entrega que nunca operou um pipeline; quem coloca latência exigida, custo e complexidade lado a lado mostra que já tomou essa decisão.

Como cai: Detecção de fraude em cartão: batch ou stream? Quais os trade-offs?

Erros comuns

Dizer que stream é sempre melhor porque é tempo real. Stream cobra cluster ligado 24 por 7, estado para manter, plantão e reprocessamento difícil. Se a decisão só é tomada no dia seguinte, você pagou por latência que ninguém consome.
Confundir micro-batch com stream evento a evento. Spark Structured Streaming agrupa a chegada em micro-lotes de segundos; Flink processa registro a registro. Isso muda o piso de latência que você pode prometer para o negócio.
Ignorar a diferença entre event time e processing time. Agregar pelo horário de chegada faz a mesma janela dar resultado diferente a cada execução, e em banco isso vira número de fechamento que não bate duas vezes.
Prometer exactly-once como se fosse uma flag. Ponta a ponta ela exige checkpoint, estado durável e destino idempotente ou transacional. Sem controlar o destino, o que você tem é at-least-once com deduplicação.
Esquecer o dado atrasado. Sem watermark o estado cresce sem limite; com watermark curto demais você descarta transação legítima que chegou fora de ordem.
Tratar batch como coisa antiga. Fechamento contábil, reporte regulatório e treino de modelo continuam em batch por bons motivos: lógica simples e resultado reproduzível.

Vocabulário

event time: — O momento em que o fato aconteceu: a hora da compra registrada pela maquininha.
processing time: — O momento em que o motor viu o evento.

ETL e ELT

É a pergunta que separa quem sabe a sigla de quem sabe decidir. A banca não quer ouvir 'no ELT o T vem depois'; quer ouvir por que o mercado migrou, o que se ganha guardando o bruto e em que situação, num banco, você ainda transforma antes de aterrissar.

Como cai: Vocês vão usar ELT no Lakehouse. Quais os riscos disso?

Erros comuns

Resumir a diferença a 'a ordem das letras'. A pergunta real é onde a computação da transformação acontece e o que fica gravado no destino, porque é isso que muda custo, governança e capacidade de reprocessar.
Dizer que ELT é sempre melhor porque é moderno. Sem contrato e sem catálogo, ELT vira despejo de tabela crua que ninguém entende, e o lake vira pântano.
Esquecer que ELT joga o custo para o destino. Transformação pesada no warehouse aparece na fatura de computação todo mês, e não em um servidor de ETL comprado uma vez.
Ignorar LGPD ao defender ELT. Carregar CPF, dado de saúde ou biometria cru na zona bronze cria uma cópia de dado sensível fora do perímetro de controle da origem.
Achar que guardar o bruto é bagunça. O bruto é o que permite recalcular seis anos de indicador quando a regra de negócio muda; sem ele, você depende da origem ainda ter o histórico.
Tratar ETL como legado. Origem que só pode ser lida uma vez, contrato rígido com o consumidor e mascaramento obrigatório antes do pouso continuam pedindo transformação em trânsito.

Particionamento de dados

É onde a banca testa julgamento técnico com número. Todo mundo sabe dizer que particionamento acelera consulta; poucos sabem explicar cardinalidade, small files e hot partition, e menos ainda percebem que particionamento em banco relacional e em data lake são mecanismos diferentes com o mesmo nome.

Como cai: Como você particionaria a tabela de transações de cartão?

Erros comuns

Particionar por uma chave de altíssima cardinalidade, como CPF ou id da transação. Cada partição vira um arquivo minúsculo, e o custo de abrir milhões de arquivos supera qualquer ganho de leitura.
Particionar por uma chave que a consulta não filtra. Se ninguém escreve WHERE naquela coluna, não existe partition pruning e você só criou complexidade.
Ignorar a distribuição real dos valores. Particionar por agência ou por bandeira quando 60 por cento do volume está em um único valor cria hot partition: uma task carrega o job inteiro.
Confundir partição de tabela relacional com pasta no data lake. No relacional é uma estrutura interna do banco com índices e estatísticas; no lake é literalmente um diretório no caminho do arquivo.
Tratar bucketing como sinônimo de particionamento. Bucket distribui por hash em um número fixo de arquivos e serve para join e agregação por chave; partição fisicamente separa e serve para pruning.
Particionar tabela pequena. Abaixo de alguns gigabytes, particionar costuma piorar: você cria arquivos pequenos e sobrecarrega o metastore sem ganhar leitura.

Vocabulário

partition pruning: — Descarte de partições inteiras antes de abrir qualquer arquivo, com base no filtro da consulta.

Spark: introdução

Spark é o motor por trás de quase todo pipeline moderno, incluindo o Databricks que o banco usa. A banca não quer a definição de marketing: quer que você descreva o que cada processo faz e o que acontece de verdade entre a linha de código e o resultado.

Como cai: O que acontece quando você chama .count()?

Erros comuns

Dizer que Spark é rápido porque 'roda em memória', sem explicar o quê. O ganho é não gravar o resultado intermediário de cada etapa em disco, como o MapReduce fazia entre map e reduce.
Achar que Spark carrega a base inteira na RAM. Ele processa por partição e derrama para disco quando não cabe; memória é otimização, não requisito.
Confundir driver com nó mestre do cluster. O driver é o processo da sua aplicação, que monta o plano e agenda tasks; o cluster manager é quem aloca recursos, e pode ser YARN, Kubernetes ou o standalone.
Não saber dizer o que uma transformação faz. Transformação não executa nada: ela acrescenta um nó ao plano. Só a ação dispara execução.
Trazer resultado para o driver sem pensar. collect() puxa todas as partições para a memória de um único processo, e é assim que se derruba o driver com uma tabela de bilhões de linhas.
Não relacionar shuffle com stage. A fronteira de stage é definida pelo shuffle: enquanto os dados não precisam ser redistribuídos entre executores, tudo cabe no mesmo stage.

Vocabulário

transformação: — Operação que devolve outro conjunto distribuído e apenas acrescenta um nó ao plano: filter, select, join, groupBy.
ação: — Operação que devolve um valor ao driver ou escreve num destino, e por isso dispara a execução: count, collect, show, write.
shuffle: — Redistribuição de dados entre executores, necessária quando a mesma chave precisa terminar no mesmo lugar.

Spark: RDD, transformações e ações

A ementa oficial ainda apresenta o Spark pela API de RDD, então a pergunta vem nesse vocabulário. Quem só decora a definição de 2014 tropeça na pergunta seguinte, que é por que hoje ninguém escreve RDD. Dominar os dois lados é o que mostra atualização.

Como cai: Quando você ainda usaria RDD em vez de DataFrame?

Erros comuns

Dizer que RDD é o mesmo que DataFrame com outro nome. DataFrame tem esquema e passa pelo otimizador Catalyst; RDD é opaco para o otimizador, que não sabe o que a sua função faz.
Achar que RDD é mutável. Toda transformação cria um novo RDD; a imutabilidade é o que torna a recomputação por lineage possível.
Confundir narrow com barato e wide com caro sem saber por quê. A diferença é a dependência: em narrow cada partição de saída depende de uma partição de entrada; em wide depende de várias, e por isso o dado precisa atravessar a rede.
Classificar reduceByKey como narrow porque 'reduz'. Toda operação por chave que precisa juntar chaves iguais é wide.
Achar que tolerância a falhas em Spark é replicação. É recomputação: com o lineage e a origem, o Spark refaz só as partições perdidas.
Recomendar RDD hoje sem justificativa. A resposta esperada é DataFrame e Spark SQL por padrão, com RDD reservado a controle fino e dado sem esquema.

Vocabulário

dependência narrow: — Cada partição de saída depende de no máximo uma partição de entrada.
dependência wide: — Uma partição de saída depende de várias partições de entrada, porque a mesma chave precisa se reunir num lugar só.

As zonas de um Data Lake

É o tema que testa se você pensa em governança, e não só em pipeline. A banca usa as zonas para puxar retenção, controle de acesso e LGPD na mesma pergunta. Quem sabe só os nomes das camadas trava na primeira repergunta.

Como cai: Dado pessoal pode ficar na zona raw do lake?

Erros comuns

Decorar os nomes das zonas sem saber o que cada uma garante. A banca não quer a lista; quer saber que contrato a zona oferece a quem lê dela.
Tratar zona como pasta. Zona é pasta mais retenção, mais permissão, mais schema esperado, mais dono. Sem isso é só um diretório com nome bonito.
Dizer que dado pessoal não pode entrar na raw. Pode, e normalmente entra, porque a raw é cópia fiel da origem; o que muda é criptografia, restrição de acesso e prazo de retenção.
Transformar dado na raw. Se você limpa na raw, perde a capacidade de reprocessar quando descobrir que a regra de limpeza estava errada.
Achar que medalhão e zonas são coisas diferentes e incompatíveis. São vocabulários distintos para o mesmo escalonamento de confiança; saber traduzir um no outro é o que a banca cobra.
Deixar a refined virar depósito de tabela de projeto. Sem dono e sem contrato, a camada de consumo vira o novo pântano.

Vocabulário

tokenização: — Substituição do valor sensível por um substituto sem significado, reversível apenas por quem tem acesso ao cofre de tokens.

Source of Record vs Source of Truth

É o tema que separa a sabatina de Analytics da de Dados. A banca não quer saber se você conhece o termo; quer ver se, diante de dois números diferentes para o mesmo KPI, você sabe qual é o oficial, por que os dois existem e como reconciliar sem inventar um terceiro.

Como cai: O saldo do cliente aparece diferente no core bancário e no dashboard da diretoria. Qual está certo, e o que você faz?

Erros comuns

Achar que Source of Truth é 'o sistema mais importante'. Não é hierarquia de prestígio: é a fonte declarada como oficial para uma decisão específica, e ela pode mudar de um KPI para outro.
Tratar os dois como sinônimos. O Source of Record é autoritativo sobre o fato bruto no momento em que ele aconteceu; o Source of Truth é autoritativo sobre a versão consolidada, tratada e governada. Um extrato do core e o saldo no DW são coisas diferentes por desenho.
Resolver a divergência escolhendo o número que agrada. Sem regra de precedência escrita, cada área elege o próprio relatório como verdade e a reunião vira disputa.
Copiar o Source of Record para o Source of Truth sem transformar nada. Se o DW é uma cópia crua do core, ele herda toda inconsistência de origem e não acrescenta governança nenhuma; virou só um backup caro.
Ignorar o tempo. Boa parte das divergências é defasagem: o core já processou a transação e o lake só recebe o lote à noite. Sem carimbo de corte, os números são incomparáveis, não errados.
Prometer um único Source of Truth para tudo. Sistemas grandes têm vários, um por domínio: cliente, contrato, transação. O que precisa ser único é a regra de qual vale para cada pergunta.

Vocabulário

Source of Record: — O sistema autoritativo sobre o fato no momento em que ele acontece: o core bancário para a transação, o CRM para o cadastro, o sistema de crédito para o contrato.
Source of Truth: — A visão consolidada, tratada e governada que a organização usa para decidir: a tabela certificada de onde sai o KPI, com dono, definição escrita e regra de cálculo.
reconciliação: — O processo que compara a origem com a visão consolidada, explica cada diferença e prova que o número oficial fecha com o fato.

Classificação de tipos de dados

É pergunta de abertura fácil de responder mal. Quem lista os três tipos e para aí perde a repergunta, que é sempre 'e o que muda na prática?'. A resposta forte liga classificação a armazenamento, modelagem, cálculo permitido e controle de acesso.

Como cai: Como você armazenaria e consultaria um dado semiestruturado?

Erros comuns

Chamar JSON e XML de dados não estruturados. Eles são semiestruturados: não têm tabela fixa, mas carregam a própria estrutura em tags e chaves, e é justamente isso que permite consultá-los.
Confundir tipo de dado do banco com natureza da variável. CPF é armazenado como texto ou número, mas é qualitativo nominal: somar, tirar média ou ordenar não produz informação.
Achar que dado não estruturado não pode ser analisado. Pode, depois de virar representação estruturada: transcrição de áudio, texto extraído de PDF, embedding de imagem.
Ignorar a classificação por sensibilidade. Em banco, saber que um campo é dado pessoal muda zona, criptografia, mascaramento e retenção; sem isso o desenho técnico está incompleto.
Tratar ordinal como quantitativo. Rating de crédito de A a E tem ordem, mas a distância entre A e B não é comparável à distância entre D e E, então média não significa nada.
Guardar tudo como texto para 'não dar problema'. Perde-se validação, compressão colunar, poda de partição e a chance de o motor pular arquivos pela estatística.

Vocabulário

dado pessoal sensível: — Dado sobre origem racial ou étnica, convicção religiosa, opinião política, filiação sindical ou a organização religiosa, filosófica ou política, saúde, vida sexual, além de dado genético ou biométrico ligado a uma pessoa natural.

XML

Cai como pergunta de realidade, não de teoria: o banco tem integração legada e obrigação fiscal em XML. Quem responde 'XML é coisa antiga' mostra que nunca abriu um arquivo de retorno; quem cita nota fiscal e mensageria mostra que conhece o terreno.

Como cai: Onde você ainda encontraria XML dentro de um banco hoje?

Erros comuns

Dizer que XML é dado não estruturado. É semiestruturado: a estrutura vem nas próprias tags, e é isso que permite validar e consultar por campo.
Confundir elemento com atributo. Elemento é o nó que carrega conteúdo e pode ter filhos; atributo é um par nome e valor dentro da tag de abertura, sem filhos. Muita integração antiga usa atributo onde hoje se usaria campo.
Ignorar namespace. Arquivo fiscal e de mensageria financeira declaram namespace, e um parser configurado sem ele simplesmente não acha os nós.
Achar que XML morreu. Perdeu espaço em API nova, mas segue obrigatório em documento fiscal eletrônico e presente em padrões de mensageria financeira.
Ler XML linha a linha com expressão regular. XML é hierárquico e permite aninhamento arbitrário; parser de verdade ou leitor nativo do Spark, nunca regex.

Vocabulário

XSD: — XML Schema Definition: o arquivo que declara a estrutura esperada do documento, com tipos e obrigatoriedade, permitindo rejeitar o que não obedece.

JSON

Praticamente toda ingestão de evento no banco chega em JSON: autorização de cartão, evento de app, resposta de API interna. A banca usa o tema para chegar em evolução de schema, que é o problema que mais quebra pipeline em produção.

Como cai: Como você trata um JSON cujo schema muda sem aviso?

Erros comuns

Deixar o Spark inferir o schema em produção. Inferência custa uma passada extra pelos dados e, pior, muda de resultado quando a amostra muda: o mesmo pipeline entrega tipos diferentes em dias diferentes.
Guardar JSON cru na camada analítica. Ler JSON é caro: parsing linha a linha, sem compressão colunar, sem estatística por arquivo e sem data skipping. Cru é para a raw; a trusted é colunar.
Confundir array com struct. Struct vira colunas aninhadas e se resolve com seleção por caminho; array precisa de explode e multiplica linhas, o que muda a granularidade da tabela.
Tratar campo novo como incidente. Campo novo é o comportamento normal de um produtor de eventos; o pipeline precisa ter uma política para isso antes de acontecer.
Achar que JSON Lines é um formato diferente de JSON. É a convenção de um objeto JSON completo por linha, que é o que permite ler o arquivo em paralelo e por pedaços.
Deixar o campo aninhado inteiro como string para 'resolver depois'. Depois vira nunca, e o consumidor acaba parseando string em SQL, que é o pior lugar para fazer isso.

Vocabulário

coluna de dado resgatado: — Coluna onde o leitor guarda os campos que não batem com o schema declarado, para que nada se perca e a mudança de origem fique registrada.

Governança de dados

A banca usa governança para separar quem só constrói pipeline de quem entende que dado é ativo com dono. Em banco, cada resposta esbarra em LGPD, auditoria e regulador, e o entrevistador quer ver você citar papel e processo, não só ferramenta.

Como cai: Quem responde por um dado errado no relatório da diretoria?

Erros comuns

Confundir governança com segurança da informação. Segurança protege o dado de quem não deve ver; governança define quem deve ver, para quê, por quanto tempo e quem responde pelo significado do dado.
Dizer que o dono do dado é o time de engenharia. Engenharia é custodiante: opera o pipeline e o armazenamento. O dono é da área de negócio que define a regra e responde pelo número.
Tratar catálogo como inventário técnico de tabelas. Sem dono, definição de negócio, classificação e linhagem, o catálogo vira lista de nomes e ninguém usa.
Achar que linhagem serve só para bonito no diagrama. Linhagem é o que responde 'o que quebra se eu mudar esta coluna' e 'de onde veio este número' numa auditoria.
Prometer governança centralizada num banco grande. Um comitê único vira gargalo; o padrão que escala é federado, com política central e execução no domínio.
Falar de LGPD só como consentimento. Consentimento é uma das bases legais; em banco a maior parte do tratamento se apoia em obrigação legal, execução de contrato ou legítimo interesse.

Vocabulário

catálogo de dados: — Inventário pesquisável de conjuntos de dados com dono, definição de negócio, classificação de sensibilidade, linhagem e forma de pedir acesso.

Qualidade de dados

Toda banca de engenharia de dados pergunta como você garante qualidade, porque é onde se separa quem escreve pipeline de quem opera pipeline em produção. Em banco, dado ruim vira número errado para o regulador, e o entrevistador quer ouvir teste, limiar e decisão de falha.

Como cai: Como você garantiria qualidade num pipeline diário de transações?

Erros comuns

Listar as dimensões sem dizer como se mede cada uma. Citar 'acurácia' não vale ponto; dizer que se mede confrontando uma amostra com o sistema de origem, vale.
Achar que todo teste que falha deve derrubar o pipeline. Derrubar tudo por um domínio inesperado numa coluna secundária custa mais que quarentenar a linha.
Confundir completude com acurácia. Campo preenchido com valor errado é completo e impreciso; campo vazio é incompleto e pode até ser correto.
Ignorar frescor. Dado certo que chega depois da decisão é dado inútil, e é a dimensão que mais gera reclamação em painel de diretoria.
Medir qualidade só na camada final. Quanto mais tarde o teste, mais caro o reprocessamento; teste na ingestão pega o problema antes de ele se espalhar.
Tratar SLA de dados como promessa verbal. Sem número, janela e consequência acordada, não existe SLA, existe expectativa.

Vocabulário

SLO de dados: — Meta interna e mensurável sobre um dado: por exemplo, a tabela de transações fica pronta até 6h em 99% dos dias úteis.