Как определить причину повторных (неожиданных) задач `repartition-split-repartition-merge`? - PullRequest
Новая
       22

Как определить причину повторных (неожиданных) задач `repartition-split-repartition-merge`?

1 голос
/ 06 марта 2020

В графе задач, который Dask выводит через ddf.visualize(), я вижу много *-repartition-split-repartition-merge задач, где * может быть join, rename или какую-либо другую задачу, которую я узнаю из моего приложения.

Я пытаюсь определить, откуда они берутся, влияют ли они на производительность (я полагаю, что постоянное перераспределение / разделение / объединение данных требует затрат, не помогая непосредственно в моих вычислительных целях), и, если да, то как я могу удалите их.

Они, по-видимому, доминируют во времени вычислений в performance_report, предоставленном distributed.

Глядя на исходный код Dask, я вижу в источнике dask.dataframe.core, что DataFrame метод repartition помещает эти значения в HighLevelGraph: 

[...]
        tmp = "repartition-split-" + token
        out = "repartition-merge-" + token
        dsk = repartition_divisions(
            df.divisions, divisions, df._name, tmp, out, force=force
        )
        graph = HighLevelGraph.from_collections(out, dsk, dependencies=[df])
        return new_dd_object(graph, out, df._meta, divisions)
[...]

Учитывая, что я специально не прошу Dask о перераспределении в моем приложении, как я могу узнать, что вызывает это?

Я пытался установить точки останова в этом кусочке кода Dask, но, похоже, я его не нажимаю.

1 Ответ

2 голосов
/ 09 марта 2020

В моем случае это произошло потому, что мое приложение обрабатывает много разных фреймов данных и объединяет их в конце своего выполнения.

В рамках этого слияния Dask необходимо выровнять подразделения / разделы и выполнить это с помощью метода DataFrame.repartition(). В этом методе создается впечатление, что создаются как минимум две разные задачи - repartition-split (взятие раздела и разбиение его на n другие) и repartition-merge (объединение m разделов в один).

...