Ivan Begtin
7.98K subscribers
1.8K photos
3 videos
101 files
4.51K 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
Download Telegram
Институт открытых данных (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, если есть что обсудить - приглашаю в общий чат http://telegram.me/begtinchat)

Ссылки:
[1] https://github.com/theodi/comma-chameleon/releases/tag/0.4.0
[2] https://github.com/theodi/comma-chameleon
[3] http://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
Forwarded from APICrafter
Обновления в каталоге APICrafter

Что нового
1. Данные о пакетах данных теперь публикуются более компактно. Страница пакета данных теперь включает сведения о характеристиках, таблицах и сборках данных вместе. Например [1] [2]
2. Таблицы открытых наборов данных теперь можно скачать в форматах JSONl, CSV и Parquet. Ссылки на данные публикуются на странице таблицы, например, "Точки обмена" [3]

Экспорт данных сейчас работает со следующими ограничениями:
- экспорт только для наборов данных менее чем с 100 тысячами записей
- форматы csv и parquet доступны только для таблиц без вложенных объектов
- сборки данных включают все данные и доступны всегда

Формат Parquet [4] популярен в data science и активно используется с помощью Jupyter Notebook.

Мы обязательно опубликуем примеры его использования.

Ссылки:
[1] https://tinyurl.com/2s3vuxaf
[2] https://tinyurl.com/2p89vp2k
[3] https://tinyurl.com/yckma22e
[4] https://tinyurl.com/mr4xjdmd

#apicrafter #datascience #datasets #parquet #json #csv
Хороший технический обзор [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
Иногда поражает какие стартапы получают финансирование, например, стартап OneSchema [1] автоматизирует загрузку и проверку CSV файлов. Основатели позиционируют свой продукт как the embeddable CSV importer for developers и получили недавно $6.3 миллиона инвестиций от нескольких венчурных фондов.

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

Это хороший пример небольшого, но очень точного продукта для работы с данными решающего очень узкую задачу и оказавшегося востребованным.

Ссылки:
[1] https://www.oneschema.co
[2] https://www.oneschema.co/blog/oneschema-announces-6m-fundraise

#datatools #startups #data #csv
Давно планировал написать о том почему не надо хранить и публиковать данные как 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