Ivan Begtin
8.03K subscribers
1.73K photos
3 videos
101 files
4.43K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech
Download Telegram
Росводресурсы открыли прототип системы "Водные данные" [1] о чем публикация на сайте Минприроды РФ [2].

Сам ресурс содержит сведения о:
- Водохозяйственных участках
- Водных объектах
- Водопользовании
- ГМВО (Государственном мониторинге водных объектов)

Кроме того доступны API для получения данных по формам ГВР [3], а данные в форме открытых данных доступны как CSV файлы и с цифровой подписью.

Если кратко резюмировать, то по форме представления данных всё выглядит довольно прилично.

А если немного углубиться в детали, то есть на что обратить внимание:
1. Нет такого понятия как ЭЦП в российском законодательстве уже давно, есть электронная подпись (ЭП) и она точно реализуется иначе и должна быть проверяема, например, через сервис на портале госуслуг. Сейчас эта проверка не проходит.
2. Хотя на сайте есть паспорта набора данных там нет ничего про метаданные. То есть паспорта сделаны не по метод рекомендациям опубликованным на data.gov.ru которые, хотя и весьма и весьма неидеальны, но даже их не соблюдают.
3. В том числе отсутствуют метаднные по структуре полей наборов данных. Иначе говоря данные есть, документации к ним нет.
4. Документация к API есть, но почему-то, не в формате Swagger, а просто HTML описанием без примеров.
5. Наборы данных опубликованы все через ajax, как следствие ни у одного набора данных нет отдельной веб страницы, они не будут находиться поисковыми системами.

Это было про форму публикации данных, а теперь про их качество и полноту:
- не все наборы данных опубликованы, по некоторым открываются пустые файлы. Например, набор данных " Данные о состоянии гидротехнических сооружений, находящихся в собственности" в разделе ГВМО пустой (обратите внимание что я не могу дать ссылку на сам набор потому что сайт так сделан)
- данные смешаны и в одном поле публикуется то что должно быть разделено на несколько полей для удобного поиска. Например, в данных по форме ГВР 2-6 есть поле owner_person, которое совсем не про владельца физ. лица, а про сведения о любом владельце и содержат наименование организации или физ. лица, адрес местонахождения и ИНН. Все вместе, хотя в большинстве реестров эти данные разделяют на 3 поля минимум, а максимум ещё и декомпозируют адрес и добавляют ему коды ОКАТО или ОКТМО.
- в опубликованных данных есть неполное заполнение данных. Всё в тех же данных по форме ГВР 2-6 есть 46 867 записей из которых код ИНН отсутствует у 4259, около 9% записей. Что означает что для сопоставления объекта водопользования с юр лицом придется выяснять ИНН юр. лица.
- даже в тех случаях когда ИНН указан, проверка показывает что в 507 случаях код указан с ошибкой, по некоторым кодам, очевидно сразу что они вводились как неверные. Например: часто встречается указание кода 7600000000 в отношении водопользователей Ярэнерго и других юр лиц. Что это означает? Что в системе(-ах) Росводресурсов нет форматно-логического контроля и данные вводятся с ошибками. И это только по самым очевидным случаям поддающимся автоматическому анализу, а многое можно понять уже создавать правила проверки под конкреный источник данных.

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

Ссылки:
[1] https://gis.favr.ru/web/guest/opendata
[2] https://www.mnr.gov.ru/press/news/rosvodresursy_otkryli_vodnye_dannye/
[3] https://gis.favr.ru/external-api

#dataquality #opendata #waterdata #voda
В феврале я писал о том что федеральные органы власти очень халтурно публикуют данные из информационных систем в их ведении. Причём на фоне разговоров про цифровую трансформацию - это всё несколько комично.

Например, в феврале этого года я писал [1] про то что Минцифра очень халатно относится к ведению реестра аккредитованных ИТ компаний и не обновляли его 5 лет. Как думаете что произошло? Его начали обновлять и даже обновили в марте, апреле и в мае, а потом на него забили и не обновляли аж до августа месяца. А то что опубликовали в августе [2], а то что опубликовано вместо кодов ОГРН значения вроде "1,05E+12". Как так получается? Так получается когда экспорт данных делают: а) Из Excel. б) Без знания Excel. в) Не перепроверяют.

Буду краток: работа халатная, сроки нарушены, данные непригодны.

P.S. В реестре в Excel тоже есть ошибки и их, ожидаемо, не исправили.

Ссылки:
[1] https://t.me/begtin/2595
[2] https://digital.gov.ru/opendata/7710474375-registergosaccred/download/

#opendata #dataquality
Интересные стартапы анализа качества данных и качества потоков данных, развивающиеся в мире, но пока малоприменимые в России.

* Metaplane - позиционируют себя как Datadog для данных, позводяют отслеживать резкие изменения в потоках данных и предупреждать при их возникновении. Подключаются к облачным хранилищам и сервисам вроде Amazon Redshift, Snowflake, Google BigQuery, dbt, Looker. Публикуют полезный обзор State of data quality monitoring
* Anomalo - сервис мониторинга аномалий в данных, на текущий момент существует в виде концепта/прототипа/демо, обещают высокую автоматизацию, если даже не автоматическое выявление аномалий в потоках данных
* Data Fold - сервис каталогизации, систематизации данных и предупреждений при нарушениях в потоках данных. У них фокус на такое явление как data outages - задержки в поставках данных и оперативное реагирование. Сервисы с которыми интегрируются практически те же что и у Metaplane
* Databand - платформа для наблюдаемости данных, data observability, с большим списком интегрируемых сервисов и системами предупреждений при аномалиях

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

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

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

Я от себя добавлю что часто инструменты контроля качества данных сильно замедляют работу с данными если они не оптимизированы. К примеру Soda-SQL и Great Expectations, скажем так, имеют большие возможности по их ускорению, потому про по умолчанию заложенные там проверки через регулярные выражения можно сильно оптимизировать. К примеру, решая похожие задачи по классификации данных в DataCrafter'е, могу сказать что там вообще нет регулярных выражений, но и нет жесткой закодированности идентифицирующих типы данных правил. Вместо них некий аналог RegExp'ов работающий многократно быстрее.

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

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

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

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

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

#dataquality #data #reading #dataengineering #metadata #dataproducts
Команда Superconductive стоящая за Great Expecations open source продуктом по контролю качества данных подняла $40M инвестиций на создание облачного продукта [1]

Можно сказать что у инструментов работы с данными просто заметнейший тренд на то что вначале команды создают востребованное open source ПО, а потом берут инвестиции на облачную версию.

Главное, я напомню, не забывать судьбу CloverETL которые начинали с open source продукта, а потом убили его ради корпоративной версии и таких примеров в настольном и сервером ПО немало, а у open source + облачного другие особенности, главная из которых в том что авторы часто потом добавляют в open source решение зависимость от своей облачной инфраструктуры.

Ссылки:
[1] https://techcrunch.com/2022/02/10/superconductive-creators-of-great-expectations-raises-40m-to-launch-a-commercial-version-of-its-open-source-data-quality-tool/

#opensource #dataquality #startups #investments
Кажется я ещё ни разу об этом не писал, о том как сопоставить метрики качества данных используемые в 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
Когда много пишешь всегда наступает момент когда надо систематизировать написанное.

Я собрал мои тексты про информатизацию государства, открытые государственные данные, качество госданных, государственные финансы, государственную политику и т.д. в одну большую подборку в рассылке [1].

Там только большие тексты, без учёта опубликованного в этом телеграм канале, в фэйсбуке и тд. Тексты вышедшие колонками в Ведомостях, Forbes, РБК и в моих блоге и в рассылке. Я мог упустить колонки в других изданиях, но большую часть материалов должен быть охватить.

Полезного чтения!

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

#opendata #government #policy #dataquality #govfinances
Хороший обзор прослеживаемости данных (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
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
Сбербанк социально ориентированная НКО?

Я тут много ругался в адрес Минцифры что они в реестр ИТ компаний навключали всяких и они вроде как даже этот реестр начали чистить.

Но, конечно, есть примеры и похуже. В плане управления качеством данных есть органы власти для которых делать плохо или неправильно - это норма. 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
Интересные стартапы по дата инженерии։
- 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.me/begtin/4532

#startups #data #dataquality #git #dataengineering
Полезное чтение про данные, технологии и не только։

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
Любопытное про стартапы на данных:
- 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
Я в своих выступлениях про поисковик по данным Dateno рассказывал про то что один из приоритетов его развития - это повышение качества данных.

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

Вот пример одной из практических задач. В Dateno сейчас 3383 типа форматов файлов, но, в реальности, это лишь 129 форматов, потому что пользователи указывают в полях типа file format что попало, часто с ошибками. Помимо того что есть указания по которым вообще нельзя понять что это за файл, так есть ещё и много форм написания расширений и типов. На скриншотах примеры с форматами и расширениями которые приходится приводить в порядок, сейчас, полувручную. Похожая ситуация с типами MIME, они очень даже активно заполняются с ошибками, хотя, казалось бы, так быть не должно.

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

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

Потому что, например, определение форматов и типов mime относительно хорошо можно делать по содержанию файла, но скачивание всех-всех файлов для поисковика является весьма дорогостоящей задачей, и с точки зрения трафика и с точки зрения ресурсов.

#dateno #data #howitworks #datasearch #dataquality