Современное производство — это уже давно не просто набор станков и всяких железок в ангарах, теперь это ещё и автоматизации, IT-инфраструктура и много, очень много данных, которые в режиме реального времени стекаются в DWH (Data Warehouse — хранилище данных) из сотен источников.

Эти данные нужно собирать, хранить, обрабатывать и анализировать, чтобы компания могла принимать правильные бизнес-решения. Качество данных (Data Quality, DQ) в таких условиях становится критически важным показателем, от которого зависит рентабельность бизнеса в целом.

Это вторая статья из небольшого цикла, в котором мы разбираем опыт СИБУРа в создании, поддержке и развитии DQ-сервиса. И этот опыт универсален — его можно применять в любой компании, перед которой стоят задачи по обеспечению качества данных.

В первой статье мы рассказывали про импортозамещение DQ-решений после ухода вендора с рынка РФ. В этой статье мы поговорим о задачах, которые решает DQ в целом, и рассмотрим архитектуру решения, которое мы строим в СИБУРе.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса в компании последние несколько лет.

Как мы строили (строим) Data Quality сервис в СИБУРе

В этой статье мы разберём опыт проб и ошибок СИБУРа, который применим в любой другой организации, где нужно собирать, хранить и анализировать данные. Обсудим, какие есть инструменты Data Quality и какие задачи можно с их помощью решить.

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

Слои DWH в СИБУРе

Для понимания общей картины предлагаем посмотреть на эту схему. У нас в СИБУРе есть концепция хранилища, которую мы стремимся реализовать. То, что на схеме, — наша цель, идеальная картинка, в которой всё разложено по слоям.

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

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

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

Задачи Data Quality сервиса

Задачи условно можно разделить на две части: технические и бизнес-задачи.

Бизнес-задачи:

1. Повышение доверия к данным для принятия на их основании верных решений. Этот пункт — очень эфемерная вещь, которую сложно посчитать в деньгах в условиях непрерывного производства. Если даже у нас есть инструменты контроля качества данных, то мы вряд ли сможем посчитать, сколько денег мы заработали на этом. Это часто некий чёрный ящик, и бизнесу сложно объяснить ценность и пользу от проверок данных, рассуждая категориями повышения доходности производства. Но тем не менее задача такая есть, и она решается.

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

Технические задачи:

1. Мониторинг инцидентов для своевременного реагирования. Это очевидная и первоочерёдная задача. Если у нас падает загрузка данных, какие-то данные приходят некорректно, выбиваются из бизнес-логики, какие-то строки дублируются, приходят пустыми — мы хотим об этом знать. Можно сравнивать количество данных за предыдущий период, например вчера, и сравнивать их с количеством данных, поступивших сегодня к тому же часу. Если вчера мы получили 1000 строк, а сегодня пять, то это может говорить нам о каком-то инциденте, и его нужно подсветить.

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

3. Self-service для Data Stewards. Self-service — интерфейс с возможностью настройки и запуска проверок качества данных для людей из бизнеса (которых принято называть Data Stewards). Проверки качества данных выполняются с помощью кастомных SQL-скриптов или типовых проверок, которые запускаются по расписанию либо после наступления какого-то триггера. Бывает, что с данными, которые мы собираем в DWH, могут возникать проблемы: они расходятся или перестают литься. И никто, кроме человека от бизнеса, не сможет корректно написать проверку качества данных. Иногда недостаточно только технических знаний, чтобы написать скрипт проверки данных, — нужны знания бизнесовой части. И эти люди должны иметь возможность использовать готовые шаблоны проверок и запускать их по расписанию.

Настройка к BI-системам для своевременного информирования об изменении ключевых метрик. Люди тратят огромное количество времени на построение графиков и отслеживание ключевых метрик в BI, то есть каждый день они заходят в этот график и смотрят, всё ли там хорошо. Вместо этого можно написать SQL-скрипт в DQ, поставить его на выполнение раз в час, день, в неделю — неважно — и не отрисовывать график каждый раз. Написать скрипт гораздо проще.

На каких уровнях можно проверять данные?

Есть различные уровни, на которых мы можем проверять данные.

1. На уровне приложения.

Самый базовый уровень проверки вводимых в систему данных — фронтенд. Мы можем фильтровать данные на входе, например, если человек вводит дату, то у неё есть определённый формат и корректный диапазон, за пределами которого мы данные не примем. И так мы исключаем возможность ввода некорректных данных, которые могут испортить статистику.

На уровне бэкенда примерно так же, как на фронтенде, но уже на уровне сервера. Если данные вводят не люди, а они попадают автоматически, то нам нужно проверять их на уровне сервера. Если мы говорим про СИБУР, то у нас есть данные статистики по работающему оборудованию, по выполнению химической реакции, это может быть температура, давление и так далее. То есть все данные, сгенерированные интернетом вещей, мы проверяем на уровне бэкенда.

Однако не всё удаётся отфильтровать на входе, поэтому существуют другие уровни проверки.

2. В режиме реального времени.

Когда данные перемещаются между слоями DWH, к ним можно применять различные проверки. Как правило, проверки реализуются python-скриптами, но не обязательно. Мы можем добавить DQ-таск или exception и ловить таким образом ошибки. При обнаружении ошибки мы принимаем решение:
1) остановить загрузку данных, если не хотим, чтобы некорректные данные попали в какую-то табличку и потом по ней был построен неправильный график;

2) продолжить загрузку, если не критично, но как-то подсветить.

3. Валидация загруженных данных.

Когда данные уже загружены и мы работаем с ними на уровне базы. И в некоторых случаях этот подход можно назвать более простым. В СИБУРе Data Quality основан на этом подходе.

Почему мы решили сделать именно так? В разных компаниях бывает, что есть проверки только на первом и втором уровнях, а на третьем не делается вообще ничего. Но мы в СИБУРе решили валидировать уже загруженные данные, потому что есть определённое legacy в процессах, когда большая часть данных загружается вручную и проверять их на других уровнях было нецелесообразно на начальных этапах создания Data Quality сервиса.

У этого подхода есть плюсы и минусы, но плюсов, на наш взгляд, больше. Главный минус, с которым мы имеем дело, — ошибки, которые могут быть при загрузке данных, и это мы резолвим с помощью data инженеров. Если обнаруживается какая-то ошибка — приходит уведомление, вмешиваются инженеры и как-то это фиксят. В идеальной картине мира они должны ещё проверять бизнес-логику, но мы до идеала ещё не дошли.

Теперь о плюсах. Когда мы работаем с уже загруженными данными, то можем:
1. Привлекать людей как из дата-офиса, так и из бизнеса на проектах, где нет аналитиков или архитекторов. То есть качество данных помогают обеспечить именно пользователи этих данных, которые понимают их суть.

2. Так проще делать удобный интерфейс для создания проверок с помощью шаблонов.

DQ-фронтенд

Чтобы пользователи сами могли писать проверки с помощью SQL-скриптов, чтобы это было юзер-френдли, мы сделали фронтенд.

Нам показалось разумным разделить технических и бизнес-пользователей по разным интерфейсам. Хотя, например, если смотреть на Ataссama, Open Metadata или ArenaData Catalog, у них эти категории пользователей ходят в один интерфейс. Но мы всё-таки сделали отдельный веб-интерфейс для бизнес-пользователей, чтобы у них не было каши в голове.

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

Шаблонные проверки данных

В нашем сервисе DQ есть такое понятие, как «шаблонные проверки» — их могут настраивать пользователи из интерфейса. Как правило, это какие-то стандартные вещи. Например, проверка на дублирование или на отсутствие нулевых значений и так далее. У нас есть большая библиотека таких проверок.

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

Эти шаблоны были встроены в библиотеку Great Expectations, с которого мы переезжаем на SODA — писали об этом здесь. Шаблонные проверки — это удобно, но они не всегда совместимы с определёнными БД, поэтому нам приходится выделять ресурсы на адаптацию этих шаблонов, оптимизацию, ну и создание новых, потому что их как будто бы всегда мало.

Ближайшие задачи по развитию интерфейса

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

Почему нужно? Чтобы быстро понять, где именно проблемные строчки, на что обратить внимание, где бизнес-логика сломалась. Сейчас, чтобы это выяснить, пользователю нужно повторно заходить в DBeaver, запускать руками скрипт проверки. И возможно, если ошибка, допустим, возникла условно в 03:00, а человек пришёл на работу в 10:00, запустил скрипт, а данные уже поменялись — нужно потратить дополнительное время, чтобы отследить ошибку. А если это бизнес-пользователь, он, возможно, вообще не заходит туда и ничего не проверяет.

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

Метрики качества данных

Количество метрик для мониторинга можно придумать сколько угодно. Но мы в СИБУРе ничего не выдумывали, брали талмуд DAMA DMBOK, открывали священную тринадцатую главу по data quality и брали метрики оттуда.

Отдельных проверок может быть бесчисленное количество, поэтому приведем ключевые категории метрик для проверки качества данных:

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

• Консистентность. Для проверки данных на соответствие значений элементов областям или множествам допустимых значений.

• Полнота. Эта категория проверок может помочь автоматизировать проверку на корректность заполнения столбцов, атрибутов, таблиц и объектов.

• Разумность. Выявление наборов данных, выходящих за рамки здравого смысла. Например, распределение продаж по географическим регионам должно хотя бы приблизительно соответствовать накопленным знаниям о структуре потребительского спроса в этих регионах.

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

• Соответствие. В этой категории все проверки, проверяющие близость данных к «эталонным».

• Уникальность. Проверки на отсутствие объектов-клонов или иных тождественных друг другу сущностей.

• Целостность. В узком прикладном понимании контроля качества данных, под целостностью обычно понимают либо целостность данных на уровне ссылок (наличие во всех парах логически связанных объектов данных общего для обоих объектов ссылочного ключа), либо внутреннюю связность набора данных, то есть отсутствие в нем логических пустот (недостающих элементов).

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

Если ошибок нет, то таблица будет подсвечена зелёным: это будет означать, что данным можно доверять.

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

Принципы организации «дата-платформы» в СИБУРе

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

Для правильной организации архитектуры мы можем задавать ограничения на уровне таблиц в DWH. Например, запрещать, чтобы у нас ключевые поля имели нулевые значения. Либо мы можем запретить создание дубликатов primary key, foreign key или полных дубликатов и так далее. Также мы можем проверять согласованность между несколькими таблицами.

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

И это то, что мы делаем в СИБУРе. Мы всегда задаём вопрос: «Насколько хорошо организовано хранилище?»

Если кому-то нужно построить какой-то красивый, удобный, сложный график, с которым можно работать, у нас выходит проектная команда, которая сначала занимается тем, что раскладывает данные на слои. Все эти сущности потом вводятся в таблички. Затем начинается аудит качества данных, и мы также проверяем, что все метаданные описаны корректно — это важно. Только после этого это всё переходит на техподдержку. 

Это подразумевает, что у нас есть отдельные люди, которые мониторят, что все DAG (Directed Acyclic Graph) в Airflow либо процессные группы отрабатывают успешно и нет ошибок. Если ошибка возникает, мы можем обратиться к ним либо к Data Steward, которые знают бизнес-процессы и могут отвечать на специфические вопросы.

Архитектура приложения DQ

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

В каталоге данных около 200 источников данных, и отдельной задачей было подключение ко всем этим источникам, потому что у них были разные типы БД и надо было всё это интегрировать в единый контур.

Также есть сложности в менеджменте этой инфраструктуры на уровне учетных записей. Есть технические учётки, у которых выделенный пул. И эти учётки могут просто замусорить оперативку, например, и положить какую-нибудь базу. На уровне дата-платформы нужно мониторить этот момент. На уровне систем и источников мы следим, чтобы проверки не вставали в длинную очередь. Всё это выполняется у нас через Kafka и сервисы исполнения проверок. Соответственно, в Kafka есть отдельные топики, которые тоже нужно умело менеджерить.

Сервис информирования

Мы разработали отдельный сервис информирования, который выполняет рассылку по статистике. Статистику можно видеть также в интерфейсе. Плюс информирование у нас выполняется при возникновении инцидентов, на которые нужно обратить внимание.

Все проверки подразделяются на три вида:

• некритичные,

• средне критичные,

• критичные.

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

На уровне Data Lineage мы видим результаты запусков проверок и метрик по принципу «Светофор».

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

Если есть хотя бы одна ошибка по средне критичной проверке, то мы помечаем эту таблицу жёлтым. Это предупреждение, что нужно проверить. Но этим данным можно доверять, но быть осторожным.

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

Ещё у нас есть сервис исполнения проверок, который запускается по некоему заданному выражению либо по нескольким cron-выражениям.

Также мы реализовали отдельный сервис, который передаёт информацию о том, что данные загрузились. Если у нас приходит информация от нашего дата-инжиниринг-стека в виде Airflow, NiFi (и сейчас добавляется Spark), то это подсвечивается и мы можем тут же запустить проверку этих данных.

Во время импортозамещения, о котором рассказали в этой статье, мы перевели DQ на Open Source — модернизировали аутентификацию и сменили Elastic на Open Search. С Grafana у нас нет проблем, потому что у нас там идёт напрямую через Open Search -> Clickhouse -> Grafana, то есть мы все продуктовые метрики и статистику можем смотреть там. Плюс сам DQ тоже интегрирован с дата-платформой на базе Vertica. И мы там тоже можем строить BI-решения и графики.

То есть пользователи с разных продуктов к нам приходят и говорят: «А как нам отслеживать статистику?» При этом у них есть свой интерфейс, но того графика, которым им нужен, может не быть. Это, конечно, вопрос, стоит ли это делать в DQ, потому что проще это построить в BI. Но мы можем вывести график в интерфейс DQ — стремимся к этому, хоть и происходит это не быстро, потому что есть более важные задачи по расширению ключевой функциональности.

Обучение

Чтобы всё это работало не только на техническом уровне, но и на уровне людей, мы занимаемся продвижением культуры работы с данными и качеством данных в массы, для этого проводим:

• обучение,

• внутренние вебинары,

• митапы.

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

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

Аудит проверок

Также важно упомянуть о потоке задач, связанных с устареванием проверок качества данных. И чтобы не проводить ненужных проверок, мы устраиваем аудит.

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

Также аудит может проходить на регулярной основе — раз в квартал или полугодие. Регулярность мы определяем в зависимости от критичности проекта, которая задаётся на этапе принятия его на поддержку.

Дальнейшие планы по развитию DQ-сервиса

Автоматизация технических проверок

Мы планируем наладить автоматическое покрытие технических проверок. Что имеется в виду? Например, есть какие-то параметры, которые могут задавать архитекторы, эти параметры оформляются в виде дата-контрактов. И на их основании должны автоматически создаваться проверки качества данных.

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

Внедрение проверок в реальном времени

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

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

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

Верификация пользовательских SQL-скриптов

Как уже говорили, наши пользователи пишут SQL-скрипты — у них есть такая возможность. Но эти скрипты могут быть не оптимизированными. Чтобы повысить их качество, мы собираемся внедрить верификацию с помощью Git и движка SQL.

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

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

Профилирование проверок данных

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

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