Spec-Zone.ru › Elasticsearch 7
›Elasticsearch Guide [7.17] ›Агрегации

Агрегации с использованием конвейера

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

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

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

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

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

buckets_path Синтаксис

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

AGG_SEPARATOR       =  `>` ;
METRIC_SEPARATOR    =  `.` ;
AGG_NAME            =  <the name of the aggregation> ;
METRIC              =  <the name of the metric (in case of multi-value metrics aggregation)> ;
MULTIBUCKET_KEY     =  `[<KEY_NAME>]`
PATH                =  <AGG_NAME><MULTIBUCKET_KEY>? (<AGG_SEPARATOR>, <AGG_NAME> )* ( <METRIC_SEPARATOR>, <METRIC> ) ;

Например, путь "my_bucket>my_stats.avg" укажет на значение avg в метрике "my_stats", которая содержится в агрегации корзины "my_bucket".

Пути относительны к положению агрегации с использованием конвейера; они не являются абсолютными путями, и путь не может двигаться «вверх» по дереву агрегаций. Например, эта скользящая средняя встроена в date_histogram и ссылается на «братскую» метрику "the_sum":

POST /_search
{
  "aggs": {
    "my_date_histo": {
      "date_histogram": {
        "field": "timestamp",
        "calendar_interval": "day"
      },
      "aggs": {
        "the_sum": {
          "sum": { "field": "lemmings" } 
        },
        "the_movavg": {
          "moving_avg": { "buckets_path": "the_sum" } 
        }
      }
    }
  }
}

Метрика называется "the_sum"

buckets_path ссылается на метрику по относительному пути "the_sum"

buckets_path также используется для агрегаций с использованием конвейера типа «братья», где агрегация находится «рядом» с рядом корзин, а не «внутри» них. Например, агрегация max_bucket использует buckets_path для указания метрики, вложенной внутри братской агрегации:

POST /_search
{
  "aggs": {
    "sales_per_month": {
      "date_histogram": {
        "field": "date",
        "calendar_interval": "month"
      },
      "aggs": {
        "sales": {
          "sum": {
            "field": "price"
          }
        }
      }
    },
    "max_monthly_sales": {
      "max_bucket": {
        "buckets_path": "sales_per_month>sales" 
      }
    }
  }
}

buckets_path сообщает этой агрегации max_bucket, что мы хотим максимального значения агрегации sales в date_histogram sales_per_month.

Если агрегация с использованием конвейера типа «братья» ссылается на многокорзинную агрегацию, такую как агрегацию terms, у неё также есть возможность выбирать определённые ключи из многокорзинной агрегации. Например, агрегация bucket_script могла бы выбрать две определённые корзины (через их ключи корзин) для выполнения вычислений:

POST /_search
{
  "aggs": {
    "sales_per_month": {
      "date_histogram": {
        "field": "date",
        "calendar_interval": "month"
      },
      "aggs": {
        "sale_type": {
          "terms": {
            "field": "type"
          },
          "aggs": {
            "sales": {
              "sum": {
                "field": "price"
              }
            }
          }
        },
        "hat_vs_bag_ratio": {
          "bucket_script": {
            "buckets_path": {
              "hats": "sale_type['hat']>sales",   
              "bags": "sale_type['bag']>sales"    
            },
            "script": "params.hats / params.bags"
          }
        }
      }
    }
  }
}

buckets_path выбирает корзины hats и bags (через ['hat']/['bag']`) для использования в скрипте, вместо извлечения всех корзин из агрегации sale_type

Специальные пути

Вместо указания пути к метрике, buckets_path может использовать специальный "_count" путь. Это указывает агрегации с использованием конвейера использовать количество документов в качестве входных данных. Например, скользящая средняя может быть вычислена по количеству документов в каждой корзине, а не по определённой метрике:

POST /_search
{
  "aggs": {
    "my_date_histo": {
      "date_histogram": {
        "field": "timestamp",
        "calendar_interval": "day"
      },
      "aggs": {
        "the_movavg": {
          "moving_avg": { "buckets_path": "_count" } 
        }
      }
    }
  }
}

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

buckets_path также может использовать "_bucket_count" и путь к многокорзинной агрегации, чтобы использовать количество корзин, возвращаемых этой агрегацией, в агрегации с использованием конвейера вместо метрики. Например, можно использовать bucket_selector, чтобы отфильтровать корзины, которые не содержат корзин для вложенной агрегации terms:

POST /sales/_search
{
  "size": 0,
  "aggs": {
    "histo": {
      "date_histogram": {
        "field": "date",
        "calendar_interval": "day"
      },
      "aggs": {
        "categories": {
          "terms": {
            "field": "category"
          }
        },
        "min_bucket_selector": {
          "bucket_selector": {
            "buckets_path": {
              "count": "categories._bucket_count" 
            },
            "script": {
              "source": "params.count != 0"
            }
          }
        }
      }
    }
  }
}

Используя _bucket_count вместо имени метрики, мы можем отфильтровать histo корзины, где они не содержат корзин для агрегации categories

Обработка точек в именах агрегаций

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

"buckets_path": "my_percentile[99.9]"

Обработка пробелов в данных

Данные в реальном мире часто шумят и иногда содержат пробелы — места, где данных просто нет. Это может происходить по разным причинам, наиболее распространёнными из которых являются:

  • Документы, попадающие в корзину, не содержат требуемого поля
  • Нет документов, соответствующих запросу для одной или нескольких корзин
  • Метрика, которая вычисляется, не может сгенерировать значение, вероятно, потому, что отсутствует значение в другой зависящей корзине. Некоторые агрегации с использованием конвейера имеют определённые требования, которые должны быть выполнены (например, производная не может вычислить метрику для первого значения, потому что нет предыдущего значения, скользящая средняя HoltWinters нуждается в данных «прогревания» для начала вычисления и т. д.)

Политики пробелов — это механизм для информирования агрегации с использованием конвейера о желаемом поведении при обнаружении «пробельных» или отсутствующих данных. Все агрегации с использованием конвейера принимают параметр gap_policy. В настоящее время доступно две политики пробелов:

skip
Этот вариант обрабатывает отсутствующие данные так, как будто корзины не существует. Он пропустит корзину и продолжит вычисление, используя следующее доступное значение.
insert_zeros
Этот вариант заменит отсутствующие значения нулём (0) и вычисление агрегации с использованием конвейера продолжится нормально.
keep_values
Этот вариант похож на skip, но если метрика предоставляет не null, не NaN значение, это значение используется, в противном случае пустая корзина пропускается.

Ошибки валидации

Недействительная агрегация с использованием конвейера возвращает код состояния HTTP 400 и список связанных ошибок валидации. До версии 7.7 недействительная агрегация с использованием конвейера возвращала код состояния HTTP 500 и первую встреченную ошибку валидации.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/search-aggregations-pipeline.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API