使用 gzip 和虚拟列的 u-sql 问题答案

【问题标题】：u-sql issue using gzip and virtual column使用 gzip 和虚拟列的 u-sql 问题
【发布时间】：2017-07-25 16:23:50
【问题描述】：

我对处理压缩文件的 u-sql 作业有一个奇怪的问题。如果我在普通的 csv 文件上运行 u-sql，它就可以正常工作。但是，如果我 gzip 文件，它不再起作用（生成 E_RUNTIME_USER_EXTRACT_ENCODING_ERROR：在处理顶点输入拆分中的 0 条记录后发生编码错误。）

所以有效的代码是

DECLARE @path string = "output/{ids}/{*}.csv";

@data =
    EXTRACT
        a string,
        b string,
        c string, 
        d string,
        ids string
    FROM  @path
    USING 
        Extractors.Csv(skipFirstNRows:1, silent: true);

@output = 
    SELECT *
    FROM @data 
    WHERE ids == "test";

OUTPUT @output
TO "output/res.csv"
USING Outputters.Csv(quoting : false, outputHeader: true);

此代码不起作用（文件的gz版本）

DECLARE @path string = "output/{ids}/{*}.csv.gz";

@data =
    EXTRACT
        a string,
        b string,
        c string, 
        d string,
        ids string
    FROM  @path
    USING 
        Extractors.Csv(skipFirstNRows:1, silent: true);

@output = 
    SELECT *
    FROM @data 
    WHERE ids == "test";

OUTPUT @output
TO "output/res.csv"
USING Outputters.Csv(quoting : false, outputHeader: true);

如果我删除虚拟列“ids”，它适用于 gz 版本

DECLARE @path string = "output/test/{*}.csv.gz";

@data =
    EXTRACT
        a string,
        b string,
        c string, 
        d string
    FROM  @path
    USING 
        Extractors.Csv(skipFirstNRows:1, silent: true);

@output = 
    SELECT *
    FROM @data;

OUTPUT @output
TO "output/res.csv"
USING Outputters.Csv(quoting : false, outputHeader: true);

附件是我正在使用的两个文件。有没有人知道发生了什么？如果我删除虚拟列 ID，它对两者都有效吗？

test.csv

test.csv.gz

我仅在针对 Data Lake Storage 中的文件运行时收到此错误。如果我在本地运行文件，它工作正常。

我收到的详细错误是 "internalDiagnostics":""-"innerError":{"diagnosticCode":195887128-"severity":"Error"-"component":"RUNTIME"-"source":"User"-"errorId":"E_RUNTIME_USER_EXTRACT_INVALID_CHARACTER"- "message":"输入流中 UTF-8 编码的无效字符。"-"description":"在输入中发现 UTF-8 编码的无效字符。"-"resolution":"更正输入文件中的无效字符-或在提取器中正确编码，然后重试。”

【问题讨论】：

您是在本地运行还是针对您的云 ADLA 帐户运行？可能都值得尝试，看看你是否得到不同的结果。
我尝试了这两个选项。我在 Visual Studio 中针对本地磁盘上的文件运行脚本（这有效）。我还尝试在 Visual Studio 中针对我的 ADLA 帐户以及 Azure 门户中的文件运行脚本（均失败）。似乎与虚拟列有关。如果我如上一个示例中所示删除这些，则它适用于所有情况。
我无法重现这个。第二个脚本在我的本地和云 ADLA 帐户上运行良好。您使用的是什么版本的工具？我在 Visual Studio 2015 中使用 2.2.6000.1。可能值得通过 Azure 门户提交脚本，这将排除工具，最后考虑提交支持请求。
是导致问题的运行时错误！
我目前在完全不同的查询和数据集上面临完全相同的问题。不知道它是否修复了..

标签： azure-data-lake u-sql

【解决方案1】：

添加一些额外的问题：

这是一个已确认的缺陷。我们已经为此部署了修复程序，因此无论有无 @@FeaturesPreview = "FileSetv2Dot5:on" 标志，您都不应再遇到该问题。
SET @@FeaturesPreview = "FileSetv2Dot5:on" 上述标志是正确的解决方法，因为它将强制在不存在缺陷的情况下生成不同的计划。
SET @@FeaturesPreview = "FileSetv2Dot5:on" 默认仍处于关闭状态。

【讨论】：

【解决方案2】：

我遇到了完全相同的问题。似乎是 ADLA 的新运行时中的一个错误。 MS正在研究它。这个修复对我有用：

SET @@FeaturePreviews = "FileSetV2Dot5:on";

【讨论】：