时间戳

首页 > 解决方案 > E_RUNTIME_USER_STRINGTOOBIG xml 传递

xml - E_RUNTIME_USER_STRINGTOOBIG xml 传递

问题描述

尝试通过 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, 
            /*....*/
              );

完整版代码在这里

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

标签： xmlazureazure-data-lakeu-sql

解决方案

解决方案

到目前为止，还没有解决这个问题的实际解决方案。但我发现只有两种解决方法：

首先，最小化您的 XML 或 JSON。如果是 XML，请检查命名空间。摆脱它们可能会有所帮助（在我的情况下，它修复了大部分“太长”的价值）

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

我使用了这两种方法，这里是我自己的解析器的实现。这是使用示例。请随意使用它。

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

表现

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

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

推荐阅读