ELK聚集查询之管道聚集和SQL语言（九）

浅浅的花香味﹌ 2022-12-13 14:09 310阅读 0赞

这篇分析ELK聚集查询之管道聚集和SQL语言：

管道聚集不是直接从索引中读取文档，而是在其他聚集的基础上再进行聚集 运算。所以管道聚集可以理解为是在聚集结果上再次做聚集运算，比如求聚集结 果中多个桶中某一指标的平均值、最大值等。要实现这样的目的，管道聚集都会 包含一个名为 buckets\_path  的参数，用于指定访问其他桶中指标值的路径。 buckets\_ path 参数的值由三部分组成，即聚集名称、指标名称和分隔符。聚集名称与聚集名称之间的分隔符是“>”，而聚集名称与指标名称之间的 分隔符使用“. ”。 按管道聚集运算来源分类，管道聚集可以分为基于父聚集结果和基于兄弟聚 集结果两类。前者使用父聚集的结果并将运算结果添加到父聚集结果中，后者则

使用兄弟聚集的结果并且结果会展示在自己的聚集结果中。

**1、基于兄弟聚集**

其于兄弟聚集的管道聚集包括  avg\_bucket 、 max\_ bucket 、 min\_bucket 、 sum \_bucket、  stats\_bucket 、 extended\_ stats\_ bucket 、  percentiles\_bucket  七种。如 果将它们名称中的 bucket  去除，它们就与本章前面介绍的部分指标聚集同名了。

事实上，它们不仅在名称上接近，而且在功能上也类似，只是聚集运算的范围由 整个文档变成了另一个聚集结果。以avg\_bucket  为例， 它的作用是计算兄弟聚 集结果中某一指标的平均值:

POST /kibana\_sample\_data\_flights/\_search?filter\_path=aggregations

"aggs": \{

"carriers": \{

"terms":\{

"field": "Carrier",

"size": 10

\},

"aggs": \{

"carrier\_stat": \{

"stats": \{

"field": "AvgTicketPrice"

\},

"all\_stat": \{

"avg\_bucket": \{

"buckets\_path": "carriers>carrier\_stat.avg"

例中，最外层包含有两个名称分别为  carriers  和  all\_stat  的聚集，这两个聚 集就是兄弟关系。 carries 聚集是一个针对  Carrier  字段的  terms  聚集， Carrier  字段保存的是航 班承运航空公司，所以这个聚集的作用是按航空公司将航班分桶。在这个聚集中

嵌套了一个名为  carrier\_stat  的聚集，它是一个针对  AvgTicketPrice  字段的  stats 聚集，会按桶计算票价的最小值、平均值等统计数据。 all\_ stat 聚集则是一个  avg\_bucket  管道聚集，在它的  Path  参数中指定了运 算平均值的路径" carriers>carrier\_stat.avg " ，即从兄弟聚集中查找  carrier\_stat  指 标聚集， 然后再用其中的 avg  字段参与平均值计算。 所以  all\_ stat  这计算出来 的是四个航空公司平均票价的平均值，实际上就是所有航班的平均票价。 尽管示例针对 avg\_bucket  管道聚集的检索，但使用其余六种基于兄弟的管 道聚集的关键字值替换后，它们就变成了另一种合法的管道聚集了。

**2、基于父聚集**

基于父聚集的管道聚集包括  moving\_avg 、 moving\_fn 、 bucket\_script 、 bucket\_selector、 bucket\_sort 、 derivative 、 cumulative\_sum 、 serial\_diff  八种。

***3、滑动窗口***

moving\_avg  和  moving\_fn  这两种管道聚集的运算机制相同，都是基于滑动 窗口( Siding Window) 算法对父聚集的结果做新的聚集运算。滑动窗口算法使用一 个具有固定宽度的窗口滑过一组数据， 在滑动的过程中对落在窗口内的数据做 运算。moving\_avg  管道聚集是对落在窗口内的父聚集结果做平均值运算，而 moving\_fn 管道聚集则可以对落在窗口内的父聚集结果做各种自定义的运算。由 于 moving\_avg  管道可以使用  moving\_fn  管道聚集实现，所以  moving\_avg  在 Elaticearch 版本  6.4.0  中已经被废止。

由于使用滑动窗口运算时每次移动  1  个位置， 这就要求  moving\_avg  和 moving\_fn 所在聚集桶与桶间隔必须固定，所以这两种管道聚集只能在  histogam 和 date\_histogam  聚集中使用：

POST /kibana\_sample\_data\_flights/\_search?filter\_path=aggregations

"aggs": \{

"day\_price": \{

"date\_histogram": \{

"field": "timestamp",

"interval": "day"

\},

"aggs": \{

"avg\_price": \{

"avg": \{  "field": "AvgTicketPrice"

\},

"smooth\_price": \{

"moving\_fn": \{

"buckets\_path": "avg\_price",

"window": 10,

"script":"MovingFunctions.unweightedAvg(values)"

在示例中，最外层的父聚集  day\_price  是  1  个  date\_histogam  桶型聚集，它 根据文档的 timestamp  字段按天将文档分桶。 day\_price  聚集包含  avg\_price  和 smooth\_price 两个子聚集，其中  avg\_price  聚集是一个求  AvgTicketPrice  字段在  1 个桶内平均值的 avg  聚集，而  smooth\_price  则是一个使用滑动窗口做平均值平 滑的管道聚集，窗口宽度由参数 window  设置为  10 ，默认值为  5 。 通过返回结果比较 avg\_price  与  smooth\_price  就会发现，后者由于经过了滑 动窗口运算，数据变化要平滑得多。

moving \_fn  聚集包含一个用于指定运算脚本的  script  参数，在脚本中可以通 过 values  访问  buckets\_path  参数指定的指标值。 moving \_fn  还内置了一个 MovingFunctions 类，包括多个运算函数 :

max()

min( )

sum( )

stdDev( )  标准偏差

unweightedAvg( )  无加权平均值

linearWeightedAvg( )  线性加权移动平均值

ewma( )  指数加权移动平均值

holt( )  二次指数加权移动平均值

holtWinters( )  三次指数加权移动平均值

***4、单桶运算***

目前我们学习的管道聚集会对父聚集结果中落在窗口内的多个桶做聚集运 算，而 bucket\_script 、  bucket\_selector  、 bucket\_sort  这三个管道聚集则会针对 父聚集结果中的每一个桶做单独的运算。其中， bucket\_script  会对每个桶执行一 段脚本， 运算结果会添加到父聚集的结果中， bucket\_selector  同样也是执行一 段脚本， 但它执行的结果一定是布尔类型， 并且决定当前桶是否出现在父聚集 的结果中； bucket\_sort  则根据每桶中的具体指标值决定桶的次序。下面通过示 例来说明这三种管道聚集的具体用法:

POST /kibana\_sample\_data\_flights/\_search?filter\_path=aggregations

"aggs": \{

"date\_price\_diff": \{

"date\_histogram": \{

"field": "timestamp",

"fixed\_interval": "1d"

\},

"aggs": \{

"stat\_price\_day": \{

"stats": \{"field": "AvgTicketPrice"\}

\},

"diff":\{

"bucket\_script": \{

"buckets\_path": \{

"max\_price":"stat\_price\_day.max",

"min\_price":"stat\_price\_day.min"

\},

"script": "params.max\_price - params.min\_price"

\},

"gt990": \{

"bucket\_selector": \{

"buckets\_path": \{

"max\_price":"stat\_price\_day.max",

"min\_price":"stat\_price\_day.min"

\},

"script": "params.max\_price - params.min\_price > 990"

\},

"sort\_by": \{  "bucket\_sort": \{

"sort":\[

\{"diff":\{"order":"desc"\}\}

在示例中同时应用这三种管道聚集，它们的聚集名称分别为  diff 、 gt990  和 sort\_by。最外层的  date\_price\_diff  聚集是一个以天为固定间隔的  date\_histogram 聚集，其中又嵌套了包括上述三个聚集在内的子聚集。 其中，stat\_price\_day  是一个根据  AvgTicketPrice  字段生成统计数据的  stats 聚集。diff  是一个  bucket\_script  管道聚集，它的作用是向最终聚集结果中添加

代表最大值与最小值之差的  diff  字段。它通过  buckets\_path  定义了两个参数 max\_price 和  min\_price,  并在  script  参数中通过脚本计算了这两个值的差作为最 终结果，而这个结果将出现在整个聚集结果中。 gt990 是一个  bucket\_selector  管道聚集，它的作用是筛选哪些桶可以出现在 最终的聚集结果中。它也在 buckets\_path  中定义了相同的参数，不同的是它的 script 参数运算的不是差值，而是差值是否大于  990 ，即“  params.max\_price - params.min\_price > 990 "。如果差值大于  990  即运算结果为  true, 那么当前桶将被 选取到结果中，否则当前桶将不能在结果中出现。 sort\_by 是一个  bucket\_sort  管道聚集，它的作用是给最终的聚集结果排序。 它通过 sort  参数接收一组排序对象， 在示例中是使用  diff  聚集的结果按倒序排 序。所以示例整体的运算效果就是将那些票价最大值与最小值大于 990  的桶选 取出来，并在桶中添加 diff  字段保存最大值与最小值的差值，并按  diff  字段值降

序排列。

**5、矩阵聚集**

前面几节介绍的聚集都是针对一个字段做聚集运算，而矩阵聚集则是针对多 个字段做多种聚集运算，因此产生的结果是一个矩阵。该类型的聚集比较简单， 目前只支持一种针对多个字段做统计运算的矩阵聚集。这个聚集目前还不稳定， 我们不予了解。

**6、父子关系** Elasticsearch  中的父子关系是单个索引内部文档与文档之间的一种关系，父 文档与子文档同属一个索引并通过父文档 id  建立联系， 类似于关系型数据库 中单表内部行与行之间的自关联，比如有层级关系的部门表中记录之间的关联。

**7、join**  **类型**

在  Elasticsearch  中并没有外键的概念，文档之间的父子关系通过给索引定义 join 类型字段实现。例如创建一个员工索引  employes,  定义个  join  类型的 managemet 字段用于确定员工之间的管理与被管理关系 :

PUT employees

"mappings": \{

"properties": \{

"management":\{

"type": "join",

"relations":\{

"manager": "member"

在示例中， management  字段的数据类型被定义为  join, 同时在该字段的 relations 参数中定义父子关系为  manager  与  member, 其中  manager  为父而 member 为子，它们的名称可由用户自定义。文档在父子关系中的地位，是在添 加文档时通过 join  类型字段指定的。还是以  employes  索引为例，在向  employees 索引中添加父文档时，应该将 mangement  字段设置为  manager; 而添加子文档时 则应该设置为 member 。具体如下 :

PUT /employees/\_doc/1

"name" : "tom",

"management":\{

"name" : "manager"

PUT /employees/\_doc/2?routing=1

\{  "name" : "smith",

"management":\{

"name" : "member",

"parent": "1"

PUT /employees/\_doc/3?routing=1

"name" : "john",

"management":\{

"name" : "member",

"parent": "1"

在示例中，编号为  1  的文档其  management  字段通过  name  参数设置为 manager, 即在索引定义父子关系中处于父文档的地位，而编号为  2  和  3  的文档 其 management  字段则通过  name  参数设置为  member, 并通过  parent  参数指定 了它的父文档为编号 1  的文档。 在使用父子关系时，要求父子文档必须要映射到同一分片中，所以在添加子 文档时 routing  参数是必须要设置的。显然父子文档在同一分片可以提升在检索 时的性能，可在父子关系中使用的查询方法有 has\_child 、  has\_parent  和 parent\_id 查询，还有  parent  和  children  两种聚集。

**8、has\_child**  **查询**

has\_child  查询是根据子文档检索父文档的一种方法，它先根据查询条件将满 足条件的子文档检索出来，在最终的结果中会返回具有这些子文档的父文档。例 如，如果想检索 smith  的经理是谁，可以 :

POST /employees/\_search

"query": \{

"has\_child":\{

"type": "member",

"query":\{

"match":\{

"name": "smith"

\} \}

在示例中， has\_child  查询的  type  参数需要设置为父子关系中子文档的名称 member,这样  has\_child  查询父子关系时就限定在这种类型中检索 ; query  参数则 设置了查询子文档的条件，即名称为 smith 。最终结果会根据  smith  所在文档， 通过 member  对应的父子关系检索它的父文档。

**9、has\_parent**  **查询**

has\_parent  查询与  has\_child  查询正好相反，是通过父文档检索子文档的一 种方法。 在执行流程上， has\_parent  查询先将满足 查询条件的父文档检索出 来，但在最终返回的结果中展示的是具有这些父文档的子文档。 例如，如果想 查看 tom  的所有下属，可以按示例请求 :

POST /employees/\_search

"query": \{

"has\_parent":\{

"parent\_type": "manager",

"query":\{

"match":\{

"name": "tom"

has\_parent  查询在结构上与  has\_child  查询基本相同，只是在指定父子关系 时使用的参数 是 parent\_type  而不是  type 。

**parent\_id**  **查询**

parent\_id  查询与  has\_parent  查询的作用相似，都是根据父文档检索子文档。 不同的是，has\_parent  可以通过  query  参数设置不同的查询条件 ; 而  parent\_id  查 询则只能通过父文档 id  做检索。例如，查询  id  为  1  的子文档 :

POST /employees/\_search

\{  "query": \{

"parent\_id": \{

"type": "member",

"id":1

**10、children**  **聚集**

如果想通过父文档检索与其关联的所有子文档就可以使用  children  聚集。同 样以 employess  索引为例，如果想要查看  tom  的所有下属就可以按示例的方式检 索:

POST /employees/\_search?filter\_path=aggregations

"query":\{

"term":\{

"name":"tom"

\},

"aggs":\{

"members":\{

"children":\{

"type": "member"

\},

"aggs": \{

"member\_name":\{

"terms":\{

"field": "name.keyword",

"size": 10

在示例中， query  参数设置了父文档的查询条件，即名称字段  name  为  tom 的文档，而聚集查询 members  中则使用了  children  聚集将它的子文档检索出来， 同时还使用了一个嵌套聚集 member\_name  将子文档  name  字段的词项全部展示 出来了。

**11、parent**  **聚集**

parent 聚集与 children 聚集正好相反，它是根据子文档查找父文档，parent 聚 集在 Elasrticsearch  版本  6.6  以后才支持。例如通过  name  字段为  smith  的文档， 在找该文档的父文档:

POST /employees/\_search?filter\_path=aggregations

"query": \{

"match":\{

"name": "smith"

\},

"aggs": \{

"who\_is\_manager":\{

"parent":\{

"type": "member"

\},

"aggs":\{

"manager\_name":\{

"terms":\{

"field" :"name.keyword" ,

"size": 10

**12、嵌套类型**

前面所说的对象类型虽然可按  JSON  对象格式保存结构化的对象数据，但由 于 Lucene  并不支持对象类型，所以  Elastiesearch  在存储这种类型的字段时会将 它们平铺为单个属性。例如:

PUT colleges/\_doc/1

"address": \{

"country":"CN" ,

"city":"BJ"

\},

"age": 10

在示例中的  colleges  文档， address  字段会被平铺为  address.country  和 address.city 两个字段存储。这种平铺存储的方案在存储单个对象时没有什么问题， 但如果在存储数组时会丢失单个对象内部字段的匹配关系。例如:

PUT colleges/\_doc/2

"address":\[

"country": "CN",

"city":"BJ"

\},

"country" : "US",

"city": "NY"

\],

"age":10

示例中的  colleges  文档在实际存储时，会被拆解为“  address. country": \["CN.US"\]” 和  address. city":\["BJ" ,"NY"\] ” 两个数组字段。这样一来，单个对象 内部，country  字段和  city  字段之间的匹配关系就丢失了。换句话说，使用  CN  与 NY 作为共同条件检索的文档时，上述文档也会被检索出来，这在逻辑上就出现 了错误:

POST colleges/\_search

"query": \{

"bool": \{

"must":\[

\{"match": \{ "address.country": "CN"\}\},

\{"match": \{"address.city": "NY"\}\} \]

在示例中使用了  bool  组合查询，要求  country  字段为  CN  而  city  字段为  NY 。 这样的文档显然并不存在，但由于数组中的对象被平铺为两个独立的数组字段， 文档仍然会被检索出来。

**13、nested**  **类型**

为了解决对象类型在数组中丢失内部字段之间匹配关系的问题， Elasticsearch 提供了一种特殊的对象类型  nested 。这种类型会为数组中的每一个 对象创建一个单独的文档， 以保存对象的字段信息并使它们可检索。由于这类 文档并不直接可见，而是藏置在父文档之中，所以这类文档可以称为为隐式文档 或嵌入文档。还是以 colleges  索引为例，我们把原有的索引删除，将它的  address 字段设置为 nested  类型 :

PUT colleges

"mappings": \{

"properties": \{

"address":\{

"type": "nested"

\},

"age":\{

"type":"integer"

然后重新存入文档  1  和  2 ，当字段被设置为  nested  类型后，再使用原来查询 中的 bool  组合查询就不能检索出来了。这是因为对  nested  类型字段的检索实际 上是对隐式文档的检索，在检索时必须要将检索路由到隐式文档上，所以必须使 用专门的检索方法。也就是说，现在即使将原来查询中的查询条件设置为 CN  和 BJ 也不会检索出结果。 nested 类型字段可使用的检索方法包括  DSL  的  nested  查询，还有聚集查询 中的 nested  和  reverse\_nested  两种聚集。

**14、nested**  **查询**

nested  查询只能针对  nested  类型字段，需要通过  path  参数指定  nested  类型 字段的路径，而在 query  参数中则包含了针对隐式文档的具体查询条件。例如 :

POST /colleges/\_search

"query":\{

"nested":\{

"path": "address",

"query": \{

"bool":\{

"must":\[

\{"match": \{"address.country": "CN"\}\},

\{"match": \{"address.city": "NY"\}\}

在示例中再次使用  CN  与  NY  共同作为查询条件，但由于使用  nested  类型后 会将数组中的对象转换成隐式文档，所以在 nested  查询中将不会有文档返回了。 将条件更换为 CN  和  BJ ，则有文档返回。

**15、nested**  **聚集**

nested  聚集是一个单桶聚集，也是通过  path  参数指定  nested  字段的路径， 包含在 path  指定路径中的隐式文档都将落入桶中。所以  nested  字段保存数组的 长度就是单个文档落入桶中的文档数量，而整个文档落入桶中的数量就是所有文 档 nested  字段数组长度的总和。有了  nested  聚集，就可以针对  nested  数组中的 对象做各种聚集运算，例如:

POST /colleges/\_search?filter\_path=aggregations

"aggs": \{

"nested\_address":\{

"nested":\{

"path": "address"

\}, "aggs":\{

"city\_names": \{

"terms":\{

"field": "address.city.keyword",

"size": 10

在示例中， nested\_address  是一个  nested  聚集的名称，它会将  address  字段 的隐式文档归入一个桶中。而嵌套nested\_address  聚集中的  city\_names  聚集 则会在这个桶中再做 terms  聚集运算，这样就将对象中  city  字段所有的词项枚举 出来了。

**16、reverse\_nested**  **聚集**

reverse\_nested  聚集用于在隐式文档中对父文档做聚集，所以这种聚集必须 作为 nested  聚集的嵌套聚集使用。例如 :

POST /colleges/\_search?filter\_path=aggregations

"aggs": \{

"nested address": \{

"nested":\{

"path": "address"

\},

"aggs":\{

"city names":\{

"terms":\{

"field": "address.city.keyword",

"size": 10

\},

"aggs": \{

"avg\_age\_in\_city":\{

"reverse\_nested": \{\},

"aggs": \{  "avg\_age": \{

"avg": \{"field": "age"\}

在示例中，city\_ names 聚集也是将隐式文档中  city  字段的词项全部聚集出来。 不同的是在这个聚集中还嵌套了一个名为 avg\_age\_in\_city  的聚集，这个聚集就是 个 reverse\_ nested  聚集。它会在隐式文档中将  city  字段具有相同词项的文档归入

一个桶中，而  avg\_age\_in\_city  聚集嵌套的另外一个名为  avg\_age  的聚集，它会 把落入这个桶中文档的 age  字段的平均值计算出来。所以从总体上来看，这个聚 集的作用就是将在同一城市中大学的平均校龄计算出来。

**17、使用**  **SQL**  **语言**

Elasticsearch  在  Basic  授权中支持以  SQL  语句的形式检索文档， SQL  语句在 执行时会被翻译为 DSL  执行。从语法的角度来看， Elastisearch  中的  SQL  语句与 RDBMS 中的  SQL  语句基本一致， 所以对于有数据库编程基础的人来说大大降低

了使用  Elaticsearch  的学习成本。 Elasticsearch 提供了多种执行 SQL  语句的方法，可使用类似 \_search  样的  REST 接口执行也可以通过命令行执行。它甚至还提供了 JDBC  和  ODBC  驱动来执行  SQL 语句，但 JDBC  和  ODBC  属于  Platinum ( 白金版 ) 授权需要付费，所以本小节将只介 绍\_sql  接口。

**18、sql**  **接口**

在早期版本中， Elasticsearch  执行  SQL  的  REST  接口为 \_xpack/sql,  但在版本 7 以后这个接口已经被废止而推荐使用 \_sql  接口。例如 :

POST \_sql?format=txt

"query":"""

select DestCountry, OriginCountry,AvgTicketPrice

from kibana\_sample\_data\_flights

where Carrier = 'Kibana Airlines'

order by AvgTicketPrice desc """

在示例中，\_sql接口通过 query 参数接收 SQL 语句，而 SQL 语句也包含有 select 、 from、 where 、  orderby  等子句。 \_sql  接口的  URL  请求参数  format  定义了返回结 果格式。比如在示例中定义了返回结果格式为 txt 。除了  txt  以外， \_sqI  接口还支 持 csv 、  json 、 tsv 、 yaml  等等格式。 示例中的请求会将所有航空公同为 Kibana Airines  的航班文档检索出来，并 以文本表格的形式返回。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

对于总量比较大的  SOL  查询，sql 接口还支持以游标的形式实现分页。当 \_sql 接口的请求参数中添加了 fetch\_size  参数， sql  接口在返回结来时就会根据 fetch\_size 参数设置的大小返回相应的条数，并在返回结果中添加游标标识。具 体来说，当请求\_sql  接口时设置的  forma  为  json  时，返回结果中会包含  cursor 属性；而其他情况下则会在响应中添加Cursor 报头。例如还是执行示例中的 SOL  ， 但是加入分页支持:

POST \_sql?format=json

"query":"""

select DestCountry, OriginCountry,AvgTicketPrice

from kibana\_sample\_data\_flights

where Carrier = 'Kibana Airlines'

order by AvgTicketPrice desc

""",

"fetch\_size":10

在示例的请求中，为了能够在返回结果中直接看到  cursor  值，我们将  format 设置为 json ，可以看到：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

POST \_sql?format=json

"cursor":"k8OvAwFaAXN4RkdsdVkyeDFaR1ZmWTI5dWRHVjRkRjkxZFdsa0RY

RjFaWEo1UVc1a1JtVjBZMmdCRkdWV2JWZDNXRWxDTVZKMlowOXpha2R4U0RVM0F

BQUFBQUFCYk5jV1dIZ3daMFZWVld4UlNtbElSVXBTWVdaRFN6RmlVUT09/w8DA

WYLRGVzdENvdW50cnkBC0Rlc3RDb3VudHJ5AQdrZXl3b3JkAQAAAWYNT3JpZ2luQ29

1bnRyeQENT3JpZ2luQ291bnRyeQEHa2V5d29yZAEAAAFmDkF2Z1RpY2tldFByaWNlA

Q5BdmdUaWNrZXRQcmljZQEFZmxvYXQAAAABBw=="

而在上面的请求中，参数  cursor  就是第一个请求返回结果中的  cursor  值， 反复执行请求，Elasticsearch  就会将第一次请求的全部内容以每次  10  个的数量 全部迭代出来。在请求完所有数据后，应该使用\_sql/close  接口将游标关闭以释 放资源。

POST \_sql/close

"cursor":"k8OvAwFaAXN4RkdsdVkyeDFaR1ZmWTI5dWRHVjRkRjkxZFdsa0RY

RjFaWEo1UVc1a1JtVjBZMmdCRkdWV2JWZDNXRWxDTVZKMlowOXpha2R4U0RVM0F

BQUFBQUFCYk5jV1dIZ3daMFZWVld4UlNtbElSVXBTWVdaRFN6RmlVUT09/w8DA

WYLRGVzdENvdW50cnkBC0Rlc3RDb3VudHJ5AQdrZXl3b3JkAQAAAWYNT3JpZ2luQ29

1bnRyeQENT3JpZ2luQ291bnRyeQEHa2V5d29yZAEAAAFmDkF2Z1RpY2tldFByaWNlA

Q5BdmdUaWNrZXRQcmljZQEFZmxvYXQAAAABBw=="

除了  fetch\_size  以外还有些可以在 \_sql  接口请求体中使用的参数，如下：

query  需要执行的  SQL  语句，必须要设置的参数

fetch\_size  默认  1000 ，每次返回的行数

filter  默认  none ，使用  DSL  设置过滤器

request\_timeout  默认  90s ，请求超时时间

page\_timeout  默认  45s ，分页超时时间

tume\_zone  默认  Z ，时区

field\_multi\_value\_leniency  默认  false ，如果一个字段返回多个值时是否忽略 在这些参数中， fiter  可以使用  DSL  对文档做过滤，支持  DSL  中介绍的所有 查询条件。query  中的  SQL  语句在翻译为  DSL  后，会与  filter  中的  DSL  查询语句共 同组合到 bool  查询中。其中  SQL  语句生成的  DSL  将出现在  must  子句，而  filter 中的 DSL  则出现在  filter  子句中。来想要查看  SQL  语句翻译后的  DSL.  可以使用 \_sql/translate 执行相同的请求，在返回结果中就可以看到翻译后的  DSL  了。

**19、SQL**  **语法**

Elasticsearch  支持传统关系型数据库  SQL  语句中的查询语句，但并不支持 DML、 DCL  句。换句话说，它只支持  SELECT  语句，不支持  INSERT 、 UPDATE 、 DELETE 语句" 。 SELECT  语句以外， Elaticsarch  还支持  DESCRIBE  和  SHOW  语句。

***20、SELECT***  ***语句***

SELECT  语句用于查询文档，基本语法格式如示例  8-29  所示 :

SELECT select \_expr ，

\[ FROM table\_name 」

\[WHERE condtion\]

\[ GROUP BY grouping\_element\]

\[ HAVING condition J

\[ ORDER BY expression \[ASC|DESC\]

\[ LIMIT\[ count\]\]

通过示例可以看出， Elastiesearch  的  SELECT  语句跟普通  SQL  几乎没有什么 区别，支持 SELECT 、 FROM 、  WHERE 、  GROUP BY 、 HAVING 、  ORDER BY  及  LIMTT 子句。SELECT 子句中可以使用星号或文档字段名称列表，FROM  子句则指定要检索 的索引名称，而 WHERE  子句则设定了检索的条件。一般的  SQL  查询使用这三个 子句就足够了，而 GROUP BY  和  HAVING  子句则用于分组， ORDER BY  子句用于排 序，而 LIMIT  一般则可以用于分页。和传统  SQL  语句非常接近。

***21、DESCRIBE***  ***语句***

DESCRIBE  语句用于查看一个索引的基础信息，在返回结果中一般会包含 column、 type 、 mapping  三个列，分别对应文档的字段名称、传统数据库类型及 文档字段中的类型。例如要查看索引的基本信息:

POST \_sql?format=txt

"query":"describe kibana\_sample\_data\_flights"

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

***22、SHOW***  ***语句***

SHOW  语句包括三种形式，即  SHOW COLUMNS 、 SHOW FUNCTIONS  和  SHOW

TABLES  。 SHOW COLUMNS 用于查看一个索引中的字段情况，它的作用与  DESCRIBE  语

句完全一样，其至连返回结果都是一样的。 SHOW FUNCTIONS 用于返回在  Elastiesearch SQL  中支持的所有函数，返回结

果中包括  MIN 、 MAX 、 COUNT  等常用的聚集函数。 最后，SHOW TABLES  用看  Elaticecearch  中所有的索引。

POST \_sql?format=txt

"query":"show columns in kibana\_sample\_data\_flights"

POST \_sql?format=txt

"query":"show functions"

POST \_sql?format=txt

"query":"show tables"

这三种形式都支持使用  LIKE  子句过滤返回结果， LIKE  子句在用法上与  SQL 语句中的 LIKE  类似。例如，“ show functions like 'a%" 将只返回以  a  开头的函数。

***23、操作符与函数***

Elasticsearch SQL  中支持的操作符与函数有  100  多种，这些操作符大多与普 通 SQL  语言一致，所以这里只介绍一些与普通  SQL  语句不一样的地方。 先来看一下比较操作符。一般等于比较在 SQL  中使用等号“ = ”，这在 ElasticsearchSQL 中也成立。但是  Elasticseareh SQL  还引人了另一个等号比较“ < = >”，这种等号可以在左值为  null  时不出现异常。 LIKE 操作符，在  LIKE  子句中可以使用 % 代表任意多个字符，而使用下划线  \_ 代表单个字符。Elasticsearch SQL  不仅支持  LIKE  子句，还支持通过  RLIKE  子句以 正则表达式的形式做匹配，这大大扩展了 SQL  语句模糊匹配的能力。 尽管使用 LIKE  和  RLIKE  可以实现模糊匹配，但它离全文检索还差得很远。SQL 语句的 WHERE  子句一般都是使用字段整体值做比较，而没有使用词项做匹配的 能力。为此 Elasticsearch SQL  提供了  MATCH  和  OUERY  两个函数，以实现在  SQL 做全文检索。例如在示例 8-33  中的两干请求分别使用  match  和  query  函数，它 们的作用都是检索 DestCounty  字段为  CN  的文档 :

POST \_sql?format=txt

"query":"""

select DestCountry, OriginCountry,AvgTicketPrice,score()

from kibana\_sample\_data\_flights

where match(DestCountry,'CN')

"""

POST \_sql?format=txt

"query":"""

select DestCountry, OriginCountry,AvgTicketPrice,score()

from kibana\_sample\_data\_flights

where query('DestCountry:CN')

"""

在示例中的两个请求的  selet  子句中都使用了  SCORE  函数，它的作用是获取 检索的相关度评分值。Elasticsearch SQL 支持传统 SQL 中的聚集函数，这包括 MAX 、 MIN 、 AVG 、COUNT、 SUM 等。同时，它还支持一些  Elasticsearch  特有的聚集函数，这些聚集函数与 Elasticsearch 聚集查询相对应。这包括  FIRST/FIRST\_ VALUE  和  LAST/LAST VALUE, 可用于查看某个字段首个和最后一个非空值; PERCENTILE  和  PERCENTILE RANK  用 于百分位聚集，KURTOSIS,SKEWNESS 、 STDDEV\_ POP 、 SUM \_OF SQUARES  和  VAR\_ POP 可用于运算其他统计聚集。除了以上这些函数和操作符， Elasticsearch SQL 还定义了一组用于日期、数值以及字符串运算的函数。

ELK聚集查询之管道聚集和SQL语言分析完毕，下篇分析es和spring的集成，敬请期待。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221123/b9a04a31df7b40ad96ef80548a93e864.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221123/1d267577047e4bf8a8400f31944aee35.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221123/0759c4545c6c4bc8a92017b28419e910.png