Я читаю High Performance Spark , и автор представляет метод, который можно использовать для выполнения объединений с сильно искаженными данными путем выборочной фильтрации данных для построения HashMap с данными, содержащими наиболее распространенные ключи. Затем эта HashMap отправляется всем разделам для выполнения широковещательного соединения. Полученные данные объединяются с помощью операции объединения в самом конце.
Заранее извиняюсь, но в тексте не приводится пример этой техники с использованием кода, поэтому я не могу поделиться фрагментом кода для его иллюстрации.
Текст следует.
Иногда не все наши меньшие RDD помещаются в память, но некоторые ключи настолько перепредставлены в большом наборе данных, что вы хотите транслировать только самые распространенные ключи. Это особенно полезно, если один ключ настолько велик, что не может поместиться на одном разделе. В этом случае вы можете использовать countByKeyApprox на большом RDD, чтобы получить приблизительное представление о том, какие ключи больше всего выиграют от трансляции. Затем вы фильтруете меньший RDD только для этих ключей, собирая результат локально в HashMap. Используя s c .broadcast, вы можете транслировать HashMap, чтобы у каждого работника была только одна копия, и вручную выполнять соединение с HashMap. Используя тот же HashMap, вы можете отфильтровать ваш большой RDD, чтобы он не включал большое количество дублирующих ключей, и выполнить стандартное объединение, объединяя его с результатом ручного объединения. Этот подход довольно запутанный, но может позволить вам обрабатывать сильно искаженные данные, которые вы не могли бы обработать иначе.
Для тех, кто не знает, широковещательное соединение - это метод, при котором пользователь может избежать случайное перемешивание, возникающее при объединении двух фрагментов данных путем отправки меньшего фрагмента каждому исполнителю. Каждый исполнитель затем выполняет соединение самостоятельно. Идея состоит в том, что перемешивание настолько дорого, что каждый исполнитель выполняет объединение, а затем отбрасывает ненужные ему данные, что иногда является лучшим способом go.
. В тексте описывается ситуация, когда часть кусок данных может быть извлечен и объединен с использованием широковещательного соединения. Затем результат объединения объединяется с остальными данными.
Причина, по которой это может быть необходимо, состоит в том, что обычно можно избежать чрезмерного тасования, следя за тем, чтобы данные, состоящие из одинаковых ключей в двух чанках, оба присутствуют в одном и том же разделе, так что один и тот же исполнитель обрабатывает его. Однако существуют ситуации, когда один ключ слишком велик для одного раздела. В этом случае автор предполагает, что разделение перепредставленного ключа на HashMap и выполнение широковещательного соединения только с перепредставленным ключом может быть хорошей идеей.
Это хорошая идея? Более того, такая техника кажется очень ситуативной, поэтому Catalyst, вероятно, не использует эту технику. Это верно? Правда ли, что Catalyst не использует эту технику? Если это так, значит ли это, что для сильно искаженных данных этот метод, использующий RDD, может превзойти Catalyst, работающий с фреймами данных или наборами данных?