A
когда-то и map-reduce голово со сбросом данных на диск хватало
Size: a a a
2021 April 01
ПФ
оно ведь не вопрос “как работало”, а в том “как быстро это работало”
Ну типа того, да.
Remove redundant sorts before repartition nodesПФ
Эта штука может стоить бесконечного времени
ИК
Знаю, что udf зло, но можно ли вообще как либо расширить функционал объявленый в spark sql?
Кастомные функции с кодогенерацией. Можно загуглить или глянуть эту статью:
https://medium.com/@fqaiser94/udfs-vs-map-vs-custom-spark-native-functions-91ab2c154b44
https://medium.com/@fqaiser94/udfs-vs-map-vs-custom-spark-native-functions-91ab2c154b44
ИК
Всем привет. Вот такой вопрос. В RDD есть понятие known partitioner. И в джойнах одинаковые известные партишенеры не приводят к пересылкам. Но я никак не помогу понять, работает ли эта терминология для датафреймов? Поэкспериментировав понимаю, что вроде бы нет, Exchange оператору как будто бы плевать на это дело и опять же неясно, как вообще можно сравнить партишенеры двух датафреймов
В плане проверяется partitioning/distribution для обоих DF, потом каталист решает, что использовать по своему усмотрению, собственно партишенер RDD как экземпляр/класс в этой проверке не участвует. Довольно комплексный процесс, дело осложняется тем, что Distibution - sealed и не может быть расширен. С точки зрения нового партишенера для датафреймов не очень удобно, пришлось передавать распределение через аргумент, иначе он не сохраняется
IS
В плане проверяется partitioning/distribution для обоих DF, потом каталист решает, что использовать по своему усмотрению, собственно партишенер RDD как экземпляр/класс в этой проверке не участвует. Довольно комплексный процесс, дело осложняется тем, что Distibution - sealed и не может быть расширен. С точки зрения нового партишенера для датафреймов не очень удобно, пришлось передавать распределение через аргумент, иначе он не сохраняется
Можно чуть помедленнее, пожалуйста?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
N
Можно чуть помедленнее, пожалуйста?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
Разные значения этой колонки могут лежать на разных экзекьюторах/нодах. Чтобы шафла не было, мало простого совпадения колонки
ИК
Можно чуть помедленнее, пожалуйста?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
Если у нас два датафрейма имеют одну партишен колонку, то разве не просто без шафла их джоинить?
Почему это комплексный процесс?
с тех пор, как появился RangePartitioner, всё стало несколько запутаннее)) И одной партишен-колонкой дело не ограничивалось никогда, нужно было совпадение числа партиций
IS
Резонно, понял
N
Пример как избежать шафла
ИК
К тому же RangePartitioner и RoundRobinPartitioner не могут обеспечить совпадение ключей в партициях. Это делаеть только и исключительно HashPartitioner, а совпадение распределений проверяется через кейс-классы - наследники sealed trait Distribution
IS
Крутая штука
Т.е. теория гласит, что если мы будем не "партишенить", а "бакетить", то без шафла сможем джоинить датафреймы?
Т.е. теория гласит, что если мы будем не "партишенить", а "бакетить", то без шафла сможем джоинить датафреймы?
ИК
Крутая штука
Т.е. теория гласит, что если мы будем не "партишенить", а "бакетить", то без шафла сможем джоинить датафреймы?
Т.е. теория гласит, что если мы будем не "партишенить", а "бакетить", то без шафла сможем джоинить датафреймы?
И вот, HashPartitioner настроен на то, чтобы быть совместимым с Hive bucketed table, но с Hive всё не очень складывается, зато в самом спарке работает неплохо. Поэтому спарковские бакетированные таблицы действительно не нужно шафлить, чтобы джойнить с произвольным датафреймом, потому что будет зашафлен этот датафрейм
IS
И вот, HashPartitioner настроен на то, чтобы быть совместимым с Hive bucketed table, но с Hive всё не очень складывается, зато в самом спарке работает неплохо. Поэтому спарковские бакетированные таблицы действительно не нужно шафлить, чтобы джойнить с произвольным датафреймом, потому что будет зашафлен этот датафрейм
Понял, спасибо!
IS
Новый день - новое знание
ИК
при условии совпадения ключей, конечно!
ИК
если джоин не по бакет-полям, всё будет перемешано
IS
Да, это уже совсем медленным языком)
IS
Спасибо)