Русский
Русский
English
Статистика
Реклама

Ignite

Обогащение данных что это и почему без него никак

15.04.2021 06:04:33 | Автор: admin

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

Сам термин "обогащение данных" это перевод англоязычного Data enrichment, который проводит аналогию между данными и... ураном. Точно так же, как промышленники насыщают урановую руду, увеличивая долю изотопа 235U, чтобы её можно было использовать (хочется надеяться, в мирных целях), в процессе обогащения данных мы насыщаем их информацией.

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

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

Заметим, что обогащение данных термин широкий, и получать данные из внешних источников можно весьма разнообразными способами. Например, представим бизнес-процесс регистрации нового клиента. Если в данных этого клиента отсутствует e-mail, то взаимодействие с внешним источником в этом случае может быть буквально следующим: взяли телефон, позвонили клиенту, узнали его e-mail. Получается, этот процесс может включать в себя такие совершенно не автоматизированные операции, как обычный телефонный разговор со всеми этими эс как доллар, "а" как русская. Это тоже можно считать обогащением данных, но данный пласт проблем в этой статье мы затрагивать не будем. Нас интересуют вполне конкретные случаи, когда данные хранятся в базе данных и именно БД служит внешним источником данных для обогащения.

Источниками сырых исходных данных могут быть:

  • Система кассовых платежей, которая отслеживает транзакции и отправляет в хранилище данных: время, id торговой точки, количество и стоимость купленного товара и т.д.

  • Логистическая система, которая отслеживает движение товара: id транспорта и его водителя, gps-координаты в заданные моменты времени, статус, маршрут и т.д.

  • Телеметрия с датчиков интернета вещей.

  • Система мониторинга инфраструктуры.

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

Таким образом, типовую задачу можно сформулировать следующим образом: на вход поступают данные вида <таймстамп, идентификатор источника, содержимое пакета>, а конечному потребителю требуется соединить (в смысле join) справочную информацию об источнике из хранилища данных с идентификатором источника из сырых данных.

Как обогащаем данные

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

Другой вариант использовать инструменты потоковой обработки данных. В этом случае нужно определиться, где же всё-таки хранить справочную информацию и что будет являться Single Source of Truth (SSOT), или единым источником истины для справочных данных. Если хранить справочные данные в хранилище, то к нему придется каждый раз обращаться, и это может быть накладным, так как к сетевым издержкам добавится ещё и обращение к диску. Вероятно, оптимальнее хранить справочную информацию в оперативной памяти или другом горячем хранилище, например, в Tarantool.

Мы, очевидно, отдаём предпочтению именно последнему варианту, и наша схема приобретает завершенный вид.

Она отличается от первой иллюстрации процесса обогащения данных тем, что появилась конкретика: процесс обогащения происходит на лету с помощью потокового обработчика, справочные данные хранятся в горячем хранилище (оперативной памяти).

Давайте посмотрим, какие плюсы и минусы мы получим, если возьмем за основу данную схему.

Преимущества потокового обогащения данных:

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

  • Схема хорошо масштабируется, если подобрать соответствующие технологии. С правильными инструментами можно масштабироваться под требуемую пропускную способность платформы и под объемы справочной информации.

Недостатки:

  • Источник истины для справочной информации вынесен из надёжного дискового хранилища данных в менее надёжную оперативную память. При сбое это грозит потерей всех несинхронизированных данных.

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

Какие технологии используем

Что касается технологий, то мы выбираем более-менее устоявшиеся на рынке решения с открытым исходным кодом и хорошей документацией, учитывая совместимость.

Выбранный стек технологий:

  • Apache Kafka источник данных и брокер очередей;

  • Apache Spark потоковый обработчик данных;

  • Apache Ignite горячее хранение справочной информации;

  • Greenplum и Apache Hadoop хранилище данных.

В выборе Greenplum мы немного поступились совместимостью. Связать его со Spark не совсем тривиальная задача, для этого не существует стандартного open source коннектора (подробнее рассказывали в этой статье). Поэтому мы разрабатываем такой коннектор сами.

В остальном набор достаточно стандартный. Hadoop держим на всякий случай, например, чтобы использовать тот же Hive поверх HDFS вместо Greenplum.

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

Итак, вот окончательные очертания нашей схемы обогащения данных.

Версии, которые используем:

  • Apache Spark 2.4.6.

  • Apache Ignite 2.8.1.

  • Apache Kafka 2.4.1.

  • Greenplum 6.9.0.

  • Apache Hadoop 2.10.1.

Обращаю на это внимание, потому что от версий выбранных компонент зависит совместимость и возможность этих компонент взаимодействовать. Например, если нужно, чтобы Apache Spark писал данные в базу данных Greenplum, это может стать отдельной проблемой, и версии также будут важны. Наш коннектор на текущий момент работает именно со Spark v2, для Spark v3 его нужно отдельно дорабатывать.

Что в результате

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

Но есть и ограничения, связанные с тем, что source of truth, по сути, находится в оперативной памяти. Поэтому при редактировании справочной информации надо напрямую работать с Ignite через интерфейсы самого Ignite. Кроме этого, нужен аккуратный механизм синхронизации, чтобы кэш Ignite был персистентным. У Ignite есть собственный механизм для записи на диск, но все же Ignite больше ориентирован на работу в ОЗУ, поэтому для резервирования справочной информации в хранилище данных лучше использовать что-нибудь специально для этого предназначенное, например, Airflow.

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

Пользуясь случаем: мы расширяем отдел систем обработки данных. Если вам интересно заниматься с подобного рода задачами, пишите мне в личку, в телеграм @its_ihoziainov или на job@itsumma.ru с пометкой data engineering.

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

Подробнее..

Мониторинг распределенной системы с помощью Zabbix на примере Apache Ignite

01.12.2020 06:16:56 | Автор: admin

Вступление

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

Наиболее распространенные проблемы:

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

  • Влияние мониторинга на работу системы сбор метрик может быть достаточно затратен для конечной системы.

  • Излишняя сложность система мониторинга должна быть той частью, которой вы доверяете. Чем сложнее решение, тем выше вероятность отказа, особенно в случае каких-либо изменений.

Общие рекомендации при построении системы мониторинга:

  • Проще лучше.

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

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

  • Автоматизируйте регулярно выполняемые действия ручные действия при увеличении количества узлов неминуемо приведут к ошибкам.

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

Создание шаблона

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

Apache Ignite это in-memory computing platform, платформа используемая как кэш, распределённая вычислительная система и база данных. Начать более подробное изучение продукта можно с официальной документации. Ключевые внешние показатели производительности системы это практически стандартный набор:

  • Загрузка CPU

  • Утилизация RAM

  • Утилизация дисков в случае persistence

  • Сеть

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

Снижение внешних показателей, до предельных значений, будет говорить о сбоях в аппаратной части, которые распределённые системы, как правило, переживают без последствий или о полной недоступности системы, когда сервис уже недоступен. Для того, чтобы обнаруживать опасные ситуации заранее, до момента возникновения инцидента, необходимо контролировать и внутренние показатели продукта. На момент написания статьи готовых шаблонов для Apache Ignite не было, поэтому напишем свой.

Так как Ignite написан на Java, основным способом мониторинга для него будет являться JMX. Если мы просто скачаем и запустим Ignite, jmx-порт будет открыт на первом свободном порту между 49112 и 65535. Для мониторинга нас такой подход не устраивает, так как, как правило, порт настраивается заранее и способов его автоматического определения по умолчанию нет. После ознакомления со скриптом запуска становится понятно, что для того, чтобы самому указать необходимый порт, можно использовать переменную окружения IGNITE_JMX_PORT. Таким образом, выполнив команду export IGNITE_JMX_PORT=49112 и запустив узел, мы получим доступ к JMX на известном нам статическом порту.

Начиная с версии Ignite 2.10, jmx-порт задаётся по другому

Начиная с версии 2.10, это поведение изменено и в будущих версиях необходимо использовать переменную JVM_OPTS. Открыть jmx-порт можно следующим образом:

export JVM_OPTS="-Dcom.sun.management.jmxremote \-Dcom.sun.management.jmxremote.port=49112 \-Dcom.sun.management.jmxremote.authenticate=false \-Dcom.sun.management.jmxremote.ssl=false"

Особенность, на которую стоит обратить внимание, по умолчанию в пути к mbean присутствует classloader, который будет меняться после каждого перезапуска узла. Он добавлялся для возможности запуска нескольких инстансов Ignite в рамках одной JVM, чтобы избежать конфликта метрик, но сейчас это не наш случай. Для нас же это будет значить, что zabbix будет обнаруживать метики заново после каждого перезапуска. Решить эту проблему можно, добавив JMX-опцию -DIGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false, она уберёт classloader из пути.

mbean с classloadermbean с classloader

Ignite находится в opensource, поэтому если вы уверены, что какая-то функциональность должна работать по-другому, то вы можете принять участие в разработке. В данном случае я так считаю и сразу завёл задачу в JIRA ASF.

В результате дерево метрик будет выглядеть следующим образом:

Интерфейс jconsoleИнтерфейс jconsole

Чтобы облегчить процесс добавления новых метрик себе и упростить процесс их изменения в дальнейшем, в первую очередь определим, какие объекты имеют схожую сущность. В Java для этого, как правило, используется реализация интерфейса. В нашем случае, изучая, например, метрики в разделе Thread pool, можно увидеть, что все объекты реализуют интерфейс ThreadPoolMXBean.

Описание объектаОписание объекта

В рамках решаемой задачи нас интересует тот факт, что каждый из этих объектов будет иметь один базовый набор метрик. Применительно к шаблонам zabbix это означает, что мы можем настроить discovery rule для этих метрик, после чего сервер мониторинга будет обнаруживать все идентичные объекты на основе нашего правила и применять к ним шаблон.

Например, правило для обнаружения всех dataRegion будет выглядеть следующим образом:

Создание правила обнаруженияСоздание правила обнаружения

В качестве значения {HOST.CONN}:{HOST.PORT} zabbix будет подставлять адрес, по которому доступен узел, с применённым шаблоном и указанное в качестве jmx-порта значение.

Дебаг jmx discovery

Если возникнет необходимость отдебажить обнаружение в JMX, это можно сделать с помощью команды zabbix_get. Пример discovery-запроса списка дата-регионов:

zabbix_get -s localhost -p 10052 -k '{"request":"java gateway jmx","jmx_endpoint":"service:jmx:rmi:///jndi/rmi://HOST:49112/jmxrmi","keys":["jmx.discovery[beans,\"org.apache:group=DataRegionMetrics,name=*\"]"]}' 

Результат будет выглядеть следующем образом следующий результат:

{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=sysMemPlc",   "{#JMXNAME}":"sysMemPlc",   "{#JMXGROUP}":"DataRegionMetrics"},{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=default",   "{#JMXNAME}":"default",   "{#JMXGROUP}":"DataRegionMetrics"},{   "{#JMXDOMAIN}":"org.apache",   "{#JMXOBJ}":"org.apache:group=DataRegionMetrics,name=TxLog",   "{#JMXNAME}":"TxLog",   "{#JMXGROUP}":"DataRegionMetrics"}

Пример шаблона метрики:

Создание метрики на основе правила обнаруженияСоздание метрики на основе правила обнаружения

Параметры {#JMXNAME} и аналогичные zabbix берёт из результата discovery-запроса.

В итоге я выделил несколько групп метрик, для которых стоит использовать механизм discovery:

  • Дата-регионы

  • Кэш-группы

  • Кэши

  • Пулы потоков

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

Развертывание и автоматизация

Имея все необходимые шаблоны и понимание работы продукта, настроим мониторинг тестового стенда. Для изоляции процессов я буду использовать docker.

Как это всё будет работать:

  1. Zabbix server регистрирует новый узел после получения первого запроса от zabbix agent.

  2. Zabbix server выполняет скрипт, который добавляет jmx-порт и применяет шаблоны к новому узлу.

  3. Zabbix server начинает посылать запросы на Java gateway, который, в свою очередь, опрашивает приложение и возвращает метрики.

  4. Zabbix agent получает от сервера список собираемых активных метрик и начинает их отправлять на zabbix server.

  5. Zabbix server запрашивает значения пассивно собираемых метрик у zabbix agent.

Метрики от приложения поступают по JMX, новые узлы регистрируются после первого обращения zabbix agent к серверу.

Подробнее о том почему в п.2 используется самописный скрипт
  • Изначально было желание использовать функционал zabbix, но zabbix из коробки не умеет присваивать jmx port новым узлам, а без этого нельзя привязать шаблон, использующий JMX. Предложение по доработке есть в jira zabbix с 2012 года, но оно до сих пор в open.

  • Реализация данного функционала через API возможна, но потребует создания служебного пользователя и будет более тяжелой в случае необходимости регистрации большого количества узлов.

  • Вариант через базу данных, описанный в тикете, возможно, применим для postgresql, но не работает на Oracle, MySQL и MariDB, так как в этих БД нельзя настроить триггер, который будет делать вставку в ту же таблицу, на которой он сработал.

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

Схема тестового окруженияСхема тестового окружения

Как установить:

  1. Скачиваем и устанавливаем docker и docker-compose, если они ещё не установлены.

  2. Скачиваем все необходимые файлы из репозитория.

  3. Переходим в скачанную папку.

  4. Запускаем сборку образа: docker-compose -f docker-compose-zabbix.yml build

  5. Запускаем кластер и сервер мониторинга: docker-compose -f docker-compose-zabbix.yml up

  6. Через несколько секунд zabbix будет доступен на 80 порту. Учётная запись по умолчанию Admin / zabbix.

Как импортировать шаблоны:

  1. Идём на вкладку Configuration->Templates->Import и импортируем шаблон ignite_jmx.xml (находится в папке, скачанной ранее). Вместе с самим шаблоном будет добавлена группа Templates/Ignite autoregistration, это название будет использоваться далее для добавления шаблонов из этой группы к новым узлам.

  2. В каждом шаблоне, который должен быть применён, указываем созданную на предыдущем шаге группу. Шаблон Template App Ignite JMX в ней уже содержится, я добавил Template App Generic Java JMX и Template OS Linux by Zabbix agent.

Создаём скрипт для авторегистрации агентов:

  1. В интерфейсе zabbix переходим на вкладку Configuration->Actions, в выпадающем списке выбираем Autoregistration actions и создаём новое действие.

  2. Даем название действию. Можем настроить условия добавления узла.

  3. В операциях добавляем пункт Add host. Это создаст новый узел в zabbix в случае выполнения условий, указанных ранее.

  4. Добавляем запуск скрипта autoreg.php, который будет добавлять jmx-порт в настройки и применять шаблоны из указанной группы к переданному узлу. Для тех, кто разворачивает тестовый кластер из образа, он будет находиться в папке /var/lib/zabbix, для тех, кто устанавливает самостоятельно, в репозитории, указанном выше. Запускаться в моём случае он будет командой php /var/lib/zabbix/autoreg.php {HOST.HOST} 'Templates/Ignite autoregistration' '{HOST.METADATA}'. Должно получиться так:

Добавление запуска скрипта в правило авторегистрацииДобавление запуска скрипта в правило авторегистрации

Если всё было сделано корректно, узлы должны появиться в zabbix с настроенным jmx-портом и применёнными шаблонами из группы. Если что-то пошло не так, первое, что рекомендую проверить, Reports->Audit log.

Результаты и куда двигаться дальше

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

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

Помимо Apache Ignite в вашем решении, вероятно, будет присутствовать ещё немало компонентов, таких как клиентские приложения, фронтенды, очереди, сетевое оборудование, СХД и тому подобное, всё это также требует мониторинга, без которого часть аварийных ситуаций не будет вовремя обнаружена.

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

Что почитать

  1. Site Reliability Engineering

  2. Zabbix documentation portal

  3. Готовый инструмент для мониторинга и управления Ignite и Gridgain

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru