Статья Smarten о проблемах многотенантной аналитики — это не просто вендорский кейс. Это иллюстрация реального архитектурного разрыва, с которым сталкиваются компании, когда их SaaS-продукт начинает расти. «Один продукт, сотни клиентов» — красивая формула, но когда каждый клиент добавляет кастомные поля, меняет рабочие процессы и требует изоляции данных, единый аналитический слой трещит по швам. Для студента ИТ это готовая исследовательская проблема: как спроектировать аналитическую платформу, которая сохраняет производительность, безопасность и гибкость при масштабировании. В этой статье разберём, как превратить тезисы из материала в полноценную структуру ВКР, какие главы наполнить архитектурными диаграммами, какие метрики посчитать и как оформить работу по ГОСТ.
Выбранный поддомен — Data Engineering, роль — Архитектор ПО. Именно с этой позиции нужно подходить к теме. Статья Smarten даёт полный перечень проблем — изоляция данных, расходящиеся схемы, «шумные соседи», сложные права доступа, самообслуживание и несостоятельность классических BI-инструментов. Каждая из этих проблем может стать самостоятельной темой ВКР.
| № | Тема | Актуальность (отсылка к статье) | Цель | Задачи | Структура работы |
|---|---|---|---|---|---|
| 1 | Разработка прототипа многотенантной BI-платформы с динамическим row-level security | Статья подчёркивает, что «безопасность должна сохраняться в запросах, кэшах, экспортах и планировщиках». Ручная фильтрация по tenant_id не масштабируется. | Спроектировать и реализовать аналитический сервис с автоматической изоляцией данных на уровне строк. | 1. Сравнить модели изоляции (shared schema, schema-per-tenant, tenant-per-database). 2. Спроектировать семантический слой с tenant-aware метриками. 3. Реализовать динамическую политику безопасности. 4. Провести нагрузочное тестирование. |
Глава 1 — анализ предметной области, обзор существующих BI-систем. Глава 2 — архитектура, диаграммы C4, выбор стека. Глава 3 — реализация, тестирование, метрики. |
| 2 | Исследование влияния «шумных соседей» на производительность аналитических запросов в мультитенантных SaaS | Статья: «Крупные тенанты доминируют в ресурсах, а мелкие страдают». Это классическая проблема изоляции нагрузки. | Количественно оценить деградацию и предложить методы управления квотами. | 1. Смоделировать сценарии нагрузки с разным распределением объёмов данных. 2. Измерить латентность (p50, p95, p99), пропускную способность. 3. Сравнить стратегии (пулы соединений, очереди, Kubernetes ResourceQuota). 4. Разработать рекомендации. |
Глава 1 — теоретические основы QoS. Глава 2 — настройка окружения для эксперимента. Глава 3 — результаты, анализ, выводы. |
| 3 | Сервис кастомных полей для многотенантной аналитики на основе гибкой схемы данных | «Клиенты добавляют атрибуты, переименовывают поля, импортируют внешние данные — стандартные BI-инструменты ломаются». Значит, нужен механизм расширений. | Разработать подсистему, позволяющую расширять модель данных без изменения базовых отчётов. | 1. Проанализировать подходы EAV, JSONB, отдельные колонки. 2. Реализовать API для управления кастомными полями. 3. Интегрировать с семантическим слоем. 4. Проверить совместимость с существующими метриками. |
Глава 1 — обзор моделей гибких схем. Глава 2 — проектирование подсистемы. Глава 3 — реализация, тесты на регрессию. |
| 4 | Встраивание аналитики в SaaS-продукт: архитектура embeddable-панелей с соблюдением OWASP | Статья указывает, что «iframe-аналитика ощущается прикрученной, контекст безопасности утекает». Нужен нативный embedded-подход. | Спроектировать архитектуру встроенной аналитики с передачей контекста через JWT и сохранением политик доступа. | 1. Исследовать паттерны embedded analytics. 2. Описать механизм единой аутентификации (SSO, JWT). 3. Реализовать компонент для встраивания. 4. Протестировать на типовых сценариях. |
Глава 1 — обзор технологий встраивания. Глава 2 — проектирование, диаграммы. Глава 3 — реализация и анализ защищённости (OWASP). |
Статья Smarten — это отличная база для первого (аналитического) раздела. Её тезисы можно переработать в сравнительную таблицу «Традиционный BI vs. многотенантный подход», а также использовать для обоснования актуальности. Например, цитата: «Каждый клиент эволюционирует по-разному» превращается в исследовательскую гипотезу: чем выше гетерогенность схем и запросов, тем быстрее деградирует производительность. Эту гипотезу уже можно проверять в главе 3.
Для второй главы обязательно потребуются диаграммы. Используйте нотацию C4: сначала контекст системы (SaaS-продукт, внешние клиенты, BI-сервис, базы данных), затем контейнеры (веб-приложение, семантический слой, API-шлюз, хранилище аналитики), потом компоненты (например, модуль row-level security, кэш, планировщик отчётов). Можно дополнить UML-диаграммой классов для моделей данных или BPMN для процесса назначения прав.
Не забывайте про стандарты. При оформлении технического задания — ГОСТ 34.601, для оценки качества — ГОСТ Р ИСО/МЭК 25010 (функциональная пригодность, производительность, безопасность, сопровождаемость). Это усиливает защиту: комиссия смотрит не только на код, но и на применение нормативной базы.
Чтобы показать реализацию, можно привести фрагмент SQL-политики в стиле PostgreSQL RLS или YAML-конфигурацию метрики, которая автоматически подставляет tenant_id.
-- Пример динамической политики безопасности
-- Каждый запрос от пользователя идёт с параметром tenant_id
CREATE POLICY tenant_isolation ON fact_sales
USING (tenant_id = current_setting('app.tenant_id'));
ALTER TABLE fact_sales ENABLE ROW LEVEL SECURITY;
ALTER TABLE fact_sales FORCE ROW LEVEL SECURITY;
Этот фрагмент можно вставить в главу 2 как решение задачи изоляции. Дополнительно покажите, как семантический слой обращается к метаданным тенанта и подставляет нужные атрибуты без изменения кода отчётов.
Тестирование многотенантной аналитики — это не просто «запустили и работает». Нужны количественные метрики. Рекомендую следующие:
Собирать метрики удобно через OpenTelemetry: инструментируйте API-слой, экспортируйте трейсы в Jaeger, а метрики в Prometheus. В тексте работы опишите схему мониторинга и приложите скриншоты Grafana-дашбордов. Это существенно повышает практическую ценность диплома — вы показываете не игрушечный прототип, а наблюдаемую систему.
Для бакалаврской работы достаточно PostgreSQL и, при желании, ClickHouse для аналитических запросов. Ключевое — не «хайп» фреймворков, а корректное проектирование изоляции и семантического слоя. Статья Smarten прямо говорит, что традиционные BI не справляются, поэтому ваш прототип может быть простым REST API + SQL.
Генерируйте синтетические данные с помощью Python (библиотека Faker). Создайте, например, 50 «тенантов» с разным количеством записей — от 10 тыс. до 10 млн. Это позволит имитировать сценарий из статьи, где «один крупный клиент задаёт шум, остальные страдают». Скрипт генерации можно вынести в приложение к ВКР.
Для диаграмм используйте PlantUML, Draw.io или Lucidchart. Формат: рисунок в тексте с подписью «Рисунок 2 — Контейнерная диаграмма C4 уровня системы». Обязательно сошлитесь на сам рисунок в тексте (например, «Как показано на рисунке 2.1, приложение состоит из…»). В разделе «Обозначения и сокращения» расшифруйте C4, UML, RLS, TCO.
Не сравнивайте «было до» и «стало после» без фактических цифр. Измерьте время ответа на 100 одновременных запросов в двух конфигурациях: без политики изоляции и с RLS. Покажите, что разница в латентности не превышает 10–15%, а безопасность при этом гарантирована. Для темы «шумный сосед» — постройте график зависимости p99 от объёма данных крупнейшего тенанта.
Вы можете обратиться за помощью к профессиональным консультантам, но сначала попробуйте самостоятельно разобрать материал статьи. Мы предлагаем бесплатную консультацию — на ней разберём структуру именно вашей работы. Если действительно нужна полная поддержка, наши эксперты помогут. Но важно, чтобы вы сами понимали, что защищаете.
Ошибка 1: Проектирование без учёта реальных BI-ограничений. Студент выбирает готовый BI-инструмент (Power BI, Metabase) и встраивает его через iframe. Статья прямо предупреждает: «нормальный BI ждёт одну организацию и одну схему». Поэтому в работе должна быть собственная семантическая модель или доработка.
Ошибка 2: Игнорирование безопасности. Если фильтрация по tenant_id прописана вручную где-то в коде, это не считается реализацией. Нужна политика на уровне БД (RLS) или централизованный шлюз с JWT-контекстом. Иначе на защите спросят: «а что если забыть один экземпляр отчёта?»
Ошибка 3: Нет экспериментальной проверки. Работа становится «рефератом». Обязательно посчитайте метрики до/после, постройте графики. Даже простой тест с сгенерированными данными покажет, что вы понимаете, о чём пишете.
Нужна помощь с дипломом? Мы готовы провести бесплатную консультацию и разобраться в вашей теме. Опыт наших специалистов — более 120 часов совместной работы со студентами ИТ-направлений. Поможем с планом, структурой, выбором стека или оформим отдельную главу. Напишите нам — и защита станет спокойнее.
Источник: The Multi-Tenant Challenge: Why Scaling Analytics Across Customers Is Harder Than It Looks (опубликовано 2026-03-16)