Azure Databricks与Synapse创建Delta表的差异问题咨询

首先澄清一个常见误区：你看到的旧帖表述有明确的适用范围限制，不是整个Azure Synapse服务都不支持Delta表——该帖提到的“不支持Delta”，特指帖子发布时Synapse的专用SQL池、无服务器SQL池没有内置Delta格式解析能力，无法直接通过SQL引擎查询Delta格式数据；Synapse集成的Apache Spark计算池从正式发布起就内置了Delta Lake依赖，完全可以正常执行Delta格式的读写操作。

你在两个环境中运行同一段代码创建的表，本质差异主要有三点：

• 元数据打通范围不同
  在Databricks中运行以下代码：

  (df.write
   .format("delta")
   .option("path", "/file/path/location")
   .saveAsTable("MyTable"))
  

  生成的表元数据会存储在Databricks托管的元存储（Hive元存储或Unity Catalog）中，元数据会完整记录表的Delta格式属性、存储路径、Schema、事务日志关联关系，Databricks全栈计算引擎（Spark、SQL、Photon加速层）都能直接识别该表，可无限制使用Time Travel、ACID事务、增删改操作、CDC等全部Delta特性。
  在Synapse Spark池中运行相同代码时，虽然也会将数据按Delta格式写入指定存储路径、在Spark关联的元存储中注册表条目，但该元数据默认仅对Synapse Spark池可见。在旧版本Synapse中，你在专用/无服务器SQL池直接查询该表会直接报错，因为SQL引擎没有解析Delta事务日志的能力，无法识别这是Delta格式的数据集。
• Delta特性支持完整度不同
  Databricks是Delta Lake的原厂维护方，Runtime中集成的Delta版本是最新的，所有Delta原生特性都能100%兼容支持，写入的Delta表不会出现特性不兼容、数据读取异常的问题。
  Synapse Spark中集成的Delta依赖是微软自行适配打包的，版本更新节奏比Databricks官方版本慢3-6个月，不少新推出的Delta高级特性（比如Liquid Clustering、Change Data Feed高阶配置、Photon写入优化等）在Synapse侧无法正常使用，甚至可能出现写入后数据损坏的问题。
• SQL层查询逻辑不同
  目前新版本Synapse的SQL池已经支持查询Delta格式数据，但实现逻辑和Databricks完全不同：Synapse SQL是直接扫描存储路径下的Parquet数据文件、解析路径下的_delta_log事务日志来获取数据快照，没有做Delta层面的查询优化，查询性能远低于Databricks，且仅支持基础的读操作，不支持通过SQL直接对Delta表执行Update/Delete/Merge等写入操作。

简单总结：Synapse Spark里写出来的Delta表，只是数据文件格式符合Delta开源规范，能在Spark层面正常读写，但没有全栈引擎的原生支持，和Databricks里创建的原生Delta表在打通能力、特性支持、性能上都有明显差距。

内容的提问来源于stack exchange，提问作者B_HOP