Итак, уже давно пора анонсировать. В этом году мы открываем новый проект, для разнообразия, коммерческий посвященный API и доступу к данным.
Он называется APICrafter и открыт на сайте https://apicrafter.ru
Идея проекта в том что кроме общественных потребителей открытых данных есть немало бизнеса которому нужны открытые и не только, но данные с удобным доступом и с регулярным обновлением.
Мы анонсируем api к данным по госзакупкам, госконтрактам, госфинансам, организациям, банкам и многому другому что мы насобирали за эти годы. А также к тем коммерческим источникам данных к которым получаем доступ сейчас.
Акцент проекта в том что:
- мы не просто предоставляем данные, а также объясняем как с ними работать;
- мы не только продаем интерфейс для доступа к данным, но и сотрудничаем с теми кто планирует сделать коммерческий доступ к своим данным
- мы помогаем делать собственные API и разрабатываем API на заказ
- плюс делаем выгрузки данных по запросу, для тех клиентов кому нужны данные в каком-то специальном формате.
- мы вычищаем и обрабатываем первоисточники в тех случаях когда это необходимо
- мы адаптируем наши API под клиентов у которых в этом возникает потребность.
Сейчас организован доступ к пакету API по госзакупкам и госконтрактам. До конца года мы будем открывать остальные пакеты API к другим данным. В том числе пока не анонсированным.
Оплата возможна по безналу, в ближайшем будущем мы добавим биллинг, личный кабинет и возможность оплаты банковскими картами и другими видами онлайн оплаты.
Для тех кто использует данные в научных или некоммерческих целях - всегда можно договориться о скидке или использовании в обмен на цитирование.
Все наши некоммерческие проекты при этом сохраняются. В тех случаях когда мы можем собрать данные и сделать API за чей-то еще счет - мы всегда и с удовольствием сделаем это в формате некоммерческого проекта. Такие проекты как Госзатраты - https://clearspending.ru и Открытая полиция - https://openpolice.ru и многие другие сохранят всю ту открытость которая была в них заложена.
В то же время бизнес клиентов все больше в последние годы, у них другие требования, тут мы не можем действовать по принципу "as is". И коммерческий проект - это возможность поддерживать нашу некоммерческую деятельность тоже>
Если у Вас будут какие-либо предложения, пожелания, готовность выступить клиентом, продавцом данных или партнером - пишите мне или на [email protected]
#apicrafter #api
Он называется APICrafter и открыт на сайте https://apicrafter.ru
Идея проекта в том что кроме общественных потребителей открытых данных есть немало бизнеса которому нужны открытые и не только, но данные с удобным доступом и с регулярным обновлением.
Мы анонсируем api к данным по госзакупкам, госконтрактам, госфинансам, организациям, банкам и многому другому что мы насобирали за эти годы. А также к тем коммерческим источникам данных к которым получаем доступ сейчас.
Акцент проекта в том что:
- мы не просто предоставляем данные, а также объясняем как с ними работать;
- мы не только продаем интерфейс для доступа к данным, но и сотрудничаем с теми кто планирует сделать коммерческий доступ к своим данным
- мы помогаем делать собственные API и разрабатываем API на заказ
- плюс делаем выгрузки данных по запросу, для тех клиентов кому нужны данные в каком-то специальном формате.
- мы вычищаем и обрабатываем первоисточники в тех случаях когда это необходимо
- мы адаптируем наши API под клиентов у которых в этом возникает потребность.
Сейчас организован доступ к пакету API по госзакупкам и госконтрактам. До конца года мы будем открывать остальные пакеты API к другим данным. В том числе пока не анонсированным.
Оплата возможна по безналу, в ближайшем будущем мы добавим биллинг, личный кабинет и возможность оплаты банковскими картами и другими видами онлайн оплаты.
Для тех кто использует данные в научных или некоммерческих целях - всегда можно договориться о скидке или использовании в обмен на цитирование.
Все наши некоммерческие проекты при этом сохраняются. В тех случаях когда мы можем собрать данные и сделать API за чей-то еще счет - мы всегда и с удовольствием сделаем это в формате некоммерческого проекта. Такие проекты как Госзатраты - https://clearspending.ru и Открытая полиция - https://openpolice.ru и многие другие сохранят всю ту открытость которая была в них заложена.
В то же время бизнес клиентов все больше в последние годы, у них другие требования, тут мы не можем действовать по принципу "as is". И коммерческий проект - это возможность поддерживать нашу некоммерческую деятельность тоже>
Если у Вас будут какие-либо предложения, пожелания, готовность выступить клиентом, продавцом данных или партнером - пишите мне или на [email protected]
#apicrafter #api
ГосЗатраты
ГосЗатраты - Общественный мониторинг госзакупок в Рф
Автоматизированный мониторинг и аналитика по заключенным госконтрактам – инструменты для общественного анализа, выявления злоупотреблений, борьбы с коррупцией и неэффективным расходованием государственных средств.
Forwarded from APICrafter
Обновления в каталоге APICrafter
Что нового
1. Данные о пакетах данных теперь публикуются более компактно. Страница пакета данных теперь включает сведения о характеристиках, таблицах и сборках данных вместе. Например [1] [2]
2. Таблицы открытых наборов данных теперь можно скачать в форматах JSONl, CSV и Parquet. Ссылки на данные публикуются на странице таблицы, например, "Точки обмена" [3]
Экспорт данных сейчас работает со следующими ограничениями:
- экспорт только для наборов данных менее чем с 100 тысячами записей
- форматы csv и parquet доступны только для таблиц без вложенных объектов
- сборки данных включают все данные и доступны всегда
Формат Parquet [4] популярен в data science и активно используется с помощью Jupyter Notebook.
Мы обязательно опубликуем примеры его использования.
Ссылки:
[1] https://tinyurl.com/2s3vuxaf
[2] https://tinyurl.com/2p89vp2k
[3] https://tinyurl.com/yckma22e
[4] https://tinyurl.com/mr4xjdmd
#apicrafter #datascience #datasets #parquet #json #csv
Что нового
1. Данные о пакетах данных теперь публикуются более компактно. Страница пакета данных теперь включает сведения о характеристиках, таблицах и сборках данных вместе. Например [1] [2]
2. Таблицы открытых наборов данных теперь можно скачать в форматах JSONl, CSV и Parquet. Ссылки на данные публикуются на странице таблицы, например, "Точки обмена" [3]
Экспорт данных сейчас работает со следующими ограничениями:
- экспорт только для наборов данных менее чем с 100 тысячами записей
- форматы csv и parquet доступны только для таблиц без вложенных объектов
- сборки данных включают все данные и доступны всегда
Формат Parquet [4] популярен в data science и активно используется с помощью Jupyter Notebook.
Мы обязательно опубликуем примеры его использования.
Ссылки:
[1] https://tinyurl.com/2s3vuxaf
[2] https://tinyurl.com/2p89vp2k
[3] https://tinyurl.com/yckma22e
[4] https://tinyurl.com/mr4xjdmd
#apicrafter #datascience #datasets #parquet #json #csv
В качестве небольшого пред-анонса, где-то через 1-2 недели планируем обновление DataCrafter'а в виде доступного сервиса идентификации типов данных. Сейчас в DataCrafter'е 76399 полей данных из которых 9722 автоматически классифицированы по классам вот [1]. Пока это делалось внутренним движком обрабатывающим данные в таблицах MongoDB и работающем по базе частично закодированных правил. Этот же движок делался для автоматизации анализа качества датасетов.
Этот код сейчас отчуждается и активно тестируется.
А сами правила переносятся из кода в YAML формат. Сейчас это уже 67 правил из которых 40 про то как называются поля, 27 про то что в них содержится и ещё выявление дат делается хоть и 1 правилом, но по 312 шаблонам.
Вначале появится открытый сервис и API по такой классификации для CSV файлов и сейчас я думаю над тем стоит ли переводить его в open source.
Ссылки:
[1] https://data.apicrafter.ru/class
#openservices #datacrafter #apicrafter #data #dataclassification
Этот код сейчас отчуждается и активно тестируется.
А сами правила переносятся из кода в YAML формат. Сейчас это уже 67 правил из которых 40 про то как называются поля, 27 про то что в них содержится и ещё выявление дат делается хоть и 1 правилом, но по 312 шаблонам.
Вначале появится открытый сервис и API по такой классификации для CSV файлов и сейчас я думаю над тем стоит ли переводить его в open source.
Ссылки:
[1] https://data.apicrafter.ru/class
#openservices #datacrafter #apicrafter #data #dataclassification
Масштабное обновление алгоритмов классификации данных в 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
Классификация данных - это процесс при котором определяется природа данных содержащихся в таблицах/файлах/наборах данных. Например, идентификация кодов ИНН/ОГРН/КПП организация, ФИО / Имён / Отчеств / Фамилий физических лиц и ещё многое другое.
При этом обновлении были добавлены новые идентификаторы и правила их распознавания:
- 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
DataCrafter
Российский город
Название российского города в написании на русском языке.
Телеграм бот @DataClassifierBot - это то что я обещал как инструмент автоматической классификации данных DataCrafter'а. В него можно загрузить файлы в формате CSV (разделитель обязательно запятая) или JSON lines (.jsonl) и на выходе будет одно или нескольк сообщений с таблицей структуры полей в файле, их типа и идентифицированного класса данных. Подробнее можно посмотреть на скриншотах. Через телеграм бот будет открытое бета тестирование, прошу делиться обратной связью в чате @apicrafterchat или написав мне. А для тех у кого более серьёзные задачи скоро будет доступно API.
По результатам бета-тестирования хочется понять:
1) Каких функций возможностей нехватает
2) Какие дополнительные классификации нужны/ожидаемы и пока отсутствуют.
3) Насколько точно алгоритмы работают на Ваших данных
Особенности работы бота:
- отключены почти все "неточные" правила
- текущие основные правила под русский язык
- ограничения на файлы 10Mb, 1000 строк, ограничений на число полей нет
#data #apicrafter #datacrafter #datatools
По результатам бета-тестирования хочется понять:
1) Каких функций возможностей нехватает
2) Какие дополнительные классификации нужны/ожидаемы и пока отсутствуют.
3) Насколько точно алгоритмы работают на Ваших данных
Особенности работы бота:
- отключены почти все "неточные" правила
- текущие основные правила под русский язык
- ограничения на файлы 10Mb, 1000 строк, ограничений на число полей нет
#data #apicrafter #datacrafter #datatools
Я ранее писал неоднократно что с момента моего ухода из проектов Счетной палаты РФ я занимаюсь проектом Datacrafter (data.apicrafter.ru) - это крупнейший каталог данных с технологиями идентификации данных, обработки данных, их сбора, построения схем и ещё многое другое. А также проектом APICrafter через который мы предоставляем API к крупным базам данных таким как госконтракты, госзакупки, реестры юридических лиц и многое другое.
Изначально продукт создавался как сервисные API, постепенно мы его перестраивали в платформу для работы с данными.
Конечно, текущий гуманитарный апокалипсис ему также сильно повредил. Проект делался под привлечение инвестиций, а поиск инвестиций в проекты на данных в России теперь сильно усложнены. Но проект продолжается, в этом волноваться не стоит. Возможно он частично перейдет в открытый код.
А пока в ближайшее время мы переносим проект на другой хостинг, поэтому временно не будет работать обновление данных и в какие-то дни он может быть временно недоступен. Как только миграция на новый хостинг завершится, мы вернемся к регулярному обновлению данных и продолжим загрузку новых данных которых тоже много накопилось.
Больше новостей проекта в отдельном телеграм канале @apicrafter
#data #opendata #apicrafter
Изначально продукт создавался как сервисные 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
Основное что важно понимать в интеграции государственных и корпоративных данных - это инертность обратной связи. При работе с корпоративными данными со многими источниками данных можно договориться, особенно если этот источник не супер-мега дата-корпорация, а частный поставщик данных за деньги. А вот случае государства даже если есть обратная связь то какие-либо изменения происходят очень долго, чаще всего проще найти альтернативные способы работы с данными чем их дождаться. Иначе говоря почти любой бизнес бизнес более клиентоориентирован чем госорганы.
Итак, государство через органы власти и разного рода учреждения собирает и кое-где предоставляет данные. Иногда за деньги, часто бесплатно, но во всех случаях это происходит по правилам которые задают сами госорганы, а не их потребители данных. Раскрываемые данные можно разделить на несколько категорий, по способу их предоставления:
- слепки данных/наборы данных ("батчи") - наборы данных выложенные большими кусками, например, 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
Singer
Singer | Open Source ETL
Simple, Composable, Open Source ETL
Для тех кто интересуется анализом и обработкой данных, большое обновление реестра семантических типов данных который я создавал когда-то для инструментов определения типов данных. Реестр называется 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
Обновления:
- 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
GitHub
GitHub - apicrafter/metacrafter-registry: Registry of metadata identifier entities like UUID, GUID, person fullname, address and…
Registry of metadata identifier entities like UUID, GUID, person fullname, address and so on. Linked with other sources - apicrafter/metacrafter-registry
Новости по разрабатываемым продуктам:
- общая стратегия в перенос в открытый код корневых/ключевых компонентов и ведение их в режиме открытой разработки. Коммерческие продукты будут вынесены в облака, то есть модель 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
- общая стратегия в перенос в открытый код корневых/ключевых компонентов и ведение их в режиме открытой разработки. Коммерческие продукты будут вынесены в облака, то есть модель 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
Обновился реестр семантических типов данных 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
GitHub
metacrafter-registry/metacrafter.yaml at main · apicrafter/metacrafter-registry
Registry of metadata identifier entities like UUID, GUID, person fullname, address and so on. Linked with other sources - metacrafter-registry/metacrafter.yaml at main · apicrafter/metacrafter-regi...
Я выложил в открытый код очередной компонент нашей платформы по публикации данных 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
Его особенности:
- автоматическое обнаружение таблиц и генерация схем данных для MongoDB
- все настройки через файлы YAML
- управление API в проектном режиме, для каждого проекта создаётся отдельный проект.
Основной сценарий использования - это когда Вы не хотите детально моделировать данные которые у Вас есть в наличии, но Вам необходимо кому-то их предоставить или использовать для интеграции систем. Тогда данные закидываются в MongoDB как есть и с помощью этой утилиты создаётся API.
Скажу сразу сейчас это упрощённая утилита, не отрабатывающая сложных сценариев, без уникальных урлов каждого объекта и тд., необходимая именно для того чтобы быстро выставить наружу API к какой-либо базе данных
Всё это отдельные внутренние части каталога данных DataCrafter (datacrafter.ru). Изначально она была сделана по монолитному режиму и в последний год я её разбирал и выкладывал по компонентам:
- metacrafter - идентификация семантических типов данных
- datacrafter - ETL для работы с большими батчами (как правило в открытых данных)
- apicrafter - фреймворк для создания API поверх MongoDB
Следующая версия каталога уже будет иметь какое-то другое название и собираться из этих компонентов почти по новой.
#opendata #data #opensource #datatools #apicrafter #datacrafter
GitHub
GitHub - apicrafter/apicrafter: REST API wrapper for MongoDB databases
REST API wrapper for MongoDB databases. Contribute to apicrafter/apicrafter development by creating an account on GitHub.
Как обещал, я буду стараться чаще писать про технологические инструменты которые делаются в рамках проекта 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
Инструмент уже, в принципе, в состоянии когда его надо переводить в промышленное использование, но, всегда хочется докрутить ещё чуть-чуть.
Так вот, здесь про пользу государственных порталов открытых данных вроде российского 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
Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами 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
По сути библиотека позволяет одинаковым образом читать любые табличные и не-табличные данные и возвращать их в виде словарей для 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