レガシーなストアドプロシージャをDatabricksに移行する手順を1行ずつ解説します。データウェアハウス移行の一環として、カーソル、一時テーブル、複数ステートメントのトランザクションがすべてSQLとして移行されます。
によって Abhishek Dey 、 ローラン・レタージェ による投稿
データウェアハウスのどこかで、毎晩何百ものストアドプロシージャが起動し、静かにビジネスを動かし続けていま す。これらは、とうの昔に退職したSQL開発者たちによって何年も前に書かれたものです。ネストされたカーソルがあり、実行時に一時テーブルを作成します。複数テーブルにまたがる更新を単一のトランザクションにまとめます。そして、47行目あたりには、ただ一言 「ここを変更しないこと」 とだけコメントが残されています。今や誰もこれらのプロシージャを完全には理解していません。それなのに、誰もがこれらに依存しています。収益ダッシュボード、決算処理、業務レポート、これらすべてが、何らかの形でプロシージャルSQLのビジネスロジックのレイヤーに遡ります。
データをレイクハウスに移行する方法はよく知られています。摩擦の原因となってきたのは、データウェアハウス移行におけるプロシージャルな核心部分です。つまり、ストアドプロシージャ、トランザクション処理、一時テーブル、制御フロー、そして企業の多くが依然としてSQLスキルに依存しているという事実です。移行の話が出るたびに、誰もが真っ先にこれらのプロシージャを指差しました。 「最小限の変更でこれを実行できるようになるまでは移行できない。我が社は依然として強力なSQL主導なのだから」と。
そこで私たちは、皆さんが今まさに思い浮かべているようなユースケース（移行プロジェクトでよく見られる複合的なプロシージャ）を取り上げ、レイクハウス上で一つずつ実証することにしました。この例はOracleの移行ユースケースに基づいていますが、あらゆるデータウェアハウス（レガシーまたはクラウドベース）に適用できま す。
このサンプルのプロシージャは、日次の注文を処理します。未処理の注文を一時テーブルにステージングし、顧客マスタと照合して検証し、失敗したものをループ処理して拒否理由を個別にログに記録します。その後、地域の収益サマリーを更新し、すべての注文を処理済みとしてマークします。これらすべてが、失敗時にロールバックされるトランザクション内で行われます。
決して止めてはならない夜間ジョブです。
以前は、これを移行するにはPythonとSparkで完全に書き直す必要がありました。何週間もの作業、新たなバグの発生、そして自社のビジネスロジックを維持できなくなるSQLチーム。
私たちは書き直したのではなく、変換したのです。
すべてのプロシージャは、シグネチャとセーフティネットから始まります。レガシー環境では、処理本体が BEGIN ... EXCEPTION ... END で囲まれていました。Databricksでは、代わりに DECLARE EXIT HANDLER FOR SQLEXCEPTION を使用します。考え方は同じですが、構文が少し異なります。セッションに適切なカタログとスキーマが設定されていると仮定しましょう。
大きな違いはコードにあるのではありません。デプロイ後に何が起こるかです。Databricksでは、プロシージャはUnity Catalogに登録されます。これにより、アクセス制御、列レベルのリネージ、そしてすべてのワークスペースにわたる検出可能性（ディスカバラビリティ）が得られます。現在のシステムでは、3人しかパスワードを知らないスキーマの中に存在していました。
レガシー | 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;（BEGINの前） | DECLARE v_id INT;（BEGINの内部） |
EXCEPTION WHEN OTHERS THEN | DECLARE EXIT HANDLER FOR SQLEXCEPTION |
参考資料： docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-create-procedure
元のプロシージャは、ステージング用と検証エラー用の2つの 一時テーブルを作成します。これらは、残りのロジックが依存する作業用スペース（スクラッチスペース）となります。
Databricksでは、これが移行の中で最もシンプルな部分の1つになります。 EXECUTE IMMEDIATEも、 ON COMMIT PRESERVE ROWSも不要です。セッションスコープの CREATE TEMP TABLEが直接の代替となりますが、1つだけ注意点があります。 CREATE OR REPLACE TEMP TABLEはまだサポートされていないため、同じセッション内で再実行可能にする必要がある場合は、事前にドロップ（削除）してください。
参考資料： docs.databricks.com/aws/en/tables/temporary-tables
これは、誰もが書き換えが必要になると想定していた部分でした。元のプロシージャは、検証エラーを1つずつループ処理し、問題のある注文を拒否して、その理由をログに記録します。典型的なカーソルパターンであり、何十年にもわたるレガシーシステム（Oracleなど）の慣習（マッスルメモリー）によるものです。
DatabricksのSQLスクリプティングは、Runtime 18.1以降、 OPEN、 FETCH、 CLOSEによるカーソルをネイティブにサポートしています。 %NOTFOUND 属性は CONTINUE HANDLER FOR NOT FOUNDになります。 ループラベルと LEAVEが EXIT WHENに代わります。
「処理する行がない場合はスキップしてログを記録する」という条件分岐のチェックは、ほとんど変わりませんでした。 SELECT ... INTOは SET var = (SELECT ...)になります。 それ以外はすべて同じです。
DatabricksのSQLスクリプティングは、プロシージャル開発に必要なツールキット（ IF/ELSE、 WHILE、 FOR、 LOOP、 REPEAT、 LEAVE、 ITERATE、 SIGNAL/RESIGNAL）を完全にサポートしています。コードベースに .GOTOや.LABELディレクティブを含むTeradata BTEQスクリプトがある場合、これらはLEAVE and ITERATEを使用したラベル付きループにマッピングされます。
参考資料： docs.databricks.com/aws/en/sql/language-manual/sql-ref-scripting
これが最後のピースであり、移行を実際に実現可能にした要素でした。元のプロシージャは regional_revenueを更新し、注文を処理済みとしてマークし、バッチをログに記録します。いずれかの部分が失敗した場合、すべてがロールバックされます。
レガシーシステムでは、これは明示的な COMMITを伴う暗黙的なトランザクションです。Databricksでは、 BEGIN ATOMIC ... ENDが同じセマンティクス（成功時の自動コミット、失敗時の自動ロールバック）を提供しますが、1つ大きな利点があります。それは「行レベルの競合検出」です。同じテーブルに書き込む並行バッチは、同じ行にアクセスする場合にのみ競合します。たとえば、OracleとSnowflakeはどちらもテーブルレベルのロックを使用するため、強制的にシリアル（順次）実行になります。
MERGE文はそのままDatabricksに移行できます。 BEGIN ATOMICが処理を行うため、明示的な COMMITは不要になりました。これにより、チームは並行バッチジョブが互いに干渉し合う心配をする必要がなくなりました。
このパターンを採用する際の、実用的な2つの注意点：
参考資料： docs.databricks.com/aws/en/transactions/
ビジネスロジックも制御フローもそのままです。Unity Catalogによって管理されます。
トランザクション内で実行するには、呼び出しをラップします。
これらのプログラムの移行期間は、重いPL/SQLパッケージの依存関係を持つ複雑なストアドプロシージャであっても、50〜75%削減できます。この効率性は、元のビジネスロジックを維持する機械的な変換プロセスによるものであり、SQLチームがメンテナンス作業をシームレスに継続できるようにします。移行そのものを超えて、チームは強力な新しいメリットを得ることができます。それは、 同じガバナンスが適用されたデータがダッシュボード、機械学習モデル、そしてAIイニシアチブを動かす、統合されたプラットフォームです。
プロシージャが変換可能かどうかを知る唯一の方法は、実際に試してみることです。バッチの中から最も小さなストアドプロシージャ（できれば誰もデバッグしたくないようなもの）を選んでください。ワークスペースで移行プロジェクトを作成し、Agentic Code Convertorを始めましょう！
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。