• Issue Jira Produção: https://jiraproducao.totvs.com.br/browse/IDEIA-2795

• Reporter: TOTVS IDEIA

• Creator: Marcos Henrique Fernandes Marcone

• Formulário de origem: Abertura de issue para Plataforma Carol

• Formulário preenchido por: marcos.marcone@totvs.com.br

• Informe a sua área de atuação na TOTVS: Clock In - PNRH

• Ambiente impactado: Desenvolvimento

• Fase/estágio: Estamos em tempo de PROJETO

• Informe o assunto a ser direcionado: Quero reportar um tema que não consta em nenhuma das opções anteriores

• Informe a Org relacionada: clockin

• Informe o tenant/ambiente relacionado: clockinunif

• Ciente de que, caso precise trazer upload de anexos, ele deverá acontecer na issue criada no JIRA Produção.: Estou ciente que o envio destas evidências será realizado diretamente na issue criada no JIRA PRODUÇÃO.

• Informe a prioridade da sua issue: MÉDIA: não acontece em ambiente produtivo e nem possui impacto financeiro direto. Ex.: problemas de teste, homologação ou desenvolvimento.

• Sendo prioridade CRÍTICA, relate a justificativa:

• Descreva o seu problema:

Contexto e Motivação

O projeto Clock In está em fase de avaliação da migração da arquitetura de processamento de dados através Orquestrador para o Ambiente Unificado. Um dos principais pilares desta migração é garantir a escalabilidade e, consequentemente, a performance otimizada das pipelines no Google BigQuery.

Para que a migração seja bem-sucedida e para que os ganhos de performance sejam relevantes, é fundamental que as pipelines utilizem as estratégias de otimização mais eficientes da arquitetura do BigQuery.

Justificativa Técnica

Uma das otimizações mais fundamentais é o pruning através do campo _ingestionDatetime_, que é o campo responsável pelo particionamento das tabelas (_stagings{} e Data Models).

Para utilizar o pruning de forma otimizada em queries é necessário realizar a comparação do campo da partição com valores constantes.

Uma das formas de garantir essa definição de constantes em jobs sequenciais no BigQuery é através da Linguagem Procedural (DECLARE/SET). No entanto, a Plataforma Carol atualmente não dá suporte a execução de pipelines que contêm essas instruções.

Evidências de Performance:
Em testes de performance realizados pelo Clock In, a utilização de Linguagem Procedural apresentou ganhos significativos em comparação com abordagens alternativas que utilizam Subqueries e `INNER JOIN`s para o filtro com o campo _ingestionDatetime.

Referências de Boas Práticas:
Essa necessidade é evidenciada tanto pela documentação oficial do Google BigQuery quanto pela própria documentação da Plataforma Carol na seção "Otimização em SQL" da página "Otimizações em consultas".

Cenário Atual

Ao tentar executar uma pipeline com instruções de Linguagem Procedural (DECLARE/SET), a task de pipeline apresenta o seguinte log de erro:

"There was an error building pipeline: configuration.query.writeDisposition cannot be set for scripts".

Solicitação

Dessa forma, solicitamos formalmente que a Equipe IDeIA avalie a possibilidade de dar suporte a execução de pipelines SQL com Linguagem Procedural.

Os benefícios em produção serão amplos, impactando positivamente a performance de vários projetos na plataforma e sendo um fator crítico de viabilidade e sucesso para o processo de migração do Clock In para o Ambiente Unificado.

Objetivo

• Permitir que pipelines tenham SQL procedurais (Procedural Language) em vez de uma instrução SQL, permitindo aplicar recursos de otimização de consultas.

Critério de Aceite

• Permitir executar pipelines com SQL procedurais, como esse exemplo: https://github.com/totvslabs/qa-sample-pipeline/tree/main/product