Elastic Stack 8.11：引入一種新的強大查詢語言 ES|QL

這篇具有很好參考價值的文章主要介紹了Elastic Stack 8.11：引入一種新的強大查詢語言 ES|QL。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

作者：Tyler Perkins, Ninoslav Miskovic, Gilad Gal, Teresa Soler, Shani Sagiv, Jason Burns

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

Elastic? Stack 8.11 引入了數(shù)據(jù)流生命周期、一種配置數(shù)據(jù)流保留和降采樣（downsampling）的簡單方法（技術(shù)預(yù)覽版），以及有關(guān) Kibana? Inspector 中跨集群搜索響應(yīng)的詳細信息以及重新路由攝取處理器（reroute ingest processor）的正式發(fā)布。

這些新功能使客戶能夠：

直接在數(shù)據(jù)流中管理數(shù)據(jù)流保留，無需 ILM 策略
查看有關(guān)遠程搜索的更多信息，以便他們可以對任何潛在問題進行分類
根據(jù)字段中的值將文檔路由到正確的索引

Elastic Stack 8.11 現(xiàn)已在 Elastic Cloud 上推出，這是唯一包含最新版本中所有新功能的托管 Elasticsearch? 產(chǎn)品。你還可以下載 Elastic Stack 和我們的云編排產(chǎn)品 Elastic Cloud Enterprise 和 Elastic Cloud for Kubernetes，以獲得自我管理的體驗。

Elastic 8.11 中還有哪些新功能？查看 8.11公告帖子了解更多>>

Discover 中的 ES|QL：直接從 Discover 中通過聚合和可視化縮短獲得見解的時間

在 8.11 中，我們引入了 Elasticsearch 查詢語言 (ES|QL)，這是 Elastic 用于數(shù)據(jù)探索和調(diào)查的新管道語言。 ES|QL 轉(zhuǎn)變、豐富并簡化了你的數(shù)據(jù)探索過程。

以下是你可以期待的：

輕松開始：要開始在 Discover 中使用 ES|QL，只需從數(shù)據(jù)視圖選擇器中選擇 “Try?ES|QL”。它用戶友好且簡單。
高效、簡單的查詢構(gòu)建：Discover 中的 ES|QL 提供自動完成和 in-app 文檔，使你可以輕松地從查詢欄創(chuàng)建強大的查詢。
全面而強大的數(shù)據(jù)探索：在 Discover 中進行臨時數(shù)據(jù)探索。直接從查詢生成器創(chuàng)建聚合、轉(zhuǎn)換數(shù)據(jù)、豐富數(shù)據(jù)集等。結(jié)果以表格格式或可視化形式呈現(xiàn)；這取決于你正在執(zhí)行的查詢。
上下文可視化：在 Discover 中編寫 ES|QL 查詢時，你將收到由 Lens 建議引擎提供支持的視覺表示。你的查詢的性質(zhì)決定了你獲得的可視化類型（例如，指標、直方圖熱圖）。
豐富：使用豐富命令使用另一個數(shù)據(jù)集中的字段來增強查詢數(shù)據(jù)集，并為所選策略提供上下文建議（即提示匹配字段和豐富列）。
內(nèi)聯(lián)可視化編輯：直接在 Discover 和儀表板中編輯 ES|QL 可視化。無需導航到 Lens 即可進行快速編輯；你可以無縫地進行更改。
儀表板集成：一旦你對結(jié)果感到滿意，就可以直接從 Discover 將 ES|QL 可視化保存到儀表板。
警報：使用 ES|QL 進行可觀察性和安全警報，將聚合值設(shè)置為閾值。通過強調(diào)有意義的趨勢而非孤立事件，減少誤報，提高檢測準確性并接收可操作的通知。

Discover 中的 ES|QL 為你的數(shù)據(jù)調(diào)查帶來效率和力量，簡化你獲得見解的路徑。

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

具有可觀察性用例的 ES|QL 查詢示例：

from metrics* 
| stats max_cpu = max(kubernetes.pod.cpu.usage.node.pct), avg_mem = max(kubernetes.pod.memory.usage.bytes) by kubernetes.pod.name 
| sort max_cpu desc 
| limit 10

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

具有可觀察性用例并使用 GROK 的 ES|QL 查詢示例：

from logstash-* |
limit 100 |
keep @message |
grok @message """%{IPORHOST:source.address} (?:-|%{HTTPDUSER:apache.access.user.identity}) (?:-|%{HTTPDUSER:user.name}) \[%{TIMESTAMP_ISO8601:timestamp}\] "(?:%{WORD:http.request.method} %{NOTSPACE:url.original}(?: HTTP/%{NUMBER:http.version})?|%{DATA})" (?:-|%{INT:http.response.status_code:int}) (?:-|%{INT:http.response.body.bytes:int}) "(?:-|%{DATA:http.request.referrer})" "(?:-|%{DATA:user_agent.original})"""" 
| keep @message, source.address, timestamp, http.response.body.bytes, url.original 
| stats max_bytes = max(http.response.body.bytes) by source.address 
|sort max_bytes desc
| limit 20

ES|QL 演示

在文檔中了解有關(guān) ES|QL 功能的更多信息。

新的 ES|QL 規(guī)則類型

現(xiàn)在，現(xiàn)有 Elasticsearch 規(guī)則類型下提供了新的 ES|QL 警報規(guī)則類型。此規(guī)則類型將新的強大語言（ES|QL）中可用的所有新功能引入 Kibana Alerting，以允許和解鎖新的警報用例。

使用新類型，用戶將能夠根據(jù)定義的 ES|QL 查詢生成單個警報，并在保存規(guī)則之前預(yù)覽查詢結(jié)果。當查詢返回空結(jié)果時，不會生成警報。

創(chuàng)建和管理 ES|QL 豐富索引策略

為了支持我們新的 ES|QL 功能，我們在索引管理體驗中添加了豐富策略（enrich policies）。用戶現(xiàn)在可以從這里創(chuàng)建他們的豐富策略并立即開始使用它。配置完成后，所有豐富策略都可在 “Enrich Policies” 選項卡中使用。可以直接從 Index Management 中的 Enrich Policies 選項卡管理現(xiàn)有策略。

使用 ENRICH 豐富策略的 ES|QL 查詢示例：

from projects* |limit 10 |
enrich servers-to-project on project_id with name, server_hostname, cost |
stats num_of_servers = count(server_hostname), total_cost = sum(cost) by project_id |
sort total_cost desc

UI 中顯示的豐富策略示例：

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

改進的 ELSER 模型現(xiàn)已正式發(fā)布

在 8.8 中，我們在技術(shù)預(yù)覽版中引入了 Elastic Learned Sparse EncodeR。 ELSER 是 Elastic 用于人工智能搜索的文本擴展語言模型。它提供開箱即用的卓越相關(guān)性（即無需對域內(nèi)數(shù)據(jù)進行再訓練或任何其他 ML 或 MLOps 工作）。只需從 Elastic 的 UI 中點擊幾下即可部署它，然后開始在搜索中利用 AI 的力量。

在 8.11 中，我們發(fā)布了普遍可用的第二個版本：ELSER model-2 有兩個版本：

優(yōu)化后的模型，運行在 linux-x86_64 平臺上
跨平臺模型

根據(jù) BEIR 基準進行衡量，與原始 ELSER 版本相比，兩個 ELSER model-2 版本（平臺優(yōu)化和跨平臺）都顯示出更高的相關(guān)性。重要的是，優(yōu)化版本還顯示出顯著提高的性能，因為它減少了推理延遲。 Elastic Cloud 支持優(yōu)化版本，因此 Elastic Cloud 用戶將受益于優(yōu)化后的 ELSER model-2 性能的大幅提升。

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

請注意，ELSER 的原始版本（8.11 之前可用的模型）將保留在技術(shù)預(yù)覽版中。

機器學習推理 API

我們正在努力引入一個統(tǒng)一的推理 API，該 API 可以抽象化在針對不同任務(wù)訓練的不同模型上執(zhí)行推理的復(fù)雜性。該 API 引入了一種簡單、直觀的語法，格式如下：

POST /_inference/<task_type>/<model_id>

在 8.11 中，我們將發(fā)布該框架的第一個 MVP 迭代。該 MVP 處于技術(shù)預(yù)覽階段，最初僅支持 ELSER。這極大地簡化了創(chuàng)建推理管道的語法。

更重要的是，未來新的推理 API 將支持內(nèi)部和外部模型，并將與 LLM 生態(tài)系統(tǒng)集成，讓我們的用戶通過統(tǒng)一、不言自明的 API，輕松、無縫地擁有最強大的 AI。

儀表板中的 Lens 內(nèi)聯(lián)編輯

現(xiàn)在，你可以在不離開儀表板的情況下編輯 Lens 可視化，而無需來回導航到 Lens 編輯器。儀表板中將打開一個彈出窗口，你可以在其中對 Lens 面板進行任何編輯。這種新的編輯體驗更加方便，并且可以節(jié)省你的時間，因為保存更改時不需要重新加載儀表板。

Kibana 的 Lens 內(nèi)聯(lián)編輯

鏈接面板

現(xiàn)在，你可以使用鏈接面板輕松從一個儀表板導航到另一個儀表板。通過將儀表板分成多個可視化較少的儀表板并將它們鏈接在一起，可以更好地組織儀表板并提高其性能。導航到其他儀表板時，你可以繼承過濾器、查詢和時間范圍。水平或垂直顯示鏈接，因為它更適合你的儀表板布局。

你還可以使用鏈接面板在儀表板中包含外部鏈接（例如，指向你的 wiki 頁面或其他應(yīng)用程序）。決定是要在同一瀏覽器選項卡中還是在新選項卡中打開鏈接。

Kibana 中的鏈接面板 - links panel

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

引入顏色映射以增強數(shù)據(jù)可視化

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

我們很高興地宣布我們最新的 Kibana 功能，它為你的數(shù)據(jù)可視化體驗帶來了顯著的好處。顏色與位置和形狀一樣是基本的視覺元素，在有效傳達信息方面發(fā)揮著至關(guān)重要的作用。

以下是我們的新功能：

輕松分類：輕松將一個或多個字段類別分配給特定顏色。這使得組織和理解數(shù)據(jù)變得比以往更加簡單。
引導顏色選擇：我們直觀的顏色選擇器為你提供預(yù)定義的調(diào)色板，確保你的圖表不僅看起來很棒，而且與不同的 Kibana 主題無縫匹配。
增強的調(diào)色板：我們重新引入了清晰的調(diào)色板概念，使你可以更輕松地選擇和應(yīng)用漸變，從而提高可視化的整體美感。

無論你使用的是笛卡爾圖表、分區(qū)圖表還是標簽云圖表，這些增強功能都旨在幫助你充分利用數(shù)據(jù)。借助此功能，你可以提高對圖表上的數(shù)據(jù)點進行分類、區(qū)分和強調(diào)的能力，最終獲得更好的見解和更具視覺吸引力的儀表板。

介紹數(shù)據(jù)流生命周期（技術(shù)預(yù)覽）

要管理 Elastic 數(shù)據(jù)的生命周期，你可以使用索引生命周期管理，它提供了強大的功能來完全自定義數(shù)據(jù)層移動、翻轉(zhuǎn)（rollover）、索引設(shè)置、降采樣（downsampling）等。有很多可能性，也許比某些人需要的更多的可定制性。

我們一直致力于為數(shù)據(jù)流開發(fā)一個內(nèi)置的簡化且有彈性的生命周期實現(xiàn)，該實現(xiàn)現(xiàn)已在 8.11 中提供。數(shù)據(jù)流生命周期的主要思想是簡單：我們從一開始就將該功能設(shè)計為易于配置，因此我們從用戶的關(guān)注中刪除了盡可能多的實現(xiàn)細節(jié)，僅公開與你的需求相關(guān)的配置。我們只會詢問與你的用例和業(yè)務(wù)相關(guān)的問題：

在刪除（保留）數(shù)據(jù)之前，我們應(yīng)該將數(shù)據(jù)保留多長時間？
對于時間序列數(shù)據(jù)流，你是否希望隨著時間的推移降低指標的粒度以降低存儲成本（降采樣）？

你可以在 Kibana 的 “Index Management” 頁面的 “Data Stream” 下設(shè)置保留：

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

或者通過 _data_stream API：

PUT _data_stream/my-data-stream/_lifecycle 
{
   "data_retention": "90d"
}

配置生命周期后，我們將管理該數(shù)據(jù)流的其他所有內(nèi)容。如果你熟悉 ILM，這意味著我們正在處理翻轉(zhuǎn)和強制合并。

沒錯：配置了生命周期的數(shù)據(jù)流將自動滾動并進行尾部合并（一種輕量級的強制合并實現(xiàn)，僅合并小段的長尾部而不是整個分片）。通過自動處理分片和索引維護任務(wù)以確保最佳性能，并在索引和搜索之間進行權(quán)衡，你將能夠?qū)Ｗ⒂谀汴P(guān)心的與業(yè)務(wù)相關(guān)的生命周期方面，例如數(shù)據(jù)保留和降采樣。

數(shù)據(jù)流生命周期當前不管理跨層（熱、冷、凍結(jié)）的數(shù)據(jù)移動。需要數(shù)據(jù)分層的用例目前應(yīng)繼續(xù)使用 ILM。

數(shù)據(jù)流的此生命周期設(shè)置的實現(xiàn)經(jīng)過非常仔細的設(shè)計，考慮了多年來支持 ILM 的經(jīng)驗教訓。 ILM 使用有狀態(tài)的基于步驟的執(zhí)行，其中索引必須從一個步驟移動到下一個步驟。有時需要進行干預(yù)，以找出 ILM 為何 “陷入困境”，并幫助迫使其逐步前進。相反，數(shù)據(jù)流生命周期使用聲明式執(zhí)行方法，每次執(zhí)行時都會評估索引的當前狀態(tài)并執(zhí)行所需的操作，以完成生命周期結(jié)束狀態(tài)配置。

在 8.11 中，此功能處于技術(shù)預(yù)覽版。

跨集群搜索響應(yīng)信息觸手可及

跨集群搜索 (CCS) 是跨多個集群統(tǒng)一數(shù)據(jù)的好方法，這些集群可以分布在世界各地和不同的環(huán)境中。我們希望它盡可能頻繁地提供完整的搜索結(jié)果，但也許某些遠程集群的日子不好過。只要有可能，我們?nèi)匀粫祷夭糠纸Y(jié)果，但是你怎么知道缺少什么，以及哪些集群有什么錯誤？ 8.11 帶來了額外的搜索響應(yīng)計數(shù)信息，現(xiàn)在我們可以在 Kibana 的檢查器中輕松找到它。

每個具有未 100% 返回沒有問題的搜索的可視化都會有一條警告，該警告也直接鏈接到檢查器的 “Clusters and shards” 選項卡。

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

在那里你可以看到所有遠程集群（和本地集群）的列表、它們的搜索狀態(tài)和響應(yīng)時間。展開集群以查看更詳細的信息（例如，成功搜索到了多少分片）。

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

如果你想更深入地了解發(fā)生的情況，請單擊 “Shards” 部分中的鏈接以查看分片故障詳細信息：

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

你還可以從每個可視化一角的面板菜單訪問檢查器：

elasticsearch 8.11,Elasticsearch,Elastic,Kibana,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,數(shù)據(jù)庫

單擊 “Inspect”，單擊 “View: Requests”，然后單擊 “Clusters and shards” 選項卡。

除了 Kibana 中這個方便的新視圖之外，Elastic 8.11 還增強了 API 響應(yīng)級別的搜索響應(yīng)。除了搜索響應(yīng)中已存在的成功和跳過的計數(shù)器之外，我們現(xiàn)在還提供每個集群的 partial、failed 和?running 的搜索狀態(tài)的說明。

8.10 中的搜索響應(yīng)集群部分：

…
   "_clusters": {
      "total": 3,
      "successful": 2,
      "skipped": 1,
      "details": {
        "(local)": {
          "status": "successful",
          …
        },
…

在8.10中，partial 和 successful 都算作 successful，skipped 和 failed 都算作 skipped。

8.11 中增強的搜索響應(yīng)集群部分：

…
   "_clusters": {
      "total": 6,
      "successful": 2,
      "partial": 1,
      "skipped": 1,
      "failed"; 1,
      "running": 1,
      "details": {
        "(local)": {
          "status": "successful",
          …
        },
…

你可以使用 running 計數(shù)器來監(jiān)視異步搜索的進度。它可以用于創(chuàng)建進度條或提供正在進行的搜索的實時更新。將 partial 搜索與 sucessfull 分離可以更輕松地了解搜索的準確性，并且粒度可以幫助用戶更有效地識別和解決任何問題。添加 failed 計數(shù)器可確保用戶及時獲悉在搜索過程中出現(xiàn)故障的任何集群。

最后，我們調(diào)整了行為，以便無論你在搜索請求中使用 minimum_roundtrips:true 還是 false，所有這些新信息都可用。

重新路由處理器（reroute processor）已正式發(fā)布

我們在 8.8 中以技術(shù)預(yù)覽狀態(tài)引入了重新路由處理器，從而實現(xiàn)了我們所說的基于文檔的路由。如果你有混合在一起的文檔（可能來自 Firehose 或 docker 日志記錄驅(qū)動程序），你可以設(shè)置重新路由處理器，將每種文檔定向到更適用的攝取管道，以便可以正確處理它們以實現(xiàn)最佳搜索。在 Elastic 8.11 中，重新路由現(xiàn)已正式發(fā)布。

如果你想了解有關(guān)此功能的更多信息并查看示例，請查看我們的可觀察性團隊撰寫的博客。

使用向量搜索查找最相似的段落（paragraph）

我們添加了一個選項，使文檔在單個字段中具有多個向量，并按文檔中向量中最相似的向量進行排名。在許多用例中，此功能至關(guān)重要，但有兩個用例最為流行：

分塊文本（chunking text）：許多嵌入模型將文本的大小限制為 512 個標記（通常意味著大約 512 個單詞）。這大致翻譯為段落長度的文本。用戶經(jīng)常希望搜索包含最相關(guān)段落的文本。為此，用戶為每個段落創(chuàng)建一個向量，并希望根據(jù)每個文檔中最相似的向量對文檔進行排名，這是現(xiàn)在支持的。
多個圖像：一個文檔經(jīng)常包含多個圖像（例如，如果文檔代表房地產(chǎn)資產(chǎn)，它將包含該資產(chǎn)的多個圖像；如果文檔代表電子商務(wù)中的產(chǎn)品，則會有該產(chǎn)品的不同圖像；如果一個文檔代表一個人，它將包含該人的多個圖像）。用戶想要找到最相關(guān)的文檔（例如資產(chǎn)、產(chǎn)品或人員）。卷積神經(jīng)網(wǎng)絡(luò)旨在為每個圖像生成一個向量，用戶希望通過最相似的圖像和向量對文檔進行排名。

有關(guān)這一令人興奮且非常獨特的功能的更多信息，請參閱向 Lucene 添加 4096 維密集向量

我們已將密集向量搜索支持的維數(shù)增加到 4096 維。正如過去所指出的，我們認為進一步提高這一標準沒有問題。我們將限制維持在 4096 維度的原因是，我們目前沒有看到需要更高維度的生產(chǎn)就緒模型。如果需求增加，我們將進一步提高限額。。

最大內(nèi)積密集向量相似度

Elasticsearch 現(xiàn)在支持使用最大內(nèi)積 (MIPS) 的密集向量搜索。此選項已添加到其他支持的向量相似度選項（歐幾里得、曼哈頓、點積和余弦）中。某些向量搜索模型需要最大內(nèi)積，特別是對于一些用于生成式 AI 和 RAG 應(yīng)用程序的模型，這些模型在近幾個月已成為使用 Elasticsearch 的流行用例。

稀疏向量數(shù)據(jù)類型

Elasticsearch 現(xiàn)在支持 sparse_vector?數(shù)據(jù)類型，可供 ELSER 模型使用。雖然它與 ELSER 迄今為止使用的 rank_features 數(shù)據(jù)類型沒有本質(zhì)上的不同，但該用例非常重要、流行且不同，足以值得擁有自己的數(shù)據(jù)類型。如果不出意外的話，這樣就更容易理解了。

Exists 稀疏向量查詢

Exists 查詢返回在字段中具有特定值的文檔。 Exists 查詢已得到增強，包含稀疏向量。這是另一個例子，說明圍繞實際向量搜索的服務(wù)范圍在實踐中與搜索本身同樣重要。我們發(fā)現(xiàn)用戶有時使用 ELSER 模型獲取文檔，然后只想重新運行一小部分沒有填充稀疏向量的文檔。 Exists 查詢對此會很方便。

波斯語（Persian）詞干分析器

用戶可以使用 Elasticsearch 支持的語言分析器插件來執(zhí)行語言分析。然而，如果 Elasticsearch 已經(jīng)附帶了該插件，那就更容易了，因此我們添加了對波斯語詞干分析器插件的支持。

默認情況下，密集向量字段類型被用于建立索引

我們正在采取行動，使密集向量搜索的使用變得更簡單、更容易。作為其中的一部分，我們默認對密集向量字段進行了索引。這是管理員需要執(zhí)行的另一項操作，我們可以消除該操作，因為向量很少不需要索引。此外，我們現(xiàn)在將根據(jù)第一個索引向量動態(tài)選擇正確的維度數(shù)。更少的配置，更少的麻煩。當然，專家仍然可以利用全套現(xiàn)有選項。