|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Прочитал заметку что некоторые архивы (*.lz0, *.bzip2, *.lz4) поддерживают опцию разделяемости (splittable) для содержимого архивного файла. Причем это не много-томный архив как RAR а свойства одного конкретнного файла-архива. Интересно как сервисы bigdata этим пользуются? Если взять во внимание что структурированные файлы (AVRO, ORC, Parquet) и так имеют эту опцию как часть спецификации. Тогда получается что сжатие применимо к не-структурированным потокам (CSV, Json e.t.c.) которые сжаты LZO/Bzip. Но как с ними работает парсер? Каким образом достигается splittable? Вводится таблица индексов? Или в stream вводятся метки как в видео-форматах для перемотки? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2021, 16:02 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Питонщики есть? Что за баг? Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Код: python 1. 2. 3. 4. 5.
/home/mayton/.local/bin/lzo-indexer Код: python 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 00:09 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
К примеру у bzip2 есть последовательность байт 0x314159265359, которые определяют начало bzip-блока, которых может быть много. На примере хадупа (с некоторыми упрощениями): маппер начинает читать сплит сначала и все, что до начала bzip-блока отбрасывает. Если какой-то bzip-блок заканчивается в другом сплите, то маппер залазит в последующий сплит ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 00:13 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Ага. Похоже на число Пи. Правильно ли я понял следующее? Тоесть если у меня есть к примеру толстый текстовый файлик. И я его положил в bzip2. Код: sql 1. 2. 3. 4. 5.
И хочу сделать некую текстовую агрегацию в Hadoop. И известно что у меня к примеру есть 4 workers. Тогда они должны (грубо) разделить 8129486942 на 4 части. Сделать seek в нужные позиции. И дальше - найдя число "Пи" приступить к процессингу своего сплита. И на подходе к границе следующего сплита нужно также обработать хвостик своей строки которую соседний worker не обработал потому-что мы попали "внахлёст". И тут у меня - еще один вопрос. А как быть с самой природой тех данных которые мы обрабатываем? Мне повезло. У меня *.CSV файлик с одной колонкой. Небольшого размера. До 100 символов. А если-бы у меня был JSON документ где некоторые сущности мелкие а некоторые могут и половину исходного документа занимать? Есть ли тут ограничения? P.S. И кажется мне что этот БЗип2 блок должен быть кратным блоку HDFS. Сколько там? 128 Мб кажется. Какие вообще требования к размеру сплита? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 00:48 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
mayton И хочу сделать некую текстовую агрегацию в Hadoop. И известно что у меня к примеру есть 4 workers. Тогда они должны (грубо) разделить 8129486942 на 4 части. Сделать seek в нужные позиции. И дальше - найдя число "Пи" приступить к процессингу своего сплита. И на подходе к границе следующего сплита нужно также обработать хвостик своей строки которую соседний worker не обработал потому-что мы попали "внахлёст". Да, это сам hadoop все сделает mayton P.S. И кажется мне что этот БЗип2 блок должен быть кратным блоку HDFS. Сколько там? 128 Мб кажется. Какие вообще требования к размеру сплита? 1) Есть размер hdfs блока - он обычно 64/128 2) Есть размер сплита - он по-умолчанию равен размеру блока (размер сплита определяет количество сплитов, количество сплитов определяет количество мапперов) 3) Есть размер БЗип2 блока - он не привязан ни к чему, только к алгоритму сжатия (тут как его менять хз - надо смотреть как алгоритм работает и что туда прокидывать). На сколько я понимаю этот размер много меньше 64/128 мегабайт Эти параметры практически никогда менять не надо. А если надо, то это обычно на практике определяется mayton И тут у меня - еще один вопрос. А как быть с самой природой тех данных которые мы обрабатываем? Мне повезло. У меня *.CSV файлик с одной колонкой. Небольшого размера. До 100 символов. А если-бы у меня был JSON документ где некоторые сущности мелкие а некоторые могут и половину исходного документа занимать? Есть ли тут ограничения? Всем обычно везет) Если один json влезет на несколько сплитов, то надо понимать, что его будет обрабатывать только один маппер. Это все на практике надо смотреть будет ли вообще с этим проблема, и как ее исправлять. Может менять размер блоков, сплитов, форматов или выносить большие структуры в отдельные задачи и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 02:41 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
mayton Питонщики есть? Что за баг? Код написан для Питона 2. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 11:37 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky mayton Питонщики есть? Что за баг? Код написан для Питона 2. Спасиб. Час от часу не легче. Теперь для легаси-версии тоже нужно ставить пакеты. Код: python 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 17:41 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
mayton Прочитал заметку что некоторые архивы (*.lz0, *.bzip2, *.lz4) поддерживают опцию разделяемости (splittable) для содержимого архивного файла. Причем это не много-томный архив как RAR а свойства одного конкретнного файла-архива. Интересно как сервисы bigdata этим пользуются? Если взять во внимание что структурированные файлы (AVRO, ORC, Parquet) и так имеют эту опцию как часть спецификации. на сколько я помню внутри parquet файла bzip2, соответственно мапперы могут прочесть hdfs блок и понять что кусок строки ушел в следующий блок и что необходимо еще один блок прочесть что бы вытянуть недостающий кусочек. mayton Тогда получается что сжатие применимо к не-структурированным потокам (CSV, Json e.t.c.) которые сжаты LZO/Bzip. Но как с ними работает парсер? в csv тупо вокруг \n символа все крутиться. сплит посреди строки не бывает. если есть json реадер в MR, думаю там так же, \n должен отделять целостные куски, какие можно разным маперам скармливать ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2021, 22:38 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Хм... CSV не запрещает перевод строки если он внутри литерала с кавычками. Вроде тут пишут https://datatracker.ietf.org/doc/html/rfc4180 Тоесть парсер должен быть терпелив и не реагировать на первый попавшийся CR | LF. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 01:10 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
H5N1 на сколько я помню внутри parquet файла bzip2, соответственно мапперы могут прочесть hdfs блок и понять что кусок строки ушел в следующий блок и что необходимо еще один блок прочесть что бы вытянуть недостающий кусочек. К паркету у меня нет вопросов. Это структурированный документ где есть колонки. И есть размер сегмента или блока. Меня какраз интересовали non-structured/semi-structured документы вроде CSV/Json в архиве со сплитом. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 01:21 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
del ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 01:22 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
mayton Хм... CSV не запрещает перевод строки если он внутри литерала с кавычками. Вроде тут пишут https://datatracker.ietf.org/doc/html/rfc4180 Тоесть парсер должен быть терпелив и не реагировать на первый попавшийся CR | LF. бигдата тулы типа hive или mr может и уважают кавычки, но я сильно сомневаюсь что архиваторы там считают кавычки ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 10:27 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
В хадупе разархивирование происходит на уровне mr. Но да, оригинальные данные должны быть разделены делиметером (новая строка по-умолчанию). Т.е если хочется обрабатывать \n в кавычках, то придется самому реализовывать свой парсер ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 23:16 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Сгенерил AVRO-файл со сплитами по 128К. Без опции сжатия. Код: java 1. 2. 3. 4. 5. 6. 7. 8.
Код: sql 1. 2. 3.
file.avro Код: sql 1. 2. 3. 4. 5.
Примечательно что магические синк-маркеры можно менять. По дефолту они рандомные. Но видимо предметная область позволяет придумать что-то похлеще что уж наверняка сбоя синхронизации не было. Посмотрел из строчных форматов - thrift, protobuf, binaryxml (ebml). Они такого не поддерживают на прикладном уровне. Ну а мою идею совокупления архиватора и прикладного формата надо выкинуть. Или только архиватор + json. Или нормальный AVRO со встроенным независимым сжатием каждого сплита отдельно. От добра - добра не ищут. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2021, 18:57 |
|
Bigdata :: опция splittable для архивов
|
|||
---|---|---|---|
#18+
Для сжатия snappy расстояние межну синками стало меньше. Код: sql 1. 2.
Задавал codec=CodecFactory.snappyCodec() syncInterval = 64K sync = 2e04be7c94a01381b508ac656bb1aadb Код: sql 1. 2. 3. 4. 5. 6.
Кстати этот алгоритм snappy - приятно порадовал. 34 килобайта на блок вместо 64. Работает быстрее чем известные мне архиваторы. Он вобщем быстрее даже чем отсутсвие сжатия. Хорошая минимизация I/O. Сравнение времени с архиваторами bzip2, xz с сжатием = 5 (это кажется дефолтная настройка). При диапазоне от 1 до 9. Код: sql 1. 2. 3. 4. 5. 6.
И размеры Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2021, 10:38 |
|
|
start [/forum/topic.php?fid=16&fpage=2&tid=1339641]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 249ms |
total: | 379ms |
0 / 0 |