Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Автоматическая агрегация использует передовые технологии машинного обучения (ML) для непрерывной оптимизации семантических моделей DirectQuery с целью достижения максимальной эффективности работы отчетов. Автоматические агрегаты создаются на основе существующей пользовательской инфраструктуры агрегатов , впервые появившихся с составными моделями для Power BI. В отличие от определяемых пользователем агрегатов, автоматические агрегаты ™не требуют обширных навыков моделирования данных и оптимизации запросов для настройки и обслуживания. Автоматические агрегирования обладают способностью к самообучению и самооптимизации. Они позволяют владельцам моделей любого уровня навыков повысить производительность запросов, обеспечивая более быстрые визуализации отчетов для больших моделей.
С автоматическими агрегациями:
- Визуализации отчетов выполняются быстрее. Оптимальная доля запросов в отчетах возвращается автоматически поддерживаемым кэшем агрегатов в оперативной памяти вместо систем источников данных на бекенде. Запросы, которые являются аномальными и не обрабатываются кэшем в памяти, передаются непосредственно к источнику данных с помощью "DirectQuery".
- Сбалансированная архитектура. По сравнению с чистым режимом DirectQuery большинство результатов запроса возвращаются подсистемой запросов Power BI и кэшом агрегатов в памяти. Нагрузка на обработку запросов на системы источников данных во время пиковых отчетов может значительно сократиться, что означает увеличение масштабируемости в серверной части источника данных.
- Простая настройка. Владельцы моделей могут включить автоматическое обучение агрегаций и запланировать одно или несколько обновлений для модели. При первом обучении и обновлении автоматические агрегации начинают создавать структуру агрегации и оптимальные агрегации. Система автоматически настраивает себя с течением времени.
- Тонкая настройка — с помощью простого и интуитивно понятного пользовательского интерфейса в параметрах модели можно оценить улучшение производительности для другого процента запросов, возвращаемых из кэша агрегации в памяти, и внести корректировки для еще большего улучшения. Элемент управления с одной панелью слайдов позволяет легко настроить среду.
Требования
Поддерживаемые планы
Автоматические агрегации поддерживаются для Power BI Premium за емкость, Premium за каждого пользователя и моделей Power BI Embedded.
Поддерживаемые источники данных
Для следующих источников данных поддерживаются автоматические агрегации:
- База данных SQL Azure
- Выделенный пул SQL в Azure Synapse
- SQL Server 2019 или более поздней версии
- Google BigQuery (сервис анализа данных)
- Snowflake
- Databricks
- Amazon Redshift
Поддерживаемые режимы
Для моделей в режиме DirectQuery поддерживаются автоматические агрегаты. Поддерживаются составные модели с таблицами импорта и подключениями DirectQuery. Автоматические агрегаты поддерживаются только для подключения DirectQuery.
Permissions
Чтобы включить и настроить автоматические агрегирования, необходимо быть владельцем модели. Администраторы рабочей области могут взять на себя роль владельца, чтобы настроить параметры автоматической статистической обработки.
Настройка автоматических агрегаций
Автоматические агрегации настраиваются в параметрах модели. Настройка проста — включите автоматическое обучение агрегациям и запланируйте одно или несколько обновлений. Прежде чем настраивать автоматические агрегации для вашей модели, обязательно внимательно прочитайте эту статью. Он предоставляет хорошее представление о том, как работают автоматические агрегаты, и может помочь вам решить, подходит ли автоматическое агрегирование для вашей среды. Когда вы будете готовы к пошаговым инструкциям по включению автоматического агрегирования, конфигурированию расписания обновлений и оптимизации под вашу среду, см. статью "Настройка автоматических агрегатов".
Преимущества
При использовании DirectQuery каждый раз, когда пользователь модели открывает отчет или взаимодействует с визуализацией отчета, запросы анализа данных (DAX) передаются в обработчик запросов, а затем в серверный источник данных в виде запросов SQL. Источник данных должен вычислять и возвращать результаты для каждого запроса. По сравнению с моделями режима импорта, хранящимися в памяти, круговые пути источника данных DirectQuery могут быть как временными, так и процессными, часто вызывая медленное время отклика запросов в визуализациях отчетов.
При включении модели DirectQuery автоматические агрегирования могут повысить производительность выполнения запросов в отчетах, исключая многократные обращения к источнику данных. Предварительно агрегированные результаты запроса автоматически возвращаются кэшом агрегатов в памяти, а не отправляются и возвращаются источником данных. Объем предварительно агрегированных данных в кэше агрегатов в памяти составляет небольшую долю объема данных, хранящихся в фактических и подробных таблицах в источнике данных. Результатом является не только повышение производительности запросов отчетов, но и снижение нагрузки на серверные системы источников данных. С автоматическими агрегациями только небольшая часть отчетов и нерегламентированных запросов, требующих агрегирования, не включенных в кэш в памяти, передаются во внутренний источник данных, как и в чистом режиме DirectQuery.
Автоматическое управление запросами и агрегациями
Хотя автоматические агрегаты устраняют необходимость создания пользовательских таблиц агрегирования и значительно упрощают реализацию предварительно агрегированного решения данных, более глубокое знакомство с базовыми процессами и зависимостями полезно в понимании того, как работают автоматические агрегаты. Power BI использует следующее для создания автоматических агрегатов и управления ими.
Журнал запросов
Power BI отслеживает запросы модели и пользовательских отчетов в журнале запросов. Для каждой модели Power BI поддерживает семь дней данных журнала запросов. Данные журнала запросов переносятся вперед каждый день. Журнал запросов является безопасным и не видимым для пользователей или через конечную точку XMLA.
Учебные операции
В рамках первой запланированной операции обновления модели для выбранной частоты (день или неделя) Power BI сначала инициирует операцию обучения, которая оценивает журнал запросов, чтобы гарантировать, что агрегирования в кэше в оперативной памяти адаптируются к изменяющимся шаблонам запросов. Таблицы агрегирования в памяти создаются, обновляются или удаляются, а специальные запросы отправляются в источник данных, чтобы определить агрегаты для включения в кэш. Однако вычисляемые статистические данные не загружаются в кэш в памяти во время обучения. Он загружается во время последующей операции обновления.
Например, если вы выберете дневную частоту и расписание обновляется в 4:00, 9:00, 14:00 и 19:00, только обновление в 4:00 каждый день будет включать и операцию обучения, и операцию обновления. Последующие запланированные обновления в 9:00 утра, 14:00 и 19:00 в этот день являются операциями только обновления, которые обновляют существующие агрегаты в кэше.
Хотя учебные операции оценивают прошлые запросы из журнала запросов, результаты достаточно точны, чтобы обеспечить покрытие будущих запросов. Однако нет никакой гарантии, что будущие запросы будут возвращены кэшом агрегатов в памяти, так как эти новые запросы могут отличаться от тех, которые получены из журнала запросов. Эти запросы, не возвращаемые кэшем агрегирования в памяти, передаются в источник данных с помощью DirectQuery. В зависимости от частоты и ранжирования этих новых запросов агрегирования для них могут быть включены в кэш агрегирования в памяти при следующей операции обучения.
Операция обучения имеет 60-минутное ограничение времени. Если обучение не может обработать весь журнал запросов в течение ограниченного времени, уведомление регистрируется в журнале обновления модели и обучение возобновляется при следующем запуске. Тренировочный цикл завершается и заменяет существующие автоматические агрегирования после обработки всего журнала запросов.
Операции обновления
Как описано ранее, после завершения операции обучения в рамках первого запланированного обновления для выбранной частоты Power BI выполняет операцию обновления, которая запрашивает и загружает новые и обновленные агрегации данных в кэш агрегатов в памяти и удаляет все агрегаты, которые больше не рангируются достаточно высоко (как определено алгоритмом обучения). Все последующие обновления для выбранной частоты дня или недели — это только операции обновления , запрашивающие источник данных для обновления существующих агрегированных данных в кэше. Используя наш предыдущий пример, запланированные обновления на 9:00AM, 2:00PM и 7:00PM в этот день являются операциями только обновления.
Плановые обновления в течение дня (или недели) гарантируют, что агрегированные данные в кэше соответствуют актуальности данных в исходной серверной базе данных. С помощью параметров модели можно запланировать до 48 обновлений в день, чтобы убедиться, что запросы отчетов, возвращаемые кэшем агрегатов, получают результаты на основе последних обновленных данных из внутреннего источника данных.
Caution
Операции обучения и обновления являются процессом и ресурсоемким для службы Power BI и систем источников данных. Увеличение процента запросов, использующих агрегаты, означает, что больше агрегатов необходимо запрашивать и вычислять из источников данных во время обучения и обновления, повышая вероятность чрезмерного использования системных ресурсов и потенциально вызывая тайм-аут. Дополнительные сведения см. в разделе "Подробные сведения о настройке".
Обучение по запросу
Как упоминалось ранее, учебный цикл может не завершиться в течение одного цикла обновления данных. Если вы не хотите ждать до следующего запланированного цикла обновления, включающего обучение, вы также можете запустить автоматическое обучение агрегаций по запросу, выбрав Запустить обучение и обновление сейчас в параметрах модели. С помощью триггера Обучение и обновление сейчас выполняются как операция обучения, так и операция обновления. Проверьте журнал обновления модели, чтобы узнать, завершена ли текущая операция перед выполнением другой операции обучения по запросу и обновления при необходимости.
Обновить историю
Каждая операция обновления записывается в журнал обновления модели. Отображаются важные сведения о каждом обновлении, включая количество агрегирования памяти в кэше, которое используется для настроенного процента запросов. Чтобы просмотреть журнал обновления, на странице "Параметры модели" выберите "Журнал обновлений". Если вы хотите выполнить детализацию немного дальше, выберите "Показать сведения".
Регулярно проверяя журнал обновления, вы можете убедиться, что запланированные операции обновления выполняются в течение допустимого периода. Убедитесь, что операции обновления успешно завершаются до начала следующего запланированного обновления.
Сбои обучения и обновления
Хотя Power BI выполняет операции обучения и обновления в рамках первого запланированного обновления в течение выбранного дня или недели, эти операции реализуются в виде отдельных транзакций. Если операция обучения не может полностью обработать журнал запросов в пределах времени, Power BI будет продолжать обновлять существующие агрегаты (и обычные таблицы в составной модели) с помощью предыдущего состояния обучения. В этом случае журнал обновления будет указывать на успешное обновление, и обучение будет возобновлять обработку журнала запросов при следующем запуске обучения. Производительность запросов может быть менее оптимизирована, если шаблоны запросов клиентского отчета изменились и агрегаты еще не корректирулись, но достигнутый уровень производительности по-прежнему должен быть гораздо лучше, чем чистая модель DirectQuery без каких-либо агрегатов.
Рекомендуется уменьшить процент запросов, использующих кэш агрегации в оперативной памяти в настройках модели, если для завершения обработки журнала запросов требуется слишком много циклов. Это уменьшит количество агрегаций, созданных в кэше, но позволит больше времени на завершение операций обучения и обновления. Дополнительные сведения см. в разделе "Подробные сведения о настройке".
Если обучение завершается успешно, но обновление завершается ошибкой, всё обновление помечается как ошибочное, так как результатом является недоступный кэш агрегаций в памяти.
При планировании обновления можно указать уведомления по электронной почте, если возникают сбои обновления.
Определяемые пользователем и автоматические агрегации
Определяемые пользователем агрегаты в Power BI можно настроить вручную на основе скрытых статистических таблиц в модели. Настройка определяемых пользователем агрегатов часто сложна, требуя большего уровня навыков моделирования данных и оптимизации запросов. С другой стороны, автоматические агрегации устраняют эту сложность в системе, управляемой ИИ. В отличие от определяемых пользователем агрегатов, которые остаются статическими, Power BI постоянно сохраняет журналы запросов и из этих журналов определяет шаблоны запросов на основе алгоритмов прогнозного моделирования машинного обучения (ML). Предварительно агрегированные данные вычисляются и хранятся в памяти на основе анализа шаблонов запросов. С автоматическими агрегированиями модели самообучаются и самооптимизируются. По мере изменения шаблонов запросов клиентского отчета автоматические агрегаты корректируются, отдавая приоритет и кэшируя те из них, которые используются чаще всего.
Так как автоматические агрегаты создаются на основе существующей пользовательской инфраструктуры агрегатов, можно использовать определяемые пользователем и автоматические агрегаты в одной модели. Квалифицированные моделировщики данных могут задавать агрегаты для таблиц с использованием DirectQuery, импорта (с добавочным обновлением или без него) или режима двойного хранения, одновременно получая преимущества более автоматических агрегатов для запросов через подключения DirectQuery, которые не обращаются к определяемым пользователем таблицам агрегирования. Эта гибкость обеспечивает сбалансированные архитектуры, которые могут снизить нагрузку запросов и избежать узких мест.
Агрегаты, созданные в кэше в памяти алгоритмом обучения автоматических агрегатов, определяются как System агрегаты. Алгоритм обучения создает и удаляет только эти System агрегаты, так как запросы отчетов анализируются и корректируются для поддержания оптимальных агрегатов для модели. Определяемые пользователем и автоматические агрегаты обновляются в процессе обновления. Только те агрегации, которые созданы автоматически и помечены как сгенерированные системой агрегации, включаются в автоматическую обработку агрегаций.
Кэширование запросов и автоматическое агрегирование
Power BI Premium также поддерживает кэширование запросов в Power BI Premium/Embedded для поддержания результатов запроса. Кэширование запросов отличается от автоматических агрегаций. При кэшировании запросов Power BI Premium использует свою локальную службу кэширования для реализации кэширования, а автоматические агрегаты реализуются на уровне модели. При кэшировании запросов служба кэширует запросы только для начальной загрузки страницы отчета, поэтому производительность запросов не улучшается при взаимодействии пользователей с отчетом. В отличие от этого, автоматические агрегаты оптимизируют большинство запросов отчетов путем предварительного кэширования агрегированных результатов запроса, включая эти запросы, созданные при взаимодействии пользователей с отчетами. Следует отметить, что кэширование запросов и автоматическая агрегация могут быть включены для модели, но это, скорее всего, не обязательно.
Мониторинг с помощью Azure Log Analytics
Azure Log Analytics (LA) — это служба в Azure Monitor, которую Power BI может использовать для сохранения журналов действий. С помощью набора инструментов Azure Monitor можно собирать, анализировать и реагировать на данные телеметрии из Azure и локальных сред. Он предлагает долгосрочное хранение, интерфейс для выполнения нерегламентированных запросов и доступ API для обеспечения экспорта и интеграции данных с другими системами. Дополнительные сведения см. в статье Об использовании Azure Log Analytics в Power BI.
Если Power BI настроена с учетной записью Azure LA, как описано в разделе "Настройка Azure Log Analytics для Power BI", можно проанализировать скорость успешного выполнения автоматических агрегатов. Помимо прочего, можно определить, обрабатываются ли запросы отчета из внутренней памяти кэша.
Чтобы использовать эту возможность, скачайте шаблон PBIT и подключите его к учетной записи log analytics, как описано в этой записи блога Power BI. В отчете можно просматривать данные на трех разных уровнях: представление сводки, представление уровня запросов DAX и представление уровня SQL-запросов.
На следующем рисунке показана страница сводки для всех запросов. Как видно, выделенная диаграмма показывает процент от общего числа запросов, которые были удовлетворены с помощью агрегаций по сравнению с теми, которые должны были использовать источник данных.
Следующий шаг для более глубокого анализа заключается в использовании агрегатов на уровне запроса DAX. Щелкните правой кнопкой мыши на запросе DAX из списка (слева внизу) >Детализация>истории запросов.
Это позволит вам получить список всех соответствующих запросов. Детализация до следующего уровня, чтобы отобразить дополнительные сведения об агрегации.
Управление жизненным циклом приложения
От разработки до тестирования и от тестирования до рабочей среды модели с включёнными автоматическими агрегатами имеют специальные требования для решений ALM.
Цепочки развертывания
С помощью конвейеров развертывания Power BI может скопировать модели с конфигурацией модели с текущей стадии на целевой этап. Однако автоматическое агрегирование должно быть сброшено на целевом этапе, так как параметры не передаются из текущего на целевой этап. Вы также можете программно развертывать содержимое с помощью интерфейсов REST API конвейеров развертывания. Дополнительные сведения об этом процессе см. в статье "Автоматизация конвейера развертывания" с помощью API и DevOps.
Кастомные решения ALM
Если вы используете пользовательское решение ALM на основе конечных точек XMLA, помните, что ваше решение может копировать созданные системой и созданные пользователем таблицы агрегирования в рамках метаданных модели. Однако вы должны вручную включить автоматическую агрегацию после каждого шага развертывания на этапе назначения. Power BI сохранит конфигурацию при перезаписи существующей модели.
Замечание
Если вы отправляете или повторно публикуете модель в составе файла Power BI Desktop (PBIX), созданные системой таблицы агрегирования теряются, так как Power BI заменяет существующую модель всеми ее метаданными и данными в целевой рабочей области.
Изменение модели
После изменения модели с автоматическими агрегациями, включенными с помощью конечных точек XMLA, таких как добавление или удаление таблиц, Power BI сохраняет все существующие агрегации, которые могут быть сохранены, и удаляет те, которые больше не нужны или актуальны. Производительность запросов может быть затронута до начала следующего этапа обучения.
Элементы метаданных
Модели с включенными автоматическими агрегатами содержат уникальные таблицы агрегирования, созданные системой. Таблицы агрегирования не видны пользователям в средствах создания отчетов. Они доступны через конечную точку XMLA с использованием клиентских библиотек служб Analysis Services версии 19.22.5 и выше. При работе с моделями с включенными автоматическими агрегатами обязательно обновите средства моделирования данных и администрирования до последней версии клиентских библиотек. Для SQL Server Management Studio (SSMS) выполните обновление до SSMS версии 18.9.2 или более поздней. Более ранние версии SSMS не могут перечислять таблицы или генерировать скрипты для этих моделей.
Автоматические статистические таблицы определяются свойством SystemManaged таблицы, которое является новым для табличной объектной модели (TOM) в клиентских библиотеках служб Analysis Services версии 19.22.5 и более поздних версий. В следующем фрагменте кода показано свойство, заданное SystemManagedtrue для таблиц автоматической агрегирования и false для обычных таблиц.
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AnalysisServices.Tabular;
namespace AutoAggs
{
class Program
{
static void Main(string[] args)
{
string workspaceUri = "<Specify the URL of the workspace where your model resides>";
string datasetName = "<Specify the name of your dataset>";
Server sourceWorkspace = new Server();
sourceWorkspace.Connect(workspaceUri);
Database dataset = sourceWorkspace.Databases.GetByName(datasetName);
// Enumerate system-managed tables.
IEnumerable<Table> aggregationsTables = dataset.Model.Tables.Where(tbl => tbl.SystemManaged == true);
if (aggregationsTables.Any())
{
Console.WriteLine("The following auto aggs tables exist in this dataset:");
foreach (Table table in aggregationsTables)
{
Console.WriteLine($"\t{table.Name}");
}
}
else
{
Console.WriteLine($"This dataset has no auto aggs tables.");
}
Console.WriteLine("\n\rPress [Enter] to exit the sample app...");
Console.ReadLine();
}
}
}
При выполнении этого фрагмента в консоли отображаются таблицы автоматических агрегаций, которые в настоящее время включены в модель.
Имейте в виду, что таблицы агрегаций постоянно меняются, поскольку процессы обучения определяют оптимальные агрегаты для включения в кэш агрегаций в оперативной памяти.
Это важно
Power BI полностью управляет объектами таблицы, создаваемыми системой для автоматических агрегатов. Не удаляйте и не изменяйте эти таблицы самостоятельно. Это может привести к снижению производительности.
Power BI поддерживает конфигурацию модели за пределами модели. Наличие в модели таблицы агрегирований, управляемой системой, не обязательно означает, что модель действительно настроена для автоматического обучения методам агрегирования. Другими словами, если вы создаете полное определение модели для модели с включенной автоматической агрегацией и создаете новую копию модели (с другим именем, рабочей областью или мощностью), новая модель не настроена на использование автоматической агрегации. Вам по-прежнему необходимо включить автоматическую тренировку агрегаций для новой модели в параметрах модели.
Соображения и ограничения
При использовании автоматических агрегаций помните следующее:
- Агрегаты не поддерживают динамические параметры запросов M.
- Запросы SQL, созданные на начальном этапе обучения, могут создать значительную нагрузку для хранилища данных. Если обучение завершается неполным и вы можете проверить на стороне хранилища данных, что запросы сталкиваются с временем ожидания, рассмотрите возможность временного масштабирования хранилища данных в соответствии с требованиями обучения.
- Агрегации, хранящиеся в кэше агрегаций в ОЗУ, могут не рассчитываться на основании самых последних данных из источника данных. В отличие от чистого DirectQuery, использование кэширования более похоже на обычные импортируемые таблицы, что приводит к задержке между обновлениями источника данных и данными, хранящимися в кэше агрегатов в памяти. Хотя всегда будет некоторая степень задержки, она может быть устранена с помощью эффективного расписания обновления.
- Чтобы оптимизировать производительность, задайте для всех таблиц измерений двойной режим и оставьте таблицы фактов в режиме DirectQuery.
- Автоматическая агрегация недоступна в Power BI Pro, Azure Analysis Services или SQL Server Analysis Services.
- Power BI не поддерживает загрузку моделей с включенными автоматическими агрегированиями. Если вы добавили или опубликовали файл Power BI Desktop (PBIX) в Power BI, а затем включили автоматические агрегаты, вы больше не сможете скачать PBIX-файл. Убедитесь, что копия PBIX-файла хранится локально.
- Автоматическая агрегация с внешними таблицами в Azure Synapse Analytics не поддерживается. Вы можете перечислить внешние таблицы в Synapse с помощью следующего SQL-запроса:
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name FROM sys.external_tables - Автоматические агрегирования доступны только для моделей, использующих расширенные метаданные. Если вы хотите включить автоматические агрегации для более старой модели, сначала обновите модель до расширенных метаданных. Дополнительные сведения см. в разделе "Использование расширенных метаданных модели".
- Не включайте автоматические агрегирования, если источник данных DirectQuery настроен для единого входа и использует динамические представления данных или элементы управления безопасностью для ограничения данных, к которым пользователь может получить доступ. Автоматические агрегирования не осведомлены о контролях на уровне источника данных, что делает невозможным гарантировать предоставление правильных данных для каждого пользователя. Процесс обучения зарегистрирует предупреждение в истории обновления, если обнаружит источник данных, настроенный для единого входа, и пропустит таблицы, использующие этот источник данных. Если это возможно, отключите единый вход (SSO) для этих источников данных, чтобы воспользоваться всеми преимуществами автоматических агрегатов для оптимизации производительности запросов.
- Не включайте автоматические агрегации, если модель содержит только гибридные таблицы, чтобы избежать ненужных издержек на обработку. Гибридная таблица использует как секции импорта, так и секцию DirectQuery. Распространенный сценарий — добавочное обновление с данными в режиме реального времени, когда секция DirectQuery извлекает транзакции из источника данных, которые произошли после последнего обновления данных. Однако Power BI импортирует агрегации во время обновления. Автоматические агрегирования не могут включать транзакции, которые произошли после последнего обновления данных. Обучение записывает предупреждение в журнал обновлений, в котором было обнаружено и пропущено гибридные таблицы.
- Вычисляемые столбцы не учитываются при автоматических агрегациях. Если вы используете вычисляемый столбец в режиме DirectQuery, например с помощью
COMBINEVALUESфункции DAX для создания связи на основе нескольких столбцов из двух таблиц DirectQuery, соответствующие запросы отчета не попадут в кэш агрегатов в памяти. - Автоматические агрегации доступны только в службе Power BI. Power BI Desktop не создает системные статистические таблицы.
- Если вы изменяете метаданные модели с включенными автоматическими агрегациями, производительность запросов может снизиться до запуска следующего процесса обучения. Рекомендуется удалить автоматические агрегации, внести изменения, а затем переобучить.
- Не изменяйте и не удаляйте создаваемые системой таблицы агрегатов, если у вас не отключены автоматические агрегаты и вы не выполняете очистку модели. Система отвечает за управление этими объектами.
Сообщество
Power BI имеет активное сообщество, где MVPs, бизнес-специалисты и одноранговые специалисты делятся опытом в группах обсуждений, видео, блогах и многое другое. При изучении автоматических агрегаций обязательно ознакомьтесь с этими другими ресурсами: