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

На s3 вот мы не знаем нами ли блоки, например

А поскольку каждый блок ещё и реплицирован - если повезёт далее не упрётся в чтение с одного диска

Окей, то есть по факту с размером блока в HDFS это никак не связано? Твой поинт что I/O параллелится за счёт блоков?

Ну, не настраиввется так типа "хочу читать по 1кб данных, чтоб они превращались в один инпут таск"

Мне казалось, что там спокойно инпут сплит сайз указывается, не?

За счёт инпут сплитов, они могут быть меньше блока

Указывается да, а кто-нибудь проверял, работает ли он так, как предполагается?😆

Ну я, честно говоря, особо не игрался.
По крайней мере, до килобайтов.
Он у тебя тупо игнорил твои вводные?

Я своими руками пытался прочитать третью строчку паркета не читая первые две. Это очень, очень сложно (хотя теоретически возможно). В спарке такой фасилити нет, будет читать минимум страйдами. Но вот вероятно дальше он может данные раскидать

Не игнорил, но зависимость какая-то сильно нелинейная)

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

Кстати, есть какие-то лучшие практики на тему какой кодек компрессии лучше с паркетом использовать?

Если у вас совсем напряг с местом, и нужно впихнуть невпихуемое - наверно имеет смысл перейти на гзип, а так снаппи и быстрее, и жмёт ок

Понял

Снэппи )

Но вообще лучше орк ЕМНИП, там лучше получается сжатие потому что формат немного умнее

+

Спасибо за помощь!
Правильно ли я понимаю - количество spark-партиций при чтении этого паркета на следующем шаге пайплайна будет зависеть от maxPartitionBytes, а не от количества паркетов в директории, откуда производится чтение?
И даже если я на предыдущем шаге при записи запихнул 2 Гб в один паркет с помощью coalesce(1) - в случае если  maxPartitionBytes=128Мб мой датасет на 2Гб будет разбит при чтении спарком на 16 партиций? (2Gb dataset size / 128Mb maxPartitionBytes)

Кстати, раз уж про орк: если на полу колонку применились одновременно delta и run length энкодинг - то прочитать n строчку будет так дорого, что легче прочитать и забыть предыдущие строки )