В блоге 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