微软正在把 Power Query 连接器的底层驱动从 ODBC 迁到 ADBC，这次轮到 Databricks。适用于 Power BI 和 Microsoft Fabric 的 Databricks ADBC 连接器已正式 GA(Generally Available，正式发布)。对每天跟 Databricks 打交道的分析师来说，这不是一次普通的版本更新，而是整个连接层技术栈的换代：语义模型(Semantic Model)、数据流(Dataflow)和分页报表(Paginated Report)里已有的连接不会被动改变，迁移目前是按连接、按工作区、按租户逐级选择加入(opt-in)的。
换句话说，你可以完全不动现有资产，也可以挑一张报表先试水。真正值得关注的是 ADBC 带来的三个变化：内存安全与垃圾回收等安全增强、对 Arrow 数据的原生高效读取、以及更完整的认证支持。下面拆开讲。
ADBC 到底解决了什么问题
ODBC 是上世纪九十年代的产物，它的数据交换模型是逐行、带序列化的。当你在 Power Query 里拉一张几千万行的 Databricks 表时，数据要在驱动层被序列化、复制、再反序列化，开销全落在刷新时间里。
ADBC(Apache Arrow Database Connectivity)换了一套思路：它定义了一组标准接口直接操作 Arrow 列式内存格式。列式数据在驱动和引擎之间传递时不需要序列化和拷贝，抓取大数据集的额外开销极小。这是它相对 ODBC 最实质的优势，也是微软推动这次迁移的技术底气。
安全性上，ADBC 驱动本身具备内存安全和垃圾回收等特性，比 C/C++ 写的传统 ODBC 驱动更不容易出内存层面的问题。
有一点必须说清楚，避免误读：这次迁移只是不再使用 Power BI 内置的 ODBC 驱动。如果你用的是自己单独安装的 ODBC 驱动，行为不会变。也就是说，受影响的只是"随 Power BI 一起发货"的那部分驱动。
本次 GA 覆盖的连接器对应关系很直接：
| 连接器 | 原驱动 | 新驱动(GA) | | --- | --- | --- | | Databricks | Simba Spark ODBC | Databricks ADBC | | Azure Databricks | Simba Spark ODBC | Databricks ADBC |
认证方面，Databricks ADBC 支持 OAuth(用户)、OAuth(M2M / 客户端凭据)以及 Microsoft Entra ID，覆盖了企业里最常见的几种接入方式。
三种验证路径，按控制粒度选
官方给了三种启用方式，本质上是按"你想控制到多细"来排序的。建议从最小的粒度开始。
第一种：按连接 opt-in，用 Implementation="2.0"
这是对比 ADBC 和 ODBC 最快的方法，适合针对某一张报表或某个数据集做验证。在 Power Query 表达式的 source 步骤里加上这个选项：
Source = Databricks.Catalogs("adb-1234567890.1.azuredatabricks.net",
"/sql/1.0/warehouses/<warehouse-id>",
[Implementation="2.0"])
刷新数据集，把行数、列类型、汇总值跟生产基线逐项对比。如果想强制走回 ODBC 做并排比较，把值改成 Implementation="1.0" 即可。这种方式的妙处在于：改动只影响这一个连接，出问题随时回退，风险可控。
第二种：在验证工作区里覆盖默认值
要同时验证多张报表时，工作区管理员可以只对某一个工作区打开 ADBC，租户里其他部分继续用旧驱动。把待测报表发布到这个工作区，按平时的刷新计划跑就行。这样既隔离了影响范围，又能批量验证。
第三种：租户级默认启用
结果确认无误后，租户管理员可以在 Admin portal 里打开"Users can connect to data sources by using Apache Arrow database connectivity (ADBC)"。此后租户内的新连接默认走 ADBC，Desktop 和 Service 保持在同一驱动上，不会出现两端行为不一致的尴尬。
验证阶段该盯什么
ADBC 驱动的定位是"兼容性保持"的替代品，目标是替换 Simba Spark ODBC 而不改变结果。但兼容性保持是设计目标，不等于零风险。在租户级启用之前，务必先在 Desktop 里验证关键报表。
具体盯三件事：刷新是否成功、行数与列数据类型是否与基线一致、关键汇总值有没有漂移。任何异常——刷新失败、汇总值变了、性能回退——都可以发到 adbcmigration@microsoft.com，附上租户 ID、连接器、M 表达式和你观察到的现象。这些信息越完整，排查越快。
时间线与行动建议
Power BI 服务从 ODBC 迁到 ADBC 的过程会贯穿到 2027 年第一季度。这个时间窗口看起来宽裕，但迁移这种事，越早验证越主动。等到租户级切换真正落地时，如果你的报表早就验证过，那就是一次无感的切换；如果拖到最后才动，风险会集中爆发。
这周就可以做的事：读一遍 Databricks 连接器文档，装上最新的 Power BI Desktop，挑一张跑在 Databricks 上的生产报表，在 source 步骤加上 Implementation="2.0"，然后对比行数、列数据类型和关键汇总值。发现任何不符合预期的现象，直接反馈给上面的邮箱。
驱动换代这种事，平时不显山露水，但它决定了你刷新报表时数据在底层怎么流动。ADBC 把这条路径从"逐行序列化"换成了"列式零拷贝"，对重度依赖 Databricks 大表的团队来说，这笔账迟早要算。
