Modelagem de Dados para Análise de Funis no Amazon Redshift

Como engenheiros de dados, frequentemente enfrentamos o desafio de transformar logs transacionais—sequências longas de eventos—em uma visão consolidada que permita análises de negócio. Um caso clássico é a modelagem de um funil de conversão, como o rastreamento do ciclo de vida de tickets de suporte em um sistema de atendimento ao cliente.

Neste post, vamos explorar as decisões de arquitetura e as técnicas de SQL para construir uma Tabela Analítica eficiente para esse cenário no Amazon Redshift, comparando duas abordagens de modelagem (One Big Table vs. Star Schema) e três técnicas de pivotagem de dados.

O Cenário: Funil de Tickets de Suporte

Imagine uma tabela de logs, suporte_ticket_eventos, com milhões de linhas e a seguinte estrutura:

id_evento	id_ticket	status_novo	timestamp
901	123	Aberto	2025-09-20 10:00
902	124	Aberto	2025-09-20 10:05
905	123	Em Análise	2025-09-20 11:30
908	123	Resolvido	2025-09-21 14:00
909	124	Resolvido	2025-09-20 18:45

O objetivo de negócio é responder a perguntas como: "Qual o tempo médio entre a abertura e a resolução de um ticket?". Para isso, precisamos de uma tabela final com uma linha por ticket, contendo as datas de cada marco importante.

Decisão 1: A Arquitetura da Tabela - OBT vs. Star Schema

A primeira grande decisão é como estruturar nossa tabela analítica final.

Característica	One Big Table (OBT) / Desnormalizada	Star Schema (Esquema Estrela)
Estrutura	Tabela única e larga com id_ticket, data_abertura, data_analise, data_resolucao, nome_cliente, categoria_produto, etc.	Tabela Fato (fato_tickets) com id_ticket, tempo_resolucao_horas e chaves para as Dimensões dim_cliente e dim_produto.
Performance de Leitura	Excelente. Sem JOINs, as consultas para dashboards são instantâneas.	Muito boa. JOINs otimizados entre a tabela fato e as dimensões.
Flexibilidade	Menor. Otimizada para o processo de funil. Perguntas sobre novas dimensões exigem alterações no ETL.	Excelente. Permite análises exploratórias (ad-hoc), cruzando fatos com qualquer combinação de dimensões.
Manutenção	Lógica complexa e centralizada no ETL de criação da tabela.	Mais simples. Atualizar o nome de um cliente, por exemplo, afeta apenas a dim_cliente.
Ideal Para	Dashboards de alta performance e análise de processos específicos como funis.	Business Intelligence geral e exploração de dados, criando uma "fonte da verdade" reutilizável.

Por que a OBT é frequentemente a escolha certa para funis?
Para analisar um processo sequencial como um funil, a OBT é superior. A complexidade de calcular os tempos entre múltiplos estados (data_resolucao - data_abertura) é resolvida uma única vez durante o ETL. A estrutura é desenhada especificamente para responder a perguntas sobre esse funil da forma mais rápida possível. Apresentar uma única linha por ticket com todos os seus marcos temporais é a forma mais intuitiva e performática para o consumo em dashboards.

Decisão 2: A Técnica de Pivotagem no Redshift

Uma vez decidida a estrutura OBT, precisamos transformar nossas linhas de log em colunas. Existem várias formas de fazer isso em SQL.

Abordagem 1: Agregação Condicional (Recomendada)

Esta técnica utiliza GROUP BY e CASE WHEN dentro de funções de agregação. É a abordagem mais idiomática e performática em bancos de dados colunares como o Redshift.

CREATE TABLE tickets_funil AS
SELECT
    id_ticket,
    MIN(CASE WHEN status_novo = 'Aberto'      THEN "timestamp" END) AS data_abertura,
    MIN(CASE WHEN status_novo = 'Em Análise'  THEN "timestamp" END) AS data_inicio_analise,
    MAX(CASE WHEN status_novo = 'Resolvido'   THEN "timestamp" END) AS data_resolucao
FROM
    suporte_ticket_eventos
GROUP BY
    id_ticket;

Por que funciona tão bem no Redshift?

• Single Pass: A tabela de logs é lida apenas uma vez.
• Execução Colunar: O Redshift lê apenas as colunas necessárias (id_ticket, status_novo, timestamp), ignorando o resto e minimizando I/O.
• Processamento Paralelo (MPP): A operação GROUP BY é massivamente paralelizada entre os nós do cluster.

Abordagem 2: Múltiplos Self-Joins (Não Recomendada)

Uma abordagem intuitiva para quem vem de bancos de dados transacionais é criar uma subquery para cada status e juntá-las com LEFT JOIN.

-- NÃO FAÇA ISSO EM REDSHIFT PARA PIVOTAGEM
SELECT
    base.id_ticket,
    abertos.data_abertura,
    resolvidos.data_resolucao
FROM
    (SELECT DISTINCT id_ticket FROM suporte_ticket_eventos) AS base
LEFT JOIN
    (SELECT id_ticket, MIN("timestamp") AS data_abertura FROM suporte_ticket_eventos WHERE status_novo = 'Aberto' GROUP BY 1) AS abertos
    ON base.id_ticket = abertos.id_ticket
LEFT JOIN
    (SELECT id_ticket, MAX("timestamp") AS data_resolucao FROM suporte_ticket_eventos WHERE status_novo = 'Resolvido' GROUP BY 1) AS resolvidos
    ON base.id_ticket = resolvidos.id_ticket;

Por que esta abordagem é ruim? Ela força o Redshift a escanear a tabela suporte_ticket_eventos múltiplas vezes, uma para cada subquery. O plano de execução se torna muito mais caro, com mais I/O e movimentação de dados entre os nós.

Alternativa: Funções de Janela (Window Functions)

Funções de janela como ROW_NUMBER() ou LEAD()/LAG() são extremamente poderosas, mas para o problema simples de pivotagem, a agregação condicional é geralmente mais direta e performática. As funções de janela brilham em análises de sequência mais complexas, como "qual foi o tempo gasto no status anterior, qualquer que seja ele?".

Dicas Finais de Otimização no Redshift

Para garantir que a abordagem de agregação condicional seja ainda mais rápida, otimize sua tabela de logs:

• DISTKEY (Chave de Distribuição): Defina a DISTKEY como o campo de agrupamento (ex: id_ticket). Isso garante que todos os eventos do mesmo ticket fiquem no mesmo nó, eliminando a movimentação de dados pela rede (shuffle) durante o GROUP BY.
• SORTKEY (Chave de Ordenação): Use uma chave de ordenação composta (ex: id_ticket, timestamp). Isso acelera a busca e a ordenação dos eventos de um mesmo ticket.

A documentação da AWS sobre "Amazon Redshift Engineering’s Advanced Table Design Playbook: Distribution Styles and Distribution Keys" oferece excelentes guias sobre estes conceitos.

Conclusão

A modelagem de dados para análise de funis exige decisões de arquitetura deliberadas. Para cenários focados em processos, como o nosso exemplo de tickets, a abordagem One Big Table oferece performance e clareza para o usuário final. Dentro do Redshift, a técnica de agregação condicional é a ferramenta mais eficiente para construir essa tabela a partir de dados de log, superando alternativas como múltiplos JOINs.