【问题标题】:U-SQL Error Extracting from BCP CSV File从 BCP CSV 文件中提取 U-SQL 错误
【发布时间】:2016-03-22 19:37:09
【问题描述】:

我有使用 BCP 从 SQL Server 提取的数据,文件是 ASCII CSV。
日期格式为 2016-03-03T23:00:00。

运行提取时我得到

补充资料:

{"diagnosticCode":195887127,"severity":"Error","component":"RUNTIME","source":"User","errorId":"E_RUNTIME_USER_EXTRACT_COLUMN_CONVERSION_INVALID_ERROR","message":"无效 尝试转换列数据时的字符。","description":"HEX: \"223022\" 转换输入记录时出现无效字符。\n位置: 第 1 行第 21 列。","re​​solution":"检查输入是否有错误或使用 \"silent\" 切换以忽略 输入。\n考虑忽略“无效”行可能会影响作业 结果,并且类型必须可以为空才能使转换错误 忽略。","helpLink":"","详细信息":"================================== ==================================================== ======== \ nHex中:5432333B35313B34362D323031362E30332E30335432333B30303B30302D302D352D323031362E30332E30335432333B35313B34392F3536372D302D323031362E30332E3033 \ n ^\nTEXT:T23:51:46,2016-03-03T23:00:00,0,5,2016-03-03T23:51:49.567,0,2016-03-03\n

您如何在提取时正确处理日期?我不清楚为什么它会在日期时间列的中间分裂。

示例行看起来像

50CA2FBB-95C3-4216-A729-999BE2DB491A,2016-03-03T23:51:49.567,1001464881,1001464795,1001464795,00000000-0000-0000-0000-000000000000,00000000-0000-0000-0000-000000000000,100 ,100 , ,12643,bCAwvRnNVwrKDXKxZkVed2Z1zHY=,o2lsnhueDApmvSbm31mh3aetYnc=,2016-03-03T23:50:46,2016-03-03T23:00:00,2016-03-03T23:301:46,3:2T:6 00,0,5,2016-03-03T23:51:49.567,0,2016-03-03T00:00:00,2016-03-03T23:59:59,00000000-0000-0000-0000-000000000000

Extract Statement is
@res =
EXTRACT 
        LicenseId Guid,
        EntryDate DateTime,
        UltimateId long,
        SiteId string,
        VirtualId string,
        ProjectId Guid,
        DocumentId Guid,
        MasterId string,
        ProductId string,
        FeatureString string,
        VersionId long,
        ComputerSid string,
        UserSid string,
        AppStartTime DateTime,
        StartHour DateTime,
        AppStopTime DateTime,
        StopHour DateTime,
        GmtDelta int,
        RecordedGmtDelta int,
        LastUpdated DateTime,
        Processed bool,
        StartDate DateTime,
        EndDate DateTime,
        ImsId Guid
FROM @dataFile
USING Extractors.Csv();

【问题讨论】:

  • 有趣的是,如果我删除了 BCP 文件中除两个日期之外的所有日期并相应地修改了 Extract 语句......它可以工作。

标签: azure-data-lake u-sql


【解决方案1】:

内置提取器的默认编码是 Encoding.UTF-8。因此,您看到的三字节序列很可能被解释为 UTF-8 而不是 ASCII。

如果您的 BCP 输出确实只包含 ASCII 范围 (0-127) 中的代码点(而不是 ANSI 8 位字符),您可以指定 Extractors.Csv(encoding:Encoding.[ASCII])(注意 [] 周围的 ASCII 以将它们从保留关键字规则)。

如果您的数据包含 ANSI 范围字符,则必须将 BCP 输出为 UTF-16(我认为 BCP 不支持 UTF-8),或者将 BCP 的结果转换为 UTF-8。

请注意,如果文件大于 250MB,如果文件是 UTF-16 编码,我们目前在上传文件时存在关于记录边界检测的错误。在我们修复此错误之前,我建议您在这种情况下上传使用 UTF-8 编码的文件。

另外,如果您需要支持完整的 ANSI 代码页,请在 https://feedback.azure.com/forums/327234-data-lake/suggestions/13077555-add-ansi-code-page-support-for-built-in-extractors 投票支持用户语音项目并提供您需要支持的代码页(例如,Windows-1254 或 ISO-Latin-1 )。

【讨论】:

  • 如何处理文件为 UTF-8 的情况,但在某处的记录中仍有 Latin-1 字符? U-SQL 仍然会在 10 亿条记录中失败。
  • 现在内置提取器将失败。如果您愿意,您可以编写一个自定义提取器来处理它。也可以随时在aka.ms/adlfeedback 请求以某种形式(请指定)忽略此类值的选项
  • 是的,编写自定义提取器不是一个好选择。我肯定会建议类似于 Polybase 处理它的方式,它只是拒绝行或转换它。现在,我相信如果文件被压缩,Polybase 会提取并重新编码它。在这种情况下,我们必须对其重新编码以触发 USQL 作业。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-04-10
  • 1970-01-01
  • 1970-01-01
  • 2016-04-20
  • 1970-01-01
相关资源
最近更新 更多