Un guide pas à pas, ligne par ligne, de la migration d'une procédure stockée existante vers Databricks. Curseurs, tables temporaires et transactions multi-instructions migrent en SQL dans le cadre de la migration du data warehouse.
par Abhishek Dey et Laurent Léturgez
Quelque part dans votre entrepôt de données, des centaines de procédures stockées se réveillent chaque nuit et font tourner l'entreprise en toute discrétion. Elles ont été écrites il y a des années par un groupe de développeurs SQL qui ont quitté l'entreprise depuis longtemps. Elles contiennent des curseurs imbriqués. Elles créent des tables temporaires à la volée. Elles regroupent les mises à jour de plusieurs tables dans une seule transaction. Et quelque part vers la ligne 47, il y a un commentaire qui dit simplement : « Ne pas modifier. » Plus personne ne comprend vraiment ces procédures. Pourtant, tout le monde en dépend. Le tableau de bord des revenus, la clôture financière, le rapport des opérations, tous, d'une manière ou d'une autre, découlent de ces couches de logique métier SQL procédurale.
Le transfert de données vers le lakehouse est un processus bien maîtrisé. Les points de friction résident dans le cœur procédural de toute migration d'entrepôt de données : les procédures stockées, la gestion des transactions, les tables temporaires, le flux de contrôle, et le fait qu'une grande partie de l'entreprise repose encore sur des compétences SQL. Chaque fois qu'une migration était évoquée, ces procédures étaient les premières pointées du doigt : « Nous ne pouvons pas migrer tant que nous ne pouvons pas exécuter cela avec un minimum de modifications. Notre entreprise est encore très axée sur le SQL. »
Nous avons donc décidé de prendre un cas d'usage comme celui auquel vous pensez probablement en ce moment, une procédure composite que nous avons rencontrée lors de diverses migrations, et de le présenter, étape par étape, sur le Lakehouse. Cet exemple s'appuie sur un cas de migration Oracle, mais il peut s'appliquer à n'importe quel entrepôt de données (hérité ou cloud).
Cet exemple de procédure traite les commandes quotidiennes. Elle stocke temporairement les commandes non traitées dans une table temporaire, les valide par rapport au fichier client principal, parcourt les erreurs pour enregistrer chaque rejet individuellement, puis met à jour les synthèses de revenus régionaux et marque toutes les commandes comme traitées, le tout au sein d'une transaction qui s'annule en cas d'échec.
Un traitement nocturne qui ne doit absolument pas s'interrompre.
Auparavant, migrer cela signifiait tout réécrire, en Python et Spark. Des semaines de travail, de nouveaux bugs à identifier, et une équipe SQL qui ne pouvait plus maintenir sa propre logique métier.
Nous ne l'avons pas réécrite. Nous l'avons traduite.
Chaque procédure commence par une signature et un filet de sécurité. Le système hérité enveloppait le corps dans BEGIN ... EXCEPTION ... END. Databricks utilise DECLARE EXIT HANDLER FOR SQLEXCEPTION à la place ; même idée, syntaxe légèrement différente. Supposons que le catalogue et le schéma appropriés ont été définis dans la session.
La grande différence ne réside pas dans le code. Elle réside dans ce qui se passe après le déploiement. Sur Databricks, la procédure est enregistrée dans Unity Catalog. Elle bénéficie de contrôles d'accès, d'une traçabilité au niveau des colonnes (lineage) et d'une découvrabilité dans tous les espaces de travail. Dans le système actuel, elle résidait dans un schéma dont seules trois personnes possédaient le mot de passe.
Système hérité | 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; avant BEGIN | DECLARE v_id INT; à l'intérieur de BEGIN |
EXCEPTION WHEN OTHERS THEN | DECLARE EXIT HANDLER FOR SQLEXCEPTION |
Référence : docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-create-procedure
La procédure d'origine crée deux tables temporaires pour le staging et les échecs de validation. Elles constituent l'espace de travail temporaire dont dépend le reste de la logique.
Sur Databricks, cela devient l'une des parties les plus simples de la migration. Pas de EXECUTE IMMEDIATE. Pas de ON COMMIT PRESERVE ROWS. L'instruction CREATE TEMP TABLE limitée à la session est le remplacement direct, avec une petite mise en garde : CREATE OR REPLACE TEMP TABLE n'est pas encore prise en charge, il faut donc d'abord supprimer la table (drop) si vous devez pouvoir la réexécuter dans la même session.
Référence : docs.databricks.com/aws/en/tables/temporary-tables
C'était l'élément que tout le monde pensait devoir réécrire. La procédure d'origine parcourt les échecs de validation un par un, rejette chaque commande incorrecte et enregistre le motif dans les journaux. Un modèle de curseur classique. Des décennies de réflexes hérités (d'Oracle, par exemple).
Les scripts SQL de Databricks prennent en charge les curseurs de manière native, OPEN, FETCH et CLOSE depuis Runtime 18.1. L'attribut %NOTFOUND devient un CONTINUE HANDLER FOR NOT FOUND. Les étiquettes de boucle et LEAVE remplacent EXIT WHEN.
La vérification conditionnelle (s'il n'y a pas de lignes à traiter, ignorer et enregistrer) a à peine changé. SELECT ... INTO devient SET var = (SELECT ...). Tout le reste est identique.
Nos scripts SQL prennent en charge l'ensemble des outils procéduraux : IF/ELSE, WHILE, FOR, LOOP, REPEAT, LEAVE, ITERATE, SIGNAL/RESIGNAL. Si votre base de code contient des scripts Teradata BTEQ, les directives .GOTO et .LABEL s'associent à des boucles étiquetées à l'aide de LEAVE et ITERATE.
Référence : docs.databricks.com/aws/en/sql/language-manual/sql-ref-scripting
C'était la dernière pièce du puzzle, celle qui a rendu la migration réellement viable. La procédure d'origine met à jour regional_revenue, marque les commandes comme traitées et enregistre le lot. Si une partie échoue, tout est annulé (rollback).
Sur le système hérité, il s'agit d'une transaction implicite avec un COMMIT explicite. Sur Databricks, BEGIN ATOMIC ... END offre la même sémantique, une validation (commit) automatique en cas de succès, une annulation (rollback) automatique en cas d'échec, avec un avantage de taille : la détection des conflits au niveau des lignes. Les lots simultanés qui écrivent dans la même table n'entrent en conflit que s'ils touchent aux mêmes lignes. Par exemple, Oracle et Snowflake utilisent tous deux un verrouillage au niveau de la table, ce qui impose une exécution séquentielle.
L'instruction MERGE peut être migrée vers Databricks telle quelle. Le COMMIT explicite a disparu car BEGIN ATOMIC s'en charge. Et l'équipe a cessé de s'inquiéter des conflits entre les tâches de traitement par lots simultanées.
Deux remarques pratiques lorsque vous adoptez ce modèle :
Référence : docs.databricks.com/aws/en/transactions/
Même logique métier. Même flux de contrôle. Géré par Unity Catalog.
Pour l'exécuter au sein d'une transaction, encapsulez l'appel :
Les délais de migration de ces programmes peuvent être réduits de 50 à 75 %, même pour les procédures stockées complexes présentant de lourdes dépendances aux packages PL/SQL. Cette efficacité découle d'un processus de traduction mécanique qui préserve la logique métier d'origine, garantissant que l'équipe SQL peut poursuivre son travail de maintenance en toute transparence. Au-delà de la migration elle-même, les équipes bénéficient d'un nouvel avantage de taille : une plateforme unifiée où les mêmes données gouvernées alimentent leurs tableaux de bord, leurs modèles de machine learning et leurs initiatives d'IA.
Le seul moyen de savoir si vos procédures se traduisent correctement est d'en essayer une. Choisissez la plus petite procédure stockée de votre lot, de préférence une que personne n'aime déboguer. Créez un projet de migration dans votre espace de travail et commencez à utiliser l'Agentic Code Convertor !
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.