Читать нас в Telegram

Почему Elasticsearch — хороший выбор для сбора и анализа данных среднего объёма

Рубрика: Блоги
3 февраля 2019 01:32
22284
4

Рассказывает Франсуа Руа, руководитель отдела разработки ГК «Авилекс»


Контекст задачи

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

Часто бывает так, что масштаб проекта ещё недостаточно велик для внедрения крупных программных платформ наподобие Hadoop, и в этом случае вам помогут универсальные варианты на базе стандартных NoSQL-решений, которые позволят справиться с накоплением и обработкой данных среднего объёма.

К таким решениям, исходя из нашей практики, относится Elasticsearch.

Что такое Elasticsearch

Elasticsearch — это представитель кластерных NoSQL с JSON REST API.

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

Аппаратная платформа — Java Virtual Machine.

Официальные клиенты доступны на Java, NET (C#), Python, Groovy, JavaScript, PHP, Perl, Ruby.

Elasticsearch разрабатывается компанией Elastic вместе со связанными проектами, называемыми Elastic Stack, — Elasticsearch, Logstash, Beats и Kibana.

Beats — легковесные агенты и отправители данных с различных устройств. Logstash собирает и обрабатывает данные зарегистрированных событий. За хранение и поиск данных отвечает Elasticsearch. Kibana визуализирует данные через web-интерфейс.

Сегодня Elastic Stack с успехом используется сервисами eBay, Adobe, Uber, Nvidia, Blizzard, Citibank, Volkswagen, Microsoft, SoundCloud, GitHub, Netflix, Amazon. Чем же привлекателен Elasticsearch в контексте поставленной задачи? Давайте разберёмся.

Простой выбор

Одним из пунктов технического задания в рамках нашего проекта было требование собирать и анализировать статистику примерно с 25 (+/- 5) тысяч различных устройств.

Аппаратные возможности, операционные системы, сетевые интерфейсы, типы и назначение устройств неоднородны — от смартфона и телевизора до инфраструктурного сервера.

Устройства находятся в отдельных зданиях (примерно 1500 зданий, в каждом от 10 до 20 устройств), обслуживаются однотипной, но изолированной от других зданий инфраструктурой.

Оценив поставленную задачу, мы поняли, что нам не нужна большая суперсистема, которую можно отнести к категории BigData и/или HighLoad. С другой стороны, любые привычные методы сохранения и обработки информации, такие как запись в текстовый файл или SQL-базу, не подходили из-за объёма и специфики данных, поскольку большая часть работы происходила с логами устройств. Сыграло свою роль и наличие дополнительной статистики, которую сообщают сервисы, запущенные на устройствах.
Также в нашем случае по оценке объёма входящих данных, скорости их поступления и озвученных задач аналитики не было необходимости отдельно строить OLTP- и OLAP-системы.

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

Да и Elastic Stack в целом предназначен для решения такого класса задач.

А что, собственно, собираем?

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

Что на базе собранной информации хотят получить аналитики и менеджеры?

Самый частый из встречающихся сценариев — он же был изначально озвучен в техническом задании — это сбор и хранение всей (сырой) статистики по всем устройствам и сервисам за последний месяц с последующей агрегацией по дням и группировкой по зданиям с «бессрочным» хранением полученного результата.

Raw-индексы перезаписываются каждый месяц новыми данными, Agg-индексы накапливаются по дням «бесконечно» (пока хватает дискового пространства).

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

Периодически некоторые данные, чаще всего новые, получаемые из исходных, выделяются в отдельную задачу предварительного расчёта, которая выполняется с помощью вычислительной платформы Spark «по расписанию» и сохраняется в ещё один Agg-индекс, откуда эти подготовленные данные попадают в сложные отчёты и т. д.

Немного фактов о системе

Elasticsearch, как выяснилось, прекрасно подходит для работы в пределах определённого объёма данных (2–10 терабайт в год, 20–30 миллиардов документов в индексах), а также хорошо интегрируется с кластером Spark.

Агенты (Beats) помогают на конкретном устройстве или конкретном сервере собрать информацию, которая интересует пользователей системы. С помощью этих агентов можно собирать разного рода данные: системную информацию Windows из журнала, логи операционной системы Linux, данные устройства на ОС Android, самим анализировать трафик с устройства, будь то TCP, HTTP и т. д.

Локальный для инфраструктуры каждого здания Logstash отлично справляется с отправкой данных, собираемых агентами устройств, в централизованный кластер Elasticsearch, а Kibana предоставляет удобный способ построения веб-отчётов.

Необходимые инфраструктурные ресурсы

В нашем случае используется Linux-кластер в составе 3–10 нод.

Нода — это 8 процессорных ядер, 16–32 гигабайта оперативной памяти, жёсткий диск размером 1–5 терабайт. Сеть 1 Гигабит.

Масштабируемость

Данная подсистема статистики может работать с любой сферой деятельности, где требуется сбор и анализ статистических данных среднего объёма. Это может быть обработка статистической информации с 1 000 и до 30 000 холодильников, мобильных устройств, ноутбуков, интерактивных панелей и т. д.

Когда устройств меньше, чем 1–3 тысячи, система избыточна, есть более простые решения. Количество в 10 000–30 000 единиц оптимально по объёму и скорости появления новых данных с устройств.

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

Хотя, если мы воспринимаем 50–100 тысяч устройств как три сегмента по 15–30 тысяч, то можно просто запустить три подсистемы нашей статистики.

Основная идея заключается в том, что чем более изолированы «сектора», тем проще применить решение формата «три по тридцать».

Заключение

На примере проекта городского масштаба мы рассмотрели применение Elasticsearch для работы с большими данными, оценили его преимущества и целесообразность применения для задач, где массивные решения вроде Hadoop избыточны.

Призы для программистов — нужно пройти опрос. Больше ответов — больше шансы

, последний центурион

Темы: Big Data
0