Um passo a passo linha por linha de um procedimento armazenado legado migrando para o Databricks. Cursores, tabelas temporárias e transações de múltiplas instruções migram como SQL como parte da migração do data warehouse.
por Abhishek Dey e Laurent Léturgez
Em algum lugar do seu data warehouse, centenas de stored procedures são executadas todas as noites e mantêm a empresa funcionando silenciosamente. Elas foram escritas anos atrás por desenvolvedores SQL que já saíram da empresa há muito tempo. Elas têm cursores aninhados. Criam tabelas temporárias dinamicamente. Agrupam atualizações em várias tabelas em uma única transação. E em algum lugar perto da linha 47, há um comentário que diz simplesmente: “Não altere isso.” Ninguém mais entende totalmente essas procedures. No entanto, todos dependem delas. O painel de receita, o fechamento financeiro, o relatório de operações, todos eles, de uma forma ou de outra, remontam a essas camadas de lógica de negócios em SQL procedural.
Mover dados para o lakehouse é um processo bem compreendido. O ponto de atrito tem sido o núcleo procedural de qualquer migração de data warehouse: as stored procedures, o tratamento de transações, as tabelas temporárias, o fluxo de controle e o fato de que grande parte da empresa ainda depende de habilidades em SQL. Toda vez que surgia uma migração, essas procedures eram a primeira coisa que todos apontavam: “Não podemos migrar até que possamos executar isso com o mínimo de alterações. Nossa empresa ainda é fortemente orientada a SQL.”
Por isso, decidimos pegar um caso de uso como o que você provavelmente está pensando agora, uma procedure composta que vimos em várias migrações, e demonstrá-la, passo a passo, no Lakehouse. Este exemplo é baseado em um caso de uso de migração do Oracle, mas pode ser aplicado a qualquer data warehouse (legado ou baseado em nuvem).
Este exemplo de procedure processa pedidos diários. Ela armazena temporariamente os pedidos não processados em uma tabela temporária, valida-os em relação ao cadastro de clientes, percorre as falhas para registrar cada rejeição individualmente, depois atualiza os resumos de receita regional e marca todos os pedidos como processados, tudo dentro de uma transação que é revertida em caso de falha.
Um job noturno que não pode falhar.
Antes, migrar isso significava reescrever tudo do zero, em Python e Spark. Semanas de trabalho, novos bugs para encontrar e uma equipe de SQL que não conseguia mais manter sua própria lógica de negócios.
Nós não a reescrevemos. Nós a traduzimos.
Toda procedure começa com uma assinatura e uma rede de segurança. O sistema legado envolvia o corpo em BEGIN ... EXCEPTION ... END. O Databricks usa DECLARE EXIT HANDLER FOR SQLEXCEPTION em vez disso; a mesma ideia, com uma sintaxe ligeiramente diferente. Vamos assumir que o catálogo e o esquema apropriados foram definidos na sessão.
A grande diferença não está no código. Está no que acontece após a implantação. No Databricks, a procedure é registrada no Unity Catalog. Ela ganha controles de acesso, linhagem em nível de coluna e capacidade de descoberta em todos os workspaces. No sistema atual, ela vivia em um esquema para o qual apenas três pessoas tinham a senha.
Legado | Databricks |
CREATE OR REPLACE PROCEDURE name IS | CREATE OR REPLACE PROCEDURE [IF NOT EXISTS] <catalog>.<schema>.<procedure_name> ( [ procedure_parameter [, ...] ] ) [ characteristic [...] ] LANGUAGE SQL SQL SECURITY { INVOKER | DEFINER } AS BEGIN |
v_id NUMBER; antes de BEGIN | DECLARE v_id INT; dentro de BEGIN |
EXCEPTION WHEN OTHERS THEN | DECLARE EXIT HANDLER FOR SQLEXCEPTION |
Referência: docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-create-procedure
O procedimento original cria duas tabelas temporárias para staging e falhas de validação. Elas são o espaço de rascunho do qual o restante da lógica depende.
No Databricks, essa se torna uma das partes mais simples da migração. Sem EXECUTE IMMEDIATE. Sem ON COMMIT PRESERVE ROWS. O CREATE TEMP TABLE com escopo de sessão é a substituição direta, com uma pequena ressalva: CREATE OR REPLACE TEMP TABLE ainda não é suportado, então faça o drop primeiro se precisar executar novamente na mesma sessão.
Referência: docs.databricks.com/aws/en/tables/temporary-tables
Esta era a parte que todos presumiam que exigiria uma reescrita. O procedimento original percorre as falhas de validação uma a uma, rejeita cada pedido incorreto e registra o motivo. Padrão clássico de cursor. Décadas de memória muscular legada (Oracle, por exemplo).
O script SQL do Databricks suporta cursores nativamente, OPEN, FETCH e CLOSE desde o Runtime 18.1. O atributo %NOTFOUND torna-se um CONTINUE HANDLER FOR NOT FOUND. Rótulos de loop e LEAVE substituem EXIT WHEN.
A verificação condicional (se não houver linhas para processar, pular e registrar) quase não mudou. SELECT ... INTO torna-se SET var = (SELECT ...). Todo o resto é idêntico.
Nosso script SQL suporta o conjunto completo de ferramentas procedimentais: IF/ELSE, WHILE, FOR, LOOP, REPEAT, LEAVE, ITERATE, SIGNAL/RESIGNAL. Se a sua base de código contiver scripts Teradata BTEQ, as diretivas .GOTO e .LABEL são mapeadas para loops rotulados usando LEAVE e ITERATE.
Referência: docs.databricks.com/aws/en/sql/language-manual/sql-ref-scripting
Esta foi a última peça, aquela que tornou a migração realmente viável. O procedimento original atualiza regional_revenue, marca os pedidos como processados e registra o lote. Se qualquer parte falhar, tudo é revertido.
No sistema legado, esta é uma transação implícita com um COMMIT explícito. No Databricks, BEGIN ATOMIC ... END oferece a mesma semântica: commit automático em caso de sucesso e rollback automático em caso de falha, com uma vantagem significativa: detecção de conflitos em nível de linha. Lotes concorrentes gravando na mesma tabela só entram em conflito se alterarem as mesmas linhas. Por exemplo, tanto o Oracle quanto o Snowflake usam bloqueio em nível de tabela, o que força a execução serial.
A instrução MERGE pode ser migrada para o Databricks como está. O COMMIT explícito desapareceu, pois o BEGIN ATOMIC cuida disso. E a equipe parou de se preocupar com jobs em lote concorrentes interferindo uns nos outros.
Duas observações práticas ao adotar este padrão:
Referência: docs.databricks.com/aws/en/transactions/
Mesma lógica de negócios. Mesmo fluxo de controle. Governado pelo Unity Catalog.
Para executá-lo dentro de uma transação, envolva a chamada:
Os cronogramas de migração para esses programas podem ser reduzidos em 50% a 75%, mesmo para stored procedures complexas com dependências pesadas de pacotes PL/SQL. Essa eficiência decorre de um processo de tradução mecânica que preserva a lógica de negócios original, garantindo que a equipe de SQL possa continuar seu trabalho de manutenção sem interrupções. Além da migração em si, as equipes ganham uma nova e poderosa vantagem: uma plataforma unificada onde os mesmos dados governados alimentam seus dashboards, modelos de machine learning e iniciativas de IA.
A única maneira de saber se suas procedures podem ser traduzidas é testando uma. Escolha a menor stored procedure do seu lote, de preferência uma que ninguém goste de depurar. Crie um projeto de migração em seu workspace e comece a usar o Agentic Code Convertor!
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.