我们正在使用基于API的数据，该数据使我们能够分析与提供的GeoJSON区域和指定的时间戳有关的大量GIS数据。当我们的提供商汇总数据时，可以将其标记为已完成，并通过回调URL提醒我们的服务。在这里，我们列出了我们运行的报告以及相关的下载链接。我们需要使用的报告之一是包含4列的TSV文件，如下所示：
deviceId | timestamp | lat | lng
有时候，如果我们要分析的区域足够大，则这些文件可能会超过60 GB。下载链接链接到文件的压缩版本，因此我们无法直接从下载URL读取它们。我们正在尝试获取该TSV中按deviceId分组并按时间戳排序的数据，以便我们可以使用路由服务中的lat / lng沿道路网络进行路由。到目前为止，我们已将Javascript用于大多数应用程序，但是此服务带来了一些独特的问题，可能需要其他软件和/或语言。
很好奇其他人如何处理和处理这种大小的数据。
我们尝试下载文件，将其传输到ReadStream中，并在计算机上分配所有可用的内核，以分别处理批量数据。可以，但是速度不如我们想要的快（即使使用36核）。
答案 0 :(得分：0)
来自Wikipedia：
正确读取ZIP存档的工具必须扫描中央目录记录签名的结尾，然后视情况扫描其他指示的中央目录记录。他们不得从ZIP文件的顶部扫描条目，因为...仅中央目录指定文件块的起始位置，并且文件块尚未删除。扫描可能会导致误报，因为该格式既不禁止其他数据出现在块之间，也不禁止文件数据流包含此类签名。
换句话说，如果尝试不首先查看zip文件末尾而尝试这样做，则可能最终会意外地包含已删除的文件。因此，您不能信任流式解压缩。但是，如果zip文件自创建以来就没有被修改过，那么流解析器也许是可以信任的。如果您不想冒险，请不要使用流解析器。 （这意味着您应该先将文件下载到磁盘上。）
在某种程度上取决于zip存档的结构：如果它由许多中等大小的文件组成，并且它们都可以独立处理，则您不需要在内存中存放太多文件一度。另一方面，如果尝试并行处理许多文件，则可能会遇到可以打开的文件句柄数量限制。但是您可以使用queue之类的方法来解决这个问题。
您说您必须按设备ID和时间戳对数据进行排序。这是流程中无法流式传输的另一部分。如果您需要对大量数据进行排序，建议您先将其保存到数据库中。这样，您可以将其设置为磁盘允许的最大大小，但也可以使其结构化。您将有一个表，其中的列是TSV的列。您可以从TSV文件流式传输到数据库，也可以通过deviceId和timestamp索引数据库。所谓的单一索引，就是按顺序使用这两个列。
如果您要使用分布式基础架构，则可以将不同的设备ID存储在具有不同CPU等的不同磁盘上（“分片”是您要搜索的词）。但是我不知道这样是否会更快。这样可以加快磁盘访问速度。但这可能会通过延迟或带宽，在网络连接中造成瓶颈，具体取决于不同设备ID的互连程度。
哦，如果要并行运行此过程的多个实例，请不要忘记创建单独的数据库，或者至少要在数据库中添加另一列以区分单独的实例。