Среди современного стека с данными отдельная тема, о которой я регулярно пишу, это продукты по 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
Так вот эти продукты переживают сейчас бум развития, инвестиций и пользовательского внимания, потому что уже многие крупные и средние компании накопили команды, наработки, данные и тд. а наведение в этом всём порядка оказывается большой задачей. Вернее задач там много, аналитические, задачи 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
Telegram
Ivan Begtin
Свежее исследование Forrester Wave со сравнением 12 облачных провайдеров управления данными: Aim, Alation, Ataccama, Collibra, Congruity360, data.world, erwin, Infogix, OneTrust, SAP, Solix, Syniti [1]
В лидерах они упоминают Colibra, Alation, Infogix, Atacamma.…
В лидерах они упоминают Colibra, Alation, Infogix, Atacamma.…
В рубрике интересное регулярное чтение:
- 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
- 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
Medium
Every Product Will Be a Data Product
Why build a data product? Typical use cases of data product
Вышла свежая версия 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
В новой версии:
- политики контроля доступа (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
Medium
OpenMetadata 0.8.0 Release
OpenMetadata 0.8.0 Release — Event Notification via Webhooks, Slack Integration, Access Control Policy, and Manual Lineage
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
Все правила оформлены прям как и у меня в виде 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
Medium
Metadata Guardian — Protect your data by searching its metadata
Scan various data sources using multiple regular expressions simultaneously.
В нашем движке по распознаванию типов данных внутри баз данных, таблиц и файлов теперь 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
Главные достоинства по сравнению с аналогичными инструментами:
* легко расширяется новыми правилами, правила описываются в файлах в 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
GitHub
GitHub - apicrafter/metacrafter: Metadata and data identification tool and Python library. Identifies PII, common identifiers,…
Metadata and data identification tool and Python library. Identifies PII, common identifiers, language specific identifiers. Fully customizable and flexible rules - apicrafter/metacrafter
В блоге 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
Я же могу сказать что это та область которая хорошо поддаётся автоматизации и алгоритмизации и я над ней думаю уже наверное с 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
Medium
Creating a Business Glossary and Putting it to use in DataHub
In a previous post, we covered the high-level differences between Tags and Glossary Terms, two powerful labeling methods in DataHub.
Вышла свежая версия 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
Из интересного нового:
- много новых коннекторов к базам данных, теперь их 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
Medium
OpenMetadata 0.9.0 Release
OpenMetadata 0.9.0 Release — Data Collaboration via Activity Feeds and Conversation Threads, Data Quality and Tests, Glossary Support …
Я вернулся к написанию технических текстов на английском языке, в этот раз заметка 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
Зачем это нужно я уже писал, это необходимо для задач:
- выявления персональных и чувствительных данных автоматически
- упрощения интеграции данных
- автоматического документирования баз данных
- контроля качества данных, в том числе автоматического
Об этом и другом про данные и про практическую работу с данными я, постепенно, буду писать больше.
Ссылки:
[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
Medium
Semantic data types. Systematic approach and types registry
What is semantic data types?
Я ранее писал про реестр семантических типов данных 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
Напомню, это реестр смысловых значений полей данных полезный для задач:
- идентификации персональных данных
- улучшения навигации по каталогам данных
- автоматическое документирование данных
- автоматические тестирование данных
Во первых - это связь типа данных со свойством из 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
www.wikidata.org
National Library of Russia ID
identifier for authority control used by the National Library of Russia, Saint-Petersburg
Новости по проекту 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
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
Medium
Semantic data types. Systematic approach and types registry
What is semantic data types?
Свежий апдейт по проекту 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...
Кажется я ещё ни разу об этом не писал, о том как сопоставить метрики качества данных используемые в Modern Data Stack и в порталах открытых данных. Во многом там разные подходы, я писал о разнице между разными типами каталогов в большом тексте на Medium.
В блоге Towards Data Science полезный текст от Prukalpa, сооснователя стартапа Atlan, про методику 5WH1
5WH1 - это список вопросов по качеству данных на которые нужны ответы: What, Why, Where, Who, When, and How.
Или, по русски։ Что, Почему, Где, Кто, Когда и Как
В целом - это перечень метаданных которые должны собираться о данных для понимания того как данные устроены и что с ними делать. В корпоративном мире применение этой методики или подобных - это нечто безусловно актуальное и важное, особенно при работе многих команд. В мире открытых данных всё несколько иначе. Данные в виде файлов, их владельцы уже часто недоступны и много исторических данных по которым мало метаданных в принципе.
Тем не менее, наиболее продуманный стандарт мониторинга качества метаданных - это европейский MQA (Metadata Quality Assurance). Но критерии там иные: Findability, Accessibility, Interoperabilty, Contextuality, Reusability.
Перечень метаданных собираемых в рамках агрегации описаний по стандарту DCAT-AP для открытых данных даже больше, но и качество данных многократно ниже.
Подробнее и со ссылками в моей заметке на Medium на английском [1]
Ссылки:
[1] https://medium.com/@ibegtin/data-catalogs-part-3-metadata-quality-observation-c49be890f6ff
#opendata #metadata #dataquality
В блоге Towards Data Science полезный текст от Prukalpa, сооснователя стартапа Atlan, про методику 5WH1
5WH1 - это список вопросов по качеству данных на которые нужны ответы: What, Why, Where, Who, When, and How.
Или, по русски։ Что, Почему, Где, Кто, Когда и Как
В целом - это перечень метаданных которые должны собираться о данных для понимания того как данные устроены и что с ними делать. В корпоративном мире применение этой методики или подобных - это нечто безусловно актуальное и важное, особенно при работе многих команд. В мире открытых данных всё несколько иначе. Данные в виде файлов, их владельцы уже часто недоступны и много исторических данных по которым мало метаданных в принципе.
Тем не менее, наиболее продуманный стандарт мониторинга качества метаданных - это европейский MQA (Metadata Quality Assurance). Но критерии там иные: Findability, Accessibility, Interoperabilty, Contextuality, Reusability.
Перечень метаданных собираемых в рамках агрегации описаний по стандарту DCAT-AP для открытых данных даже больше, но и качество данных многократно ниже.
Подробнее и со ссылками в моей заметке на Medium на английском [1]
Ссылки:
[1] https://medium.com/@ibegtin/data-catalogs-part-3-metadata-quality-observation-c49be890f6ff
#opendata #metadata #dataquality
Написал сегодня очередной текст в рассылку, на сей раз чуть подробнее рассказал о том как применяется и для чего делается утилита metacrafter [1] выявляющая семантические типы данных.
Если кратко, то это:
- выявление персональных данных
- улучшение data discovery
- автоматическое документирование
Тем временем могу сказать что утилита пополнилась новыми правилами и этой работы там ещё много, а также в базовом варианте она теперь позволяет анализировать XML файлы. В базовом, потому что у ей надо передавать название тега в который вложен объект, а автоматическое определение таких тегов где-то на следующем шаге.
Ссылки:
[1] https://begtin.substack.com/p/28
#metadata #metacrafter #datatools #data #opensource
Если кратко, то это:
- выявление персональных данных
- улучшение data discovery
- автоматическое документирование
Тем временем могу сказать что утилита пополнилась новыми правилами и этой работы там ещё много, а также в базовом варианте она теперь позволяет анализировать XML файлы. В базовом, потому что у ей надо передавать название тега в который вложен объект, а автоматическое определение таких тегов где-то на следующем шаге.
Ссылки:
[1] https://begtin.substack.com/p/28
#metadata #metacrafter #datatools #data #opensource
Ivan’s Begtin Newsletter on digital, open and preserved government
#28. Data discovery, автодокументирование и выявление персональных данных
Я довольно давно не писал про инструмент metacrafter [1] который я постепенно развиваю как небольшой экспериментальный проект по идентификации семантических типов данных, но которые имеет самое что ни на есть прямое применение. Собственно в этом и цель в…
Полезные материалы по управлению метаданными и каталогами данных
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
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
www.amundsen.io
Amundsen, the leading open source data catalog
Как обещал, я буду стараться чаще писать про технологические инструменты которые делаются в рамках проекта 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-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
Для тех кто не знает что это такое, напомню про мой текст с рассказом того как их применяют и зачем они нужны [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
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
Онтология типов данных
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Когда я только-только начинал возиться с семантическими типами данных то столкнулся с тем что онтологического моделирования типов данных очень мало. Есть исследование и онтология 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
Docs
Common Data Model - Common Data Model
Common Data Model is a standardized, modular, and extensible collection of data schemas that Microsoft published to help you build, use, and analyze data.
This media is not supported in your browser
VIEW IN TELEGRAM
Вышла версия 1.0 корпоративного каталога данных Open Metadata [1] с открытым кодом. Продукт интересный, даёт уйму интересных возможностей для тех кто делает свои корпоративные каталоги данных и систематизирует внутренние ресурсы в виде данных. Я давно к нему присматриваюсь и, хотя пока ещё не смотрел версию 1.0, обязательно посмотрю. В том числе они заявляют автоматическое выявлении персональных данных (Auto PII Classification), а я продолжаю заниматься небольшим продуктом по идентификации семантических типов данных и персональные данные туда тоже входят.
Но даже до того как я посмотрю версию 1.0 я могу сказать то чего в Open Metadata точно до сих пор нет - это поддержка NoSQL во всех формах. Нет поддержки, ни Redis, ни MongoDB, ни ArangoDB, ни JSON объектов внутри NewSQL баз данных. А это значит что если у вас только SQL архитектура и инфраструктура, то это инструмент, возможно, подходящий. А если, например, кроме SQL у вас ещё и базы MongoDB для хранения, Elastic для поискового индекса, Redis для сессий пользователей и ещё что-нибудь экзотическое и какое-нибудь legacy, то нужно искать другие инструменты.
Конечно, команда Open Metadata действует как стартап и делают хорошо какую-то узкую область, но одновременно они заложили архитектурное ограничение восприятия каталогизируемых объектов как таблиц. Преодолеть им его теперь очень сложно, нужно будет переписать много кода и поломать совместимость с уже написанными расширениями.
Ссылки:
[1] https://blog.open-metadata.org/openmetadata-1-0-release-beb34762d916
#opensource #datacatalogs #metadata
Но даже до того как я посмотрю версию 1.0 я могу сказать то чего в Open Metadata точно до сих пор нет - это поддержка NoSQL во всех формах. Нет поддержки, ни Redis, ни MongoDB, ни ArangoDB, ни JSON объектов внутри NewSQL баз данных. А это значит что если у вас только SQL архитектура и инфраструктура, то это инструмент, возможно, подходящий. А если, например, кроме SQL у вас ещё и базы MongoDB для хранения, Elastic для поискового индекса, Redis для сессий пользователей и ещё что-нибудь экзотическое и какое-нибудь legacy, то нужно искать другие инструменты.
Конечно, команда Open Metadata действует как стартап и делают хорошо какую-то узкую область, но одновременно они заложили архитектурное ограничение восприятия каталогизируемых объектов как таблиц. Преодолеть им его теперь очень сложно, нужно будет переписать много кода и поломать совместимость с уже написанными расширениями.
Ссылки:
[1] https://blog.open-metadata.org/openmetadata-1-0-release-beb34762d916
#opensource #datacatalogs #metadata
В качестве регулярного напоминания, если Вы ищите данные по России и постсоветским странам, то в каталоге каталогов данных DataCatalogs.ru [1] они как раз собраны.
В проекте сейчас 322 каталога данных, из которых 294 по России, ещё 28 по Казахстану, Кыргызстану, Узбекистану, Армении и тд.
В данном случае открытые данные трактуются расширительно, исходя из того что в каталоге каталогов собраны и источники не только открытых данных в строгом определении, но и другие общедоступные источники данных которые что называется "недооткрыты", например, порталы открытого бюджета или геопорталы.
Этот проект был одним из источников для создаваемого сейчас Common Data Index [2] реестра каталогов данных по всему миру, где их уже более 2000+ тысяч и о котором я, также, регулярно пишу.
Ссылки:
[1] https://www.datacatalogs.ru/
[2] https://github.com/commondataio/dataportals-registry
#opendata #datacatalogs #dataportals #metadata
В проекте сейчас 322 каталога данных, из которых 294 по России, ещё 28 по Казахстану, Кыргызстану, Узбекистану, Армении и тд.
В данном случае открытые данные трактуются расширительно, исходя из того что в каталоге каталогов собраны и источники не только открытых данных в строгом определении, но и другие общедоступные источники данных которые что называется "недооткрыты", например, порталы открытого бюджета или геопорталы.
Этот проект был одним из источников для создаваемого сейчас Common Data Index [2] реестра каталогов данных по всему миру, где их уже более 2000+ тысяч и о котором я, также, регулярно пишу.
Ссылки:
[1] https://www.datacatalogs.ru/
[2] https://github.com/commondataio/dataportals-registry
#opendata #datacatalogs #dataportals #metadata
Теперь уже 7055 каталогов данных в реестре каталогов данных registry.commondata.io из которых как минимум 5393 потенциально индексируемых в поиск. Много это или мало? Много. В dataportals.org всего 598 порталов, в Datashades.info 530 инсталляций CKAN, в re3data.org 3125 порталов научных данных.
Самое сложное - это собирать описания всех записей, а для этого нужны метрики качества. Для любого дата проекта нужны метрики качества и автоматизация их улучшения.
Вот в данном случае это референсная база данных, не транзакционная, а справочная для любых других проектов по систематизации данных. Полнота метаданных имеет значение и поэтому метрики именно про эту полноту: есть ли какое-то поле, ненулевое ли оно и так далее.
Вот чего не хватает так это простой системы метрик которую можно было бы пристыковать к базе данных в виде СУБД или в виде CSV/NDJSON файла.
Существующие движки оценки и мониторинга качества данных не подходят. Какие существуют альтернативы кроме как изобретать свой велосипед?
#opendata #datatools #metadata #datacatalogs #commondataindex
Самое сложное - это собирать описания всех записей, а для этого нужны метрики качества. Для любого дата проекта нужны метрики качества и автоматизация их улучшения.
Вот в данном случае это референсная база данных, не транзакционная, а справочная для любых других проектов по систематизации данных. Полнота метаданных имеет значение и поэтому метрики именно про эту полноту: есть ли какое-то поле, ненулевое ли оно и так далее.
Вот чего не хватает так это простой системы метрик которую можно было бы пристыковать к базе данных в виде СУБД или в виде CSV/NDJSON файла.
Существующие движки оценки и мониторинга качества данных не подходят. Какие существуют альтернативы кроме как изобретать свой велосипед?
#opendata #datatools #metadata #datacatalogs #commondataindex