过去十年，同时使用Azure Databricks和微软Fabric（或前身Synapse）的企业，几乎都逃不开一条无奈的铁律：工程团队在Databricks上做数据处理，BI团队在Fabric里建报表，两份相同的数据表、两套治理模型，外加一个无人认领的夜间导出任务。这种重复并非技术事故，而是两个平台对数据存储位置和访问权限各自为政的必然代价。

如今这个前提已经被推翻。过去一年里，微软与Databricks悄悄将底层存储统一到了OneLake，并围绕Unity Catalog建立起共享的治理协议。截至2026年中，双向互操作已经落地，关键场景下实现了零拷贝——只要架构设计得当，你只需维护一份Delta表，用Databricks写入，通过Fabric仓库或Power BI直接查询，行级和列级安全策略在两端一致生效。但设计得不好，也完全可能把老问题换个Logo重新搬回来。真正的区别在于选择正确的集成路径。

首先要澄清一个常见误区：“Fabric与Databricks集成”并非单一功能，而是至少三种数据流模式各异的机制。选错门，是当前最常见的架构失误。

第一种是镜像Azure Databricks目录，现已正式可用。Fabric通过生成OneLake快捷方式——本质是虚拟链接而非物理拷贝——读取存储在ADLS Gen2上的Unity Catalog表。整个过程没有数据移动，也不存在复制延迟。Fabric定时轮询Unity Catalog的元数据，自动反映新增表、删除或模式变更；急用时可手动刷新。关键是，镜像表在Fabric中只读，真实数据源始终驻留在Databricks一侧。当Databricks掌控写入链路、Fabric仅充当消费界面时，这就是正确入口。

第二种门是面向Unity Catalog的OneLake外部位置（2026年6月Beta阶段），它直接把存储问题翻转过来。不再是Databricks写ADLS Gen2、Fabric做快捷方式，而是创建一个映射到OneLake路径的Unity Catalog外部位置，此后所有UC资产——托管表、视图、物化视图、流表——都直接落入OneLake。OneLake变成主存储，而非镜像别处的存储。这些表依然是完整的Unity Catalog托管表，预测优化、液态聚类和UC治理全部照常生效，唯一的区别是，从写入那一刻起，唯一的物理拷贝就已位于Fabric原生的湖里。

第三种门是“发布到Fabric”（预览阶段），它更像是连接前两种模式的纽带。其设计让Databricks中的资产可以更直接地暴露为Fabric语义模型和报告可用对象，进一步降低消费侧的理解门槛。虽然细节还在完善中，但它的出现表明双方正在把互操作从底层存储向上延伸到语义层。

三种门的共同底色是：单份数据、统一治理、零拷贝不再是愿景。但落脚点各不相同——是Databricks做主、Fabric消费；还是OneLake做主、Databricks直接写入；抑或需要快速共享语义成果——架构师必须在项目早期就做出清醒选择，而不是等表已经建好再补救。因为一旦走偏，等待你的仍然是那个熟悉的双份拷贝噩梦，只是Logo换了而已。

微软与Databricks这次的靠近，与其说是技术突破，不如说是对现实的妥协与共谋。双方都意识到，企业不会为了平台便利而放弃任意一端的计算能力，也不该再被迫在数据孤岛和治理碎片之间做选择。而OneLake加Unity Catalog的组合，正把那个用过时逻辑搭建的旧墙拆掉，让写与读、工程与BI，终于可以在同一份数据上各自运转。