Мониторинг никогда не спит

Прежде чем переходить к сборке слоя data-mart, разберем еще одну тему — мониторинг качества данных. В первом марафоне «Генеральная уборка данных» мы разбирали множество вариантов того, как недостаточно качественные данные могут исказить результаты анализа.

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

Качество данных

Компонент для оповещений в Telegram

Откройте пакет прошлого занятия, зайдите в подмодель Sales_plan. Разместите там компонент «📁 Аудит качества данных» из Data_Control_Kit. Подайте ему на вход данные из импорта LGD-файла.

Как вы можете видеть, «📁 Аудит качества данных» — это производный узел, а значит содержит внутри себя шаблон сценария, который мы будем настраивать.

Но для начала задайте на входном порту переменных название проверки, которую мы будем проводить.

Внутри нас ждет готовая схема.

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

В калькуляторе «DQ проверки» задаются условия для контроля значений. Давайте зайдем в него.

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

Название такого поля должно начинаться с префикса DQ_, за которым следует название проверки. Рассмотрим пример проверки значения в поле Amount_plan >= 30000.

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

Давайте создадим вторую проверку с условием Amount_plan <= 500.

​​​​Представим, что таким образом мы будем контролировать наличие подозрительно больших и маленьких объемов в планах продаж.

Компонент «Отчет DQ» формирует сводную информацию на основе созданных полей. Сводка включает:

• количество строк с инцидентами;
• процентное соотношение этих строк к общему количеству записей.

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

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

Давайте ради теста сделаем проверку дубликатов в поле Key_ERP_User_Sales_ID, указав его как входное поле.

Очень удобно, что в результате проверки создаются логические поля, принимающие значение true для дубликатов. Необходимо лишь переименовать метку на выходном порте поля, например, в «DQ_Дубли ИД менеджера», чтобы узел «Отчет DQ» включил его статистику в сводку.

Теперь статистика по дубликатам тоже формируется в сводке.

Как узнать, что в данных есть проблема, не заходя в Loginom?

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

Теперь, поставив выполнение компонента «📁 Аудит качества данных» на регулярное выполнение через планировщик (делается только на серверных версиях Loginom).

Визуальный контроль проблем в данных

Когда пакетов станет много, вспомнить все контрольные точки может быть непросто. Однако это уже предусмотрено: компонент «Отчет DQ» содержит встроенные визуализаторы, которые позволяют быстро анализировать данные и выявленные проблемы.

​​​​​Их можно использовать для быстрого просмотра и построения специфического отчета.

Кроме того, на серверных версиях Loginom есть возможность получить ссылку на любое место пакета.

​​​​​​Эту ссылку можно скопировать и вставить в переменную подмодели, отправляющей сообщение.

Вы можете прописать у себя тестовую ссылку, вроде https://ya.ru.

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

Как вы уже догадались, этот функционал можно использовать не только для оповещений о качестве данных.

Механизм работает на базе компонента «Отправить сообщение» из библиотеки API_Telegram, что позволяет создавать собственные системы оповещений и рассылок.

Напишите в чат, о чем бы вы могли или хотели оповещать ваших коллег таким образом?

Как использовать контроль качества данных в сценарии

Вы можете использовать данный механизм:

1. На любом этапе ETL-процесса — для работы с сырыми данными, таблицами core-уровня, витринами и моделями.
2. Как неотъемлемую часть обработки потока данных — проверка может автоматически запускаться при каждом выполнении сценария.
3. В отдельных ветках — проверки данных можно расположить так, чтобы они запускались вручную или по расписанию через планировщик, независимо от основного потока данных.
4. Для создания отдельных пакетов контроля данных — для проверки больших объемов данных, чтобы не замедлять выполнение основного сценария.
5. С ограничением выборки — при работе с таблицами, содержащими миллионы или десятки миллионов строк, проверка всех записей может занимать слишком много времени. В таких случаях следует ограничить выборку, по которой выполняется проверка, например:
   • брать данные только за х последних дней.
   • использовать ограниченную выборку из случайных мест таблицы (сэмплирование).
   • с ограничением на этапе импорта в Loginom — вместо загрузки всех 50 млн записей и последующего отбора 500 тыс., лучше сразу запрашивать только нужные 500 тыс. записей.

Скачайте и установите Loginom Community Edition, если он еще не установлен.