Я вчера задавал вопрос. А может кто-то ответить. У меня ощущение, что я пропустил что-то важное. Кто-нибудь может пояснить контекст?

Я немного не понял, а в каком контексте речь шла о том, что Спарк иногда cpu-bound, а не I/o. То есть это к чему (сорри не уловил)?

Ты задал вопрос, но сделал это без уважения, поэтому сиди и страдай теперь ))

🤣🤣🤣

Можно я буду использовать это в качестве комментария на стековерфлоу?

Репутацию мне сольют, конечно, но оно того стоит

+

Ладно, чет это по-мудацки вышло. Кароч, как я понял, возможно неверно. При чтении паркетов, типа кучи мелких файлов, Спарк тратит просто дохера процессорного времени на конвертации столбцов в Internal row и вот эта бодяга становится более cpu bound, чем io bound

Но лучше я бобу в слачке сейчас вопрос задам

чот странно. По идее должно быть похер если схема уже выведена

Ну то есть глобально похер

а если я читаю уже со схемой?

Ну вот это то, о чём я говорю

Не понял, а при чем тут схема, если тупо формат столбцовый, а его надо в Internal row сконвертить

Ну то есть конечно там есть расходы на декомпрессию, на превращение столбцов в строки и так далее. Но кажется что прочитать маленький файл в память и там всё расжать сложнее чем большой файл

в том, что если нет схемы, он в каждый файл лезет и читает ее, и потом пытается вывести общую

представь себе что тебе надо прочесть паркет с миллиардом строк, где первый столбец схлопывается в одну запись, второй в две, третий в 4 и так далее. Тебе придётся в памти гигантский экспанд делать. Если же у тебя в файле 1000 строк — то такой экспанд будет гораздо меньше и гораздо легче влезет в ноду.

где у меня ошибка в логике?

Хз, я чет плохо представляю внутрянку паркета по ходу

Он почти как орк:
в конце меджик, хранящий размер футера, в футере схема и указатели на позиции страйпов и всякая мета, каждый страйп хранит заголовок с информацией о колонках какой-то, пожаты ли эти колонки и так далее. Дальше после заголовка страйпа ты читаешь данные подряд и оказывается что ты прочитал первую пожатую колонку, вторую и так далее.

Без зависимостей на: spark-core, kafka и сейчас еще ищу откуда взять org/apache/kafka/common/protocol/SecurityProtocol - не стартует kafkaTestUtils.setup(). Возможно инфа про это есть где-то в предыдущих частях статей, если так то стоит дать ссылку в туда.

Применяемый в примере кода Utils.deleteRecursively является приватным объектом из внутрянки спарка, то есть доставать этот метод надо тоже через хак, по аналогии с PublicKafkaTestUtils
И это пример всё еще не запустился…

Второй вариант это написать перед примером кода - это просто пример, который показывает базовый принцип но не запускается

Третий вариант, в конце статьи дать ссылку на репозиторий где будут микро-проекты с рабочими примерами - это в разы повысит полезность материала.