从 BigQuery 迁移到 Databricks：一套战略框架

迁移作为战略演进

如今，许多组织在 BigQuery 上支持一系列数据和分析工作负载，但正在探索将 BI、ETL 和多模型 AI 工作负载纳入单一治理和运营模型的方法。一个带有统一治理层的开放 Lakehouse 可以帮助简化运营、简化数据和 AI 的合规流程、随着需求增长提供可预测的性能，并为新的 AI 驱动用例奠定基础。

成功的迁移不仅仅是复制表。它需要分阶段的策略：将数据迁移到 Google Cloud Storage 等服务上的开放格式，审慎地转换逻辑，并使用自动化工具验证结果。本指南概述了一个跨三大支柱——流程、技术和人员——的迁移框架，以最小干扰和可衡量的业务影响来引导这一过渡。

流程：迁移之旅与治理演进

流程支柱定义了如何迁移。成功取决于选择正确的切入点并有效管理过渡期。

评估

迁移之旅按顺序进行：评估资产、选择切入点、迁移、在双运行中验证，然后退役。评估先于一切：不了解当前运行的内容，就无法选择正确的切入点。首先对 BigQuery 资产进行剖析——数据集、查询历史和槽位消耗——以找出哪些工作负载驱动成本、哪些仪表板实际被使用，以及哪些表从未被查询过。Lakebridge 是开源 Databricks Labs 迁移工具包，包含一个 BigQuery 剖析器，可自动化这一发现过程，从而围绕实际使用的内容而非仅仅存在的内容来规划迁移批次。

选择策略

• BI 优先：优先处理决策者每天看到的仪表板。此路径适合仪表板/数据产品需要扩展且分析师希望使用 AI 功能的团队。在 Databricks 上重建最常用的仪表板，首先就地读取 BigQuery 数据，并逐个用例切换团队，并排证明一致性。收益从第一天就可见：更快的仪表板和 Genie 的自然语言问答。
• ETL 优先：当目标是将转换工作负载整合到 Databricks 的 Photon/Spark 引擎并优化成本和性能时，优先处理后端。此路径适合希望首先建立 AI 就绪的数据基础，并让仪表板和应用程序等下游消费者跟随的团队。权衡之处在于可见性：业务用户在管道落地之前几乎看不到变化，因此每批次发布运行时和效率指标。如有疑问，让评估来决定：仪表板使用率高指向 BI 优先；繁重的转换工作负载指向 ETL 优先。

无论选择哪个切入点，都要分批迁移，而不是一次性切换。一次性切换会把所有风险集中在同一时刻——一旦出问题，整个项目也会失去信任。分批迁移能把影响范围控制得很小：按两个维度对工作负载排序——对组织的价值（对领导层的可见度、与收入的直接关联程度、背后合规截止日期的紧迫性、日常依赖它的人数）和迁移复杂度——从价值高、复杂度低的地方开始。每一批迁移都要交付一个可见的业务成果，在下一批开始前完成核对，并让团队的操作手册在下一批中更加高效。只有极少数规模小、风险低的场景才适合一次性切换，因为在这种情况下，同时运行两个平台的成本高于它所带来的保护。 

执行

1. 直接迁移：将现有 SQL 逻辑“原样”迁移到 Databricks Lakehouse。这样可以快速建立可用的基线，让团队在优化前验证一致性。
2. 现代化改造：稳定之后，将高价值管道重构为 Lakeflow Spark Declarative Pipelines，以实现自动化编排、内置数据质量，以及同时支持批处理和流处理的统一框架。

大多数组织会借助 Lakehouse Federation 进入双运行阶段，对工作负载进行“影子”验证。实现 ROI 的关键是设定明确的“成功标准”（例如 99.9% 的一致性），以此触发立即下线旧管道，从而消除运行两个平台的成本。

双运行是双向的，合适的过渡方式取决于你的切入点。以 BI 为先的团队使用 Lakehouse Federation，让 Databricks 读取 BigQuery，同时先迁移仪表板。以 ETL 为先的团队则反过来：将数据摄取和转换迁移到 Databricks，以开放格式落地整理后的表，并让 BigQuery 继续从这同一份数据为现有仪表板和应用提供服务——无需双写管道、无需导出作业、无需第二份数据来核对。 

分批迁移能让这个双运行窗口保持短而窄：只有当前批次中的工作负载承担同时运行在两个平台上的成本，因此双运行的费用与实际在迁移中的部分成正比，而不是整个数据资产。把 BigQuery 作为服务层视为过渡状态而非最终目标：外部表在 BigQuery 一侧是只读的，并且存在一些限制，例如模式变更后需要手动刷新模式，因此要把服务层切换到 Databricks Lakehouse 作为整个迁移旅程的最后一步。

治理

Unity Catalog 将治理从障碍转变为战略引擎。它提供无缝的三层映射（Project → Catalog、Dataset → Schema、Table → Table），在复刻 BigQuery 权限的同时，增加了自动的端到端血缘，并将 AI 模型视为一等公民。

这种映射比对象层级更深入。Unity Catalog 原生提供同样细粒度的保护：行过滤器逐行限制访问，列掩码和标签处理列级安全——因此保护随数据一起迁移，而不是从头重建。还有一条来自实践的顺序规则：先迁移权限，再迁移数据，这样每一批切换只改变表所在的位置，而从不改变谁可以看到它。

技术：构建开放基础

技术支柱侧重于将数据迁移到 Google Cloud Storage 等服务上的开放格式，将逻辑迁移到 Databricks SQL 和 Spark，并验证结果。 

从 BigQuery 迁移到 Databricks 涉及三个工作流：数据迁移、逻辑迁移和验证。

数据迁移

根据数据量和新鲜度选择路径。批量历史数据通过 BigQuery 导出为 Google Cloud Storage 上的 Parquet 格式速度最快，在大规模场景下通常是经济实惠的路线，而且导出同时充当冻结的时间点副本，简化了验证。持续更新的表通过 Storage API 连接器读取或在源端重定向，而小型、频繁变化的数据集可以通过联邦查询保持可查询状态，直到其迁移批次到来。所有数据都以开放格式落地，为奖章分层做好准备。

逻辑迁移

永远不要手工转换整个资产。三个层级可以覆盖：基于规则的转译（例如 Lakebridge）处理大部分常规 SQL，LLM 辅助转换处理方言的特殊之处，工程师则保留给真正复杂的尾部工作。编排遵循同样的模式：计划查询和 Composer DAG 映射到 Lakeflow Jobs。

验证

像对待迁移本身一样认真地对待验证预算——在实际项目中，它通常消耗相当的努力。在三个层面运行验证：完整性（行数）、一致性（模式和类型）以及准确性（聚合对账加行级哈希），通过 Lakebridge reconcile 自动化，它支持 BigQuery 作为原生源。一个现场教训：两种 SQL 方言之间小的内置函数差异可能会破坏哈希比较——在假设数据丢失之前先调查不匹配之处。这里的对等性是触发 Process 旅程中退役的关键。

开放表格式

开放基础在迁移完成之前就已见效。由于 Delta Lake 和 Apache Iceberg 是开放格式，你落在 Google Cloud Storage 上的表可以被不止 Databricks 读取：BigQuery 通过 BigLake 外部表读取 Delta，通过 Iceberg 外部表读取 Iceberg，而 Unity Catalog 与 BigQuery 之间的目录联邦（目前处于预览阶段）让两个平台无需复制即可治理和查询相同的表。存储与引擎解耦——一份数据副本，多个引擎。这种互操作性不是附带好处；它是 Process 部分所述低风险过渡模式背后的能力。

人员：组织现代数据 + AI 团队

第三个支柱提供了迁移的最终 ROI：一支能力更强、更统一的劳动力队伍。

终结交接文化。在遗留技术栈中，SQL 分析师和数据科学家之间的差距造成了孤岛。在 Databricks 中，共享 Notebook 让整个“小队”生活在同一个工作区中，减少了沟通开销。

构建新技能组合。Genie 为重度依赖 SQL 的团队充当桥梁。分析师可以用自然语言生成 Python 或 Spark 代码，将传统分析师转变为多面手数据从业者，而无需经历陡峭的学习曲线。将这种日常 AI 辅助与结构化培训、Databricks Academy 课程和基于角色的认证相结合，让新技能组合在整个组织内扎根，而不是依赖少数自学成才的早期采用者。

工程严谨性。团队通过采用 Unity Catalog、Git 集成和 CI/CD 等软件工程最佳实践，从“编写查询”转向“构建数据产品”。

来自一线的经验

基于我们的迁移项目经验，成功的 BigQuery 迁移中反复出现六种模式：

• 先分析再规划。在大多数数据资产中，相当一部分 BigQuery 表很少或从未被查询。先分析查询历史和槽位使用情况，意味着你可以迁移真正重要的工作负载，并淘汰其余部分。
• 在双跑开始前定义一致性标准。提前商定成功阈值（例如，行数、聚合和哈希的 99.9% 对账率）——没有它，影子期就没有退出条件。
• 不要手工转换 SQL。 基于规则的转译加上 AI 辅助转换可处理大部分资产；将工程师保留给真正复杂的剩余部分。
• 先一对一映射治理，再现代化。 项目 → 目录、数据集 → 模式、表 → 表映射到 Unity Catalog，可在第一天保留现有权限——包括行级和列级策略；更丰富的标记、基于属性的控制和血缘驱动的治理可以在切换后演进。
• 将 BI 优先视为变更管理项目。 技术往往是比较容易的一半；仪表板迁移的分析师需要赋能、倡导者和反馈循环。
• 合理确定平台规模。一旦工作负载在 Databricks 上得到验证，就淘汰重复的处理，以避免在两个地方运行并为相同的工作付费（“双重泡沫”）。庆祝完成的迁移，而不仅仅是上线。

结论

迁移到 Databricks 不是一次跳跃——而是一系列你可以实际规划的决策：哪种入口点适合你的团队，如何安排波次以便每一波在下一波开始前锁定胜利，以及哪种桥梁能让 BigQuery 和 Databricks 并行运行，直到最后一个仪表板切换。把顺序安排对了，流程、技术和人员就会相互强化：数据迁移、逻辑转换和验证在一侧淘汰资产，而分析师用 Genie 以自然语言查询、工程师交付受治理的数据产品则在另一侧构建。

结果是一个开放的湖仓、一个你的组织可以逐波信任的迁移，以及一个准备好在其落地基础上继续构建的团队。

准备好规划你的迁移了吗？探索 Databricks 迁移中心，使用开源 Lakebridge 工具包评估你的资产，或联系你的 Databricks 客户团队进行迁移评估。