¶ Основная теория
¶ Визуализация больших данных
На предыдущих этапах мы построили полноценный конвейер обработки данных. Собрали сырые данные в озеро, очистили их с помощью Apache Spark, загрузили агрегаты в колоночную СУБД ClickHouse и настроили брокер сообщений RabbitMQ для асинхронных вычислений.
Сами по себе базы данных и очереди сообщений не несут ценности для конечного бизнес-пользователя. Для представления результатов обработки данных используются системы Business Intelligence (BI), а также интерактивные аналитические панели (дашборды).
Дашборд (Dashboard) — визуальный интерфейс, который предоставляет ключевую информацию (метрики, графики, таблицы), необходимую для достижения одной или нескольких целей. Информация при этом скомпонованна на одном или нескольких экранах для удобного мониторинга.
Пара особенностей визуализации больших данных:
- агрегация на лету: BI-системы отправляют аналитические SQL-запросы в OLAP-базы (ClickHouse) и отрисовывают уже агрегированные данные
- асинхронность: если пользователь инициирует тяжелый расчет, то интерфейс не должен зависать; В таких случаях фронтенд отправляет задачу в очередь и ждет результат
¶ Фреймворк Streamlit
В индустрии для создания дашбордов часто применяют готовые BI-решения (Apache Superset, Yandex DataLens, Metabase). Однако для создания кастомных интерактивных приложений, где объединяется аналитика и сложная бизнес-логика (как поиск слотов), дата-инженеры и аналитики активно используют Python-фреймворки.
Принципиальное отличие Streamlit от классических веб-фреймворков — модель перезапуска. При каждом взаимодействии пользователя с элементом интерфейса (нажатие кнопки, изменение значения в выпадающем списке и т.д.) Streamlit полностью перезапускает скрипт сверху вниз. Это означает, что обычные переменные Python не сохраняют состояние между взаимодействиями. Для сохранения данных между перезапусками используются специальные механизмы.
Декоратор @st.cache_data позволяет кэшировать результат функции (можно настроить TTL). При повторном вызове с теми же аргументами функция не выполняется заново, а возвращает сохранённый результат. Декоратор @st.fragment позволяет выделить часть UI в независимый блок, который перезапускается изолированно, не затрагивая остальные части страницы.
В архитектуре нашего проекта Streamlit-приложение будет выступать одновременно в двух ролях: как BI-инструмент (SELECT запросы к ClickHouse) и как Producer (отправка сообщений в RabbitMQ)
¶ Цель работы
Разработать интерактивное веб-приложение (дашборд) с использованием фреймворка Streamlit. Приложение должно визуализировать аналитические данные из витрины (ClickHouse) и предоставлять пользовательский интерфейс для отправки запросов на перенос занятий через RabbitMQ, отображая полученные результаты (слоты).
¶ Задание
¶ Подготовка
Упакуйте скрипт consumer.py из ЛР 4 в Docker-образ и добавьте соответствующий сервис в docker-compose.yaml. Предусмотрите отдельное виртуальное окружение.
Не забывайте про файл
.dockerignore, используйтеslim-образы в качестве основы; для организации виртуального окружения используйте пакетный менеджерuv(никакогоrequirements.txt)
Убедитесь, что кластер запущен (docker compose up -d --build).
Создайте новое виртуальное окружение для Streamlit-приложения и установите необходимые зависимости. Создайте файл dashboard.py.
¶ Разработка дашборда
Подключение к ClickHouse и RabbitMQ настраивается через переменные окружения; никакого хардкода!
Реализуйте вкладку аналитики (или блок). С помощью интерфейса Streamlit отобразите:
- общее количество уникальных преподавателей, групп и аудиторий в базе
- топ преподавателей по количеству пар за выбранный период (столбчатая диаграмма)
- распределение пар по типам занятий (лекции, практики, лабораторные) (круговая диаграмма)
Используйте
clickhouse_connectдля выполнения SQL-запросов
используйте декоратор
@st.cache_dataперед функцией загрузки данных из БД
Реализуйте вторую вкладку (или блок) для работы преподавателя/диспетчера. Там должна быть форма, содержащая:
- выпадающий список для выбора преподавателя
- выпадающий список для выбора группы
- выпадающий список для выбора аудитории
- выбор диапазона дат для поиска свободного окна
- кнопку для запуска поиска слотов
Списки преподавателей, групп и аудиторий для выпадающих меню также должны динамически подгружаться из ClickHouse
¶ Сценарий работы при нажатии на кнопку
- генерируется уникальный
request_id(UUID) - формируется и публикуется в очередь JSON-сообщение с выбранными параметрами (предусмотрите таймаут -- вдруг Consumer упадёт)
- Consumer обрабатывает запрос и кладёт результат в соответствующую очередь
- дашборд забирает результат по
request_idи отображает его (здесь ваша фантазия, можно вывести результат в виде таблицы)
Подумайте, как можно обработать ситуацию, когда пользователь быстро пытается получить свободные слоты для нескольких входных конфигураций; дашборд не должен зависать; используйте фрагменты, а также
session_state
Рекомендуется использовать эксклюзивные очереди для каждого запроса и
request_idв качествеcorrelation_id(паттерн RPC over RabbitMQ)
Проверьте работу дашборда (streamlit run dashboard.py).
Упакуйте дашборд в отдельный Docker-образ. Добавьте соответствующий сервис в docker-compose.yaml и выполните повторную сборку (docker compose up -d --build).
Не забывайте про
depends_onиhealthcheck. Consumer должен запускаться раньше, чем приложений (дашборд)
Проверьте работу всего стека.
¶ Критерии приёмки
- весь разработанный стек запускается и работает
- дашборд имеет понятный и аккуратный пользовательский интерфейс
- аналитический блок приложения отображает графики, построенные на основе данных из ClickHouse; использовано кэширование данных
- интерфейс переноса занятий позволяет выбрать параметры из списков, полученных из БД
- по нажатию кнопки сообщение корректно уходит в брокер (можно проследить по логам Consumer)
- дашборд правильно отображает предложенные свободные слоты
- для хранения чувствительных данных используются переменные окружения
- студент понимает архитектуру приложения (Frontend, Queue, Backend Worker, Queue, Frontend) и может объяснить, почему для тяжелых вычислений используется асинхронный подход с брокером сообщений, а не прямой запрос из UI
- студент может ответить на вопросы по всему пройденному материалу