Видеозаписи прошедших семинаров:
- "Лучшие практики работы с большими научными данными: используем Parquet и DuckDB" доступен на сайте ИВ РАН или напрямую на RuTube или на YouTube
- "Дата-инженерия в цифровой гуманитаристике" доступен в сообществе в VK и в YouTube
Если кому-то будут интересны презентации с этих семинаров, напишите в комментарии, я их выложу онлайн или пришлю ссылку.
Честно говоря я давно не читал лекций и не выступал, сначала
Ближайшие мои выступления или мастер-классы будут в рамках дня открытых данных в России и в Армении, скорее и там, и там.
P.S. Ссылки на презентации:
- Дата инженерия в цифровой гуманитаристике
- Лучшие практики работы с большими научными данными. Используем Parquet и DuckDB
#opendata #digitalhumanities #lectures #parquet #duckdb #dataengineering
- "Лучшие практики работы с большими научными данными: используем Parquet и DuckDB" доступен на сайте ИВ РАН или напрямую на RuTube или на YouTube
- "Дата-инженерия в цифровой гуманитаристике" доступен в сообществе в VK и в YouTube
Если кому-то будут интересны презентации с этих семинаров, напишите в комментарии, я их выложу онлайн или пришлю ссылку.
Честно говоря я давно не читал лекций и не выступал, сначала
Ближайшие мои выступления или мастер-классы будут в рамках дня открытых данных в России и в Армении, скорее и там, и там.
P.S. Ссылки на презентации:
- Дата инженерия в цифровой гуманитаристике
- Лучшие практики работы с большими научными данными. Используем Parquet и DuckDB
#opendata #digitalhumanities #lectures #parquet #duckdb #dataengineering
В ответ на список любви к CSV формату, я напишу свои 5 пунктов в пользу формата данных Parquet:
1. Parquet гораздо компактнее CSV и других форматов которые в него преобразуют, даже если они сжаты. Колоночное сжатие в Parquet работает гораздо эффективнее и это особенно ярко ощущается на денормализованных данных, например, статпоказателях в формате плоских файлов в режиме "1 строка=1 значение".
2. Parquet позволяет работать с данными как с базами данных позволяя на недорогих устройствах работать с данными большого объёма и быстро выполнять аналитические запросы.
3. Parquet имеет строгую схему описания и хорошую типизацию полей, а большая часть инструментов по работе с ним умеют определять типы данных динамически при создании Parquet файлов.
4. Parquet может иметь вложенные объекты в отличие от CSV файлов в Parquet есть возможность хранить структурированные вложенные объекты и Parquet файлы могут создаваться на базе JSON / NDJSON / JSON lines файлов
5. Все современные аналитические инструменты работы с данными умеют работать с этим форматом это Pandas, Polars, Clickhouse, DuckDB и многие другие. Новые инструменты появляются ежегодно и работают всё более производительно.
#data #dataformats #csv #parquet
1. Parquet гораздо компактнее CSV и других форматов которые в него преобразуют, даже если они сжаты. Колоночное сжатие в Parquet работает гораздо эффективнее и это особенно ярко ощущается на денормализованных данных, например, статпоказателях в формате плоских файлов в режиме "1 строка=1 значение".
2. Parquet позволяет работать с данными как с базами данных позволяя на недорогих устройствах работать с данными большого объёма и быстро выполнять аналитические запросы.
3. Parquet имеет строгую схему описания и хорошую типизацию полей, а большая часть инструментов по работе с ним умеют определять типы данных динамически при создании Parquet файлов.
4. Parquet может иметь вложенные объекты в отличие от CSV файлов в Parquet есть возможность хранить структурированные вложенные объекты и Parquet файлы могут создаваться на базе JSON / NDJSON / JSON lines файлов
5. Все современные аналитические инструменты работы с данными умеют работать с этим форматом это Pandas, Polars, Clickhouse, DuckDB и многие другие. Новые инструменты появляются ежегодно и работают всё более производительно.
#data #dataformats #csv #parquet
В продолжение про форматы файлов и применение CSV vs Parquet, реальная разница ощущается на больших объёмах и когда работаешь с файлами без чётких спецификаций.
Вот приведу несколько примеров:
1. Статистические данные одного крупного международного агентства, сравнительно среднего объёма в CSV файлах в десятки гигабайт и сотнях миллионов строк. Какая-либо информация о файлах отсутствует, просто выложены дампами для массовой выгрузки (bulk download). Большая часть инструментов при автоматическом парсинге файлов выдаёт что у них кодировка us-ascii, но в итоге оказывается что она windows-1250 (Центрально и Восточно европейская). Причём символы выдающие эту кодировку начинаются где-то очень далеко при обработке файлов. Механизмы автоидентификации кодировки почти все используют куски файла, а не его целиком, в результате нужно понаступать на множество грабель прежде чем настроить автоматическое преобразование этих файлов в другие форматы. Могло бы быть проще будь файлы в кодировке UTF-8, или вообще не в CSV, а в Parquet, к примеру.
2. Файлы Parquet в 800MB и 3.5GB со статистикой международной торговли. Первый может быть развернут в примерно 14GB CSV файл, второй в примерно 56GB. Это сотни миллионов и даже миллиарды записей. Аналитические запросы к таким файлам, на среднем железе, выполняются очень долго и поэтому Parquet файлы необходимо разрезать на множество файлов поменьше по продукции или по странам, в зависимости от задач применения. Но и разрезка больших Parquet файлов весьма ресурсоёмкая задача если пользоваться SQL запросами на копирование. В этом случае большие CSV файлы проще и быстрее обрабатывать потоковым образом. Проблема именно в размере Parquet файлов и решается она дистрибуцией их в меньшем размере
3. В "дикой природе" на порталах открытых данных в мире CSV файлы слишком часто публикуются просто как экспорт Excel файлов которые, в свою очередь, могут не иметь нормальную табличную структуру, а имеют множество заголовков, отклонений и тд, в общем-то не рассчитанных на автоматическую обработку, не говоря уже о разнообразных кодировках. Вручную во всем этом разумеется, можно разобраться, а автоматический анализ сильно затрудняется. Например, попытка натравить duckdb на эти файлы лишь в чуть более 50% случаев заканчивается успехом, в основном потому что duckdb не умеет разные кодировки. Альтернативные способы лучше читают файлы, но существенно медленнее.
4. Один из крупных порталов международной статистики отдаёт данные статистики в CSV формате внутри файлов заархивированных 7z. Это десятки гигабайт в сжатом виде и 1.5 терабайта в разжатом. Если необходимо обработать эти данные целиком то это требует очень много дискового пространства просто потому что 7z не адаптирован под потоковую обработку файлов, если не писать специальных инструментов для работы с ним. В итоге обработка этих данных происходит через промежуточное их разжатие в виде файлов. Всё могло бы быть куда удобнее если бы данные сразу распространялись в форматах parquet или же в CSV сжатом для потоковой обработки, например, Zstandard или даже Gzip.
В принципе сейчас всё выглядит так что мир data science сейчас parquet-first, а в остальные области работа с новыми-старыми форматами файлов приходит на пересечении с data science.
#opendata #dataengineering #fileformats #csv #parquet
Вот приведу несколько примеров:
1. Статистические данные одного крупного международного агентства, сравнительно среднего объёма в CSV файлах в десятки гигабайт и сотнях миллионов строк. Какая-либо информация о файлах отсутствует, просто выложены дампами для массовой выгрузки (bulk download). Большая часть инструментов при автоматическом парсинге файлов выдаёт что у них кодировка us-ascii, но в итоге оказывается что она windows-1250 (Центрально и Восточно европейская). Причём символы выдающие эту кодировку начинаются где-то очень далеко при обработке файлов. Механизмы автоидентификации кодировки почти все используют куски файла, а не его целиком, в результате нужно понаступать на множество грабель прежде чем настроить автоматическое преобразование этих файлов в другие форматы. Могло бы быть проще будь файлы в кодировке UTF-8, или вообще не в CSV, а в Parquet, к примеру.
2. Файлы Parquet в 800MB и 3.5GB со статистикой международной торговли. Первый может быть развернут в примерно 14GB CSV файл, второй в примерно 56GB. Это сотни миллионов и даже миллиарды записей. Аналитические запросы к таким файлам, на среднем железе, выполняются очень долго и поэтому Parquet файлы необходимо разрезать на множество файлов поменьше по продукции или по странам, в зависимости от задач применения. Но и разрезка больших Parquet файлов весьма ресурсоёмкая задача если пользоваться SQL запросами на копирование. В этом случае большие CSV файлы проще и быстрее обрабатывать потоковым образом. Проблема именно в размере Parquet файлов и решается она дистрибуцией их в меньшем размере
3. В "
4. Один из крупных порталов международной статистики отдаёт данные статистики в CSV формате внутри файлов заархивированных 7z. Это десятки гигабайт в сжатом виде и 1.5 терабайта в разжатом. Если необходимо обработать эти данные целиком то это требует очень много дискового пространства просто потому что 7z не адаптирован под потоковую обработку файлов, если не писать специальных инструментов для работы с ним. В итоге обработка этих данных происходит через промежуточное их разжатие в виде файлов. Всё могло бы быть куда удобнее если бы данные сразу распространялись в форматах parquet или же в CSV сжатом для потоковой обработки, например, Zstandard или даже Gzip.
В принципе сейчас всё выглядит так что мир data science сейчас parquet-first, а в остальные области работа с новыми-старыми форматами файлов приходит на пересечении с data science.
#opendata #dataengineering #fileformats #csv #parquet