ADF在复制数据活动中合并复制JSON文件会创建映射数据流的错误

Question

我试图在ADF中做一些优化。安装程序是第三方工具，每个对象将一个JSON文件复制到BLOB存储容器中。这些输入到映射数据流。由第三方工具编写的个人文件工作非常出色。如果我使用Azure复制数据活动将这些文件复制到不同的BLOB文件夹，MDF将不再解析这些文件并提供一个错误："JSON解析错误、不支持的编码或多行“。我是从合并文件开始的，但是无论我选择什么复制行为，结果都是一样的。

第二编辑：在另一天的工作之后，我发现JSON中的复制活动合并文件在导入到合并文件时肯定会向每个JSON对象添加一个EOL字符。我还发现，对于合并文件中的那些EOL字符，MDF肯定会失败。如果我从合并文件中删除所有的EOL字符，同样的MDF也会工作。对我来说，这是个窃听器。复制活动正在添加一个中断MDF的字符。在我的一些数据中似乎还有第二个问题，它不是作为一个单独的文件失败，而是当我试图将所有文件放在一起时，连接起来破坏了MDF，但是我已经测试了1-5000个文件的基本行为，并且能够重复失败/成功测试。

我获取了原始文件，以及复制的文件，通过各种测试运行它们，这是我最终在转储到Notepad++中时发现的:复制的文件：

{"CustomerMasterData":{"Customer":[{"ID":"123456","name":"Customer Name",}]}}\r\n

原始档案：

{"CustomerMasterData":{"Customer":[{"ID":"123456","name":"Customer Name",}]}}\n

如果我将复制的文件从\r\n结尾更改为\n，MDF可以再次读取该文件。这里发生什么事情？如何更改文件写入行为或MDF设置，以便可以在没有CRLF的情况下连接或复制文件？

编辑:新信息--似乎在进一步的审查中，缩小/删除空白可能是罪魁祸首。如果我下载ADF副本创建的文件并使用JSON格式化程序对其进行格式化，它就能工作。也许CRLF -> LF掩盖了别的东西。我不知道现在该怎么做，但这非常令人沮丧。其他可能相关的信息：

• 源和接收器JSON数据集都被设置为使用UTF-8 (不是默认的(UTF-8)，尽管我尝试过)。不同的编码会解决这个问题吗？
• I尝试过重新映射模式、创建新的数据集、创建新的映射数据流，但仍然会出现相同的错误。

根据注释编辑的：在文件中有一个JSON元素的情况下，我可以让它工作--数据预览在运行时返回与管道相同的成功或失败

​

对于ADF合并的多个文档，我将得到以下内容。从进一步的回顾来看，也许缩小/删除空格才是罪魁祸首。如果我下载ADF副本创建的文件并使用JSON格式化程序对其进行格式化，它就能工作。也许CRLF -> LF掩盖了别的东西。我不知道现在该怎么做，但这非常令人沮丧。

​

Repro:将任何有效的JSON创建为单个文件，将其放入blob存储，在映射数据流中使用它作为源，以执行任何接收器操作。创建具有相同架构的第二个文件，让它们使用通配符路径在相同的流中运行。使用包含合并文件的复制活动作为Sink复制活动，将对象数组用作文件模式。尝试让您的MDF使用这个新文件。如果失败，下载ADF创建的文件，通过格式化程序运行它(我使用了VS代码-> "Format Document“从标准VS代码JSON扩展名到VS 2019 "Unminify”命令)并重新上传.现在应该管用了。

Answer 1

不知道你是否已经解决了这个问题:3天前我遇到了同样的问题，经过几次尝试，我找到了一个解决方案：

1. 在接收器设置下的复制数据活动中，使用文件模式下的“对象集”(而不是“对象数组”)，这样合并后的大JSON在以*.json模式设置通配符路径之后，在JSON : Document格式下，在MDF中的每行
2. 中具有原始小JSON文件的值。

在那之后，你应该可以走了，至少它解决了我的问题。复制数据活动中的“对象数组”设置中的自动写入CRLF应该是默认设置，MSFT应该提供在将来的设置中省略它的选项。

Answer 2

根据我的测试：

1.复制数据活动不能将unix(LF)更改为windows(CRLF)。

2.MDF还可以解析unix(LF)文件和windows(CRLF)文件。

也许还有别的地方不对劲。顺便说一下，我看到在您的原始文件中有一个逗号在"name":"Customer Name"后面，我在测试之前删除它。