内存映射文件格式在大于内存文件上运行。箭？答案

【问题标题】：Memory mapped file format operating on bigger than memory files. Arrow?内存映射文件格式在大于内存文件上运行。箭？
【发布时间】：2021-08-02 16:28:57
【问题描述】：

我有一个包含 50K 列、500K 行的矩阵，我想在不使用太多内存（例如内存映射）的情况下快速按列名/索引对其进行子集化。大多数列是 {NA,1,2}，少数 (1%) 列是定量或字符串。 R 中的哪些文件格式/框架最适合执行此操作？

我以为我可以为此使用羽毛，但它似乎加载了整个文件并且使用的内存几乎与 data.table 一样多。等效，即使我设置为 as_data_frame=F。

  f="/path/to/matrix.50Kcolums.500Krows.tsv"
  df <- data.table::fread(f) #
  arrow::write_feather(df,paste0(f,".feather"))  
  df <- read_feather(f.arrow, as_data_frame = FALSE) # uses almost as much memory as fread()
  df <- as.data.frame(df[,grep("columns_with_some_name", names(df))]) # this is what I need it to do fast and without using much memory.

有什么想法吗？

【问题讨论】：

不要对此类数据使用文件，使用数据库系统。
我同意。我想知道是否有允许这样做的文件格式。什么数据库格式可以很好地处理这么多列？我读到 SQL(lite) 可能不适合这么多列。
你可以看看disk.frame，测试here
SQLite 本质上是一个围绕平面文件的数据库包装器。当您想要一个数据库 API（即：SQL）而没有实际的数据库系统时，这是一个方便的解决方案。你是对的，SQL 通常可以更好地处理关系、规范化的数据，而你的数据是极度非规范化的。您可能想查看 NoSQL 格式，例如 Google Bigtable 或类似格式。传统上，数据仓库在这里也可能是一种解决方案，但我不确定它是否仍然被大量使用。其实我可能错了：Feather/HDF5/... 可能比这里的数据库更适合。
您是否尝试过使用col_select 参数仅选择您对read_feather() 感兴趣的列？

标签： r memory-mapped-files apache-arrow feather

【解决方案1】：

@Jon Keane 是正确的。使用col_select 应该可以实现这一点。

(conbench2) pace@pace-desktop:~/dev/arrow/r$ /usr/bin/time -v Rscript -e "print(arrow::read_feather('/home/pace/dev/data/feather/big/data.feather', col_select=c('f0', 'f7000', 'f32000'), as_data_frame = FALSE))"
Table
500000 rows x 3 columns
$f0 <int32>
$f7000 <int32>
$f32000 <int32>
    Command being timed: "Rscript -e print(arrow::read_feather('/home/pace/dev/data/feather/big/data.feather', col_select=c('f0', 'f7000', 'f32000'), as_data_frame = FALSE))"
    User time (seconds): 1.16
    System time (seconds): 0.51
    Percent of CPU this job got: 150%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.11
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 262660
    Average resident set size (kbytes): 0
    ...

话虽如此，当您的整个文件无法放入内存时，羽毛可能不是最佳格式。在这种情况下，即使您指定了内存映射，您仍然必须执行 I/O。如果您一次又一次地重复访问相同的一小组列，您应该没问题。它们将很快被加载到页面缓存中，并且 I/O 成本将消失。

另一方面，如果您每次都访问随机列，或者您希望在运行之间有很大的时间间隔（在这种情况下，页面不会在页面缓存中），您可以考虑 parquet。 Parquet 将需要更多的 CPU 时间来压缩/解压缩，但应该会减少您需要加载的数据量。当然，对于相对少量的数据（例如该数据集的 0.2%），性能差异可能非常小。即使这样，它也可以节省您的硬盘，因为您描述的表占用了大约 100GB 的空间，并且由于“大多数列是 {NA,1,2}”，我希望数据是高度可压缩的。

【讨论】：