O caso
Vendas que ninguém consegue somar. O relatório do mês trava a loja.
O Isaac quer saber quanto a loja vendeu por região nos últimos três anos. A pergunta parece simples, mas o pedido está no banco que atende os clientes. Quando alguém roda a consulta, a finalização de compra fica lenta, e o contador recebe uma planilha que ninguém confere.
Enquanto isso, o time de marketing quer saber em que páginas do site as pessoas estão antes de comprar. Esses cliques não estão em lugar nenhum.
Este post parte de Bancos de Dados na Nuvem e de Armazenamento na Nuvem. Lá a pergunta era onde guardar o dado. Aqui ela muda: o que fazer com ele depois de guardado.
O problema
Dois tipos de trabalho num mesmo banco
Atender a loja e analisar a loja são trabalhos diferentes:
- Atender é gravar e ler poucas linhas, muitas vezes por segundo, sem erro. Um pedido não pode ficar pela metade.
- Analisar é ler milhões de linhas para responder uma pergunta, uma vez ou algumas vezes por dia.
A solução
Três formatos de dado
Antes de escolher o serviço, é preciso saber a forma do dado:
Estruturado (structured)
Linhas e colunas com um formato fixo: pedidos, itens, estoque.
Na loja: cada pedido tem sempre data, cliente, valor e status.
Semiestruturado (semi-structured)
Chave e valor, ou documentos (como JSON), em que cada registro pode ter campos diferentes.
Na loja: o carrinho de cada cliente, com itens e opções que mudam de produto para produto.
Não estruturado (unstructured)
Arquivos sem uma tabela por dentro: imagens, PDFs, áudios.
Na loja: as fotos dos produtos e as notas fiscais em PDF.
O formato guia a escolha: o dado estruturado vai para um banco relacional, o semiestruturado para um banco de documentos e o não estruturado para o Cloud Storage.
Não confunda
Transação × análise
Transacional (OLTP)
“Como o pedido entra na loja?”
- Exemplo
- Um cliente finaliza o carrinho: a compra, o estoque e o pagamento são gravados em milissegundos.
- Foco
- Muitas operações pequenas, ao mesmo tempo, sem perder nenhuma. Serviços: Cloud SQL e Spanner.
Analítico (OLAP)
“Quanto vendemos por região nos últimos três anos?”
- Exemplo
- Uma consulta lê milhões de linhas, mas só três colunas: região, data e valor.
- Foco
- Poucas consultas, mas enormes, sobre muitos dados. Serviço: BigQuery.
A diferença aparece no jeito de guardar. O banco transacional guarda cada linha junta, o que ajuda a gravar e a ler um pedido inteiro de uma vez. O analítico guarda cada coluna junta, o que permite ler só a coluna da pergunta e comprimir bem os dados repetidos, como o nome das regiões.
Por baixo
Do clique ao relatório
Os cliques do site não vão direto para o relatório. Passam por um caminho:
- Coleta: o site publica cada clique no Pub/Sub. Quem publica não espera ninguém processar: se o processamento estiver lento, o site segue no ar e as mensagens esperam na fila.
- Transformação: o Dataflow lê as mensagens, descarta o que não interessa (um robô de busca, por exemplo) e agrega por minuto.
- Armazenamento para análise: o resultado vai para o BigQuery, onde as perguntas do marketing são feitas.
Esse caminho é de streaming: o dado é processado à medida que chega. Já a exportação noturna dos pedidos é em lote (batch): um bloco de dados é processado de uma vez, e o mesmo Dataflow serve para os dois casos.
Para séries temporais com volume muito grande, lidas por chave, o Bigtable é outra opção. Para perguntas que mudam a cada dia, o BigQuery é a escolha.
A solução completa
O lago e a governança
Nem todo dado precisa ser organizado antes de ser guardado. Um data lake é um repositório de dados brutos, em formatos variados, guardado no Cloud Storage porque é barato e durável. Os dados entram como estão e são tratados depois, quando alguém precisa deles.
O risco é transformar o lago num depósito sem dono. A governança responde perguntas simples: quem é responsável por cada conjunto de dados, quem pode ler, se o dado está correto. No Google Cloud, o Dataplex Universal Catalog organiza lago e warehouse num painel só, aplicando as mesmas regras de acesso e um catálogo para encontrar os dados.
Na prática
Onde fica cada dado da loja
| Dado | Onde fica | Por quê |
|---|---|---|
| Pedidos da loja | Cloud SQL | Transações com consistência, em milissegundos |
| Carrinho de cada cliente | Firestore | Os campos mudam de produto para produto |
| Fotos e notas fiscais em PDF | Cloud Storage | Arquivos grandes, baratos e duráveis |
| Cliques no site | Pub/Sub, Dataflow e BigQuery | Eventos em tempo quase real, filtrados e agregados |
| Vendas por região | BigQuery | Consultas sobre muitos dados, sem tocar na loja |
Termos-chave
Cinco termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
Um relatório precisa somar as vendas de cinco anos, por região, lendo milhões de linhas. Qual serviço fica melhor?
02
Onde guardar as fotos dos produtos e as notas fiscais em PDF?
03
Os cliques do site devem chegar ao relatório quase em tempo real, sem que o site espere o processamento. Qual combinação faz isso?
Cada pergunta pede um lugar diferente. Pedido precisa de transação rápida, relatório precisa de leitura em massa, e o clique precisa de um caminho próprio até o painel. Separar essas três coisas é o que impede o relatório de travar a loja.