Быть может не каталоги данных, а каталоги метаданных? Свежий проект OpenMetadata [1] нацелен на автоматизацию сбора именно данных-о-данных которые находятся под Вашим управлением в самых разных СУБД - MySQL, PostgreSQL, MSSQL, ElasticSearch и иногие другие. По сути это почти то же самое что корпоративный каталог данных, но без претензий на "швейцарский нож". OpenMetadata начинает со стандартизации и продолжает интеграцией и взаимодействием пользователей.

Плюс - это подход от стандартизации и открытый код
Минус - в пока ещё слабой поддержке NoSQL и других источников данных

Реализуемые идеи очень похожи на те что у нас в движке DataCrafter'а [2], но с акцентом на корпоративные, а не на общедостурные данные.

В любом случае это интересный проект за которым стоит понаблюдать и попробовать.

Ссылки:
[1] https://open-metadata.org
[2] https://beta.apicrafter.ru

#opendata #metadata #data #datacatalogs

В рубрике инструментов работы с данными, об инструментах с открытым кодом для работы над качеством данных.

- OpenRefine - инструмент для ручной/автоматизированной очистки наборов данных. Работает преобразуя их в плоские таблицы, поддерживает Excel/CSV/JSON/JSON lines и другие форматы. Позволяет проводить довольно гибкие преобразования по отдельным колонкам. Основан на продукте Google Refine, когда-то переданным компанией в open source.
- Great Expectations - "Большие ожидания", библиотека для языка Python, одна из наиболее активно используемых для автоматической валидации значений в наборах данных, потоках данных, data pipelines и не только.
- Soda-SQL - инструмент с открытым кодом для создания метрик и тестирования данных в SQL базах данных. Поддерживает несколько SQL баз данных и несколько базовых видов/типов полей. Умеет анализировать данные в СУБД и на основе этого рекомендовать автоматизированные тесты.
- Re-data - инструмент подсчёта метрик и проверки качества данных в SQL базах данных. Включает возможность активного мониторинга данных.
- ODD Platform - Open Data Discovery Platform, включает механизмы проверки качества данных, а сама платформа делается на основе ODD Spec спецификации описания метаданных. Здесь Open Data Discovery - это [Open] [Data Discovery], не открытые данные, а открытое обнаружение данных.
—
Я от себя добавлю что часто инструменты контроля качества данных сильно замедляют работу с данными если они не оптимизированы. К примеру Soda-SQL и Great Expectations, скажем так, имеют большие возможности по их ускорению, потому про по умолчанию заложенные там проверки через регулярные выражения можно сильно оптимизировать. К примеру, решая похожие задачи по классификации данных в DataCrafter'е, могу сказать что там вообще нет регулярных выражений, но и нет жесткой закодированности идентифицирующих типы данных правил. Вместо них некий аналог RegExp'ов работающий многократно быстрее.

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

В частных случаях задача решается. Лично я её решал и решил для сравнений связанных с датами и строками размера до 50 символов довольно грубым способом на 50% состоящим из замены регулярных выражений на их сборный конструктор-аналог и на 50% заменой индекса на код по предпроцессингу входящего потока. Результаты 3 года назад опубликовал в виде библиотеки для Python qddate, там не все наработки, но значительная часть по распознаванию дат в любых форматах. Поэтому можно ли ускорить проверку качества данных и расчёт метрик по миллиардам записей в базах данных? Конечно можно и значительно!

#opendata #metadata #dataquality #datatools #tools

Команда создателей Datahub [1], каталога управления метаданными от LinkedIn, в 2020 году выделились в отдельный стартап Metaphor и вот в ноябре этого года анонсировали Metaphor Platform [2].

По сути это коммерческая SaaS платформа, аналогичная Datahub, используемая для сбора данных о данных (метаданных), но с разделением на 3 типа метаданных:
- технические метаданных - данные из первоисточиков о структуре, качестве, описании таблиц и тд.
- метаданные бизнеса - мэппинг между физическими данными и их производственным рабочим представлением, от сценариев использования
- поведенческие метаданные - привязывание данных к конкретным пользователям и их поведению.

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

В любом случае продукт ещё только в режиме demo, надо будет за ним последить внимательнее.

Ссылки:
[1] https://engineering.linkedin.com/blog/2019/data-hub
[2] https://metaphor.io/blog/metaphor-product-launch

#metadata #datacatalogs

Среди современного стека с данными отдельная тема, о которой я регулярно пишу, это продукты по data discovery, каталоги данных в современном стеке данных. О них было исследование Forrester Wave [1] в середине прошлого года и это такие продукты как Atlan, Alation, Collibra из коммерческих и продукты вроде Amundsen, Datahub и др. из недавно превращённых в открытые продукты с открытым кодом.

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

Полезно посмотреть на два обзора и "каталога каталогов". Один от одного из сотрудников Atlan [2] со списком основных продуктов их конкурентов и кратким описанием каждого.

Другой от CastorDoc [3] с куда более детальным списком и сравнением по областям применения, стоимости и возможностям.

Сейчас это всё довольно сложные платформы, с разными акцентами на управлении метаданными. Лично приглядываюсь к ним потому что многие возможности такой платформы, но в формате открытого каталога, мы реализуем в DataCrafter'е. Например, автоматическая идентификация типов данных есть в Collibra, но пока мало где в других каталогах.

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

Ссылки:
[1] https://t.me/begtin/2978
[2] https://www.notion.so/atlanhq/The-Ultimate-Repository-of-Data-Discovery-Solutions-149b0ea2a2ed401d84f2b71681c5a369
[3] https://notion.castordoc.com/catalog-of-catalogs

#datadiscovery #metadata #metadatamanagement #datacatalogs

В рубрике интересное регулярное чтение:
- Every product will be data product [1] - статья о том что любой корпоративный продукт превращается в data product. Мои предыдущие мысли о том что любой госпродукт - это data product очень похожи [2]. Превращение / восприятие любого цифрового продукта как продукта на данных - это очень логично.
- dbd: new ELT tool that you’ll love [3] - автор пишет про свежесозданный инструмент dbd для задач ETL (Extract Transform Load) с примерами загрузки данных. Не то чтобы ETL инструментов было мало, в том числе с открытым кодом, но может пригодится и этот [4]. Инструмент совсем свежий, написан на Python и, похоже, рабочий.
- (P)TL, a new data engineering architecture [5] - автор пытается описать новую архитектуру работы с данными как Pushing Transform Load, где Pushing заменяет Extract и сводится к тому что "давайте вместо извлечения данных будем получать их в структурированном виде из потоковых источников вроде Kafka". Проблема в том что такой подход работает только в случае управляемых источников данных, причём скорее внутренних или очень зрелых внешних способных отдавать поток данных.
- The Modern Metadata Platform: What, Why, and How? [6] - видение современной платформы метаданных от Metaphor, стартапа, как уже понятно, декларирующего создание именно такой платформы. Интересно, по сути, описанием стратегии на то что платформы управления метаданными - это давно уже не только индексация таблиц, а систематизация баз данных, дашбордов, озёр данных, ETL, A/ML и многое другое. Metaphor делает та же команда что создала Datahub в Lyft [7] так что эти рассуждения достойны внимания.
- AutoDoc — a project to document automatically your data warehouse [8] - о том как один из продуктов каталогизации данных автоматически документирует данные из популярных источников. Они отслеживают когда пользователь подключает данные из одного из популярных источников вроде Salesforce, Facebook Ads, Google Ads, HubSpot и ещё нескольких десятков (всего 61) и автоматически добавляют документацию и метаданные которые заранее собраны и привязаны к полям/таблицам из этих источников. Интересный подход, в DataCrafter'е мы используем другой, кучу правил идентификации типов данных на основе их содержания [9], технологически это сложнее.
- The MAD Landscape 2021 — A Data Quality Perspective [10] - обзор стартапов по автоматическому мониторингу инфраструктуры данных и качества данных, data observability и data quality. Обзор интересный про 3 основных способа контроля качества данных: на основе правил, машинного обучения и статистики.

А в качестве завершения, как сформулировано в последней заметке Data is eating the world по аналогии с известной фразой Марка Андерсена Software is eating the world.

Ссылки:
[1] https://medium.com/kyligence/every-product-will-be-a-data-product-19e648f0333
[2] https://t.me/begtin/3423
[3] https://zsvoboda.medium.com/declarative-database-management-89d79e80d0cb
[4] https://github.com/zsvoboda/dbd
[5] https://adoreme.tech/p-tl-a-new-data-engineering-arhitecture-1dee8b7a84c0
[6] https://metaphor.io/blog/the-modern-metadata-platform
[7] https://engineering.linkedin.com/blog/2019/data-hub
[8] https://medium.com/castor-app/docmaster-a-project-to-auto-document-your-data-warehouse-castor-blog-69005927c4c3
[9] https://data.apicrafter.ru/class
[10] https://medium.com/validio/the-mad-landscape-2021-a-data-quality-perspective-e633f71c3eff

#dataquality #data #reading #dataengineering #metadata #dataproducts

Вышла свежая версия OpenMetadata 0.80 [1] инструмента сбора метаданных о таблицах, дашбордах, трубах данных и тд. Аналог Datahub, Amundsen, но с прицелом на открытый общедоступный стандарт описания данных.

В новой версии:
- политики контроля доступа (access control policy)
- ручное добавление происхождения данных (manual linage)
- уведомления о событиях (event notification)
- контроль качество данных (data profiler) на базе Great Expectations

и ещё много чего.

Главный недостаток, на мой взгляд, в том что OpenMetadata не поддерживает NoSQL базы данных такие как MongoDB или Elasticsearch. Например, Datahub умеет данные о MongoDB собирать.

Об этом я как-нибудь отдельно напишу, о том как существующая среда Modern Data Stack тяжело стыкуется с NoSQL продуктами и что с этим делать.

А пока стоит изучить новые возможности OpenMetadata.

Ссылки:
[1] https://blog.open-metadata.org/openmetadata-0-8-0-release-ca09bd2fbf54

#opensource #datatools #metadata

Metadata Guardian [1] [2] свежая утилита для Python, делающая практически то же что и наш движок по идентификации полей и даже теми же самыми способами, только с акцентом на PII (Personally Identifiable Information). Поставляется в виде утилиты командной строки, поддерживает Snowflake, AWS, GCP, MySQL и файлы Avro, Arrow, ORC и Parquet.

Все правила оформлены прям как и у меня в виде YAML файлов [3] с регулярными выражениями. Правила также разделяются на те которые применяются к названиям колонок и те которые применяются

В общем это хорошая утилита, разница между ней и тем что делаю я тоже есть:
1. Правил нашем классификаторе кратно больше. В metadata guardian их около 20, в нашем боте их уже более 150.
2. В нашем классификаторе правила и идентификаторы разделены. Много разных правил могут указывать на один и тот же идентификатор. Например, отдельное правило для почтовых индексов и их написания на английском языке и общее для всех, такое как "postindex" или "postcode" и отдельно для написания на русском "почтовый_индекс" или "pochtoviy_indeks". Это позволяет разделять правила по контексту языка.
3. Это особенность нашего движка, контекстное и языковое разделение правил. Можно задать фильтр и подгрузить любые правила, а не только преднастроенные.
4. В Metadata Guardian используют регулярные выражения, у нас вместо них три типа правил: прямое сравнение, внешние функции и конечные автоматы на PyParsing через которые также можно запускать регулярные выражения.
5. У нас в движке предусмотрена доп. валидация данных после определения. Для этого можно указать внешнюю функцию.
6. Пока наш движок работает с базовым объектом как словарь для Python (python dict), а в качестве входного потока принимает СУБД MongoDB, JSON lines и CSV. А Metadata Guardian нацелен на базы и форматы для облачного применения и для data science.

Причины отличий в том что MG создан для идентификации PII, а наш Data Classifier для задач более общих и, более того, как основа для оценки качества данных и их обогащений. Напомню что наш движок можно потестить вот тут @DataClassifierBot как телеграм бот и скоро будет API.

Тем не менее на Metadata Guardian стоит посмотреть и попробовать, потому что направление движения правильное. К тому же он хоть и меньше может, но более production ready и стыкуется с СУБД.

Ссылки:
[1] https://medium.com/@florian.valeye/metadata-guardian-protect-your-data-by-searching-its-metadata-fe479c24f1b1
[2] https://github.com/fvaleye/metadata-guardian
[3] https://github.com/fvaleye/metadata-guardian/blob/main/python/metadata_guardian/rules/pii_rules.yaml

#metadata #data #datatools #privacy #opensource

В нашем движке по распознаванию типов данных внутри баз данных, таблиц и файлов теперь 195 правил охватывающих геоданные, данные об организациях, о людях, о медицинских препаратах, финансах, госфинансах, справочниках и классификаторах и так далее. Прежде чем запускать бета-тестирование API, я выложил сам движок как открытый код и он доступен на Github как metacrafter [1].

Главные достоинства по сравнению с аналогичными инструментами:
* легко расширяется новыми правилами, правила описываются в файлах в YAML формате
* быстро работает без дополнительных расширений. Вместо регулярных выражений используются конечные автоматы PyParsing
* обычно такие инструменты работают с колоночными данными, а тут наоборот поддержка любых построчных.
* поддерживает MongoDB, любую СУБД через SQL Alchemy, файлы в форматах CSV, JSON, JSON lines, BSON, Parquet
* прицел именно на распознавание идентфикаторов, а не просто идентификацию PII.

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

Движок можно использовать для применения написанных и написания собственных правил.

Обратите внимение что в среди правил есть правила идентификации персональной информации (PII). Сейчас нет команды поиска только и именно PII, но это несложно добавить.

Плюс в него же встроен веб-сервер для запуска движка распознавания в серверном варианте, с API.

Для того чтобы правила и выявляемые идентификаторы были систематизированы, в отдельном репозитории metacrafter-registry [2] доступны данные по всем идентифицируемым объектам. По списку идентификаторов [3] в нём можно понять, то какие правила существуют и какие данные идентифицируются. Этот реестр будет расширяться, дополняться и пополняться.

Наше коммерческое API использует этот же движок, включает все 195 правил идентификации объектов и скоро будет доступно для бета-тестирования.

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

#metadata #data #opensource

В блоге Datahub, open source продукта каталога корпоративных данных пост про то как составлять бизнес глоссарии [1] в привязке к данным. То что в Datahub называется бизнес глоссарием - это просто другой взгляд на те же semantic types, смысловые категории данных. В Datahub всё решают через самостоятельное составление этого глоссария и через тэгирование данных что тоже вполне себе подход для многих задач.

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

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

Вообще же могу сказать что мне лично в этом всём нехватает большого числа разных данных. Всё основное что можно было собрать по российским порталам открытых данных уже или загружено в DataCrafter [2], или лежит большими слепками вроде слепка данных в data.gov.ru или, ещё, с крупных зарубежных порталов данных. В общей сложности около 75 тысяч наборов данных по которым не менее 300 тысяч полей/метаданных доступны. Но это всё общедоступные данные, там почти нет чувствительных персональных данных (кроме некоторых исключений).

Для задач распознавания типов данных всегда нехватает данных предметных областей: финансовой, коммерческой, транспорта, медицины и тд. В общем и целом постоянное ощущение что данных мало сколько бы их не было;)

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

Ссылки:
[1] https://medium.com/datahub-project/creating-a-business-glossary-and-putting-it-to-use-in-datahub-43a088323c12
[2] https://data.apicrafter.ru

#datacatalogs #metadata

Вышла свежая версия Open Metadata 0.9.0 [1], каталога метаданных собирающего сведения о данных и процессах работы с ними.

Из интересного нового:
- много новых коннекторов к базам данных, теперь их 47 [2] поддерживают почти все популярные SQL базы данных
- поддерживают глоссарий терминов (смысловую привязку) к полям с данными
- дискуcсии к данным и отдельным полям
- контроль качества в виде стандартных метрик

В целом продукт быстро нагоняет другие каталоги данных такие как Amundsen или DataHub. Главным недостатком его остаётся отсутствие поддержки NoSQL баз данных таких как MongoDB и ElasticSearch

Ссылки:
[1] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882?gi=a94cfb8bcb3c
[2] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#8f53
[3] https://blog.open-metadata.org/openmetadata-0-9-0-release-8e7b93ab1882#a91f

#data #metadata #opensource #datacatalogs

Я вернулся к написанию технических текстов на английском языке, в этот раз заметка Semantic data types. Systematic approach and types registry [1] в Medium о инструментах о которых я регулярно пишу тут и на других площадках. Это инструмент metacrafter [2] по определению типов данных и наконец-то завершенный реестр Semantic data types [3] в котором собираются смысловые типы данных которые поддерживаются утилитой metacrafter или будут поддерживаться в будущем.

Зачем это нужно я уже писал, это необходимо для задач:
- выявления персональных и чувствительных данных автоматически
- упрощения интеграции данных
- автоматического документирования баз данных
- контроля качества данных, в том числе автоматического

Об этом и другом про данные и про практическую работу с данными я, постепенно, буду писать больше.

Ссылки:
[1] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[2] https://github.com/apicrafter/metacrafter
[3] http://registry.apicrafter.io/

#opendata #data #datatools #opensource #metadata

Я ранее писал про реестр семантических типов данных registry.apicrafter.io [1], сегодня добавил к нему расширение схемы описания каждого такого типа.
Напомню, это реестр смысловых значений полей данных полезный для задач:
- идентификации персональных данных
- улучшения навигации по каталогам данных
- автоматическое документирование данных
- автоматические тестирование данных

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

Например, код РНБ [3], для которого есть примеры и есть регулярное выражение для проверки [1-9]\d{3,8} и так ещё многие коды, в большей степени не российские, но некоторые российские тоже есть.

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

А во вторых - это примеры данных по каждому семантическому типу данных, чтобы было понятно как выглядят именно эти данные.

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

Ссылки:
[1] http://registry.apicrafter.io
[2] https://wikidata.org
[3] https://www.wikidata.org/wiki/Property:P7029

#data #opendata #metadata #opensource

Новости по проекту Metacrafter по распознаванию семантических типов данных, напомню, это небольшой pet-проект по идентификации типов данных в наборах данных и в СУБД, необходимо, например, для идентификации чувствительных данных вроде персональных данных, лучшей навигации по данным, поиска и интеграции данных. Я писал об этом большой текст на английском [1] и регулярно пишу тут.

1. Я выложил извлечённые метаданные из каталогов данных data.gov.ru, socrata.com, data.opendatasoft.com и data.gov.ru в репозиторий на Github [2]. Каталоги разного качества, поэтому метаданные не лучше данных, но могут быть полезны тем кто интересуется этой темой.

2. Значительно обновился реестр, всего 168 типов данных и 43 дополнительных шаблона. У 55% есть ссылки на дополнительное описание, у 28% регулярное выражение, у 21% ссылки на свойства в Wikidata, у 32% примеры данного семантического типа.

3. Для того чтобы всё это вносить была создана схема для валидации YAML файлов шаблонов и добавлена команда validate к скрипту сборки реестра которая использует библиотеку Cerberus в Python для валидации. Всё это в репозитории metacrafter-registry [3]

4. В какой-то момент накопилась уже критическая масса в более чем 24 задачи [4] большая часть которых - это материалы для изучения по метаданным. Например, есть много идентификаторов в экосистеме GS1 [5], а персональные данные неплохо идентифицируются IBM Default Guardium Analyzer [6] и ещё многие другие. Это ещё раз подталкивает меня к мысли о том что почему-то никто не занимался этой темой серьёзно, в основном очень точечные решения. Даже исследований крайне мало.

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

Ссылки:
[1] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[2] https://github.com/apicrafter/metacrafter-datacatalogs-raw
[3] https://github.com/apicrafter/metacrafter-registry
[4] https://github.com/apicrafter/metacrafter-registry/issues
[5] https://www.gs1.org/standards/barcodes/application-identifiers
[6] https://www.ibm.com/docs/en/sga?topic=sources-default-guardium-analyzer-patterns

#opendata #datatools #metadata

Свежий апдейт по проекту 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 [1] выявляющая семантические типы данных.

Если кратко, то это:
- выявление персональных данных
- улучшение data discovery
- автоматическое документирование

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

Ссылки:
[1] https://begtin.substack.com/p/28

#metadata #metacrafter #datatools #data #opensource

Полезные материалы по управлению метаданными и каталогами данных

Open source продукты
- Amundsen [1] создан внутри Lyft
- OpenMetadata [2] пытаются создавать стандарт
- Datahub [3] создан в LinkedIn, передан в Acryl Data
- Metacat [4] создан в Netflix
- Apache Atlas [5] передан в Apache Foundation
- Marquez [6] передан в Linux Foundation
- Whale [7] не обновлялся около года

Обзоры
- Top 7 Data Catalog Tools in 2022 [8] обзор от Hevo Data облачных, открытых и корпоративных каталогов

Видео и выступления на русском языке
- Data-docs — как найти данные о данных — Олег Харатов, Авито [9]
- Как мы строим Metadata Managemen — Юлия Кошелева и Энрика Матвейчук, Тинькофф [10]
- Под капотом каталога данных — Анастасия Ожигина, Тинькофф [11]

Видео на английском языке
- Data Catalog for data discovery and metadata management [12] от Google и про Google Data Catalog
- Amundsen: A Data Discovery Platform From Lyft | Lyft [13] видео 2019 года, про раннюю стадию создания Amunsen

Ссылки:
[1] https://www.amundsen.io/
[2] https://open-metadata.org/
[3] https://datahubproject.io/
[4] https://github.com/Netflix/metacat
[5] https://atlas.apache.org
[6] https://marquezproject.ai/
[7] https://github.com/hyperqueryhq/whale
[8] https://hevodata.com/learn/data-catalog-tools/
[9] https://www.youtube.com/watch?v=Cr1DDmhoLKI
[10] https://www.youtube.com/watch?v=3xuNp5L_ikU
[11] https://www.youtube.com/watch?v=puH3uBNoDXk
[12] https://www.youtube.com/watch?v=eUKqXZDXj78
[13] https://www.youtube.com/watch?v=EOCYw0yf63k

#datacatalogs #data #metadata #datatools

Как обещал, я буду стараться чаще писать про технологические инструменты которые делаются в рамках проекта 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-registry [1] [2], реестр существующих семантических типов данных и регулярных выражений для их идентификации.

Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [3], если кратко то для автоматизации визуализации, анализа, навигации и обработки данных.

Реестр вырос уже до 284 типов данных сгруппированных по 26 категориям и в привязке к 11 странам. Более всего страновых идентификаторов по России - более 70 (ИНН, СНИЛС, КЛАДР и все остальные), но по мере обработки порталов данных и других источников растет список и по другим странам.

Самые главные изменения в том что многие типы данных теперь имеют привязку к Wikidata и Schema.org. Какие-то ещё можно привязать, но, к сожалению не все. Wikidata почти не покрывает персональные идентификаторы, зато включает сотни идентификаторов литературных источников почти нигде "в диком виде" не встречающиеся.

Реестр всё лучше перелинкован, синхронизован с используемыми инструментами и понемногу включает и регулярные выражения для идентификации типов данных. Часть их уже перенесена в утилиту metacrafter [4] для идентификации семантических типов данных, а часть будет перенесена постепенно позже.

Ссылки:
[1] https://registry.apicrafter.io/
[2] https://github.com/apicrafter/metacrafter-registry
[3] https://medium.com/@ibegtin/semantic-data-types-systematic-approach-and-types-registry-a2c2a60a467b
[4] https://github.com/apicrafter/metacrafter

#opensource #data #datatools #metadata #semanticdatatypes

Онтология типов данных

Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология OntoDT [1] ещё 2016 года, но сайт с ним уже недоступен, и сама онтология кое-где ещё доступна как RDF/OWL [2]. Основной автор Panče Panov явно переключился на более прикладные исследования [3]

В качестве других примеров։
- онтология EDAM [4] в биоинформатике, с акцентом на особенности анализа и майнинга данных в этой области
- CDM (Common Data Model) [5] не-формальная онтологии от Microsoft привязанная с акцентом на продажах, пользователях, маркетинге и тд.
- онтология типов данных при ответах на вопросы по геоаналитике [6] прошлогоднее исследование с акцентом на геоданные.

Есть, также, какое-то количество других научных и не только научных публикаций на эту тему, но в целом их довольно мало. Они чаще всего происходят в контексте задач по анализу данных и его автоматизации. Самое развитое идёт в сторону автоматизации создания и аннотирование моделей для ИИ. Проект D3M (Data-Driven Discovery of Models) [7] от DARPA в США. Я не так давно писал о нём и порождённых им стартапах. [8]

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

Ещё какое-то время назад в СУБД на родном уровне поддерживались только самые базовые типы данных։ INT, FLOAT, STRING/VARCHAR, BLOB и тд. с небольшими вариациями. Сейчас, современные СУБД, поддерживают многочисленные дополнительные типы данных, перешедших из смысловых (семантических) в базовые типы. Пример: ip-адреса и mac-адреса уже достаточно давно имеющиеся в некоторых СУБД [9] и недавно добавляемые в другие [10].

Ранее всего это произошло с датами и временем в разных вариациях, с геоданными для которых есть сейчас много отдельных функций и индексов внутри СУБД. Также происходит с сетевыми наиболее популярными данными.

Мои ощущения что на этом процесс не остановится. Например, меня удивляет что всё ещё нет СУБД общего типа с отдельными типами данных под хэши (SHA1, SHA256 и др.).

Многие составные идентификаторы и коды классификаторов сейчас в СУБД хранятся как строки, при том что часто они нужны в декомпозированной форме и, в итоге, создаётся избыточность разбирая этот код на части. Пример в России: Вы можете хранить код КЛАДР как есть, а можете разделить его на подэлементы и осуществлять поиск по ним когда это необходимо.

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

Ссылки:
[1] https://fairsharing.org/FAIRsharing.ydnwd9
[2] https://kt.ijs.si/panovp/OntoDM/archive/OntoDT.owl
[3] https://orcid.org/0000-0002-7685-9140
[4] http://edamontology.org/page
[5] https://docs.microsoft.com/en-us/common-data-model/
[6] https://digitalcommons.library.umaine.edu/josis/vol2020/iss20/2/
[7] https://datadrivendiscovery.org
[8] https://t.me/begtin/3926
[9] https://www.postgresql.org/docs/current/datatype-net-types.html
[10] https://mariadb.com/kb/en/inet4/

#data #rdbms #research #metadata #semanticdatatypes