Fala dataholics, da série de dicas rápidas, hoje uma dica bem simples que podemos aplicar em nossos ambientes Databricks.
A maioria dos desenvolvedores não estão acostumados a lidar com problemas de performance, muitas vezes por estarem focados na solução e prazos apertados, entregam o desenvolvimento funcionando (o que já bom rs), mas, na maioria dos cenários teremos problemas de performance em produção, o que na minha experiência, por mais "foda" que seja o desenvolvedor, ainda, sim, vai acontecer, digo, pois, já estive nos dois lados, desenvolvendo e também no lado de especialista em performance tuning, não é nada fácil.
Isso não é um julgamento, é compreensível em alguns casos, embora, precisamos começar a criar uma cultura de códigos mais performáticos e não deixar a galera mal acostumada achando que o time de produção / sustentação resolverá todos os problemas.
Com, isso configurar thresholds de timeout em seus pipelines é realmente importante, evitar Jobs e queries rodando por horas e horas gastando recurso computacional e dinheiro da empresa.
No post de hoje veremos como configurar timeout no SQL Warehouse e em Jobs do Workflows, isso poderá te ajudar a entender onde estão os principais problemas de performance.
SQL Warehouse Timeout
Em ambientes maiores, com muitos relatórios rodando no SQL Warehouse e usuários conectados fazendo queries Ad Hocs, é comum ver situações como essas do print abaixo.
Queries rodando há muitas horas e consumindo recursos do cluster e gerando custos.
A imagem acima espelha um cenário que não é incomum de acontecer, queries mal escritas podem gerar problemas de performance e gerar um custo elevado.
Para evitar os casos acima, podemos definir um TIMEOUT ao nível do Workspace, aplicando um limite máximo para todos os clusters e queries do ambiente.
Por padrão essa configuração é de 172800 seconds (2 dias) muita coisa não? Imagina uma query rodando por dois dias? Não queremos isso.
Aqui podemos informar a configuração ao nível de Workspace e todos os clusters SQL Warehouse vão aderir a essa configuração.
Esse valor é informado em segundos, aqui no meu exemplo estou usando 60 segundos apenas para testes.
STATEMENT_TIMEOUT 60
O ideal é você analisar o histórico das queries e criar uma média ou usar com base na mais demorada, exemplo sua query mais demorada leva 1 hora, então um valor interessante talvez seja colocar 2 horas, qualquer coisa que passar disso tomará um erro.
Isso forçará o desenvolvedor a melhorar a performance da query e não deixar queries muito longas rodando.
Com isso, quando as queries atingirem o tempo estipulado nesse parâmetro, o erro abaixo será gerado:
É possível configurar esse parâmetro ao nível de Query, se ambos estiverem configurados, a configuração ao nível de query prevalece sobrescrevendo a configuração ao nível de Workspace.
Usando o comando RESET você volta para o valor global do Workspace.
RESET STATEMENT_TIMEOUT;
O comando SET -v lista todas as configurações aplicadas na sessão.
Essa é a lista de parâmetros que você pode ajustar na sessão ou workspace:
Workflows - Timeout
Podemos configurar essa mesma opção em nossos Jobs e Tasks no Workflows, sendo muito útil para não ter Jobs rodando por horas e gastando dinheiro sem ninguém ver.
Essa configuração no Workflows é ainda mais dinâmica, pois, podemos configurar um tempo de alerta e um tempo máximo de execução tanto ao nível de Job como de Task.
No nível de Task podemos configurar um threshold tanto para o alerta quando para o timeout, isso pode ser aplicado a cada task do Job.
Se a task passar do valor configurado ela irá falhar por timeout, conforme imagem abaixo.
Caso ela execute antes do valor configurado para o timeout, mas, ultrapasse o valor configurado no Warning, teremos essa visão abaixo.
Na visão macro, tudo apresenta sucesso, sem warning.
Mas, dentro da Task veremos esse Warning indicando que ela atingiu o tempo do alerta.
Podemos aplicar essa mesma configuração no nível do Job, servindo para todas as Tasks.
Quando o Job atingir o tempo do Warning você pode configurar para um alerta ser enviado, isso pode ser bem útil para algumas ocasiões.
Quando o Job atingir o tempo do Warning, mas não o tempo total teremos essa visão abaixo:
Job ainda em execução, mas já podemos ver o Warning na execução.
Job finalizado com Sucesso, mas note que temos Warning.
Agora quando o Job atingir o tempo máximo configurado teremos uma falha:
Na task que falhou não temos Timeout configurado, embora, quando atingir o máximo configurado no Job ele irá falhar independente da Task.
Resumo
Nesse post vimos como configurar timeout no SQL Warehouse para evitar queries rodando até 2 dias, o que é um valor muito agressivo e se não tiver ninguém monitorando isso pode acontecer.
Como configurar timeout nos seus Jobs do Workflows para evitar longos processamentos, importante que mesmo que você esteja orquestrando seus Jobs em outra ferramenta, a maioria suporta essa configuração, seja no Azure Data Factory, Airflow entre outras.
O mais importante aqui é, o objetivo não é gerar falhas e trabalhado para o time de produção e sim saber onde estão os gargalos e avisar os responsáveis para melhorar o seu código.
Espero que seja útil para vocês, avalie bem o tempo de Timeout a ser configurado em ambos os casos para evitar falhas desnecessárias, mas não deixe de configurar um tempo máximo, ter Jobs e Queries rodando por horas não é o cenário que desejamos, force o seu time a estudar mais sobre performance, isso vai te ajudar a reduzir custos no ambiente.
Fique bem e até a próxima.