Попробуем применить многомерный анализ к данным временных рядов с помощью интерактивной визуализации данных измерений и их взаимосвязей.
Некоторые базовые принципы:
Визуализация данных измерений в различных разрезах и их взаимосвязях с другими. Отображение вложенных и скрытых измерений в данных;
Работа с данными в режиме реального времени, просмотр истории и прогнозирование временных рядов. Прошлое, настоящее и будущее – в некотором роде свои измерения времени;
Простой и удобный доступ ко всем данным, минимум лишних движений для получения результата. Интерактивность и наглядность в приоритете;
Гибкость в работе с данными. Возможность работы с данными как локально, так и обращение к внешним системам для визуализации данных;
Различные форматы предоставления результата: Stacked и линейные графики, диаграммы Ганта, сводные таблицы Pivot, просмотр исходных данных Raw.
Dimension UI - это настольное приложение, предназначенное для сбора, хранения, визуализации и анализа данных временных рядов.
Сбор и анализ данных в режиме реального времени, что позволяет отслеживать метрики в режиме онлайн, анализировать реакцию на различные виды воздействия, просматривать историю и проводить сравнительный анализ с другими показателями;
Гибкая и быстрая настройка профилей сбора данных. Эта функция особенно полезна, когда скорость имеет первостепенное значение и есть необходимость быстро собрать специальные статистические данные для более детальной оценки характеристик системы или компонента;
Локальное хранение в специализированной базе данных блочно-колоночного типа со встроенным сжатием данных и дедупликацией Dimension DB;
Продвинутые возможности по интеллектуальному анализу данных временных рядов с использованием Matrix profile и ARIMA;
Визуализация данных временных рядов во внешних БД по JDBC с использованием автоматической генерации SQL-запросов к источникам данных, режим No-code;
Система информационных панелей для отображения метрик из разных источников в одном интерфейсе. Быстрый доступ к метрикам облегчает работу по просмотру больших объемов анализируемых данных;
Система создания отчетов по собранным данным в формате PDF для последующего анализа.
Ниже приведено краткое описание каждого компонента. Изображений будет немного — по одному скриншоту на каждый компонент. Как всё работает в динамике, можно посмотреть в скринкастах.
Интерфейс Configuration
Для начала работы необходимо провести первоначальную настройку по определению источников данных с которыми мы будем работать и настроить конвейеры по сбору данных.
Скринкаст Configuration
Создаем профиль, к нему привязываем задание в котором указываем подключение по JDBC или HTTP и указываем запросы для получения данных. Запросы можно создавать самостоятельно или использовать предварительно настроенные из шаблонов.
Все элементы на расстоянии одного-двух кликов, можно настраивать достаточно сложные процедуры по сбору данных из различных источников. Очень гибкая система по сбору данных. Все подробности по опциям хранения есть в документации.
Интерфейс Workspace
Выбираем модель данных, по которой необходимо посмотреть информацию. Профиль → Задание → Запрос. И в запросе выбираем измерение для отображения. Переключаемся в просмотр данных в режиме реального времени — вкладка Real‑time или смотрим историю — вкладка History. Далее — выбираем любой диапазон для отображения данных и смотрим детализацию: Top в виде диаграмм Ганта, сводные таблицы с элементами диаграмм Ганта Pivot или просмотр исходных данных Raw.
Скринкаст Workspace
Если требуется просмотр данных по другим измерениям из запроса – переключаемся на вкладку Analyze, там уже отображается текущее измерение и к нему можно добавить любое из списка — многомерный анализ данных. Также в левой части снизу отображается Top по всем измерениям по выбранному диапазону — если заинтересовал какой‑то показатель из других измерений, по нему можно построить график с фильтром, который тоже будет добавлен на панель с графиками справа. Если показатели на графике большого размера — их можно скрыть Legend → Show/Hide, если графиков много и есть необходимо посмотреть только несколько из них — жмите Collapse All и выбирайте нужные из Dashboard-ов. Вернуть все обратно можно через Expand All.
По каждому измерению на вкладке Analyze можно посмотреть статистику по аномалиям и наличию повторяющихся значений во временных рядах. В настоящий момент для поиска аномалий — Anomaly detection и повторов в данных — Motif discovery, используется семейство алгоритмов Matrix profile, которое в основе своей считает Z‑нормализованное евклидово расстояние. Matrix profile очень простой, всего один параметр — окно расчета и график легко читать и интерпретировать. Все значимые всплески в верхней части графика — это аномалии в данных, тоже самое но в нижней части — повторяющиеся значения. Все просто.
Далее — на вкладке Search можно выполнить поиск по подстроке во всех измерениях запроса и получить график частоты вхождения подстроки во всех столбцах. По выбранному диапазону посмотреть исходные данные Raw.
Интерфейс Dashboard
Информационные панели Dashboard предназначены для отображения данных по любым измерениям из любых профилей в одном интерфейсе, в отличии от Workspace где мы можем смотреть только данные измерений по одному запросу для задания. В Workspace если заданий несколько — то одновременно по запросу на задание, каждая на своей вкладке.
Скринкаст Dashboard
В Dashboard можно выбирать практически любое количество измерений из разных профилей, также как и в Workspace, в Analyze интерфейсе скрывать их одним кликом по Collapse All/Expand All, скрывать наименования показателей в Legend Show/Hide, как на уровне всего интерфейса Dashboard так и по измерению. Можно скрыть детализацию и смотреть только на графики Detail Show/Hide. Переключаться между вкладками Real-time/History, менять диапазоны работы с данными. Все тоже самое и для измерения, с возможность для каждого измерения менять функцию группировки применяемую к данным.
Функции интерфейса Analyze в Dashboard находятся в детализации, по выбранному диапазону отображается график самих данных на вкладке Data, на вкладках Anomaly и Forecast смотрим статистику по аномалиям и наличию повторяющихся значений во временных рядах.
Интерфейс Report
Есть своя система создания отчетности. Можно создать PDF отчет по собранным данным по измерениям. На вкладке Design выбираем запросы, по каждому запросу нужные измерения для анализа, указываем произвольный диапазон для отображения данных жмем Show.
Скринкаст Report
На вкладке Design выбираем запросы, по каждому запросу нужные измерения для анализа, указываем произвольный диапазон для отображения данных жмем Show. При необходимости вносим правки, выбираем в детализации необходимую вкладку — и потом формируем отчет — жмем Report. PDF отчет отображается в предварительном просмотре на вкладке Report. Жмем Save и сохраняем отчет локально. Можно управлять файлами конфигурации Дизайна и Отчетов — открывать их, редактировать и удалять.
Интерфейс Ad-hoc
Компонент Ad-hoc позволяет подключаться к внешним базам данных и смотреть графики не загружая сами данные на локальный ПК.
Скринкаст Ad-hoc
Выбираем подключение Connection, затем схему или каталог Schema/Catalog и далее работаем с таблицей или представлением — указываем столбец данных, где хранятся метки времени и сами измерения — смотрим график по выбранному диапазону (Day, Week, Month) на вкладке Visualize. На вкладке Analyze также как и в Workspace — выбираем дополнительные измерения для анализа данных. Anomaly detection, Motif discovery и Forecast — аналогично как и в Workspace. Следует отметить, что можно выбрать произвольный диапазон на графике на вкладке Data — и по нему будет проводиться расчет в Anomaly и Forecast, если не выбрано — расчет идет по всем данным.
Рефакторинг
Изначально, проекты Dimension DB и Dimension UI начинались как БД FBase и Real Time Intelligence Desktop, которые были нацелены прежде всего на мониторинг в режиме реального времени. Данная функция в Dimension UI тоже осталась, но это сейчас не главное. Сейчас проект больше тяготеет к интерактивности и анализу данных измерений временных рядов в различных разрезах, поиск корреляций в данных и аномалий, motif discovery, forecasting. Также, длинные и непонятные названия тяжело воспринимать, когнитивная нагрузка имеет место быть. Поэтому для хранения данных измерений – Dimension DB, для их визуализации Dimension UI.
Далее будут некоторые идеи о том, что можно улучшить в приложении с точки зрения удобства использования пользовательского интерфейса — UX.
Необходимо унифицировать интерфейс работы с данными модели. Наиболее подходящим видится текущая реализация на вкладке Dashboard в левой части, её необходимо перенести на Workspace тоже. Также необходимо добавить возможность сокрытия ненужных деталей при выборе запроса, речь про список профилей и заданий.
Добавить в настройки dashboard‑а измерения расчет медианы, перцентилей. На вкладке истории нужна функция произвольного выбора диапазона дат Custom. Переработать логику работу с фильтрацией, пока добавить возможность наложения фильтра в Real‑time и History через функцию Filter и связать Workspace, Dashboard и Report через функцию Action, например из Workspace создавать необходимый dashboard измерения в Dashboard или в Report. Доступ к функциям Filter и Action через кнопку.
Очень сложный пункт. Это отображения графиков по измерениям в режиме предварительного просмотра (Preview) и в режиме интерактивности (Interactive). Все‑таки попытка совместить эти режимы работы с данными в одном месте пока выглядит не очень. Требуется разделить Preview и Interactive, чтобы в Preview можно было смотреть на картинку в целом списком или с помощью grid, с группировкой по профилям/заданиям — а в Interactive — переходить уже к развернутому варианту.
В Workspace нужен тоже режим разделения Preview и Interactive но уже по запросу, чтобы убрать ненужное количество переходов и дублирования (Real‑time→Analyze, History→Analyze). Как решение — перенести функции Analyze в детализацию, как это сделано в отображении данных измерения в Dashboard.
Добавить интерактивности в анализе данных для аномалий. Возможно для этих целей придется открывать новую вкладку на интерфейсе измерения Dashborad‑a. Формировать по диапазонам данных которые явно определены как аномалии или повторяющиеся значения систему визуализации — линейные графики, Gantt диаграммы.
В Report интерфейс достаточно прост и функционален с учетом решаемой задачи, можно добавить возможность просмотра истории по Day, Week etc. диапазонам на уровне дизайна и по выбранному измерению, добавить возможность определения данных отчетов детализации которые необходимо включить в отчет (Top, Pivot, Raw, Data, Anomaly, Forecast) и формировать шаблон страницы с детализацией. Настройки добавить в левой части от описания Description.
Ad‑hoc компонент тоже требует унификации. Таблицы и представления в одном модуле, каждая на своей вкладке, ниже добавить вкладки Timestamps и Columns. Сделать список измерений также как и на Dashboard, возможно подумать над тем, чтобы размещать графики по таблицам/представлениям в отдельных вкладках. На дальнюю перспективу — поддержка визуализации данных не только временных рядов.
Цветовые схемы при каждом создании нового графика генерируются в случайном режиме, иногда получаются достаточно резкие палитры цветов. Необходимо реализовывать функции по сохранению цветовых схем и привязывать их к запросам.
Если есть необходимость посмотреть статистики с использованием групповой функции COUNT и значений показателей больше чем 15, отображаются текущие 10 значений. Например есть необходимость посмотреть значения некоторых идентификаторов на графике, а всего их в наборе скажем сотня — Stacked отображение не поможет, все будет сливаться. Работает как для числовых так и текстовых типов данных. В этом варианте визуализации необходимо выполнить доработку табличного отображения данных, чтобы была возможность удобной навигации по данным.
Кодовая база пока не стабилизирована, идет постепенное удаление Dagger 2 в компонентах, в работе процесс унификации компонентов для отображения отчетов, элементов детализации. Что можно сделать лучше:
Перейтина True ООП — все объекты и обмен между компонентами и модулями через сообщения. Исторически для инверсии зависимостей использовался Dagger 2. Всем хорош, но — сопровождать тесты сложно, изолировать модули нет никакой возможности — везде надо прокидывать Dagger 2 специфичную обвязку для управления жизненным циклом объектов. По сути для тестов надо создавать отдельное приложение DaggerMainComponent с моками всех зависимостей. Конечно это сделано, и инфраструктура вся настроена, и UI тесты на Configuration есть — но это очень неудобно. Итог: для динамических приложений Dagger 2 не подходит. Посмотреть первое и второе приближение к идеалу — это реализация модулей в блоках Analyze и информационной панели Dashboard.
Унификация модуля отображения графиков данных. Частично уже есть в Dashboard, в модулях блока Analyze и Report. Преимущества повторного использование кода заметно стало, когда переносил логику отчетов в Report. Композиция все‑таки предпочтительней наследования. Кто бы мог подумать!
Поработать с кодом на предмет оптимизации, можно переписать часть функций на использование более красивых решений. Тесты пока не пишем, так как код часто меняется.
Известные проблемы
В общем приложение работает стабильно, но есть пара моментов, которые надо учитывать при эксплуатации:
Есть одна сложно диагностируемая ошибка. Возникает при визуализации данных по измерению в запросе в режиме Real‑time. В приложении активно используются виртуальные потоки, вероятно где‑то происходит блокировка при запуске обновления данных графика (срабатывает при получении события завершения сбора данных). Встречается очень редко, на Java 21 при запуске в режиме Debug из IntelliJ IDEA, ошибок в логах нет. Сколько не нагружал системы — воспроизвести не получилось. Подозреваю это какая‑то платформенная проблема с deadlock‑ами.
Редактирование настроек в Configuration может работать не совсем корректно, поэтому лучше пересоздавать все сущности с новыми именами. Встречается редко, просто пересоздаем необходимую сущность.
Ad‑hoc режим использовать на production аккуратно, смотреть performance — если что, можно использовать шаблоны для сбора информации по истории активных сессий и смотреть нагрузку через Dimension UI. Везде где возможно, ограничиваем объем обрабатываемых данных, но могут быть проблемы.
Есть поддержка не всех типов данных (BLOB‑ы не нужны для аналитики итп), поэтому могут быть ошибки при получении данных с таким типом данных. Или что‑то экзотическое, что еще не учтено. В настоящее время есть поддержка основных типов данных для следующих БД: PostgreSQL, Oracle, MS SQL и ClickHouse. Если возникают проблемы — смотреть журнал приложения.
Ограничения
Так как система гибридная, содержит в себе функции агента по сбору данных, их обработки, хранения, визуализации и анализа — требуется ПК среднего уровня с достаточным объемом памяти. Для работы самого приложения необходимо 2 Gb памяти и достаточно шустрых процессоров среднего уровня для нормальной работы с несколькими потоками сбора данных и визуализации. Все‑таки это сжатие данных, дедупликация, визуализация real‑time и все в памяти и на одном ПК. Если считать в числах, сколько графиков одновременно можно запускать в Dashboard — тестировали отображение свыше 50 графиков (real‑time) — все работает, замедлений нет.
Оценить объем данных, который можно загрузить в один поток достаточно просто. В Dimension DB который используется как backend для Dimension UI есть интеграционные тесты с помощью которых можно проверить производительность работы загрузки данных и получение результатов. Для самого быстрого, локального режима хранения данных Dimension DB со сжатием загрузка порядка 78 млн. строк (это данные за 2016 год) из БД Taxi из ClickHouse занимает порядка 19 минут (БД занимает объем 12 Gb). Всего в БД Taxi тестовых данных 1,3 млрд. строк, 130 Гб на диске — это в сжатом виде, коэффициент сжатия примерно 3. Итого: за секунду записано ~ 68 000 строк, при среднем размере строки 100 байт, примерно 7 Мб сжатых данных, сырых данных обработано раза в 2–3 больше в секунду, так как используется JDBC.
Сбор данных происходит с определенным интервалом, который указывается в настройках задания. Все запросы выполняются каждый в своем виртуальном потоке и время запуска строго регламентировано — через каждые 1, 3, 5 итд. секунд. Если запрос + обработка выполняется дольше — в логах приложения будет сообщение — Task execution took too long ({}ms), more than task pull timeout. Эту ситуацию можно также будет видеть на графиках — будут пропуски в графиках. По хорошему — надо добавлять мониторинг каждого сбора данных и где‑то добавлять сигнализацию на такие случаи. То есть необходимо понимать, что за время между запусками задания приложение должно их получить с внешней системы и обработать локально, об этом было в предыдущем пункте. Если у вас медленные каналы связи или есть проблемы с забором данных — нужно увеличивать pull timeout. Как вариант — в планах добавить дополнительную настройку к уже существующей: сбор данных в режиме клиента (CLIENT mode) в локальную БД или подгрузка уже сформированных данных на сервере в локальную БД (SERVER mode). Назвать ее HYBRYD и работать с данными в real‑time режиме без сохранения локально.
Пример расчета: средний объем получаемых данных в секунду запросом ~ 68 000 строк, средний размер строки 300 байт. Порядка 20 Мб данных в секунду нужно загрузить в приложение. Используется сеть 1 Gbit Ethernet, для которой скорость передачи 20 Мб в идеальных условиях будет примерно 0,16 секунды. В этому случае pull timeout необходимо выбирать равный 3 секундам и выше. За pull timeout в 1 секунду обработать корректно такой объем данных (загрузить по сети, сохранить в БД и показать на графике) не получится.
Где можно использовать
Мониторинг информационных систем, программно‑аппаратных комплексов и баз данных в режиме реального времени;
Оценка работы программно‑аппаратных комплексов в ходе нагрузочного и стресс‑тестирования, подготовка отчетов по результатам тестирования;
Мониторинг параметров устройств «Интернета вещей» (англ. internet of things, IoT);
Решение задач комплексного мониторинга информационной безопасности систем с доступом к источникам данных по API JDBC и HTTP (Prometheus);
Использование приложения для обучения на курсах, связанных с обработкой и анализом данных, в которых требуется выполнять быструю настройку сбора данных с тестовых систем, визуализацию с возможностью продвинутого анализа данных для демонстрации тех или иных концепций, например для обучения системных администраторов, администраторов БД, разработчиков и аналитиков;
Диагностика проблем в работе комплексных систем предоставляющих API для доступа к данным мониторинга по JDBC и HTTP (Prometheus). Например, для детальной диагностики работы систем и их компонентов в гетерогенном окружении, микросервисы на Java работающие с БД;
Визуализация и многомерный анализ собранных данных временных рядов в локальной БД в режиме реального времени, историческом разрезе и предиктивная аналитика для различных типов приложений по JDBC и HTTP (Prometheus);
Визуализация и многомерный анализ данных временных рядов для таблиц и представлений во внешних базах данных Postgres, Oracle, Microsoft SQL Server, ClickHouse по протоколу JDBC без написания SQL (No-code режим).
Используемые библиотеки
Исходники проекта
Dimension UI — настольное приложение, предназначенное для сбора, хранения, визуализации и анализа данных временных рядов.
Если есть вопросы — можно обратиться к документации по проекту. Подробная инструкция по сборке приложения в README, там же есть ссылки на инструкцию пользователя.
Приложение разработано при поддержке «Фонда содействия инновациям».
Вроде все, спасибо за внимание!