Популярные вопросы

Первая встреча – это откровенный разговор. Мы задаём вопросы о бизнес-контексте, текущих проблемах и ожидаемом результате, вы рассказываете о своём видении. На выходе у обеих сторон есть понимание, как подойти к задаче.

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

Lakehouse объединяет принципы data lake и data warehouse: позволяет работать с большими массивами разнотипных данных и в то же время поддерживать структурированную аналитику. Но универсально лучшего варианта нет: выбор между data lake, data warehouse и data lakehouse зависит от типов данных, задач аналитики и требований к архитектуре.

Да, NDA подписываем на любом этапе. Мы с уважением относимся к информации наших клиентов и ценим собственную репутацию. У нас есть свой шаблон NDA, но если у клиента есть другой, согласуем его без лишних сложностей.

В упрощённой архитектуре можно выделить четыре основных блока: источники данных и интеграции, хранилище, аналитический и BI-слой, а также governance – правила доступа, качества и управления данными. В более сложных платформах отдельными компонентами также могут быть обработка данных, каталогизация, мониторинг и средства безопасности.

Поддержка после релиза – отдельное направление работы. При необходимости подписываем SLA и берём ответственность за uptime, устранение багов и обновления. Формат зависит от проекта: где-то нужна реакция в течение часа, где-то достаточно регулярного просмотра логов раз в неделю. Длительность тоже гибкая: от нескольких месяцев до долгосрочного сопровождения.

Последовательно: сначала аудит текущих систем, чтобы понять, какие источники данных критичны. Далее – выбор архитектуры под масштаб бизнеса. Затем построение ETL/ELT-конвейеров, которые переносят и трансформируют данные. И только в конце – подключение BI-слоя для дашбордов и отчётов. Пропуск аудита или попытка начать сразу с BI повышают риск того, что платформа будет построена на несогласованных данных и потребует переработки уже после запуска.

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

RLS ограничивает доступ к отдельным строкам модели данных в зависимости от роли пользователя. Поэтому один и тот же отчёт может показывать разные данные разным людям.

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

Создайте RLS-роль, задайте правило фильтрации, протестируйте его, опубликуйте модель и назначьте пользователей или группы на роль в Power BI Service. Отдельно проверьте их права в рабочем пространстве и доступ к отчёту.

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

Во внутренних системах ограничиваем доступы и внедряем многоуровневую авторизацию. В BI изолируем среды и контролируем права вплоть до уровня отдельных дашбордов. В e-commerce – защита API, шифрование платежей, аудит трафика. Работали с банками, госструктурами и юридическими компаниями, где требования к безопасности особенно жёсткие.

В статическом RLS правило фильтрации закреплено за ролью. В динамическом оно может изменяться в зависимости от пользователя, например через USERPRINCIPALNAME() и таблицу соответствия.

Для этого используют RLS Power BI: правила модели определяют, какие данные увидит пользователь после входа.

В Power BI Desktop используйте View as, чтобы проверить отчёт от имени роли. После публикации роль также можно протестировать в Power BI Service.

Типичные ошибки: ошибка в DAX-фильтре, некорректно назначенные роли рабочего пространства, устаревшая таблица соответствия и попытка заменить RLS обычными фильтрами в отчёте.

DAX (Data Analysis Expressions) — язык формул для расчётов в Power BI. DAX работает с таблицами, столбцами и связями модели данных, а результат мер меняется в зависимости от текущих фильтров отчёта.

DAX позволяет создавать собственные бизнес-метрики: например, рассчитывать маржинальность, сравнивать показатели между периодами или строить нарастающий итог. Power BI может работать и без собственных DAX-формул, но DAX в Power BI нужен для расчётов, которых нет в исходных данных и которые должны меняться в зависимости от фильтров отчёта.

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

Достаточно уверенно владеть базовым набором: CALCULATE (изменение контекста фильтров), SUM и SUMX (агрегация), DIVIDE (безопасное деление) и функциями временной аналитики — SAMEPERIODLASTYEAR, DATESYTD, TOTALYTD.

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