Сугубо техническое и инструментальное. Я на днях обновил исходный код утилиты metacrafter [1] и библиотеки для Python iterabledata [2].

Metacrafter - это утилита и библиотека для Python по выявлению семантических типов данных и далее автодокументирования датасетов. Она изначально поддерживала MongoDB, базовые типы файлов вроде csv, xml, jsonl и тд, а также большую часть SQL баз данных (через SQLAlchemy). Не хватало только поддержки файлов которые могут быть разнообразно сжаты. Эту задачу получилось решить переключившись на библиотеку iterabledata которая поддерживает работу с файлами вроде .csv.bz2, .xml.xz, .jsonl.gz и так далее. Собственно к уже имеющимся алгоритмам сжатия и форматам я добавил ещё Zstandard и Brotli. Из популярных форматов не поддерживаются пока только Snappy и 7z . Но у Snappy неудобная реализация на Python, надо её переписывать, а библиотека для 7z не поддерживает режим открытия файла в контейнере, без обязательного раз сжатия .

Но в остальном оказалось очень удобно . Осталось часть других инструментов переписать с этой библиотекой для простоты обработки условно любых входящих дата файлов с условно любым типом сжатия/контейнеров.

А поддержку сжатых файлов в metacrafter пришлось добавлять не просто так, а потому что хранение бесконечного числа CSV'шек и других первичных файлов в Dateno сжирает очень много места, а обрабатывать их надо. И обрабатывать достаточно быстро и с достаточно небольшими ресурсами памяти, процессора и тд.

Один из способов такой экономии это обновление инструментария для поддержки сжатых файлов на всех этапах. Причём не только на этапе обработки данных, но и на этапе извлечения и загрузки. Импорт в СУБД тоже нужен не в чистых .csv или .json, файлах, а в том числе, сжатыми тоже.

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/pyiterable

#opensource #datatools #data #metacrafter #dateno

Где то полтора года назад я писал про то как устроен поиск по данным у Гугла и про ограничения использования разметки из Schema.org. Для тех кто пропустил ту публикацию, расскажу: Schema.org - это стандарт структурированной разметки веб страниц помогающий поисковикам извлекать из веб страниц структурированные разметку о продуктах, статьях, людях , фильмах, книгах и других понятиях. Включая такое понятие как набор данных (Dataset). Саму разметку делают веб-мастера или они встроены в код веб сайта, а поисковая система находит веб страницы и умело их обрабатывает.

Изначально готовили этот стандарт Google, Microsoft и Yandex. Сейчас главный её потребитель это Гугл. Данные этой разметки индексируют, также, другие краулеры и её извлекают из индекса Common Crawl. Я как раз недавно об этом писал.

И всё бы ничего, если бы не один немаловажный факт который прост и неизбежен. Проблема в том что все врут!
Уж не знаю как разметка помогает при SEO оптимизации, но реально всё устроено так что большая часть датасетов не имеет такой структурированной разметки и в том что большая часть того что так размечено, в реальности датасетами не являются. Это какие-то другие концепты/понятия, к данным не относящиеся.

В таблице выборка сайтов в которых есть разметка Dataset. И вот разве они есть на сайтах вроде kakprosto.ru или cbonds.ru ? Совсем нет. Там статьи и другие материалы. И так не только по российским доменам, но и по многим другим.

Из 1.4 миллионов размеченных Datasets в Common Crawl, реально ситуация такова что около 33% мусор, около 33% коммерческие датасеты и оставшиеся 33% данные которые можно скачать. И ещё надо проверять качество их метаданных.

Конечно, реально датасетов больше чем в индексе Common Crawl и индексация веба даст больший охват. Но даже индексация данных по стандартам API CKAN или DCAT работает быстрее и качество метаданных лучше.

#opendata #dateno #data #datasetsx

У меня есть регулярные аналитические задачи которые я решаю и которым сложно обучать других, не потому что нет людей способных к ним, а потому что они нетиповые и требуют опыта довольно длительного в разных областях. Это задачи по data discovery, обнаружению данных и систематизации источников. В каком-то смысле Dateno как поисковик, а до того каталоги каталогов данных появились как отражение этих задач. Потому что данные регулярно необходимо искать, находить, систематизировать и описывать.

Так вот в этих задачах ключевым является то что при всём развитии каталогизации данных за последние пару десятилетий слишком часто приходится сводить информацию из сотен полуструктурированных или неструктурированных источников и в таких задачах Dateno (пока что) мало помогает.

Вот примеры вопросов, выдуманные конечно, но близкие, таких задач.
1. Энергопотребление по странам Ближнего Востока
2. Индикаторы экономического роста и ёмкости рынка по странам Южной Африки
3. Реальная ценовая инфляция в Юго-Восточной Азии

И такого довольно много. В том числе по России, и пост-советским странам.

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

Следующий шаг - это data sources (источники данных) которые практически всегда зависят от списка дата стейкхолдеров и которые могут варьироваться от специальных порталов, до веб сайтов и отчетов международных организаций.

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

Всё это не творчество, а весьма структурированный процесс, результат которого, по сути, идёт в основу ТЗ на дата продукт.

Для открытых данных когда-то делали очень упрощённую модель инвентаризации данных через карты данных. Для корпоративных систем управления данных всё слегка проще по смыслу и сложнее технически, и зачастую упирается в отсутствие адекватной документации и то что внедряющие каталоги данных компании не понимают всей трудоёмкости их наполнения.

Что я могу сказать точно так то что для всех областей data discovery инструментов нехватает. Dateno закрывает некоторые поисковые задачи, но не аналитические. GPT подобные инструменты не помогают в решении поиска данных когда данных нет. Но, возможно, инструменты подспорья аналитика могут быть куда как более структурированными и решать если не типовые задачи, то реализовывать типовые подсказки для их решения.

#thoughts #dateno

В качестве лирического отступления. Если бы я был писателем пишущим по методу Хэмингуэя, без исправления текста, то сказал бы что "аллилуйя", пришёл настоящий вызов. Но я не такой писатель, и художественное творчество моё куда как скромно, но вот работа с нефункционирующей кнопкой бэкспейса на клавиатуре и ещё рядом других кнопок накладывает свои ограничения, как минимум на скорость печати. К сожалению замена клавиатуры будет только через несколько дней, так что это писать также часто как раньше пока не выходит.

Но даже так я слегка пробежался по старому коду движка metacrafter'а [1], инструмента для идентификации семантических типов данных, или более простым языком, инструмент идентификации того что за колонка в наборе данных или в базе данных и что с ней можно делать. Инструмент я потихоньку начал приводить в целевое состояние - усиление поисковых возможностей у Dateno и автодокументирование датасетов.

Что нового:
- правила для metacrafter'а перенесены теперь в новый репозиторий metacrafter-rules [2], их стало больше, в основном за счёт правил для других языков отличных от английского и русского;
- обновился серверный и клиентский режимы работы. Теперь можно ускорить сканирование данных запустив metacrafter как сервер и обращаясь к нему через параметр remote при вызовах сканирования файлов или баз данных. Это важно для ускорения процесса поскольку правила инициализируются только один раз
- добавилась команда просмотра правил 'metacrafter rules list'
- и так далее

Главный недостаток сейчас - это скорость работы на больших датасетах. Чем больше колонок тем дольше анализ, до нескольких минут. Это не так критично для задач вроде сканирования корпоративных СУБД, но тяжко для задач Dateno когда миллионы датасетов.

На самом деле чтобы всё ускорить нужно просто много ресурсов: процессорных, хранения и памяти. А прикрутив LLM'ку можно сильно повысить качество автодокументирования данных.

Понимание данных, автодокументирование датасетов, автоматизация анализа данных - это одни из наиболее любимых мной тем в дата инженерии и дата анализе. Жаль удаётся уделять немного времени.

Ссылки:
[1] https://github.com/apicrafter/metacrafter/
[2] https://github.com/apicrafter/metacrafter-rules/

#opensource #data #datatools #dateno #metacrafter

Я уже рассказывал про геоклассификацию данных в Dateno и то что существенная фича в поиске - это возможность поиска по городам/регионам, на субрегиональном уровне. Классификация датасетов по субрегионам основана почти полностью на аннотировании каталогов данных и с этой точки зрения это довольно простая задача с понятным решением.

Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.

Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.

Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.

Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.

Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.

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

Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.

Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.

#dateno #statistics #indicators #geodata #geo #thoughts

Пополнение в каталоге каталогов данных Dateno, +40 репозиториев научных данных на базе Weko3 [1], все они относятся к Японии и в совокупности содержат около 50 тысяч наборов данных. Не очень много по глобальным меркам, но хорошо индексируется и имеет стандартизированное API. Прежде чем данные таких каталогов индексируются в Dateno, они описываются и размещаются в реестре, идентифицируются их точки подключения к API и тд.

Ссылки:
[1] https://dateno.io/registry/country/JP

#opendata #dateno #datacatalogs

Почему некоторых особенно крупных порталов с данными нет в Dateno? Например, европейский портал data.europe.eu [1] кажется очень большим. Там более чем 1.8 миллиона датасетов со всех стран входящих в Европейский союз, там есть API через которое их можно выкачать и выглядит как "надо брать", проиндексировать его и сразу индекс сильно расшириться.

Всё так, за несколькими но, и очень существенными.

Проблема прослеживаемости
Data.europe.eu - это агрегатор, причём агрегатор агрегаторов. Потому что во многих европейских странах данные публикуются на городских/районных порталах, собираются на национальных и далее в индексируются в общеевропейский. В результате прослеживаемость до первоисточника и часть метаданных теряются.

Вот наглядный пример. Набор данных Miljöfarliga verksamheter (Экологически опасные виды работ) на портале данных шведского города Malmo [2] попадает на шведский национальный портал dataportal.se [2] и оттуда аггрегируется в общеевропейский [3]. В оригинальном источнике у всех ресурсов указана лицензия cc0-1.0, а в национальном и общеевропейском лицензия не указана. Также как и нет цепочки прослеживаемости до первоисточника.

Проблема полноты
На европейском портале сейчас агрегируются данные с национальных порталов открытых данных и из геокаталогов по программе INSPIRE. Для агрегации используются стандарты DCAT-AP, расширение INSPIRE для геокаталогов, в основном, на базе Geonetwork и стандарт SPARQL и расширение API для CKAN. Городские, региональные, муниципальные, научные и иные каталоги данных не поддерживающие эти стандарты туда не попадают.
В этом есть некое характерное отличие европейского портала открытых данных от, к примеру, порталу открытых данных США где более 80% всех данных - это научные данные и геоданные. В Европейском портале научных данных нет совсем, а геоданные составляют от 60% до 70% всех данных. В Евросоюзе научные данные собираются на портале OpenAIRE и в data.europe.eu не попадают. Практически все источники данных которые в data.europe.eu собираются есть и в Dateno.

Проблема качества
В европейском портале данных только около 150-180 тысяч наборов данных имеют разметку по типу используемой лицензии. Это очень, я бы даже сказал, совсем мало, максимум 10% от общего числа данных, при том что зная природу порталов открытых данных откуда агрегируются данных можно было бы идентифицировать лицензии гораздо эффективнее. Внутри Dateno сейчас идентифицируются 40 лицензий и условий использования по более чем 800 правилам
—
В целом картина складывается так что в каком-то смысле европейский портал можно рассматривать как конкурент для Dateno, а не как источник данных. Единственные значимые там характеристики - это оценка качества метаданных по их методологии и отметки что наборы данных относятся к особо ценным. Но первое можно оценивать самостоятельно, а второе содержится в метаданных первоисточников.

Важная характеристика европейского портала в попытках получить хороший поисковик выставляя высокие требования к первоисточникам которые должны соблюсти определённые стандарты.

В отличие от него в Dateno агрегируется всё что хоть как-то напоминает каталоги данных и чьи метаданные можно стандартизировать под описание схожее с DCAT, как бы оно не было в оригинале.

Ссылки:
[1] https://data.europa.eu
[2] https://ckan-malmo.dataplatform.se/dataset/miljofarliga-verksamheter
[3] https://www.dataportal.se/datasets/290_5852/miljofarliga-verksamheter
[4] https://data.europa.eu/data/datasets/https-ckan-malmo-dataplatform-se-dataset-5249aa0b-6528-43ef-880f-172adac8515b?locale=en
[5] https://github.com/commondataio/cdi-licensemapper

#opendata #data #datasets #dateno #europe

В качестве примера живых данных чтобы проверит Duckdb, попробовал его на одном из слепков индекса Dateno.

Вот в цифрах и фактах:
- оригинальный формат JSONL, слепок данных без файлов ресурсов/ссылок, только карточки источников и наборов данных
- всего записей в базе 16 133 670
- размер parquet файла после преобразования 1.9GB
- размер базы duckdb 15GB
- простые запросы group by отрабатываются менее чем за 1 секунду

Сложности
- Есть проблемы с запросами которые необходимы для поиска записей в которых данные отсутствуют, например, где не заполнены какие-либо поля которые являются struct'ами. К пример, если мне нужно найти все записи у которых не указаны темы или привязка к стране. В MongoDB такие запросы делают гораздо проще, даже со сложными схемами когда есть вложенные массивы внутри вложенных словарей внутри вложенных массивов.
—
Но, особенность данных в том что за исключением задач дедубликации данных, можно разрезать базу на тысячи parquet файлов или баз duckdb под каждый источник данных. Поэтому метрики качества можно замерять не по единой базе, а по источникам данных и формировать в единую базу обрабатывая каждый источник отдельно и параллельно.

Например, одна из задач в документировании источников данных, привязывании их к стране, темам и к типу владельца данных. Это перевод источников из временных в постоянные. Как определять приоритеты? По числу проиндексированных датасетов, чтобы расширить метаданные хотя бы источников данных с 1000+ наборами данных.

#data #datatools #duckdb #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

Почему я в последнее время много думаю и пишу про геоданные?
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.

Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.

Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.

При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.

Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.

А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.

Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.

#opendata #data #dateno #thoughts #geodata

Open data in Scotland: a blueprint for unlocking innovation, collaboration and impact [1] ещё один любопытный документ про открытые данные в Шотландии.

Видимо чтобы подтолкнуть правительство Шотландии создать портал открытых данных региона. При этом надо сказать что в реестре Dateno [2] Шотландии есть 29 каталогов данных и в самом Dateno проиндексировано 7500+ датасетов из Шотландии. Скорее всего данных там реально больше.

Надо, кстати, как-нибудь доработать реестр и отображать каталоги данных на субрегиональном уровне, добавить мониторинг доступности, перевести ведение реестра из формата сборки в формат СУБД.

Но это скорее задачи для бэклога.

Сейчас чтобы работать с реестром каталогов данных Dateno можно просто скачать файл full.jsonl [3] из репозитория и выполнить команду

select uid, catalog_type, software.id, link from (select *, unnest(owner.location.subregion) from 'full.jsonl') where id_1 = 'GB-SCT';

Очень и очень просто. А сам реестр постоянно пополняется.

Ссылки:
[1] https://www.gov.scot/publications/open-data-scotland-blueprint-unlocking-innovation-collaboration-impact/
[2] https://dateno.io/registry
[3] https://github.com/commondataio/dataportals-registry/tree/main/data/datasets

#opendata #datasets #scotland #dateno

На всякий случай, для тех кто не знает, посты с рассказом про источники данных и Dateno я дублирую на английском в LinkedIn [1] где можно подписаться на эти и другие новости проекта.

Закидывать туда посты, я, и коллеги, будем нечасто, но регулярно и на английском языке и по теме data discovery.

А в этом телеграм канале я пишу:
а) На русском.
б) Часто
в) Про разное

Ссылки:
[1] https://www.linkedin.com/company/datenoproject/posts/?feedView=all

#opendata #dateno

А вот и свежие новости о Dateno. Мы привлекли раунд инвестиций в рамках которого в ближайшее время планируем запустить API, значительно увеличить поисковый индекс и добавить немало новых возможностей которые сейчас в разработке, а это и функции ИИ, и значительная работа по улучшению качества и полноты поиска. А также, что немаловажно, мы добавим в поиск немало данных связанных с web3 и blockchain.

#opendata #dateno #datasearch #investment #ai #blockchain #web30