O seu dashboard é lento, e o problema não é o dashboardO seu dashboard é lento, e o problema não é o dashboard

Alguém pergunta porque é que o dashboard de vendas demora quatro minutos a carregar. A ferramenta de BI é o que se vê, por isso é a ferramenta de BI que leva a culpa. Discute-se uma licença mais rápida. Às vezes, até se compra.

Raramente ajuda, porque os quatro minutos não foram gastos a desenhar gráficos. Foram gastos a fazer trabalho que devia ter acontecido horas antes, e que é repetido a cada atualização.

O que um dashboard lento costuma estar a fazer

Abra a consulta por trás de um relatório lento e é provável que encontre os mesmos padrões. Junta cinco tabelas de origem no momento da leitura. Converte colunas de texto em datas porque ninguém corrigiu os tipos a montante. Filtra por uma expressão calculada, por isso nenhum índice ajuda. Elimina linhas duplicadas, o que significa que a origem tem duplicados que nunca foram resolvidos. E faz tudo isto outra vez para cada utilizador, todas as manhãs, à mesma hora.

Nada disto é um problema de visualização. É um problema de preparação de dados que foi empurrado para jusante até se tornar visível.

Mude o trabalho de sítio, não o repita

A abordagem por camadas a que se chama Bronze, Silver e Gold não tem glamour, e é aqui que se justifica. Bronze é o que chegou, guardado tal como chegou. Silver são esses dados limpos, tipados e sem duplicados, uma única vez. Gold é a forma de que a pergunta realmente precisa: uma tabela de factos com as suas dimensões, já agregada ao nível de detalhe que as pessoas procuram.

O que importa não são os nomes. O que importa é que cada operação cara acontece uma vez, de forma agendada, em vez de uma vez por pessoa e por atualização. Um relatório que lê uma tabela Gold quase não trabalha: filtra, agrega, desenha.

Se um cálculo é igual para todos os utilizadores, não deve correr uma vez por utilizador.

A questão incremental

A segunda coisa que torna os relatórios lentos é reprocessar o histórico. Um pipeline que reconstrói três anos de encomendas todas as noites para acrescentar as de ontem vai ficar mais lento todas as noites, para sempre, pela forma como foi construído.

O carregamento incremental resolve isto, e é sobretudo uma questão de conseguir responder a duas perguntas: o que é novo desde a última vez, e o que significa correr isto duas vezes. A primeira precisa de uma marca de água: uma coluna updated-at fiável, um feed de alterações, uma sequência. A segunda precisa que o carregamento seja idempotente, um tema suficientemente grande para ter o seu próprio artigo.

O que verificar de facto

• Quanto tempo demora a consulta mais lenta por trás do relatório, sozinha, fora da ferramenta de BI?
• Lê uma tabela preparada, ou junta origens em bruto no momento da leitura?
• O processo noturno reprocessa tudo, ou só o que mudou?
• Os tipos são corrigidos uma vez, a montante, ou convertidos em cada consulta que toca na coluna?
• Quantas pessoas disparam a mesma atualização cara nos mesmos dez minutos?

Se as respostas apontam para montante, e costumam apontar, nenhuma definição do dashboard o vai salvar. A boa notícia é que a correção dura. Trabalho que passa para um pipeline fica lá.