Часть 1. Мониторинг качества структурированных данных в масштабе
Чтобы конкурировать в мире, управляемом данными, организации должны консолидировать данные в централизованные хранилища и использовать их для улучшения продуктов и принятия обоснованных решений.
Данные теперь являются стратегическим активом. Но как организации могут гарантировать, что они могут доверять данным, лежащим в основе этих продуктов и решений?
Большинство групп данных приходят к выводу, что им нужно начать тестирование своих данных, используя тщательно поддерживаемую библиотеку правил.
Но мониторинг всех данных в корпоративном хранилище может быть сложной задачей. Такие хранилища обычно содержат десятки тысяч или даже сотни тысяч таблиц.
- 10 самых популярных таблиц
. Определяйте показатели на уровне совета директоров и цели компании. - 100 самых популярных таблиц
Межфункциональные данные, которые информируют о продуктах и операциях. - Первые 1000 таблиц
Подробные данные, которыми владеют отдельные команды, управляющие процессами и продуктами. - Осталось более 1000 таблиц
Специальные данные о проектах или функциях
Критические таблицы в организации следует тщательно тестировать и контролировать. Подробнее о том, как этого можно достичь, читайте в нашей публикации Данные о качестве Airbnb для всех. А как же остальное?
Если средняя таблица содержит 50 столбцов, и для каждого столбца требуется 5 правил или показателей для тщательного мониторинга, то для склада с 1000 важными таблицами требуется управление 250 000 правил!
Даже если для выполнения каждого правила требуется всего 10 минут каждый год, для этого потребуется специальная команда из 20 высококвалифицированных специалистов по данным (большинство из которых быстро уволятся в знак протеста против тяжелой работы):
Тем не менее, организация по-прежнему зависит от качества этих данных. Здесь может иметь решающее значение неконтролируемый мониторинг данных.
Uber хорошо резюмировал это в своем посте Мониторинг качества данных в масштабе:
Принято считать, что для объяснения аномалий в больших объемах данных следует использовать какой-либо вариант статистического моделирования. Однако с учетом того, что Uber обеспечивает 14 миллионов поездок в день, масштаб связанных данных опровергает это общепринятое мнение. Размещая десятки тысяч таблиц, мы не можем вручную оценить качество каждой части серверных данных в наших конвейерах.
Этот первый пост из серии продемонстрирует, как Anomalo использует обучение без учителя для мониторинга качества данных в масштабе. В следующих статьях мы рассмотрим:
- Ключевые требования нашей системы и почему традиционные подходы к временным рядам и обнаружению выбросов не работают
- Архитектура системы неконтролируемого обучения Anomalo - от моделирования данных до объяснения основных причин проблем
- Как мы определяем и минимизируем ложные срабатывания, и как мы тестируем наш алгоритм, используя нашу библиотеку хаоса данных
Роль неконтролируемого мониторинга данных
Чтобы проиллюстрировать, как работает наш неконтролируемый мониторинг, мы будем использовать простую демонстрационную среду только с одной таблицей, public.fact_listing:
Это демонстрационный набор данных о продажах билетов на концерты и спортивные мероприятия. Вы можете видеть, что у нас есть 3 проверки, которые проходят через эту таблицу, и что проверки выполняются ежедневно, когда данные свежие.
При нажатии на таблицу открывается домашняя страница таблицы:
Как видите, для этой таблицы уже запущена функция Обновление данных, которая определяет, когда данные заполняются каждый день, и автоматически запускает все остальные проверки.
Внизу находятся разделы Ключевые показатели и Правила проверки, в которых пользователь может использовать наши модели временных рядов или библиотеку пользовательских проверок для проверки своих данных.
Между ними находится раздел Аномалии таблиц, содержащий две проверки, которые автоматически настраиваются для любой отслеживаемой таблицы:
Наша модель машинного обучения изучает представление типичных данных в таблице. По мере поступления новых данных он определяет, существенно ли отличаются эти данные от тех, что были в таблице ранее.
Мы запускаем два варианта этого алгоритма:
- без увеличения значений NULL
Модель с ограничениями, ищущая значительное увеличение значений NULL - отсутствие аномальных записей
Наш полный алгоритм машинного обучения, который определяет изменения в непрерывных распределениях, категориальных значениях, продолжительности времени или даже отношениях между столбцами
Первый вариант работает с высоким уровнем приоритета и уведомляет пользователей, когда наблюдается внезапный всплеск значений NULL, поскольку это может указывать на недостающие данные, которые следует быстро исправить. Второй вариант, отсутствие аномальных записей, создает журнал значимых изменений в каждой таблице.
Например, в этом Оксфордском наборе данных ответа правительства на COVID-19 в BigQuery в столбце public_information_campaigns_flag значение 1 почти полностью исчезло и было заменено значениями NULL 30 октября.
Конечно, не все столбцы важны, поэтому пользователь может контролировать, для каких таблиц и столбцов он хочет видеть уведомления.
Поиск и описание хаоса данных с помощью обучения без учителя
Чтобы проиллюстрировать, как это работает на практике, давайте введем аномалию в этот набор данных. Мы будем использовать наш клиент командной строки для запуска одной из наших операций chaos: TimeColumnZero. Это вводит нулевые значения в столбец в определенный момент времени.
Столбец numtickets в fact_listing теперь будет содержать 30% нулевых значений на 2021–01–17, когда venuestate равно «NY». Это иллюстрирует распространенную проблему качества данных - неожиданно появляется недопустимое значение для части строк в ключевом сегменте данных.
Затем мы можем повторно запустить проверку на аномалию таблицы и обнаружить, что вариант no anomalous records не работает (поскольку он ищет любое значимое изменение):
Мы можем щелкнуть просмотреть подробности, чтобы увидеть объяснение:
Проверка на аномалии таблицы правильно определила, что столбец numtickets имеет внезапное увеличение 0 значений. Обратите внимание, что мы никогда не говорили ему смотреть на этот столбец или искать нулевые значения.
Он также оценивает серьезность аномалии (эта сильная) и сравнивает ее с полученным порогом для этой таблицы, который учитывает, сколько фонового шума присутствует в каждом столбце. Поскольку серьезность превышает пороговое значение, эта проверка не выполняется и выделяется в пользовательском интерфейсе (и может уведомить пользователя в Slack или Teams).
Прокручивая вниз, мы видим настраиваемую визуализацию, выбранную в зависимости от типа аномалии и распределения данных:
В этом случае диаграмма верхних значений показывает наиболее распространенные numtickets значения и сравнивает распределение на 2021–01–16 (левые столбцы) с распределением на 2021–01-17 (правые столбцы). . Вы можете видеть, что значения 0 раньше не было, и теперь оно составляет 10,4% записей.
Прокручивая дальше, мы можем увидеть объяснение основной причины, которое анализирует необработанные данные, лежащие в основе нашей неконтролируемой модели, чтобы определить, есть ли сегменты данных, в которых проблема наиболее заметна:
Как видите, алгоритм правильно определяет, что в Нью-Йорке произошла аномалия. 100% аномальных строк находятся в этом состоянии, но только 29,8% строк населения находятся в Нью-Йорке.
Это автоматическое определение места возникновения проблемы очень важно. Без него пользователю нужно было бы исследовать записи, отслеживать происхождение или повторно запрашивать и визуализировать данные, чтобы изолировать проблему.
Алгоритм может обнаруживать даже более сложные проблемы, например, когда меняется отношение между столбцами. Например, рассмотрим эту беспорядочную операцию:
Здесь мы перемешиваем столбец priceperticket, чтобы значения больше не соответствовали правильным строкам. Фактические значения остаются такими же (и имеют одинаковое распределение и среднее значение), но связь между этим столбцом и другими столбцами в таблице нарушена.
В этом случае алгоритм определяет, что priceperticket является наиболее проблемным столбцом и что проблема также связана с listid и totalprice.
Изучение распределения priceperticket значений на 1/16 и 1/17 показывает, что аномалия является самой сильной в самом низком и самом высоком priceperticket значениях:
Мы можем изучить выборку отдельных строк и увидеть, что алгоритм оценивает каждое значение в таблице, насколько оно аномально:
В этом примере цена 1 960 долларов за билет не имеет никакого смысла в контексте 28 билетов за 1 568 долларов. К тому же цена за билет необычно высока для шоу Vampire Weekend.
Уменьшив масштаб, мы можем увидеть этот эффект во многих строках:
Теперь вы можете более четко увидеть, какие конкретные значения таблицы, по мнению алгоритма, вносят наибольший вклад в аномалию, на что указывает цветовая шкала severity справа.
Это детальное распределение аномалии по конкретным значениям таблицы является ключевым. Это позволяет нашей системе четко визуализировать и объяснять основную проблему.
Отправляясь в путешествие по мониторингу и тестированию качества данных на вашем складе, имеет смысл начать с простого. Вы можете использовать библиотеки с открытым исходным кодом, писать свои собственные тесты или использовать платформу, подобную нашей в Anomalo, для тщательного тестирования ваших данных.
Но по мере роста масштабов складов, организаций и тестирования подходы, основанные на простых правилах и временных рядах, падают. Они не могут эффективно покрыть длинный хвост часто возникающих проблем с качеством данных.
Именно здесь на помощь приходит неконтролируемый мониторинг данных. Вы используете машину для изучения структуры ваших данных и отслеживания значительных неожиданных изменений. Он уведомляет вас, когда происходит значимое негативное изменение, и представляет вам визуальные сводки и объяснения, которые значительно ускоряют вашу сортировку и разрешение.
Следите за обновлениями в нашей следующей публикации из этой серии, которая объяснит, как наш неконтролируемый алгоритм работает за кулисами.
Чтобы начать работу с Anomalo и начать масштабный мониторинг ваших данных с использованием наших алгоритмов, обязательно запросите демонстрацию.
