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