As 10 melhores práticas para a otimização do desempenho de dashboards de AI/BI (Parte 2)

Este post é a segunda parte de uma série de duas partes sobre como otimizar o desempenho do AI/BI dashboard da Databricks em grande escala. 

No post anterior, focamos em como a disposição, os filtros, os parâmetros e o cache determinam quanto trabalho o sistema realiza a cada clique. Essas otimizações geralmente são suficientes para fazer com que os dashboards pareçam rápidos. 

Nesta postagem, mudamos o foco para os fundamentos da plataforma que as mantêm rápidas à medida que o uso cresce. Analisaremos a seleção e o dimensionamento do warehouse, a modelagem de dados e as escolhas de esquema, a disposição do arquivo e a clusterização, e quando depender da materialização em vez da recomputação para alcançar um desempenho estável e previsível.

Otimização nº 6: Escolha a configuração de warehouse que corresponda ao design 

Combine a estrutura do seu dashboard (páginas, combinação de consultas, picos de atividade do usuário) com o tipo e o dimensionamento do DBSQL warehouse para que o sistema aceite o trabalho rapidamente sem enfileiramento.

Como os widgets visíveis são enviados juntos, os dashboards naturalmente geram picos de simultaneidade de curta duração. Se o warehouse não conseguir absorver o pico, você verá enfileiramento (Pico de queries na Fila > 0) e tempos de carregamento de blocos inconsistentes, especialmente nos horários de pico.

Como funciona a simultaneidade do warehouse do DBSQL

• Serverless + IWM: o Serverless usa o Intelligent Workload Management para prever custos, admitir e priorizar queries e autoescalar rapidamente. A startup típica é de 2 a 6 segundos, portanto, os picos permanecem com baixa latência sem ajuste manual.
• Pro/Classic: Limite fixo de “10 queries concorrentes por cluster”, o autoscale adiciona clusters em limites de nível de minuto e a startup leva vários minutos. Planeje a capacidade com base na concorrência esperada e evite picos no carregamento da página.
• Monitore e dimensione corretamente: acompanhe o Peak Queued Queries e o Query History. Se os picos persistirem acima de 0, aumente o tamanho do cluster (especialmente se o Query Profile mostrar derramamento para o disco) ou aumente o número máximo de clusters. 

Por que Serverless primeiro

• Serverless recomendado para BI interativo: startup mais rápida, simultaneidade dinâmica via IWM e E/S mais eficiente.

Heurísticas práticas de dimensionamento

• Comece com um tamanho maior (tamanho do cluster) e reduza-o após os testes, deixe o autoscale Serverless lidar com picos de simultaneidade e aumente o número máximo de clusters somente quando os picos na fila persistirem.
• Mantenha ETL pesado e BI separados: dedique warehouses Serverless por carga de trabalho/domínio (evite a poluição do cache e deixe o IWM aprender o padrão da carga de trabalho).
• Priorize queries pequenas e frequentes: o IWM Serverless protege interações curtas e escala rapidamente durante cargas mistas; crie páginas para que a Visão Geral execute primeiro os blocos mais leves. 

Para obter mais detalhes, consulte: https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior 

Otimização nº 7: Aplique as melhores práticas de modelagem de dados

Modelos de dados bem projetados são um recurso fundamental de desempenho para painéis de AI/BI. O esquema estrela continua sendo o padrão de modelagem mais eficaz e previsível para analítica interativa, pois se alinha diretamente à forma como as queries de BI são escritas e otimizadas.

Em um esquema estrela, uma tabela de fatos central contém eventos mensuráveis (ventas, transações, cliques) e faz join às tabelas de dimensão ao redor (data, cliente, produto, região). Essa estrutura minimiza a complexidade das junções, reduz a duplicação de dados e permite agregações eficientes com padrões de consulta simples e estáveis. Como resultado, os dashboards executam menos joins, analisam menos dados e se beneficiam de forma mais consistente do cache e da otimização de queries.

Um detalhe crítico, mas muitas vezes esquecido, são os tipos de dados da chave de junção. As junções de tabelas de dimensão e de fatos devem usar chaves substitutas baseadas em inteiros, e não em strings. Integer joins são significativamente mais rápidas, exigem menos memória, melhoram a eficiência do cache e permitem que o Photon execute joins usando caminhos vetorizados altamente otimizados. joins baseadas em strings aumentam o custo de CPU e podem se tornar um gargalo oculto à medida que os dados e a simultaneidade aumentam.

No Databricks, esse padrão se encaixa naturalmente com a arquitetura Lakehouse. A camada ouro deve ser modelada como fatos e dimensões armazenados como tabelas do Unity Catalog, fornecendo uma base semântica governada e reutilizável para dashboards de AI/BI, exibições de métricas e exibições materializadas.

A lição é simples: modele para como as queries de BI realmente são executadas. Um esquema em estrela com keys de junção de inteiros na camada ouro oferece SQL mais simples, joins mais rápidas e desempenho mais previsível em escala.

Otimização nº 8: Técnicas de otimização do Parquet

Projete sua disposição de dados para que os dashboards leiam muito menos dados por query e, em seguida, deixe o mecanismo explorar as estatísticas do Parquet e as leituras seletivas. 

Trate a disposição do arquivo como um recurso de desempenho

O Databricks SQL é mais rápido quando pode:

• eliminar arquivos inteiros usando metadados (estatísticas mín./máx.),
• ler blocos grandes e contíguos de forma eficiente,
• e evite abrir milhares de arquivos pequenos.

Portanto, os dois maiores ganhos são: compactar arquivos em tamanhos ideais e
clusterizar dados para que os predicados eliminem arquivos.

Mais detalhes estão disponíveis aqui: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

Um antipadrão clássico: um filtro de dashboard como WHERE customer_id = ? parece seletivo, mas se os dados não estiverem clusterizados, o motor ainda acessa uma grande parte dos arquivos porque as linhas correspondentes estão espalhadas por toda parte.

Técnicas

• Use o Photon para se beneficiar do Predictive IO integrado em Parquet: o Photon aplica leitura seletiva assistida por IA e IO paralelo para pular blocos não correspondentes e listar menos arquivos, oferecendo varreduras seletivas rápidas sem indexação manual.
• Ative as otimizações preditivas para tabelas gerenciadas: o Databricks pode agendar e executar automaticamente a manutenção da tabela com base nos padrões de carga de trabalho observados —OPTIMIZE (compactação para manter os tamanhos dos arquivos saudáveis), ANALYZE (estatísticas novas), VACUUM (limpeza) e Liquid Clustering (layout adaptável) — liberando você do ajuste manual e melhorando o preço/desempenho da leitura em escala. Na prática, isso ajuda a manter os tamanhos de arquivo saudáveis por meio da compactação proativa de arquivos pequenos (via OPTIMIZE) para que os metadados Parquet (rodapés + estatísticas mínimas/máximas) permaneçam eficazes para saltos de dados, verificações seletivas e verificações/simultaneidade de BI.
• Trigger the same operações manualmente quando necessário: você ainda pode executá-las por conta própria quando precisar de um controle mais rígido ou de um tempo de obtenção de benefícios mais rápido (por exemplo, após grandes ingestões/preenchimentos retroativos, alterações de esquema ou antes de um pico conhecido de relatórios), executando comandos como OPTIMIZE e ANALYZE. A key é ser intencional: alinhe a cadência da manutenção com a frequência com que a tabela muda e garanta que o custo de computação seja justificado pelos ganhos posteriores em simultaneidade, latência e eficiência de varredura.
• Adote o Liquid Clustering em vez de particionamento intensivo. O Liquid agrupa dados incrementalmente para pesquisas de ponto e varreduras seletivas, e você pode alterar as colunas de agrupamento a qualquer momento (mesmo de alta cardinalidade) sem uma reescrita completa; a disposição se adapta conforme o uso evolui.
• Alinhe a disposição aos predicados do dashboard. Escolha colunas de clusters Liquid que espelhem dimensões comuns de filtro/agrupamento (por exemplo, data, cliente, região) para que o Predictive IO possa pular grandes porções de dados para as páginas de “Investigação” e “Análise aprofundada”. 

Resultado: menos arquivos acessados, mais blocos ignorados e menor tempo de relógio para as mesmas percepções, sem índices frágeis ou ajuste manual. 

Para obter mais detalhes, consulte: 

• https://www.databricks.com/blog/faster-lakeview-dashboards-materialized-views
• https://docs.databricks.com/aws/en/compute/photon
• https://docs.databricks.com/aws/en/delta/data-skipping
• https://docs.databricks.com/aws/en/delta/optimize 

Otimização nº 9: faça uso da Materialização para Exibições de Métricas

Em Otimização nº 7: aplicar as melhores práticas de modelagem de dados, focamos na importância do esquema em estrela com fatos, dimensões e KPIs claramente definidos. As Views de métricas são uma continuação direta desses princípios no Databricks AI/BI.

As Metric Views são projetadas em torno da semântica de BI: elas consistem em medidas e dimensões, o que as torna uma abstração natural para modelar KPIs. Elas permitem que as equipes definam métricas de negócios uma vez e reutilizem os mesmos KPIs de forma consistente em vários dashboards, agentes e outras ferramentas de cliente. Isso reduz a duplicação, evita o KPI drift e mantém a lógica analítica alinhada à medida que a adoção aumenta.

Com a Materialização para views de métricas, o Databricks pré-computa e mantém automaticamente os agregados usados com frequência. Essas agregações são atualizadas incrementalmente e, no momento da query, o otimizador reescreve de forma transparente as queries do dashboard para o resultado pré-computado mais compatível. Como resultado, as consultas dos dashboards verificam muito menos dados por interação, sem exigir que as equipes gerenciem tabelas de agregação separadas ou pipelines personalizados.

Se as Metric Views não forem usadas, a mesma abordagem pode ser aplicada com Materialized Views. Por exemplo, uma versão agregada de uma tabela de fatos grande pode ser pré-calculada e armazenada, permitindo que os dashboards consultem um dataset muito menor e otimizado. Isso melhora significativamente o desempenho, reduzindo a quantidade de dados verificados e evitando o recálculo repetido de agregações dispendiosas para cada interação do usuário.

Todas essas técnicas otimizam a mesma coisa: verificar menos dados. Ao definir KPIs uma vez e pré-computar agregações usadas com frequência com Views de Métrica ou Views Materializadas, os dashboards evitam a agregação repetida de grandes tabelas de fatos. Menos bytes verificados se traduzem diretamente em queries mais rápidas, latência mais previsível e melhor desempenho em escala.

Para obter mais detalhes, consulte: 

• https://docs.databricks.com/aws/en/metric-views/materialization

Otimização nº 10: Otimize os tipos de dados

Os tipos de dados influenciam diretamente a quantidade de dados que o Databricks SQL precisa ler, mover e processar para cada query de dashboard. Mesmo com SQL e cache perfeitos, tipos de dados ineficientes aumentam silenciosamente a E/S, a pressão sobre a memória e o custo de CPU, manifestando-se como blocos mais lentos e simultaneidade reduzida.

Internamente, o Databricks SQL opera em arquivos Parquet colunares. Tipos de dados menores e bem escolhidos significam:

• Menos dados verificados do armazenamento (colunas mais estreitas),
• Melhor densidade de cache (mais valores cabem na memória e no cache de resultados),
• Execução vetorizada mais rápida no Photon (disposições compatíveis com SIMD),
• Salto de dados mais eficaz, porque as estatísticas de mín./máx. são mais precisas.

Alguns mecanismos são mais importantes:

• Use INT / BIGINT em vez de STRING para identificadores sempre que possível. As strings são caras para digitalizar, comparar e armazenar em cache; as chaves numéricas são ordens de magnitude mais baratas.
• Prefira DATE ou TIMESTAMP em vez de datas baseadas em string. Tipos temporais nativos permitem o predicate pushdown, comparações eficientes e uma melhor eliminação.
• Use o menor tipo numérico que couber (INT vs. BIGINT, FLOAT vs. DOUBLE) para reduzir a largura da coluna e o consumo de memória.
• Evite o uso excessivo de DECIMAL com precisão excessiva em tabelas voltadas para BI, a menos que seja necessário; decimais de alta precisão aumentam o custo da CPU durante a agregação.
• Mantenha os esquemas limpos e estáveis. Conversões implícitas (por exemplo, STRING → INT em tempo de consulta) desativam otimizações e adicionam computação desnecessária a cada execução.

Em cargas de trabalho de BI, essas escolhas se acumulam rapidamente: uma página de painel pode executar dezenas de queries, cada uma verificando milhões de linhas. Colunas estreitas e bem tipadas reduzem o tempo de varredura, melhoram as taxas de acerto de cache e permitem que o Photon opere com eficiência máxima.

Regra geral: trate o design do esquema como um recurso de desempenho. Otimize os tipos de dados uma vez no Lakehouse, e todo dashboard, atual e futuro, se beneficia automaticamente.

Conclusão

O tema em todas as dez melhores práticas é simples: pare de pagar o preço total de uma interação no dashboard toda vez. Faça o sistema trabalhar menos por visualização (menos fan-out, menos dados analisados) e faça com que o trabalho que ele realiza seja reutilizável (datasets compartilhados, queries determinísticas, caches e agregados pré-computados). Quando essas peças se alinham, o desempenho se torna estável sob concorrência — e o custo se torna previsível.

Na prática, você deve ser capaz de responder “sim” a estas perguntas para seus dashboards mais usados:

• Os usuários têm uma primeira pintura rápida (view de destino leve + defaults sensatos)?
• Uma interação típica trigger um pequeno número de queries baratas (os parâmetros filtram cedo, não após a digitalização)?
• As visualizações repetidas estão se tornando hits de cache (blocos determinísticos, reutilização entre blocos, aquecimento programado)?
• O warehouse consegue absorver a carga de pico sem enfileiramento ou derramamento (Peak Queued queries permanece próximo de zero, o query Profile não derrama)?
• O Lakehouse está otimizado para leituras (tamanhos de arquivo saudáveis, Liquid Clustering, tipos de dados limpos e agregados quentes pré-computados)?

Escolha um dashboard com adoção real, execute uma linha de base rápida (primeira renderização, latência de interação, pico de queries enfileiradas, spill, taxa de acerto de cache), aplique algumas das alterações de maior impacto e meça novamente. Faça isso de forma consistente, e você passará de um AI/BI “às vezes rápido” para um confiavelmente rápido à medida que os dados e os usuários crescem.

Referências e leitura adicional

• Dimensionamento, escalonamento, enfileiramento e monitoramento de SQL warehouses, IWM Serverless versus escalonamento automático Pro/Classic. https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior
• Criar/configurar warehouses, orientação de clusters por simultaneidade.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/create
• Vantagens do Serverless e por que é recomendado.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/
• Tipos de Warehouse e recursos de desempenho (Photon, Predictive IO, IWM, startup de 2 a 6s para Serverless).
  https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types
• Cache de resultados (por cluster e cache de resultados remoto Serverless).
  https://docs.databricks.com/aws/en/lakehouse-architecture/performance-efficiency/best-practices https://learn.microsoft.com/pt-br/azure/databricks/sql/user/queries/query-caching
• Dashboards de AI/BI: páginas/tela/modelo de dados e componentes.
  https://docs.databricks.com/aws/en/dashboards
• Parâmetros vs. filtros de campo, parâmetros baseados em consulta.
  https://docs.databricks.com/aws/en/dashboards/parameters
• Exporte um dataset do dashboard para uma view materializada para acelerar cargas de trabalho pesadas.
  https://docs.databricks.com/aws/en/ai-bi/release-notes/2025
• Execuções de query do painel em logs de auditoria (verifique o que é execuções no carregamento).
  https://docs.databricks.com/aws/en/admin/account-settings/audit-logs

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original