Я ранее писал неоднократно что с момента моего ухода из проектов Счетной палаты РФ я занимаюсь проектом Datacrafter (data.apicrafter.ru) - это крупнейший каталог данных с технологиями идентификации данных, обработки данных, их сбора, построения схем и ещё многое другое. А также проектом APICrafter через который мы предоставляем API к крупным базам данных таким как госконтракты, госзакупки, реестры юридических лиц и многое другое.

Изначально продукт создавался как сервисные API, постепенно мы его перестраивали в платформу для работы с данными.

Конечно, текущий гуманитарный апокалипсис ему также сильно повредил. Проект делался под привлечение инвестиций, а поиск инвестиций в проекты на данных в России теперь сильно усложнены. Но проект продолжается, в этом волноваться не стоит. Возможно он частично перейдет в открытый код.

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

Больше новостей проекта в отдельном телеграм канале @apicrafter

#data #opendata #apicrafter

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

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

Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления:
- слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, 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

Новости по разрабатываемым продуктам:
- общая стратегия в перенос в открытый код корневых/ключевых компонентов и ведение их в режиме открытой разработки. Коммерческие продукты будут вынесены в облака, то есть модель open source engine + cloud services.
- приоритет будет сдвигаться на технологические сервисы и сервисные API
- через какое-то время появится общий репозиторий с архитектурой продуктов APICrafter'а как единого целого. Это будет включать ряд технологических продуктов и ряд продуктов агрегаторов данных.
- для DataCrafter'а добавлен Getting Started гайд [1], его можно почитать тут, а далее будет сайт документации
- задачи по развитию DataCrafter'а перенесены в issues продукта на Github [2] туда можно добавить предложения, проголосовать и прокомментировать. Пока добавлено основное, что в работе.
- все задачи по datacrafter'у, metacrafter'у и др. продуктам вынесены в проект с общим списком задач [3]

Ссылки:
[1] https://github.com/apicrafter/datacrafter/blob/main/docs/getting-started.md
[2] https://github.com/apicrafter/datacrafter/issues
[3] https://github.com/orgs/apicrafter/projects/1

#opensource #code #apicrafter

Свежий апдейт по проекту metacrafter.

Обновился реестр семантических типов данных metacrafter-registry [1], теперь там появился раздел инструментов [2] со списком, пока, из 9 инструментов и того какие семантические типы данных они поддерживают.

Список неполный потому что есть инструменты вроде Microsoft Presidio [3] которые по факту поддерживают ещё и многие типы данных которые пока в этот реестр не входят, но их систематизация хотя бы начата. Каждый инструмент описывается в виде yaml файла с описанием, например, yaml файл metacrafter'а.

Сейчас metacrafter с базовыми правилами распознает 48 семантических типов данных [4], а как веб сервис поддерживает 118 семантических типов [5].

На самом деле, конечно, если говорить про ширину охвата, то можно упростить распознавание сведя все численные типы к одному семантическому типу. Например, так сделано в Google Data Studio, а можно наоборот усложинить добавив множество градаций и подтипов. Как это сделано в Metabase где есть отдельные типы данных "Creation Date", "Updated Date" и тд.


Ссылки:
[1] https://registry.apicrafter.io/
[2] https://registry.apicrafter.io/tool
[3] https://registry.apicrafter.io/tool/presidio
[4] https://github.com/apicrafter/metacrafter-registry/blob/main/data/tools/detectors/metacrafter.yaml
[5] https://github.com/apicrafter/metacrafter-registry/tree/main/data/tools
[4] https://registry.apicrafter.io/tool/metacrafter
[5] https://registry.apicrafter.io/tool/metacrafterpro

#opensource #datatools #apicrafter #metadata #pii

Я выложил в открытый код очередной компонент нашей платформы по публикации данных 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

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

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

Так вот, здесь про пользу государственных порталов открытых данных вроде российского data.gov.ru, британского data.gov.uk и др. Польза эта в многообразии. Например, по data.gov.ru я обучаю распознавалку семантических типов данных.

Для тех кто интересуется как это работает, в репозитории metacrafter-datacatalogs-raw собраны метаданные с разных порталов и опубликован результат распознавания семантических типов данных по data.gov.ru. Желающие могут скачать нефильтрованный результат распознаваний в файле datagovru_semantictypes.jsonl.xz

В цифрах:
- 18+ тысяч обработанных наборов данных
- 198 660 полей полей структурированных файлах
- 66 921 полей у которых автоматически определен семантический тип (примерно 34%)
- наиболее успешно идентифицируются: уникальные идентификаторы, булевые значения, наименования, ФИО, дата и время, номер телефона, url, год и тд
- самые частые ошибки в полях когда название поля используется как булевое значение, а не как содержащие сущность. Например, если поле называется "passport", а не "hasPassport" и по факту является словарем в значениях "имеется" и "отсутствует"
- распознавание можно улучшить зная контекст, источник данных, дополнительные метаданные и тд., но это какое-то дополнительное направление исследований, скорее научное чем практическое.

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

Но даже для такой задачи есть ключевая проблема - это качество данных. Я не просто так пишу про то что госданные, в целом, это мусор.
Вот лишь несколько характеристик именно низкого качества данных:
- CSV файлы публикуются в разных кодировках и с разными разделителями (это, отчасти, преодолимо)
- CSV файлы очень часто публикуются без заголовков, например, многие данные из ХМАО (это реальная проблема)
- многие расширения файлов не соответствуют содержанию. CSV или ZIP вместо XML, HTML вместо CSV и так далее
- многие ссылки на файлы на других сайтах давно протухли, например, ссылки на сайт fstrf.ru давно ведут на какой-то левый сайт.
- вместо настоящих XML файлов с данными публикуются файлы разметки. Я об этом писал ранее, это вообще напоминает какой-то подлог
- многие CSV файлы это кривой экспорт из Excel с многострочтными заголовками и строками ИТОГО нарушающими разбор файла
- огромное число файлов просто пустые

Делать полную оценку причин и проблем с качеством открытых гос данных долго, я пишу о том насколько они влияют на возможность их автоматизированного анализа. Собственно по причинам выше и из 26+ тысяч наборов данных удалось обработать около 18+ тысяч и среди обработанных есть ошибки связанные с неверными заголовками у CSV файлов.

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

Но всё постепенно меняется и я про качество данных расскажу ещё не раз.

#opendata #datasets #metadata #metacrafter #apicrafter

Я довольно давно не рассказывал про развитие инструментов metacrafter для выявления семантических типов данных и реестра семантических типов данных metacrafter-registry которыми давно занимаюсь.

Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами Schema.org и Wikidata. А есть одно изменение важное именно для инженерии данных - это экспорт реестра в формат бизнес глоссария (Business Glossary) используемого в каталоге данных Datahub.

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

Datahub - это опенсорсный каталог корпоративных данных [1] созданный некогда в LinkedIn и развиваемый сейчас компанией Acryl. Среди его достоинств есть импорт данных, в том числе, для бизнес глоссария.

И вот для тех кто хочет загрузить туда типы данных из Metacrafter'а теперь это можно сделать воспользовавшись файлом metacrafter.yml [2] из репозитория проекта. Выглядит результат примерно как на вот этом скриншоте.

Следующий шаг в интеграции metacrafter'а в непосредственно процесс загрузки метаданных в Datahub, так чтобы привязку поля к данным можно было бы осуществлять автоматически.

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

#opensource #semanticdatatypes #dataengineering #apicrafter #metacrafter

Я всё забыл написать, ещё пару месяцев начал и почти доделал небольшую программную библиотеку для Python для чтения данных из файлов в любых форматах с данными։ csv, json, json lines, xml, parquet, orc, xls, xlsx и в перспективе других. Называется pyiterable [1] и воспроизводит и улучшает код который был в утилите командной строки undatum [2] и в ETL движке datacrafter [3].

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

Аналогично, для ряда форматов, поддерживается не только чтение, но и запись, опять же в виде записей в виде python dict.

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

На картинке изначальная модель библиотеки, сейчас реализовано около 70% возможностей. Ошибки, предложения можно отправлять в issues, исправления в код в pull request

Ссылки։
[1] https://github.com/apicrafter/pyiterable
[2] https://github.com/datacoon/undatum
[3] https://github.com/apicrafter/datacrafter

#datatools #opensource #apicrafter #data