Про разного рода технически сложные задачи и их решения.
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
К вопросу о состоянии открытости данных в РФ, я не очень верю что в ближайшие месяцы (годы?) случится чудо и оживёт государственный портал data.gov.ru. Пока не проглядывается сценарий при котором внутри гос-ва тренд на систематическую открытость вернулся. Больше шансов что мы в Dateno соберём больше данных чем когда-то было в data.gov.ru. Там уже сейчас проиндексировано много разного и можно больше.
Но есть посмотреть профиль РФ в Dateno, то там проиндексировано только около 15 каталогов данных из 154. Почему так? Можно ли лучше?
Конечно можно, и ограничения тут очень понятные:
1. Большая часть российских госресурсов сейчас не индексируются с зарубежных датацентров. Это преодолевается развертыванием прокси в РФ и индексация через прокси. И РФ не единственная страна где есть такие ограничения.
2. Значительная часть открытых данных в России публикуется по метод рекомендациям Минэка. Они очень плохо написаны, индексировать сайты публикующие данные по ним сложно, но возможно. Только этот парсер будет только под российские госпорталы, и то не все. И, по большей части, с устаревшими данными.
3. Очень много в РФ своих геопродуктов, самописных порталов данных и тд. Это также требует написания множества парсеров. Штук 40-50. Более менее стандартизированы только порталы NextGIS, Bitrix и Орбис, но их не так много.
4. Часть порталов с данными используют известное ПО типа Ipt, Pure, Figshare и до них пока ещё не дошли руки, но как только дойдут они добавятся в общий индекс.
В итоге, если специально не заморачиваться российской спецификой получится проиндексировать ещё 20-40 каталогов данных через прокси и за счёт парсеров для универсального софта, а в остальном надо приложить существенные усилия чтобы проиндексировать оставшиеся.
В этом смысле, собрать данные, например, по Финляндии гораздо проще. Там уже большая часть каталогов данных проиндексирована, да и не проиндексированные работают на типовом ПО которое тоже скоро будет индексироваться.
Вся эта национальная специфика очень сильно снижает видимость и находимость данных. И в Dateno ещё можно более-менее, но измерить эту доступность, а, к примеру, в Google Dataset Search невозможно даже посмотреть сколько датасетов и источников есть по странам.
#opendata #dateno #datasets #datacatalogs
Но есть посмотреть профиль РФ в Dateno, то там проиндексировано только около 15 каталогов данных из 154. Почему так? Можно ли лучше?
Конечно можно, и ограничения тут очень понятные:
1. Большая часть российских госресурсов сейчас не индексируются с зарубежных датацентров. Это преодолевается развертыванием прокси в РФ и индексация через прокси. И РФ не единственная страна где есть такие ограничения.
2. Значительная часть открытых данных в России публикуется по метод рекомендациям Минэка. Они очень плохо написаны, индексировать сайты публикующие данные по ним сложно, но возможно. Только этот парсер будет только под российские госпорталы, и то не все. И, по большей части, с устаревшими данными.
3. Очень много в РФ своих геопродуктов, самописных порталов данных и тд. Это также требует написания множества парсеров. Штук 40-50. Более менее стандартизированы только порталы NextGIS, Bitrix и Орбис, но их не так много.
4. Часть порталов с данными используют известное ПО типа Ipt, Pure, Figshare и до них пока ещё не дошли руки, но как только дойдут они добавятся в общий индекс.
В итоге, если специально не заморачиваться российской спецификой получится проиндексировать ещё 20-40 каталогов данных через прокси и за счёт парсеров для универсального софта, а в остальном надо приложить существенные усилия чтобы проиндексировать оставшиеся.
В этом смысле, собрать данные, например, по Финляндии гораздо проще. Там уже большая часть каталогов данных проиндексирована, да и не проиндексированные работают на типовом ПО которое тоже скоро будет индексироваться.
Вся эта национальная специфика очень сильно снижает видимость и находимость данных. И в Dateno ещё можно более-менее, но измерить эту доступность, а, к примеру, в Google Dataset Search невозможно даже посмотреть сколько датасетов и источников есть по странам.
#opendata #dateno #datasets #datacatalogs