Размер локального шлюза данных

Эта статья предназначена для администраторов Fabric, которым необходимо установить и управлять локальным шлюзом данных .

Шлюз необходим, когда Power BI должен получать доступ к данным, которые недоступны непосредственно через Интернет. Его можно установить на сервере на территории заказчика или на предоставленной как услуга (IaaS) инфраструктуре, размещенной на виртуальной машине.

Рабочие нагрузки шлюза

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

Кэшированные рабочие нагрузки данных

Рабочая нагрузка кэшированных данных извлекает и преобразует исходные данные для загрузки в семантические модели Power BI. Это делается в трех шагах:

1. Подключение: шлюз подключается к исходным данным.
2. Получение и преобразование данных: данные извлекаются и при необходимости преобразуются. Когда это возможно, подсистема mashup Power Query отправляет шаги преобразования в источник данных, это называется свертыванием запроса. Если это невозможно, процесс преобразования должен выполняться сетевым шлюзом. В этом случае шлюз будет использовать больше ресурсов ЦП и памяти.
3. Передача: данные передаются в служба Power BI— важно надежное и быстрое подключение к Интернету, особенно для больших объемов данных.

Рабочие нагрузки Live Connection и DirectQuery

Рабочая нагрузка Live Connection и DirectQuery работает в основном в режиме сквозной передачи. Служба Power BI отправляет запросы, а шлюз отвечает с результатами запроса. Как правило, результаты запроса имеют небольшой размер.

• Для получения дополнительной информации о живом подключении см. в разделе семантических моделей в службе Power BI (внешне размещенные модели).
• Для получения дополнительных сведений о DirectQuery см. раздел Режимы семантической модели в службе Power BI (режим DirectQuery).

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

Важно обеспечить надежное, быстрое и стабильное подключение, чтобы пользователи отчетов могли получать оперативный доступ.

Учет факторов при выборе размера

Определение правильного размера компьютера шлюза может зависеть от следующих переменных:

• для рабочих нагрузок данных кэша:
  • Количество одновременных обновлений семантической модели
  • Типы источников данных (реляционная база данных, база данных аналитики, веб-каналы данных или файлы)
  • Объем данных, получаемых из источников данных
  • Любые преобразования, которые необходимо выполнить с помощью механизма группировки данных Power Query
  • Объем данных, передаваемых в служба Power BI
• для рабочих нагрузок Live Connection и DirectQuery:
  • Число одновременных пользователей отчета
  • Количество визуальных элементов на страницах отчетов (каждый визуальный элемент отправляет по крайней мере один запрос)
  • Частота обновлений кэша запросов панели мониторинга Power BI
  • Количество отчетов в режиме реального времени с помощью функции автоматического обновления страницы
  • Защищают ли семантические модели безопасность на уровне строк (RLS)

Как правило, для рабочих нагрузок Live Connection и DirectQuery требуется достаточно ЦП, а рабочие нагрузки данных кэша требуют больше ЦП и памяти. Обе рабочие нагрузки зависят от хорошего подключения к служба Power BI и источникам данных.

Рекомендации

Рекомендации по размеру шлюза зависят от многих переменных. В этом разделе приведены общие рекомендации, которые можно учитывать.

Начальное определение размера

Трудно точно оценить правильный размер. Рекомендуется начать работу с компьютером с по крайней мере 8 ядрами ЦП, 8 ГБ ОЗУ и несколькими сетевыми адаптерами Gigabit. Затем можно измерить типичную рабочую нагрузку шлюза, залогировав счетчики системы центрального процессора и памяти. Дополнительные сведения см. в статье "Мониторинг и оптимизация производительности локального шлюза данных".

Подключение

Запланируйте оптимальное подключение между служба Power BI и шлюзом, а также шлюзом и источниками данных.

• Стремиться к надежности, быстрой скорости и низкой, согласованной задержке.
• Исключите — или уменьшите — перескоки между сетевым шлюзом и вашими источниками данных.
• Удалите любые ограничения сети, введенные на уровне прокси-сервера брандмауэра. Дополнительные сведения о конечных точках Power BI см. в статье "Добавление URL-адресов Power BI" в список разрешений.
• Настройте Azure ExpressRoute для установления частных управляемых подключений к Power BI.
• Для источников данных на виртуальных машинах Azure убедитесь, что виртуальные машины совместно размещаются с службой Power BI.
• Для рабочих нагрузок динамических подключений к службам SQL Server Analysis Services (SSAS), включающих динамические RLS, убедитесь в хорошем подключении между компьютером шлюза и локальной службой Active Directory.

Кластеризация

Для крупномасштабных развертываний можно создать шлюз с несколькими членами кластера. Кластеры избегают отдельных точек сбоя и могут балансировать трафик между шлюзами. Вы можете:

• Установите один или несколько шлюзов в кластере.
• Изолируйте рабочие нагрузки для автономных шлюзов или кластеров шлюзовых серверов.

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

Проектирование и параметры семантической модели

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

Для семантических моделей импорта:

• Настройте менее частое обновление данных.
• Настройте добавочное обновление, чтобы свести к минимуму объем передаваемых данных.
• По возможности убедитесь , что выполняется свертывание запросов.
• Особенно для больших объемов данных или потребности в низкой задержке, преобразуйте структуру в модель DirectQuery или составную модель.

Для семантических моделей DirectQuery:

• Оптимизируйте источники данных, модели и проекты отчетов— для получения дополнительной информации см руководство по модели DirectQuery в Power BI Desktop.
• Создайте агрегаты для кэширования результатов более высокого уровня, чтобы уменьшить количество запросов DirectQuery.
• Ограничьте интервалы автоматического обновления страницы в макетах отчетов и настройках производительности.
• Особенно при принудительном применении динамической RLS, ограничьте частоту обновления кэша панели мониторинга.
• Особенно для небольших объемов данных или для неизменяемых данных преобразуйте структуру в модель импорта или составная модель.

Для семантических моделей активного подключения:

• Особенно при принудительном применении динамической RLS, ограничьте частоту обновления кэша панели мониторинга.

Связанный контент

Дополнительные сведения, связанные с этой статьей, см. в следующих ресурсах:

• Планирование реализации Power BI: шлюзы данных
• Guidance for deploying a data gateway for Power BI (Руководство по развертыванию шлюза данных для Power BI)
• Настройка параметров прокси-сервера для локального шлюза данных
• Monitor and optimize on-premises data gateway performance (Мониторинг и оптимизация производительности локального шлюза данных)
• Устранение неполадок шлюзов — Power BI
• Устранение неполадок с локальным шлюзом данных
• Важность свертывания запросов
• Вопросы? попробуйте обратиться к сообществу Fabric
• Есть предложения? Вносите идеи по улучшению Fabric