В первой фразе мы говорим о связанных этапах, во второй о несвязанных.
Пример: мы готовим два датасета не связанные друг с другом а потом делаем с ними join. Подготовка каждого из них может быть разделена на несколько этапов в каждом из них могут быть группировки, свои join и т.д. И т.к. подготовка каждого датасета не связана с другим, то они могут идти параллельно. Но в конце концов они встретятся на join и вот тогда этап join будет ждать и подготовку первого и подготовку второго датасета. На рисунке 4 этап (join) ждет когда завершатся 1+3 (это последовательные этапы подготовки первого датасета) и 2 этап (один этап подготовки второго датасета). Последовательно идут этапы 1 поток 3, а этап 2, как не связанный с ними, идет параллельно. Но на 4 этапе они встречаются.
Тут скорее все определяется логикой работы с конкретными данными, и возможностями кластера. По крайней мере какой-то обобщенный рецепт мне не известен.
Вы совершено правы насчет BroadcastHashJoin. Он не приводит к shuffle, а следовательно, не приводит к началу нового этапа и является по сути еще одной задачей внутри этапа. Для цели статьи рассматриваем обычный SortMergeJoin, который как раз будет работать без подсказки оптимизатору о broadcast join и без установки порога размера набора данных, при котором broadcast будет использоваться автоматически.
Добрый день.
В первой фразе мы говорим о связанных этапах, во второй о несвязанных.
Пример: мы готовим два датасета не связанные друг с другом а потом делаем с ними join. Подготовка каждого из них может быть разделена на несколько этапов в каждом из них могут быть группировки, свои join и т.д. И т.к. подготовка каждого датасета не связана с другим, то они могут идти параллельно. Но в конце концов они встретятся на join и вот тогда этап join будет ждать и подготовку первого и подготовку второго датасета. На рисунке 4 этап (join) ждет когда завершатся 1+3 (это последовательные этапы подготовки первого датасета) и 2 этап (один этап подготовки второго датасета). Последовательно идут этапы 1 поток 3, а этап 2, как не связанный с ними, идет параллельно. Но на 4 этапе они встречаются.
Тут скорее все определяется логикой работы с конкретными данными, и возможностями кластера. По крайней мере какой-то обобщенный рецепт мне не известен.
Вы совершено правы насчет BroadcastHashJoin. Он не приводит к shuffle, а следовательно, не приводит к началу нового этапа и является по сути еще одной задачей внутри этапа. Для цели статьи рассматриваем обычный SortMergeJoin, который как раз будет работать без подсказки оптимизатору о broadcast join и без установки порога размера набора данных, при котором broadcast будет использоваться автоматически.