← Аналитика / analytics / faq

Несогласованные результаты GraphQL API

Если вы несколько раз выполняете один и тот же запрос GraphQL Analytics API и каждый раз получаете немного разные результаты, это вызвано выборкой Adaptive Bit Rate (ABR). ABR динамически подстраивает разрешение данных под сложность запроса и время выполнения, из-за чего результаты разных запусков могут немного отличаться.

Чтобы уменьшить разброс, запрашивайте более короткие периоды (день или неделю вместо месяца) и используйте агрегированные наборы данных (узлы с Groups суффикс) и запрашивать доверительные интервалы, чтобы оценить качество данных. Дополнительные сведения см. в Сэмплирование.

Что такое выборка?

Конвейер данных Cloudflare обрабатывает более 700 миллионов событий в секунду по всей глобальной сети. Обрабатывать все эти данные в реальном времени для каждого запроса было бы непомерно дорого и долго.

Выборка анализирует лишь часть данных, а не каждую отдельную точку данных. Cloudflare использует выборку Adaptive Bit Rate (ABR), чтобы запросы выполнялись быстро даже при работе с большими наборами данных.

ABR хранит данные в нескольких разрешениях:

100% : полные данные (используются для небольших наборов данных)
10% : выборка 10% (среднее разрешение)
1% : выборка 1% (более низкое разрешение)

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

Почему результаты отличаются между запусками запроса?

Результаты могут отличаться по нескольким причинам:

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

Например, если один и тот же запрос за 30 дней выполнить дважды, в первый раз он может вернуть 3,500 объектов, а во второй раз уже 3,600. Это означает, что использовалось разное разрешение выборки.

Можно ли доверять выборочным данным?

Да. Данные, полученные с помощью выборки, высоко надёжны и дают такие же достоверные результаты, как и данные, полученные из полных наборов данных. Методы выборки Cloudflare отражают основные характеристики всего набора данных.

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

Как уменьшить расхождения в результатах запросов?

Запрос более коротких временных диапазонов

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

До (более изменчиво):

datetime_geq: "2024-09-01T00:00:00Z"
datetime_lt: "2024-10-01T00:00:00Z"

После (более согласованно):

datetime_geq: "2024-09-01T00:00:00Z"
datetime_lt: "2024-09-02T00:00:00Z"

Затем агрегируйте результаты на стороне клиента. При меньших временных окнах агрессивные пороги выборки срабатывают реже.

Использование агрегированных наборов данных

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

Например, используйте httpRequestsAdaptiveGroups вместо необработанных данных событий.

Добавьте явную сортировку

Всегда указывайте orderBy в своих запросах, чтобы обеспечить неизменный порядок результатов:

orderBy: [datetime_ASC]

Использование доверительных интервалов

Для адаптивных наборов данных запрашивайте доверительные интервалы чтобы оценить качество данных и проверить выборку:

confidence(level: 0.95) {
  count {
    estimate
    lower
    upper
    sampleSize
  }
}

Более высокий sampleSize означает более надёжные результаты.

Краткий справочник

Issue	Противодействие
Результаты отличаются между запусками	Запрос более коротких временных диапазонов (по дням или неделям вместо месяцев)
Агрессивная выборка при больших запросах	Разбивайте запросы на более короткие временные интервалы и агрегируйте данные на стороне клиента
Нужен единообразный порядок сортировки	Добавить `orderBy` секцию ко всем запросам
Нужно проверить качество данных	Запрос `confidence` интервалов для проверки размера выборки и точности
Использование необработанных адаптивных данных	Переключитесь на агрегированные наборы данных (узлы с `Groups` суффикс)