🎭 Двойная игра в Power BI: как совмещать роли разработчика и администратора
Когда твой руководитель говорит: «А теперь ты еще и администратор сервера Power BI». Гид по выживанию для разработчика, внезапно ставшего многостаночником.
Привет всем!
Я, Ипатов Александр, backend-разработчик в компании USETECH. В данной статье я хотел бы поднять вопросы, которые возникают уже тогда, когда человек, имея знания разработчика, становится в компании еще и администратором сервера Power BI: теперь в его зоне ответственности помимо разработки есть еще и другие задачи, о которых поговорим ниже.
В компаниях малого и среднего размера, зачастую, разработчиком и администратором Microsoft Power BI отчетности является один и тот же сотрудник. Обычно это человек, который прошел некие начальные курсы по работе с Microsoft Power BI в качестве разработчика: он умеет создавать дашборды, подключать туда разные источники данных, обрабатывать данные и реализовывать метрики в виде DAX-мер.
Да, в текущее санкционное время вопрос использования Microsoft очень рискованный, однако есть компании, которые продолжают его использование, конечно же, с некими параллельными процессами по интеграции на российский или западный-opensource /азиатский аналог.
Два вопроса, которые будут рассмотрены в статье:
- локальный шлюз данных;
- настройка RLSна уровне MicrosoftPowerBI.
Локальный шлюз данных
Локальный шлюз данных помогает в автоматическом обновлении отчетности. Чтобы настроить это автоматическое обновление, сначала на будущем сервере нужно установить программу «On-premises data gateway» (для Windows). После установки нужно залогиниться под логин/паролем администратора Power BI, в которой находятся отчеты (дашборды) Microsoft Power BI. Важный момент: этот будущий сервер и является тем местом, чей канал интернета будет тратиться на выполнение обновлений отчетов. Следовтельно при низкой скорости отчеты будут обновляться долго, а если отчетов очень много, а в базах данных, которые являются одними из источников наборов данных в отчетах – могут «падать» в таймауты. Поэтому, если такое случается, нужно искать решение в двух направлениях:
- уменьшить выборку данных (или оптимизировать SQL-запрос);
- увеличить канал интернета на сервере (но бывают и ограничения на скорость со стороны БД – значит, необходимо взаимодействие с DWH-отделом компании).
Случаются редкие ситуации, когда локальный шлюз данных «впадает в ступор» и глючит. Обычно решается эта проблема простым перезапуском сервера. Но, если проблему решить не удается ребутом – то на помощь придет перезапуск Службы (PBIEgwService) в диспетчере задач (Свойства – Перезапустить).
После настройки локального шлюза мы можем спокойно настраивать автоматическое обновление отчетности (минимальный интервал – 1 раз в 30 минут, если мы не говорим о подключениях Direct Query).
Настройка RLS на уровне Microsoft Power BI (внутри PBIX + настройка в облаке ролей)
Бывают случаи, когда бизнесу требуется реализовать жесткие доступы к данным внутри дашборда. Например, если сеть магазинов хочет не показывать в дашбордах каждому магазину результаты продаж других магазинов, но администраторам и кураторам этих магазинов должны быть видны данные по продажам всех магазинов. Это достигается за счет применения RLS – ограничения по видимости строк, которые у них будут в отчетах.
Как настроить RLS внутри отчета
0) Открываем отчеты (pbix-файлы в «Power BI Desktop»), в которых нужно реализовать ограничения по видимости строк.
1) Нажимаем
Моделирование.
2) Нажимаем
Управление ролями.
3) Выбираем роль (либо создаем новую строку/дублируем и переименовываем) – это обертка того, что настроим ниже. Далее эта «обертка» будет выдаваться пользователю в сервере Power BI.
4) Выбираем таблицу, где будет стоять ограничение на строку (это зависит от конкретного набора данных, который заложен в эту таблицу. Например, это может быть сформированная таблица на основе SQL-запроса к БД или просто excel-таблица, загруженная в Power BI).
5) В
поле «Выражение DAX-фильтра
таблицы» пишем выражение по конкретному ограничению. Например [Магазин] = ‘123’
(в таблице, выбранной в пункте 4 есть столбец «Магазин» и в нем есть магазин с
номером «123»).
Вот мы и сформировали новый pbix-файл, но теперь нужно его опубликовать и настроить эти самые ограничения уже на сервере.
6) После
окончания работы внутри настройки RLS в Power BI Desktop нужно заново опубликовать отчет
на сервер. Делаем это нажатием «Опубликовать» (из нужной нам учетной записи в
нужную нам рабочую область, по умолчанию «Моя рабочая область»).
Теперь отчет загружен, но все еще
RLS не
работает. Далее, после того, как отчет обновится (либо остановить обновление
принудительно, т. к. во время обновления нельзя настраивать настройку у Набора
данных «Безопасность») нужно завершить настройки RLS для этого «Магазина»
– в разделе «Безопасность» набора данных этого отчета:
7) Заходим
в «Моя рабочая область» (или другая рабочая область, в которую мы опубликовали
дашборд).
8) Нажимаем
«Наборы данных».
9) Нажимаем
на кнопку «три точки».
10) Нажимаем
«Безопасность»:
11) Выбираем
роль, которую создали ранее в пункте 3 (в примере это был «Магазин» = ‘123’).
12) Начинаем вводить учетную запись, с которой авторизуется директор или менеджер данного магазина из Azure. Выбираем этого пользователя.
13) Нажимаем
«Сохранить».
Итог
Теперь у учетной записи данного магазина будут лишь те данные, которые соответствуют фильтру, который мы создали на DAX языке в пункте 5.
Надеюсь, что представленный материал поможет в реализации рабочих задач начинающим администраторам Power BI. Кстати, для тех, кому понравилось, здесь ссылка на другую статью про Microsoft Power BI. В ближайшее время планирую выпустить еще несколько статей, затрагивающих тонкие темы разработки и администрирования Power BI.