Институт открытых данных (The ODI) выпустили версию 0.4 приложения Comma Chameleon [1] - по валидации CSV файлов, а заодно и по исправлению в них ошибок. Эта версия наиболее стабильная из всех предыдущих и существует для Mac, Linux, Windows и просто как открытый код в репозитории [2].

Полезный инструмент для всех кто готовит данные для публикации и думает об автоматизации и упрощении очистки данных.
Также напомню что существуют такие сервисы и инструменты как:
- CSVLint [3] - онлайн сервис по валидации CSV файлов и с открытым кодом [4]
- CSVkit [5] - библиотека для Python по многочисленным манипуляциям с CSV файлами и множеством инструментов для командной строки
- textql [6] - инструмент по запуску SQL запросов на CSV/TSV файлах
- PapaParse [7] - парсер очень больших CSV файлов
- Countries [8] - страны мира в JSON, CSV, XML и YAML
- Tablib [9] - библиотека для работы с любыми табличными данными включая CSV

(Если Вам есть что добавить - пишите мне на @ibegtin, если есть что обсудить - приглашаю в общий чат https://telegram.me/begtinchat)

Ссылки:
[1] https://github.com/theodi/comma-chameleon/releases/tag/0.4.0
[2] https://github.com/theodi/comma-chameleon
[3] https://csvlint.io/
[4] https://github.com/theodi/csvlint
[5] https://github.com/wireservice/csvkit
[6] https://github.com/dinedal/textql
[7] https://github.com/mholt/PapaParse
[8] https://mledoze.github.io/countries/
[9] https://github.com/kennethreitz/tablib

#opendata #opengov #csv #datacleaning

Хороший технический обзор [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

В рубрике полезных инструментов работы с данными CSVFiddle [1] сервис по разбору CSV файлов из проекта DucksDb. Он построен на базе DucksDB-Wasm [2] для аналитики прямо в браузере и использует функцию read_csv_auto [3] полезную фичу DucksDb по разбору CSV файлов практически любого типа. Что особенно актуально для разбора CSV файлов экспортированных из Excel когда до колонок с данными есть всякие другие записи. Довольно частая ситуация.

CSVFiddle умеет разбирать такие данные и позволяет прямо в браузере работать с ними с помощью SQL запросов.

Я, кстати, кажется ничего не писал про DuckDB [4], а это такая весьма интересная OLAP СУБД как замена SQLite для аналитической работы. Задач для применения масса, а ещё умеет импортировать Parquet файлы.

Делает его команда исследователей из Centrum Wiskunde & Informatica в Амстердаме, год назад они создали DuckDb Labs [5], коммерческую компанию. Меня удивляет что они до сих пор не привлекли никакого венчурного финансирования, впрочем, может ещё привлекут.

Ссылки:
[1] https://csvfiddle.io
[2] https://duckdb.org/2021/10/29/duckdb-wasm.html
[3] https://duckdb.org/docs/data/csv#read_csv_auto-function
[4] https://duckdb.org/
[5] https://duckdblabs.com/news/spin-off-company-DuckDB-Labs/

#opensource #datatools #csv #dbms

Давно планировал написать о том почему не надо хранить и публиковать данные как CSV файлы.

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

Почему? Потому что он предельно прост. Первая строка - это перечень названий полей через разделитель, а далее каждая строка файла - это строка из базы данных где последовательно значения по этим полям. Разделителем, обычно, выступает запятая (,), но также часто используют: символ табуляции (\t), пайп (|), точку с запятой (;) и др.

У этой простоты есть и своя цена:
1. Файлы CSV не содержат метаданных о типах полей. Эти типы надо определять из внешнего источника или угадывать
2. При плохой реализации, велика вероятность ошибки и того что в CSV файле будут ошибки форматирования и какие-то записи могут быть прочтены неверно.
3. Диалектов очень много, это и разделители разные, выделение текста в кавычки, и разный подход к прочтению и сохранению записей с переносами строк и тд.

Об этом немало публикаций есть уже давно:
- Why You Don’t Want to Use CSV Files [1]
- Stop Using CSVs for Storage — This File Format Is 150 Times Faster [2]
- Why should you use Parquet files if you process a lot of data? [3]

Тем не менее CSV активно используют из-за его простоты. Особенно если надо сделать CSV файл из Excel файлов. Это очень распространённое явление где открытые данные были обязательными для госслужащих, это привело к тому что массово они публиковали данные в CSV формате просто сохраняя Excel файлы. Но файлы Excel не обязательно устроены так что первая строка это заголовки и последующие - это данные, часто это сложные формы и разные нетривиальные способы записи данных. Поэтому очень многие CSV файлы на госпорталах использовать автоматически не получается, приходится их проверять и чистить вручную.

Но открытые данные - это одно, а есть и просто повседневная работа с данными где у CSV должны быть альтернативы и они есть. Самая очевидная - это стандарт Frictionless Data [4] который сохраняет CSV файл внутрь ZIP контейнера и вкладывает в этот контейнер файл манифеста с метаданными, то какой там разделитель и какие типы полей. Формат на выходе называется data package и его начинают применять на некоторых научных системах хранениях данных.

Другой путь - это в сохранении данных в формате Apache Parquet [5] - это специальный открытый формат для колоночного сохранения данных. У него немало достоинств, они легко гуглятся и несколько ссылок я привел выше, но главный в том что данные ещё и хорошо сжимаются и невероятно удобны и быстры для анализа. В Parquet файлах колонки хранятся по отдельности и сжимаются по отдельности. Уровень их сжатия гораздо выше чем у CSV файлов, поскольку часто колонки имеют всего несколько значений и содержать, по сути, не уникальные значения, а словари. Parquet позволяет хранить данные в меньшем объёме и гораздо быстрее их загружать в любой инструмент работы с дата-фреймами, такими как библиотеки Pandas и Polars.

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

Ссылки:
[1] https://haveagreatdata.com/posts/why-you-dont-want-to-use-csv-files/
[2] https://towardsdatascience.com/stop-using-csvs-for-storage-this-file-format-is-150-times-faster-158bd322074e
[3] https://datos.gob.es/en/blog/why-should-you-use-parquet-files-if-you-process-lot-data
[4] https://frictionlessdata.io/
[5] https://parquet.apache.org/

#opendata #datasets #data #dataformats #datastandards #csv #likbez

Подборка полезных open source инструментов для работы с данными и не только:
- JameSQL [1] внедряемая NoSQL СУБД похожая на MongoDB. Несколько лет назад я бы сказал, "о как хорошо", а сейчас слишком много альтернатив в виде NewSQL продуктов, вроде DuckDB и аналогов. NoSQL базы уже не единственные инструменты работы с JSON'ами
- pyloid [2] библиотека для написания бэкэндов для настольных браузерных приложений/продуктов типа Electron. Для тех кто хочет писать настольные приложения на связке JS + Python
- tabled [3] библиотека и командная строка для извлечения таблиц из PDF. Лично я ещё не пробовал, а надо попробовать на неанглийском языке. Много есть PDF документов на разных языках на которых хотелось бы такое опробовать.
- nixiesearch [4] движок для организации поиска, работает поверх Apache Lucene. Выглядит неплохо, надо потестить на реально больших данных которые у нас есть. К вопросу о декларативном программировании, тут оно тоже есть, все настройки в YAML файле:)
- Vortex [5] колоночный формат файла и набор инструментов альтернативных Parquet и Apache Arrow. Выглядит интересно, но нужны сравнения. Кто сделает сравнение?
- Stricli [6] для тех кто любит командную строку и Javascript удобный фреймворк для первого на втором.

Ссылки:
[1] https://github.com/capjamesg/jamesql
[2] https://github.com/pyloid/pyloid
[3] https://github.com/VikParuchuri/tabled
[4] https://github.com/nixiesearch/nixiesearch
[5] https://github.com/spiraldb/vortex
[6] https://bloomberg.github.io/stricli/

#opensource #data #datatools #csv #pdf #search