javascript - 如何使用 NodeJS 处理大量文本分隔文件

Question

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

设备编号 |时间戳 |纬度 |液化天然气

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

想知道其他人是如何处理和处理这种规模的数据的问题。

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

Answer 1

来自 Wikipedia :

Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because ... only the central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures.

换句话说，如果您不先查看 zip 文件的末尾就尝试执行此操作，您可能会不小心包含已删除的文件。所以你不能相信流式解压器。但是，如果 zip 文件自创建以来未被修改，则流解析器可能是可信的。如果你不想冒险，那就不要使用流式解析器。 (这意味着您首先将文件下载到磁盘是正确的。)

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

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

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

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