ADF从SQL Server复制数据到Delta Lake时目标端特殊字符丢失如何解决

这类特殊字符丢失基本都是同步链路某一环配置错配导致，常见原因有以下几类：

• 编码配置不一致：SQL Server端存储特殊字符的字段如果是NVARCHAR等Unicode类型，ADF源数据集没开Unicode支持、中间暂存文件用了ASCII/GBK等非UTF-8编码时，超出编码集的字符会被直接丢弃，部分场景下连~$这类半角特殊符号也会因为编码解析错误被连带截断。
• 隐式类型转换截断：ADF复制活动开了自动类型映射时，容易把存了~$534这类带符号内容的字符串字段错识别为数值类型，同步过程中自动把非数字的~$部分过滤掉，只保留数字内容。
• 转义规则冲突：如果同步链路中用了CSV等文本格式做中转，配置的转义符、字段分隔符和业务数据里的特殊字符重合（比如误把$设为转义标记），解析时会直接把转义符本身和后续不符合转义规则的内容吞掉。
• Delta写入端配置异常：用旧版集成运行时（IR）写入Delta时，低版本的Parquet序列化组件存在特殊字符兼容bug，或是写入时配置了自定义的特殊字符清洗规则，会主动过滤掉非字母数字的符号。
• 暂存环节配置错误：开启ADF暂存复制时，如果暂存账户的文件写入编码没设为UTF-8，数据写入暂存层的时候就已经出现字符丢失，和后续Delta写入逻辑无关。

按从源到目标的顺序分段排查，避免无意义的配置试错：

• 先校验源端数据：直接在SQL Server中对异常数据行执行查询，确认源端字段值完整，排除源端数据本身损坏、查询逻辑带替换函数截断字符的问题。
• 核对类型映射配置：打开ADF复制活动的「映射」面板，逐行检查异常字段的源类型、sink类型映射关系，确认字符串类型字段没有被错配为INT/DECIMAL等数值类型，检查映射表达式里有没有自带REPLACE、SUBSTRING等截断字符的逻辑。
• 检查全链路编码配置：依次核对源SQL Server数据集、暂存配置（如果开启）、Delta sink数据集的编码参数，确认所有文本编码统一设为UTF-8，源数据集勾选「支持Unicode」选项；如果用了文本格式做中转，检查分隔符、转义符、引号配置，确认没有和业务数据里的~/$等字符重合。
• 分段定位丢失节点：把复制活动的sink临时改成Azure Blob存储的Parquet格式，执行单条异常数据的同步，下载生成的Parquet文件查看内容：如果这一步已经丢字符，问题出在源读取或暂存环节；如果这一步字符完整，问题出在Delta写入环节。
• 核对Delta写入配置：检查Delta sink有没有配置自定义的写入脚本、字符清洗规则，确认当前使用的集成运行时版本不是存在已知兼容问题的旧版本。

定位到问题节点后对应修复即可：

• 编码类问题：全链路所有文本处理环节统一配置为UTF-8编码，SQL Server连接串追加Unicode=True参数强制驱动用Unicode模式读取NVARCHAR字段内容，禁止使用ASCII、GB2312等非通用编码。
• 类型映射问题：关闭复制活动的「自动类型推断」选项，手动修正字段映射关系，所有存储业务文本的字段统一映射为Delta的STRING类型，不要让系统自动做类型转换。
• 转义规则问题：尽量用Parquet这类二进制格式做同步中转，避免CSV文本格式的转义解析问题；如果必须用CSV做中转，明确配置转义符为反斜杠\、字段引号为双引号"，不要用特殊字符做转义或分隔标记。
• 写入端问题：如果用自托管IR，先升级到最新稳定版本，移除Delta写入流程中自定义的特殊字符过滤、清洗规则，用ADF原生的Delta写入连接器做同步，不要用自定义脚本写入。
• 修复后验证：选取包含~$、%、&、中文等各类特殊字符的测试样本做全链路同步，逐字段对比源端和Delta端的字符长度、内容，确认完全一致后再启动全量同步任务。

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