sql查询翻译查询DSL kibana答案

【问题标题】：sql query translation Query DSL kibanasql查询翻译查询DSL kibana
【发布时间】：2019-09-02 19:35:41
【问题描述】：

请解释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"
          }
        }
      }
    }
  }
}

【问题讨论】：

这是什么版本的 Elasticsearch？
我的 Elasticsearch 是 7.3.0

标签： elasticsearch elasticsearch-sql

【解决方案1】：

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

【讨论】：

好的，group by 是“10985”，order by 是“11030”，反之亦然？我怎么能看到找到任何可以识别我正在将限制从 2 更改为 3 的标记？
分组依据是您的术语聚合("10985");它基本上是按条款聚合的（也就是按价值分组）。 order by 只是同一 agg 中的 "order" : "asc" 子句。 limit 子句将是 size 子句，但似乎没有在 sql 的 ES 查询中翻译 bben；可能还不支持。

【解决方案2】：

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

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

关于asc DESC 差异，如果您密切注意，您的DESC 排序在AVG 上，而asc 排序是针对composite 的terms 聚合，这是两个不同的聚合事物。 ES-SQL 对聚合 "client" side (as opposed to server/ES side) 执行排序，因为在使用 composite 聚合时没有 ES 查询会执行该排序。

底线是您看到的查询是完整的，但不完全，因为这是 ES-SQL 在 Elasticsearch 上运行的查询，但还有一个客户端任务执行实际按 AVG 排序。有一个 improvement issue already opened 来增强 translate API 以表明，如果用户在 ES 本身上运行该查询，至少生成的查询可能不足以实现相同的结果。

【讨论】：