0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: производительность, spark, broadcasting</p>
1
<p>Теги: производительность, spark, broadcasting</p>
2
<p>Соединение нескольких таблиц является достаточно распространенной операцией в<strong>Spark</strong>. Как правило, при ее выполнении происходит перетасовка (<strong>shuffle</strong>), которая за счет перемещений данных между узлами оказывает влияние на производительность. Можно ли избежать этой дорогостоящей операции?</p>
2
<p>Соединение нескольких таблиц является достаточно распространенной операцией в<strong>Spark</strong>. Как правило, при ее выполнении происходит перетасовка (<strong>shuffle</strong>), которая за счет перемещений данных между узлами оказывает влияние на производительность. Можно ли избежать этой дорогостоящей операции?</p>
3
<p>Практика показывает, что можно, если одна из таблиц не является большой по размеру. Например, посредством<strong>Broadcasting</strong>-- трансляции небольшой таблицы по кластерным узлам, в результате чего операции перетасовки можно избежать.</p>
3
<p>Практика показывает, что можно, если одна из таблиц не является большой по размеру. Например, посредством<strong>Broadcasting</strong>-- трансляции небольшой таблицы по кластерным узлам, в результате чего операции перетасовки можно избежать.</p>
4
<p>Давайте представим, что у нас существует таблица<strong>df_order</strong>, содержащая информацию о заказах. Кроме того, есть также и таблица<strong>df_city</strong>, включающая в себя информацию о городах, которые соответствуют заказу. И если даже в самих заказах миллионы строк и много столбцов, то, скорее всего, в таблице<strong>df_city</strong>число городов будет не очень высоким, к примеру, сотни строк. И если при добавлении информации о городах мы добавим к таблице заказов трансляцию (<strong>Broadcasting</strong>), никакой перетасовки не произойдет.</p>
4
<p>Давайте представим, что у нас существует таблица<strong>df_order</strong>, содержащая информацию о заказах. Кроме того, есть также и таблица<strong>df_city</strong>, включающая в себя информацию о городах, которые соответствуют заказу. И если даже в самих заказах миллионы строк и много столбцов, то, скорее всего, в таблице<strong>df_city</strong>число городов будет не очень высоким, к примеру, сотни строк. И если при добавлении информации о городах мы добавим к таблице заказов трансляцию (<strong>Broadcasting</strong>), никакой перетасовки не произойдет.</p>
5
<p>Важно отметить, что максимальный размер таблицы для трансляции составляет 8 Гб. Также<strong>Spark</strong>поддерживает изменение границы размеров этой таблицы, при которых<strong>Broadcasting</strong>станет выполняться автоматически. Реализовать это можно через параметр spark.sql.autoBroadcastJoinThreshold, который по дефолту равен 10 Мб.</p>
5
<p>Важно отметить, что максимальный размер таблицы для трансляции составляет 8 Гб. Также<strong>Spark</strong>поддерживает изменение границы размеров этой таблицы, при которых<strong>Broadcasting</strong>станет выполняться автоматически. Реализовать это можно через параметр spark.sql.autoBroadcastJoinThreshold, который по дефолту равен 10 Мб.</p>
6
<p><em>Источник: https://towardsdatascience.com/apache-spark-performance-boosting-e072a3ec1179</em></p>
6
<p><em>Источник: https://towardsdatascience.com/apache-spark-performance-boosting-e072a3ec1179</em></p>
7
<p>P. S. Интересует Spark? Обратите внимание на<a>специализированный курс по Spark</a>в Otus.</p>
7
<p>P. S. Интересует Spark? Обратите внимание на<a>специализированный курс по Spark</a>в Otus.</p>
8
8