← вся теориятеория к собесу · BI и визуализация

BI-инструменты и российский стек

BI-инструменты: где живёт правда о метриках

Инструментов много, но собес проверяет не кнопки конкретного Tableau, а принципы: где считаются метрики, как не расплодить 50 версий одной цифры, как дать доступ по правам. Принципы переносимы между всеми BI.

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

// Формулировки: «что такое семантический слой?», «live-подключение или экстракт?», «что такое row-level security?».

Классы инструментов и РФ-стек

Три класса. Self-service BI (business intelligence) (Tableau, Power BI, Yandex DataLens, Superset) - дашборды поверх готовых витрин. Notebook и код - ad-hoc глубина, куда BI не дотягивается. Excel и таблицы - быстрые прикидки и финмодели.

В РФ-стеке полезно знать расклад: DataLens (облачный, дешёвый), Superset и Metabase (open source), Power BI и Tableau - часто легаси после ухода вендоров. Но принципы дашбординга переносимы между всеми, инструмент вторичен.

// Типичная ошибка новичка - тащить в BI сырые логи и джойнить их прямо в отчёте. Витрины и агрегаты делаются в хранилище; BI только рисует готовое.

self-service BI: бизнес сам собирает отчёты по готовым витринам
витрина: предагрегированная таблица под отчёт (в хранилище)

Live против экстракта, модель

Живое подключение против экстракта это обмен свежести на скорость. Live даёт свежие данные ценой нагрузки на БД, extract (импорт-снапшот) - скорость ценой лага. Выбор диктуют требования к свежести.

Модель данных BI - обычно звезда: таблица фактов и измерения вокруг; различают меры (что агрегируем) и измерения (по чему режем). Вычисляемые метрики задают на уровне модели или семантического слоя, а не копипастой в каждый чарт.

// Аналитический дашборд нельзя вешать live прямо на прод-OLTP (online transaction processing): тяжёлый отчёт положит боевую базу. Между ними - хранилище и витрины.

экстракт: снапшот данных внутри BI ради скорости
мера / измерение: что агрегируем / по чему режем

Семантический слой и доступ

Семантический слой - единые определения метрик над хранилищем: одна формула выручки, которую видят все инструменты (metric store, dbt metrics). Он и убивает «войну цифр», когда у каждого аналитика своя выручка.

Row-level security - доступ к строкам по пользователю: менеджер видит только свой регион. Это решают на уровне BI или семантического слоя, а не клонированием дашборда под каждый регион.

// Self-service это культура, а не кнопка: витрины с понятными именами, каталог, обучение. Без этого «self-service» превращается в 50 версий одной метрики от 50 аналитиков. И половина ценности BI - экспорт и алерты: подписка на отчёт, оповещение о пороге.

семантический слой: единые определения метрик между BI и SQL
row-level security: фильтрация строк по правам пользователя

Как отвечать: «Что такое семантический слой и зачем он нужен?»

Семантический слой это единое место, где заданы определения метрик поверх хранилища: одна формула выручки, оттока, активных пользователей, которую используют все дашборды и инструменты. Нужен он, чтобы убить войну цифр. Без него каждый аналитик пишет свою выручку в своём чарте, и на встрече выясняется, что у трёх отчётов три разных числа, дальше спорят не о деле, а о том, чьё правильное. С семантическим слоем формула одна, правишь в одном месте, и она меняется везде сразу; в стеке это реализуют как metric store или dbt metrics. Заодно на этом же уровне удобно держать row-level security - доступ к строкам по правам, чтобы менеджер видел свой регион, а не плодить дашборды-клоны. По сути это единый источник правды о том, что означают метрики.

Почему это сильный ответ: определение (единые определения над хранилищем), конкретная боль, которую он лечит (война цифр), механизм (одна формула - правка в одном месте) и связка с RLS (row level security) и dbt/metric store.

На чём валят

−Тащить в BI сырые логи и джойнить в нём - витрины и агрегаты делаются в хранилище.
−Формула метрики скопирована в 30 чартов - правка в 29 из них забудется.
−Live-подключение аналитического дашборда к прод-OLTP - положить прод отчётом.
−Дашборды-клоны на каждый регион вместо row-level security.
−Выбор инструмента по хайпу без учёта того, где живут данные и кто пользователи.

Проверьте себя

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

#bi_tools1 / 5
После ухода Tableau и Power BI с российского рынка какие BI-инструменты стали типичным выбором в РФ?
A)После ухода западных вендоров в РФ не осталось BI-инструментов, кроме ручных таблиц в Excel
B)Исключительно проприетарный софт из США
C)BI не используется в РФ-компаниях
D)Яндекс DataLens, Apache Superset, Metabase + отечественные Visiology/Loginom
показать ответ и разбор
+D)Яндекс DataLens, Apache Superset, Metabase + отечественные Visiology/Loginom
// разбор: С 2022 из-за ухода западных вендоров и вопросов лицензирования РФ-компании переходят на доступные альтернативы: Яндекс DataLens (облачный, экосистема Яндекса), Apache Superset и Metabase (open-source, self-hosted), отечественные Visiology, Loginom, Analytic Workspace и др. Для аналитика в РФ 2026 знание этого стека практично — вакансии всё чаще требуют DataLens/Superset вместо Tableau.
#bi_tools2 / 5
Тяжёлые джойны и агрегации для дашборда лучше делать до BI (в хранилище/витрине), а не внутри дашборда. Почему?
A)Готовить данные в витрине: дашборд читает предагрегат — быстро, логика централизована
B)BI-инструменты вообще не умеют джойнить таблицы
C)Расчёты в дашборде бесплатны по производительности
D)Логику расчётов лучше писать заново прямо в каждом дашборде — так она ближе к конкретной визуализации
показать ответ и разбор
+A)Готовить данные в витрине: дашборд читает предагрегат — быстро, логика централизована
// разбор: Если каждый дашборд на лету джойнит и агрегирует большие таблицы, он медленный и грузит источник, а сложная логика размазана по отчётам и расходится. Правильнее подготовить витрину (ETL/ELT в хранилище, dbt-модель, материализованное представление): дашборд читает уже компактный предрасчёт, работает быстро, а определения метрик живут в одном месте. BI — для подачи, тяжёлая трансформация — до него.
#bi_tools3 / 5
Разным пользователям одного дашборда нужно показывать только их данные (свой филиал/клиент). Какой механизм BI это решает?
A)Сделать отдельную персональную копию дашборда для каждого пользователя и раздать ссылки вручную
B)Row-level security (RLS): правила фильтруют строки по личности — один дашборд, свой срез каждому
C)Просто попросить пользователей не смотреть чужие строки
D)Скрыть лишние строки цветом фона
показать ответ и разбор
+B)Row-level security (RLS): правила фильтруют строки по личности — один дашборд, свой срез каждому
// разбор: Row-level security задаёт на уровне модели/датасета правила: какие строки видит пользователь в зависимости от его роли или атрибута (менеджер видит свой регион, клиент — свой аккаунт). Один и тот же дашборд отдаёт каждому только разрешённый срез, без копий. Копировать дашборд на каждого — неуправляемо; «скрытие» цветом или доверие не защищают данные. RLS — стандартная практика многопользовательских BI.
#bi_tools4 / 5
Дашборд с extract тормозит и занимает много памяти на больших данных. Что помогает, кроме «взять сервер мощнее»?
A)Добавить на дашборд больше графиков
B)Перейти на live-подключение к тем же большим таблицам — оно снимет нагрузку по памяти с дашборда
C)Отключить все фильтры дашборда
D)Агрегировать снимок до нужной гранулярности, инкремент, убрать лишние поля и историю
показать ответ и разбор
+D)Агрегировать снимок до нужной гранулярности, инкремент, убрать лишние поля и историю
// разбор: Скорость extract-дашборда определяется размером снимка. Его сокращают: агрегируют до нужной детализации (не тянуть строку-события, если нужен день), обновляют инкрементально (только новое), выкидывают неиспользуемые колонки и лишнюю историю. Меньше строк и полей — меньше памяти и быстрее отклик. Live на тех же больших таблицах лишь переносит нагрузку на источник, а не решает объём.
#bi_tools5 / 5
Чем дашборд в BI отличается от разового ad-hoc запроса аналитика?
A)Это одно и то же
B)Дашборд — под постоянный вопрос (многие, по расписанию); ad-hoc — разовый ответ сейчас
C)Ad-hoc сложнее дашборда
D)Дашборд строят только по одной таблице, а ad-hoc-запрос — по нескольким соединённым источникам сразу
показать ответ и разбор
+B)Дашборд — под постоянный вопрос (многие, по расписанию); ad-hoc — разовый ответ сейчас
// разбор: Дашборд — это продукт для повторяющегося вопроса: его смотрят регулярно многие, он обновляется по расписанию, его поддерживают. Ad-hoc — разовое исследование под конкретный вопрос («почему просела прошлая неделя»), которое не обязано жить дальше. Ошибка — превращать каждый разовый вопрос в постоянный дашборд: растёт зоопарк неподдерживаемых экранов. Дашборд заводят под то, что будут спрашивать снова и снова.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: BI и визуализация