Вообще прежде чем запускать DataCrafter [1] я изучил несколько десятков каталогов данных и специального ПО для ведения таких каталогов.

У них у всех примерно 3 ниши:
- научная (репозитории научных данных)
- корпоративная/коммерческая (каталоги для data science)
- государственная (каталоги открытых данных)

Я об этом писал в большом обзоре в январе этого года [2].

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

У хорошего каталога всегда есть как минимум 4 направления развития:
- больше данных
- лучшее описание/документирование/инструментальное обеспечение данных
- улучшенный пользовательский интерфейс
- хорошая интеграция со всем что активно используется

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

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

Пользовательский интерфейс самая понятная и самая сложная штука. Понятная потому что примеров много, сложная потому что разным пользователям нужно разное.

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

Примеры для вдохновения больших публичных каталогов - это QRI [3], Data.world [4], Airtable [5], Dolthub [6] и многие другие

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

Ссылки:
[1] https://beta.apicrafter.ru
[2] https://begtin.substack.com/p/11
[3] https://qri.io
[4] https://data.world
[5] https://airtable.com
[6] https://www.dolthub.com

#data #datacatalogs #datacrafter

Большое обновление в данных DataCrafter'а. В каталог загружены 1514 наборов данных о климате и погоде из Единой государственной системы информации об обстановке в Мировом океане (ЕСИМО). Все данные были преобразованы в унифицированные форматы и доступны в каталоге как открытые данные через API или в виде сборок/слепков данных.

Данные загружены вместе с описанием каждого поля, сведения доступны в разделе "Документация" к каждой таблице. Например, документация к набору данных Оперативные данные о сопутствующих метеонаблюдениях, передаваемых по коду FM-18 X BUOY. Период хранения в БД.

Несмотря на то что многие данные в системе ЕСИМО являются архивными, они могут пригодиться исследователям работающим с данными о мировом океане, климатологам, специалистам по работе с погодными данными и данными экономики моря.

Для нас загрузка такого числа наборов данных оказалась вызовом по причине числа наборов данных, всё таки 1514 наборов из системы ЕСИМО - это почти в 4 раза больше 393 наборов данных которые ранее к нам были загружены и сейчас интерфейс уже недостаточно удобен для работы с таким числом наборов данных, но мы уже работаем над его доработкой.

Второй вызов был в том что данные имеют свою специфику и текущие алгоритмы распознавания типов данных определяют типы данных наборов данных из ЕСИМО достаточно ограниченно. В ближайшее время начнётся работа по классификации этих полей и доработке алгоритмов под эту задачу.

#datasets #esimo #climate #weather #datacrafter #data

Масштабное обновление алгоритмов классификации данных в DataCrafter'е. Теперь из 76500 полей наборов данных классифицированы 19 501 поле, это около 25,5%. Учитывая что многие поля надо отмечать как "неклассифицируемые" потому что они содержат только расчёт численные данные, то 25,5% от всех полей это очень много, можно сказать рекорд!

Классификация данных - это процесс при котором определяется природа данных содержащихся в таблицах/файлах/наборах данных. Например, идентификация кодов ИНН/ОГРН/КПП организация, ФИО / Имён / Отчеств / Фамилий физических лиц и ещё многое другое.

При этом обновлении были добавлены новые идентификаторы и правила их распознавания:
- ruscity - Российский город
- rusdayofweek - День недели на русском языке (понедельник, вторник и т.д.)
- runpa - нормативно-правовые и распорядительные документы. Законы, постановления, распоряжения и приказы
- mimetype - типы MIME, как правило ассоциированные с файлами
- filename - название файла
- rusworkposition - должности. Например: ректор,директор,и.о. директора и т.д.
- timerange - временные промежутки. Например: 10:00-12:00 или 21:10-21:30

и многие другие.

А также многие другие. Сейчас в DataCrafter внесено 90 классов данных [1] для идентификации которых используется 134 правила идентифицирующих данные и 304 правила идентифицирующих дату/время. Дата и время идентифицируются отдельно поскольку ещё в 2017 году я заопенсорсил движок qddate [2] определяющая даты в 348 шаблонах и на 9 языках. Движок, кстати, делался для библиотеки newsworker [3] по извлечению новостей из сайтов не отдающих RSS ленты, на основе шаблонов текстов, в основе которых даты. Эту библиотеку я тогда же заопенсорсил и слегка подзабросил, но она всё ещё вполне работает и актуальна.

Чтобы достичь этого результата внутренний движок классификации данных был полностью переписан. Большая часть правил теперь описывается в конфигурационных настраиваемых файлах YAML. При применении правил они могут фильтроваться по контексту, по языку и по точности. Кроме коллекций в MongoDB теперь поддерживаются файлы CSV и JSONl. Через некоторое время рабочая версия классификатора появится в виде страницы в интернете и телеграм бота (телеграм бот уже тестируется).

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

Ссылки:
[1] https://data.apicrafter.ru/class
[2] https://github.com/ivbeg/qddate
[3] https://github.com/ivbeg/newsworker

#opendata #data #datasets #datacrafter #apicrafter #dataclassification

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

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

Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления:
- слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, XML файлами в несколько гигабайт каждый в которых содержатся все данные в этом наборе данных
- документированные API - редки, содержат описание, как правило не в привычном формате вроде OpenAPI, а в виде PDF/DOC документа с описанием всего текстом по ГОСТу или близко к ГОСТу
- недокументированные API - наиболее распространены, есть почти на любом современном государственном ресурсе. К ним можно подключаться, выгружать данные, но нет никакой гарантии что всё это не слетит при следующем обновлении их системы. Документация отсутствует в принципе.
- API в режиме запрос-ответ - когда доступа к данным в чистом виде нет, но можно запросить сведения по конкретному запросу и получить данные только по нему
- неструктурированные данные - всё то что массово публикуется на сайтах в виде HTML/PDF/DOC и реже Excel файлов. Требует навыков извлечения и распознавания этих данных разными способами. Это не так сложно, но задаёт определенный "порог входа" при доступе к данным.

Более всего неструктурированных данных, далее много данных в виде батчей опубликовано на порталах открытых данных, очень много недокументированных API, значительно меньше документированных.

Всё это отличается от корпоративного сектора и довольно сильно. В корпоративном секторе, там где есть онлайн сервисы и цифровые онлайн продукты акцент идёт на API и доступность данных через API. Какие-то сервисы дают API за деньги (почти все API распознавания образов например), какие-то бесплатно для удержания в своей экосистеме (Github, Яндекс.Метрика и др.).

Поэтому практически все сервисы интеграции корпоративных данных в облаке построены вокруг сбора данных из API и прямого подключения к базам данных. Базы данных, как правило собственные, API, как правило, чужие и к ним пишутся многочисленные коннекторы вроде стандарта Singer [1] и тех что собраны в каталоге коннекторов Meltano [2]. Но в целом, и у других инструментов тот же подход, в приоритете подключение к сервисам предоставляющим API.

Отсюда возникает ситуация когда инструменты вроде Meltano, Airbyte, Singer, Fivetran и др. очень хорошо заточены под выгрузку на регулярной основе, вплоть до реального времени, из API, и почти не умеют и не адаптированы про то о чём я писал выше - работу с батчами, неструктурированными данными и недокументированным API.

Когда я начинал только писать движок в Datacrafter'е про сбор данных - он был как раз про ситуации когда API недокументировано, описания данных нет, файлы лежат батчами или надо из HTML страниц создавать наборы данных.

Ссылки:
[1] https://www.singer.io
[2] https://hub.meltano.com

#data #datatools #opendata #apicrafter #datacrafter

Для тех кто интересуется анализом и обработкой данных, большое обновление реестра семантических типов данных который я создавал когда-то для инструментов определения типов данных. Реестр называется metacrafter registry и его репозиторий доступен на github [1].

Обновления:
- 158 семантических типов данных
- 38 дополнительных шаблона записи данных
- 18 категорий, 6 стран и 6 языков. Поддерживаются некоторые типы данных специфичные для США, Великобритании, Франции и Испании и, конечно, России. Например. идентификаторы организаций.

Все семантические типы описаны теперь как индивидуальные YAML файлы [2], это значительно упрощает их развитие и обновление.

По сути над базой не хватает только веб интерфейса для постоянных ссылок (пермалинков).

Зачем это нужно? Этот реестр развитие утилиты metacrafter [3] написанной как универсальный инструмент определения смысловых полей данных в базах данных, вне зависимости от их названия. Утилита умеет работать с SQL, MongoDB, файлами CSV, JSON, JSON lines и BSON․ Определяет десятки типов полей, а самое главное, она расширяема и можно писать свои правила. В опубликованной версии присутствует пара десятков готовых правил, а в нашей внутренней версии в DataCrafter'е, их несколько сотен. Все они сейчас обновляются для привязки к реестру семантических типов.

Ссылки:
[1] https://github.com/apicrafter/metacrafter-registry
[2] https://github.com/apicrafter/metacrafter-registry/tree/main/data/datatypes
[3] https://github.com/apicrafter/metacrafter

#datatools #opensource #datacrafter #apicrafter

Я выложил в открытый код очередной компонент нашей платформы по публикации данных APICrafter с таким же названием apicrafter это инструмент/утилита/библиотека кода по автоматическому созданию API поверх NoSQL СУБД, сейчас это MongoDB. Внутри используется REST API фреймворк Python Eve, а сам движок предполагает создание только read-only API, для публикации и раскрытия данных.

Его особенности:
- автоматическое обнаружение таблиц и генерация схем данных для MongoDB
- все настройки через файлы YAML
- управление API в проектном режиме, для каждого проекта создаётся отдельный проект.

Основной сценарий использования - это когда Вы не хотите детально моделировать данные которые у Вас есть в наличии, но Вам необходимо кому-то их предоставить или использовать для интеграции систем. Тогда данные закидываются в MongoDB как есть и с помощью этой утилиты создаётся API.

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

Всё это отдельные внутренние части каталога данных DataCrafter (datacrafter.ru). Изначально она была сделана по монолитному режиму и в последний год я её разбирал и выкладывал по компонентам:
- metacrafter - идентификация семантических типов данных
- datacrafter - ETL для работы с большими батчами (как правило в открытых данных)
- apicrafter - фреймворк для создания API поверх MongoDB

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


#opendata #data #opensource #datatools #apicrafter #datacrafter