Хороший технический обзор [1] том почему вместо файлов в формате CSV лучше использовать формат Parquet [2] из экосистемы Apache Hadoop. Формат этот, в отличие от CSV, адаптирован изначально под инструменты вроде Pandas и для аналитики он значительно удобнее, к тому же, и на этом акцент в обзоре, он изначально обеспечивает сжатие данных до 4-х раз при этом сохраняя возможность их загрузки в pandas и другие аналитические инструменты.

Из достоинств:
- с этим форматом хорошо работают библиотека pandas, разные инструменты для экосистемы Apache Hadoop, его поддерживает PowerBI и Tableau
- лучшее сжатие данных, до 4-х раз меньше чем CSV
- ускоряет запросы при загрузке в pandas, поскольку изначально колоночный, а не построчный формат

Из недостатков:
- не подгружается в Excel стандартными средствами
- нет стандартных инструментов загрузки в СУБД (SQL или No SQL), в отличие от CSV
- нет инструментов а ля csvkit позволяющих гибко обрабатывать данные

Мы в DataCrafter'е в конце прошлого года добавили экспорт данных в форматах CSV, JSON lines и Parquet к большинству наборов данных. Можно посмотреть вот тут на примере Действующего справочника поставщиков лекарственных средств [3]. Ко всем данным, конечно, добавить его сложно поскольку некоторые данные у нас в каталоге - это много гигабайт и миллионы записей и они доступны только через API и через ZIP файлы с экспортом, но для всех таблиц с менее чем 100 тысячами записей такой экспорт работает, а данные актуализируются.

Parquet не единственный интересный формат для хранения данных и сжатие не единственный важный критерий для форматов данных. Есть полезные обзоры сравнения Parquet, Avro и CSV [4] и Parquet, Apache Orc [5], а также Paquet, Avro и Orc [6] и у каждого из них свои важные полезные особенности, например, Avro гораздо лучше адаптирован под изменение схем данных.

Но, Avro и Orc ещё хуже поддерживаются общедоступными аналитическими инструментами, а есть и другие форматы такие как Protocol Buffers, XML, JSON. Например, в этом обзоре сравнение их возможностей [7]

И тут я, конечно, не могу не обратить внимание что за пределами корпоративного сектора и Modern Data Stack эти форматы практически не используются. В большинстве порталов открытых данных используются обычно CSV, реже XML, реже JSON и ещё какое-то количество унаследованных форматов данных вроде MS Access или DBF.

Адаптация современных порталов открытых данных, да и вообще порталов с данными, например, статистическими и аналитическими - это доступность данных в том числе в аналитических форматах, удобных для быстрой загрузки в инструменты вроде Power BI, Tableau или в сервисы обработки данных (data pipelines, ETL, ELT и др) и многое другое.

Ссылки:
[1] https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d
[2] https://en.wikipedia.org/wiki/Apache_Parquet
[3] https://data.apicrafter.ru/packages/roszdravvendors
[4] https://medium.com/ssense-tech/csv-vs-parquet-vs-avro-choosing-the-right-tool-for-the-right-job-79c9f56914a8
[5] https://medium.com/@dhareshwarganesh/benchmarking-parquet-vs-orc-d52c39849aef
[6] https://oswinrh.medium.com/parquet-avro-or-orc-47b4802b4bcb
[7] https://www.adaltas.com/en/2020/07/23/benchmark-study-of-different-file-format/

#opendata #data #dataformats #datastandards #csv #avro #parquet #orc

В блоге Uber Engineering полезная заметка об оптимизации формата Parquet [1] с точки зрения сжатия, хранения и скорости работы. Автор рассказывает как они используют Parquet в экосистеме Hadoop'а у себя внутри для обработки и хранения данных измеряемых петабайтами и том что хранение в таких объёмах обходится дорого и после многих экспериментов они остановились на формате Parquet со сжатием через ZSTD и что это значительно эффективнее чем Snappy/Gzip по балансу скорости обращения к данным и уровню сжатия.

Но что интереснее автор приводит ещё и трюк с сортировкой данных который позволяет значительно улучшить сжатие предварительно проведя сортировку данных в колонках. Причём очень многое зависит от порядка сортировки полей, в их случае при порядке начинающегося с поля uuid достигается наилучший результат. В основе этого эксперимента статья Reordering Rows for Better Compression: Beyond the Lexicographic Order [2].

Случай Uber'а с хранением таких объёмов, конечно, довольно редкий, такое есть только в крупнейших стартапах/корпорациях. Есть много задач сильно меньше, до терабайтов, где также надо работать с разными форматами данных и Parquet выглядит всё более привлекательным для хранение и распространения данных для аналитической работы.

Ссылки:
[1] https://eng.uber.com/cost-efficiency-big-data/
[2] https://arxiv.org/pdf/1207.2189.pdf

#parquet #data #reading #dataengineering

Про формат Parquet я многократно писал и давал ссылки, а вот сравнение от Databricks его же с CSV [1]. Если кратко то CSV проигрывает Parquet по всем статьям, сравнение проводилось в экосистеме Amazon AWS:
- экономия при хранении данных на 87%
- в 34 раза быстрее отрабатываются запросы
- на 99% меньше данных надо сканировать
- финансовая экономия до 99.7%

Недостаток Parquet'а для человекочитаемости компенсируется появлением инструментов для GUI и командной строки которые эту проблему снимают. Она, вообще не так значима как кажется.

Лично я считаю что статистику, многие другие данные с временными рядами и иные большие наборы данных которые сразу берут в работу аналитики, можно и нужно публиковать сразу в Parquet. Это даёт не только экономию в хранении, но и сильно облегчает работу аналитиков. Тем более что многие инструменты вроде Power BI и Tableau их его поддерживают.

Ссылки:
[1] https://databricks.com/glossary/what-is-parquet

#fileformats #data #parquet

Про сжатие данных и о том почему я регулярно пишу что Parquet - это реально значимый формат хранения и обмена данными, важнее довольно многих.

Я приведу в пример данные с которыми я лично работал в аналитических задачах. У меня есть выгрузка слепка данных из российского реестра юридических лиц ЕГРЮЛ в виде 11 миллионов записей в которых 12 полей-признаков места организации, её типа, кода окопф, оквэд, кладр, статус ликвидации и тд. Без названий и без идентификаторов, данные нужны только для аналитической работы и построения кубов и срезов для BI. В общеё сложности - это 4.07ГБ. Не очень много когда один файл и много когда таких файлов десятки. С файлом нужно иметь возможность работать, загружать в СУБД или библиотеку вроде Pandas. Как сжать эти данные?

Самое очевидное - это сжать классическими архиваторами и хранить так. Gzip даёт сжатие до 337 МБ это примерно 8.3%, альтернативный Gzip'у архиватор LZ4 для быстрого сжатия и разжатия даёт компрессию до 340МБ это тоже примерно 8.3%, а LMA-архивация с помощь. XZ даёт 136МБ это примерно 3%, но она работает значительно медленнее. Все архиваторы проверялись в режиме максимального сжатия (ключ -9).

Так вот, а если этот же CSV файл преобразовать в parquet формат со сжатием, то итоговый файл получается размером в 109МБ, это примерно 2.7% от оригинального и, при этом, с ним весьма удобно работать с инструментами вроде Pandas при том что скорость преобразования значительно быстрее чем сжатие с помощью xz, к примеру. Во многом, похоже, это происходит из-заавтоматической идентификации типов полей и их преобразования.

Причём даже если повторить используемый в parquet трюк с колоночным сжатием, так просто такой результат повторить непросто. Например, у меня есть код который из CSV файла создаёт пучёк одноколоночных CSV файлов сжатие которых по отдельности должно быть лучше чем сжатие оригинального файла. Сжатые одноколоночные файлы дают дополнительное сжатие. GZIP файлы таких файлов занимают 221 МБ вместо 337 МБ. Аналогично для lz4 и только для xz размер общий файлов увеличивается до 139 МБ.

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

Отдельная история про сжатие данных для долгосрочного хранения и для сохранения интеграции с унаследованными системами. Тем не менее, имея выбор формата для хранения данных - Parquet это хороший выбор.

Для того чтобы он стал отличным ему нехватает только некоторых опций работы стандартными инструментами. Чтобы его можно было открыть в Excel, в браузере, в чтобы были аналоги grep/cat/awk/sed или csvkit и ещё много разных других инструментов. Тем не менее и сейчас его уже можно использовать.

#dataengineering #data #compression #parquet

Отличная тема в блоге DuckDB про 42.parquet или о том как запихнуть в Parquet файл 4 петабайта данных [1]. Для тех кто не вспомнил контекст, несколько лет назад по интернету ходил файл zip bomb, с названием 42.zip и размером в 42 килобайта. Внутри него, 5 вложенными слоями было по 16 пустых файлов в 4.3 ГБ. В общей сложности 4.3 петабайта. А это штука способная сильно испортить жизнь тем кто использует наивные антивирусы и другие сервисы распаковки архивов. Про него есть статья в Википедии по ссылками [2] для тех кто хочет изучить тему. Я специально про это не писал до 1 апреля во избежание обострения юмора у весёлых ребят;)

Как ни странно, Virustotal показывает [3] что запароленный zip bomb определяет только Fortinet, остальные сервисы и продукты его игнорируют. Может быть они незапароленные zip bomb ловят? Но пока не хочется проверять такое;)

А теперь то же самое для Parquet, 42.parquet от DuckDB. Может быть довольно жестокой шуткой над каким-то дата сайентистом, а может быть просто примером для тренировки навыков.

Я пока не знаю случаев когда сайты/информационные системы взламывали бы parquet файлами. Но может быть всё впереди? Например, начнут антивирусы и другие инфобезные продукты отслеживать утечки персональных данных из компаний и начнут сканировать parquet файлы, а тут им подсунут 42.parquet.

Похоже на реальный сценарий ;)

Ссылки:
[1] https://duckdb.org/2024/03/26/42-parquet-a-zip-bomb-for-the-big-data-age.html?
[2] https://en.wikipedia.org/wiki/Zip_bomb
[3] https://www.virustotal.com/gui/file/bbd05de19aa2af1455c0494639215898a15286d9b05073b6c4817fe24b2c36fa

#data #datatools #dataspecs #parquet #readings

К вопросу о том почему я так часто писал в последнее время про форматы данных вроде Parquet которые из data science постепенно перебираются в другие дисциплины работы с данными. Вот наглядный пример, у меня на руках датасет который в несжатом виде занимает 195GB, а в сжатом .tar.gz около 22GB. Его владелец распространяет его именно в сжатой форме, но понятно что для работы с ним его приходится распаковывать, особенно учитывая что tar.gz не тот формат с которым удобно работать без полного его разжатия. Внутри датасета сплошные .jsonl файлы, удобный при любой работе с NOSQL, но не для хранения.

При этом, если пересжать все данные в архиве в формат parquet, то они сожмутся до 8-12GB, и с ними можно будет продолжить работу. Загрузить в СУБД из parquet в общем-то не проблема.

В целом получается настолько большой выигрыш что игнорировать такие инструменты просто нельзя.

И сюда же, кстати, про мои давние размышления про поиск замены OpenRefine. Самым интересным продуктом было бы если бы внутренний движок OpenRefine можно было бы заменить на DuckDB. Тогда можно было бы на стандартном десктопном железе работать по очистке датасетов условно почти любого размера.

#data #datatools #parquet #duckdb