Перейти к основному содержимому

Ограничения частоты запросов к API

dbt ограничивает частоту запросов к API dbt platform, чтобы обеспечить надёжную и предсказуемую работу интеграций.

Для Administrative API и Discovery API действуют разные ограничения. К административным эндпоинтам в /api/ можно отправлять больше запросов в минуту, а к GraphQL-эндпоинтам Discovery в /graphql/ — меньше, поскольку запросы Discovery часто возвращают больше данных за один вызов.

Для обоих API используются одни и те же учётные данные: персональные токены доступа, токены сервисных аккаунтов и OAuth, если ваша организация его поддерживает. Сведения о создании и использовании этих учётных данных приведены в разделе Токены аутентификации, а о назначении каждого API — в обзоре API.

На этой странице приведены стандартные ограничения частоты запросов для основных API и интерфейсов интеграции:

Сведения об области действия ограничений SCIM, ответах при ограничении частоты запросов и поведении поставщиков удостоверений приведены в разделах Подготовка пользователей через SCIM и IdP и Настройка SCIM. Сведения об интеграции MCP и сценариях его использования приведены в разделах Удалённый MCP и MCP на собственной инфраструктуре.

GraphQL-эндпоинты Discovery API и Semantic Layer

Ограничение Discovery API распространяется только на эндпоинт метаданных. GraphQL API Semantic Layer использует другой хост и имеет собственное ограничение частоты запросов.

Пагинация и Discovery API​

Чаще всего команды достигают ограничения Discovery API, многократно запрашивая очень маленькие страницы в GraphQL (например, first: 1). Каждая страница — это отдельный запрос, поэтому получение маленьких страниц требует гораздо большего количества вызовов, чем получение тех же данных более крупными порциями. Используйте наибольший подходящий вам размер страницы в пределах, допустимых для конкретного запроса (часто до 500). Полные примеры, в том числе пагинации с помощью after, приведены в разделе Выполнение запросов к Discovery API.

Подготовка пользователей через SCIM и IdP EnterpriseEnterprise +​

Для SCIM ограничение на уровне приложения в 20 запросов за каждые 5 секунд на аккаунт (Enterprise и Enterprise+) распространяется только на создание пользователя (POST /api/v3/accounts/{account_id}/scim/v2/Users) и замену пользователя (PUT /api/v3/accounts/{account_id}/scim/v2/Users/{user_id}). dbt подсчитывает запросы в фиксированном 5-секундном окне.

Оно не распространяется на запросы GET, PATCH и DELETE для пользователей; на любые операции с группами (создание, получение списка, получение отдельной группы, замена, частичное обновление или удаление); а также на другие эндпоинты SCIM, такие как конфигурация поставщика услуг, схемы, типы ресурсов или маршруты токенов конфигурации. Эти операции не подпадают под данное ограничение, но на них могут распространяться другие ограничения частоты запросов платформы.

При превышении этого ограничения dbt возвращает 429 Too Many Requests с обоими заголовками: Retry-After и x-rate-limit-retry-after-seconds (например, интеграции Okta часто учитывают Retry-After, а SailPoint — x-rate-limit-retry-after-seconds). Эти заголовки указывают, сколько времени нужно подождать перед отправкой следующего запроса. Настройте поставщика удостоверений так, чтобы он считывал заголовок, поддерживаемый вашим стеком подготовки пользователей, и повторял запросы с экспоненциальным увеличением задержки при ограничении частоты запросов.

Инструкции по настройке приведены в разделе Настройка SCIM. Сведения о лицензиях, разрешениях, SSO и роли SCIM в управлении доступом к аккаунту приведены в разделе О доступе пользователей в dbt.

Удалённый MCP​

Удалённый MCP использует то же стандартное глобальное ограничение частоты запросов, что и другие API dbt: 5 000 запросов в минуту на IP-адрес. Для него используются те же способы аутентификации, что и для других интеграций (например, персональные токены доступа, токены сервисных аккаунтов или OAuth, если он поддерживается).

При автоматизации с удалённым MCP придерживайтесь тех же правил, что и для любого другого API-клиента: не повторяйте запросы без пауз между попытками. Получив ответ 429, подождите перед повторной попыткой и увеличивайте задержку между попытками, если ответы 429 продолжают поступать.

API Semantic Layer​

dbt ограничивает частоту запросов к API Semantic Layer (GraphQL, JDBC и Python SDK) независимо от Administrative API и Discovery API. Ограничение Semantic Layer является общим для всех клиентов, пользователей и аккаунтов в одном экземпляре платформы (например, все аккаунты в US1 используют единое ограничение), поэтому вероятность его достижения зависит не только от объёма ваших запросов.

MCP на собственной инфраструктуре​

MCP на собственной инфраструктуре напрямую вызывает публичные Administrative API и Discovery API, поэтому к нему применяются их ограничения: 5 000 запросов в минуту на аккаунт для /api/ и 500 запросов в минуту для /graphql/, как указано выше.

Превышение ограничения частоты запросов​

При превышении ограничения Administrative API или Discovery API dbt возвращает 429 Too Many Requests и вводит пятиминутный период ожидания. Через пять минут можно снова отправлять запросы в обычном режиме.

Этот период ожидания не применяется к API Semantic Layer.

Превышение ограничения частоты запросов к API Semantic Layer​

Если вы получили ошибку 429 Too Many Requests, значит, вы превысили ограничение Semantic Layer. Периода ожидания нет, поэтому запросы снова начинают выполняться успешно, как только общая интенсивность использования опускается ниже ограничения. Чтобы снизить нагрузку от ваших запросов:

  • Объединяйте несколько метрик в один запрос.
  • Повторяйте запросы с экспоненциальным увеличением задержки и случайным разбросом интервалов вместо опроса с фиксированным интервалом.
  • Используйте предустановленные диапазоны дат вместо пользовательских, чтобы dbt мог повторно использовать кешированные результаты.
  • Заранее материализуйте метрики, которые можно предварительно агрегировать, с помощью экспортов или сохранённых запросов. Метрики, которые нельзя предварительно агрегировать, например количество уникальных значений, по-прежнему вычисляются в реальном времени.

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

Нашли ошибку?

0
Loading