Стартап Anomalo [1] специализируется на автоматизации проверки качества данных, как автоматически, так и через специально подготовленные правила проверки данных. Главный акцент в проверке и документировании данных без написания кода. Сам продукт пока недоступен, есть только скриншоты и анонсы в блоге. А также новость от 17 декабря о получении стартапом первых инвестиций в $5.95 миллионов [2].

Ключевое ноу-хау - это искусственный интеллект пишущий правила для проверки данных.

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

Ссылки:
[1] https://www.anomalo.com/
[2] https://news.crunchbase.com/news/anomalo-raises-5-95m-to-validate-data/

#data #dataquality

Я всё искал живые примеры того как хорошо/плохо построена работа с данными и сколько иллюзий у граждан/бизнеса/пользователей. Многие, например, думают что госорганизации публикуют плохие данные специально, а где-то внутри и тайно хранят и используют хорошие. Такое бывает очень редко, а чаще миром правит худоумие, а не хитроумие. О многих историях об этом написать нельзя по разным причинам, но о каких-то публичных и общедоступных более чем необходимо.

Рассмотрим пример, Центр по лицензированию, сертификации и защите государственной тайны ФСБ России [1] в открытом доступе публикует 4 реестра [2], все в формате .docx файлов:
- Реестр лицензий на деятельность, связанную с шифровальными (криптографическими) средствами
- Реестр лицензий на деятельность по разработке и производству средств защиты конфиденциальной информации
- Реестр лицензий на деятельность по выявлению электронных устройств
- Реестр лицензий на деятельность, связанную с оборотом СТС

Среди них, первый реестр, лицензий на деятельность, связанную с шифровальными (криптографическими) средствами - это файл MS Word (.docx) состоящий из одной таблицы в 1985 страниц и 4880 записи. Алексей Лукацкий ранее писал что этот файл с коллосальным трудом открывается, действительно, это аномально вести реестр таким образом. Для тех у кого не получится его открыть, я когда-то делал специальную утилиту docx2csv [4], она умеет вытаскивать таблицы из .docx файлов и сохранять их как серию файлов CSV или один XLSX.

Поэтому то что этот и остальные реестры публикуются в docx формате - это проблема, но проблема скорее культурная. Если бы в центре реально хотели делать это максимально вредным способом то публиковали бы реестр в виде отсканированного PDF файла с утверждающей подписью руководителя и аргументами что "только так можно дать ему юридическую значимость". Но, слава Богу, это не наш случай. Наш случай - это культура ведения реестра.

Сравнительно недавно я делал другую утилиту для командной строки, undatum [5] специально для разного рода операций преобразования и проверки данных и с её помощью регулярно проверяю разного рода официальные реестры на достоверность самых базовых реквизитов ИНН и ОГРН. Причём на уровне самой-самой простой проверки на валидность, даже без поиска по ЕГРЮЛ, проверки соответствия наименованию, кросс-валидации и так далее.

Так вот из 4880 записей у 191 (3,9%) недостоверные сведения в поле ОГРН и у 120 (2.4%) недостоверные сведения в поле ИНН. Чаще это отсутствие кода, реже это неверно введённые коды. Всего есть 16 организаций в сведениях о которых нет указаний на их коды ИНН и ОГРН одновременно. Причём все они не секретны, у многих, например, АО КБ "Хлынов", есть другие лицензии в этом же реестре и при этом заполненные реквизитами.

Являются ли эти данные достоверными? Где совершена ошибка: при их внесении, при подаче заявки на лицензию заявителем или, быть может, логичнее предположить ещё на этапе организации ведения реестра. Если он ведётся даже не в Excel и уж точно для него нет даже самой простой системы ведения реестров, если у него нет синхронизации и проверки с ЕГРЮЛ, если у него нет регламента ведения и так далее, то в нём как и в сотнях других реестров государства и опубликованных данных - будут ошибки. Эти ошибки накапливаются и итоговые системы принятия решений основанные на этих данных дают значительные искажения.

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

Ссылки:
[1] https://clsz.fsb.ru
[2] https://clsz.fsb.ru/clsz/license.htm
[3] https://t.iss.one/alukatsky/3880
[4] https://github.com/ivbeg/docx2csv
[5] https://github.com/datacoon/undatum

#opendata #dataquality #registries

В рубрике интересные наборы данных, Table Union Search on Open Data, научная статья [1] и база данных [2] с фокусом на автоматизацию объединения табличных данных. Исследование о том можно ли и насколько эффективно можно объединять разные табличные данные по полям которые кажутся идентичными, совпадающими.

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

Несмотря на то что статье более 3-х лет и результаты анализа на основе таблиц из порталов открытых данных 3-х летней давности, актуальности задачи не теряет. Отчасти жаль лишь что опубликовано маловато кода, может быть авторы делают коммерческий продукт, правда 3 года прошло.

Ссылки:
[1] https://www.vldb.org/pvldb/vol11/p813-nargesian.pdf
[2] https://github.com/RJMillerLab/table-union-search-benchmark

#opendata #dataquality #data

К вопросу об интересных наборах данных и их сохранности. После обновления системы ЕГИСУ НИОКТР (Единая государственная информационная система учета результатов научно-исследовательских, опытно-конструкторских и технологических работ гражданского назначения) [1] из раздела открытые данные исчезла возможность выгрузки данных до 2016 года, а также изменился сам формат выгрузки данных. Если ранее это были XML дампы (без схем и документации), то сейчас это JSON дампы, также, без схем и документации.

Масштаб изменений пока измерить сложно потому что в новых выгрузках данных в ЕГИСУ много ошибок. Но старые данные, до 2016 года в них не находятся.

Архив этих данных у нас, конечно, есть, но это ещё один сигнал о необходимости архивации открытых данных.

Ссылки:
[1] https://rosrid.ru

#opendata #data #dataquality

Совсем свежий открытый проект по контролю качества данных soda-sql [1] от создателей платформы мониторинга качества данных Soda [2]. Помимо того что сама платформа выглядит интересно, хотя и не применима в российских условиях госпроектов, к примеру, но сделана она с правильными акцентами на наблюдаемость данных и автоматизацию контроля качества. А тут ещё и soda-sql, можно сказать что инструмент из коробки для оценки пропусков в данных и подсчёта десятка разных метрик для оценки их качества. Для тех кто собирает собственные технологические стеки работы с данными - этот инструмент будет удобным дополнением.

Автоматизация контроля качества данных - это важная "фишка" современных платформ сбора и обработки данных поэтому за Soda стоит понаблюдать и далее, и как за решением с открытым кодом, и как за платформой.

Ссылки:
[1] https://github.com/sodadata/soda-sql
[2] https://www.soda.io/

#data #dataquality

Хороший обзор стартапов и тренда на рост значимости качества данных (data quality) по частоте упоминания в резюме, росту инвестиций в эту отрасль и другие признаки [1].

Я ранее уже упоминал весьма любопытные стартапы Soda [2] и Anomalo [3], а в этом обзоре ещё упоминаются Aquarium [4] и Datafold [5] и многие другие.

Качество данных, действительно, одна из ключевых задач инженерии данных и большой растущий рынок для инструментов в этой области.

Ссылки:
[1] https://gradientflow.com/data-quality-unpacked/
[2] https://t.iss.one/begtin/2810
[3] https://t.iss.one/begtin/2388
[4] https://www.aquariumlearning.com
[5] https://www.datafold.com/

#data #dataquality

Росводресурсы открыли прототип системы "Водные данные" [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

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

* 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.iss.one/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