Обзор функции Rollup

Данные, основанные на времени (документы, главным образом идентифицируемые по метке времени), часто имеют связанные политики хранения для управления ростом данных. Например, ваша система может генерировать 500 документов каждую секунду. Это приведет к генерации 43 миллионов документов в день и почти 16 миллиардов документов в год.

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

Стоимость хранения — это фиксированная величина. Хранение Y данных стоит X денег. Но полезность данных часто меняется со временем. Данные датчиков, собранные с временной меткой в миллисекунды, очень полезны прямо сейчас, достаточно полезны, если они из нескольких недель назад, и лишь незначительно полезны, если старше нескольких месяцев.

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

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

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

Если мы сжимаем 43 миллиона документов в часовые сводки, мы можем сэкономить огромное количество места. Функция Rollup автоматизирует этот процесс обобщения исторических данных.

Подробности настройки и конфигурации Rollup описаны в API создания задач.

Функция Rollup предоставляет новый конечный пункт поиска (/_rollup_search по сравнению со стандартным /_search), который знает, как искать по свернутым данным. Важно, что этот конечный пункт принимает 100% обычный Elasticsearch Query DSL. Вашему приложению не нужно изучать новый DSL для проверки исторических данных; оно может просто повторно использовать существующие запросы и панели.

Существуют некоторые ограничения функциональности; не все запросы и агрегации поддерживаются, некоторые функции поиска (выделение и т. д.) отключены, а доступные поля зависят от того, как была настроена функция Rollup. Эти ограничения более подробно описаны в Ограничения поиска Rollup.

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

Полезной функцией Rollup является возможность запроса как «живых» данных в реальном времени, так и исторических «свернутых» данных в одном запросе.

Например, ваша система может сохранять один месяц сырых данных. После месяца сырые данные сворачиваются в исторические сводки с помощью Rollup, а сырые данные удаляются.

Если вы запросите сырые данные, вы увидите только самые последние данные за месяц. И если вы запросите свернутые данные, вы увидите только данные старше месяца. Однако конечный пункт RollupSearch поддерживает одновременный запрос обоих типов данных. Он будет собирать результаты из обоих источников данных и объединять их. При наличии пересечения между «живыми» и «свернутыми» данными, предпочтение отдается «живым» данным для повышения точности.

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

Функция Rollup хранит данные таким образом, что запросы могут определить наименьший доступный интервал и использовать его для обработки. Если вы храните сворачивание с суточными интервалами, запросы могут выполняться с суточными или более длительными интервалами (недельные, месячные и т. д.) без необходимости явной настройки новой задачи сворачивания. Это помогает устранить один из основных недостатков системы сворачивания; уменьшенная гибкость по сравнению с исходными данными.