сбор большого фрейма данных обратно в мастер в распределенном dask

У меня есть большой (~ 180 тыс. строк) кадр данных, для которого

df.compute()

зависает при запуске dask с распределенным планировщиком в локальном режиме на AWS m5.12xlarge (98 ядер). Все рабочие остаются почти без дела Однако

df.head(df.shape[0].compute(), -1)

завершается быстро, с хорошим использованием доступного ядра.

Логически вышеперечисленное должно быть эквивалентно. В чем причина разницы? Есть ли какой-то параметр, который я должен передать compute в первой версии, чтобы ускорить его?


dataframe dask dask-distributed
person Daniel Mahler    schedule 13.06.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Когда вы вызываете .compute(), вы запрашиваете весь результат в своем локальном процессе в виде кадра данных pandas. Если этот результат большой, он может не подойти. Вам нужен весь результат локально? Если нет, то, возможно, вы хотели вместо этого .persist()?

person MRocklin    schedule 16.06.2019
comment
Я хочу, чтобы весь фрейм данных был собран. Несмотря на большой размер, он легко помещается. на моей машине. Второй фрагмент df.head(df.shape[0].compute(), -1) делает то, что мне нужно, довольно быстро. Я правда спрашиваю, почему compute глохнет? - person Daniel Mahler; 18.06.2019
comment
Нет подсказки. Это зависит от всего в ваших вычислениях. Это может быть что угодно на самом деле. - person MRocklin; 19.06.2019
comment
хорошо, но почему у df.head(df.shape[0].compute(), -1) не может быть такой же проблемы, как у compute()? Разве они не делают то же самое? - person Daniel Mahler; 20.06.2019