zstd

Упрется в скорость диска

Как пример лог в 5т прочесывался на скорости дисков, и сжимался до сотни гб

он говорит через один из трех методов:
1. поднимает свой гейтвей через спарк сабмит
2. говорит с ливи
3. говорит с датабрикс по их апи

ливи по-умолчанию

но вообще бэкенд для dplyr можно написать и иначе, у нас например бэкенд это тонкая обвязка на R вокруг гошного драйвера (и для питона этот же драйвер используется)

Подскажите пожалуйста как легче или проще всего определить data skew в паркет файле?

По размеру файла можно предположить, что это потенциальный кандидат с data skew, но там также может быть нормальное распределение.

ну и с вашим инвентарем поджоинить, чтобы размеры файла узнать

Спасибо. Мне нужны скорее статистические характеристики, типа вот этого (нашёл по вашей ссылке):


Aggregate function: returns the skewness of the values in a group.

Ребята, помогите плиз кмк, с performance проблемой spark structured streaming & kafka

В общем, есть кафка топик на 24 партиции, с не skew распределенными ключами. Так же есть spark-streming jobа, которая пытается выгрясти все даннные из этого топика. Message в топике достаточно маленькие, но их очень много - 13 миллиардов. Кластеру spark - консюмеру выделил 8 "жирных" (core, ram) нод, но через Spark UI вижу, что на первом стейдже висят 24 активные таски, и только один executor & driver. Все остальные 7 нод отвалились, поскольку они долго были в idle статусе.

2 часа назад запустил streamer (spark 3.1, scala 12), и за это время он обработал только 500М строк. Собственно вопрос, куда копать, чтоб увеличить пропускную способность джобы?

Hello Almaz jan! 🙂
а 24 таски действительно что-то делают. в их логах что-то проскакивает? на стороне Кафки нет перекосов (много партиций на одном брокере)?

Ого, какие люди)

Так и есть, таски выгребают данные из кафки, но слишком медленно. За 2 часа они выгребли 500М сообщений, а над 13млрд.

По поводу перекосов на стороне Кафки, вроде нет, как точно это посмотреть? На дашборде от кафки ничего странного нет

если Spark3, то у него в Spark UI появилась вкладка Structured Streaming, с графиками - input rate/ processing rate/ latency - какая там частота входящего потока?

странно, что становятся idle и "отваливаются" 7 экзекуторов, тогда как чтение идет...

КМК, тут проблема именно в тулинге/конективности между spark & kafka. Либо не те ключи/параметры указаны в спарк джобе, либо проблемы с офсетами на кафке, либо еще что-то, что я не знаю

Насчет отваливания нод, мне кажется здесь нет проблем, поскольку это часть Dynamic Resource Allocation и они должны отваливаться.

Почему я так думаю?
Поскольку каждый экзекютор достаточно "жирный", то спарк может на одну ноду заассайнить все 24 таски (кол-во партиций откуда считывать данные). В итоге, 24 таски аллоцируются на одну машину, все остальные 7 ждут следующих спарк стейдей/джоб, и если долгое время они его не получают - то они отваливаются. Это можно увидеть в евент логе кластера

а если как советуют тут - увеличить опцию minPartitions до 48/72 ?