Написал сегодня очередной текст в рассылку, на сей раз чуть подробнее рассказал о том как применяется и для чего делается утилита 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] который я постепенно развиваю как небольшой экспериментальный проект по идентификации семантических типов данных, но которые имеет самое что ни на есть прямое применение.
Как обещал, я буду стараться чаще писать про технологические инструменты которые делаются в рамках проекта APICrafter, в том числе тот о котором я пишу часто в последнее время - metacrafter про распознавание семантических типов данных.
Инструмент уже, в принципе, в состоянии когда его надо переводить в промышленное использование, но, всегда хочется докрутить ещё чуть-чуть.
Так вот, здесь про пользу государственных порталов открытых данных вроде российского data.gov.ru, британского data.gov.uk и др. Польза эта в многообразии. Например, по data.gov.ru я обучаю распознавалку семантических типов данных.
Для тех кто интересуется как это работает, в репозитории metacrafter-datacatalogs-raw собраны метаданные с разных порталов и опубликован результат распознавания семантических типов данных по data.gov.ru. Желающие могут скачать нефильтрованный результат распознаваний в файле datagovru_semantictypes.jsonl.xz
В цифрах:
- 18+ тысяч обработанных наборов данных
- 198 660 полей полей структурированных файлах
- 66 921 полей у которых автоматически определен семантический тип (примерно 34%)
- наиболее успешно идентифицируются: уникальные идентификаторы, булевые значения, наименования, ФИО, дата и время, номер телефона, url, год и тд
- самые частые ошибки в полях когда название поля используется как булевое значение, а не как содержащие сущность. Например, если поле называется "passport", а не "hasPassport" и по факту является словарем в значениях "имеется" и "отсутствует"
- распознавание можно улучшить зная контекст, источник данных, дополнительные метаданные и тд., но это какое-то дополнительное направление исследований, скорее научное чем практическое.
В общем и целом могу сказать что такое разнообразие данных полезно для разработки алгоритмов несмотря даже на бесполезность данных для практического использования.
Но даже для такой задачи есть ключевая проблема - это качество данных. Я не просто так пишу про то что госданные, в целом, это мусор.
Вот лишь несколько характеристик именно низкого качества данных:
- CSV файлы публикуются в разных кодировках и с разными разделителями (это, отчасти, преодолимо)
- CSV файлы очень часто публикуются без заголовков, например, многие данные из ХМАО (это реальная проблема)
- многие расширения файлов не соответствуют содержанию. CSV или ZIP вместо XML, HTML вместо CSV и так далее
- многие ссылки на файлы на других сайтах давно протухли, например, ссылки на сайт fstrf.ru давно ведут на какой-то левый сайт.
- вместо настоящих XML файлов с данными публикуются файлы разметки. Я об этом писал ранее, это вообще напоминает какой-то подлог
- многие CSV файлы это кривой экспорт из Excel с многострочтными заголовками и строками ИТОГО нарушающими разбор файла
- огромное число файлов просто пустые
Делать полную оценку причин и проблем с качеством открытых гос данных долго, я пишу о том насколько они влияют на возможность их автоматизированного анализа. Собственно по причинам выше и из 26+ тысяч наборов данных удалось обработать около 18+ тысяч и среди обработанных есть ошибки связанные с неверными заголовками у CSV файлов.
При этом, не в защиту российских чиновников, а в сторону госчиновников в принципе могу сказать что мало где в мире над качеством открытых данных реально работают. Я недавно общался с командой одного из крупных продуктов по публикации открытых данных и они говорят что чиновники по всему миру просят их, скорее, добавить возможность публикации PDF'ов и других плохоструктурированных данных, чем мониторинг качества данных.
Но всё постепенно меняется и я про качество данных расскажу ещё не раз.
#opendata #datasets #metadata #metacrafter #apicrafter
Инструмент уже, в принципе, в состоянии когда его надо переводить в промышленное использование, но, всегда хочется докрутить ещё чуть-чуть.
Так вот, здесь про пользу государственных порталов открытых данных вроде российского data.gov.ru, британского data.gov.uk и др. Польза эта в многообразии. Например, по data.gov.ru я обучаю распознавалку семантических типов данных.
Для тех кто интересуется как это работает, в репозитории metacrafter-datacatalogs-raw собраны метаданные с разных порталов и опубликован результат распознавания семантических типов данных по data.gov.ru. Желающие могут скачать нефильтрованный результат распознаваний в файле datagovru_semantictypes.jsonl.xz
В цифрах:
- 18+ тысяч обработанных наборов данных
- 198 660 полей полей структурированных файлах
- 66 921 полей у которых автоматически определен семантический тип (примерно 34%)
- наиболее успешно идентифицируются: уникальные идентификаторы, булевые значения, наименования, ФИО, дата и время, номер телефона, url, год и тд
- самые частые ошибки в полях когда название поля используется как булевое значение, а не как содержащие сущность. Например, если поле называется "passport", а не "hasPassport" и по факту является словарем в значениях "имеется" и "отсутствует"
- распознавание можно улучшить зная контекст, источник данных, дополнительные метаданные и тд., но это какое-то дополнительное направление исследований, скорее научное чем практическое.
В общем и целом могу сказать что такое разнообразие данных полезно для разработки алгоритмов несмотря даже на бесполезность данных для практического использования.
Но даже для такой задачи есть ключевая проблема - это качество данных. Я не просто так пишу про то что госданные, в целом, это мусор.
Вот лишь несколько характеристик именно низкого качества данных:
- CSV файлы публикуются в разных кодировках и с разными разделителями (это, отчасти, преодолимо)
- CSV файлы очень часто публикуются без заголовков, например, многие данные из ХМАО (это реальная проблема)
- многие расширения файлов не соответствуют содержанию. CSV или ZIP вместо XML, HTML вместо CSV и так далее
- многие ссылки на файлы на других сайтах давно протухли, например, ссылки на сайт fstrf.ru давно ведут на какой-то левый сайт.
- вместо настоящих XML файлов с данными публикуются файлы разметки. Я об этом писал ранее, это вообще напоминает какой-то подлог
- многие CSV файлы это кривой экспорт из Excel с многострочтными заголовками и строками ИТОГО нарушающими разбор файла
- огромное число файлов просто пустые
Делать полную оценку причин и проблем с качеством открытых гос данных долго, я пишу о том насколько они влияют на возможность их автоматизированного анализа. Собственно по причинам выше и из 26+ тысяч наборов данных удалось обработать около 18+ тысяч и среди обработанных есть ошибки связанные с неверными заголовками у CSV файлов.
При этом, не в защиту российских чиновников, а в сторону госчиновников в принципе могу сказать что мало где в мире над качеством открытых данных реально работают. Я недавно общался с командой одного из крупных продуктов по публикации открытых данных и они говорят что чиновники по всему миру просят их, скорее, добавить возможность публикации PDF'ов и других плохоструктурированных данных, чем мониторинг качества данных.
Но всё постепенно меняется и я про качество данных расскажу ещё не раз.
#opendata #datasets #metadata #metacrafter #apicrafter
Я довольно давно не рассказывал про развитие инструментов metacrafter для выявления семантических типов данных и реестра семантических типов данных metacrafter-registry которыми давно занимаюсь.
Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами Schema.org и Wikidata. А есть одно изменение важное именно для инженерии данных - это экспорт реестра в формат бизнес глоссария (Business Glossary) используемого в каталоге данных Datahub.
Для тех кто не знает, бизнес глоссарий, это смысловые характеристики полей данных записываемые в каталогах данных. Не обязательно семантический/смысловой тип поля, но может быть, например, уровень его конфиденциальности, чувствительности данных и так далее.
Datahub - это опенсорсный каталог корпоративных данных [1] созданный некогда в LinkedIn и развиваемый сейчас компанией Acryl. Среди его достоинств есть импорт данных, в том числе, для бизнес глоссария.
И вот для тех кто хочет загрузить туда типы данных из Metacrafter'а теперь это можно сделать воспользовавшись файлом metacrafter.yml [2] из репозитория проекта. Выглядит результат примерно как на вот этом скриншоте.
Следующий шаг в интеграции metacrafter'а в непосредственно процесс загрузки метаданных в Datahub, так чтобы привязку поля к данным можно было бы осуществлять автоматически.
Ссылки:
[1] https://datahubproject.io
[2] https://github.com/apicrafter/metacrafter-registry/tree/main/data/datahub
#opensource #semanticdatatypes #dataengineering #apicrafter #metacrafter
Изменений там много, в основном в части постепенно улучшения списка типов данных, связанности с базами Schema.org и Wikidata. А есть одно изменение важное именно для инженерии данных - это экспорт реестра в формат бизнес глоссария (Business Glossary) используемого в каталоге данных Datahub.
Для тех кто не знает, бизнес глоссарий, это смысловые характеристики полей данных записываемые в каталогах данных. Не обязательно семантический/смысловой тип поля, но может быть, например, уровень его конфиденциальности, чувствительности данных и так далее.
Datahub - это опенсорсный каталог корпоративных данных [1] созданный некогда в LinkedIn и развиваемый сейчас компанией Acryl. Среди его достоинств есть импорт данных, в том числе, для бизнес глоссария.
И вот для тех кто хочет загрузить туда типы данных из Metacrafter'а теперь это можно сделать воспользовавшись файлом metacrafter.yml [2] из репозитория проекта. Выглядит результат примерно как на вот этом скриншоте.
Следующий шаг в интеграции metacrafter'а в непосредственно процесс загрузки метаданных в Datahub, так чтобы привязку поля к данным можно было бы осуществлять автоматически.
Ссылки:
[1] https://datahubproject.io
[2] https://github.com/apicrafter/metacrafter-registry/tree/main/data/datahub
#opensource #semanticdatatypes #dataengineering #apicrafter #metacrafter
После моего выступления на SmartData чуть ли не большая часть вопросов, во всяком случае существенная, была про семантические типы данных. Я много писал про них ранее. Для тех кто не читал или подзабыл, семантические типы данных - это когда полям таблицы или дата-файла добавляется идентификатор характеризующий содержание этой колонки/полня с данными.
Например, не просто колонка со строкой, а колонка с полными ФИО человека, или колонка с названием страны, или города, или кодом организации и так далее. Это нужно для многих задач, самая распространённая из которых - выявление персональных данных в базах данных.
И напомню про инструмент metacrafter [1] который ещё 2 года назад я выкладывал в открытый код и в котором реализована идентификация семантических типов.
Инструмент работает через набор правил описываемых в YAML файлах и ссылающихся на реестр семантических типов [2].
Правила отличаются от очень простых, до довольно сложных. Простые сводятся к соответствие 1 к 1, сложные к комплексным регулярным выражениям и описанию правил скриптами или кодом для pyparsing [3].
pyparsing - это, кстати, реальная находка для таких задач поскольку конечные автоматы описанные этой библиотекой работают гораздо быстрее регулярных выражений в Python и выглядит более читабельно через регулярные выражения, хотя и длиннее.
Пример: Word(nums, exact=3) + Literal('-').suppress() + Word(nums, exact=1) + Literal('-').suppress() + Word(nums, exact=2) + Literal('-').suppress() + Word(nums, exact=6) + Literal('-').suppress() + Word(nums, exact=1)
Этот код для идентификации кодов для ISBN13, а сами правила можно посмотреть в репозитории [4].
Инструмент работает как библиотека для Python и как утилита командной строки. Поддерживает файлы в форматах CSV, JSON, NDJSON, Parquet, XML, и базы SQL и MongoDB.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://registry.apicrafter.io
[3] https://github.com/pyparsing/pyparsing/
[4] https://github.com/apicrafter/metacrafter/tree/main/rules
#opensource #datatools #metacrafter
Например, не просто колонка со строкой, а колонка с полными ФИО человека, или колонка с названием страны, или города, или кодом организации и так далее. Это нужно для многих задач, самая распространённая из которых - выявление персональных данных в базах данных.
И напомню про инструмент metacrafter [1] который ещё 2 года назад я выкладывал в открытый код и в котором реализована идентификация семантических типов.
Инструмент работает через набор правил описываемых в YAML файлах и ссылающихся на реестр семантических типов [2].
Правила отличаются от очень простых, до довольно сложных. Простые сводятся к соответствие 1 к 1, сложные к комплексным регулярным выражениям и описанию правил скриптами или кодом для pyparsing [3].
pyparsing - это, кстати, реальная находка для таких задач поскольку конечные автоматы описанные этой библиотекой работают гораздо быстрее регулярных выражений в Python и выглядит более читабельно через регулярные выражения, хотя и длиннее.
Пример: Word(nums, exact=3) + Literal('-').suppress() + Word(nums, exact=1) + Literal('-').suppress() + Word(nums, exact=2) + Literal('-').suppress() + Word(nums, exact=6) + Literal('-').suppress() + Word(nums, exact=1)
Этот код для идентификации кодов для ISBN13, а сами правила можно посмотреть в репозитории [4].
Инструмент работает как библиотека для Python и как утилита командной строки. Поддерживает файлы в форматах CSV, JSON, NDJSON, Parquet, XML, и базы SQL и MongoDB.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://registry.apicrafter.io
[3] https://github.com/pyparsing/pyparsing/
[4] https://github.com/apicrafter/metacrafter/tree/main/rules
#opensource #datatools #metacrafter
Сугубо техническое и инструментальное. Я на днях обновил исходный код утилиты metacrafter [1] и библиотеки для Python iterabledata [2].
Metacrafter - это утилита и библиотека для Python по выявлению семантических типов данных и далее автодокументирования датасетов. Она изначально поддерживала MongoDB, базовые типы файлов вроде csv, xml, jsonl и тд, а также большую часть SQL баз данных (через SQLAlchemy). Не хватало только поддержки файлов которые могут быть разнообразно сжаты. Эту задачу получилось решить переключившись на библиотеку iterabledata которая поддерживает работу с файлами вроде .csv.bz2, .xml.xz, .jsonl.gz и так далее. Собственно к уже имеющимся алгоритмам сжатия и форматам я добавил ещё Zstandard и Brotli. Из популярных форматов не поддерживаются пока только Snappy и 7z . Но у Snappy неудобная реализация на Python, надо её переписывать, а библиотека для 7z не поддерживает режим открытия файла в контейнере, без обязательного раз сжатия .
Но в остальном оказалось очень удобно . Осталось часть других инструментов переписать с этой библиотекой для простоты обработки условно любых входящих дата файлов с условно любым типом сжатия/контейнеров.
А поддержку сжатых файлов в metacrafter пришлось добавлять не просто так, а потому что хранение бесконечного числа CSV'шек и других первичных файлов в Dateno сжирает очень много места, а обрабатывать их надо. И обрабатывать достаточно быстро и с достаточно небольшими ресурсами памяти, процессора и тд.
Один из способов такой экономии это обновление инструментария для поддержки сжатых файлов на всех этапах. Причём не только на этапе обработки данных, но и на этапе извлечения и загрузки. Импорт в СУБД тоже нужен не в чистых .csv или .json, файлах, а в том числе, сжатыми тоже.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/pyiterable
#opensource #datatools #data #metacrafter #dateno
Metacrafter - это утилита и библиотека для Python по выявлению семантических типов данных и далее автодокументирования датасетов. Она изначально поддерживала MongoDB, базовые типы файлов вроде csv, xml, jsonl и тд, а также большую часть SQL баз данных (через SQLAlchemy). Не хватало только поддержки файлов которые могут быть разнообразно сжаты. Эту задачу получилось решить переключившись на библиотеку iterabledata которая поддерживает работу с файлами вроде .csv.bz2, .xml.xz, .jsonl.gz и так далее. Собственно к уже имеющимся алгоритмам сжатия и форматам я добавил ещё Zstandard и Brotli. Из популярных форматов не поддерживаются пока только Snappy и 7z . Но у Snappy неудобная реализация на Python, надо её переписывать, а библиотека для 7z не поддерживает режим открытия файла в контейнере, без обязательного раз сжатия .
Но в остальном оказалось очень удобно . Осталось часть других инструментов переписать с этой библиотекой для простоты обработки условно любых входящих дата файлов с условно любым типом сжатия/контейнеров.
А поддержку сжатых файлов в metacrafter пришлось добавлять не просто так, а потому что хранение бесконечного числа CSV'шек и других первичных файлов в Dateno сжирает очень много места, а обрабатывать их надо. И обрабатывать достаточно быстро и с достаточно небольшими ресурсами памяти, процессора и тд.
Один из способов такой экономии это обновление инструментария для поддержки сжатых файлов на всех этапах. Причём не только на этапе обработки данных, но и на этапе извлечения и загрузки. Импорт в СУБД тоже нужен не в чистых .csv или .json, файлах, а в том числе, сжатыми тоже.
Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/pyiterable
#opensource #datatools #data #metacrafter #dateno
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
В качестве лирического отступления. Если бы я был писателем пишущим по методу Хэмингуэя, без исправления текста, то сказал бы что "аллилуйя", пришёл настоящий вызов. Но я не такой писатель, и художественное творчество моё куда как скромно, но вот работа с нефункционирующей кнопкой бэкспейса на клавиатуре и ещё рядом других кнопок накладывает свои ограничения, как минимум на скорость печати. К сожалению замена клавиатуры будет только через несколько дней, так что это писать также часто как раньше пока не выходит.
Но даже так я слегка пробежался по старому коду движка metacrafter'а [1], инструмента для идентификации семантических типов данных, или более простым языком, инструмент идентификации того что за колонка в наборе данных или в базе данных и что с ней можно делать. Инструмент я потихоньку начал приводить в целевое состояние - усиление поисковых возможностей у Dateno и автодокументирование датасетов.
Что нового:
- правила для metacrafter'а перенесены теперь в новый репозиторий metacrafter-rules [2], их стало больше, в основном за счёт правил для других языков отличных от английского и русского;
- обновился серверный и клиентский режимы работы. Теперь можно ускорить сканирование данных запустив metacrafter как сервер и обращаясь к нему через параметр remote при вызовах сканирования файлов или баз данных. Это важно для ускорения процесса поскольку правила инициализируются только один раз
- добавилась команда просмотра правил 'metacrafter rules list'
- и так далее
Главный недостаток сейчас - это скорость работы на больших датасетах. Чем больше колонок тем дольше анализ, до нескольких минут. Это не так критично для задач вроде сканирования корпоративных СУБД, но тяжко для задач Dateno когда миллионы датасетов.
На самом деле чтобы всё ускорить нужно просто много ресурсов: процессорных, хранения и памяти. А прикрутив LLM'ку можно сильно повысить качество автодокументирования данных.
Понимание данных, автодокументирование датасетов, автоматизация анализа данных - это одни из наиболее любимых мной тем в дата инженерии и дата анализе. Жаль удаётся уделять немного времени.
Ссылки:
[1] https://github.com/apicrafter/metacrafter/
[2] https://github.com/apicrafter/metacrafter-rules/
#opensource #data #datatools #dateno #metacrafter
Но даже так я слегка пробежался по старому коду движка metacrafter'а [1], инструмента для идентификации семантических типов данных, или более простым языком, инструмент идентификации того что за колонка в наборе данных или в базе данных и что с ней можно делать. Инструмент я потихоньку начал приводить в целевое состояние - усиление поисковых возможностей у Dateno и автодокументирование датасетов.
Что нового:
- правила для metacrafter'а перенесены теперь в новый репозиторий metacrafter-rules [2], их стало больше, в основном за счёт правил для других языков отличных от английского и русского;
- обновился серверный и клиентский режимы работы. Теперь можно ускорить сканирование данных запустив metacrafter как сервер и обращаясь к нему через параметр remote при вызовах сканирования файлов или баз данных. Это важно для ускорения процесса поскольку правила инициализируются только один раз
- добавилась команда просмотра правил 'metacrafter rules list'
- и так далее
Главный недостаток сейчас - это скорость работы на больших датасетах. Чем больше колонок тем дольше анализ, до нескольких минут. Это не так критично для задач вроде сканирования корпоративных СУБД, но тяжко для задач Dateno когда миллионы датасетов.
На самом деле чтобы всё ускорить нужно просто много ресурсов: процессорных, хранения и памяти. А прикрутив LLM'ку можно сильно повысить качество автодокументирования данных.
Понимание данных, автодокументирование датасетов, автоматизация анализа данных - это одни из наиболее любимых мной тем в дата инженерии и дата анализе. Жаль удаётся уделять немного времени.
Ссылки:
[1] https://github.com/apicrafter/metacrafter/
[2] https://github.com/apicrafter/metacrafter-rules/
#opensource #data #datatools #dateno #metacrafter
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