作者：來自 Elastic Tyler Perkins, Kostas Krikellas 及 Julian Kiryakov

探索Elasticsearch9.2 中對 ES|QL 的三個獨立更新：增強的 LOOKUP JOIN 用於更具表現力的數據關聯、新的 TS 命令用於時間序列分析，以及靈活的 INLINE STATS 命令用於聚合。

動手體驗 Elasticsearch：深入我們的示例 notebooks，開始免費雲試用，或在本地機器上試用 Elastic。

Elasticsearch 9.2 於十月發佈，包含大量重要改進，使數據分析比以往更快、更靈活、也更容易使用。本次發佈的核心是對ES|QL（我們的管道查詢語言）的重要增強，旨在為終端用户直接帶來更多價值。

以下是 Elasticsearch 9.2 中能通過 ES|QL 改變你數據分析工作流的功能。

革新數據關聯：更智能、更快、更靈活的 Lookup Join

ES | QL 中的LOOKUP JOIN命令在 Elasticsearch 9.2 中經歷了重大變革，變得更加高效和多功能。LOOKUP JOIN 將 ES | QL 查詢結果表與指定 lookup 模式索引中匹配的記錄進行組合，根據連接字段中的匹配值，將 lookup 索引中的字段作為新列添加到結果表中。此前，數據連接僅限於單字段和簡單等值匹配。但現在不再是這樣了！這些增強讓你可以輕鬆處理複雜的數據關聯場景。

Lookup Join 的主要增強包括：

• 多字段連接：輕鬆在多個字段上進行連接。例如，將 application_logs 與 service_registry 按 service_name、environment 和 version 進行連接：

FROM application_logs
| LOOKUP JOIN service_registry ON service_name, environment, version

• 使用表達式釋放複雜連接謂詞（技術預覽）：

你不再被限制於簡單的等值匹配。LOOKUP JOIN 現在允許你為關聯指定多個條件，並使用一系列二元運算符，包括 ==、!=、<、>、<= 和 >=。這意味着你可以創建非常細緻的連接條件，從而能夠對數據提出更加複雜的問題。

示例 1：查找帶有每個服務 SLA 閾值的應用指標

FROM application_metrics
| LOOKUP JOIN sla_thresholds
      ON service_name == sla_service AND response_time > sla_response_time

示例 2：此查詢根據隨時間變化的區域定價策略計算應付金額。它基於複雜的日期範圍和等值條件連接三個數據集，以計算最終的 due_amount。第二個 lookup join 使用 meter_readings 索引中的 measurement_date 字段和 customers 索引中的 region_id 字段連接到 pricing_policies 索引，以找到特定區域和 measurement_date 對應的正確定價策略。

FROM meter_readings
| LOOKUP JOIN customers
      ON meter_id
| LOOKUP JOIN pricing_policies
      ON
        region_id == region AND
          measurement_date >= policy_begin_date AND
          measurement_date < policy_end_date
| EVAL due_amount = (kwh_consumed * rate_per_kwh + base_charge) * (1 + tax_rate)
| EVAL period = policy_name
| KEEP customer_name, period, due_amount, measurement_date, kwh_consumed,
    rate_per_kwh, base_charge, tax_rate
| SORT measurement_date

• 過濾連接的巨大性能提升：

我們改進了使用 lookup 表條件進行過濾的 “擴展連接” 性能。擴展連接會為每一行輸入生成多個匹配結果，可能會產生非常大的中間結果集。如果隨後又有過濾條件丟棄其中的許多行，情況會更糟。在 9.2 中，我們通過在對 lookup 數據應用過濾時提前過濾掉不必要的行來優化這些連接，從而避免處理最終會被丟棄的行。在某些場景下，這類連接的速度甚至可以提升到原來的 1000 倍！

當處理 “擴展連接” 時，這種優化至關重要，因為 lookup 可能最初會生成許多潛在匹配。通過智能下推過濾器，僅處理相關數據，大幅減少查詢執行時間，並支持對海量數據進行實時分析。這意味着即使在非常大或複雜的連接操作中，你也能更快獲得洞察。

Lookup Join 跨集羣搜索（CCS）兼容性：

在 8.19 和 9.1 中，Lookup Join 推出 GA 時不支持跨集羣搜索（CCS）。對於在多個集羣上運行的組織，LOOKUP JOIN 在 9.2 中現在可以無縫集成 CCS。只需將你的 lookup 索引放在所有希望執行連接的遠程集羣上，ES | QL 會自動利用這些遠程 lookup 索引與遠程數據進行連接。這簡化了分佈式數據分析，並確保在整個 Elasticsearch 部署中實現一致的數據豐富。

這些改進意味着你可以以前所未有的精度、速度和便捷性關聯多樣化數據集，發現更深層、更可操作的洞察，而無需複雜的變通方法或預處理步驟。

輕鬆豐富你的數據：Kibana Discover 對 Lookup 索引的用户體驗

數據豐富應該簡單，而不是障礙。我們在 Kibana 的 Discover 中引入了一個出色的新用户體驗，用於創建和管理 lookup 索引。

直觀的工作流程：Discover 的完整自動補全會引導你完成整個過程，在 ES | QL 編輯器中建議 lookup 索引和連接字段，讓你輕鬆將上傳的數據與現有索引連接。輸入不存在的 lookup 索引名稱，只需點擊一次即可直接進入 Lookup 編輯器創建索引。輸入已有 lookup 索引名稱，我們會建議編輯選項：

行內管理（CRUD）：在 Discover 中直接使用行內編輯功能（創建、讀取、更新、刪除），保持你的參考數據集最新。

輕鬆文件上傳：現在你可以在 Discover 中直接上傳文件，例如 CSV，並立即在你的 LOOKUP JOIN 中使用。無需再在 Kibana 的不同區域來回切換上下文！

無論你是在將用户 ID 映射到名稱、添加業務元數據，還是連接靜態參考文件，這個功能都讓數據豐富更加普及，將連接的能力直接交到每個用户手中 —— 快速、簡單、集中操作。

保留你的上下文：推出 INLINE STATS（技術預覽）

聚合數據很重要，但有時你需要同時查看聚合結果和原始數據。我們很高興將 INLINE STATS 作為技術預覽功能推出。

與會用聚合輸出替換輸入字段的 STATS 命令不同，INLINE STATS 保留所有原始輸入字段，只是添加新的聚合字段。這使你在聚合後可以對原始輸入字段執行進一步操作，提供更連續、更靈活的分析工作流。

例如，在保留單個航班行的同時計算平均航程：

FROM kibana_sample_data_flights
 | KEEP Carrier, Dest, DistanceMiles
 | INLINE STATS avgDist = ROUND(AVG(DistanceMiles))
       BY Dest
 | WHERE DistanceMiles > avgDist

在此查詢中，avgDist 被添加到每一行對應的 Dest（目的地）分組中，然後，因為我們仍保留航班信息列，所以可以篩選出距離大於平均值的航班。

ES|QL 中的時間序列支持（技術預覽）

Elasticsearch 使用時間序列數據流來存儲指標。我們通過TSsource 命令為 ES|QL 添加了時間序列聚合支持。這在 Elastic Cloudserverless和 9.2 basic 中作為技術預覽提供。

時間序列分析主要基於聚合查詢，通過時間桶彙總指標值，並按一個或多個過濾維度切分。大多數聚合查詢依賴兩步處理，(a) 內部聚合函數按時間序列彙總數值，(b) 外部聚合函數將 (a) 的結果跨時間序列組合。

TSsource 命令結合STATS提供了一種簡潔而有效的方式來表達時間序列查詢。更具體地，考慮以下示例，用於計算每個主機每小時的請求總率：

TS my_metrics
| WHERE @timestamp > NOW() - 1 day
| STATS SUM(RATE(requests))
      BY host, TBUCKET(1h)

在這種情況下，時間序列聚合函數 RATE 首先按時間序列和小時進行評估。生成的部分聚合結果隨後使用 SUM 組合，以計算每個主機每小時的最終聚合值。

你可以在這裏查看可用的時間序列聚合函數列表。counterrate 現在得到支持，這可以説是處理計數器時最重要的聚合函數。

TS source 命令設計為與 STATS 結合使用，其執行經過優化以高效支持時間序列聚合。例如，數據在進入 STATS 之前會先進行排序。可能豐富或更改時間序列數據或其順序的處理命令，如 FORK 或 INLINE STATS，目前不允許在 TS 和 STATS 之間使用。此限制未來可能會取消。

STATS 的表格輸出可以進一步使用任何適用命令處理。例如，以下查詢計算每個主機每小時的平均 cpu_usage 與每個主機最大值的比率：

TS my_metrics
| STATS avg_usage = AVG(AVG_OVER_TIME(cpu_usage))
      BY host, time_bucket = TBUCKET(1h)
| INLINE STATS max_avg_usage = MAX(avg_usage)
      BY host
| EVAL ratio = avg_usage / max_avg_usage
| KEEP host, time_bucket, ratio
| SORT host, time_bucket DESC

時間序列數據存儲在我們基於 Lucene doc values 的底層列式存儲引擎上。TS 命令通過 ES|QL 計算引擎增加了向量化查詢執行。與等效的DSL查詢相比，查詢性能通常提高一個數量級以上，且與成熟的指標專用系統相當。我們將在未來提供詳細的架構和性能分析，敬請關注。

擴展你的工具箱：新的 ES|QL 函數

為了進一步增強 ES | QL 的實用性和多功能性，我們增加了一套新函數：

字符串處理：CONTAINS、MV_CONTAINS、URL_ENCODE、URL_ENCODE_COMPONENT、URL_DECODE，用於更強大的文本和 URL 處理。

時間序列與地理空間：TBUCKET用於靈活的時間分桶，TO_DENSE_VECTOR 用於向量操作，以及一整套地理空間函數，如 ST_GEOHASH、ST_GEOTILE、ST_GEOHEX、TO_GEOHASH、TO_GEOTILE、TO_GEOHEX，用於高級基於位置的分析。

日期格式化：DAY_NAME、MONTH_NAME，用於更易讀的日期表示。

這些函數為你提供了更豐富的工具集，可在 ES | QL 中直接操作和分析數據。

底層優化：更多性能和效率

除了突出功能之外，Elasticsearch 9.2 在 ES|QL 中還包含了大量性能優化。我們通過下推優化加速了 RLIKE (LIST)，在函數替換多個相似 RLIKE 查詢的情況下可將這些查詢合併為單個自動機，並應用一個自動機而非多個。我們還加快了帶索引排序的 keyword 字段加載，以及一般查詢優化——這些改進確保你的 ES | QL 查詢比以往更高效。

立即開始體驗！

Elasticsearch 9.2 對 ES | QL 是一次重大飛躍，為你的數據分析工作流帶來前所未有的強大和靈活性。我們鼓勵你探索這些新功能，體驗它們帶來的不同。

有關 Elasticsearch 9.2 中所有更改和增強的完整列表，請查閲官方發行説明。祝查詢愉快！

原文：https://www.elastic.co/search-labs/blog/esql-elasticsearch-9-2-multi-field-joins-ts-command