2

我们正在使用提供的基于 API 的数据，它允许我们分析与提供的 GeoJSON 区域和指定时间戳相关的大量 GIS 数据。当我们的提供商汇总数据时，可以将其标记为完整并通过回调 URL 提醒我们的服务。从那里，我们有一个我们已经运行的报告的列表及其相关的下载链接。我们需要处理的报告之一是具有 4 列的 TSV 文件，如下所示：

deviceId | timestamp | lat | lng

有时，如果我们分析的区域足够大，这些文件可能会超过 60+GB。下载链接链接到文件的压缩版本，因此我们无法直接从下载 URL 中读取它们。我们正在尝试获取此 TSV 中按 deviceId 分组并按时间戳排序的数据，以便我们可以使用路由服务中的 lat/lng 沿道路网络进行路由。到目前为止，我们的大部分应用程序都使用了 Javascript，但这项服务带来了独特的问题，可能需要额外的软件和/或语言。

好奇其他人如何解决处理和处理这种大小的数据的问题。

我们已经尝试下载文件，将其通过管道传输到 ReadStream 中，并分配机器上所有可用的内核来单独处理批量数据。这行得通，但它并没有我们想要的那么快（即使是 36 核）。

4

1 回答 1

1

来自维基百科：

正确读取 ZIP 档案的工具必须扫描中央目录记录签名的结尾，然后酌情扫描其他指示的中央目录记录。他们不能从 ZIP 文件的顶部扫描条目，因为......只有中央目录指定文件块的开始位置并且它没有被删除。扫描可能会导致误报，因为该格式不禁止其他数据位于块之间，也不禁止文件数据流包含此类签名。

换句话说，如果您尝试在不先查看 zip 文件末尾的情况下执行此操作，则最终可能会意外包含已删除的文件。所以你不能相信流式解压器。但是，如果 zip 文件在创建后没有被修改过，那么流解析器可能是可信的。如果您不想冒险，请不要使用流解析器。（这意味着您首先将文件下载到磁盘是正确的。）

在某种程度上，它取决于 zip 存档的结构：如果它由许多大小适中的文件组成，并且如果它们都可以独立处理，那么您不需要在任何时候在内存中存储太多。另一方面，如果您尝试并行处理许多文件，那么您可能会遇到可以打开的文件句柄数量的限制。但是你可以使用类似queue的东西来解决这个问题。

您说您必须按设备 ID 和时间戳对数据进行排序。这是无法流式传输的过程的另一部分。如果您需要对大量数据进行排序，我建议您先将其保存到数据库中；这样，您就可以使其尽可能大，但也可以结构化。您将有一个表，其中列是 TSV 的列。您可以从 TSV 文件流式传输到数据库中，还可以通过deviceId和索引数据库timestamp。我的意思是按顺序使用这两个列的单个索引。

如果您想要一个分布式基础架构，也许您可​​以将不同的设备 ID 存储在具有不同 CPU 等的不同磁盘上（“分片”是您想用谷歌搜索的词）。但我不知道这是否会更快。它将加快磁盘访问速度。但它可能会通过延迟或带宽在网络连接中造成瓶颈，具体取决于不同设备 ID 的互连程度。

哦，如果您要并行运行此进程的多个实例，请不要忘记创建单独的数据库，或者至少在数据库中添加另一列以区分单独的实例。

于 2019-06-06T20:52:21.960 回答