Azure Data Factory入Fabric Lakehouse异常：表存入文件目录而非表文件夹

使用Azure Data Factory向Fabric Lakehouse摄入表数据时遇到以下异常：

• 从AWS S3和SQL Server摄入正常，但从Azure Database for PostgreSQL和MySQL摄入时，数据被存入普通文件目录而非Lakehouse的专属表文件夹
• 部分文件目录下同时存在parquet文件和delta日志，部分仅含delta日志；只有存入表文件夹且包含有效parquet文件的表才能在Lakehouse中正常显示并使用
• AWS S3和SQL Server摄入正常的前提是目标表已存在，仅执行覆盖操作；若目标表不存在，同样会出现数据存入文件目录的问题

需求：是否存在配置项，可让新表在摄入时自动创建并存入Lakehouse的表文件夹？

相关截图 #

异常存储示例 #

表的正确存储方式（单文件夹对应单表） #

文件的错误存储方式 #

源配置 #

接收器配置 #

数据集配置 #

链接服务配置 #

要实现新表自动存入Fabric Lakehouse的专属表文件夹，需调整以下核心配置：

1. 接收器配置：触发表创建逻辑 #

在ADF Copy活动的接收器设置中，确保：

• 表名：明确指定完整的Lakehouse表路径，格式为{Lakehouse名称}.{Schema名称}.{表名}（例如SalesLakehouse.dbo.Customer）
• 写入行为：选择Create table if not exists或Create table，而非仅写入文件的选项
• 高级设置：勾选自动创建表，并将表类型设置为Delta table（Fabric Lakehouse默认的表存储格式）

2. 数据集配置：绑定Lakehouse表资源 #

修改Fabric Lakehouse数据集的配置：

• 在连接选项卡中，选择表作为数据类型，避免使用“文件路径”模式
• 若使用参数化表名，需在数据集的Table name字段中绑定动态参数，确保运行时能解析为合法的Lakehouse表名

3. 链接服务配置：使用专属Lakehouse链接 #

确保ADF与Fabric Lakehouse的链接服务采用Azure Fabric Lakehouse类型：

• 通过Fabric工作区身份验证，确保链接服务拥有创建表的权限
• 避免使用ADLS Gen2直接访问Lakehouse的底层存储路径，这种方式会绕过Lakehouse的元数据管理，导致数据以普通文件目录形式存储

4. 数据类型映射：保证Schema兼容性 #

从PostgreSQL/MySQL摄入时，需校验并调整数据类型映射：

• 在Copy活动的映射选项卡中启用自动映射，并手动校验类型转换（例如PostgreSQL的TEXT对应Lakehouse的STRING，TIMESTAMP对应DATETIME）
• 修复任何不兼容的类型映射，避免因Schema校验失败导致无法创建表，进而退化为文件存储

5. 权限校验：确保ADF拥有表创建权限 #

检查ADF的身份（服务主体或托管身份）在Fabric Lakehouse中拥有：

• Contributor或Table Creator角色权限，允许创建和管理表
• 若使用托管身份，需在Fabric工作区中为该身份分配对应的Lakehouse权限

关键原理 #

当目标表已存在时，ADF直接写入现有Delta表的专属目录；若目标表不存在，需通过上述配置触发ADF调用Fabric的元数据接口创建表，同时将数据写入对应的Delta表目录。PostgreSQL/MySQL摄入时的异常，本质是未触发表创建逻辑，导致数据被写入通用存储路径而非表专属目录。

内容的提问来源于stack exchange，提问作者Antônio Farias