我正在将大量(100s至1000s)实木复合地板文件读入单个dask数据帧(单机,全部本地)。我意识到
files = ['file1.parq', 'file2.parq', ...]
ddf = dd.read_parquet(files, engine='fastparquet')
ddf.groupby(['col_A', 'col_B']).value.sum().compute()
的效率比
低很多from dask import delayed
from fastparquet import ParquetFile
@delayed
def load_chunk(pth):
return ParquetFile(pth).to_pandas()
ddf = dd.from_delayed([load_chunk(f) for f in files])
ddf.groupby(['col_A', 'col_B']).value.sum().compute()
对于我的特定应用程序,第二种方法(from_delayed
)需要6秒钟才能完成,第一种方法需要39秒。在dd.read_parquet
情况下,在工作人员开始做某事之前似乎有很多开销,并且在任务流图上分散了许多transfer-...
操作。我想了解这里发生了什么。 read_parquet
方法这么慢的原因可能是什么?它与仅读取文件并将它们分成小块有什么不同?
答案 0 :(得分:3)
您正在体验客户端试图建立数据列的最小/最大统计信息,从而为数据帧建立良好索引的问题。索引对于防止从您的特定工作不需要的数据文件中读取数据非常有用。
在许多情况下,这是一个好主意,其中文件中的数据量很大,而文件总数很小。在其他情况下,相同的信息可能包含在特殊的“ _metadata”文件中,因此无需先读取所有文件。
为防止扫描文件的页脚,应致电
dd.read_parquet(..,. gather_statistics=False)
这应该是dask下一版本的默认设置。