打破SQL迁移迷思：新SQL特性让湖仓迁移更轻松
内容提要
本文介绍将传统数据仓库中的存储过程迁移至Databricks湖仓的方法。通过示例展示游标、临时表、事务等SQL脚本的翻译过程，保留原业务逻辑，无需重写为Python或Spark。迁移后由Unity Catalog管理，支持访问控制和血缘追踪，并发处理更高效，迁移时间可减少50-75%。
延伸解读
迁移核心：保留SQL逻辑，而非重写
文章强调，迁移存储过程的关键在于“翻译”而非“重写”。通过将游标、临时表、事务等SQL脚本直接转换为Databricks SQL脚本，保留了原有业务逻辑，避免了用Python或Spark重写带来的风险和额外工作量。这尤其适合依赖SQL技能的企业，让原有SQL团队能继续维护业务逻辑，降低迁移门槛。
Unity Catalog带来的治理优势
迁移后，存储过程注册在Unity Catalog中，获得访问控制、列级血缘和跨工作区的可发现性。相比传统系统中仅少数人掌握密码的schema，这显著提升了数据治理能力。同时，Databricks支持行级冲突检测，并发批处理仅在同一行冲突时才会阻塞，相比Oracle和Snowflake的表级锁，提高了并发效率。
迁移时间可减少50-75%
文章指出，即使对于依赖PL/SQL包的复杂存储过程，迁移时间也能减少50-75%。这得益于机械化的翻译过程，保留了原始业务逻辑，使SQL团队能无缝继续维护。但文章也提醒，实际效果需通过尝试最小的存储过程来验证，建议使用Agentic Code Convertor工具启动迁移项目。
Q&A
如何将传统数据仓库中的存储过程迁移到Databricks湖仓？
迁移时无需重写为Python或Spark，而是将存储过程逐行翻译为Databricks SQL脚本。例如，将Oracle的BEGIN...EXCEPTION...END替换为DECLARE EXIT HANDLER FOR SQLEXCEPTION，将临时表改为会话级CREATE TEMP TABLE，游标使用OPEN、FETCH、CLOSE等原生支持，事务用BEGIN ATOMIC...END实现自动提交或回滚。
Databricks SQL脚本如何支持游标？
Databricks SQL脚本从Runtime 18.1开始原生支持游标，包括OPEN、FETCH、CLOSE操作。%NOTFOUND属性用CONTINUE HANDLER FOR NOT FOUND替代，循环标签和LEAVE替代EXIT WHEN，SELECT...INTO改为SET var = (SELECT...)。
在Databricks中如何实现事务的原子性和回滚？
使用BEGIN ATOMIC...END语句，它提供自动提交和自动回滚的语义。如果事务内任何语句失败，整个事务会回滚。此外，Databricks支持行级冲突检测，并发事务只有在操作相同行时才会冲突，比表级锁更高效。
迁移到Databricks后，存储过程的管理有哪些改进？
迁移后，存储过程注册在Unity Catalog中，获得访问控制、列级血缘追踪和跨工作区的可发现性，相比传统模式（如只有少数人有密码）更安全、更易管理。
迁移存储过程到Databricks能节省多少时间？
迁移时间可减少50-75%，即使对于依赖PL/SQL包的复杂存储过程也是如此。这得益于机械翻译过程，保留了原始业务逻辑，使SQL团队能无缝继续维护。
Databricks SQL脚本支持哪些过程化编程结构？
支持IF/ELSE、WHILE、FOR、LOOP、REPEAT、LEAVE、ITERATE、SIGNAL/RESIGNAL等。Teradata BTEQ脚本中的.GOTO和.LABEL指令可映射为带标签的循环和LEAVE/ITERATE。
迁移存储过程时，临时表如何处理？
使用会话级CREATE TEMP TABLE直接替换，但需要注意CREATE OR REPLACE TEMP TABLE尚未支持，因此如果需要在同一会话中重新运行，需先DROP表。
