Почему обнаружение аномалий в масштабе сложно, дорого и шумно.
Допустим, вы работаете в интернет-магазине. В вашем магазине продается 1000 товаров. Вы хотите запустить обнаружение аномалий в ежедневных заказах для каждого из этих 1000 продуктов. Это означает следующее:
Number of Metrics = 1 (Orders) Number of Dimension Values = 1000 (1000 products) Number of Metric Combinations = 1000 (1 metric * 1000 dimension values)
Это означает, что алгоритм обнаружения аномалий запускается 1000 раз в день, по одному разу для каждой комбинации метрик.
Допустим, вы хотите отслеживать Заказы по другому параметру — Состояние (50 уникальных значений). Вы также хотите отслеживать метрику по комбинациям этих двух измерений. Это означает, что алгоритм обнаружения аномалий запускается 51 050 раз каждый день.
51,050 = (1 metric * 1000 products) + (1 metric * 50 states) + (1 metric * 1000 products * 50 states)
Теперь предположим, что вы хотите отслеживать десятки показателей. Каждая метрика имеет десятки измерений. Каждое измерение имеет сотни или тысячи значений измерения. Теперь вы просматриваете десятки или сотни миллионов комбинаций метрик, которые нужно отслеживать ежедневно.
Обнаружение аномалий в масштабе стоит дорого
Чтобы получить представление о ценах на инфраструктуру, давайте посмотрим на стоимость сервиса обнаружения аномалий на базе машинного обучения AWS. Если вы посмотрите на пример с ценами, AWS будет взимать с вас 1900 долларов США в месяц за ежедневное отслеживание комбинаций метрик 221K.
Это просто плата за запуск алгоритма. Перед каждым запуском алгоритма вам необходимо выполнить запрос для извлечения данных из вашего хранилища данных. Миллионы комбинаций метрик означают миллионы запросов к вашему хранилищу данных ежедневно, что требует дополнительных затрат.
И это только стоимость облачной инфраструктуры.
Обнаружение аномалий в масштабе зашумлено
Вернемся к примеру в начале. Вы отслеживаете метрику «Ежедневные заказы» по двум параметрам — продукту и состоянию. Каждая из этих комбинаций метрик 51K потенциально может быть аномалией.
Даже если 0,1% этих комбинаций окажутся аномалиями, вы ежедневно просматриваете 51 аномалию для одной метрики. Хватит ли у вас или вашей команды пропускной способности, чтобы ежедневно реагировать на такое количество аномалий? Вероятно, не. Если вы не будете реагировать на эти аномалии, эти аномалии не добавят никакой ценности для бизнеса. Вместо этого они просто увеличивают ваши расходы.
Обнаружение аномалий в масштабе сложно
Теперь вы, вероятно, согласитесь со мной, что обнаружение аномалий в масштабе дорого и шумно. Но есть решение этой проблемы. И это то, что мы строим в Cuebook. Это была трудная и сложная задача, но это было очень весело. Я не буду делиться здесь решением, потому что оно сложное и включает слишком много доменов — запросы, хранение данных, облачную инфраструктуру, взаимодействие с пользователем и т. д.
На очень высоком уровне вот некоторые из проблем, которые мы решили, или подход, который мы использовали:
- Мы начали с потребления аномалий, а не производства. Если конечный пользователь не использует аномалию, то эта аномалия не представляет ценности для бизнеса.
- Чтобы включить потребление, мы должны убедиться, что аномалия актуальна и значительна для пользователя.
- Мы не можем ожидать, что пользователь явно расскажет нам, что для него актуально и важно. То, что актуально и значимо сегодня, может не остаться таковым через 2 месяца.
- Мы также не можем ожидать, что аналитик или разработчик настроят аномалии для пользователя. Они не смогут. Одного пользователя может интересовать только Калифорния как штат, а другого пользователя могут интересовать Техас и Нью-Йорк.
- Обнаружение аномалий не является технической проблемой или проблемой алгоритма машинного обучения. Это проблема продукта и взаимодействия с пользователем.
- Чтобы вскипятить океан данных, потребуется много топлива, независимо от его типа. Кипячение океана выгодно только поставщикам облачной инфраструктуры.
