はてだBlog(仮称)

私的なブログど真ん中のつもりでしたが、気づけばWebサイト系のアプリケーション開発周りで感じたこと寄りの自分メモなどをつれづれ述べています。2020年6月現在、Elasticsearch、pandas、CMSなどに関する話題が多めです。...ですが、だんだんとより私的なプログラムのスニペット置き場になりつつあります。ブログで述べている内容は所属組織で販売している製品などに関するものではなく、また所属する組織の見解を代表するものではありません。

ElasticsearchのAggregations(nested,reverse_nested,parent,children)の例

はじめに

ElasticsearchのAggregationsのnested,reverse_nested,parent,childrenについては次の過去記事ではごまかして説明をスキップしたので、あらためてまとめてみました。

itdepends.hateblo.jp

まとめてみた... と言っても、公式の例を筆者なりに噛み砕いた例におきかえただけですので悪しからず。

www.elastic.co

www.elastic.co

www.elastic.co

www.elastic.co

なぜこの4つか

...というほど大げさな話ではないものの、Bucket Aggregationsに所属するこの4つのAggsですが、実際のところ、同じBucket Aggregationsの最も定番かなと思われるtermsクエリと実際はほぼ一緒と言えると思います。

じゃあ、ほぼ一緒じゃない部分はどこかというと、termsはいくつかあるElasticsearchの基本的なデータタイプをターゲットにしているのに対し、この4つはnested、join(parent,children)というRDBでは苦手(というと語弊があるかもしれませんがひとまず)な検索エンジンおもしろじゃんという変わった型を扱うところが違います。

まあ、つまるところ、これらの型についてもterms Aggが使えるように拡張されたクエリととらえて良いのではないでしょうか。

Nested field type | Elasticsearch Guide [master] | Elastic

Join field type | Elasticsearch Guide [master] | Elastic

なお、この記事はElasticsearch ver 6.8 で確認して記述しました。ただし、ここで記述した範囲のことの本質は ver 7系でも変わっていないと思います。(違ったらごめんなさい)

ためしてみる

(1)nested, reverse_nested

ある製品種別に対して、取り扱い業者(販売業者ということにしました)がA、B、...のようにいて、業者には担当者がいるとしたデータを考えます。 また、販売業者ごとに同じ製品種別でも販売価格が違うこととします。

nestedデータの仕込み

PUT /products?include_type_name=false
{
  "mappings": {
    "properties": {
      "resellers": {
        "type": "nested",
        "properties": {
          "reseller": { "type": "keyword" },
          "staff":{"type":"keyword"},
          "price": { "type": "double" }
        }
      }
    }
  }
}
PUT /products/_doc/0
{
  "name": "LED TV",
  "n":"エルイーディーテレビ",
  "resellers": [
    {
      "reseller": "companyA",
      "staff": "Hachimura-San",
      "price": 350
    },
    {
      "reseller": "companyB",
      "staff": "Ohtani-San",
      "price": 500
    }
  ]
}

PUT /products/_doc/1
{
  "name": "dryer", 
  "n":"ドライヤー",
  "resellers": [
    {
      "reseller": "companyA",
      "staff": "Ohsaka-San",
      "price": 50
    },
    {
      "reseller": "companyB",
      "staff": "Ohtani-San",
      "price": 65
    },
        {
      "reseller": "companyC",
      "staff": "Nishigori-San",
      "price": 65
    }
  ]
}

製品情報に対して、これを取り扱う販売業者の情報を直接保持するというデータをある種自然な形で保持できるというところがポイントですね。 (JSON的には、オブジェクトの配列で保持されているところに注目)

(A)nested Agg

うまくいかない例

nested Aggの文法例を示す前に、あえてうまくいかない例を示します。

nested データタイプとかどうとかはひとまず考えず、Elasticsearchには、resellers.resellerみたいなドットで区切ってフィールドを指定できるパターンがあります。

常にうろ覚えの筆者のようなヒトだと次のようなクエリでいけそうな気がするのです。

GET /products/_search
{
  "size":0,
  "aggs": {
    "製品種別ごとの": {
      "terms": {
        "field": "name.keyword"
      },
      "aggs": {
        "について、販売業者の一覧": {
          "terms": {
            "field": "resellers.reseller"
          }
        }
      }
    }
  }
}

が、結果としては次のようになりそれらしき値は取得できません。

{
  "aggregations" : {
    "製品種別ごとの" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "LED TV",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [ ]
          }
        },
        {
          "key" : "dryer",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [ ]
          }
        }
      ]
    }
  }
}

nested を使った動作する例1

nested型のフィールドにはおまじないが必要です。

GET /products/_search
{
  "size":0,
  "aggs": {
    "製品種別ごとの": {
      "terms": {
        "field": "name.keyword"
      },
      "aggs": {
        "について、販売業者の一覧": {
          "nested": {
            "path": "resellers"
          },
          "aggs": {
            "名前": {
              "terms": {
                "field": "resellers.reseller"
              }
            }
          }
        }
      }
    }
  }
}

クエリの結果↓

{
  "aggregations" : {
    "製品種別ごとの" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "LED TV",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count" : 2,
            "名前" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "companyA",
                  "doc_count" : 1
                },
                {
                  "key" : "companyB",
                  "doc_count" : 1
                }
              ]
            }
          }
        },
        {
          "key" : "dryer",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count" : 3,
            "名前" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "companyA",
                  "doc_count" : 1
                },
                {
                  "key" : "companyB",
                  "doc_count" : 1
                },
                {
                  "key" : "companyC",
                  "doc_count" : 1
                }
              ]
            }
          }
        }
      ]
    }
  }
}

nested を使った動作する例2

nestedを間に挟めば、Metrics aggregationも使えます。 最安価格をチョイスします。

GET /products/_search
{
  "size":0,
  "aggs": {
    "製品種別ごとの": {
      "terms": {
        "field": "name.keyword"
      },
      "aggs": {
        "について、販売業者の一覧": {
          "nested": {
            "path": "resellers"
          },
          "aggs": {
            "最安価格": {
              "min": {
                "field": "resellers.price"
              }
            }
          }
        }
      }
    }
  }
}

クエリの結果↓

{
  "aggregations" : {
    "製品種別ごとの" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "LED TV",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count" : 2,
            "最安価格" : {
              "value" : 350.0
            }
          }
        },
        {
          "key" : "dryer",
          "doc_count" : 1,
          "について、販売業者の一覧" : {
            "doc_count" : 3,
            "最安価格" : {
              "value" : 50.0
            }
          }
        }
      ]
    }
  }
}

(B)reverse nested Agg

つづいてreverse_nested です。

こちらは、nestedを下敷きに、nested内にある、ある値を持つドキュメントをトップレベルの値のバリエーションでグループ化できるというやつです。

(販売業者の)各担当者がどの製品を担当しているかといったことを先述のドキュメントから抽出するのが次のreverse_nestedを使ったクエリです。

GET /products/_search
{
  "size": 0,
  "aggs": {
    "(販売業者)": {
      "nested": {
        "path": "resellers"
      },
      "aggs": {
        "担当者が": {
          "terms": {
            "field": "resellers.staff"
          },
          "aggs": {
            "どの製品を担当しているか": {
              "reverse_nested": {},
              "aggs": {
                "___": {
                  "terms": {
                    "field": "name.keyword"
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

↑クエリ構造としては、aggsの4階層なのですが、3階層目に「reverse_nested:{}」のおまじないを入れることで、4階層目にあるドキュメントのトップに定義されているフィールドであるnameを使ってドキュメント全体をバケットにグループ分けできる...という理解でいいと思います。 ↓ 検索結果です。

{
  "aggregations" : {
    "(販売業者)" : {
      "doc_count" : 5,
      "担当者が" : {
        "doc_count_error_upper_bound" : 0,
        "sum_other_doc_count" : 0,
        "buckets" : [
          {
            "key" : "Ohtani-San",
            "doc_count" : 2,
            "どの製品を担当しているか" : {
              "doc_count" : 2,
              "___" : {
                "doc_count_error_upper_bound" : 0,
                "sum_other_doc_count" : 0,
                "buckets" : [
                  {
                    "key" : "LED TV",
                    "doc_count" : 1
                  },
                  {
                    "key" : "dryer",
                    "doc_count" : 1
                  }
                ]
              }
            }
          },
          {
            "key" : "Hachimura-San",
            "doc_count" : 1,
            "どの製品を担当しているか" : {
              "doc_count" : 1,
              "___" : {
                "doc_count_error_upper_bound" : 0,
                "sum_other_doc_count" : 0,
                "buckets" : [
                  {
                    "key" : "LED TV",
                    "doc_count" : 1
                  }
                ]
              }
            }
          },
          {
            "key" : "Nishigori-San",
            "doc_count" : 1,
            "どの製品を担当しているか" : {
              "doc_count" : 1,
              "___" : {
                "doc_count_error_upper_bound" : 0,
                "sum_other_doc_count" : 0,
                "buckets" : [
                  {
                    "key" : "dryer",
                    "doc_count" : 1
                  }
                ]
              }
            }
          },
          {
            "key" : "Ohsaka-San",
            "doc_count" : 1,
            "どの製品を担当しているか" : {
              "doc_count" : 1,
              "___" : {
                "doc_count_error_upper_bound" : 0,
                "sum_other_doc_count" : 0,
                "buckets" : [
                  {
                    "key" : "dryer",
                    "doc_count" : 1
                  }
                ]
              }
            }
          }
        ]
      }
    }
  }
}

(2)join系(parent,children)

join系(parent,children)の例です。

join系データの仕込み

まず、joinタイプを使ったデータを仕込みます。

公式の「stack overflow」風の例を少し置き換えた、以下のようなデータを仕込みます。 (親となる質問ドキュメント(Q)と子となる回答ドキュメント("ANSWER"でラベリング&親のドキュメントIDを指定))から構成されます。)

PUT cp_example?include_type_name=false
{
  "mappings": {
    "properties": {
      "join": {
        "type": "join",
        "relations": {
          "Q": "ANSWER"
        }
      }
    }
  }
}
PUT cp_example/_doc/1
{
  "join": {
    "name": "Q"
  },
  "body": "Windows2003とWindows2008の話です...",
  "title": "ファイルの転送",
  "TAGS": [
    "WIN2003",
    "WIN2008",
    "FTP"
  ]
}

PUT cp_example/_doc/2?routing=1
{
  "join": {
    "name": "ANSWER",
    "parent": "1"
  },
  "OWNER": "太郎",
  "body": "WinでFTPはやめた方が...",
  "creation_date": "2009-05-04T13:45:37.030"
}

PUT cp_example/_doc/3?routing=1
{
  "join": {
    "name": "ANSWER",
    "parent": "1"
  },
  "OWNER": "花子",
  "body": "Linuxを使え...",
  "creation_date": "2009-05-05T13:45:37.030"
}

PUT cp_example/_doc/4?routing=1
{
  "join": {
    "name": "ANSWER",
    "parent": "1"
  },
  "OWNER": "花子",
  "body": "macはLinuxではない。BSDは...",
  "creation_date": "2009-05-05T13:46:01.021"
}

(C)childrenと(D)parent

以下、childrenとparentをまとめて例示します。

各タグに関して、回答者の一覧とその回答投稿数を"children"を使って取得します。 また、回答者ごとの回答をおこなった質問のタグ(分野)の一覧を"parent"を使って取得します。

(やりたいことが対照的になっていることと、それに合わせて実際のクエリのカタチもchildren、parentを境に反転したイメージになっていることにご注目ください。)

POST cp_example/_search?size=0
{
  "aggs": {
    "TAGS": {
      "terms": {
        "field": "TAGS.keyword",
        "size": 10
      },
      "aggs": {
        "というタグの質問への": {
          "children": {
            "type" : "ANSWER" 
          },
          "aggs": {
            "回答者、その回答投稿数": {
              "terms": {
                "field": "OWNER.keyword",
                "size": 10
              }
            }
          }
        }
      }
    }
  }
}
POST cp_example/_search?size=0
{
  "aggs": {
    "OWNERS": {
      "terms": {
        "field": "OWNER.keyword",
        "size": 10
      },
      "aggs": {
        "という人の": {
          "parent": {
            "type" : "ANSWER" 
          },
          "aggs": {
            "答えている質問のタグ(分野)の一覧": {
              "terms": {
                "field": "TAGS.keyword",
                "size": 10
              }
            }
          }
        }
      }
    }
  }
}

↓クエリの結果(children)

{
  "aggregations" : {
    "TAGS" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "FTP",
          "doc_count" : 1,
          "というタグの質問への" : {
            "doc_count" : 3,
            "回答者、その回答投稿数" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "花子",
                  "doc_count" : 2
                },
                {
                  "key" : "太郎",
                  "doc_count" : 1
                }
              ]
            }
          }
        },
        {
          "key" : "WIN2003",
          "doc_count" : 1,
          "というタグの質問への" : {
            "doc_count" : 3,
            "回答者、その回答投稿数" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "花子",
                  "doc_count" : 2
                },
                {
                  "key" : "太郎",
                  "doc_count" : 1
                }
              ]
            }
          }
        },
        {
          "key" : "WIN2008",
          "doc_count" : 1,
          "というタグの質問への" : {
            "doc_count" : 3,
            "回答者、その回答投稿数" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "花子",
                  "doc_count" : 2
                },
                {
                  "key" : "太郎",
                  "doc_count" : 1
                }
              ]
            }
          }
        }
      ]
    }
  }
}

↓クエリの結果(parent)

{
  "aggregations" : {
    "OWNERS" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "花子",
          "doc_count" : 2,
          "という人の" : {
            "doc_count" : 1,
            "答えている質問のタグ(分野)の一覧" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "FTP",
                  "doc_count" : 1
                },
                {
                  "key" : "WIN2003",
                  "doc_count" : 1
                },
                {
                  "key" : "WIN2008",
                  "doc_count" : 1
                }
              ]
            }
          }
        },
        {
          "key" : "太郎",
          "doc_count" : 1,
          "という人の" : {
            "doc_count" : 1,
            "答えている質問のタグ(分野)の一覧" : {
              "doc_count_error_upper_bound" : 0,
              "sum_other_doc_count" : 0,
              "buckets" : [
                {
                  "key" : "FTP",
                  "doc_count" : 1
                },
                {
                  "key" : "WIN2003",
                  "doc_count" : 1
                },
                {
                  "key" : "WIN2008",
                  "doc_count" : 1
                }
              ]
            }
          }
        }
      ]
    }
  }
}

ElasticsearchのAggsで「グループ内で最大値をとるレコードを抽出する」風の実現例(邪道流)

はじめに

Elasticsearchでは、SQLでいうところのGROUP BYに近い挙動となるAggregationsというクエリがあります。

ここ何回かの過去記事でもAggregationsをちょいと雑に俯瞰する記事を投稿しました。

itdepends.hateblo.jp

なおこのAggregationsですが、GROUP BYに近いというものの、SQLでのGROUP BYと副問い合わせなどを駆使した「グループ内で最大値をとるレコードを抽出する」といったことは(私がモグリで見逃しているだけかもしれませんが)直接的な方法はありません。

検索エンジンの用法・用途としては、無理にこの仕組みはいらないな〜、少なくともその対応のために、新しいクエリのシンタックスを覚えたりするのはめんどくさいな〜と思いつつ、どうしても小手先のワザで済ませたい場合のある手法の一例を共有します。

途中はさみこむワザはやや邪道かもしれませんが、はからずもAggregationsのシンタックスや挙動を深く理解することにもつながるかもしれませんので、記事にしてみた次第です。

考え方

具体的なアイディアの土台としては、次の図のように、「ドキュメントの中にそのドキュメントを象徴する複合項目(図では「サマリ」項目と呼びました)を再掲」しておき、そこにからめて所定のAggregationsをかませる、です。

f:id:azotar:20210713165847p:plain

ま、それでいいなら可能だよなと思った方、ごめんなさい。先に謝っておきます。

お、邪道だけどアリかもと思っていただいた方ありがとうございます。もちろん、いろいろと効率が悪いというか目的外使用の側面はあると思いますので、ご利用時はパフォーマンス含めご注意ください。

なお、サマリ項目と言えば、runtime_mappingという動的にAggregationの対象フィールドを擬似的に生成するオプションが7.x系で追加になっているようです。 もちろん他の用途をイメージしたものだと思いますが、「サマリ」フィールドをインデックス時に考えなくて良いという本手法の選択肢が増えたといえるかもしれません。

本記事は6.8系で確認した都合、runtime_mappingの説明は含めていませんが、そもそも本記事の邪道用途に限らずおもしろい仕掛けなのでご紹介しておきます。

www.elastic.co

Runtime fields | Elasticsearch Guide [7.13] | Elastic

ということで以下事例です。

データインポート

ちょっと冗長ですが、以下のデータを入れてみてください。

※直接使うのは、aフィールド、dフィールド、そして上の方で、便宜上「サマリ」フィールドと呼称したものに該当するのが、complフィールドです。

aフィールド(のちの例では「a.keyword」となります)でグループ化すると5グループで、うち4グループは配下に5件、1グループだけ6件となるようなデータ群です。

POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "compl": "a10:10:0", "d": 0, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "compl": "a10:10:1", "d": 1, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "compl": "a10:10:2", "d": 2, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "compl": "a10:10:3", "d": 3, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "compl": "a10:10:4", "d": 4, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "compl": "a100:100:1000", "d": 5, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "compl": "a100:100:1001", "d": 6, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "compl": "a100:100:1002", "d": 7, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "compl": "a100:100:1003", "d": 8, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "compl": "a100:100:1004", "d": 9, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "compl": "a1000:1000:2000", "d": 10, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "compl": "a1000:1000:2001", "d": 11, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "compl": "a1000:1000:2002", "d": 12, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "compl": "a1000:1000:2003", "d": 13, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "compl": "a1000:1000:2004", "d": 14, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "compl": "a10000:10000:3000", "d": 15, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "compl": "a10000:10000:3001", "d": 16, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "compl": "a10000:10000:3002", "d": 17, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "compl": "a10000:10000:3003", "d": 18, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "compl": "a10000:10000:3004", "d": 19, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:4000", "d": 20, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:4001", "d": 21, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:4002", "d": 22, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:4003", "d": 23, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:4004", "d": 24, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "compl": "a100000:100000:9999", "d": 24, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}

1. グループごとの擬似レコード一覧(ウォーミングアップ)

GET a_ex/_search?size=0&filter_path=agg*
{
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "c_list": {
                    "terms": {
                        "field": "compl.keyword",
                            "size": 3
                    }
                }
            }
        }
    }
}

結果

aフィールドでグループ化しつつ、実質ユニークなフィールドcomplでサブグループ化するので配下の一覧が得られます。 (ここでは、全件ではなく、(結果的に)DB出現順に3件ずつ取得しています。)

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 3,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1
              }
            ]
          }
        },
        {
          "key" : "a10",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "a10:10:0",
                "doc_count" : 1
              },
              {
                "key" : "a10:10:1",
                "doc_count" : 1
              },
              {
                "key" : "a10:10:2",
                "doc_count" : 1
              }
            ]
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "a100:100:1000",
                "doc_count" : 1
              },
              {
                "key" : "a100:100:1001",
                "doc_count" : 1
              },
              {
                "key" : "a100:100:1002",
                "doc_count" : 1
              }
            ]
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "a1000:1000:2000",
                "doc_count" : 1
              },
              {
                "key" : "a1000:1000:2001",
                "doc_count" : 1
              },
              {
                "key" : "a1000:1000:2002",
                "doc_count" : 1
              }
            ]
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "a10000:10000:3000",
                "doc_count" : 1
              },
              {
                "key" : "a10000:10000:3001",
                "doc_count" : 1
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1
              }
            ]
          }
        }
      ]
    }
  }
}

2. あるフィールド値の合計がある値以上のグループに限定した擬似レコード一覧

GET a_ex/_search?size=0&filter_path=agg*
{
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "c_list": {
                    "terms": {
                        "field": "compl.keyword",
                            "size": 3
                    }
                },
                "the_sum": {
                    "sum": {
                        "field": "b"
                    }
                },
                "my_selection": {
                    "bucket_selector": {
                        "buckets_path": {
                            "p": "the_sum"
                        },
                        "script": "params.p > 5000"
                    }
                }
            }
        }
    }
}

bucket_selectorを使って、合計が5000より大きいグループのみに限定しています。 今回のデータの場合、a10000とa100000のグループのみ抽出されます。

結果

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 3,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1
              }
            ]
          },
          "the_sum" : {
            "value" : 600000.0
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "a10000:10000:3000",
                "doc_count" : 1
              },
              {
                "key" : "a10000:10000:3001",
                "doc_count" : 1
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1
              }
            ]
          },
          "the_sum" : {
            "value" : 50000.0
          }
        }
      ]
    }
  }
}

3. 配下件数が多いグループのみ擬似一覧抽出

GET a_ex/_search?size=0&filter_path=agg*
{
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "c_list": {
                    "terms": {
                        "field": "compl.keyword"
                    }
                },
                "count": {
                    "value_count": {
                        "field": "b"
                    }
                },
                "myfilter": {
                    "bucket_selector": {
                        "buckets_path": {
                            "c": "count"
                        },
                        "script": "params.c > 5"
                    }
                }
            }
        }
    }
}

結果

グループ配下のレコード数が5より大のものが抽出されるので、6件レコードがある、a100000グループの配下の6件が抽出されます。

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4003",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:4004",
                "doc_count" : 1
              },
              {
                "key" : "a100000:100000:9999",
                "doc_count" : 1
              }
            ]
          },
          "count" : {
            "value" : 6
          }
        }
      ]
    }
  }
}


4. グループごとにグループ配下の擬似レコードと特定フィールドをペアで抜き出し(sumは実際は1件のレコードの合計なので1つの値を抽出)

おさらい1

complフィールドが実質ユニークなので、そのサブAggsのさらにサブサブAggsで合計を取得すると実際は1件のレコードのあるフィールドの合計つまり値そのものなので、そのような取得を行ってみます。邪道感が増しますが、実質ユニークフィールドに固めた項目以外の項目が欲しい場合とともに、次項のクエリの下敷きの例となっています。

GET a_ex/_search?size=0&filter_path=agg*
{
            "aggs": {
                "grp": {
                    "terms": {
                        "field": "a.keyword"
                    },
                    "aggs": {
                        "c_list": {
                            "terms": {
                                "field": "compl.keyword"
                            },
                            "aggs": {
                                "dValue": {
                                    "sum": {
                                        "field": "d"
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }

結果

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 20.0
                }
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 21.0
                }
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 22.0
                }
              },
              {
                "key" : "a100000:100000:4003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 23.0
                }
              },
              {
                "key" : "a100000:100000:4004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              },
              {
                "key" : "a100000:100000:9999",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10:10:0",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 0.0
                }
              },
              {
                "key" : "a10:10:1",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 1.0
                }
              },
              {
                "key" : "a10:10:2",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 2.0
                }
              },
              {
                "key" : "a10:10:3",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 3.0
                }
              },
              {
                "key" : "a10:10:4",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 4.0
                }
              }
            ]
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100:100:1000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 5.0
                }
              },
              {
                "key" : "a100:100:1001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 6.0
                }
              },
              {
                "key" : "a100:100:1002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 7.0
                }
              },
              {
                "key" : "a100:100:1003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 8.0
                }
              },
              {
                "key" : "a100:100:1004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 9.0
                }
              }
            ]
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a1000:1000:2000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 10.0
                }
              },
              {
                "key" : "a1000:1000:2001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 11.0
                }
              },
              {
                "key" : "a1000:1000:2002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 12.0
                }
              },
              {
                "key" : "a1000:1000:2003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 13.0
                }
              },
              {
                "key" : "a1000:1000:2004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 14.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10000:10000:3000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 15.0
                }
              },
              {
                "key" : "a10000:10000:3001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 16.0
                }
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 17.0
                }
              },
              {
                "key" : "a10000:10000:3003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 18.0
                }
              },
              {
                "key" : "a10000:10000:3004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 19.0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

5. グループ内であるフィールド値が最大の擬似レコードを抽出(件名に対応した例)

GET a_ex/_search?size=0&filter_path=agg*
{
  "aggs": {
    "grp": {
      "terms": {
        "field": "a.keyword"
      },
      "aggs": {
        "c_list": {
          "terms": {
            "field": "compl.keyword"
          },
          "aggs": {
            "dValue": {
              "sum": {
                "field": "d"
              }
            }
          }
        },
        "max_record": {
          "max_bucket": {
            "buckets_path": "c_list>dValue"
          }
        }
      }
    }
  }
}

結果

max_recordという戻り値フィールドに注目!

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 20.0
                }
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 21.0
                }
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 22.0
                }
              },
              {
                "key" : "a100000:100000:4003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 23.0
                }
              },
              {
                "key" : "a100000:100000:4004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              },
              {
                "key" : "a100000:100000:9999",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              }
            ]
          },
          "max_record" : {
            "value" : 24.0,
            "keys" : [
              "a100000:100000:4004",
              "a100000:100000:9999"
            ]
          }
        },
        {
          "key" : "a10",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10:10:0",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 0.0
                }
              },
              {
                "key" : "a10:10:1",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 1.0
                }
              },
              {
                "key" : "a10:10:2",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 2.0
                }
              },
              {
                "key" : "a10:10:3",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 3.0
                }
              },
              {
                "key" : "a10:10:4",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 4.0
                }
              }
            ]
          },
          "max_record" : {
            "value" : 4.0,
            "keys" : [
              "a10:10:4"
            ]
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100:100:1000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 5.0
                }
              },
              {
                "key" : "a100:100:1001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 6.0
                }
              },
              {
                "key" : "a100:100:1002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 7.0
                }
              },
              {
                "key" : "a100:100:1003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 8.0
                }
              },
              {
                "key" : "a100:100:1004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 9.0
                }
              }
            ]
          },
          "max_record" : {
            "value" : 9.0,
            "keys" : [
              "a100:100:1004"
            ]
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a1000:1000:2000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 10.0
                }
              },
              {
                "key" : "a1000:1000:2001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 11.0
                }
              },
              {
                "key" : "a1000:1000:2002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 12.0
                }
              },
              {
                "key" : "a1000:1000:2003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 13.0
                }
              },
              {
                "key" : "a1000:1000:2004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 14.0
                }
              }
            ]
          },
          "max_record" : {
            "value" : 14.0,
            "keys" : [
              "a1000:1000:2004"
            ]
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10000:10000:3000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 15.0
                }
              },
              {
                "key" : "a10000:10000:3001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 16.0
                }
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 17.0
                }
              },
              {
                "key" : "a10000:10000:3003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 18.0
                }
              },
              {
                "key" : "a10000:10000:3004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 19.0
                }
              }
            ]
          },
          "max_record" : {
            "value" : 19.0,
            "keys" : [
              "a10000:10000:3004"
            ]
          }
        }
      ]
    }
  }
}


6. グループごとに配下レコードの特定項目の値の降順に並べて値を取得(前項の「sumは実際は1件だけの合計」方式の応用)

前項はmaxでしたが、こちらは特定のフィールドの値の順序で並べて取得の例です。 (降順にしてあります。ここでは動きを見るために、降順に3件取得にしました。)

GET a_ex/_search?size=0&filter_path=agg*
{
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "c_list": {
                    "terms": {
                        "field": "compl.keyword"
                    },
                    "aggs": {
                        "dValue": {
                            "sum": {
                                "field": "d"
                            }
                        },
                        "orderby": {
                            "bucket_sort": {
                                "sort": [
                                    {
                                        "dValue": {
                                            "order": "desc"
                                        }
                                    }
                                ],
                                    "size": 3
                            }
                        }
                    }
                }
            }
        }
    }
}

結果

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100000:100000:4004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              },
              {
                "key" : "a100000:100000:9999",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              },
              {
                "key" : "a100000:100000:4003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 23.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10:10:4",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 4.0
                }
              },
              {
                "key" : "a10:10:3",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 3.0
                }
              },
              {
                "key" : "a10:10:2",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 2.0
                }
              }
            ]
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100:100:1004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 9.0
                }
              },
              {
                "key" : "a100:100:1003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 8.0
                }
              },
              {
                "key" : "a100:100:1002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 7.0
                }
              }
            ]
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a1000:1000:2004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 14.0
                }
              },
              {
                "key" : "a1000:1000:2003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 13.0
                }
              },
              {
                "key" : "a1000:1000:2002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 12.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10000:10000:3004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 19.0
                }
              },
              {
                "key" : "a10000:10000:3003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 18.0
                }
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 17.0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

7. レコードの特定項目の値が特定の値以上のものを取得(グループごとに分類あり)

GET a_ex/_search?size=0&filter_path=agg*
{
            "aggs": {
                "grp": {
                    "terms": {
                        "field": "a.keyword"
                    },
                    "aggs": {
                        "c_list": {
                            "terms": {
                                "field": "compl.keyword"
                            },
                            "aggs": {
                                "dValue": {
                                    "sum": {
                                        "field": "d"
                                    }
                                },
                                "myfilter": {
                                    "bucket_selector": {
                                        "buckets_path": {
                                            "d": "dValue"
                                        },
                                        "script": "params.d >= 11"
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }

結果

  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100000",
          "doc_count" : 6,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a100000:100000:4000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 20.0
                }
              },
              {
                "key" : "a100000:100000:4001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 21.0
                }
              },
              {
                "key" : "a100000:100000:4002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 22.0
                }
              },
              {
                "key" : "a100000:100000:4003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 23.0
                }
              },
              {
                "key" : "a100000:100000:4004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              },
              {
                "key" : "a100000:100000:9999",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 24.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [ ]
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [ ]
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a1000:1000:2001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 11.0
                }
              },
              {
                "key" : "a1000:1000:2002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 12.0
                }
              },
              {
                "key" : "a1000:1000:2003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 13.0
                }
              },
              {
                "key" : "a1000:1000:2004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 14.0
                }
              }
            ]
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "c_list" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "a10000:10000:3000",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 15.0
                }
              },
              {
                "key" : "a10000:10000:3001",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 16.0
                }
              },
              {
                "key" : "a10000:10000:3002",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 17.0
                }
              },
              {
                "key" : "a10000:10000:3003",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 18.0
                }
              },
              {
                "key" : "a10000:10000:3004",
                "doc_count" : 1,
                "dValue" : {
                  "value" : 19.0
                }
              }
            ]
          }
        }
      ]
    }
  }
}

8. 複合クエリも可能

GET a_ex/_search?size=0&filter_path=agg*
{
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "c_list": {
                    "terms": {
                        "field": "compl.keyword"
                    },
                    "aggs": {
                        "dValue": {
                            "sum": {
                                "field": "d"
                            }
                        },
                        "f": {
                            "bucket_sort": {
                                "sort": [
                                    { "dValue": { "order": "desc" } }
                                ],
                                    "size": 3
                            }
                        }
                    }
                },
                "count": {
                    "value_count": {
                        "field": "b"
                    }
                },
                "myfilter": {
                    "bucket_selector": {
                        "buckets_path": {
                            "c": "count"
                        },
                        "script": "params.c > 5"
                    }
                }


            }
        }
    }
}

Elasticsearch のPipeline aggregationsのさわり

ElasticsearchのPipeline aggregationsは、ElasticsearchでSQLのHavingっぽいことが可能になるしかけです*1

www.elastic.co

これまた品揃えが豊富で、今確認したら、20種類近くあるようですが、次のBucket aggregationsや Metrics aggregationsの記事と同じ論法(シンタックスが似ているAggregationは、似た挙動となるのでまとめて覚えると一度に覚える負担が減る論法!)でPipelineについてもおなじように本記事でまとめてみました。

itdepends.hateblo.jp

itdepends.hateblo.jp

※この記事を書くにあたり、Elasticsearchのバージョンは6.8で確認しました。

事前準備:

この類の話はサンプルデータがあると理解が進みます。

次の過去記事の最初のセクション記載の手順でa_exインデックスを作成ください。

itdepends.hateblo.jp

1.各バケットでの集計値を見るAggs

Pipleline aggsのうち、入力に数値を取り扱い、必須プロパティがbuckets_pathでかつ大外のaggsにぶら下げるタイプのもの一覧です。

他に紛れているとわかりづらいですが、こうして抜き出してみると、名前だけで何をしてくれるかなんとなく分かりますね(?)。

このシリーズの例によって(?)、シンタックスのエッセンスをあぶり出す意図で、JSONを扱いやすいJavaScriptの簡易コードを通して、シンタックスを説明します。

a_exインデックスに対して、上記を全部盛りしたクエリを標準出力に出力する、JavaScriptの例は次のとおりです。

// Pipeline aggregationsは前段階の別のAggregationsにのっかることになりますが、その土台のクエリです。
const bucp = 'grp>the_sum';
const base_query = {
    "size": 0,
    "aggs": {
        "grp": {
            "terms": {
                "field": "a.keyword"
            },
            "aggs": {
                "the_sum": {
                    "sum": {
                        "field": "b"
                    }
                }
            }
        }
    }
};

// Pipleline aggsのうち、入力に数値を取り扱い、必須プロパティがbuckets_pathでかつ大外のaggsにぶら下げるタイプのもの一覧
const plagg_names = [
    "max_bucket",
    "min_bucket",
    "sum_bucket",
    "stats_bucket",
    "extended_stats_bucket",
];

const bp1 = (plagg_name, buckets_path) => { // buckets_pathは複数階層の場合、「aaa > bbb」のようなパンくず風に指定する。
    return {
        [plagg_name]: {
            buckets_path
        }
    }
};

// (もちろん1つずつ使えますが)比較のため全てのaggsを一度に実行するクエリを生成します。
plagg_names.forEach(pln => {
    base_query.aggs[`my_${pln}`] = bp1(pln, bucp);
});

console.log(JSON.stringify(base_query));

上記を実行して得られるElasticsearchの生クエリは次のものです。

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "grp": {
      "terms": {
        "field": "a.keyword"
      },
      "aggs": {
        "the_sum": {
          "sum": {
            "field": "b"
          }
        }
      }
    },
    "my_max_bucket": {
      "max_bucket": {
        "buckets_path": "grp>the_sum"
      }
    },
    "my_min_bucket": {
      "min_bucket": {
        "buckets_path": "grp>the_sum"
      }
    },
    "my_sum_bucket": {
      "sum_bucket": {
        "buckets_path": "grp>the_sum"
      }
    },
    "my_stats_bucket": {
      "stats_bucket": {
        "buckets_path": "grp>the_sum"
      }
    },
    "my_extended_stats_bucket": {
      "extended_stats_bucket": {
        "buckets_path": "grp>the_sum"
      }
    }
  }
}

これは、先のa_exに対して、フィールドaの登録値で、Bucket Agg(値でグループ化)して、グループ内のbフィールド値の合計をMetrics Agg(のsum)で計算したバケットが得られているところに対し、「max_bucket」でグループごとの合計が最も多いグループを抜き出す、最も少ない(min_bucket)グループを抜き出す、... というクエリ例になっています。

なお、buckets_pathに、grp>the_sumと目印が指定されていますが、これはクエリの上の方の、grpとその配下のthe_sumに至るパスを示すことで、Aggregation結果を参考にmax_bucket等を行いなさいという命令になっているととらえて良いでしょう。

ということでこれの実行結果です。↓

{
  "aggregations" : {
    "grp" : {
      "buckets" : [
        {
          "key" : "a10",
          "doc_count" : 5,
          "the_sum" : {
            "value" : 50.0
          }
        },
        {
          "key" : "a100",
          "doc_count" : 5,
          "the_sum" : {
            "value" : 500.0
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "the_sum" : {
            "value" : 5000.0
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "the_sum" : {
            "value" : 50000.0
          }
        },
        {
          "key" : "a100000",
          "doc_count" : 5,
          "the_sum" : {
            "value" : 500000.0
          }
        }
      ]
    },
    "my_max_bucket" : {
      "value" : 500000.0,
      "keys" : [
        "a100000"
      ]
    },
    "my_min_bucket" : {
      "value" : 50.0,
      "keys" : [
        "a10"
      ]
    },
    "my_sum_bucket" : {
      "value" : 555550.0
    },
    "my_stats_bucket" : {
      "count" : 5,
      "min" : 50.0,
      "max" : 500000.0,
      "avg" : 111110.0,
      "sum" : 555550.0
    },
    "my_extended_stats_bucket" : {
      "count" : 5,
      "min" : 50.0,
      "max" : 500000.0,
      "avg" : 111110.0,
      "sum" : 555550.0,
      "sum_of_squares" : 2.525252525E11,
      "variance" : 3.81596184E10,
      "std_deviation" : 195344.87042151886,
      "std_deviation_bounds" : {
        "upper" : 501799.7408430377,
        "lower" : -279579.7408430377
      }
    }
  }
}

2. max_bucketなどと同様にbuckets_pathを指定するが累積型の挙動なので親バケットに条件ありAggs

以下のとおり、前項のmax_bucketと単品のクエリシンタックスは似ていますが、cumulattiveとかderivativeという名のとおり、親バケット(上位のグループ化)が産まれながらに順序性を持つことになるhistogram系Aggバケットが前提になっており、言い換えると親バケットにぶら下げる形でクエリを作るという点でも前項とやや異なります。

const bp2 = {
    "cumulative_sum": {
        "buckets_path": "aggname"
    }
}

const bp3 = {
    "derivative": {
        "buckets_path": "aggname"
    }
}

// X-Pack
const bp4 = {
    "cumulative_cardinality": {
        "buckets_path": "aggname"
    }
}

実際のクエリ例

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "adh": {
      "date_histogram": {
        "field": "date",
        "interval": "1D"
      },
      "aggs": {
        "the_sum": {
          "sum": {
            "field": "b"
          }
        },
        "cumsum": {
          "cumulative_sum": {
            "buckets_path": "the_sum"
          }
        },
        "derv": {
          "derivative": {
            "buckets_path": "the_sum"
          }
        }
      }
    }
  }
}

derivativeの例はエラーにはならなかったというレベルの例になっていますが、cumsumは累積和になっていることがよくわかる応答が戻ってきます。

3. ソートする(sort)

集計というよりは、バケット一覧をソートします。

ぶら下げたAggのバケット一覧を特定の条件で並び替えます。

シンタックス例(の擬似表現)

const sort = {
    "bucket_sort": {
        "sort": [
            { "aggname1": { "order": "asc" } },
            { "aggname2": { "order": "desc" } },
        ],
        "from": 1,
        "size": 3
    }
}

* 実際のクエリ例

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "grp": {
      "terms": {
        "field": "a.keyword"
      },
      "aggs": {
        "the_sum": {
          "sum": {
            "field": "b"
          }
        },
        "the_avg": {
          "avg": {
            "field": "b"
          }
        },
        "my_max_bucket": {
          "bucket_sort": {
            "sort": [
              {
                "the_avg": {
                  "order": "desc"
                }
              },
              {
                "the_sum": {
                  "order": "desc"
                }
              }
            ],
            "from": 1,
            "size": 3
          }
        }
      }
    }
  }
}

この例だと旨味を感じにくいですが、フィールドaの値でグループ分けし、バケットのbフィールドのグループ内の合計の降順、バケットのbフィールドのグループ平均の降順の優先度で得られたMetrix Aggregationバケットの一覧をソートしています。

4. bucket_scriptとbucket_selector

Painless scriptで同じ階層のAggregationで得られた値を変数に見立てて、新たな演算を行ったり(bucket_script)、条件にマッチするもののみフィルター(bucket_selector)します。

ビルトインのままでは難しいものはこちらで頑張るという選択肢を広げてくれますね。

擬似シンタックス表現はこちら↓。

// シンタックスはよく似ています。

//  同じ並びのaggsの値を使って、さらに別の計算値を取得します。script部分で計算式を指定します。
//  ここでは、バケットごとのあるフィールドの合計値をバケット内の要素数で割って、平均値を取得する例です。
//   (この例であれば、わざわざPipeline aggsを使わなくとも、Metrics aggsのavgで十分ですが、あえてそちらと同じ結果をPipeline aggsで得るという例としました)

const script = {
    "bucket_script": {
        "buckets_path": {
            "v1": "the_sum",
            "v2": "the_count"
        },
        "script": "params.v1 / params.v2"
    }
}

// 同じ並びのaggsの値を使って、条件に合致したもののみを取得します。script部分で条件判定の式を指定します。
const select = {
    "bucket_selector": {
        "buckets_path": {
            "v1": "the_max",
            "v2": "the_min"
        },
        "script": "params.v1 > params.v2 * 2"
    }
}

*クエリ例

実際のクエリ例です。script(自前で平均(avg)を計算)とselector(グループ内の合計が件数の11倍より多いもののみ残す(=このデータ例だとフィールドaが「a10」のデータが脱落)を両方実施しています。

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "grp": {
      "terms": {
        "field": "a.keyword"
      },
      "aggs": {
        "the_sum": {
          "sum": {
            "field": "b"
          }
        },
        "the_count": {
          "value_count": {
            "field": "b"
          }
        },
        "custom_avg": {
          "bucket_script": {
            "buckets_path": {
              "var1": "the_sum",
              "var2": "the_count"
            },
            "script": "params.var1 / params.var2"
          }
        },
        "custom_selection":{
            "bucket_selector": {
            "buckets_path": {
              "var1": "the_sum",
              "var2": "the_count"
            },
            "script": "params.var1 >  params.var2 * 11"
          }
          
        }
      }
    }
  }
}

結果イメージ

{
  "aggregations" : {
    "grp" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "a100",
          "doc_count" : 5,
          "the_count" : {
            "value" : 5
          },
          "the_sum" : {
            "value" : 500.0
          },
          "custom_avg" : {
            "value" : 100.0
          }
        },
        {
          "key" : "a1000",
          "doc_count" : 5,
          "the_count" : {
            "value" : 5
          },
          "the_sum" : {
            "value" : 5000.0
          },
          "custom_avg" : {
            "value" : 1000.0
          }
        },
        {
          "key" : "a10000",
          "doc_count" : 5,
          "the_count" : {
            "value" : 5
          },
          "the_sum" : {
            "value" : 50000.0
          },
          "custom_avg" : {
            "value" : 10000.0
          }
        },
        {
          "key" : "a100000",
          "doc_count" : 5,
          "the_count" : {
            "value" : 5
          },
          "the_sum" : {
            "value" : 500000.0
          },
          "custom_avg" : {
            "value" : 100000.0
          }
        }
      ]
    }
  }
}

その他のPipeline aggregations

だいぶ俯瞰できた気でいましたが、他にもまだまだありますが、(心の声)解説がむずかしそうなので、別の機会に。 (movingとあるので、移動平均とかこの類の要件の次のレベルのものたちだと思います。そこをとっかかりに理解を深めると良いのではと思います。> 筆者自分自身向け)

  • avg_bucket
  • serial_diff
  • moving_avg
  • moving_fn
  • moving_percentiles
  • inference

自分メモ:それぞれの擬似シンタックス俯瞰表現↓

const avgb = {
    // tag::avg-bucket-agg-syntax[]               
    "avg_bucket": {
        "buckets_path": "sales_per_month>sales",
        "gap_policy": "skip",
        "format": "#,##0.00;(#,##0.00)"
    }
    // end::avg-bucket-agg-syntax[]               
}

const sd = {
    "serial_diff": {
        "buckets_path": "the_sum",
        "lag": 7
    }
}

const mva = the_sum => ({
    "moving_avg": {
        "buckets_path": the_sum,
        "model": "holt",
        "window": 5,
        "gap_policy": "insert_zeros",
        "settings": {
            "alpha": 0.8
        }
    }
})

const mvf = the_sum => ({
    "moving_fn": {
        "buckets_path": the_sum,
        "window": 10,
        "script": "MovingFunctions.min(values)"
    }
})

const mvp = the_percentile => ({
    "moving_percentiles": {
        "buckets_path": "the_percentile",
        "window": 10
    }
})

const inference = {
    "inference": {
        "model_id": "a_model_for_inference",
        "inference_config": {
            "regression_config": {
                "num_top_feature_importance_values": 2
            }
        },
        "buckets_path": {
            "avg_cost": "avg_agg",
            "max_cost": "max_agg"
        }
    }
}

*1:ただし、あくまで親や同列のAggs結果に作用するものです

ElasticsearchのBucket aggregationsのさわり

ElasticsearchのAggregationsは種類が豊富ゆえに、嬉しい悲鳴なのですが、私のようなメモリが小さい人間はどれがどれというところの理解が大変です。

実際は、似た演算は、クエリの形とパラメータ、得られるバケット(演算結果)の形式が似ているので、同じような用途の内容違いのものを形から入って理解しましょうということで、記事をまとめてみました。

今回は、Bucket aggregatios、Metrics ...、Pipeline ...、でいうところのBucket aggregationsの俯瞰照会です。

www.elastic.co

事前準備:サンプルデータのインポート

クエリの説明用に、a_ex というインデックスにデータをインポートします。 他の方法でもかまいませんが、ここではkibanaにペタペタ貼り付け想定で示しています。

mapping設定

PUT a_ex/
{
  "mappings": {
    "mapping": {
      "properties": {
        "date": {
          "type": "date"
        },
        "loc": {
          "type": "geo_point"
        }
      }
    }
  }
}

データ(25件)のPOST

POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}, "date": "2021-07-01"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a100", "b": 100, "c": 200, "weight": 2, "loc": {"lat": 35.5, "lon": 145.2}, "date": "2021-07-02"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a1000", "b": 1000, "c": 2000, "weight": 3, "loc": {"lat": 35.5, "lon": 145.3}, "date": "2021-07-03"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a10000", "b": 10000, "c": 20000, "weight": 4, "loc": {"lat": 35.5, "lon": 145.4}, "date": "2021-07-04"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}
POST a_ex/_doc/
{"a": "a100000", "b": 100000, "c": 200000, "weight": 5, "loc": {"lat": 35.5, "lon": 145.5}, "date": "2021-07-05"}

1.時系列バケット(date系)

  • auto_date_histogram
  • date_histogram
  • date_range

まずは、時系列バケットキラーコンテンツならぬキラークエリですね。

Date系タイプのフィールドを指定して、それをグループにしたバケット分類します。

そのグループや刻み方のオプションによって何種類かあります。

並べてみると相対化されてわかりやすくなる(と思う)のですが、

というものになっているようです。

同列に語れるものは3種類あり、これを仕様を見比べしやすいように、JavaScriptのアロー関数で擬似的にシンタックスの要点を示したものが次のものです。 (似た形のものをまとめて、かつ対比することで、具体的な説明を見なくとも、名前から何ができるかなんとなくわかりません? 今回は対比することで察しやすくなるよね、という考えで、具体的な説明は極力省かせてもらっています。)

const date = field => ({
    "aggs": {
        "my_num": {
            "auto_date_histogram": {
                field,
                "buckets": 10
                //, "format": "yyyy-MM-dd"
            }
        },
        "my_interval": {
            "date_histogram": {
                field,
                "calendar_interval": "2d"
            }
        },
        "my_range": {
            "date_range": {
                field,
                "format": "MM-yyyy",
                "ranges": [
                    { "from": "01-2015", "to": "03-2015", "key": "quarter_01" },
                    { "from": "03-2015", "to": "06-2015", "key": "quarter_02" }
                ],
                "keyed": true
            }
        }
    }
})

実際に、上記の一つを試してみます。

注:私の手元のElasticsearch 6.8では、7系から対応のcalender_intervalパラメータには対応しておらず、deprecatedなintervalパラメータで代用しています。7系でcalender_interval対応後のバージョンをご利用の方は下記例についてご注意ください。

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "my_interval": {
      "date_histogram": {
        "field": "date",
        "interval": "1d"
      }
    }
  }
}

結果

{
  "aggregations" : {
    "my_interval" : {
      "buckets" : [
        {
          "key_as_string" : "2021-07-01T00:00:00.000Z",
          "doc_count" : 5
        },
        {
          "key_as_string" : "2021-07-02T00:00:00.000Z",
          "doc_count" : 5
        },
        {
          "key_as_string" : "2021-07-03T00:00:00.000Z",
          "doc_count" : 5
        },
        {
          "key_as_string" : "2021-07-04T00:00:00.000Z",
          "doc_count" : 5
        },
        {
          "key_as_string" : "2021-07-05T00:00:00.000Z",
          "doc_count" : 5
        }
      ]
    }
  }}

2.数値範囲(ヒストグラム的)バケット

  • variable_width_histogram
  • histogram
  • range

日付を巡る要件と数値(お金など)の階級化・グループ化は似たものが多いですね。 ということで、数値の値によるバケットのグループ化に対応するのが、rangeやhistogramアグリゲーションです。 こころなしか、時系列系と品揃えが似ていますね。

以下、JavaScriptのアロー関数で擬似的にシンタックスの要点です。

const hist = field => ({
    "aggs": {
        // variable_width_histogramが使えるのは7.9あたりから
        /* 
        "my_num": {
            "variable_width_histogram": {
                field,
                "buckets": 2
            }
        },
        */
        "my_interval": {
            "histogram": {
                field,
                "interval": 5
            }
        },
        "my_range": {
            "range": {
                field,
                "ranges": [
                    { "to": 100.0 },
                    { "from": 100.0, "to": 200.0 },
                    { "from": 200.0 }
                ]
            }
        }
    }
})

実際のクエリイメージ(histogram)

GET a_ex/_search
{
  "size": 0,
  "aggs": {
    "my_interval": {
      "histogram": {
        "field": "b",
        "interval": "1000"
      }
    }
  }
}

3. geo系バケット

  • geohash_grid
  • geotile_grid
  • geo_distance

時系列と数値の間ほどではありませんが、 座標(GEO)系にも似た要件が発生することが多いような気がしますが、それらにも対応しているようです。

geohashとグループ化の精細度のようなもの、geotileとグループ化の精細度のようなもの および geo_distacneとrangesの3種類ですね。

以下、JavaScriptのアロー関数で擬似的にシンタックスの要点です。

なお、クエリイメージと結果は割愛します。実際に試す場合は、最初に登録したデータのlocフィールドを使ってください。

const geo = field => ({
    "aggs": {
        "my_geohashGrid": {
            "geohash_grid": {
                field,
                "precision": 3
            }
        },
        "my_geotileGrid": {
            "geotile_grid": {
                field,
                "precision": 8
            }
        },
        "my_geoDistance": {
            "geo_distance": {
                field,
                "origin": "52.3760, 4.894",
                "ranges": [
                    { "to": 100000 },
                    { "from": 100000, "to": 300000 },
                    { "from": 300000 }
                ]
            }
        }
    }
})

4. terms(特定フィールドの値で分類)系バケット

  • terms
  • rare_terms

これはシンプルな例ですね。 特定のフィールドの値に応じて分類。 いわゆるカテゴリデータ的なものでのグループ分類。

説明順が真ん中あたりになりましたが、私見では、Bucket Aggsで一番最初にお世話になるのは、termsアグリゲーションではないでしょうか。

以下、JSアロー関数での擬似説明。

const aggByFieldVal = field => ({
    "aggs": {
        "vals": {
            "terms": { field }
        },
        /* ver 7系から対応(ver 6系では未対応) 
        "rareVals": {
            "rare_terms": { field, max_doc_count:1 }
        }
        */

    }
})

5. filters

バケットの分類条件を検索クエリで指定しようというのがfilters。

他のBucket Aggregations でもそのようなものがないわけではないのですが、あるドキュメントが、複数のバケット両方でカウントされるということも可能です。

const filters = {
    "size": 0,
    "aggs": {
        "messages": {
            "filters": {
                "filters": {
                    "overRank1": { "prefix": { "a.keyword": "a10" } },
                    "onlyOverRank2": { "prefix": { "a.keyword": "a1000" } }
                }
            }
        }
    }
}

6. adjacency_matrix

あらかじめ定義したカギとなる分類条件(検索クエリ風の記法・条件で指定)のうち、同時に当てはまったものの組み合わせ自体をバケット分類基準とするのがadjacency_matrix。 ただし、マトリックスという名のとおり、どれか一つに当てはまるもの、同時に2つの条件に当てはまるものに分類されるので、3つの条件を設定すると、最大で3 + (3 * 2 )/2 = 6バケットに分類されます。

前項のfiltersと似ていますね。

filtersだと無意味に難しくなるような例に対してもっと宣言的にバケット分類できると言えるような気がするが、そこそこリアルでかつメリットを示しやすい良い例が思い当たらないところが悩ましい。

注:以下の例は、最初にインポートした例とは噛み合っていません。(公式Rの例が一番わかりやすいと思います。)


// 全体クエリで示しています。
const adj = {
    "size": 0,
    "aggs": {
        "interactions": {
            "adjacency_matrix": {
                "filters": {
                    "grpA": { "terms": { "accounts": ["hillary", "sidney"] } },
                    "grpB": { "terms": { "accounts": ["donald", "mitt"] } },
                    "grpC": { "terms": { "accounts": ["vladimir", "nigel"] } }
                }
            }
        }
    }
}

7. filter

filtersではなくて、filterです。

クエリで絞り込まなくても、絞り込みしたバケットを形成できる。 下記のようにアパレルの売り上げ平均とTシャツのみの売り上げ平均を比べてみるといった例に便利そうですし、 aggsを組み合わせなくとも、単純にこの分類のみのバケットをみてみたい...という使い方もそれなりに使えそうですね。

形から入る本記事ではこの場所になりましたが、実際は、termsと同じぐらいよく使われるAggsで、ゆえに理解は難しくないように思います。

// 全体クエリで示しています。

const filter = field => ({
    "size":0,
    "aggs": {
        "avg_price": { "avg": { field } },
        "t_shirts": {
            "filter": { "term": { "type": "t-shirt" } },
            "aggs": {
                "avg_price": { "avg": { field } }
            }
        }
    }
})

8. sampler

samplerは、shard数を指定して(つまりある程度shardを絞って)、バケット分類のある種の精度を落としつつその分、レスポンス確保するためのヒント的なaggsです。

分類というよりは、比較的ヘビーな処理であるAggregationsを近似的に行うための命令と思って良いでしょう。

const sampler = field => ({
    "aggs": {
        "sample": {
            "sampler": {
                "shard_size": 10
            },
            "aggs": {
                // value_countはちょっと変な組み合わせだが、やってることが分かる。
                "vc": {
                    "value_count": {
                        field
                    }
                }
            }
        }
    }
})

9. significant_terms(とsignificant_text)

このブログでは何度かでてます、significant_terms(とsignificant_text)。

const sig = (filterField, field) => ({
    "aggs": {
        "siggrp": {
            "terms": { "field": filterField },
            "aggs": {
                "sig": {
                    "significant_terms": { field }
                }
            }
        }
    }
})

itdepends.hateblo.jp

10. 機会があれば(残りのもの一覧)

ver 7.13のX-packを除いたBucket Aggregationsとしては他に次のようなものがあります。 これらはまた別途。 (ここまでご紹介したものと、形はだいぶ異なる...ということだけお伝えしておきます。)

  • global
  • nested
  • reverse_nested

ElasticsearchのMetrics aggregationsのさわり

ElasticsearchのMetrics aggregationsは、その名の通り?統計的なAggregationsです。

www.elastic.co

機能充実はありたがたいもののその分だけ数も多いですね。

それぞれの名称、SQLや他の言語などでの関数名と類似性から、得られる値や使い方は同じような用法だろうなーと推測はされるものの、実際必要になるまでは試す気にもならずということで私自身も食わず嫌いではあるのですが、見た目から入って入門するというのが良いのではと思い、ちょいと変則的な切り口でまとめてみました... という記事です。

Metrics aggregationsのよくある「型」

さっそくですが、Metrics aggregationsらは、つまるところ集計関数です。

QueryDSLで得られた検索結果ドキュメント一覧に対して、なんらかの集計などを行います。

集計を行うからには、当然対象のフィールドをどれか指定することになり、おそらく数値型のフィールドを指定することになるでしょう。

実際、集計クエリの形としては、(全部ではありませんが)次のようなものになるものが大半です。

{ 
        aggs: {
            [agg_label]: {
                [AGGNAME]: {
                    field: fieldname,
                }
            }
        }
}

クエリの種類数は多いですが、上記の見た目をとるものについては、fieldnameで指定されるフィールドに対し、AGGNAMEで示す統計的演算を施す...と見れば一網打尽ではないでしょうか。

現に、X-Packが必要ないもののうちで、AGGNAMEに指定できるものは次のようなものとなっています。

value_count,avg,max,min,sum,stats,extended_stats,cardinality,percentiles,median_absolute_deviation

名前だけで分からないものもありますが、agv、max,sum ...などという顔ぶれを見ればなんとなくわかったような気がしてきます。

では、次に上記にいろいろ当てはめて、試してみましょう。

試してみる

試してみましょうと言いましたが、実際のところ、上記のヒトたちは、名前と形から予想される動作となります。

よって、ひとつずつ試してみるというよりは、同じ形になるというところを示唆することも兼ねて、kibanaにコピペしやすいクエリ一覧をアドホックに出力するスニペットのご紹介で代用することにします。

データ登録用のポストデータ出力

import json

ii = [10, 100, 1000, 10000,100000]

a = []

num = 5

for i, v in enumerate(ii):
    idx = i + 1
    x = [{'a':'a'+str(v),'b':v, 'c': v * 2, 'weight':idx,'loc':{'lat':35.5,'lon':float('145.'+str(idx))}} for _ in range(num) ]
    a.extend(x)

for i in a:
    print('POST a_ex/_doc/')
    print(json.dumps(i, ensure_ascii=False))
    

python hoge.py

などとすると下記が出力されます。

POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}}
POST a_ex/_doc/
{"a": "a10", "b": 10, "c": 20, "weight": 1, "loc": {"lat": 35.5, "lon": 145.1}}
POST a_ex/_doc/
 ...

a_exが今回お試し用のインデックスです。

あとで平均などの集計を行う際に、得られる値が予測しやすいようにラフな規則の値をPOSTすることをイメージした出力にしてあります。

逆にいうと、ここで登録するデータはなんらかのドメインとは全く関係ありませんので、数値傾向自体は何も意味をなさないことに注意ください。

なお今回は、locフィールドは使っていません。主に、bフィールドを練習に使います。

上記の出力をkibanaにコピペすると、データ登録されます。今回は明示的なmapping設定は行いません(ひとまず不要です)。

検索(aggsクエリ発行)

前項で登録したデータ(インデックス)をターゲットに、特にbフィールドを意識した、同じ形のクエリ一覧を生成します。 (例によって、直接クエリを発行するのではなく、kibanaに貼り付け用の例を出力する方式です。)


const h = _ => console.log('GET a_ex/_search?filter_path=agg*');

const aggs1 = (AGGNAME, fieldname) => {
    const agg_label = `my_${AGGNAME}`;
    return {
        aggs: {
            [agg_label]: {
                [AGGNAME]: {
                    field: fieldname,
                }
            }
        }
    };
};


AGGNAMES1 = 'value_count,avg,max,min,sum,stats,extended_stats,cardinality,percentiles,median_absolute_deviation'.split(',');

AGGNAMES1.forEach(a => {
    const f = 'b';
    //console.log('GET a_ex/_search?filter_path=agg*');
    h();
    console.log(JSON.stringify(aggs1(a, f)));
});


matstats = fields => {
    return {
        size: 0,
        aggs: {
            "mtrx_stats": {
                matrix_stats: {
                    fields
                }
            }
        }
    }
};

h();
console.log(JSON.stringify(matstats(['b', 'c'])));

const pr = (field, values) => ({
    size: 0,
    aggs: {
        "my_percentile_ranks": {
            percentile_ranks: {
                field,
                values,
            }
        }
    }
});

h();
console.log(JSON.stringify(pr('b', [10, 1000])));

const wg = (f1, f2) => ({
    // Σ (value * weight)/Σ(weight) 
    size: 0,
    aggs: {
        "my_weighted_avg": {
            weighted_avg: {
                value: {
                    field: f1
                },
                weight: {
                    field: f2
                }
            }
        }
    }
});

h();
console.log(JSON.stringify(wg('b', 'idx')));

上記はJavaScriptのプログラムですが、例えば下記のように実行してください。

node fuga.js

あとは、kibanaでポチポチ実際に実行してみれば確かにそうだね...という感じの結果が得られます。

これを、先ほどのインデックスデータを登録した環境のkibanaでポチポチ実行してみてください。

先の話のとおり、この類の分野に慣れている方なら、ああ確かにこうなのねという結果が得られるのえですが、自分メモとして、上記の中では少しだけクセがある演算について以下のとおり、ひとこと補足しておきます。

  • stats: avgやmaxなどの主要な基本統計量を一括で取得
  • extended_stats: statsのさらに拡張
  • median_absolute_deviation: いわゆるMADが取得できる(とのこと)

また、次は、複数パラメータを取る分、少しだけaggsクエリの形が違うのでやや別枠としましたが、本質的には、似た種類に属するので合わせてご紹介してあります。

  • matrix_stats: 複数フィールドを指定すると、フィールド間の共分散等が取得できる。それ以外にももともと各フィールドのstatsおよび歪度と尖度が得られるので、指定フィールドを1つだけにしてこの数値を取得する命令と考えても良いかもシレナイ。
  • percentile_ranks: 指定した数値が累積パーセンタイルのどこに属するかを表してくれる。
  • weighted_avg: 各レコードの集計フィールドに対して、指定の別フィールドの値を重みとみなした平均

その他

Metrics aggregationsのうち、X-Pack以外のもので、残りは次のものです。 こちらは時間があればまた。

  • top_hits
  • geo_bounds
  • geo_centroid

www.elastic.co

www.elastic.co

自作の照合型ソートのスニペット例(JavaScriptでもmapやreduce、filter(手習いメモ) その4)

JavaScriptのmapやreduceは実用言語っぽい挙動で自分のようなぬる者にはありがたいよね〜のシリーズの第4弾です。

といいつつ、ある素材について、いざやってみるとfilterやreduceはおろか、メインロジック部分あたりではmapさえも使わなかったので、実際は、filterやreduceでおしゃれにコーディングできそうな雰囲気があるテーマについて、筆者の棋力ではそうはならなかったけど、そこそこスニペットとして面白かったので、公開してみました...という読み替えでお願いします。

とりあつかっているもの

  1. 漢字表記とカナ読みの固有名詞的なワードの組み合わせがあり、カナでない部分に読みを当てたトークンを生成
  2. 自作の照合型ソートの例

1がこりゃ面白いかもと思って始めたものの力技(というかナイーブな例)になってしまったので、記事にするには不足かなと思って、2も対応してみましたが、手グセで、2の方もナイーブな例となりました。 (ですが、書捨てるには惜しい気がしたので自分メモとして残しています。)

1. 漢字表記とカナ読みの固有名詞的なワードの組み合わせがあり、カナでない部分に読みを当てたトークンを生成

コード例

'use strict';

const a = 'ブラックJARKSニ世露死苦メカドッグ'.split('');
const bStr = 'ブラックジャックスニヨロシクメカドッグ';
const k = 0x30A1;
const kana = [...Array(92).keys()].map(i => String.fromCodePoint(k + i));
//const hiragana = [...Array(86).keys()].map(i => String.fromCodePoint(0x3041 + i));
console.log(kana);
const isKana = c => kana.includes(c);

const tokenize = a => {
    let c = a.shift();
    let p = c;
    const s = [p];
    while (a.length > 0) {
        c = a.shift();
        s.push(
            (isKana(c) && !isKana(p))
                || (!isKana(c) && isKana(p))
                ? ',' + c
                : c
        );
        p = c;
    }
    return s.join('').split(',');
};

const tokens = tokenize(a);

const getReadingForm = (tokens, bStr) => {
    const k2k = {};
    let str = bStr;
    for (let i = 0; i < tokens.length; i++) {
        const t = tokens[i];
        const kanaTknStsPos = str.indexOf(t);
        if (kanaTknStsPos < 0) {
            continue;
        }
        if (kanaTknStsPos === 0) {
            str = str.slice(t.length);
            continue;
        }
        const kanjiYomi = str.slice(0, kanaTknStsPos);
        k2k[tokens[i - 1]] = kanjiYomi;
        str = str.slice(kanaTknStsPos + t.length);
    }
    return k2k;
}

console.log(getReadingForm(tokens, bStr));


実行結果

{ JACKS: 'ジャックス', '世露死苦': 'ヨロシク' }

漢字と読み(例では変数 aとbStr)を前の方から比較して、同じカナが現れるまでは漢字(やアルファベットなど)と読みのペアとみなして、走査するイメージです。

ある前提のもと、diffっぽいことをナイーブなやり方で実施するイメージでしょうか。

2. 自作の照合型ソートの例

実際は難しいことはしておらず、Array.sort関数に、照合表で勝ち負けを参照しながら、並びを判定する関数を引き渡しして実現します。

'use strict';

const collationfunc = (a, b) => {
    const co = [...'abcdefghijklmnopqrstuvwxy'].reverse();  //照合用の配列。zはあえて無し。
    console.log(co);
    const ia = co.findIndex(e => e === a);
    const ib = co.findIndex(e => e === b);
    //どちらも存在しない場合は昇順
    if (ia === -1 && ib === -1) return a > b ? 1 : -1;
    //一方が存在しなければ、もう一方の存在する方の勝ち
    if (ia === -1) return 1;
    if (ib === -1) return -1;
    //照合の優先度が高い方が勝ち
    if (ia > ib) return 1;
    if (ia < ib) return -1;
};

const sorted = ['a', 'b', 'g', 'd', 'z', 'zzzz', 'f'].sort(collationfunc);

console.log(sorted);

/*

↓ 期待値イメージ

zをのぞく1文字アルファベットは降順。それ以外(zとzzzz)は最後尾となりこの2つの間はアルファベットの昇順。
[
 'g','f','d','b','a','z','zzzz'
]
*/

Elasticsearchアナライズ時に派生型のプラグインを使う場合の雑図解(関連:edge_ngramやmultiplexer)

はじめに

私なぞは、検索時とインデックス時のアナライザーは同じものにしとく(つまりデフォルト)方が検索エンジンが賢いのでよしなにやってくれる派(という名のモグリ)なのですが、 edge_ngramやmultiplexerのような「トークン複数派生」的なアナライザーのプラグインを使う場合に、それを使いこなす上で、トークンに対して暗黙のORマッチング?的なところの当たり前といえば当たり前な挙動を雑にでも書き出しておきたいと考えてここにチラ裏記事を投稿します。

注意事項:

  • 検索エンジンを自作するような人には今更何をという内容です。
  • ※ Elasticsearchのanalyzerと各プラグインの設定を、処理フローというよりは、宣言的に解釈している方は実はそれで十分だと思います。そのような方は良い意味でこの記事はかえって紛らわしいことを言っているように聞こえると思いますので、用法にはご注意ください。
  • 題名で図解といいましたが、図解というほど図にしてません。

アナライザーのプラグインは変換型と派生型がある

私の他記事でもそうですが検索とインデックス時のアナライザーは同じで良い、少なくとも検討の最初はそれで良いと我思うというところの背景は次の図に考え方によります。

f:id:azotar:20210627225701p:plain

アナライザーの目的の大きなところは表記揺れ等を吸収して、同義と見なす語でマッチングさせるというものと言って良いと思われますが、その手法の根幹の一つは、同義と見なす語のグループは最終的に同じワード(見出し語)に終着させるというところがポイントになっています。

事前のインデックス時の見出し語終着と同じ手順(アナライザー)で検索時も見出し語を終着させれば、同じ結果が得られますよねというところです。

もちろん、一つの見出し語に無理に終着させなくとも、検索時かインデックス時に終着に向かうものとおおよそ逆の手順で派生してやれば、反対の方はアナライズは最小限ですみそうです(下記の図A、図B)。 ただ、それでもひとつの見出し語に片寄するのは、多分、これがもろもろの空間効率が良い方式だからだと思います。

f:id:azotar:20210627225919p:plain

ということで、細かいところはボロが出るのでこれ以上は深追いしませんが、検索時とインデックス時のアナライザーは同じ...でスタートして不都合があれば、別のことを考えましょうがヒューリステックなのかと思います。

が、実のところElasticsearchでも、トークン(この場合は見出し語とおおよそ同義)を複数派生させることができるプラグインがあります。代表的なところでいうと、edge_ngramです。

複数派生プラグインの挙動(edge_ngramを例にして)

edge_ngramでは、

あいうえおかきくけこ

という語であれば、min_gram:1、max_gram:50としたセッティングの場合、

あ
あい
あいう
あいうえ
あいうえお
あいうえおか
あいうえおかき
あいうえおかきく
あいうえおかきくけ
あいうえおかきくけこ

と派生されます。

ちなみに、

あいうれろ

という語の場合、

あ
あい
あいう
あいうれ
あいうれろ

となります。

ここで、

あいうえお

という語が検索語で、ここにmin_gram:1、max_gram:50とした先と同じセッティングのアナライズをかけると

あ
あい
あいう
あいうえ
あいうえお

で派生されます。

そうです。

派生されて、

"あ "で始まる
"あい "で始まる
"あいう "で始まる
"あいうえ "で始まる
"あいうえお "で始まる

のいずれかのものを検索しにいくことになります。

よって、

この場合、

検索語、

あいうえお

 は

あいうえお
あいうえおかも
あいうえおです

はもちろん、

"あ "で始まる
"あい "で始まる
"あいう "で始まる
"あいうえ "で始まる
"あいうえお "で始まる

ような

あいう
あいう***...
あいうえ***...

みたいなものもヒットすることになります。

edge_ngramで派生した転置インデックスと同じ条件で派生した検索語で検索される場合、ある意味それは意図通りとは言え、最初の何文字かが一致するものを幅広く当ててしまうことになります。

ということで、他のアナライズの例が検索時とインデックス時で同じアナライザーを用いる組み合わせがおのずと大半となるのに対し、edge_ngramでは次のようなところを戦略的に決めておく度合いが高くなると思います。

1) 検索時とインデックス時のアナライザーは同じにする(上記を狙い通りとする) ※prefix検索にはない特徴を得られると考えた用法

2) トーカナイザーにwhitespace(など何もしない検索時アナライザー)を使う

3) 検索時のアナライザーでは、トーカナイザーにkuromojiなどを使い、かつトークンフィルターで2トークン目を読み捨てるなどする

4) 最小gramが大きめのedge_ngramを使うことで、加減する   (検索語"あいうえお"で、"あいうけ","あいうせそ"はヒットさせないが、"あいうえと"はヒットすると嬉しい範囲とする。)

なお、ここまでの話で出てきたedge_ngramはどちらかと言えば、tokenizerの方のedge_ngramです。

実際のところ、同じことは、token filter系である、multiplexerなどでもあてはまります。もちろん、token filterのedge_ngramでも当てはまります。

また、ngram系でなくとも、multiplexerでは、いくつか別のfilterを用いた、複数トークンを派生させることができますが、派生させた複数トークンに対して「このうちのどれか」というマッチングになります。

というか、書いていて気づきましたが、token filter、tokenizerどちらでedge_ngramを使う場合でも、またtoken filterであるmultiplexerでも、いずれも最終的に同じpositionのトークンが派生されるという意味では、違いがなくて当然ですね。やや回りくどい説明になってしまったかもしれません。

とりとめもなく書き下してしまいましたが、この記事以上です。

【付録】いろいろ試す用の例

特に解説等はしませんが、上記等を試すためのmapping設定の例などです。

確認はElasticsearch v6.8ですが、以下の範囲であれば、7.x系でも動作すると思います。

(なお、マッチしたトークン数を把握しやすくするために、similarityを独自定義しています。本記事テーマそのものの設定として必要かというとそうではありません。)

egde_ngram版

PUT en
{
  "settings": {
    "similarity": {
      "cnt": {
        "type": "scripted",
        "script": {
          "source": "return query.boost * doc.freq;"
        }
      }
    },
    "analysis": {
      "analyzer": {
        "a1": {
          "type": "custom",
          "similarity": "cnt",
          "tokenizer": "kuromoji_tokenizer"
        },
        "a2":{
          "type":"custom",
          "similarity":"cnt",
          "tokenizer":"en"
        }
      },
    "tokenizer":{
      "en":{
        "type":"edge_ngram",
        "min_gram":1,
        "max_gram":20,
        "token_chars":["letter"]
      }
    }
    }
  },
  "mappings": {
    "mapping": {
      "properties": {
        "text_a1": {
          "type": "text",
          "analyzer": "a1",
          "similarity": "cnt"
        },
        "text_a2": {
          "type": "text",
          "analyzer": "a2",
          "similarity": "cnt"
        }
      }
    }
  }
} 
POST en/_doc/1
{"text_a1":"会社のお金の話" }
POST en/_doc/2
{"text_a2":"会社のお金の話" }
GET en/_search
{
  "query": {"match": {
    "text_a2": {
      "query":"会社が",
    "analyzer":"a2"
    }
  }}
}

multiplexer版

PUT mp
{
  "settings": {
    "similarity": {
      "cnt": {
        "type": "scripted",
        "script": {
          "source": "return query.boost * doc.freq;"
        }
      }
    },
    "analysis": {
      "analyzer": {
        "a1": {
          "type": "custom",
          "similarity": "cnt",
          "tokenizer": "kuromoji_tokenizer",
          "filter": [
            "mp1"
          ]
        },
        "a2":{
          "type":"custom",
          "similarity":"cnt",
          "tokenizer":"kuromoji_tokenizer"
        }
      },
      "filter": {
        "mp1": {
          "type": "multiplexer",
          "filters": [
            "kuromoji_readingform",
            "k2h",
            "roma"
            ],
            "preserve_original": true
        },
        "k2h": {
          "type": "icu_transform",
          "id": "Katakana-Hiragana"
        },
        "roma":{
          "type":"kuromoji_readingform",
          "use_romaji": true
        }
      }
    }
  },
  "mappings": {
    "mapping": {
      "properties": {
        "text_a1": {
          "type": "text",
          "analyzer": "a1",
          "similarity": "cnt"
        },
        "text_a2": {
          "type": "text",
          "analyzer": "a2",
          "similarity": "cnt"
        }
      }
    }
  }
} 
POST mp/_doc/1
{"text_a1":"こんにちは サヨウナラ"}
POST mp/_doc/2
{"text_a1":"コンニチハ さようなら"}
POST mp/_doc/3
{"text_a1":"こんにちは さようなら"}
POST mp/_doc/4
{"text_a1":"コンニチハ サヨウナラ"}

POST mp/_doc/5
{"text_a2":"こんにちは サヨウナラ"}
POST mp/_doc/6
{"text_a2":"コンニチハ さようなら"}
POST mp/_doc/7
{"text_a2":"こんにちは さようなら"}
POST mp/_doc/8
{"text_a2":"コンニチハ サヨウナラ"}
POST mp/_doc/9
{"text_a2":"konnichiha"}
GET mp/_search
{
  "query":{
    "match": {
      "text_a1":{
        "query": "こんにちは さようなら",
        "operator": "and", 
        "analyzer": "whitespace"
      }
    }
  }
}