ADF复制活动使用REST源时Big Decimal值精度异常求助

核心原因拆解 #

• 浮点数二进制存储的固有局限
  绝大多数REST API返回的数值如果是JSON原生的number类型，本质是64位双精度浮点数。这种类型的有效精度仅为15-17位十进制，当你的数值位数接近这个上限时，部分十进制小数无法被二进制精确编码，必然会产生微小的舍入误差。比如你提到的155575307.6085215，在二进制转换过程中就会出现精度损失，ADF读取后直接写入ADLS时会保留这个误差值。

• ADF自动类型推断的默认行为
  由于你使用通用管道未指定schema mapping，ADF会自动推断源数据类型。如果REST返回的数值没有明确标记为高精度decimal类型（比如API仅返回纯数字，无类型元数据），ADF会默认将其推断为double类型而非decimal。double的精度限制直接导致了偏差，而decimal类型专门用于高精度十进制数存储，不会有这类问题。

• REST API端的序列化问题
  部分后端服务在序列化十进制数值时，可能已经将其转换为浮点数而非字符串或高精度decimal类型。如果API返回的原始数据就已经是浮点数格式，那么精度损失在ADF读取之前就已经发生，ADF只是将这个有误差的值写入到ADLS的JSON中。

可行的临时应对思路 #

• 若REST API可控，要求后端将高精度十进制数值以字符串格式返回，ADF读取字符串后直接写入JSON，完全避免浮点数转换过程。
• 尝试在ADF复制活动的源设置中开启「保留源数据类型」选项（部分连接器支持），强制ADF使用API返回的原始类型而非自动推断。
• 若允许添加轻量处理逻辑，可通过数据流动动态判断数值长度，将疑似高精度的double类型显式转换为decimal(38,10)这类高精度类型后再写入ADLS（通用管道可通过动态表达式适配多源场景）。

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