Весьма полезное руководство по форматам файлов геоданных оптимизированных для облаков [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

Про разного рода технически сложные задачи и их решения.

Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде 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

В качестве регулярных напоминаний о том где взять открытые данные:

Списки на Github
- awesome-public-dataset один из крупнейших списков общедоступных данных
- awesome-citygml - список доступных 3D моделей городов, много, по разным странам
- awesome-gis в основном открытый код для ГИС, но и раздел с геоданными
- awesome-opendata-rus довольно давно ещё собранный нами в Инфокультуре и пополняемый контрибьюторами список данных по РФ
- awesome-italian-public-dataset список открытых данных в Италии
- awesome-syntetic-data список инструментов по генерации синтетических данных

Каталоги каталогов данных
- Dateno Registry реестр каталогов данных который мы ведём в Dateno
- datacatalogs.org каталог порталов открытых данных от Open Knowledge Foundation
- datacatalogs.ru каталог порталов открытых данных в РФ и постсоветском пространстве от Инфокультуры

Поисковики по данным
- Dateno.io поисковик по более чем 15 миллионов наборов данных, со множеством фасетов и источников
- Google Dataset Search поисковик по датасетам от Google. На сегодняшний день крупнейший в мире
- BASE (Bielefeld Academic Search Engine) один из крупнейших поисковиков по научным данным
- OpenAIRE Explore европейский поисковик и агрегатор по научным данным ЕС и не только.
- Findata.cn китайский поисковик по научным данным Китая и данным связанным с Китаем от Китайской Академии Наук
- SciDb.cn китайский агрегатор научных данных, аналог OpenAIRE
- GeoSeer единственный известный мне поисковик по геоданным (кроме Dateno, конечно)

Крупные [над]национальные порталы открытых данных
- Data.europa.eu портал открытых данных Евросоюза
- Data.gov портал открытых данных США
- Data.gov.uk портал открытых данных Великобритании

Данные для ИИ и обучения нейросетей
- Kaggle крупнейший каталог данных для ИИ, поддерживается Google
- Hugging Face большое сообщество дата сайентистов и каталог данных

#opendata #datasets #data

Кстати, я совсем упустил, а ещё месяц назад с организаторы конференции Smart Data выложили видео моего прошлогоднего доклада Common Data Index. Строим аналог Google Dataset Search, но проще и быстрее [1] про пред-проект Dateno. По сути Common Data Index был идеей собрать все каталоги данных, а Dateno сейчас это уже полноценный поисковый индекс.

Ссылки:
[1] https://www.youtube.com/watch?v=IWLNlHTo9M0

#opendata #data #datasets #datacatalogs

В рубрике как это устроено у них, подборка общедоступных каталогов данных Республики Беларусь:

Статистика
- http://dataportal.belstat.gov.by Портал статистических данных Белстата. Экспорт данных в XML, SDMX, XLS. Есть недокументированное API

Геоданные
- https://meta.geo.by/geoserver сервер геоданных на базе GeoServer. По умолчанию требует авторизации, но прямые ссылки на OGC API доступны
- https://gisoopt.by/arcgis/rest/services - ArcGIS сервер национального парка Нарочанский
- https://oopt.gis.by/arcgis/rest/services/ - ArcGIS сервер Национальной академии геоинформационных систем
- https://gis.maps.by/arcgis/rest/services/ - ArcGIS сервер Госкартгеоцентра
- https://vitebsk.gismap.by/arcgis/rest/services - ArcGIS сервер с геоданными Витебска

Государственного портала открытых данных в РБ никогда не существовало.
Общественный портал opendata.by закрылся несколько лет назад.

#opendata #datacatalogs #belarus #data

Полезные ссылки про данные, технологии и не только:
- FOR-species20K dataset [1] датасет результатов лазерного сканирования более 20 тысяч деревьев и идентификация их видов на основе этих данных
- DuckDB Tricks – Part 1 [2] полезные трюки по работе с данными с помощью DuckDB.
- ncWMS Guide [3] руководство по серверу WMS ncWMS, активно используется вместе с серверами Thredds в метеорологии. Начал их активно добавлять в реестр каталогов данных, скоро проиндексируются в Dateno
- Mapbender 4.0 [4] вышла 4-я версия Mapbender, популярного open source геопортала используемого в ЕС во многих странах.
- SuperMap [5] популярный в Китае геосервер, альтернатива ArcGIS. Используется во многих китайских госорганах, компаниях и активно распространяется в южной, восточной и юго-восточной азии. Имеет частичную совместимость с ArcGIS
- Mealie [6] сервер для ведения рецептов, открытый код и импорт из разных источников. Локализован на многие языки включая русский.
- Slackdump [7] архиватор публичных и личных сообщений из Slack'а. Не требует админских привилегий, открытый код.

Ссылки:
[1] https://zenodo.org/records/13255198
[2] https://duckdb.org/2024/08/19/duckdb-tricks-part-1
[3] https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/
[4] https://mapbender.org/aktuelles/details/mapbender-version-400-released/
[5] https://www.supermap.com/en-us/
[6] https://github.com/mealie-recipes/mealie
[7] https://github.com/rusq/slackdump

#opensource #data #datatools #geodata #geoportals #tools #datasets

К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.

В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.

Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.

Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.

Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.

При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.

Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.

Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.

Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.

Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.

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

#data #thoughts #tech #duckdb #dataengineering