10 arquiteturas de dados, analytics e BI conversacional
- ⬜🧭 10 arquiteturas de copiloto interno e produtividade(100 Arquiteturas de IA na AWS)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O que une estas dez arquiteturas
Aqui a IA entra num sistema que já tinha regras próprias — e a regra mais dura é que o modelo não adivinha o significado da coluna. Catálogo bem descrito rende mais que instrução elaborada: uma coluna chamada `dt_ref` com a descrição "data de competência contábil, não a data do lançamento" muda a consulta gerada; a mesma coluna sem descrição gera um número errado com aparência de certo.
A segunda regra é de divisão de trabalho. Previsão e detecção de anomalia são tarefas de modelo tabular, não de modelo de linguagem; o modelo de linguagem entra na explicação do desvio, na geração da consulta e na descrição do metadado. Confundir os dois papéis produz previsão ruim e explicação desnecessária.
| # | Problema | A decisão que transfere |
|---|---|---|
| 51 | Pergunta de negócio que exige SQL | Catálogo bem descrito rende mais que prompt elaborado: o modelo não adivinha o significado da coluna |
| 52 | Painel que ninguém consulta porque a pergunta muda | Explicar a consulta gerada é o que dá confiança para o usuário aceitar o número |
| 53 | Custo de consulta gerada sem controle | Formato colunar com particionamento corta o dado varrido em ordem de magnitude — é a otimização de maior retorno |
| 54 | Qualidade de dado que quebra o relatório | Testar só no fim descobre o problema depois de propagado por todas as transformações |
| 55 | Enriquecimento de acervo existente com classificação | Lote custa cerca de metade e entrega em janela de horas: serve para tudo sem usuário na frente |
| 56 | Detecção de anomalia em série temporal | Previsão é tarefa de modelo tabular; o modelo de linguagem entra na explicação, não no cálculo |
| 57 | Catálogo de dado sem descrição utilizável | Metadado gerado sem revisão propaga erro para toda consulta que confia nele |
| 58 | Mudança de esquema que quebra o consumidor | Viagem no tempo é o recurso que mais salva em incidente de pipeline |
| 59 | Captura de mudança do banco operacional para o analítico | A retenção do registro é o risco: consumidor parado tempo suficiente exige recarga completa |
| 60 | Dado sensível no acervo analítico | O que não entra no acervo não vaza por consulta nenhuma |
51. Pergunta de negócio que exige SQL
"Quanto vendemos de assinatura recorrente no Nordeste no trimestre?" exige saber que `tipo_rec = 2` significa recorrente e que a região vem de uma tabela de dimensão. O modelo não tem como adivinhar isso — e quando adivinha, devolve um número plausível e errado.
- → esquema descrito
- → termo de negócio
- → pergunta de negócio
- → SQL proposto
- → SQL dentro do teto
- → número + consulta
- Analytics
- Fora da AWS
- IA e machine learning
- Conceito de arquitetura
O modelo não adivinha o significado da coluna nem a definição de negócio: catálogo descrito e glossário no contexto valem mais que qualquer refinamento de instrução. A contenção de custo é a partição obrigatória.
- Descrição de coluna é o insumo de maior retorno. Nome de coluna quase nunca diz o significado. Investir uma semana em descrever colunas rende mais que meses ajustando a instrução.
- Valor de domínio no contexto. `tipo_rec = 2` só é traduzível se o catálogo disser o que 2 significa. Sem isso o modelo inventa o filtro — e o número sai plausível.
- Termo de negócio é ambíguo por natureza. "Receita recorrente" tem definição na empresa, e ela não está no esquema. O glossário é o que impede cada consulta usar uma definição diferente.
- Partição obrigatória na consulta. Consulta sem filtro de partição varre o histórico inteiro. Exigir a partição é a contenção de custo mais eficaz — e ela é verificável antes de executar.
- Limite por consulta, não por dia. Cota diária permite uma consulta destruir a cota de todos. O teto por consulta isola o dano.
52. Painel que ninguém consulta porque a pergunta muda
O painel responde as dez perguntas de quando foi construído, e a décima primeira exige um pedido ao time de dados com duas semanas de espera. A camada conversacional resolve a flexibilidade e cria outro problema: por que confiar num número que apareceu do nada?
- → pergunta nova
- → consulta
- → resultado
- → a consulta que rodou
- → o que foi contado
- → tabelas usadas
- → número + como cheguei
- → virou recorrente? fixa no painel
- Fora da AWS
- IA e machine learning
- Conceito de arquitetura
- Analytics
A flexibilidade da camada conversacional só é aproveitada se o número vier com procedência: consulta exibida, explicação em prosa e linhagem. E pergunta que se repete deve virar painel — a conversa é para a cauda longa.
- Número sem procedência não é usado. Quem vai levar o dado à reunião precisa poder defender como ele foi obtido. Sem isso, o analista refaz no Excel — e a camada conversacional não é adotada.
- Explicação em prosa, não só o SQL. Quem faz a pergunta muitas vezes não lê SQL. "Contei pedidos com status pago entre janeiro e março" é auditável por quem conhece o negócio.
- Linhagem responde a pergunta seguinte. "Essa tabela é atualizada quando?" vem sempre depois do número. Ter a linhagem ali encurta a segunda conversa.
- Pergunta recorrente vira painel fixo. Se a mesma pergunta aparece toda semana, gerar a consulta de novo é desperdício. A camada conversacional serve à cauda longa, não ao recorrente.
- O painel não morre — ele muda de papel. Ele passa a servir o que é estável e monitorado. A conversa cobre a pergunta que ninguém previu, que é onde o painel sempre falhou.
53. Custo de consulta gerada sem controle
A primeira fatura depois de abrir o BI conversacional veio dez vezes maior. A causa não foi o modelo: foram consultas geradas varrendo terabytes porque a tabela estava em CSV, sem partição, e qualquer filtro lia tudo.
- → conversão
- → partições a registrar
- → plano com poda de partição
- → recusa acima do teto
- → dado varrido por consulta
- → linha de base
- Armazenamento
- Analytics
- Conceito de arquitetura
- Gestão e governança
O custo de consulta gerada é dominado pelo dado varrido, e o dado varrido é decidido no formato e no particionamento — antes de qualquer prompt. É a otimização de maior retorno em BI conversacional.
- Colunar lê só as colunas pedidas. Consulta que usa 3 de 60 colunas lê 5% do dado. Em CSV, lê 100% — e essa diferença é a maior alavanca desta arquitetura.
- Partição elimina arquivo inteiro da leitura. Filtro por mês em tabela particionada por mês não abre os outros onze. Sem partição, o filtro é aplicado depois de ler tudo.
- O teto por consulta é a rede de segurança. Otimizar o formato reduz o custo típico; o teto impede o caso patológico. São proteções diferentes e as duas são necessárias.
- A partição precisa estar no catálogo. Partição no caminho do arquivo sem registro no catálogo não é usada pelo planejador — e a economia não acontece.
- Medir custo por consulta, não total. O total sobe com o uso, que é bom. Custo por consulta caindo é o que mostra que a otimização funcionou.
54. Qualidade de dado que quebra o relatório
O relatório do diretor mostrou receita 30% menor, e a causa foi uma carga parcial três etapas antes. Entre a origem do defeito e a descoberta houve quatro transformações — e todas rodaram silenciosamente sobre dado errado.
- → antes de tratar
- → passou
- → antes de agregar
- → passou
- → antes de publicar
- → falhou
- → falhou
- → falhou
- Conceito de arquitetura
Teste na fronteira de cada camada mantém a distância entre defeito e sintoma em uma transformação. E interromper é a decisão certa: dado desatualizado é problema conhecido, dado errado atualizado é decisão tomada errado.
- Teste na fronteira de cada etapa. É o que limita a distância entre causa e sintoma a uma transformação. Teste só no fim transforma investigação de minutos em investigação de dias.
- Volume é o teste que pega carga parcial. É o defeito mais comum e o mais silencioso: o pipeline conclui com sucesso sobre metade do dado. Comparar com a série histórica pega isso.
- Interromper é melhor que propagar. Relatório desatualizado é um problema conhecido. Relatório atualizado com dado errado é um problema que ninguém vê — e alguém decide com base nele.
- Chave duplicada é o que estraga agregado. Soma dobra sem quebrar nada. Teste de unicidade na camada tratada é barato e pega o caso que mais gera reunião.
- Órfão precisa falhar, não virar zero. Junção que não encontra o par produz nulo, que soma como zero. Verificar integridade transforma isso em erro visível.
55. Enriquecimento de acervo existente com classificação
Há dois milhões de registros históricos sem categoria, e categorizar melhora busca, relatório e recomendação. Ninguém está esperando por nenhum registro específico — e essa única característica muda o custo do projeto pela metade.
- → dois milhões de registros
- → divide em fatias
- → fatias em paralelo
- → classificação + versão do modelo
- → partições novas
- → esquema para consultar
- → retoma da fatia que falhou
- Armazenamento
- Integração de apps
- Compute
- Conceito de arquitetura
- Analytics
Onde ninguém espera, o lote é a escolha correta — cerca de metade do preço com entrega em horas. O trabalho de engenharia é fatiar com retomada e calibrar o paralelismo pela cota do modelo.
- Ausência de usuário na frente é o requisito que libera o lote. Não é otimização: é reconhecer que a latência não é requisito. Sob demanda aqui seria pagar o dobro por urgência inexistente.
- Dividir em fatias com retomada. Um trabalho de dois milhões vai falhar no meio. Sem fatia e sem marca de progresso, a falha custa o trabalho inteiro.
- Paralelismo controlado, não máximo. Empurrar o máximo esbarra na cota do modelo e derruba tudo. O paralelismo é calibrado pela cota, não pela vontade.
- Saída em formato consultável. Enriquecer e gravar JSON solto obriga um segundo projeto para usar. Parquet particionado com catálogo é consultável no mesmo dia.
- Reprocessar é parte do plano. O modelo melhora e a taxonomia muda. Guardar a versão que classificou cada registro é o que permite reprocessar só o necessário.
O BI conversacional gera consultas erradas sobre uma tabela financeira. Qual investimento rende mais?
56. Detecção de anomalia em série temporal
Alguém sugeriu usar o modelo de linguagem para prever a série e apontar anomalia. Ele produz números plausíveis e erra sistematicamente, porque previsão numérica não é a tarefa dele — e o intervalo de confiança, que é o que importa, ele não produz.
- → métrica por minuto
- → esperado vs. observado
- → anomalia detectada
- → o que aconteceu por volta
- → desvio + hipótese
- Analytics
- IA e machine learning
- Conceito de arquitetura
Previsão e detecção são tarefas de modelo tabular, com intervalo de confiança; o modelo de linguagem entra na explicação do desvio. Trocar os papéis produz previsão ruim sem critério objetivo de anomalia.
- Cada modelo na tarefa dele. O tabular prevê e entrega intervalo de confiança. O de linguagem não entrega intervalo — e sem intervalo não existe critério objetivo de anomalia.
- A detecção é aritmética, não julgamento. Fora do intervalo é anomalia. Determinístico, reproduzível e auditável — três propriedades que a geração não oferece.
- A explicação é onde o modelo de linguagem ganha. Juntar implantação, campanha e feriado com o desvio produz a hipótese que o plantonista usaria dez minutos para montar.
- Hipótese é hipótese, e precisa ser dita como tal. A explicação não é diagnóstico. Apresentá-la como causa confirmada faz o plantonista parar de investigar no lugar errado.
- Alerta com número e hipótese. "Vendas 22% abaixo do esperado; houve implantação às 14h02" é acionável. "Anomalia detectada" gera uma investigação do zero.
57. Catálogo de dado sem descrição utilizável
São 4.000 colunas sem descrição, e é por isso que o BI conversacional gera consulta errada. Gerar as descrições automaticamente resolve a escala — e cria um risco novo: descrição errada é pior que descrição ausente, porque ninguém desconfia dela.
- → valores de exemplo
- → origem da coluna
- → descrição + confiança
- → baixa confiança primeiro
- → aprovado
- → nunca direto
- Conceito de arquitetura
- IA e machine learning
- Fora da AWS
- Analytics
Descrição de coluna é insumo de toda consulta gerada, e por isso metadado errado se multiplica. Gerar com evidência resolve a escala; aprovação pelo dono do domínio é o que impede oficializar suposição.
- Evidência antes de geração. Amostra de valores, cardinalidade e linhagem. Sem isso, a descrição sai do nome da coluna — que é exatamente a informação insuficiente que originou o problema.
- Descrição aprovada, nunca publicada direto. Metadado errado se propaga para toda consulta gerada e para todo relatório construído sobre ela. É erro que se multiplica silenciosamente.
- Ordenar a fila pela confiança. As colunas óbvias podem ser aprovadas em lote; as siglas opacas precisam de atenção. Ordenar por confiança concentra o tempo humano onde ele rende.
- O dono do domínio é quem sabe. Descrição de coluna financeira aprovada por engenheiro de dados vira suposição oficializada. Roteie por domínio.
- Aprovação em lote com amostragem para o óbvio. Exigir revisão individual de 4.000 colunas garante que o projeto não termine. Lote com amostragem é o que faz caber.
58. Mudança de esquema que quebra o consumidor
Alguém acrescentou uma coluna e renomeou outra, e sete painéis pararam de funcionar às 8h de segunda. Pior: a carga já sobrescreveu a versão anterior, e não há como comparar com o que existia antes.
- → arquivos + metadado de versão
- → valida a mudança
- → o que o consumidor espera
- → qualquer versão
- → se a nova está errada
- → ponteiro anterior
- Analytics
- Armazenamento
- Conceito de arquitetura
Formato de tabela com histórico transforma incidente de pipeline de horas em minutos: comparar versões localiza a mudança e reverter é mover um ponteiro. A regra de evolução é a assimetria entre acrescentar e renomear.
- Acrescentar é seguro; renomear e apagar não são. Coluna nova não quebra consumidor que não a conhece. Renomear quebra todos. A regra de evolução é essa assimetria escrita.
- Contrato de dado é o que torna a regra exigível. Sem declarar o que o consumidor pode esperar, toda mudança é negociação. Com contrato, a validação é automática.
- Viagem no tempo responde "o que mudou?". Comparar a versão de hoje com a de ontem localiza a mudança em minutos. Sem histórico, a investigação começa por reconstruir o passado.
- Reverter é mudar ponteiro, não recarregar. A reversão é imediata e não depende de a origem ainda ter o dado. É o que transforma incidente de horas em incidente de minutos.
- O histórico tem custo, e ele é escolhido. Guardar versões custa armazenamento. A política de expiração é decisão explícita — e ela precisa cobrir a janela de investigação típica.
59. Captura de mudança do operacional para o analítico
O analítico precisa refletir o operacional em minutos, e consultar a tabela inteira a cada ciclo pressiona o banco de produção. A captura de mudança resolve isso — e introduz um risco novo, que quase ninguém dimensiona no desenho.
- → transações confirmadas
- → lê o registro, não a tabela
- → eventos de mudança
- → inserção, alteração e exclusão
- → atraso em segundos
- → se passar da retenção: recarga
- Banco de dados
- Conceito de arquitetura
- Analytics
- Integração de apps
- Armazenamento
Captura de mudança tira a pressão do banco operacional e coloca um risco novo: a retenção do registro é o tempo máximo que o consumidor pode ficar parado. Passar disso significa recarga completa.
- Ler o registro, não a tabela. A captura não consulta a tabela: ela lê o registro de transações. É o que elimina a pressão no banco operacional.
- A retenção do registro é o teto de tolerância a falha. Se o consumidor ficar parado além da retenção, o registro necessário foi descartado — e a única saída é recarga completa. Esse número precisa ser conhecido.
- Defasagem é o alarme, não erro. A captura pode parar sem lançar exceção. O sintoma é a defasagem crescendo, e o alarme precisa ser sobre ela.
- A fila durável desacopla os ritmos. O destino pode ficar indisponível sem que a captura pare. Sem fila, uma manutenção no analítico consome a retenção do registro.
- Exclusão também é evento. Pipeline que só aplica inserção e alteração deixa registro apagado vivo no analítico. É a divergência mais difícil de descobrir depois.
60. Dado sensível no acervo analítico
O acervo analítico recebeu uma tabela com CPF e endereço, e a partir daí toda consulta gerada, todo painel e todo exportação passaram a ser um risco. Controlar quem consulta é tratamento; o problema estava na ingestão.
- → onde há dado pessoal
- → o que mascarar
- → quando precisa juntar
- → coluna mascarada e original
- → por papel
- → audita o que escapou
- Segurança e identidade
- Conceito de arquitetura
- Compute
- Analytics
Dado pessoal se resolve na fronteira de ingestão: o que não entra não vaza por consulta, exportação, registro nem cache. Permissão por coluna atende a exceção legítima sem duplicar a tabela.
- Mascarar na ingestão, não na consulta. O que não entra não vaza — por consulta, por exportação, por registro nem por cache. Filtrar na leitura deixa o dado presente em todos esses lugares.
- Pseudonimizar preserva a junção. A análise geralmente precisa juntar por pessoa, não saber quem é a pessoa. Identificador estável e irreversível atende os dois requisitos.
- A descoberta é contínua. Fonte nova entra toda semana e traz campo que ninguém declarou. Varredura periódica é o que mantém a classificação viva.
- Permissão por coluna para a exceção legítima. Alguns papéis precisam do original. Permissão em nível de coluna atende sem duplicar a tabela em duas versões.
- O padrão é o mascarado. Quem consulta sem papel específico vê a versão sem dado pessoal. Padrão seguro é o que faz o esquecimento não custar caro.
Perguntas frequentes
❓ Como fazer texto-para-SQL funcionar de verdade em produção?
❓ Como reduzir o custo de um BI conversacional na AWS?
❓ Devo usar um modelo de linguagem para detectar anomalia em série temporal?
Fixando
Um pipeline de dados de quatro etapas produziu relatório errado. Onde os testes de qualidade devem ficar?
Uma captura de mudança (CDC) ficou parada por 36 horas durante uma manutenção. Qual é o risco principal?
Próximo passo
A próxima família de arquiteturas é **Conteúdo, mídia e personalização** — mesma estrutura: dez soluções, cada uma com o desenho completo e a decisão que ela transfere. Se o que falta é praticar em vez de ler — nenhum destes desenhos tem código, de propósito, porque quem constrói é a trilha 100 Laboratórios de Arquitetura AWS —, comece por um laboratório da família equivalente.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…