Как обещал пишу о том как работать с API Dateno, пока на уровне совсем азов, а далее будут примеры на Python и других языках. Может быть даже SDK, телеграм бот и не только.
1. Идём на Dateno.io, нажимаем на Sign In и регистрируемся на сайте my.dateno.io, там же получаем ключ
2. Открывает документацию на API по адресу api.dateno.io и смотрим как устроены запросы
3. Берём командную строку или UI инструмент или Python и делаем запрос к эндпоинту. Например такой запрос: https://api.dateno.io/index/0.1/query?apikey=my_personal_key&q=Nuclear&filters="source.countries.name"="Kazakhstan" где my_personal_key ключ из личного кабинета.
4. Получаем ответом JSON с результатами поиска по ключевому слову "Nuclear" и по стране Казахстан (Kazakhstan). В ответе ссылки на статистику связанную с ядерной энергетикой страны
5. Параметр filters можно передавать много раз и задавать не только страну, но и тип ПО (source.software.name), тип каталога данных source.catalog_type или тип владельца каталога данных "source.owner_type".
6. Фильтры - это фасеты. При запросе они возвращаются в атрибуте facetDistribution. Можно сделать вначале запрос без фасетов, получить найденные значения и далее фильтровать. Если будет запрос от пользователей, то мы опубликуем, в дополнение к API, полные значения фасетов.
7. В результатах поиска есть ссылка на первоисточник, но нет ссылок на ресурсы которые файлы или API. Чтобы из получить надо сделать запрос к точке подключения https://api.dateno.io/search/0.1/entry/{entry_id}?apikey=my_personal_key где entry_id - это идентификатор записи из результатов поиска. Ресурсов может не быть, иногда, может быть только один как в случае на картинке, а может быть много, десятки. Поэтому к ним запросы индивидуально.
API - это уникальная фича Dateno, открытого API нет у Google Dataset Search и большинства поисковиков по данным. Оно есть только у некоторых поисковиков по научным данным/ресурсам, но они сильно меньше по размеру чем индекс Dateno.
Пишите мне если про API будут вопросы, они почти наверняка появятся.
#opendata #api #dateno #datasearch #data
1. Идём на Dateno.io, нажимаем на Sign In и регистрируемся на сайте my.dateno.io, там же получаем ключ
2. Открывает документацию на API по адресу api.dateno.io и смотрим как устроены запросы
3. Берём командную строку или UI инструмент или Python и делаем запрос к эндпоинту. Например такой запрос: https://api.dateno.io/index/0.1/query?apikey=my_personal_key&q=Nuclear&filters="source.countries.name"="Kazakhstan" где my_personal_key ключ из личного кабинета.
4. Получаем ответом JSON с результатами поиска по ключевому слову "Nuclear" и по стране Казахстан (Kazakhstan). В ответе ссылки на статистику связанную с ядерной энергетикой страны
5. Параметр filters можно передавать много раз и задавать не только страну, но и тип ПО (source.software.name), тип каталога данных source.catalog_type или тип владельца каталога данных "source.owner_type".
6. Фильтры - это фасеты. При запросе они возвращаются в атрибуте facetDistribution. Можно сделать вначале запрос без фасетов, получить найденные значения и далее фильтровать. Если будет запрос от пользователей, то мы опубликуем, в дополнение к API, полные значения фасетов.
7. В результатах поиска есть ссылка на первоисточник, но нет ссылок на ресурсы которые файлы или API. Чтобы из получить надо сделать запрос к точке подключения https://api.dateno.io/search/0.1/entry/{entry_id}?apikey=my_personal_key где entry_id - это идентификатор записи из результатов поиска. Ресурсов может не быть, иногда, может быть только один как в случае на картинке, а может быть много, десятки. Поэтому к ним запросы индивидуально.
API - это уникальная фича Dateno, открытого API нет у Google Dataset Search и большинства поисковиков по данным. Оно есть только у некоторых поисковиков по научным данным/ресурсам, но они сильно меньше по размеру чем индекс Dateno.
Пишите мне если про API будут вопросы, они почти наверняка появятся.
#opendata #api #dateno #datasearch #data
Могу сказать что один из самых частых вопросов по Dateno - это как сделать чтобы мои данные были проиндексированы? Вопрос этот одновременно очень простой и сложный.
Модель индексирования данных в Dateno основано на доверии к источникам данных. Вместо того чтобы сканировать весь интернет на наличие датасетов, существует реестр каталогов данных [1] в котором более 10 тысяч каталогов и куча метаданных о них. Чуть более половины этих каталогов данных уже проиндексированы и доля проиндексированных постепенно растёт.
Индексирование датасетов таким образом, на самом деле, сложнее чем попытаться воспроизвести краулер Google Data Search (GDS), потому что для такого краулера можно было бы просто взять индекс Common Crawl и регулярно обновлять метаданные оттуда. Ресурсоёмкая, но интеллектуально простая задача. Если идти таким путём то немедленно всплывают все проблемы с качеством данных, с тем что существенная часть датасетов публикуется только для SEO продвижения и так далее.
Индексирование каталогов же предполагает что кто-то уже провел работу по валидации того что этот датасет не полное фуфло, а что-то осмысленное.
Поэтому как проще всего опубликовать датасеты? Проще всего, либо опубликовать на одном из каталогов данных которые Dateno индексирует. Второй вариант - это развернуть собственный каталог данных и прислать на него ссылку. Но этот каталог должен работать на типовом ПО таком как CKAN [2], DKAN [3], JKAN [4], InvenioRDM [5] и ряде других. Если Вы публикуете не один набор данных, а множество то использование типового портала для их публикации - это хорошая практика. Например, в РФ от Инфокультуры мы создавали Хаб открытых данных [6], а в Армении Data Catalog Armenia [7], оба на базе движка CKAN как наиболее продвинутого для публикации данных.
У публичных каталогов открытых данных, при этом, есть свои ограничения. К примеру, мы закрыли регистрацию пользователей на наших CKAN порталах из-за бесконечного объёма спама. А то есть, если Вы хотите там что-то опубликовать, то надо написать админам чтобы они Вас там зарегистрировали. Спамеры - это неприятная часть нашей жизни и ещё один довод в пользу создания собственных каталогов данных.
Тем не менее у нас в Dateno постоянно крутится идея того что иногда чтобы что-то проиндексировать, надо это что-то собрать в каталог. А Dateno не каталог, а именно поисковик. Например, крипто данные разбросаны по интернету. Возможно стоит создать каталог крипто данных и уже его проиндексировать в Dateno. Он будет указывать на первоисточники, конечно, но будет пополняем. Хорошая ли это идея? Пока непонятно, если бы был подтверждённый исследовательский интерес к теме то можно было бы хоть сразу запилить каталог данных для исследователей по этой теме.
А вот другой пример, многие госорганы в разных странах массово публикуют документы. И, предположим, у нас есть код превращающий таблицы из документов в машиночитаемые файлы. Но вот так просто их не поместить сейчас в Dateno потому что Dateno содержит только ссылки на ресурсы, но не сами файлы. Расширять ли Dateno или делать промежуточный каталог данных ?
Есть немало таких примеров с необходимостью промежуточных каталогов для существенного расширения доступности многих данных. И это уже куда больше чем просто индексация данных, де-факто это создание датасетов. Техника с помощью которой мы можем добавить в поисковый индекс ещё десяток миллионов карточек датасетов без феноменальных усилий.
Возвращаясь к публикации данных, Dateno - это поисковик. Задача его как продукта в повышении находимости данных. Всегда есть большой соблазн отклониться чуть в сторону, расширить границы продукта и добавить больше возможностей за пределами строго определённых фич. Публикация данных одна из таких возможностей, над которой, мы конечно же думаем.
Ссылки:
[1] https://dateno.io/registry
[2] https://ckan.org
[3] https://getdkan.org
[4] https://jkan.io
[5] https://inveniosoftware.org/products/rdm/
[6] https://hubofdata.ru
[7] https://data.opendata.am
#opendata #datasets #data #datasearch #dateno
Модель индексирования данных в Dateno основано на доверии к источникам данных. Вместо того чтобы сканировать весь интернет на наличие датасетов, существует реестр каталогов данных [1] в котором более 10 тысяч каталогов и куча метаданных о них. Чуть более половины этих каталогов данных уже проиндексированы и доля проиндексированных постепенно растёт.
Индексирование датасетов таким образом, на самом деле, сложнее чем попытаться воспроизвести краулер Google Data Search (GDS), потому что для такого краулера можно было бы просто взять индекс Common Crawl и регулярно обновлять метаданные оттуда. Ресурсоёмкая, но интеллектуально простая задача. Если идти таким путём то немедленно всплывают все проблемы с качеством данных, с тем что существенная часть датасетов публикуется только для SEO продвижения и так далее.
Индексирование каталогов же предполагает что кто-то уже провел работу по валидации того что этот датасет не полное фуфло, а что-то осмысленное.
Поэтому как проще всего опубликовать датасеты? Проще всего, либо опубликовать на одном из каталогов данных которые Dateno индексирует. Второй вариант - это развернуть собственный каталог данных и прислать на него ссылку. Но этот каталог должен работать на типовом ПО таком как CKAN [2], DKAN [3], JKAN [4], InvenioRDM [5] и ряде других. Если Вы публикуете не один набор данных, а множество то использование типового портала для их публикации - это хорошая практика. Например, в РФ от Инфокультуры мы создавали Хаб открытых данных [6], а в Армении Data Catalog Armenia [7], оба на базе движка CKAN как наиболее продвинутого для публикации данных.
У публичных каталогов открытых данных, при этом, есть свои ограничения. К примеру, мы закрыли регистрацию пользователей на наших CKAN порталах из-за бесконечного объёма спама. А то есть, если Вы хотите там что-то опубликовать, то надо написать админам чтобы они Вас там зарегистрировали. Спамеры - это неприятная часть нашей жизни и ещё один довод в пользу создания собственных каталогов данных.
Тем не менее у нас в Dateno постоянно крутится идея того что иногда чтобы что-то проиндексировать, надо это что-то собрать в каталог. А Dateno не каталог, а именно поисковик. Например, крипто данные разбросаны по интернету. Возможно стоит создать каталог крипто данных и уже его проиндексировать в Dateno. Он будет указывать на первоисточники, конечно, но будет пополняем. Хорошая ли это идея? Пока непонятно, если бы был подтверждённый исследовательский интерес к теме то можно было бы хоть сразу запилить каталог данных для исследователей по этой теме.
А вот другой пример, многие госорганы в разных странах массово публикуют документы. И, предположим, у нас есть код превращающий таблицы из документов в машиночитаемые файлы. Но вот так просто их не поместить сейчас в Dateno потому что Dateno содержит только ссылки на ресурсы, но не сами файлы. Расширять ли Dateno или делать промежуточный каталог данных ?
Есть немало таких примеров с необходимостью промежуточных каталогов для существенного расширения доступности многих данных. И это уже куда больше чем просто индексация данных, де-факто это создание датасетов. Техника с помощью которой мы можем добавить в поисковый индекс ещё десяток миллионов карточек датасетов без феноменальных усилий.
Возвращаясь к публикации данных, Dateno - это поисковик. Задача его как продукта в повышении находимости данных. Всегда есть большой соблазн отклониться чуть в сторону, расширить границы продукта и добавить больше возможностей за пределами строго определённых фич. Публикация данных одна из таких возможностей, над которой, мы конечно же думаем.
Ссылки:
[1] https://dateno.io/registry
[2] https://ckan.org
[3] https://getdkan.org
[4] https://jkan.io
[5] https://inveniosoftware.org/products/rdm/
[6] https://hubofdata.ru
[7] https://data.opendata.am
#opendata #datasets #data #datasearch #dateno
Написал краткий обзор новых возможностей [1] в Dateno, включая открытую статистику, расширенный поисковый индексы, фасеты и API.
Лонгриды буду и далее разворачивать на Substack на русском языке, а на английском языке на Medium [2]
Ссылки:
[1] https://open.substack.com/pub/begtin/p/dateno?r=7f8e7&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
[2] https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829
#opendata #datasearch #dateno #datadiscovery
Лонгриды буду и далее разворачивать на Substack на русском языке, а на английском языке на Medium [2]
Ссылки:
[1] https://open.substack.com/pub/begtin/p/dateno?r=7f8e7&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
[2] https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829
#opendata #datasearch #dateno #datadiscovery
Ivan’s Begtin Newsletter on digital, open and preserved government
Обновления в Dateno
Статистика, API, новые фасеты и ещё больше данных.
Кстати, в качестве регулярного напоминания, кроме всего прочего какое-то время назад я занимался разработкой утилиты metacrafter, она довольно умело умеет идентифицировать семантические типы данных. При этом в ней нет нейросетей, ИИ, а лишь очень много правил в виде регулярных выражений и их аналога в синтаксисе pyparsing с помощью которых можно быстро сканировать базы данных и файлы для выявления смысловых полей данных.
Чтобы собрать те правила я тогда перелопатил около 10 порталов открытых данных и кучу других собранных датасетов для выявления повторяющихся типов данных. И то типов данных собрал больше чем потом сделал правил, реестр типов, при этом вполне живой.
Так вот одна из интересных особенностей Dateno - это бесконечный источник данных для обучения чего-либо. Например, у меня сейчас для экспериментальных целей уже собрано около 5TB CSV файлов из ресурсов Dateno, а также несколько миллионов мелких CSV файлов из потенциальных каталогов данных, ещё в Dateno не подключённых. А это гигантская база для обучения алгоритмов на выявление типовых паттернов и атрибутов.
Вообще в планах было подключить к Dateno возможность фильтрации по распознанным семантическим типам данных, правда уже сейчас понятно что самым распространённым атрибутом из CSV файлов будет геометрия объекта, атрибут the_geom который есть в каждом экспорте слоя карт из Geoserver.
В любом случае Dateno оказывается совершенно уникальным ресурсом для тех кто хочет поделать себе обучающих подборок данных на разных языках, в разных форматах, из разных стран и заранее обладающим множеством метаданных позволяющих упростить задачи классификации распознавания содержимого.
Я уже общался недавно с группой исследователей которые так вот запрашивали подборки CSV файлов именно на разных языках: английском, испанском, арабском и тд. и желательно из разных источников, чтобы были и примеры с ошибками, с разными разделителями и тд.
Впрочем в Dateno проиндексированы не только CSV файлы, но и многие JSON, NetCDF, Excel, XML, KML, GeoTIFF, GML, DBF и других. Можно собирать уникальные коллекции именно для обучения.
А какие файлы для каких задач для обучения нужны вам?
#opendata #thougths #dateno #algorithms
Чтобы собрать те правила я тогда перелопатил около 10 порталов открытых данных и кучу других собранных датасетов для выявления повторяющихся типов данных. И то типов данных собрал больше чем потом сделал правил, реестр типов, при этом вполне живой.
Так вот одна из интересных особенностей Dateno - это бесконечный источник данных для обучения чего-либо. Например, у меня сейчас для экспериментальных целей уже собрано около 5TB CSV файлов из ресурсов Dateno, а также несколько миллионов мелких CSV файлов из потенциальных каталогов данных, ещё в Dateno не подключённых. А это гигантская база для обучения алгоритмов на выявление типовых паттернов и атрибутов.
Вообще в планах было подключить к Dateno возможность фильтрации по распознанным семантическим типам данных, правда уже сейчас понятно что самым распространённым атрибутом из CSV файлов будет геометрия объекта, атрибут the_geom который есть в каждом экспорте слоя карт из Geoserver.
В любом случае Dateno оказывается совершенно уникальным ресурсом для тех кто хочет поделать себе обучающих подборок данных на разных языках, в разных форматах, из разных стран и заранее обладающим множеством метаданных позволяющих упростить задачи классификации распознавания содержимого.
Я уже общался недавно с группой исследователей которые так вот запрашивали подборки CSV файлов именно на разных языках: английском, испанском, арабском и тд. и желательно из разных источников, чтобы были и примеры с ошибками, с разными разделителями и тд.
Впрочем в Dateno проиндексированы не только CSV файлы, но и многие JSON, NetCDF, Excel, XML, KML, GeoTIFF, GML, DBF и других. Можно собирать уникальные коллекции именно для обучения.
А какие файлы для каких задач для обучения нужны вам?
#opendata #thougths #dateno #algorithms
GitHub
GitHub - apicrafter/metacrafter: Metadata and data identification tool and Python library. Identifies PII, common identifiers,…
Metadata and data identification tool and Python library. Identifies PII, common identifiers, language specific identifiers. Fully customizable and flexible rules - apicrafter/metacrafter
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
Лично я постоянно ищу какие есть поисковики по данным, глобальные и национальные, а недавно обнаружил что оказывается такой поисковик есть у правительства Шотландии find.data.gov.scot и по многим параметрам он напоминает Dateno, что хорошо😜, но тысячу раз меньше поэтому не конкурент😂.
Итак, в Шотландии пр-во достаточно давно планирует осуществить открытие портала открытых данных data.gov.scot, но пока они этого не сделали они пошли по австралийскому пути создания национального поисковика по данным.
Всего на портале на главной странице декларируется что присутствует 17 тысяч датасетов, а на странице поиска только 11 тысяч. Метаданные о них собираются из примерно 60 источников данных (data hosts) через парсеры нескольких видов API.
Что мне нравится, ребята явно идут нашим путём и проанализировали не меньше пары сотен источников данных, систематизировали их API, идентифицировали ПО некоторых каталогов данных о которых я не знал (MetadataWorks, USmart и др.), но при этом про наш каталог Dateno registry явно не знали. Плюс у них в источниках данных многое что каталогами данных назвать нельзя, публикации файлов отдельными ведомствами, но для сбора датасетов на региональном уровне явно полезно..
В итоге поисковик у них получается, на самом деле, не совсем поисковик, поскольку у каждого датасета есть веб страница с метаданными.
Из всего что я видел - это, пока, наибольшее приближение к подходу в Dateno, за исключением, масштаба, конечно.
Если делать внутристрановой поисковик по данным то на их проект стоит обратить внимание. Они явно писали HTML парсеры под разделы статистики на многих сайтах и значительная часть датасетов там - это PDF файлы статистики нескольких инспекций.
В любом случае любопытно, в том числе как референсные оценки числа датасетов в Шотландии. В Dateno их сейчас около 8 тысяч, в этом местном поисковике их около 11 тысяч. Есть куда стремиться 🛠
#opendata #scotland #datasets #data #datasearch #dateno
Итак, в Шотландии пр-во достаточно давно планирует осуществить открытие портала открытых данных data.gov.scot, но пока они этого не сделали они пошли по австралийскому пути создания национального поисковика по данным.
Всего на портале на главной странице декларируется что присутствует 17 тысяч датасетов, а на странице поиска только 11 тысяч. Метаданные о них собираются из примерно 60 источников данных (data hosts) через парсеры нескольких видов API.
Что мне нравится, ребята явно идут нашим путём и проанализировали не меньше пары сотен источников данных, систематизировали их API, идентифицировали ПО некоторых каталогов данных о которых я не знал (MetadataWorks, USmart и др.), но при этом про наш каталог Dateno registry явно не знали. Плюс у них в источниках данных многое что каталогами данных назвать нельзя, публикации файлов отдельными ведомствами, но для сбора датасетов на региональном уровне явно полезно..
В итоге поисковик у них получается, на самом деле, не совсем поисковик, поскольку у каждого датасета есть веб страница с метаданными.
Из всего что я видел - это, пока, наибольшее приближение к подходу в Dateno, за исключением, масштаба, конечно.
Если делать внутристрановой поисковик по данным то на их проект стоит обратить внимание. Они явно писали HTML парсеры под разделы статистики на многих сайтах и значительная часть датасетов там - это PDF файлы статистики нескольких инспекций.
В любом случае любопытно, в том числе как референсные оценки числа датасетов в Шотландии. В Dateno их сейчас около 8 тысяч, в этом местном поисковике их около 11 тысяч. Есть куда стремиться 🛠
#opendata #scotland #datasets #data #datasearch #dateno
К вопросу о дата-инженерии и Dateno, одна из особенностей проекта в том что практически вся работа с данными построена на собственных инструментах с открытым кодом, что имеет кучу преимуществ при старте, и накапливающиеся ограничения в будущем которые уже хочется избежать.
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
Forwarded from Выше квартилей
Dateno: первые опыты
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search выглядит подходящим инструментом, но исследователи, для которых предметом изучения являются сами данные, сталкиваются с ограничениями по автоматизации их получения.
Мы давно обратили внимание на проект Dateno (команда под руководством Ивана Бегтина), о котором упоминали в мартовском дайджесте. На сегодняшний день Dateno содержит информацию о 19 миллионах датасетов, но самое главное - имеет достаточно понятный и удобный API-интерфейс, с которым мы и решили, наконец, попробовать поработать.
Простая инструкция с примером очень хорошо описана в телеграм-канале И. Бегтина: пользователь регистрируется, получает токен, а дальше применение API возможно как напрямую из браузерной строки, так и через консольный инструмент, скрипт Python/R и т.д.
Зарегистрировавшись, мы сразу запросили данные о датасетах, в заголовке которых есть слово "scientometric*". Таких нашлось 92. Всего включено 35 параметров, в том числе данные о самих датасетах (название, ссылка, тематика, описание, формат и др.) и об источниках этих датасетов (название и тип каталога, название и тип его владельца, страна, язык и прочее).
Конкретно по нашей тематике данные размечены не полностью — например, лицензия указана всего для 10 датасетов из 92, тематика — для 16, а макрорегион — для 33. Подавляющее большинство наборов данных (56) принадлежит Европейскому Союзу, а вот в США их всего 17. Самые распространенные форматы .tsv и .txt (по 13). Датасетов в формате .json, к нашему удивлению, всего 2.
В целом, Dateno оказался действительно удобным инструментом, как с точки зрения технической доступности (открытый API есть у немногих репозиториев), так и с точки зрения покрытия данных. Предлагаем поделиться своим опытом использования Dateno в комментариях.
#dateno #датасеты #открытыеданные
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search выглядит подходящим инструментом, но исследователи, для которых предметом изучения являются сами данные, сталкиваются с ограничениями по автоматизации их получения.
Мы давно обратили внимание на проект Dateno (команда под руководством Ивана Бегтина), о котором упоминали в мартовском дайджесте. На сегодняшний день Dateno содержит информацию о 19 миллионах датасетов, но самое главное - имеет достаточно понятный и удобный API-интерфейс, с которым мы и решили, наконец, попробовать поработать.
Простая инструкция с примером очень хорошо описана в телеграм-канале И. Бегтина: пользователь регистрируется, получает токен, а дальше применение API возможно как напрямую из браузерной строки, так и через консольный инструмент, скрипт Python/R и т.д.
Зарегистрировавшись, мы сразу запросили данные о датасетах, в заголовке которых есть слово "scientometric*". Таких нашлось 92. Всего включено 35 параметров, в том числе данные о самих датасетах (название, ссылка, тематика, описание, формат и др.) и об источниках этих датасетов (название и тип каталога, название и тип его владельца, страна, язык и прочее).
Конкретно по нашей тематике данные размечены не полностью — например, лицензия указана всего для 10 датасетов из 92, тематика — для 16, а макрорегион — для 33. Подавляющее большинство наборов данных (56) принадлежит Европейскому Союзу, а вот в США их всего 17. Самые распространенные форматы .tsv и .txt (по 13). Датасетов в формате .json, к нашему удивлению, всего 2.
В целом, Dateno оказался действительно удобным инструментом, как с точки зрения технической доступности (открытый API есть у немногих репозиториев), так и с точки зрения покрытия данных. Предлагаем поделиться своим опытом использования Dateno в комментариях.
#dateno #датасеты #открытыеданные
