Хороший технический обзор [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
Из достоинств:
- с этим форматом хорошо работают библиотека 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
Medium
CSV Files for Storage? No Thanks. There’s a Better Option
Saving data to CSV’s is costing you both money and disk space. It’s time to end it.
Давно планировал написать о том почему не надо хранить и публиковать данные как 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
Для тех кто не знает, 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
Have a great data!
Why You Don't Want to Use CSV Files
“Microsoft has incompatible versions of CSV files between its own applications, and in some cases between different versions of the same application (Excel being the obvious example here).”
Eric S. Raymond
We have all been there: you are assigned an exciting…
Eric S. Raymond
We have all been there: you are assigned an exciting…
Весьма полезное руководство по форматам файлов геоданных оптимизированных для облаков [1], а это такие форматы как:
Cloud Optimized GeoTIFFs (COG)
- Zarr
- Kerchunk
- Cloud-Optimized HDF5 and NetCDF
- Cloud-Optimized Point Clouds (COPC)
- GeoParquet
- FlatGeobuf
- PMTiles
Многие из них могут быть малоизвестными широкой публике, но они быстро набирают популярность.
Ссылки:
[1] https://guide.cloudnativegeo.org
#dataformats #opendata #geodata #data
Cloud Optimized GeoTIFFs (COG)
- Zarr
- Kerchunk
- Cloud-Optimized HDF5 and NetCDF
- Cloud-Optimized Point Clouds (COPC)
- GeoParquet
- FlatGeobuf
- PMTiles
Многие из них могут быть малоизвестными широкой публике, но они быстро набирают популярность.
Ссылки:
[1] https://guide.cloudnativegeo.org
#dataformats #opendata #geodata #data
Я тут регулярно рассуждал про форматы файлов для публикации данных онлайн, в последний раз в тексте на Substack и постоянно говорю о том что надо публиковать данные в формате parquet везде где только можно, а те кто создают корпоративные озёра данных уже изучают и пишут про формат Hoodie из проекта Apache Hudi.
То что я могу сказать, так то что для открытых и иных общедоступных данных он будет применяться ещё очень нескоро. Даже формат файлов Apache Parquet, которому уже более 11 лет, за пределами data science стал применяться сравнительно недавно.
Тем не менее, за пределами форматов файлов находится платформенный режим доступа к данным. Google BigQuery как наиболее яркий пример, но есть ещё дата продукты в маркетплейсе Databricks, дата продуктах на Amazon и многих других.
#opendata #data #dataformats #datatools
То что я могу сказать, так то что для открытых и иных общедоступных данных он будет применяться ещё очень нескоро. Даже формат файлов Apache Parquet, которому уже более 11 лет, за пределами data science стал применяться сравнительно недавно.
Тем не менее, за пределами форматов файлов находится платформенный режим доступа к данным. Google BigQuery как наиболее яркий пример, но есть ещё дата продукты в маркетплейсе Databricks, дата продуктах на Amazon и многих других.
#opendata #data #dataformats #datatools