À medida que empresas como a Carousell empurram mais relatórios para plataformas de dados em nuvem, um gargalo está aparecendo nas pilhas de enterprise intelligence. Os painéis que antes funcionavam bem em pequena escala começam a ficar lentos, as consultas se estendem por dezenas de segundos e pequenos erros de esquema se espalham nos relatórios. Em suma, as equipes encontram-se equilibrando duas necessidades concorrentes: métricas executivas estáveis e exploração flexível para analistas.
A tensão está se tornando comum em ambientes de análise em nuvem, onde se espera que as ferramentas de enterprise intelligence (BI) sirvam relatórios operacionais e experimentação profunda. O resultado geralmente é um único ambiente fazendo muito – agindo como uma camada de apresentação, um mecanismo de modelagem e um sistema de computação ad-hoc ao mesmo tempo.
Uma recente mudança de arquitetura no mercado Carousell do Sudeste Asiático mostra como algumas equipes de análise estão respondendo. Os detalhes compartilhados pelos engenheiros analíticos da empresa descrevem uma mudança de uma única instância de BI sobrecarregada em direção a um design dividido que separa relatórios críticos de desempenho de cargas de trabalho exploratórias. Embora o caso reflita a experiência de uma organização, o problema subjacente reflete padrões mais amplos observados nas pilhas de dados na nuvem.
Quando o BI se torna um gargalo computacional
Ferramentas modernas de BI permitem que as equipes definam a lógica diretamente na camada de relatórios. Essa flexibilidade pode acelerar o desenvolvimento inicial, mas também transfere a pressão computacional dos bancos de dados otimizados para a camada de visualização.
Na Carousell, os engenheiros descobriram que “Explores” analíticos estavam frequentemente conectados a conjuntos de dados extremamente grandes. De acordo com o líder de análise Shishir Nehete, os conjuntos de dados às vezes atingiam “centenas de terabytes de tamanho”, com junções executadas dinamicamente dentro da camada de BI, e não upstream no warehouse. O design funcionou – até que a escala expôs os seus limites.
Nehete explica que junções derivadas pesadas levaram a caminhos de execução lentos. “Explores” que extraíram grandes conjuntos de dados de transações foram montados sob demanda, o que aumentou a carga de computação e aumentou a latência da consulta. A equipe descobriu que os tempos de consulta do percentil 98 eram em média de aproximadamente 40 segundos, tempo suficiente para interromper as análises de negócios e reuniões com as partes interessadas. Os números são baseados no acompanhamento de desempenho interno da Carousell, fornecido pela equipe de análise.
O desempenho period apenas parte do desafio: as lacunas de governação criavam riscos adicionais e os programadores podiam introduzir alterações diretamente nos modelos de produção sem testes rigorosos, o que ajudava na entrega de recursos, mas introduzia dependências frágeis. Um pequeno erro na definição de um campo pode causar falhas nos painéis downstream, forçando os engenheiros a realizar correções reativas.
Separando estabilidade da experimentação
Em vez de continuar a ajustar o ambiente atual, os engenheiros da Carousell optaram por repensar onde o trabalho computacional deveria ficar. Transformações pesadas foram transferidas upstream para pipelines do BigQuery, onde os mecanismos de banco de dados são projetados para realizar grandes junções. A camada de BI mudou em direção à definição e apresentação de métricas.
A maior mudança veio da divisão de responsabilidades em duas instâncias de BI. Um ambiente foi dedicado a dashboards executivos pré-agregados e relatórios semanais. Os conjuntos de dados foram preparados antecipadamente, permitindo que consultas de liderança fossem executadas em tabelas otimizadas em vez de volumes brutos de transações.
O segundo ambiente permanece aberto para análise exploratória. Os analistas ainda podem unir conjuntos de dados granulares e testar novas lógicas sem correr o risco de degradação do desempenho nos fluxos de trabalho de seus colegas executivos.
A estrutura dupla reflete um princípio mais amplo de análise em nuvem: isolar cargas de trabalho experimentais ou de alto risco dos relatórios de produção. Muitas equipes de engenharia de dados agora aplicam padrões semelhantes em camadas de preparação de warehouse ou em projetos de sandbox. Estender essa separação para a camada de BI ajuda a manter um desempenho previsível durante o crescimento.
Governança como parte da infraestrutura
A estabilidade também dependia de controles de liberação mais fortes. O engenheiro de BI Wei Jie Ng descreve como o novo ambiente introduziu verificações automatizadas por meio do Looker CI e do Look At Me Sideways (LAMS), ferramentas que validam regras de modelagem antes que o código chegue à produção. “O sistema agora detecta automaticamente erros de sintaxe SQL”, diz Ng, acrescentando que as verificações com falha bloqueiam as mesclagens até que os problemas sejam corrigidos.
Além da validação de sintaxe, as regras de governança impõem documentação e disciplina de esquema. Cada dimensão requer metadados e as conexões devem apontar para bancos de dados aprovados. Os controles reduzem o erro humano ao mesmo tempo em que criam definições de dados mais claras, uma base importante à medida que as ferramentas analíticas começam a adicionar interfaces de conversação.
De acordo com os engenheiros da Carousell, os metadados estruturados preparam conjuntos de dados para consultas em linguagem pure. Quando as ferramentas de análise conversacional leem modelos bem definidos, elas podem mapear a intenção do usuário para métricas consistentes, em vez de adivinhar relacionamentos.
Ganhos de desempenho – e menos tiroteios
Após a reformulação, a equipe de análise relatou melhorias mensuráveis. O rastreamento interno mostra os tempos de consulta do percentil 98 caindo de mais de 40 segundos para menos de 10 segundos. A mudança alterou o desenrolar das análises de negócios. Em vez de perguntar se os painéis estavam quebrados, as partes interessadas poderiam concentrar-se na avaliação dos dados em tempo actual. Tão importante quanto isso, os engenheiros poderiam abandonar a constante solução de problemas.
Embora cada ambiente de análise tenha restrições únicas, a lição mais ampla é simples: as camadas de BI não devem funcionar como mecanismos de computação pesados. À medida que os volumes de dados na nuvem crescem, separar apresentação, transformação e experimentação reduz a fragilidade e mantém os relatórios previsíveis.
Para as equipes que estão ampliando suas pilhas de análise, a questão não é a escolha de ferramentas, mas sim os limites arquitetônicos – decidir quais cargas de trabalho pertencem ao warehouse e quais residem no BI.
Veja também: Alphabet aumenta investimento em nuvem para atender à crescente demanda por IA
(Foto por Velocidade do obturador)
Quer aprender mais sobre Cloud Computing com os líderes do setor? Confira Segurança cibernética e exposição de nuvem acontecendo em Amsterdã, Califórnia e Londres. O evento abrangente faz parte TechEx e está localizado junto com outros eventos líderes de tecnologia, clique aqui para mais informações.
CloudTech Information é desenvolvido por Mídia TechForge. Discover outros eventos e webinars de tecnologia empresarial futuros aqui.