Компонентный подход к качеству данных

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

Почему так происходит? Причин может быть несколько.

• Процесс обеспечения качества данных разбит на блоки. Например, имеются разрозненные блоки: «Качество на источнике», «Качество на ETL», «Качество данных в витринах», которые не стыкуются между собой. Подобное разделение есть как в оргструктуре, так и в зонах ответственности, где эти блоки могут иметь расхождения даже в рамках одного продукта.
• Недостаточная квалификация ответственного за обеспечение качества данных. Командный аналитик может не обладать необходимой полнотой знаний и навыков по всему циклу создания информационного продукта, а бизнес-владелец данных не готов достаточно внимания уделить их качеству.
• Разнообразие инструментов. Инструменты оценки качества данных для источника, ETL и итоговых витрин могут быть очень разными — в зависимости от функционала специалисты используют разные инструменты, что усиливает расхождение процессов в блоках.

В итоге получается, что команде нужно представить единый результат — качественные данные в продукте, пригодные для дальнейшего использования бизнесом, однако этого результата параллельно добиваются три разные группы сотрудников, использующие разные блоки инструментов и зачастую не вникающие в суть работы друг друга. Избежать подобных ошибок позволяет компонентный подход к обеспечению качества данных. Его основные принципы:

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

В теории компонентный подход (рис. 1) выглядит неплохо, но на практике может быть иначе.

Рис. 1. Компонентный подход

Система-источник

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

Компонентный подход предполагает полное исследование качества данных, включающее в себя процесс их создания, в том числе и работу системы-источника: суть и структура данных; регулярность их появления; проверки при вводе данных; собственные проверки.

Результаты проверок на источнике переводятся в единый формат и отображаются в каталоге данных на lineage (родословная данных). Например, монтажники в компании отчитывались по результатам установки системы подсчета посетителей (СПП) в формате «ID устройства — ID точки — ID монтажника». Программа поддержки системы подсчета посетителей требует заполнить карточку устройства с обязательным указанием названия точки, адреса установки и еще ряда полей. Монтажники заполняли эти поля на свое усмотрение, продуктовые ана­литики по СПП были в курсе ситу­ации, но ничего не меняли, так как вне­сенные в систему данные в дальнейшей работе не использовались. При попытке использовать данные из СПП в продуктах анализа больших данных стало быстро понятно, что данные некачественные, полагаться на них нельзя, а использование ведет к огромному количеству ошибок. Первый же отчет по посещаемости торговых точек оказался весьма далек от действительности. Личная встреча со всеми участниками бизнес-процесса, оперирующими системой-источником, может быть полезней, чем недели исследований уже опубликованных данных.

Путь данных до аналитики

В рабочей практике классической связки «аналитик — разработчик — тестировщик» всегда есть разделение полномочий: что-то входит в круг обязанностей аналитика, что-то — только разработчика, и обычно их зоны ответственности не пересекаются. Однако ответственность за результат проверок качества данных чаще всего лежит на аналитике, который может оказаться в ситуации, когда данные есть, он понимает процесс их формирования, имеется инструмент и возможность написать проверки. В итоге аналитик пишет запрос: select count (*) from _lz; select count (*) from _stg; select count (*) from _prd, чтобы убедиться, что все данные «доехали» до слоя с трансформациями. Эту же информацию можно получить из логов загрузки. Но как узнать, что все загрузилось? Например, это можно сделать через запрос select на итоговом массиве после отработки загрузчика.

Показательный пример: в одной продуктовой команде результат проверок качества данных по продукту три месяца подряд показывал неизменные 100% качества данных, но при этом все эти три месяца данные вообще не подгружались — не было ни одной новой записи. Причина некорректного результата? Проверки, которые были настроены, не оценивали количество записей за новые даты, это было сделано осознанно, в силу специфики данных. Узнать, что загрузок не было, можно было бы с помощью выгрузки из ETL-инструмента, но вот как раз результаты проверок из него никто не оценивал.

Решение состоит в подключении разработчиков и дата-инженеров к обеспечению процессов качества данных — это ключевая часть успешного внедрения этих процессов. Но здесь возникает дополнительная сложность — определение зон ответственности.

Требования — реализация — ответственность

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

Компонентный подход предлагает решение:

• родословная данных должна быть неотъемлемой частью управления качеством данных;
• в дорожную карту процессов разработки требуется внести ряд изменений: требования к качеству данных должны формулироваться уже на этапе проектирования и согласования продукта; требования разделяются по отдельным этапам создания данных: требования для источника, ETL-разработка, готовые таблицы/витрины; проверки качества данных должны быть включены в список задач для разработки.

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

Рис. 2. Процесс принятия решений на данных

В процессе формирования витрин для принятия решений на данных (рис. 2) может произойти сбой на любом из этапов, и обычно все дальнейшие шаги после сбоя уже не имеют смысла или даже заведомо вредны. Например, формировать маршрутные листы для курьеров разумно только при наличии актуальных адресов доставок.

Основная опасность подобных сбоев в том, что в общем процессе они часто незаметны. Хорошо, если возможна проверка с заданными параметрами, например, «забирать только данные за конкретный день», но это не всегда применимо, так как источник данных может обновляться не ежедневно, целиком или неравномерно.

Согласно компонентному подходу, скрипты, реализуемые в инструментах, должны уметь обнаруживать сбои и останавливать процесс дальнейших расчетов, информируя об ошибках. Но важно отметить, что это — возможность, а не обязательство. При создании ETL-процесса пользователь должен сам принять решение, критично ли для него, чтобы предыдущие шаги процесса были полностью отработаны, и какие действия следует принимать, если на предыдущем этапе произошла ошибка. Допустима ли ошибка или надо не только прекратить все дальнейшие расчеты, но и проинформировать владельцев отчета?

Ключевой проблемой инструментов проверок качества данных становится то, что таких инструментов много, они поддерживают отдельные направления работы, требуют разных уровней подготовки сотрудника и при этом не интегрированы в единый сервис. Например, что-то нужно смотреть средствами Airflow, для чего-то есть свои дашборды в Grafana, какие-то проверки хранятся в своем отдельном модуле качества данных, например в GE Digital. У каждого специалиста, ответственного за тот или иной этап проверок, есть свой инструмент, и при попытке объединения этих инструментов в единый комплекс может возникнуть вопрос «а где смотреть результаты?», на который не будет очевидного ответа.

Компонентный подход к обеспечению качества данных предполагает не только разделение процесса обеспечения качества данных на составляющие, но и объединение этих составляющих в единое целое. Проверки качества данных на системе-источнике могут осуществляться и храниться в ней самой и не зависеть от инструментов работы с большими данными. Но при этом результаты проверок качества точно должны быть доступны при оценке готовности витрин. При компонентном подходе — это каталог данных, например, «Аренадата», OMD, RT.DG. Каталоги данных чаще всего имеют встроенный функционал, хотя бы для демонстрации родословной построения данных, ведь именно благодаря lineage обеспечивается связка системы-источника и ETL готовых витрин.

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

***

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

Оксана Солдатова (OSoldatova@datatech.ru) — консультант по управлению данными, компания «Дататех» (Москва). Статья подготовлена на основе материалов выступления на конференции «Качество данных 2024».