Databricks近期发布了一份战略框架，指导企业将数据和人工智能工作负载从Google BigQuery迁移到开放的Databricks Lakehouse架构。该框架指出，迁移不仅仅是复制表，而是一项需要分阶段推进的战略演进，涉及流程、技术和人员三大支柱，旨在以最小 disruption 实现可衡量的业务影响。
许多组织目前在BigQuery上运行多种数据和分析工作负载，但正在探索如何将BI、ETL和多模态AI工作负载纳入统一的治理和运营模型。开放的Lakehouse架构配合统一的治理层，可以帮助简化运营、跨数据和AI streamlining 合规性、在需求增长时提供可预测的性能，并为新的AI驱动用例奠定基础。
流程支柱定义了如何迁移。迁移旅程按顺序进行：评估现状、选择入口点、执行迁移、在双运行中验证，然后退役旧平台。评估是第一步，因为不了解当前运行情况就无法选择正确的入口点。企业应首先对BigQuery资产进行剖析，包括数据集、查询历史和槽位消耗，以找出哪些工作负载驱动成本、哪些仪表板实际被使用、哪些表从未被查询。开源工具Lakebridge包含一个BigQuery剖析器，可以自动化这一发现过程，从而围绕实际使用情况而非仅仅存在的内容来规划迁移波次。
选择策略时，有两种主要路径：BI优先和ETL优先。BI优先适合那些需要扩展仪表板/数据产品并且分析师希望使用AI功能的团队。企业可以在Databricks上重建最常用的仪表板，初期直接读取BigQuery数据，然后逐个用例切换团队，并排证明一致性。回报从第一天起就可见：更快的仪表板和Genie的自然语言问答。ETL优先则优先考虑后端，目标是将转换工作负载整合到Databricks的Photon/Spark引擎上，优化成本和性能。这条路径适合希望先建立AI就绪的数据基础，然后让下游消费者如仪表板和应用程序跟进的团队。权衡之处在于可见性：业务用户在管道落地之前几乎看不到变化，因此需要随每个波次发布运行时和效率指标。当不确定时，让评估来决定：高仪表板使用率指向BI优先；重型转换工作负载指向ETL优先。
无论选择哪种入口点，都应分波次迁移，而不是一次性切换。一次性切换将所有风险集中在单一时刻，一旦出现问题，整个项目的信任也会受损。波次可以缩小影响范围：根据对组织的价值（领导层可见度、直接影响收入的程度、合规截止日期的紧迫性、日常依赖人数）和迁移复杂性两个维度对工作负载进行排序，从高价值、低复杂性的地方开始。每个波次都应交付可见的业务成果，在下一波次开始前进行对账，并使团队的操作手册更加成熟。只有对于小型、低风险的资产，当运行两个平台的成本超过其保护价值时，才考虑一次性切换。
执行阶段包括直接迁移和现代化改造。直接迁移将现有SQL逻辑原样迁移到Databricks Lakehouse，快速建立可工作的基线，让团队在优化前验证一致性。现代化改造则在稳定后，将高价值管道重构为Lakeflow Spark声明式管道，实现自动化编排、内置数据质量以及批流统一的框架。大多数组织会经历一个双运行阶段，使用Lakehouse Federation来“影子”工作负载进行验证。投资回报的关键是设定明确的成功标准（例如99.9%的一致性），以触发立即退役旧管道，消除运行两个平台的成本。
双运行可以双向进行，正确的桥梁取决于入口点。BI优先的团队使用Lakehouse Federation让Databricks读取BigQuery，同时仪表板先迁移。ETL优先的团队则反过来：将数据摄入和转换迁移到Databricks，将整理好的表以开放格式落地，让BigQuery继续从同一份单一副本为现有仪表板和应用程序提供服务——无需双写管道、无需导出作业、无需协调第二份副本。
迁移波次可以保持双运行窗口短暂而狭窄：只有当前波次的工作负载承担同时运行在两个平台上的成本，因此双运行的费用与实际进行中的工作成比例，而非整个资产。将BigQuery视为服务层是一种过渡状态而非目的地：外部表在BigQuery侧是只读的，并且存在限制，例如模式更改后需要手动刷新模式，因此应将服务层的切换作为旅程的最后一步。
治理方面，Unity Catalog将治理从障碍转变为战略引擎。它提供无缝的三层映射（项目→目录，数据集→模式，表→表），复制BigQuery权限，同时增加自动的端到端血缘，并将AI模型视为一等公民。这种映射比对象层次更深。Unity Catalog原生提供同样的细粒度保护：行过滤器逐行限制访问，列掩码和标签处理列级安全——因此保护随数据一起移动，而不是从头重建。一个来自现场的排序规则：先迁移权限，再迁移数据，这样每个波次的切换只改变表的位置，而不改变谁可以看到它。
技术支柱侧重于将数据迁移到Google Cloud Storage等服务的开放格式，将逻辑迁移到Databricks SQL和Spark，并验证结果。从BigQuery迁移到Databricks涉及三个工作流：数据迁移、逻辑迁移和验证。
数据迁移根据数据量和新鲜度选择路径。批量历史数据通过BigQuery导出到Google Cloud Storage上的Parquet最快，通常是大规模下最经济的路线，而且导出同时作为冻结的时间点副本，简化验证。持续更新的表通过Storage API连接器读取或在源端重定向，小型且频繁变化的数据集可以通过联邦查询保持可查询，直到其波次到来。所有数据都以开放格式落地，为medallion层做好准备。
逻辑迁移方面，永远不要手动转换整个资产。三个层级覆盖：基于规则的转译（如Lakebridge）处理大部分常规SQL，LLM辅助转换处理方言差异，工程师保留给真正复杂的尾部。编排遵循相同模式：计划查询和Composer DAG映射到Lakeflow Jobs。
验证应像迁移本身一样认真预算——在现场，它通常消耗相当的努力。在三个层面运行验证：完整性（行数）、一致性（模式和类型）和准确性（聚合对账加行级哈希），使用Lakebridge reconcile自动化，它支持BigQuery作为原生源。一个现场教训：两个SQL方言之间小的内置函数差异可能破坏哈希比较——在假设数据丢失之前调查不匹配。这里的一致性是流程旅程中触发退役的关键。
开放表格式的回报在迁移完成之前就已经显现。由于Delta Lake和Apache Iceberg是开放格式，落地在Google Cloud Storage上的表可以被不止Databricks读取：BigQuery通过BigLake外部表读取Delta，通过Iceberg外部表读取Iceberg，而Unity Catalog和BigQuery之间的目录联邦（目前处于预览阶段）让两个平台无需复制即可治理和查询相同的表。存储与引擎解耦——一份数据，多个引擎。这种互操作性不是副作用；它是流程部分描述的低风险过渡模式背后的能力。
人员支柱提供迁移的最终投资回报：一个更有能力、统一的劳动力。结束交接文化。在传统栈中，SQL分析师和数据科学家之间的差距造成孤岛。在Databricks中，共享笔记本让整个“小队”生活在同一个工作空间，减少沟通开销。
构建新技能集。Genie作为SQL密集型团队的桥梁。分析师可以使用自然语言生成Python或Spark代码，将传统分析师转变为多才多艺的数据从业者，而无需陡峭的学习曲线。将日常AI辅助与结构化培训、Databricks Academy课程和基于角色的认证相结合，使新技能集在整个组织扎根，而不是依赖于少数自学成才的早期采用者。
工程严谨性。团队通过采用Unity Catalog、Git集成和CI/CD等软件工程最佳实践，从“编写查询”转向“构建数据产品”。
来自现场的六条经验：规划前先剖析；在双运行开始前定义一致性标准；不要手动转换SQL；先一对一映射治理，再现代化；将BI优先视为变更管理项目；合理调整平台足迹。
结论：迁移到Databricks不是一次跳跃，而是一系列可以实际规划的决策：哪个入口点适合你的团队，如何安排波次以便每个波次在下一个开始前获得成果，以及哪个桥梁让BigQuery和Databricks并行运行直到最后一个仪表板切换。把顺序搞对，流程、技术和人员就会相互加强：数据迁移、逻辑转换和验证退役旧的资产，为AI就绪的Lakehouse让路。