Про формат 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

В рубрике как это работает у них, о том что не все форматы файлов для работы с данными сводятся к CSV, SQL, JSON и другим наиболее распространённым. На порталах открытых данных часто встречаются файлы в непривычных форматах, например PX [1], этот формат ещё называют PX-Axis потому что он используется в одноимённом программном продукте который позже переименовали в серию продуктов PxWeb, PxWin и PxEdit. PxWeb и PxWin были разработаны статистическим ведомством Швеции [2] и переведены, по большей части, в открытый код. А PxEdit сделали в статистическом ведомстве Финляндии [3].

Во многих странах и организациях собирающих статистику этот программный пакет весьма популярен. Например, в Испании на портале открытых данных страны в формате PX-Axis опубликовано 24 169 наборов данных [4]. Все эти файлы это индикаторы из национальных и региональных статистических систем. У многих регионов Испании они свои и практически все дают возможность получения данных показателей в разных форматах. Аналогично публикуются 7 131 статистический индикатор в Ирландии в виде наборов открытых данных на официальном портале [5] и, конечно же, непосредственно в Швеции, Финляндии и во многих других странах.

Столкнуться с этим форматом в России практически невозможно, российская статистика преимущественно использует свои внутренние форматы + некую версию SDMX. В других постсоветских странах, большая часть статистики публикуется только в Excel или самостоятельно разработанных информационных системах, вроде Талдау в Казахстане. Но если Вам доведётся поработать с данными в других странах, то с PX файлами можно столкнуться.

Ссылки։
[1] https://www.scb.se/en/services/statistical-programs-for-px-files/px-file-format/
[2] https://www.scb.se/en/services/statistical-programs-for-px-files/
[3] https://www.stat.fi/tup/tilastotietokannat/px-tuoteperhe_en.html
[4] https://datos.gob.es/es/catalogo?res_format_label=PC-Axis
[5] https://data.gov.ie/dataset?res_format=PX

#opendata #datasets #fileformats #data

Про разного рода технически сложные задачи и их решения.

Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.

Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.

Причём именно в такой комбинации. Почему так?

DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.

Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.

CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.

Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.

Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.

Ссылки:
[1] https://github.com/datacoon/undatum

#thoughts #data #datatools #fileformats #dateno

В продолжение про форматы файлов и применение CSV vs Parquet, реальная разница ощущается на больших объёмах и когда работаешь с файлами без чётких спецификаций.

Вот приведу несколько примеров:
1. Статистические данные одного крупного международного агентства, сравнительно среднего объёма в CSV файлах в десятки гигабайт и сотнях миллионов строк. Какая-либо информация о файлах отсутствует, просто выложены дампами для массовой выгрузки (bulk download). Большая часть инструментов при автоматическом парсинге файлов выдаёт что у них кодировка us-ascii, но в итоге оказывается что она windows-1250 (Центрально и Восточно европейская). Причём символы выдающие эту кодировку начинаются где-то очень далеко при обработке файлов. Механизмы автоидентификации кодировки почти все используют куски файла, а не его целиком, в результате нужно понаступать на множество грабель прежде чем настроить автоматическое преобразование этих файлов в другие форматы. Могло бы быть проще будь файлы в кодировке UTF-8, или вообще не в CSV, а в Parquet, к примеру.

2. Файлы Parquet в 800MB и 3.5GB со статистикой международной торговли. Первый может быть развернут в примерно 14GB CSV файл, второй в примерно 56GB. Это сотни миллионов и даже миллиарды записей. Аналитические запросы к таким файлам, на среднем железе, выполняются очень долго и поэтому Parquet файлы необходимо разрезать на множество файлов поменьше по продукции или по странам, в зависимости от задач применения. Но и разрезка больших Parquet файлов весьма ресурсоёмкая задача если пользоваться SQL запросами на копирование. В этом случае большие CSV файлы проще и быстрее обрабатывать потоковым образом. Проблема именно в размере Parquet файлов и решается она дистрибуцией их в меньшем размере

3. В "дикой природе" на порталах открытых данных в мире CSV файлы слишком часто публикуются просто как экспорт Excel файлов которые, в свою очередь, могут не иметь нормальную табличную структуру, а имеют множество заголовков, отклонений и тд, в общем-то не рассчитанных на автоматическую обработку, не говоря уже о разнообразных кодировках. Вручную во всем этом разумеется, можно разобраться, а автоматический анализ сильно затрудняется. Например, попытка натравить duckdb на эти файлы лишь в чуть более 50% случаев заканчивается успехом, в основном потому что duckdb не умеет разные кодировки. Альтернативные способы лучше читают файлы, но существенно медленнее.

4. Один из крупных порталов международной статистики отдаёт данные статистики в CSV формате внутри файлов заархивированных 7z. Это десятки гигабайт в сжатом виде и 1.5 терабайта в разжатом. Если необходимо обработать эти данные целиком то это требует очень много дискового пространства просто потому что 7z не адаптирован под потоковую обработку файлов, если не писать специальных инструментов для работы с ним. В итоге обработка этих данных происходит через промежуточное их разжатие в виде файлов. Всё могло бы быть куда удобнее если бы данные сразу распространялись в форматах parquet или же в CSV сжатом для потоковой обработки, например, Zstandard или даже Gzip.

В принципе сейчас всё выглядит так что мир data science сейчас parquet-first, а в остальные области работа с новыми-старыми форматами файлов приходит на пересечении с data science.

#opendata #dataengineering #fileformats #csv #parquet

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

С чего начать тем кто ищет информацию о структурах файлах и того как работать с разными форматами работать?

1. PRONOM

Это специальный реестр форматов файлов от Национальных Архивов Великобритании и он включает подробное описание сотен форматов файлов включая форматы разных старых приложений или относительно новые форматы для данных такие как JSONl. В реестре PRONOM присутствуют и цифровые отпечатки файлов, помогающие их идентифицировать. Эти отпечатки используются в утилите DROID для идентификации типов файлов по большому их реестру. Утилита сама не обновлялась давно, но цифровые отпечатки из PRONOM обновляются довольно часто, чуть ли не ежемесячно

2. Archive Team Wiki (File formats)

У команды ArchiveTeam есть большой вики проект fileformats.archiveteam.org с большим числом практических статей по разным форматам файлов и о том как с ними работать и как их архивировать. Полезный сайт для всех кто погружается в работу с какими либо относительно популярными файловыми форматами. Вики ArchiveTeam полезно именно своей практичностью и включает материалы из множества источников.

3. MultimediaWiki

Другой Вики проект доступный по адресу wiki.multimedia.cx и включающий описание многих мультимедийных форматов включая те что используются в игровой индустрии и многое про то как заниматься реверс инжинирингом кода для извлечения интересных материалов из тех же игр.

4. IANA Mimetypes

Это реестр mime типов на сайте IANA, покрывает те форматы файлов для которых mime типы зарегистрированы, их много, но не исчерпывающе. Важнее подробное описание каждого типа и ссылки на сами спецификации и области применения.
—

#readings #fileformats