E_RUNTIME_USER_STRINGTOOBIG xml 通过

Question

尝试通过 Azure Data Lake 作业加载 XML 我在 E_RUNTIME_USER_STRINGTOOBIG 使用 Microsoft.Analytics.Samples.Formats

时遇到了牢不可破的问题

问题是 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，请检查命名空间。摆脱它们可能会有所帮助（在我的例子中它修复了大部分 'too-long' 值）

第二个是编写自己的提取器（并不难）。

我使用了这两种方法，这里是我自己的实现 parser. Here is the usage example。请放心使用。

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

性能

在我调查这个问题的过程中，我发现这两个解析器在处理许多小文件时都非常缓慢。

但是，制作太大的文件 (~2GB) 会导致 OutOfMemory 异常。我在这里的假设是，它发生是因为文件被处理为原子（文件不是由 250 MB 的块分发的，这些块像 CSV 或 TSV 一样独立处理）。至于我的情况，文件大小 200-250 MB 是最佳的

E_RUNTIME_USER_STRINGTOOBIG xml 通过

E_RUNTIME_USER_STRINGTOOBIG xml pasing

xml

azure

azure-data-lake

u-sql

解决方案

性能