Apresentando Stored Procedures SQL no Databricks

Gerenciar tarefas repetitivas de SQL — como limpeza de dados, atualização de regras de negócios ou execução de lógica em lote — pode ser tedioso e propenso a erros se você copiar e colar código. 

Agora, os Procedimentos Armazenados SQL no Databricks (geralmente disponíveis) permitem que você armazene essa lógica uma vez, a execute sempre que precisar e a mantenha governada pelo Unity Catalog. 

Seja para limpar dados antes da análise, atualizar tabelas com base em critérios de negócios ou migrar cargas de trabalho de um data warehouse corporativo legado, os procedimentos armazenados tornam o processo mais simples, consistente e fácil de manter.

O Databricks suporta padrões abertos e interoperabilidade, evitando implementações proprietárias ou específicas de fornecedores. Os Procedimentos Armazenados SQL seguem o padrão ANSI/PSM SQL e serão contribuídos para o open source Apache Spark™.

Procedimentos são amplamente utilizados em tarefas administrativas, gerenciamento de dados e fluxos de trabalho de ETL — especialmente em data warehouses corporativos (EDWs). Para clientes que migram de EDWs para o Databricks, procedimentos armazenados existentes podem ser migrados sem reescrita, tornando a transição mais simples. E, como sempre, o melhor data warehouse é um lakehouse.

Para um de nossos casos de uso críticos em segmentação de clientes, aproveitamos os Procedimentos Armazenados SQL com DBSQL para obter melhor desempenho, escalabilidade e eficiência de custo. Estar familiarizado com SQL nos ajudou a implementar e implantar a solução em produção em um tempo muito curto. O uso de Procedimentos Armazenados nos permitiu gerenciar a lógica complexa de forma mais eficaz, mantendo a arquitetura geral simplificada e de fácil manutenção. —SambaSiva Rao, Sr. Data Engineer/Architect, ClicTechnologies

Os Procedimentos Armazenados SQL estão agora geralmente disponíveis.

Visão Geral dos Procedimentos Armazenados SQL

O que são Procedimentos Armazenados?

Em fluxos de trabalho de processamento de dados, os clientes podem ter dificuldades em manter a consistência e o desempenho de tarefas repetitivas e lógica complexa. Procedimentos armazenados são uma ótima abordagem nesses casos, garantindo que os dados sejam processados de forma consistente e padronizada, e que o desempenho seja otimizado. 

Para tarefas de limpeza de dados, procedimentos podem aplicar transformações como converter formatos de data inconsistentes em uma estrutura padronizada, remover espaços em branco no início e no fim de campos de texto e substituir ou corrigir valores errôneos. Isso garante que seus dados estejam preparados para análises posteriores. Veja o exemplo detalhado de ETL abaixo.

No lado do gerenciamento de dados, procedimentos armazenados podem atualizar eficientemente valores de tabelas com base em regras de negócios definidas — como sinalizar registros desatualizados, recalcular campos ou sincronizar dados entre tabelas relacionadas. Ao encapsular essas operações em procedimentos, as equipes podem garantir a execução consistente, reduzir a intervenção manual e melhorar a qualidade dos dados em escala. Veja o exemplo detalhado de gerenciamento de dados abaixo, usando procedimentos armazenados para atualizar um programa de fidelidade/assinatura.

Então, o que são Procedimentos? São coleções pré-compiladas de instruções SQL que permitem a um usuário gerenciar sua lógica SQL em uma unidade única e reutilizável. Procedimentos são armazenados no Unity Catalog, o que significa que são governados e encapsulam totalmente as permissões. Quando um procedimento armazenado é chamado, o banco de dados executa essas operações predefinidas, oferecendo o benefício de segurança aprimorada, manutenção simplificada de cargas de trabalho complexas e potencial para melhoria de desempenho.

O que é suportado?

Existem 5 comandos principais que suportam procedimentos: CREATE, CALL, DESCRIBE, SHOW e DROP.

• CREATE PROCEDURE: Define e armazena um novo procedimento armazenado no Unity Catalog. Ele especifica o nome do procedimento, parâmetros (se houver) e as instruções SQL a serem executadas quando o procedimento for chamado.
• CALL PROCEDURE: Executa um procedimento armazenado previamente criado; passando quaisquer parâmetros necessários.
• DESCRIBE PROCEDURE: Retorna os metadados básicos sobre um procedimento existente, como seu nome e parâmetros. Com EXTENDED, a descrição incluirá metadados adicionais, incluindo proprietário, data/hora de criação, tipo de segurança, etc.
• SHOW PROCEDURES: Lista todos os procedimentos armazenados disponíveis no esquema do catálogo atual.
• DROP PROCEDURE: Exclui um procedimento existente do armazenamento. 

Ao criar um procedimento, você pode usar vários tipos de parâmetros para controlar a entrada e a saída. 

• Parâmetro `IN`: Usado para passar valores para um procedimento como entrada. Por exemplo, você pode passar um ID de cliente para recuperar ou processar apenas os dados desse cliente. O procedimento pode ler, mas não modificar esses valores.
• Parâmetro `OUT`: Usado para retornar valores de um procedimento, após serem atribuídos. Por exemplo, você pode passar um ID de cliente e retornar o status da conta dele ou o total de vendas calculado, para processamento posterior fora do procedimento.
• Parâmetro `INOUT`: Serve a um propósito duplo, permitindo que um valor seja passado para um procedimento, modificado dentro dele, e o valor atualizado retornado. Ele funciona como entrada e saída. 

Esses parâmetros podem ser atribuídos a:

• Variáveis locais, declaradas dentro de um script/procedimento
• Variáveis de sessão, declaradas dentro da sessão, e até mesmo fora do script/procedimento

A lógica encapsulada em um Procedimento Armazenado SQL é construída sobre o SQL Scripting. Um procedimento armazenado pode ser considerado um script reutilizável com parâmetros, governado pelo Unity Catalog. Você pode ler sobre Scripting nestes dois blogs introdutórios:

• Introdução ao SQL Scripting Parte 1
• Introdução ao SQL Scripting Parte 2
• Revise a documentação de SQL Scripting

Chamadas de procedimentos aninhadas e recursivas são suportadas, o que significa que os clientes podem organizar suas unidades de trabalho ou lógica de negócios convenientemente em procedimentos separados, tornando todo o fluxo de execução SQL mais modular. Isso melhora a legibilidade e a manutenção.

Como os Procedimentos diferem das Funções?

Procedimentos são agrupados com Funções no Unity Catalog na interface do usuário. No entanto, procedimentos e funções, embora permitam reutilizar a lógica SQL, servem a propósitos diferentes.

Uma função é usada para retornar um valor ou uma tabela. Ela deve ser usada dentro de uma consulta SQL e não pode incluir SQL dinâmico ou lógica procedural. Um procedimento, por outro lado, é usado para executar uma sequência de instruções SQL. Ele pode incluir fluxo de controle, variáveis, loops e SQL dinâmico usando IDENTIFIER e EXECUTE IMMEDIATE. Você chama um procedimento como um comando autônomo, tipicamente para executar uma tarefa ou fluxo de trabalho.

Exemplos de uso de Procedimentos Armazenados SQL

Agora que cobrimos as capacidades dos Procedimentos Armazenados SQL, vamos explorar alguns exemplos para demonstrar seu valor e os problemas que eles ajudam a resolver.

Você pode usar este notebook para acompanhar — ele contém todos os exemplos deste post, bem como comandos de preparação de dados.

ETL – Limpeza de Dados: Preparando tabelas das camadas Silver ou Gold

Se você segue a arquitetura típica de medallion, sabe que mover dados de Bronze para Silver (ou de Silver para Gold) pode exigir limpeza, transformação, agregação e formatação de dados. Stored Procedures são ótimas para gerenciar processos repetitivos como esses em um fluxo de trabalho de ETL.

Neste cenário de ETL, um Procedure é usado para:

• Carregar dados brutos em uma tabela de fatos
• Selecionar dados com base no intervalo de datas e na origem da venda (web, mobile, ponto de venda, fornecedor 3p)
• Limpar e formatar os dados convertendo datas para um formato específico e removendo espaços em branco
• Após a limpeza, carregar os dados em uma tabela ‘limpa’
• Adicionar um registro de log com base no timestamp, datas de início/fim e origem da venda
• Usando o Procedure, consultar as vendas de aplicativos móveis para junho de 2025

Procedures como este ajudam a padronizar produtos de dados. Qualquer usuário deste procedure produzirá dados na mesma estrutura, independentemente do intervalo de datas ou ponto de venda. Este é um benefício primário da reutilização de código. A reutilização de código será naturalmente menos propensa a erros, pois a mesma lógica é executada toda vez.

Gerenciamento de Dados: Atualizar uma tabela com base em critérios de negócios

Gerenciamento de dados é a prática de garantir que seus dados sejam precisos, consistentes e acessados de forma eficiente — qualidades essenciais para qualquer organização que visa tomar decisões baseadas em dados. Sem um forte gerenciamento de dados, até mesmo os esforços de análise ou relatórios mais avançados podem ser prejudicados por informações não confiáveis ou inconsistentes.

Vamos examinar um exemplo encontrado em indústrias comerciais onde é comum um negócio estabelecer um programa de fidelidade para fornecer benefícios aos clientes com base em seu nível. Companhias aéreas têm programas de milhagem e a maioria das franquias de varejo tem programas de recompensas, etc. À medida que os clientes voam mais com a mesma companhia aérea ou compram mais itens da mesma franquia, os clientes ganham mais benefícios.

Aqui está um exemplo de como Stored Procedures podem ser usados para gerenciar e atualizar um programa de fidelidade de varejo padrão. Existem dois procedures usados para gerenciar os níveis de fidelidade do cliente, um para atualizar o nível de fidelidade de um cliente específico para o customerID fornecido, e outro que atualiza o nível de fidelidade do cliente para todos os clientes de um país fornecido.

Agora vamos usar o procedure criado para atualizar os níveis de fidelidade dos clientes da Sérvia, Alemanha e Canadá, e então verificar os registros atualizados:

A consulta anterior produz o seguinte resultado:

Ao encapsular a lógica de atualização de nível em procedures respectivos, evitamos a duplicação de código, ao mesmo tempo que removemos a complexidade do chamador, que só precisa invocar o procedure com os parâmetros apropriados.

Próximos passos?

Com SQL Stored Procedures agora no DBSQL, os clientes podem continuar a migrar cargas de trabalho de data warehouse corporativo legadas para o lakehouse. Com base no feedback dos clientes, existem várias capacidades importantes que queremos abordar à medida que avançamos para a disponibilidade geral (GA):

• SQL Stored Procedures no Apache Spark™: Suporte para todos os SQL Procedures no código aberto
• Suporte para SQL SECURITY DEFINER: Permitir que os clientes executem a lógica do procedure com as permissões do criador do procedure (definer)

Clientes que desejam compartilhar feedback ou solicitações relacionadas a SQL Scripting e Procedures podem fazê-lo através deste formulário.

Outros dois construtos SQL importantes são necessários para migrar Stored Procedures de sistemas legados: Tabelas Temporárias e Transações. Tabelas Temporárias já estão geralmente disponíveis no DBSQL, enquanto o suporte para Transações (multi-statement e multi-table) estará disponível em breve.

Se você já é um usuário Databricks ou está migrando de outro Data Warehouse, os Procedimentos Armazenados SQL são um recurso que você deve usar para simplificar o gerenciamento de fluxos de trabalho SQL complexos. Comece a usar os Procedimentos Armazenados SQL lendo a documentação do Databricks documentação.

Para saber mais sobre Databricks SQL, visite nosso site ou leia a documentação. Você também pode conferir o tour do produto para Databricks SQL. Se você deseja migrar seu data warehouse existente para um data warehouse serverless de alta performance com uma ótima experiência de usuário e menor custo total, então Databricks SQL é a solução — experimente gratuitamente.

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