资源介绍
视频数量：103个
总时长：7小时34分
课程介绍：
企业级数据仓库迁移到Lakehouse架构实战
三年前，我参与了一个Teradata到Lakehouse的迁移项目。18个月，迁移了4200张表，每张表的数据都完整复制，每个ETL任务都显示绿灯。然而财务部门每天早上依然在老的Teradata上跑当天的报表，因为没有人敢把业务切换到新平台。最终CFO走进会议室，说了一句让所有人沉默的话：烧掉的预算大概是最初估算的六倍。
这个场景并不罕见。在企业级数据仓库迁移领域，大约三分之一的项目会停滞或者被回滚。更讽刺的是，这些失败很少发生在数据搬运环节——字节搬运得很顺利，问题出在别的地方。我把这个现象叫做“逻辑税”：三十年积累的业务规则，埋藏在无人记录的存储过程里，隐藏在隐式的NULL处理逻辑里，散落在递归宏和级联触发器里。这些东西从来没有人完整地写下来过，但业务每天都在依赖它们运行。
这门课就是从这场葬礼开始的。我们不聊Databricks有哪些酷炫功能，我们聊真实的企业迁移项目是怎么死的，然后告诉你怎么活下来。
课程的第一部分从尸检开始。你得先读懂遗留系统的AWR报告，从Oracle的等待事件里找到真正的性能瓶颈；你要学会解析Teradata的DBQL和SQL Server的Query Store，从日志里还原那些没人说得清楚的批量任务；你要绘制出存储过程的依赖关系图，画出表的访问热度图，把那些沉睡了几十年的逻辑挖出来晒太阳。只有把遗产真正读懂，你才知道该扔什么、该留什么、该用什么替换。
接下来是关键决策点：Rehost、Replatform还是Re-architect。这三个R不是随便选的，每一个都涉及真实的成本和风险。大多数遗留系统的组合是60% Rehost、30% Replatform，只有10%值得彻底重新设计。选错的后果很直接——要么迁移完发现省的钱还不够付维护费，要么重构了三个月发现那个报表只有三个人在用。课程会带你用TCO计算器把三年的账算清楚，然后用一张评估计分卡说服CFO。
Lakehouse Federation是一个被低估的策略。它不是让你一次性把所有数据搬到新平台，而是先用联邦查询的方式连接新旧系统，让业务在不需要迁移的情况下先尝到Lakehouse的甜头。这种渐进式的过渡模式能大幅降低政治阻力，但也有自己的陷阱——跨引擎查询的延迟和成本会在某个时间点突然爆发。课程会告诉你什么时候该Federate，什么时候该Migrate，怎么判断这个临界点。
Schema翻译是另一个高风险环节。Lakebridge能帮你自动转换DDL，但有些数据类型转换会悄悄丢失精度。200列的Teradata大表和地理空间数据尤其麻烦，生成的SQL语法上完全正确，运行时却返回错误结果。这一部分会手把手演示如何在真实DDL上跑Lakebridge的Analyzer和Converter，怎么审计生成的Schema是否有语义漂移，怎么处理那些Lakebridge永远也搞不定的硬骨头。
存储过程是迁移的灵魂。PL/SQL不是SQL，它有控制流、有状态、有隐式的执行顺序。你不能直接让AI翻译，必须先把业务逻辑从代码里剥离出来，用颜色标记每个代码块，理解它的真实意图。课程会展示一种“尸检方法”，把级联触发器包拆解成可迁移的原子单元，告诉你哪些逻辑必须迁移、哪些逻辑在Lakehouse里有原生替代方案、哪些逻辑纯粹是技术债可以直接废弃。
从游标到DataFrame操作，从触发器到CDC，从临时表到CTE或Lakeflow声明式管道，从Oracle MERGE到Delta Lake MERGE INTO，从传统的SCD Type 2到Lakehouse的原生实现——这些模式翻译都有具体的对应关系。课程还总结了常见的反模式，比如把整个ETL跑在All-Purpose集群上因为觉得调试方便，比如给每个表都加上Liquid Clustering因为觉得总没坏处，这些看起来无害的选择在大规模场景下会变成成本噩梦。
AI辅助迁移是近两年的新变量。LLM可以把翻译速度提升好几倍，但也会引入新的风险：窗口函数的幻觉、事务语义的差异、语法正确但逻辑错误的代码。关键不是禁止使用AI，而是在AI生成的代码和人工审核之间建立严格的门控流程。课程提供了具体的Prompt模板和代码审计检查清单，帮助你在不牺牲质量的前提下享受AI的速度。
迁移的验证环节往往被低估。行数对上了就代表数据一致吗？不是。浮点数的精度差异会导致SUM的结果在Oracle和Spark之间出现微小偏差，这是真实存在的Bug，曾经造成过数百万美元的损失。课程设计了一套五层验证栈：行数校验、总和校验、校验和校验、哈希校验、语义校验。每一层解决不同类型的偏差，组合起来才能真正证明新旧系统的输出完全一致。你会学到如何构建自动化对账引擎，如何设计对账仪表盘让业务用户一眼看懂数据是否可信，以及为什么这些验证必须从第一天就开始运行，而不是等到项目快结束时才想起来。
并行运行是建立信任的唯一路径。课程会展示如何让Oracle和Databricks同时运行30天，完整跑完一个财务结算周期，对比两边的输出结果。切过模式的选择也很关键：是大爆炸式的一次切换，还是分批的软切过——先读只读流量，再切读写流量，最后再下线老系统。每一步都要有业务方的签收回执，因为最终承担责任的不是技术团队。
权限迁移是迁移后期最容易被忽视的部分。Oracle时代可能积累了500个角色，迁移到Unity Catalog后必须精简到十几个标签。直接复制原有的角色层级是行不通的，Unity Catalog的架构完全不同。你会学到如何设计标签体系，如何用ABAC（基于属性的访问控制）替代传统的RBAC，如何在Schema级别而非表级别打标签，以及如何配置动态视图实现行级安全和PII数据脱敏。
成本控制贯穿整个迁移过程。Databricks的计费模型远比传统数据库复杂：Jobs计算集群、All-Purpose计算集群、Serverless模式各自的适用场景是什么？Photon引擎的溢出问题怎么避免？系统表里藏着哪些你看不到的隐藏成本？课程会带你深入分析system.billing.usage的数据结构，建立归属和成本分摊模型，搭建成本分摊仪表盘，用数据证明迁移的价值而不是空口承诺。
最后的章节把前面所有内容串成一份完整的迁移行动手册：迁移的排序和并行策略、风险登记簿、72小时回滚窗口的设计、干系人沟通机制和指导委员会的运作方式。 capstone模拟了一个50TB Oracle数据仓库、500个存储过程、200份报表、5000万美元收入线的真实场景，从Go/No-Go决策矩阵开始，到48小时War Room的启动、叫停或回滚，完整走一遍整个决策流程。
这门课适合正在规划或执行EDW到Lakehouse迁移的架构师和技术负责人，适合需要对迁移方案做技术评审的技术总监，也适合需要向管理层解释迁移价值和风险的项目经理。如果你面对的是Oracle、Teradata或SQL Server上的核心业务系统，正在评估迁移方案或者已经在迁移路上踩过坑，这门课会帮你把那些零散的经验串成一个完整的体系。