← Аналитика / analytics / analytics-engine

Выборка в WAE

Workers Analytics Engine позволяет записывать большие объёмы данных и быстро их извлекать при минимальных затратах или вовсе без них. Чтобы обеспечить запись больших объёмов данных по разумной цене, Workers Analytics Engine использует взвешенную адаптивную выборка ↗.

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

Для Analytics Engine это означает, что мы можем сжимать очень большие наборы данных до гораздо меньшего числа наблюдений и при этом отвечать на большинство запросов с очень высокой точностью. Благодаря этому мы можем предложить аналитический сервис, способный измерять очень высокие объёмы использования с неограниченной кардинальностью по низкой и предсказуемой цене.

На общем уровне выборка работает так:

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

В следующих разделах вы узнаете:

• Как работает выборка.
• Как читать выборочные данные.
• Как выполняется выборка данных.
• Как работает выборка Adaptive Bit Rate.
• Как выбрать индекс так, чтобы данные выбирались удобным для использования способом.

Выборка данных в Cloudflare работает похожим образом на онлайн-картографические сервисы вроде Google Maps, которые отрисовывают карты на разных уровнях масштабирования. Например, при просмотре спутникового снимка целого континента сервис подбирает изображение подходящего размера с учётом разрешения экрана пользователя и скорости его интернет-соединения.

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

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

Есть сходство между тем, как картографический сервис обрабатывает разрешение изображения, и тем, как Cloudflare Analytics предоставляет аналитику с помощью адаптивной выборки:

• Как данные хранятся:
  • Служба сопоставления: Изображения, сохранённые в разных разрешениях.
  • Cloudflare Analytics: События, сохранённые с разной частотой выборки.
• Как данные отображаются пользователю:
  • Служба сопоставления: Общее количество пикселей приблизительно постоянно для заданного размера экрана независимо от выбранной области.
  • Cloudflare Analytics: Для каждого запроса читается примерно одинаковое количество событий независимо от размера набора данных или выбранного периода времени.
• Как выбирается разрешение:
  • Служба сопоставления: Площадь, которую представляет один пиксель, зависит от размера отображаемой карты. Чем сильнее уменьшен масштаб карты, тем большую площадь занимает каждый пиксель.
  • Cloudflare Analytics: Интервал выборки для каждого события в результате зависит от размера исходного набора данных и выбранного периода времени. При запросе к большому набору данных или за длительный период каждое выборочное событие может представлять множество похожих событий.

Прежде чем эффективно писать запросы и анализировать данные, полезно разобраться, как в Workers Analytics Engine читаются выборочные данные.

В Workers Analytics Engine каждое событие записывается с полем _sample_interval поле. Интервал выборки является обратной величиной частоты выборки. Например, если применяется частота выборки в один процент (1%), sample_interval будет установлено значение 100.

Если говорить просто языком аналогии с картой, интервал выборки показывает «количество невыборочных точек данных» (километров или метров), которые представляет одна выборочная точка данных (пиксель).

Интервал выборки: это свойство, связанное с каждой отдельной строкой, хранящейся в Workers Analytics Engine. Из-за особенностей реализации равномерной выборки интервал выборки может отличаться для каждой строки. Поэтому при запросе данных нужно учитывать поле интервала выборки. Простого умножения результата запроса на постоянный коэффициент выборки недостаточно.

Ниже приведены примеры того, как записать некоторые распространённые запросы к выбранным данным.

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

Чтобы определить интервал выборки для каждого события, учтите, что в большинстве видов аналитики есть важные подгруппы, которые нужно анализировать с высокой точностью. Например, может потребоваться анализировать использование ресурсов пользователями или трафик к определённым именам хостов. Пользователи Analytics Engine могут задавать такие группы, заполняя index поле при записи события. Это позволяет проводить более целевой и точный анализ в рамках указанных групп.

Следующее наблюдение состоит в том, что для этих значений индекса, скорее всего, записано очень разное количество событий. На практике использование большинства веб-сервисов подчиняется Распределение Парето ↗, а значит, на нескольких самых активных пользователей будет приходиться подавляющая часть использования. Распределения Парето встречаются часто и выглядят так:

Если взять простая случайная выборка ↗ одного процента (1%) этих данных и применили эту выборку ко всей совокупности, вы могли бы точно отслеживать своих крупнейших клиентов, но потеряли бы представление о том, что делают ваши более мелкие клиенты:

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

Это показывает, что для большой совокупности может быть достаточно выборки в один процент (1%) или даже меньше, а для маленькой совокупности, чтобы получить точные результаты, может понадобиться хранить значительно большую долю событий.

Мы делаем это с помощью техники, которая называется равномерная выборка: количество сохраняемых событий выравнивается для каждого уникального значения индекса. Поэтому для относительно редких значений индекса мы можем записывать все получаемые точки данных через writeDataPoint(). Но если вы записываете много точек данных в одно значение индекса, мы начнём применять выборку.

То же распределение, но теперь с применением (симуляции) равномерной выборки:

Вы можете заметить, что этот график очень похож на первый. Однако для него требуется лишь <10% от общего объёма сохраняемых данных. Частота выборки на самом деле гораздо ниже, чем 10% для более крупных рядов (то есть мы храним более длинные интервалы выборки), однако для меньших рядов частота выборки выше.

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

Равномерная выборка обеспечивает хранение одинакового объёма данных для каждого индекса за определённый промежуток времени. При этом запросы могут существенно различаться по продолжительности анализируемого периода: одним достаточно десятиминутного снимка данных, а другим нужно анализировать данные за 10 недель, то есть период в 10 000 раз длиннее.

Чтобы решить эту проблему, мы используем метод под названием адаптивная битовая скорость ↗ (ABR). При ABR запросы, охватывающие более длительные периоды, получают данные с более крупным интервалом выборки, что позволяет уложиться в фиксированный лимит времени. Проще говоря, в нашей аналогии с картой размер экрана или пропускная способность являются фиксированным ресурсом, и время, необходимое для выполнения запроса, точно так же фиксировано. Поэтому независимо от объёма задействованных данных нам нужно ограничивать общее количество просматриваемых строк, чтобы уложиться в ответ на запрос. Это обеспечивает справедливость: независимо от размера запрашиваемого набора данных все запросы получают равную долю доступного вычислительного времени.

Для этого мы храним данные в нескольких разрешениях (то есть с разным уровнем детализации, например 100%, 10%, 1%), полученных из равномерно выбранных данных. Во время выполнения запроса мы выбираем наиболее подходящее разрешение данных для чтения в зависимости от сложности запроса. Сложность запроса определяется количеством строк, которые нужно получить, и вероятностью того, что запрос завершится в пределах заданного лимита времени N секунд. Динамически выбирая подходящее разрешение, мы оптимизируем производительность запроса и обеспечиваем его выполнение в рамках выделенного бюджета времени.

ABR даёт существенное преимущество: эта технология позволяет стабильно получать результаты запросов в рамках фиксированного бюджета запроса независимо от объёма данных и охватываемого периода. Этим ABR отличается от систем, которые при работе с большими наборами данных сталкиваются с таймаутами, ошибками или высокими затратами.

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

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

• Получите точную сводную статистику по всему набору данных, по всем значениям индекса.
• Получите точное количество уникальных значений вашего индекса.
• Получите точную сводную статистику (например, количество, сумму) для конкретного значения индекса.
• См. Top N значения определённых полей, которых нет в вашем индексе.
• Фильтровать можно по большинству полей.
• Выполните другие агрегации, например квантили.

Стоит учитывать следующие ограничения и компромиссы:

• Точные количества уникальных значений для полей, не входящих в индекс, могут быть недоступны.
  • Например, если вы индексируете по hostname, вы не сможете подсчитать количество уникальных URL-адресов.
• Очень редкие значения полей, не входящих в индекс, могут быть незаметны.
  • Например, конкретный URL для имени хоста, если вы индексируете по хосту и у вас миллионы уникальных URL.
• Точные запросы сразу по нескольким индексам могут быть недоступны.
  • Например, точных результатов можно ожидать только при запросе одного хоста за раз (или всех сразу).
• Нет гарантии, что можно получить какую-то одну конкретную запись.
• Точную последовательность событий восстановить не всегда возможно.

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

См. частые вопросы по Workers Analytics Engine, в частности о Сэмплирование.