Spark SQL (Scala) - Какой самый эффективный способ объединения двух очень больших таблиц с перекосом ключей - PullRequest
0 голосов
/ 26 апреля 2018

Моя текущая работа заключается в создании процессов ETL с SparkSQL / Scala с использованием Spark 2.2 с поддержкой Hive (все таблицы находятся на складе Hive / HDFS).

Один конкретный процесс требует объединения таблицы с 1b уникальных записей с другой из 5b уникальных записей.

Ключ соединения перекошен, в том смысле, что некоторые ключи повторяются намного чаще, чем другие, но наш Hive не настроен на перекос по этому полю, и это невозможно реализовать в текущем кенарио.

В настоящее время я читаю каждую таблицу в два отдельных кадра данных и выполняю соединение между ними. Пробовал внутреннее соединение и правое внешнее соединение в таблице 5b, чтобы увидеть, был ли какой-либо выигрыш в производительности (я бы потом отбросил строки с нулевыми записями). Не мог заметить, но это могло быть вызвано нестабильностью кластера (я не уверен, что для правильного объединения потребуется меньше перетасовки, чем для внутреннего)

Попробовал отфильтровать ключи из таблицы 1b в таблице 5b, создав временное представление и добавив предложение where к оператору select таблицы 5b, но все равно не смог заметить какого-либо увеличения производительности (obs: собрать невозможно уникальные ключи из таблицы 1b, так как это вызовет исключение памяти). Также пытался выполнить все это в одном SQL-запросе, но опять не повезло.

Я читал, что некоторые люди говорили о создании PairRDD и выполнении partitionBy с помощью hashPartitioner, но это кажется устаревшим с выпуском фреймов данных. Сейчас я нахожусь в поиске надежного руководства по объединению двух очень больших наборов данных.

edit: здесь есть ответ здесь , который в значительной степени решает ту же проблему, что и я, но ему 2 года и просто говорит мне сначала присоединиться к транслируемому набору записей которые соответствуют ключам, которые многократно повторяются, а затем выполняют другое объединение с остальными записями, объединяя результаты. Это все еще лучший подход к моей проблеме? У меня есть перекос ключей на обеих таблицах

...