Кажется я ещё ни разу об этом не писал, о том как сопоставить метрики качества данных используемые в 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
June 25, 2022
Когда много пишешь всегда наступает момент когда надо систематизировать написанное.
Я собрал мои тексты про информатизацию государства, открытые государственные данные, качество госданных, государственные финансы, государственную политику и т.д. в одну большую подборку в рассылке [1].
Там только большие тексты, без учёта опубликованного в этом телеграм канале, в фэйсбуке и тд. Тексты вышедшие колонками в Ведомостях, Forbes, РБК и в моих блоге и в рассылке. Я мог упустить колонки в других изданиях, но большую часть материалов должен быть охватить.
Полезного чтения!
Ссылки:
[1] https://begtin.substack.com/p/29
#opendata #government #policy #dataquality #govfinances
Я собрал мои тексты про информатизацию государства, открытые государственные данные, качество госданных, государственные финансы, государственную политику и т.д. в одну большую подборку в рассылке [1].
Там только большие тексты, без учёта опубликованного в этом телеграм канале, в фэйсбуке и тд. Тексты вышедшие колонками в Ведомостях, Forbes, РБК и в моих блоге и в рассылке. Я мог упустить колонки в других изданиях, но большую часть материалов должен быть охватить.
Полезного чтения!
Ссылки:
[1] https://begtin.substack.com/p/29
#opendata #government #policy #dataquality #govfinances
August 13, 2022
Хороший обзор прослеживаемости данных (data lineage) [1] от Borja Vazquez из Monzo Bank
Прослеживаемость данных - это важная тема, актуальная особенно в корпоративной развитой аналитике и в научной среде, где важна достоверность результатов, или, хотя бы понимаемые уровни отклонения, и важна воспроизводимость результатов. Воспроизводимость результатов особенно актуальна при публикации научных работ, связанных с ними данных и тд.
Автор делает акцент на картографии данных в разных разрезах - пользовательского использования, качества данных, производительности и тд. в разных формах картографии данных, в основном вокруг DAG (directed acyclic graph) и потоков обработки данных.
Текст короткий, постановка проблем и подходов вполне понятные.
Когда-то я также активно занимался картированием данных, в основном для задач, обнаружения данных (data discovery).
Это другой подход, его задача идентифицировать основные источники данных в целях:
а) Внутреннего аудита
б) Создания дата-продукта
В итоге вместо того чтобы многие карты данных мы собрали общедоступные источники данных в datacatalogs.ru [2]
Ключевая разница между картографией данных на уровне прослеживаемости и картами данных для их обнаружения - в зрелости объектов анализа. В корпоративном мире, как правило, есть возможность влиять на потоки данных, источники данных, процедуры и тд. Ключевой вопрос: "Где проблемы? Как организовать процесс чтобы решать проблемы оперативно?"
В работе с открытыми источниками ключевые вопросы: "Как найти источник? Как получить к нему доступы?"
Ссылки:
[1] https://medium.com/data-monzo/the-many-layers-of-data-lineage-2eb898709ad3
[2] https://datacatalogs.ru
#data #dataquality #datamaps #opendata #datalineage
Прослеживаемость данных - это важная тема, актуальная особенно в корпоративной развитой аналитике и в научной среде, где важна достоверность результатов, или, хотя бы понимаемые уровни отклонения, и важна воспроизводимость результатов. Воспроизводимость результатов особенно актуальна при публикации научных работ, связанных с ними данных и тд.
Автор делает акцент на картографии данных в разных разрезах - пользовательского использования, качества данных, производительности и тд. в разных формах картографии данных, в основном вокруг DAG (directed acyclic graph) и потоков обработки данных.
Текст короткий, постановка проблем и подходов вполне понятные.
Когда-то я также активно занимался картированием данных, в основном для задач, обнаружения данных (data discovery).
Это другой подход, его задача идентифицировать основные источники данных в целях:
а) Внутреннего аудита
б) Создания дата-продукта
В итоге вместо того чтобы многие карты данных мы собрали общедоступные источники данных в datacatalogs.ru [2]
Ключевая разница между картографией данных на уровне прослеживаемости и картами данных для их обнаружения - в зрелости объектов анализа. В корпоративном мире, как правило, есть возможность влиять на потоки данных, источники данных, процедуры и тд. Ключевой вопрос: "Где проблемы? Как организовать процесс чтобы решать проблемы оперативно?"
В работе с открытыми источниками ключевые вопросы: "Как найти источник? Как получить к нему доступы?"
Ссылки:
[1] https://medium.com/data-monzo/the-many-layers-of-data-lineage-2eb898709ad3
[2] https://datacatalogs.ru
#data #dataquality #datamaps #opendata #datalineage
September 3, 2022
This media is not supported in your browser
VIEW IN TELEGRAM
Свежий интересный проект с открытым кодом по мониторингу качества данных Elementary Data [1] изначально собранный через интеграцию с dbt и возможность мониторинга данных в хранилищах данных.
Формирует отчеты по наблюдению за данными (data observability report) на основе проведенных тестов.
Как я понимаю, собираются монетизироваться через облачный сервис, который сейчас готовится к бета тестированию.
Построить контроль качества данных на основе dbt - это актуальная задумка, будет актуальна для многих задач и сред. Главный минус - отсутствие поддержки NoSQL потому что NoSQL нет в dbt.
Впрочем инструмент интересный, надо пробовать.
Ссылки:
[1] https://www.elementary-data.com/
#opensource #datatools #dataquality
Формирует отчеты по наблюдению за данными (data observability report) на основе проведенных тестов.
Как я понимаю, собираются монетизироваться через облачный сервис, который сейчас готовится к бета тестированию.
Построить контроль качества данных на основе dbt - это актуальная задумка, будет актуальна для многих задач и сред. Главный минус - отсутствие поддержки NoSQL потому что NoSQL нет в dbt.
Впрочем инструмент интересный, надо пробовать.
Ссылки:
[1] https://www.elementary-data.com/
#opensource #datatools #dataquality
September 8, 2022
Сбербанк социально ориентированная НКО?
Я тут много ругался в адрес Минцифры что они в реестр ИТ компаний навключали всяких и они вроде как даже этот реестр начали чистить.
Но, конечно, есть примеры и похуже. В плане управления качеством данных есть органы власти для которых делать плохо или неправильно - это норма. 2 года назад я писал колонку в РБК [1] о том что Минэкономразвития отвратительно ведёт реестр социально ориентированных организаций. Они даже валидацию реквизитов ИНН/ОГРН не проводили. Прошло 2 года, валидацию они поправили, новое постановление Пр-ва N 1290 выпустили и, стало ли лучше ?
Короткий ответ - нет. Качество данных - это не только качество формы, но и содержания. В реестре социально ориентированных НКО всего 45+ тысяч организаций и там есть не только Сбербанк, но и:
- 288 НКО учрежденных федеральными органами власти и госорганизациями (госНКО)
- 336 НКО учрежденных региональными органами власти (госНКО)
- 314 НКО учрежденных муниципальными органами власти (почти госНКО, с некоторой натяжкой)
- 34 муниципальных учреждения
- Московское областное отделение КПРФ (а как же остальные отделения, не социально ориентированы?)
- 3 региональных министерства и 3 региональных бюджетных учреждения.
Мне есть что про это всё сказать, но скорее я напишу. Последний месяц работаю над книжкой по госНКО. Поднял свои старые записки и хочу привести текст к эпистолярному жанру. К сожалению, многие источники данных уже исчезли из открытого доступа, но и оставшихся достаточно для интересного рассказа.
А за Сбербанк, лично мне, конечно, очень тревожно. То ИТ компания, то СОНКО, неужели всё так плохо?
Ссылки:
[1] https://www.rbc.ru/newspaper/2020/06/19/5ee8ce139a79479edce77585
[2] https://data.economy.gov.ru/analytics/sonko
#registry #data #dataquality #ngo
Я тут много ругался в адрес Минцифры что они в реестр ИТ компаний навключали всяких и они вроде как даже этот реестр начали чистить.
Но, конечно, есть примеры и похуже. В плане управления качеством данных есть органы власти для которых делать плохо или неправильно - это норма. 2 года назад я писал колонку в РБК [1] о том что Минэкономразвития отвратительно ведёт реестр социально ориентированных организаций. Они даже валидацию реквизитов ИНН/ОГРН не проводили. Прошло 2 года, валидацию они поправили, новое постановление Пр-ва N 1290 выпустили и, стало ли лучше ?
Короткий ответ - нет. Качество данных - это не только качество формы, но и содержания. В реестре социально ориентированных НКО всего 45+ тысяч организаций и там есть не только Сбербанк, но и:
- 288 НКО учрежденных федеральными органами власти и госорганизациями (госНКО)
- 336 НКО учрежденных региональными органами власти (госНКО)
- 314 НКО учрежденных муниципальными органами власти (почти госНКО, с некоторой натяжкой)
- 34 муниципальных учреждения
- Московское областное отделение КПРФ (а как же остальные отделения, не социально ориентированы?)
- 3 региональных министерства и 3 региональных бюджетных учреждения.
Мне есть что про это всё сказать, но скорее я напишу. Последний месяц работаю над книжкой по госНКО. Поднял свои старые записки и хочу привести текст к эпистолярному жанру. К сожалению, многие источники данных уже исчезли из открытого доступа, но и оставшихся достаточно для интересного рассказа.
А за Сбербанк, лично мне, конечно, очень тревожно. То ИТ компания, то СОНКО, неужели всё так плохо?
Ссылки:
[1] https://www.rbc.ru/newspaper/2020/06/19/5ee8ce139a79479edce77585
[2] https://data.economy.gov.ru/analytics/sonko
#registry #data #dataquality #ngo
September 12, 2022
Интересные стартапы по дата инженерии։
- Seek AI [1] позиционируют себя как Generative AI for Data. Ты формулируешь запрос/вопрос на аналитику общими словами, а они используют ИИ для генерации ответа. Привлекли $7.5m инвестиций в этом январе [2], очень интересно что будет их итоговым продуктом потому что общедоступной информации маловато.
- Metaplane [3] платформа для мониторинга данных включая базы данных, трубы данных, источники и тд. Позиционируют себя как Datadog for data. Позиционирование довольно грамотное, для облачной дата инфраструктуры это актуально начиная со средних размеров компаний. Привлекли $8.4m инвестиций в последнем раунде в этом январе [4]. Таких проектов всё больше, с разными акцентами и шансами на выживаемость. Делать аналог Datadog кажется вполне разумной затеей.
- XetData [5] ещё один проект Git для данных, с поддержкой версионности и git-подобного режима доступа к данным. Акценты делают на обучении моделей работы с данными, возможности исследования данных (data exploration) и на эффективной дедупликации данных с сильным сжатием оригинальных данных. Привлекли $7.5m инвестиций. Выглядят интересно, но это лишь ещё один проект "git for data" вроде тех о которых я писал недавно [7]. ИМХО, в этой области модель github'а не сработает, потому что код давно уже гораздо больше подходит под общественное достояние, а данные являются объектами монетизации. Скорее востребовано должна быть модель Gitlab для данных, с возможность делать свои инстансы бесплатно или за небольшие деньги и управлять хранилищем данных подключая разные опции. А сервисы вроде XetData или того же Dolt(-а) больше напоминают сервисы очень специализированного хостинга с монетизацией за гигабайт/терабайт и каналы доступа.
Ссылки։
[1] https://www.seek.ai
[2] https://www.seek.ai/press-01-11-23
[3] https://www.metaplane.dev
[4] https://www.metaplane.dev/blog/the-next-stage-of-metaplane
[5] https://xetdata.com
[6] https://xetdata.com/blog/2022/12/13/introducing-xethub/
[7] https://t.iss.one/begtin/4532
#startups #data #dataquality #git #dataengineering
- Seek AI [1] позиционируют себя как Generative AI for Data. Ты формулируешь запрос/вопрос на аналитику общими словами, а они используют ИИ для генерации ответа. Привлекли $7.5m инвестиций в этом январе [2], очень интересно что будет их итоговым продуктом потому что общедоступной информации маловато.
- Metaplane [3] платформа для мониторинга данных включая базы данных, трубы данных, источники и тд. Позиционируют себя как Datadog for data. Позиционирование довольно грамотное, для облачной дата инфраструктуры это актуально начиная со средних размеров компаний. Привлекли $8.4m инвестиций в последнем раунде в этом январе [4]. Таких проектов всё больше, с разными акцентами и шансами на выживаемость. Делать аналог Datadog кажется вполне разумной затеей.
- XetData [5] ещё один проект Git для данных, с поддержкой версионности и git-подобного режима доступа к данным. Акценты делают на обучении моделей работы с данными, возможности исследования данных (data exploration) и на эффективной дедупликации данных с сильным сжатием оригинальных данных. Привлекли $7.5m инвестиций. Выглядят интересно, но это лишь ещё один проект "git for data" вроде тех о которых я писал недавно [7]. ИМХО, в этой области модель github'а не сработает, потому что код давно уже гораздо больше подходит под общественное достояние, а данные являются объектами монетизации. Скорее востребовано должна быть модель Gitlab для данных, с возможность делать свои инстансы бесплатно или за небольшие деньги и управлять хранилищем данных подключая разные опции. А сервисы вроде XetData или того же Dolt(-а) больше напоминают сервисы очень специализированного хостинга с монетизацией за гигабайт/терабайт и каналы доступа.
Ссылки։
[1] https://www.seek.ai
[2] https://www.seek.ai/press-01-11-23
[3] https://www.metaplane.dev
[4] https://www.metaplane.dev/blog/the-next-stage-of-metaplane
[5] https://xetdata.com
[6] https://xetdata.com/blog/2022/12/13/introducing-xethub/
[7] https://t.iss.one/begtin/4532
#startups #data #dataquality #git #dataengineering
January 16, 2023
Полезное чтение про данные, технологии и не только։
Why I moved my dbt workloads to GitHub and saved over $65,000 [1] автор пишет о том что заменил облако dbt (продукт dbt cloud) на Github Actions и сэкономил много денег. Правда в комментариях ему пишут что мол автор, это же очевидно. Но про несколько важных выводом можно вспомнить։
1) Github - это теперь в первую очередь система управления разработкой и автоматизации задач и лишь во вторую хранилище кода. Как минимум с точки зрения бизнес модели.
2) Крупные инфраструктурные игроки могут достаточно легко подорвать бизнес open source сервисов вроде dbt, просто предлагая то же сильно дешевле. Кстати, пример с конфликтом лицензий Elastic тоже был из той же природы, когда Amazon давали аналогичный сервис значительно дешевле
The State of Data Testing [2] обзор состояния задач и подходов к тестированию данных. Автор сотрудник компании Datafold и текст в их блоге. Поскольку компания как раз на тестировании данных специализируется, то и акценты на их компетенциях. С другой стороны все перечисленные подходы действительно есть, а их data-diff [3] полезный продукт с открытым кодом для сравнения таблиц. Почему подходы не полны? Это всё та же ситуация с управляемыми и неуправляемыми источниками данных. Задачи корпоративной дата-инженерии чаще всего сводятся к работе с управляемыми источниками или в возможности воздействия на них в случаях ошибок в данных. Работа с общедоступными данными слишком часто означает ненадёжность источника, невозможность повлиять на качество данных привычными методами.
Ссылки:
[1] https://medium.com/@datajuls/why-i-moved-my-dbt-workloads-to-github-and-saved-over-65-000-759b37486001
[2] https://www.datafold.com/blog/the-state-of-data-testing
[3] https://github.com/datafold/data-diff
#data #readings #dataengineering #dataquality
Why I moved my dbt workloads to GitHub and saved over $65,000 [1] автор пишет о том что заменил облако dbt (продукт dbt cloud) на Github Actions и сэкономил много денег. Правда в комментариях ему пишут что мол автор, это же очевидно. Но про несколько важных выводом можно вспомнить։
1) Github - это теперь в первую очередь система управления разработкой и автоматизации задач и лишь во вторую хранилище кода. Как минимум с точки зрения бизнес модели.
2) Крупные инфраструктурные игроки могут достаточно легко подорвать бизнес open source сервисов вроде dbt, просто предлагая то же сильно дешевле. Кстати, пример с конфликтом лицензий Elastic тоже был из той же природы, когда Amazon давали аналогичный сервис значительно дешевле
The State of Data Testing [2] обзор состояния задач и подходов к тестированию данных. Автор сотрудник компании Datafold и текст в их блоге. Поскольку компания как раз на тестировании данных специализируется, то и акценты на их компетенциях. С другой стороны все перечисленные подходы действительно есть, а их data-diff [3] полезный продукт с открытым кодом для сравнения таблиц. Почему подходы не полны? Это всё та же ситуация с управляемыми и неуправляемыми источниками данных. Задачи корпоративной дата-инженерии чаще всего сводятся к работе с управляемыми источниками или в возможности воздействия на них в случаях ошибок в данных. Работа с общедоступными данными слишком часто означает ненадёжность источника, невозможность повлиять на качество данных привычными методами.
Ссылки:
[1] https://medium.com/@datajuls/why-i-moved-my-dbt-workloads-to-github-and-saved-over-65-000-759b37486001
[2] https://www.datafold.com/blog/the-state-of-data-testing
[3] https://github.com/datafold/data-diff
#data #readings #dataengineering #dataquality
Medium
Why I moved my dbt workloads to GitHub and saved over $65,000
What is dbt Cloud?
January 22, 2023
Любопытное про стартапы на данных:
- Collibbra приобрели стартап по созданию SQL тетрадок Huspray [1] учитывая что основной бизнес Collibra это корпоративные каталоги данных, причём изначально с сильным акцентом на выявление персональных данных, то эта покупка про сдвиг приоритетов на дата аналитиков.
- Treefera подняли pre-seed $2.2 миллиона инвестиций на дата-платформу по мониторингу лесного покрова [2], внутри обещают ИИ и создание data продуктов
- DataBricks получили ещё $500 миллионов инвестиций в рамках Series I [3], пишут что это скорее всего раунд перед IPO и на IPO оценка может достигнуть $43 миллиардов.
- Gable получил $7 миллионов на seed стадии [4] - Gable это стартап по повышению качества данных через применение data contracts. Тут так и хочется спросить "а что так можно было?!", стартап явно под экосистему работы с данными в Modern data stack и под последующую покупку одним из крупных платформенных игроков.
Ссылки:
[1] https://www.collibra.com/us/en/company/newsroom/press-releases/collibra-acquires-sql-data-notebook-vendor-husprey
[2] https://www.treefera.com/blog/treefera-pre-seed-funding-round
[3] https://techcrunch.com/2023/09/14/databricks-raises-500m-more-boosting-valuation-to-43b-despite-late-stage-gloom/
[4] https://www.linkedin.com/feed/update/urn:li:activity:7107413267072917504/
#startups #data #dataquality
- Collibbra приобрели стартап по созданию SQL тетрадок Huspray [1] учитывая что основной бизнес Collibra это корпоративные каталоги данных, причём изначально с сильным акцентом на выявление персональных данных, то эта покупка про сдвиг приоритетов на дата аналитиков.
- Treefera подняли pre-seed $2.2 миллиона инвестиций на дата-платформу по мониторингу лесного покрова [2], внутри обещают ИИ и создание data продуктов
- DataBricks получили ещё $500 миллионов инвестиций в рамках Series I [3], пишут что это скорее всего раунд перед IPO и на IPO оценка может достигнуть $43 миллиардов.
- Gable получил $7 миллионов на seed стадии [4] - Gable это стартап по повышению качества данных через применение data contracts. Тут так и хочется спросить "а что так можно было?!", стартап явно под экосистему работы с данными в Modern data stack и под последующую покупку одним из крупных платформенных игроков.
Ссылки:
[1] https://www.collibra.com/us/en/company/newsroom/press-releases/collibra-acquires-sql-data-notebook-vendor-husprey
[2] https://www.treefera.com/blog/treefera-pre-seed-funding-round
[3] https://techcrunch.com/2023/09/14/databricks-raises-500m-more-boosting-valuation-to-43b-despite-late-stage-gloom/
[4] https://www.linkedin.com/feed/update/urn:li:activity:7107413267072917504/
#startups #data #dataquality
Collibra
Collibra Acquires SQL Data Notebook Vendor Husprey
Collibra, the Data Intelligence company, today announced the acquisition of Husprey, a leading integrated SQL data notebook platform.
September 19, 2023
Я в своих выступлениях про поисковик по данным Dateno рассказывал про то что один из приоритетов его развития - это повышение качества данных.
Причём, чтобы было понятно, качество данных и их описания, метаданных, подавляющего числа порталов открытых данных плохое. Иногда совсем плохое - чаще, реже среднее, но очень хорошее - это огромная редкость. Причём почти всегда это качество является отражением того что с ним работают люди которые вручную вносят файлы и заполняют описание.
Вот пример одной из практических задач. В Dateno сейчас 3383 типа форматов файлов, но, в реальности, это лишь 129 форматов, потому что пользователи указывают в полях типа file format что попало, часто с ошибками. Помимо того что есть указания по которым вообще нельзя понять что это за файл, так есть ещё и много форм написания расширений и типов. На скриншотах примеры с форматами и расширениями которые приходится приводить в порядок, сейчас, полувручную. Похожая ситуация с типами MIME, они очень даже активно заполняются с ошибками, хотя, казалось бы, так быть не должно.
Поэтому большая часть работы над поисковиком - это обогащение данных, повышение качества их описания, извлечение метаданных из самих данных и многое другое для нормализации описания каждого датасета.
На скриншотах можно увидеть проверку в OpenRefine автоматически размеченных форматов и типов mime по одному из снапшотов базы Dateno. И это с оговоркой что сейчас проиндексированы далеко не самые "грязные" каталоги данных. Скорее всего ситуация будет сильно хуже с форматами когда начнём индексировать большие каталоги научных данных. Вот тут, конечно, хотелось бы найти инструмент который бы всё это делал без участия человека, но такого не наблюдается.
Потому что, например, определение форматов и типов mime относительно хорошо можно делать по содержанию файла, но скачивание всех-всех файлов для поисковика является весьма дорогостоящей задачей, и с точки зрения трафика и с точки зрения ресурсов.
#dateno #data #howitworks #datasearch #dataquality
Причём, чтобы было понятно, качество данных и их описания, метаданных, подавляющего числа порталов открытых данных плохое. Иногда совсем плохое - чаще, реже среднее, но очень хорошее - это огромная редкость. Причём почти всегда это качество является отражением того что с ним работают люди которые вручную вносят файлы и заполняют описание.
Вот пример одной из практических задач. В Dateno сейчас 3383 типа форматов файлов, но, в реальности, это лишь 129 форматов, потому что пользователи указывают в полях типа file format что попало, часто с ошибками. Помимо того что есть указания по которым вообще нельзя понять что это за файл, так есть ещё и много форм написания расширений и типов. На скриншотах примеры с форматами и расширениями которые приходится приводить в порядок, сейчас, полувручную. Похожая ситуация с типами MIME, они очень даже активно заполняются с ошибками, хотя, казалось бы, так быть не должно.
Поэтому большая часть работы над поисковиком - это обогащение данных, повышение качества их описания, извлечение метаданных из самих данных и многое другое для нормализации описания каждого датасета.
На скриншотах можно увидеть проверку в OpenRefine автоматически размеченных форматов и типов mime по одному из снапшотов базы Dateno. И это с оговоркой что сейчас проиндексированы далеко не самые "грязные" каталоги данных. Скорее всего ситуация будет сильно хуже с форматами когда начнём индексировать большие каталоги научных данных. Вот тут, конечно, хотелось бы найти инструмент который бы всё это делал без участия человека, но такого не наблюдается.
Потому что, например, определение форматов и типов mime относительно хорошо можно делать по содержанию файла, но скачивание всех-всех файлов для поисковика является весьма дорогостоящей задачей, и с точки зрения трафика и с точки зрения ресурсов.
#dateno #data #howitworks #datasearch #dataquality
March 19, 2024
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
November 13, 2024
Свежий интересный продукт по контролю качества данных DQX - Data Quality Framework от Databricks Labs [1].
Плюсы:
- зрелость поскольку Databricks один из лидеров рынка дата инженерии
- хорошая документация, судя по первому взгляду
- декларативное описание тестов в YAML (тут очень субъективно)
- интегрированность и заточенность на работу с Apache Spark
- открытый код на Github
Минусы:
- зависимость от Databricks Workspace в их дата каталоге Unity
- код открыт но лицензия несвободная, а специальная Databricks License с ограничениями [2], вполне возможно внешних контрибьюторов это оттолкнёт
Он очень напоминает движок Soda [3] который тоже даёт возможность декларативного описания тестов, но ещё более заточенный на их облачный сервис и который бесплатен только в рамках 45 дней тестирования. Можно пользоваться из Soda Core, правда, который под лицензией Apache 2.0
Итоговая ситуация такова что из частично открытых остались только движки Soda и great_expectations [4] который также стремительно коммерциализируется, но вроде как его команда обещала сохранить продукт GX Core под лицензией Apache 2.0 и развивать его, но как бы не закончилось также как с Elasticsearch и MongoDB, со сменой лицензии или тем что новые ключевые возможности будут только в облачных сервисах.
А DQX продукт интересный, но хотелось бы то же самое, но без вот этого вот всего (с).
Итого я могу сказать что есть заметный дефицит инструментов контроля качества данных. Сейчас нет ни одного подобного продукта под лицензией MIT, с простой интеграцией и, желательно, декларативным описанием тестов.
Поляна инструментов контроля качества данных совершенно точно заполнена не до конца и "рулят" на нём продукты в гибридном состоянии открытого кода и SaaS платформ.
Ссылки:
[1] https://databrickslabs.github.io/dqx/
[2] https://github.com/databrickslabs/dqx?tab=License-1-ov-file#readme
[3] https://github.com/sodadata/soda-core
[4] https://github.com/great-expectations/great_expectations
#opensource #dataquality #datatools
Плюсы:
- зрелость поскольку Databricks один из лидеров рынка дата инженерии
- хорошая документация, судя по первому взгляду
- декларативное описание тестов в YAML (тут очень субъективно)
- интегрированность и заточенность на работу с Apache Spark
- открытый код на Github
Минусы:
- зависимость от Databricks Workspace в их дата каталоге Unity
- код открыт но лицензия несвободная, а специальная Databricks License с ограничениями [2], вполне возможно внешних контрибьюторов это оттолкнёт
Он очень напоминает движок Soda [3] который тоже даёт возможность декларативного описания тестов, но ещё более заточенный на их облачный сервис и который бесплатен только в рамках 45 дней тестирования. Можно пользоваться из Soda Core, правда, который под лицензией Apache 2.0
Итоговая ситуация такова что из частично открытых остались только движки Soda и great_expectations [4] который также стремительно коммерциализируется, но вроде как его команда обещала сохранить продукт GX Core под лицензией Apache 2.0 и развивать его, но как бы не закончилось также как с Elasticsearch и MongoDB, со сменой лицензии или тем что новые ключевые возможности будут только в облачных сервисах.
А DQX продукт интересный, но хотелось бы то же самое, но без вот этого вот всего (с).
Итого я могу сказать что есть заметный дефицит инструментов контроля качества данных. Сейчас нет ни одного подобного продукта под лицензией MIT, с простой интеграцией и, желательно, декларативным описанием тестов.
Поляна инструментов контроля качества данных совершенно точно заполнена не до конца и "рулят" на нём продукты в гибридном состоянии открытого кода и SaaS платформ.
Ссылки:
[1] https://databrickslabs.github.io/dqx/
[2] https://github.com/databrickslabs/dqx?tab=License-1-ov-file#readme
[3] https://github.com/sodadata/soda-core
[4] https://github.com/great-expectations/great_expectations
#opensource #dataquality #datatools
January 22
Есть задачи для которых LLM совсем не годятся, а есть те которые годятся очень даже. Например, есть довольно узкая, но очень частая задача автоматического документирования данных.
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation
January 29