我正在使用R和Apache Arrow处理大数据。我的数据分为两个数据集,称之为:
vals
:一组配置单元分区的parquet,每行包含一个ID(长字符串)和数百列数据(整数)meta
:一个元数据的组合,每行包含相同的ID和一些分组变量。
为了将vals
聚合到一个可管理的大小,我需要首先连接meta
。我相信以一种内存高效的分段方式来做这件事正是Arrow擅长的,但我不能做到这一点。
以下是我的尝试:
library(arrow)
library(dplyr)
vals = open_dataset(path_to_vals)
meta = open_dataset(path_to_meta)
temp = left_join(vals, meta, by='id') %>%
group_by(grouping_variables_from_meta) %>%
summarise(across(all_of(variables_from_vals), mean))
write_dataset(temp, 'some_path')
字符串
一旦我调用write_dataset
,我的内存使用量就会激增。在我看来,Arrow试图通过将两个表都保存在内存中来进行连接。即使我通过从集群请求荒谬的内存量(不是长期解决方案)来暂时回避这个问题,这个过程最终还是失败了:Error: Invalid: There are more than 2^32 bytes of key data. Acero cannot process a join of this magnitude.
我曾经使用Arrow来总结大得多的数据集,a)很少的内存使用和B)没有关于太大的关键数据的错误。但是,在那些情况下,我总是在单个数据集中有分组变量,并且不需要首先连接它们。所以,我很确定连接步骤是问题所在。
我是不是该换个方式?我是不是误解了什么?
sessionInfo():
R version 4.3.1 (2023-06-16)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Rocky Linux 8.7 (Green Obsidian)
Matrix products: default
BLAS: /n/sw/helmod-rocky8/apps/Core/R/4.3.1-fasrc01/lib64/R/lib/libRblas.so
LAPACK: /n/sw/helmod-rocky8/apps/Core/R/4.3.1-fasrc01/lib64/R/lib/libRlapack.so; LAPACK version 3.11.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
time zone: America/New_York
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] dplyr_1.1.3 arrow_13.0.0.1 nvimcom_0.9-147
loaded via a namespace (and not attached):
[1] assertthat_0.2.1 utf8_1.2.3 R6_2.5.1 bit_4.0.5
[5] tidyselect_1.2.0 magrittr_2.0.3 glue_1.6.2 tibble_3.2.1
[9] pkgconfig_2.0.3 bit64_4.0.5 generics_0.1.3 lifecycle_1.0.3
[13] cli_3.6.1 fansi_1.0.4 vctrs_0.6.3 compiler_4.3.1
[17] purrr_1.0.2 tools_4.3.1 pillar_1.9.0 rlang_1.1.1
型
1条答案
按热度按时间svmlkihl1#
由于acero(用于连接的C++执行引擎)存储键数据(uint32_t)的方式,目前不支持键数据超过4GB的连接。
您看到的错误消息是由一个检查引起的,该检查旨在防止数据被破坏并默默地返回损坏的结果。但似乎在https://github.com/apache/arrow/pull/37709中正在处理该检查,这可能意味着即使关键数据<4gb也会受到影响。