Azure Analysis Services и Power BI: подключение, модели и обновление данных

Обновлено 3 сентября 2026 года.

Azure Analysis Services (AAS) — управляемый сервис для табличных аналитических моделей. В нём хранятся таблицы модели, связи, меры и правила доступа; Power BI подключается к этой модели и показывает отчёты. AAS полезен там, где одна управляемая модель обслуживает несколько потребителей, например Power BI и Excel.

Для работающего решения нужны три самостоятельных компонента: источники данных, развёрнутая модель AAS и отчёт. Создание ресурса Azure ещё не создаёт модель продаж, а публикация PBIX в Power BI service не развёртывает её на сервере AAS. Ниже разобраны эти этапы и контрольные проверки после каждого.

Что именно хранится и выполняется в AAS

AAS поддерживает tabular models, а не многомерные модели SSAS Multidimensional. В табличной модели определяют столбцы, связи, иерархии и меры DAX. Слово «куб» иногда используют в разговоре, но переносить инструкции для многомерных кубов на AAS нельзя. Обзор AAS у Microsoft.

У модели AAS может быть режим хранения в памяти либо DirectQuery с поддерживаемым источником и тарифом. Отдельно выбирается способ подключения Power BI к AAS. Это два разных решения: live connection отчёта к AAS не означает, что сама модель AAS читает исходную базу при каждом запросе.

Перед началом: ресурс, учётные записи и тариф

1. Проверьте наличие подписки Azure, связанного tenant Microsoft Entra ID и прав на создание ресурса.
2. Выберите регион с доступностью AAS и оцените память модели, обработку данных, число одновременных запросов и бюджет.
3. Назначьте администратора AAS из Entra ID. Здесь не создают отдельный SQL-логин с паролем для подключения Power BI.
4. Определите доступ к источникам. Если источник находится в локальной сети организации, для обработки модели облачным AAS потребуется соответствующая настройка on-premises data gateway.

В Azure portal создайте ресурс Analysis Services, укажите подписку, группу ресурсов, имя, регион, тариф и администратора. Сохраните полное имя сервера из Overview: оно понадобится инструментам разработки и клиентам. Создание сервера; Требования к развёртыванию и шлюзу.

Developer предназначен для разработки и проверки, не имеет SLA и scale-out реплик. Basic не поддерживает DirectQuery, несколько секций таблицы и perspectives. Standard поддерживает эти возможности и реплики для запросов. Увеличение мощности внутри тарифа и переход на более высокий уровень доступны, но обратный переход между уровнями ограничен. Цену проверяйте для своего региона и соглашения в калькуляции Azure Analysis Services; отдельная стоимость Power BI и сопутствующих сервисов тоже входит в бюджет.

Разработка и развёртывание табличной модели

Один из штатных путей — Visual Studio с расширением Analysis Services projects. Создайте проект табличной модели, настройте источники, импортируемые таблицы, связи, меры и роли. Для учебной проверки можно пройти официальный учебник Adventure Works.

1. Определите детализацию фактов. Например, одна строка Sales — одна строка заказа, а Product содержит один ряд на ProductID.
2. Настройте типы данных и связи. Проверьте уникальность ключа справочника и отсутствие продаж с неизвестными ключами.
3. Добавьте меры и проверьте их на небольшом контрольном наборе.
4. Обработайте модель в среде разработки и устраните ошибки чтения источников.
5. В свойствах проекта, Deployment → Server, укажите адрес целевого AAS. Выполните Deploy, проверьте журнал развёртывания, затем состояние и данные базы на сервере.

Развёртывание метаданных и обработка данных связаны, но не тождественны: результат зависит от настроек deployment. Проверяйте оба этапа. При следующих публикациях учитывайте существующие роли, учётные данные и секции; сохраняйте проект и используйте отдельную тестовую модель. Порядок развёртывания из Visual Studio.

SQL Server Management Studio используют для подключения к AAS, администрирования, обработки и выполнения команд. Изменение связей в обычном PBIX и нажатие Publish не заменяют этот процесс. Универсальных пунктов Azure portal «Добавить модель → выбрать таблицы → сохранить модель» для проектирования произвольной рабочей модели нет.

Как подключить Power BI Desktop

1. Выберите Get data → Azure → Azure Analysis Services database.
2. Введите полное имя сервера, скопированное из Azure portal. Оно начинается с asazure://. Имя базы можно указать сразу либо выбрать модель в навигаторе.
3. Для отчёта поверх управляемой модели выберите Connect live.
4. Войдите учётной записью Microsoft, имеющей доступ к модели AAS, и выберите нужную модель.
5. Создайте визуализации и проверьте контрольные суммы, фильтры и отображаемые поля.

Коннектор также поддерживает Import. В таком случае Power BI получает отдельную копию данных с собственным циклом обновления и управлением доступом. Для составных моделей вместо чистого live connection может использоваться DirectQuery к AAS; это отдельная архитектура с дополнительными ограничениями. Windows и Basic authentication для этого подключения не поддерживаются. Подключение Power BI к AAS.

Сохраните PBIX и опубликуйте отчёт в нужную рабочую область Power BI. Проверьте его в сервисе под учётной записью получателя: разрешения на отчёт не заменяют права на модель AAS. Лицензирование совместного доступа Power BI также проверяется отдельно.

Учебная проверка: одна мера для нескольких отчётов

Возьмём три строки продаж. Числа условные и служат только для проверки расчёта.

В модели с числовыми столбцами Sales[UnitPrice] и Sales[Quantity] мера имеет такой вид:

Revenue := SUMX(Sales, Sales[UnitPrice] * Sales[Quantity])
Units := SUM(Sales[Quantity])
AverageUnitPrice := DIVIDE([Revenue], [Units])

Ожидаемые результаты: Revenue = 230, Units = 16, AverageUnitPrice = 14,375. Для товара B — 120, 8 и 15 соответственно. Простое среднее трёх цен равно 15 и отвечает другому вопросу: оно не учитывает количество проданных единиц. SUMX вычисляет выражение для строк в текущем контексте, а DIVIDE обрабатывает деление на ноль.

Создайте два отчёта с live connection и одинаковым фильтром. После успешной обработки одной и той же модели их контрольная выручка должна совпадать. Если нет, сначала сравните фильтры, роли пользователя и адрес модели. Названия одинаковых мер в разных базах ещё не гарантируют одинаковую логику.

Обновление данных: что запускать по расписанию

При модели в памяти AAS показывает данные последней успешной обработки. Обновление визуализаций Power BI повторяет запрос к модели, но не загружает в неё новые записи из источника. Live connection само по себе не обеспечивает поступление новых продаж в реальном времени.

Для автоматизации можно использовать Logic Apps с REST-вызовами, Azure Automation/PowerShell или оркестратор, запускающий такую обработку после загрузки источников. Расписание Recurrence в документированном примере Microsoft настраивается в Logic Apps. Вымышленную вкладку AAS «Обновление данных → Добавить расписание» искать не нужно. Пример автоматизации через Logic Apps.

1. Дождитесь завершения загрузки исходных данных; зафиксируйте контрольную дату и количество строк.
2. Запустите обработку всей модели или выбранных таблиц/секций.
3. Проверяйте состояние операции до завершения: принятие асинхронного запроса ещё не означает успеха.
4. При наличии query replicas синхронизируйте их после обработки и проверьте результат синхронизации.
5. Сравните контрольные показатели в отчёте с источником и отправляйте уведомление о сбоях владельцу загрузки.

REST API позволяет задавать объекты обработки, режим фиксации и MaxParallelism — предел параллельных потоков обработки. Это не «количество клавиш» и не универсальное число одновременных пользователей. При CommitMode=transactional операция фиксируется целиком; при partialBatch успешно зафиксированные пакеты сохраняются даже при последующем сбое. Подбирайте параллелизм по измерениям памяти, времени и нагрузке источника. Параметры асинхронного refresh API.

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

Права: Azure IAM, администраторы и роли модели

В AAS нужно различать управление ресурсом Azure, администрирование сервера и доступ к отдельной базе модели. Роль Owner/Contributor в Azure IAM не заменяет модельную роль читателя. Пользователи отчётов получают права через роли базы; их можно определить в проекте Visual Studio и администрировать в SSMS после развёртывания. Аутентификация и уровни разрешений.

Для ограничения строк задайте фильтр RLS в роли модели. Например, роль регионального аналитика может разрешать только записи его региона. Проверяйте доступ обычной учётной записью читателя, а не администратором. Скрытие столбца в списке полей, срез отчёта и perspective не заменяют защиту данных. Настройка ролей через SSMS.

Для автоматизации используйте отдельно управляемую сервисную идентичность и права, которые нужны выбранному API. Например, официальный сценарий Logic Apps требует service principal с правами администратора AAS. Ограничьте доступ к его учётным данным и к запускающему процессу; не публикуйте секреты в коде отчёта. Сетевые правила AAS должны разрешать нужный маршрут подключения. Отключение firewall не является обязательным этапом интеграции.

Производительность и масштабирование

Начните с конкретного симптома: не хватает памяти при обработке, медленная отдельная мера или много одновременных запросов. Сократите ненужные столбцы и высокую кардинальность, проверьте DAX и схему связей, измерьте работу источника. В табличной модели не создают произвольные SQL-индексы через Power BI; индексы исходной реляционной базы относятся к другому уровню.

Scale-out в Standard распределяет запросы между репликами модели, а не делит одну большую модель на фрагменты с общей памятью. Реплики оплачиваются отдельно; объём памяти для модели от их добавления не увеличивается. После изменения данных на основном сервере нужна синхронизация копий. Автоматизацию изменения мощности проектируют отдельно, с бюджетными пределами и проверкой результата. Устройство и ограничения scale-out.

Резервные копии и переход на модель Power BI

Резервные копии AAS сохраняют в контейнер Azure Storage; их можно создавать и восстанавливать через SSMS или PowerShell. Для модели в памяти копия содержит данные и метаданные, а для DirectQuery — метаданные модели. Она не заменяет резервное копирование исходной базы, PBIX и кода автоматизации. Задайте срок хранения и проверьте восстановление в отдельную тестовую базу. Backup and restore AAS.

Для нового проекта сравните AAS с семантической моделью Power BI/Fabric: функциональность, требования к клиентам, управление, стоимость и доступность для вашей организации. Для существующего AAS Microsoft предоставляет сценарий миграции в подходящую рабочую область Power BI. Переносятся модель, данные последнего обновления и роли; сервисные субъекты не переносятся автоматически. Перенаправление клиентов и перепривязка отчётов выполняются отдельно. Документация по миграции.

До переключения сравните меры, RLS, источники, расписания и время выполнения отчётов. Сохраните возможность возврата на исходную модель. Наличие инструмента миграции не означает, что любой PBIX можно напрямую опубликовать в AAS или что перенос пройдёт без проверки совместимости.

Проверка готового решения

• На сервере существует нужная база модели, а не только пустой ресурс AAS.
• Контрольные суммы совпадают с источником при одинаковых фильтрах.
• Получатель отчёта видит разрешённые ему строки и не получает административных прав ради просмотра.
• Новая тестовая запись появляется после завершения обработки и, при необходимости, синхронизации реплик.
• Сбой источника виден в журнале и уведомлениях; отчёт не выдаёт прежнюю загрузку за новую.
• Зафиксированы владелец модели, расходы, время обновления и проверенный порядок восстановления.