Microsoft Dynamics F&O导出至数据湖：如何解决更新文件查询失败问题？

我们通过Microsoft Dynamics Finance & Operations (F&O)的Export to Datalake功能，实现对Synapse数据湖中F&O数据的近实时访问，但查询正在被F&O更新的CSV文件时，频繁出现Unexpected end-of-input within record at....错误，严重影响用户体验。根据微软官方说明，这是Synapse无服务器SQL服务查询正在写入的文件时的读写冲突限制，官方建议重试查询，但实际场景中重试无法解决用户体验问题。

我们已尝试以下两种方案，但效果不佳：

• 启用ALLOW_INCONSISTENT_READS选项：在访问数据湖的Synapse无服务器数据库中开启该参数后，报错仍频繁出现，未达到预期效果。
• 使用CETAS导出后查询：CETAS生成的数据集只能删除重建，若仅夜间执行则丢失近实时性；若频繁执行则ETL流程过于复杂，维护成本高。

企业常用解决方案 #

1. 利用数据湖版本化/快照机制 #

配置数据湖存储的版本保留策略（如Azure Storage的版本控制），查询时指定读取文件的历史版本而非最新版本。这样可以避开F&O正在写入的文件版本，从已完成写入的历史版本中读取数据，彻底避免读写冲突。

• 操作方式：在Synapse无服务器SQL的OPENROWSET查询中，通过VERSION参数指定文件的特定版本ID，或者利用存储的快照时间戳筛选可用版本。

2. 引入中间层缓冲 #

通过Azure Function或Logic Apps监听数据湖的文件更新事件，当F&O完成文件写入（可通过文件大小稳定、写入时间戳判断）后，将文件数据同步到Synapse专用池的表中，或者创建Serverless的临时外部表指向已完成写入的文件。用户查询时直接访问中间层的表，而非原始的实时写入文件。

• 优势：既保证近实时性（事件触发同步延迟通常在分钟级），又避免了直接查询写入中文件的冲突问题。

3. 调整F&O导出的文件分割策略 #

修改F&O Export to Datalake的配置，将大文件拆分为多个小文件导出。这样单个文件的写入时间更短，冲突窗口被大幅缩小，报错概率显著降低。同时结合查询时的重试逻辑（在应用层或Synapse的查询脚本中加入自动重试），进一步减少用户感知到的错误。

4. 转换为Delta Lake格式 #

将F&O导出的CSV文件自动转换为Delta Lake格式（通过Azure Databricks或Synapse Spark池定时/事件触发转换）。Delta Lake支持ACID事务和快照隔离，Synapse无服务器SQL可以直接查询Delta Lake表，天然解决读写冲突问题，同时保留近实时访问能力。

• 注意：需要配置Spark作业监听数据湖的新文件，实时转换为Delta表，转换延迟可控制在分钟级。

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