大文件的 USQL 查询答案

【问题标题】：USQL Query for Huge Files大文件的 USQL 查询
【发布时间】：2017-02-21 11:45:41
【问题描述】：

我在 Azure Data Lake 存储 (257 gb) 中有一个非常大的文件，当我昨天尝试对其进行简单提取时，我收到以下错误

Vertex 在运行超过 5 小时后终止。带 guid 的顶点 SV1_Extract_Partition[0][53].v0 的输入大小 {2F8802B8-F93A-47EE-80E2-274590BD76A5} 为 1.171594 GB。多数情况情况下，这是由数据倾斜引起的，例如一个数据分区包含大部分数据。使用不同的分区方案或重新分区数据可以解决此类问题。

所以我很确定发生了什么是 U-SQL 没有正确分区我的文件。我正在使用自定义的书面提取器，但我不明白为什么会这样和问题。

如何确保对文件进行分区。这个错误让我损失了很多钱（超过 2000 美元），所以我真的不想再次运行这种规模的任何东西，然后才能确保在作业运行时我的文件被正确分区。

我真的必须手动将我的文件拆分成更小的文件吗？

【问题讨论】：

我能否建议处理一个 2.57GB（甚至 MB）的示例文件，让您的过程变得更好、更高效，这样它可以在不到一分钟的时间内完成，然后扩展到 20GB 以确保您的流程呈线性扩展，依此类推...

标签： azure-data-lake u-sql

【解决方案1】：

大约 1GB 的分区大小看起来很正常。问题可能出在您的自定义提取器中，它确实处理该数据超过 5 小时。

我建议调查一下您的提取器在文件的特定分区上做了什么。

【讨论】：

嗨迈克尔，首先非常感谢您的快速回答。我非常感谢您和 Saveen 为社区提供的支持。所以分区大小是我所期望的。我下载了失败顶点的输入文件（总共 5 个）。第一个文件似乎从中线开始，不应该有换行符（或任何类似的东西，因为前一个字符是“b”）。此外，我看到每行变成 1114 列，而不是原来的 557 列。我会进行更多调查，但如果您有任何可能对我有帮助的见解，请告诉我。
如果您的数据被划分为行，那么您应该使用 input.Split() 命令（例如参见 github.com/Azure/usql/blob/master/Examples/…）而不是直接在基本流上操作。这与文件被分成块而不管行的结尾有关。 input.Split 调用将查看 4MB 到下一个块以找到行尾并在开头跳过上一行的数据。
谢谢 Mike，我会调查的 :)