Ivan Begtin
8.09K subscribers
1.99K photos
3 videos
102 files
4.7K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech
加入频道
Forwarded from APICrafter
December 7, 2021
Хороший технический обзор [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
January 16, 2022
January 31, 2022
Про формат 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
February 5, 2022
April 26, 2023
Отличная тема в блоге 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
April 3, 2024
April 5, 2024
December 3, 2024
Для тех кто хочет поработать с относительно небольшими открытыми данными в области культуры по ссылке доступен слепок Госкаталога музейного фонда РФ в формате Parquet (3GB) преобразованный из слепка датасета в 78GB с портала данных Минкультуры.

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

Серия запросов по объединению наиболее тяжелых экспонатов по весу и получению отсортированного списка предметов по весу в любом измерении
1. copy (select name, museum.name, weight/1000 as weight from 'data.parquet' where weightUnit = '{"name":"килограммы"}' order by weight desc) to 'heavy_kg_to_tonn.csv';
2. copy (select name, museum.name, weight/100000 as weight from 'data.parquet' where weightUnit = '{"name":"граммы"}' order by weight desc) to 'heavy_gramm.csv';
3. copy (select name, museum.name, weight from 'data.parquet' where weightUnit = '{"name":"тонны"}' order by weight desc) to 'heavy_tonn.csv';
4. select * from read_csv(['heavy_kg_to_tonn.csv', 'heavy_tonn.csv']) order by weight desc;

Рейтинг музеев по качеству заполнения описания (поле description) во внесённых элементах каталога

select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where len(description) = 0 group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;

Рейтинг музеев по качеству заполнения invNumber (инвентарный номер) во внесённых элементах каталога

select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where invNumber = '' group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;

#opendata #russia #parquet #duckdb
January 24
January 24
January 29