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

Архитектурный шаблон Lambda состоит из двух слоев: пакетной обработки и одного обслуживающего слоя, в котором решаются вопросы приема входных потоков данных и сохранения результатов [1]. Слой пакетной обработки отвечает за преобразования ранее сохраненных данных — например, за выполнение статистических расчетов, получение результатов и ответов на вопросы, интересующие пользователей системы. На основе накопленной информации строятся различные модели для выполнения анализа в режиме реального времени [2] с помощью таких технологий, как Storm, Spark Streaming, Samza, Kafka и RabbitMQ.

Данные из доступных источников через REST API передаются в аналитическую систему и затем в брокер сообщений Kafka (рис. 1). Для взаимодействия с источниками данных можно применять, например, и SOAP, но протокол REST проще — он поддерживается многими веб-сервисами и компактнее при передаче сравнимого с SOAP объема полезной информации. К тому же REST уже стал де-факто индустриальным стандартом. Брокер сообщений — связующее звено между источниками данных и их обработчиками, он решает проблему асинхронного приема и обработки данных благодаря возможности развязать «поставщиков» (producer) и «потребителей» (consumer) данных. Apache Kafka состоит из набора тем (topic) — например, в случае телекоммуникационной системы можно использовать такие темы, как TAggregation (объединение информации из всех источников), TAlarm (отправка уведомлений о нештатных ситуациях) и др. Поставщики данных — контроллеры сегментов телекоммуникационной сети — отправляют сообщения заранее выбранной теме, а потребители — Storm-топологии — забирают эти сообщения для последующей обработки. Для каждой из тем Kafka гарантирует: очередность сообщений в пределах каждого раздела; распределение нагрузки между потребителями информации из одной темы; отказоустойчивость за счет создания синхронизированных копий разделов. Брокер может использоваться для обмена промежуточными данными или временного хранения результатов.

 

Рис. 1. Архитектура системы обработки данных в реальном времени
Рис. 1. Архитектура системы обработки данных в реальном времени

 

Для обработки данных в реальном времени используется Apache Storm. Каждый обработчик сообщений представлен в виде Storm-топологии, состоящей из некоторого количества «труб» (spout) и «задвижек» (bolt). Основная функция каждой трубы — обеспечить подключение к входному потоку данных. В случае проведения мониторинга телекоммуникационного оборудования все топологии получают сообщения из Kafka. После подключения к источнику данных труба последовательно распределяет входные сообщения между одной или несколькими задвижками в соответствии с заранее определенной топологией. Основным предназначением каждой задвижки является выполнение одной определенной функции (фильтрация данных, расчет метрик и т. д.) над входными данными и передача результата на вход последующих задвижек согласно топологии. Концевые задвижки сохраняют итоговые результаты.

Источники данных отправляют сообщения в темы T1…Tn (рис. 1), а топология ТAggregation объединяет данные из различных источников, упорядочивает их по времени и унифицирует формат представления. Агрегированные данные сохраняются в виде промежуточных результатов в теме TAggregated брокера Kafka, которая, в свою очередь, используется как входной поток для множества других топологий. В нашем примере это расчет счетчиков (топология Counter), показывающих в реальном времени количество занятых ресурсов в каждой ячейке телекоммуникационной сети, и генерация предупреждений (топология Alarm) при выявления ошибочных ситуаций. Все полученные результаты сохраняются в темах Kafka (Tcounter, TAlarm) и в режиме реального времени отображаются на веб-странице администратора сети, обновляемой посредством протокола WebSocket. Кроме того, результаты вычислений могут быть сохранены в хранилищах на базе СУБД MongoDB, Elasticsearch и др.

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

  • топология Archiving читает данные из всех тем, содержащих входные данные, и сохраняет их в HDFS для последующей обработки;
  • расчетные значения загрузки сети, появляющиеся в результате работы топологии Counter, — это производные от исходных данных, но эти значения могут быть также сохранены в хранилище для каждого момента времени и впоследствии использованы для анализа состояния сети в заданном интервале времени;
  • топология Alarm использует модель, построенную на основе исторических данных, для выявления нестандартных ситуаций в режиме реального времени.

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

Задачи по автоматическому выявлению нестандартных ситуаций, или выбросов, на основании накопленных исторических данных, как правило, решаются с применением методов машинного обучения «без учителя», таких как кластерный анализ. Использование кластеризации k-means позволяет управлять сложностью, а значит, и временем вычислений, путем задания количества кластеров и итераций кластеризации.

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

Оптимальное количество кластеров зависит от конкретной задачи. На рис. 2 приведен пример с множеством кластеров: одно подмножество представляет «нормальное» состояние входящих в них компонентов, а другое — выбросы. Увеличение количества кластеров позволяет получить более точную выборку однотипных компонентов. Как видно из рис. 2, большинство центроидов кластеров расположены близко друг к другу в ограниченной области, что считается нормальным состоянием системы. Чем дальше центроид некоторого кластера от данного скопления, тем выше вероятность того, что нестандартная ситуация будет признана ошибочной, поэтому точки, принадлежащие «дальним» кластерам, отмечаются как нестандартные ситуации, характеризуемые определенными значениями выбранных параметров, — это и есть выбросы, требующие дополнительного анализа. Точки, лежащие вне осей координат, могут определять наличие зависимости между этими двумя параметрами: чем четче просматривается линейная зависимость между точками на графике, тем сильнее связь между параметрами.

Рис. 2. Пример определения выбросов по двум параметрам
Рис. 2. Пример определения выбросов по двум параметрам

 

Процесс определения нестандартной ситуации, базирующийся на результатах кластеризации по методу k-means, предусматривает следующие шаги: определение списка параметров, характеризующих телекоммуникационную систему, на основании анализа связей при их попарной корреляции; выбор количества кластеров и задание числа итераций для метода k-means; предварительную обработку входных данных (например, заполнение отсутствующих значений, нормализация и т. д.); выполнение кластеризации k-means в многомерном пространстве, определяемом выбранным набором параметров; выделение наборов кластеров, центроиды которых удалены от общей массы скопления кластеров на расстояние, большее некоторого порогового значения, и пометка всех элементов таких кластеров как выбросов.

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

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

На основании исторических входных данных строится модель кластера и определяются кластеры с выбросами. Далее построенная модель используется для обработки новых входных данных в реальном времени, а результат ее работы направляется на верификацию. Если построенная модель перестает выявлять выбросы («хорошие» данные были классифицированы как выброс или, наоборот, выброс был пропущен), то производятся ревизия параметров и перестроение кластерной модели.

***

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

Литература

  1. Nathan Marz, James Warren. Big Data. Principles and best practices of scalable realtime data systems // April 2015 ISBN 9781617290343.
  2. Андрей Егоров, Александр Смирнов. Анализ работы телекоммуникационной системы // Открытые системы. СУБД — 2015. — № 3. — С. 20–21. URL: http://www.osp.ru/os/2015/03/13046895 (дата обращения: 18.05.2016).

Андрей Егоров (ay@bekitzur.com) — ведущий инженер, компания BeKitzur, Александр Смирнов (Alexandr.Smirnov@motorolasolutions.com) — ведущий инженер, «Моторола Солюшнз» (Санкт-Петербург).