xml - E_RUNTIME_USER STRING TOO BIG xml 解析

Question

尝试通过 Azure Data Lake 作业加载 XML 时，我遇到了使用 Microsoft.Analytics.Samples.Formats 的 E_RUNTIME_USER_STRINGTOOBIG 无法解决的问题。

问题是，XmlDomExtractor 是从同一 XML 文件(一对多)内部连接(或更确切地说应用)元素的唯一方法。

@xml =
EXTRACT Id string,
        //...
        Products string
FROM @"/pathToXml.xml"
USING new Microsoft.Analytics.Samples.Formats.Xml.XmlDomExtractor("contract",
      new SQL.MAP<string, string>{
      {"id", "Id"},
      //...
      // this is actually a node that may contain thousand of child node
      {"products", "Products"}
      });

申请:

@data = SELECT c.Id,
        //....
        pp.ProductSid, 
        // ... other product properties
    FROM @prepareData AS c
    OUTER APPLY
        new Microsoft.Analytics.Samples.Formats.Xml.XmlApplier ("Products","/",new SQL.MAP<string, string>{
      {"/abc/p/s", "ProductSid"},
      //....
      }) AS pp(
            ProductSid string, 
            /*....*/
              );

完整版代码为here

我尝试通过用字母替换名称来最小化我的 XML 节点。不幸的是，它没有帮助，因为里面的数千个项目(+产品的长名称)无论如何都突破了限制。

Answer 1

解决方案

到目前为止还没有实际的解决方案来解决这个问题。但我只找到了两种解决方法:

首先，尽量减少 XML 或 JSON。如果是 XML，请检查 namespace 。摆脱它们可能会有所帮助(在我的例子中，它修复了大部分“太长”值)

第二个是编写自己的提取器(这并不难)。

我使用了这两种方法，这是我自己的实现 parser 。这是用法example 。请随意使用它。

它非常通用，并且还支持 XPath 和命名空间。在性能方面，它与微软的实现非常相似

性能

在调查此问题期间，我发现两个解析器处理许多小文件的速度都非常慢。

但是，创建太大的文件(~2GB)会导致 OutOfMemory 异常。我在这里的假设是，发生这种情况是因为文件被作为原子处理(文件不是按 250 MB block 分布，这些 block 像 CSV 或 TSV 一样独立处理)。就我而言，文件大小最佳为 200-250 MB