Расширение инфраструктуры телекоммуникационных сетей и усложнение оборудования приводят к увеличению объемов данных, описывающих работу системы, что существенно усложняет обнаружение в ней узких мест и планирование дальнейшего развития. Сложность обработки и анализа данных обуславливается тем, что разнородная информация собирается с многочисленных узлов: от базовых станций поступают статистика о функционировании передатчиков, их состоянии и данные о диагностике ПО; с контроллера сети — информация о совершенных абонентами звонках, преданных данных и возникших ошибках в работе сети и т. п. Собранные данные могут быть представлены в различных исходных форматах (бинарном, упакованном, текстовом). Все это приводит к тому, что входную информацию необходимо привести к удобному формату, пригодному для последующего анализа, синхронизировать по времени и учесть зависимости между данными, полученными из многочисленных узлов системы. Массивы данных для анализа могут измеряться миллиардами строк, операции с ними — задача непосильная даже для экспертов, а попытки ее упростить, используя традиционные инструменты, приводят к созданию паллиативных решений, которые, как правило, имеют предел масштабируемости и теряют эффективность начиная с определенного объема данных — например, Microsoft Excel перестает справляться с документами, содержащими более одного миллиона строк. Кроме того, требуются специфические для выбранного инструмента навыки по автоматизации вычислительного процесса — например, знание Visual Basic и умение создавать и использовать макросы Excel. Для работы с такими инструментами необходимы дополнительные действия (обычно выполняемые вручную) по первичной обработке и подготовке данных для их удобного использования в выбранной программе. Например, для уменьшения объема передаваемых в бинарном виде данных от телекоммуникационного оборудования производится их декодирование.
На преодоление всех этих сложностей инженеры тратят немало времени, вместо того чтобы следить непосредственно за поведением системы. Для мониторинга работы телекоммуникационной системы требуется инструментарий , который способен учитывать стремительный рост объема телеметрии и позволяет автоматизировать ее сбор и анализ. Горизонтально масштабируемое решение для конвейерной обработки Больших Данных, поступающих от телекоммуникационного оборудования, созданное на базе таких инструментов, как Spring Framework (spring.io), HDFS [1] и Hadoop [2], обеспечивает анализ потоков телеметрии от оборудования, индексирование результатов и их визуализацию, например в системах Elasticsearch и Kibana .
На рис. 1 представлена схема потоков данных от источника к получателю. Все данные, поступающие от телекоммуникационного оборудования, складываются для долговременного хранения и последующего анализа в Swift — распределенное объектное хранилище, предназначенное для безопасного хранения и организованное по принципу «ключ-значение» («ключ» — уникальное имя файла, «значение» — файлы в любом формате). В нашем случае в Swift размещаются бинарные и текстовые файлы, запакованные с помощью утилиты bzip2. Аргументом в пользу Swift является то, что Hadoop поддерживает параллельное копирование (утилита distcp) файлов из этого объектного хранилища в HDFS, над которым уже будут проводиться все дальнейшие операции.
.png "Рис. 1. Схема потоков данных от телекоммуникационного оборудования") |
| Рис. 1. Схема потоков данных от телекоммуникационного оборудования |
На этапе подготовки данных, как правило, производится их предварительная обработка с целью оставить только значимую информацию и преобразовать данные из исходного представления в формат, удобный для дальнейшего использования. Например, для закрытого формата бинарных файлов требуется обрабатывать каждый файл целиком на одном вычислительном узле, преобразуя его из бинарного представления в текстовое. Кроме того, необходимо распаковать текстовые данные из формата bzip2. Обе эти задачи можно решать средствами языка Pig [3].
После завершения подготовительного этапа, когда все данные загружены в HDFS в нужном формате, начинается их обработка, например с привлечением языка скриптов Pig Latin. Для визуализации полученных результатов они загружаются в Elasticsearch — распределенное индексное хранилище, реализованное на движке Apache Lucene, которое предназначено для текстового поиска и поддерживает интерфейс RESTful.
Визуализация результатов анализа осуществляется с помощью веб-приложения Kibana, которое запрашивает данные из Elasticsearch и представляет их в графическом виде. Приложение выполняет статистические расчеты: определяет количество записей; производит вычисление среднего, минимального или максимального значений и т. д. Изображение веб-приложения Kibana показано на рис. 2, в верхней части которого приводится краткая статистическая информация: количество отображаемых отсчетов и максимальное количество активных устройств в одной из ячеек сотовой сети, а внизу — диаграмма времени, показывающая совокупную информацию о количестве активных устройств в пяти выбранных ячейках сотовой сети для заданного интервала времени. Такая визуализация позволяет оператору моментально определить самые загруженные ячейки сотовой сети и интервалы времени с максимальной нагрузкой. Далее, на основании этой информации, можно принять решение о необходимости изменения конфигурации сети или ее модернизации.
.png "Рис. 2. Пример визуализации результатов") |
| Рис. 2. Пример визуализации результатов |
На рис. 3 представлена архитектура решения для анализа функционирования телекоммуникационного оборудования. Базовым компонентом является распределенная файловая система HDFS, которая может быть развернута практически на любом оборудовании. Манипуляции с данными и вычисления реализуются на языке Pig Latin, команды которого преобразуются в последовательность операций MapReduce с помощью транслятора, встроенного в Pig, что позволяет исключить работу с функциями Hadoop низкого уровня. Стоит отметить, что Pig поддерживает как «встроенные» операции (фильтрация, группировка, сортировка и т. д.), так и специфические функции, определяемые пользователем (User Defined Functions, UDF), которые могут быть необходимы для выполнения нестандартных преобразований или сложных расчетов. Например, нестандартная задача преобразования бинарных файлов в текстовый формат решается с помощью специальной реализации загрузчика PigLoader для Pig.
.png "Рис. 3. Архитектура решения") |
| Рис. 3. Архитектура решения |
Для выполнения многоэтапного анализа данных используются два фреймворка: Spring Batch — универсальный инструмент для организации конвейера различных задач обработки мониторинговой информации, собранной с телекоммуникационного оборудования, например Pig-скриптов; Spring Batch Admin — веб-приложение, поддерживающее RESTful API, для управления конвейером и мониторинга состояния его этапов.
Spring Batch представляет собой связующий компонент для организации анализа, отвечающий за запуск отдельных этапов обработки данных в заранее определенной последовательности. Очередность выполнения шагов описывается в виде XML-документа, основным элементом которого является определение задачи (job), состоящей из последовательности шагов (step). Каждый шаг определяет запускаемый скрипт с набором параметров и значение атрибута next, указывающее на следующий выполняемый шаг. Задавая таким образом шаг за шагом, в конце концов можно получить готовый конвейер. Кроме того, одним из интересных элементов Spring Batch является split, позволяющий описать параллельный запуск нескольких потоков (flow). При этом каждый поток также представлен набором последовательно запускаемых шагов.
Еще одной интересной возможностью Spring Batch является поддержка условных переходов с помощью элемента decision — выбор следующего шага будет осуществлен в зависимости от того, удовлетворяется ли некоторое условие. Spring Batch — не единственный фреймворк такого типа, существуют и другие решения для организации конвейера: Oozie описывает последовательность запуска шагов в виде XML-документа и обеспечивает сопоставимую со Spring Batch функциональность, однако требует отдельной установки и конфигурирования, что не всегда удобно; Azkaban описывает последовательность запуска шагов в виде текстового файла, но имеет ограниченную функциональность по сравнению со Spring Batch и Oozie.
***
Предложенное решение для автоматизированной подготовки, обработки и анализа больших объемов данных, поступающих от телекоммуникационного оборудования, отличается высокой масштабируемостью, которая достигается за счет расширяемости таких средств, как Swift и Elasticsearch, а также технологий из стека Hadoop, что позволило значительно упростить развертывание решения, снять ограничения на длительность интервалов времени для анализа и открыло возможность для проведения точных статистических вычислений.
Литература
- Дмитрий Волков, Лев Левин. Большие Данные и суперкомпьютеры // Открытые системы.СУБД. — 2014. — № 7. — С. 21–22. URL: http://www.osp.ru/os/2014/07/13042912 (дата обращения: 18.09.2015).
- Леонид Черняк. Hadoop против Big Data // Открытые системы.СУБД. — 2010. — № 7. — С. 46–47. URL: http://www.osp.ru/os/2010/07/13004186/ (дата обращения: 18.09.2015).
- Леонид Черняк. Платформы для Больших Данных // Открытые системы.СУБД. — 2012. — № 7. — С. 10–14. URL: http://www.osp.ru/os/2012/07/13017635 (дата обращения: 18.09.2015).
Андрей Егоров (Andrei.Yegorov@motorolasolutions.com), Александр Смирнов (Alexandr.Smirnov@motorolasolutions.com) — ведущие инженеры, «Моторола Солюшнз» (Санкт-Петербург).
