0

请解释在kibana控制台中从sql查询翻译的逻辑。最令人困惑的是“order”：“asc”，而我请求 desc。

数字“10985”和“11030”看起来也很奇怪。如果我重新运行翻译，这些数字会发生变化。

我做一个查询翻译：

    POST _sql/translate
{
  "query": "SELECT day_of_week, avg(taxful_total_price) FROM kibana_sample_data_ecommerce WHERE customer_id = 52 GROUP BY day_of_week ORDER BY avg(taxful_total_price) DESC LIMIT 2"
  }

翻译：

    {
  "size" : 0,
  "query" : {
    "term" : {
      "customer_id" : {
        "value" : 52,
        "boost" : 1.0
      }
    }
  },
  "_source" : false,
  "stored_fields" : "_none_",
  "aggregations" : {
    "groupby" : {
      "composite" : {
        "size" : 1000,
        "sources" : [
          {
            "10985" : {
              "terms" : {
                "field" : "day_of_week",
                "missing_bucket" : true,
                "order" : "asc"
              }
            }
          }
        ]
      },
      "aggregations" : {
        "11030" : {
          "avg" : {
            "field" : "taxful_total_price"
          }
        }
      }
    }
  }
}
4

2 回答 2

0

关于变化的数字，它们只是聚合的名称；好像你会在 sql 中使用“AS 11030”。它允许您通过引用其名称在其他聚合中使用聚合。在 ES 查询的结构中必须有一个聚合的名称。也许用数字随机命名聚合是翻译的正常行为。它不应该对查询结果或其行为产生影响。

于 2019-08-30T18:27:20.450 回答
0

聚合名称没有意义，它们是随机生成的，但是 ES-SQL 会跟踪哪个是哪个（显然），并且每当一个聚合需要另一个聚合的结果时，它就知道要使用哪个。

有一个改进请求 - https://github.com/elastic/elasticsearch/issues/43531 - 具有一致的命名，以便可以使用缓存。尚未实施，目前不在近期的路线图中。

关于ascDESC 差异，如果您密切注意，您的DESC排序是开启AVG的，而asc排序是针对composite的terms聚合，这是两个不同的事情。ES-SQL 在聚合“客户端”端（而不是服务器/ES 端）composite执行排序，因为在使用聚合时没有 ES 查询会执行该排序。

底线是您看到的查询是完整的，但并不完全，因为这是 ES-SQL 在 Elasticsearch 上运行的查询，但还有一个客户端任务执行 AVG 的实际排序。已经打开了一个改进问题以增强translateAPI，以表明，如果用户在 ES 本身上运行该查询，至少生成的查询可能不足以实现相同的结果。

于 2019-09-02T11:35:41.853 回答