Правильно ли это число? Если вы работаете с аналитикой, вы часто слышите этот вопрос. Качество данных сложно.
AB Tasty предлагает решения для создания онлайн-экспериментов и оптимизации взаимодействия с пользователем. Судя по приведенным нами цифрам, наши клиенты вносят изменения, затрагивающие миллионы конечных пользователей. Без гарантии качества данных наши клиенты могут в конечном итоге принять катастрофические бизнес-решения.
В AB Tasty мы часто слышим Это правильный номер?.

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

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

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

Архитектура

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

Фон

Мы используем стандартные инструменты мониторинга DevOps для отслеживания этого конвейера: частота запросов, использование сети, количество сообщений, пропускная способность и т. Д.
Мы можем определить, идет ли поток данных правильно, но у нас нет точных данных. детализированный взгляд на данные. Поскольку 4000 клиентов отправляют события, в этих показателях DevOps невозможно обнаружить ни одного сбывающего клиента. Кроме того, один клиент мог бы преобразовать все транзакции из долларов в евро, метрикам DevOps все равно.
По сути, мы следим за 3V: громкостью, скоростью и разнообразием, но мы не замечаем дополнительных 2V: правдивости и ценности.

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

  • Клиент. Интеграция тегов / SDK может нарушиться. Например, подрядчик клиента может по ошибке удалить интеграцию на Android. Такие инциденты ограничены одним клиентом. Часто проблема связана с аналитическим параметром: типом устройства, субдоменом, способом оплаты и т. Д.
  • AB Tasty. Ошибки случаются. Такие инциденты затрагивают подгруппу клиентов. Часто проблема связана с определенным бизнес-аспектом: пакетом продукта, функцией и т. Д.
  • Другие интернет-плееры. Браузеры, дополнения, поставщики ... Интернет-экосистема постоянно развивается. Такие инциденты затрагивают всех клиентов, но крошечные группы населения. Например, некоторые файлы cookie могут быть повреждены новой версией браузера. Пострадавшее население растет по мере обновления браузера.

Странствия

Мы начали с того, что встроили обнаружение аномалий в конвейер потоковой передачи. Система выполняла агрегирование, разбивку по размерам и использовала простые правила для обнаружения аномалий.
Обнаружение аномалий потоковой передачи звучит круто, но мы поняли, что у него есть серьезные недостатки. Когда произошла аномалия потоковой передачи, нам пришлось проверить ее влияние в хранилище данных. Инженер данных вручную писал и запускал SQL-запросы, а затем вставлял результаты в инструмент визуализации. Если в хранилище данных не было обнаружено никаких проблем, было непросто понять, была ли аномалия законной, вызванной ошибкой в ​​системе обнаружения или пропущенной при ручном исследовании SQL.
Длинные исторические базовые показатели и множество измерений действительно плохо масштабируется: потоковая система должна хранить много состояний в памяти.
Кроме того, потоковая структура сильно увязала агрегирование данных и обнаружение аномалий: добавление новых правил было трудным.

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

- Раздельные обязанности по сбору данных и обнаружению аномалий.
- Проверка качества там, где данные в конечном итоге потребляются: в хранилище данных.
- Обеспечивает основу для простого создания и обновления правил обнаружения.
- Разрешить произвольные частота обнаружения (каждую минуту, каждый час, каждый день и т. д.)
- Предоставьте пользовательский интерфейс для простого перехода от аномалии к анализу первопричин.
- Подключите систему к нашим рабочим инструментам (Jira, Slack)

Встречайте ThirdEye

Перед тем, как самостоятельно построить эту систему, мы проверили наличие коммерческих решений и решений с открытым исходным кодом. 18 месяцев - это целая жизнь в мире данных: в начале 2020 года инструменты для обеспечения качества данных практически отсутствовали. Мы решили попробовать ThirdEye, платформу качества данных с открытым исходным кодом, созданную в Linkedin и используемую поверх хранилища данных Apache Pinot.
ThirdEye фактически проверял все наши потребности: он описывается как платформа для реального времени мониторинг временных рядов и интерактивный анализ первопричин. В Linkedin есть три отличных статьи о Thirdeye, поэтому мы не будем представлять его подробно. Ниже приведены несколько снимков экрана, чтобы вы могли получить представление о функциях:

Интеграция ThirdEye

Чтобы подключить Thirdeye к нашим данным, нам сначала пришлось реализовать коннектор BigQuery. Мы вернули его в проект с открытым исходным кодом. Затем мы определили в BigQuery 3 показателя, которые могут помочь в обнаружении инцидентов:

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

С тремя правилами обнаружения для каждых 4000 клиентов создание и обновление конфигурационных yamls в пользовательском интерфейсе было невозможным. Мы создали небольшое пакетное задание для генерации и обновления правил. Работа подключается к нашей бизнес-базе данных, и мы настраиваем правила обнаружения на основе бизнес-информации, такой как SLA, пакет продуктов и отрасль.

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

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

Представление

Используя 3 показателя для каждых 4000 клиентов, ThirdEye управляет 12 000 правил обнаружения в час. Одно задание по обнаружению соответствует одному или двум запросам.
Мы позаботились о том, чтобы задания были равномерно распределены в течение часа, поэтому у нас постоянная нагрузка 4,3 запроса в секунду, что очень разумно для BigQuery.
8000 правила используют модели машинного обучения. BigQuery выполняет большую часть работы с данными, но модели машинного обучения таймсерий и пороговые логики вычисляются в рабочих процессах. В Kubernetes рабочие процессы масштабируются автоматически, и мы видим, что 4 модулей по 8 ГБ, 1,4 виртуальных ЦП обычно достаточно.
В целом, мы обнаружили, что система довольно дешевая и простая в обслуживании.

Вначале обнаружение аномалий вызывало слишком много ложных срабатываний. Это подвергало проект опасности: слишком много предупреждений означает, что предупреждения никто не проверяет. После нескольких часов тонкой настройки мы получаем от 1 до 4 предупреждений в день, и мы достигаем 85% истинного положительного результата. Мы упускаем некоторые инциденты (ложноотрицательные результаты), но мы обнаружили, что текущие настройки уже оказывают большое положительное влияние на операции, не обременяя инженеров по обработке данных.

Вот несколько примеров операционных успехов:

  • В начале апреля 2021 года во Франции вступил в силу новый закон о конфиденциальности данных. Десятки клиентов нарушили интеграцию тегов / SDK. Мы смогли выявить все эти инциденты и связаться с клиентами менее чем за один день.
  • мы обнаружили проблему для нового клиента, которая могла поставить под угрозу его период проверки концепции. Мы обеспечили удовлетворение клиента и в конечном итоге выиграли его.
  • мы обнаружили, что некоторые клиенты регулярно сокращали наши инструменты для SEO. Мы связались с ними и исправили влияние на SEO.

Заключение

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

Мы все еще изучаем возможности Thirdeye. Некоторые проекты, над которыми мы работаем:
- детальный мониторинг по параметрам: страна, устройство и т. Д.
- метаобучение: дать обратную связь в ThirdEye для автоматической точной настройки предупреждений
- отчеты о расследовании: открывать платформу для других команд и делиться результатами

В следующей статье мы объясним, как мы построили эффективные правила обнаружения аномалий в Thirdeye. Будьте на связи!

Ресурсы:

Блоги Linkedin:
- Александр Пучер, Общее представление о возможностях ThirdEye, 2019
- Сяохуэй Сунь, Умные оповещения в ThirdEye, 2019
- Йен-Юнг Чанг, Анализ аномалий. с ThirdEye , 2020

Репозиторий ThirdEye на Github

Все изображения автора.