基於 Elasticsearch 的指標可觀測實踐

分享嘉賓：魏子珺 阿里雲 ES 內核專家

編輯整理：陳凱翔 亞廈股份

出品平臺：DataFunTalk

導讀： 大家好，我是來自阿里巴巴的魏子珺，今天給大家分享的主題是基於 Elasticsearch 的指標可觀測實踐。主要包括以下幾部分內容：

• Elasticsearch 爲什麼做時序引擎

• Elasticsearch 做時序引擎的挑戰

• Elasticsearch 時序引擎特性介紹

• 阿里雲基於 Elasticsearch TimeStream 介紹

01 Elasticsearch 爲什麼做時序引擎

首先看一下 Elasticsearch 爲什麼要做時序引擎。

故事要從阿里雲和 ES（後面文章 Elasticsearch 統一簡稱 ES）社區的一次溝通會議說起，當時我們在溝通一些 ES 內核方面的問題，共同說到了 ES 做指標存儲的痛點， ES 社區當時已經開始設計時序引擎的文檔，我們也在阿里雲內部監控發現了很多 ES 做存儲指標的問題。於是雙方一拍即合，開始共同建設時序引擎這個項目。時序引擎相關的 Issue：_https://github.com/elastic/elasticsearch/issues/74660，_記錄了所有時序引擎相關的 TODO list。

說到 ES 做時序引擎，用戶們通常會有下面兩種對立的聲音：

一種是怎麼能用 ES 做時序引擎？ 肯定要用專業的時序引擎，他們可能不知道 ES 爲什麼不能做時序引擎，只是覺得專業的事情要交給專業的人去做。

另外一種是 ES 本來就可以做時序引擎，爲什麼還要開發？ 這些用戶可能已經把 ES 用作了時序引擎的場景。

那麼用 ES 做時序引擎到底會有什麼問題？本文就爲大家解開謎題。

時序引擎有兩大主流的場景：

一類是用作監控，這也是可觀察性的一個方向，所以這也是 ES 的核心戰場。

另一類是用作 IOT 場景，IOT 場景有大量的設備會產生大量的指標，所以需要一個時序數據庫來存儲這些數據。

下面簡單介紹一下時序引擎。時序引擎應對的是一種特點非常鮮明的場景。

首先，它存儲的是採樣數據，採樣數據是基於穩定頻率持續產生的一系列數據，相對應的是基於事件產生的數據，事件型數據是離散、隨機產生的，而採樣型數據是穩定的，持續產生的。

第二個特點是時序引擎的數據模型非常固定，一般都由時間、維度、指標三類字段組成。

第三個特點是時間線的概念，圖中的縱座標是時間線 id，他是由維度組成的，一般是保持不變的。橫座標是指標數據，會隨着時間不停的變化，這就組成了時間線的概念。

第四個特點，時序引擎存儲的數據沒有波峯波谷，7*24 小時都在穩定的產生數據，跟他相對應的事件型數據一般根據業務的高峯低峯會有起伏。

第五個特點是時序引擎是垂直寫，水平查，始終都在寫最新的數據，查詢會基於一個時間段去做一些聚合型的分析。

基於時序引擎鮮明的特點，時序引擎主要有下面幾個需求：

• 在寫入方面， 時序引擎需要支持高 TPS 寫入，因爲他面對的場景無論是監控還是 IOT 都有大量的設備在持續不斷的產生數據。

• 第二點是查詢方面， 時序引擎一般都是針對大量的數據去做多維度聚合，而不是單純去查某一些點的數據。

• 第三是成本方面，由於時序引擎寫入量非常大，所以存儲在時序引擎上的數據量是非常大的，一般來說數據重複度非常高，而且特點也很鮮明，所以針對性做一些壓縮可以極大的降低這部分數據的存儲成本。

針對上面的需求，時序引擎需要三大關鍵能力：

• 首先是列式存儲，跟他相對的是行式存儲，由於時序引擎一般都是分析型需求，而且都是對單個指標的查詢，所以如果用行式存儲的話會有大量的無效 IO，所以一般都得使用列式存儲，而且列式存儲對壓縮也非常友好，這就是爲什麼很多早期時序引擎都是基於 HBase 構建的。

• 第二個關鍵能力是類 LSM 數據結構，這類數據結構可以很好地支持高吞吐量的寫入。

• 第三個是聚合分析，對時序引擎的查詢都是一些分析型的需求，所以需要時序引擎支持很好的分析能力，早期的 HBase 不支持分析，所以都是時序引擎在 HBase 之上做了支持分析的能力。

這三類能力 ES 都是具備的，所以說 ES 沒有道理不去做時序引擎。

02 Elasticsearch 做時序引擎的挑戰

接下來介紹一下用 ES 做時序引擎的挑戰。

目前用 ES 做時序引擎會面臨三類痛點：使用門檻過高，查詢慢且複雜，以及成本過大。

由於 ES 的定位還是一個通用的搜索引擎，所以用戶如果想把 ES 用作時序引擎的最佳實踐，需要對 ES 有深入瞭解，做很多定製化的優化和在業務側做很多開發才能使用，圖中列出來的這些內容就是 ES 做時序引擎的最佳實踐。

第二個是查詢方面的問題，下面用兩個例子來看這個問題，這是一個查看指標 up 監控曲線的需求，PromQL 只需要一個 “up” 關鍵字就可以完成這個需求，對 ES 來說他的 DSL 需要寫 quary、 aggs 等複雜的語法才能夠完成。

第二個例子，按集羣維度查看 index_qps 監控曲線，對 PromQL 來說，先對指標做一次 rate，再對 cluster 做一次 sum by 就可以完成這個需求，而對 ES 來說，需要寫 query 和很複雜的 aggs，甚至還用到了 ES 最複雜的 pipeline aggs，功能雖然 OK，但性能非常低下。

再看成本過大的問題，InfluxDB 官方給出了 ES 做時序引擎的 benchmark 的對比，這裏貼出來了一個存儲容量對比的結果，可以看到存同樣的數據存儲 ES 容量是 InfluxDB 的 12 倍。

我們也用阿里雲監控存儲 ES 的數據來進行了對比，可以看到更誇張的結果，ES 是 InfluxDB 存儲容量的 74 倍，即使 ES 做了在時序場景的最佳實踐，容量減半，也還是 InfluxDB 的 30 多倍。

所以可以看到包括使用門檻，查詢、容量的問題，這些雖然都不影響功能，但是相比其他的時序引擎，他的缺點就非常明顯，這也回答了前面的問題，ES 也能做時序引擎，但是效率非常的低下。

03 Elasticsearch 時序引擎特性介紹

接下來看 ES 時序引擎項目，以及阿里雲 ES TimeStream 怎麼解決這些問題。先來看下社區的優化。

關於 Index Level 的優化，這裏列出了 ES 做時序引擎的幾個優化的關鍵點：

• Setting 中增加了一個 index.mode=time_series 的設置，這個設置告訴 ES 在內部去實現時序場景的最佳實踐。這個配置要結合一些其他配置一起生效。

• Mapping 字段配置增加了 2 個關鍵字：time_series_dimension 和 time_series_metric， 這兩個設置是爲了告訴 ES 哪些字段用作維度字段，哪些字段用作指標字段，有這兩個配置再結合 index.mode=time_series，ES 會把所有的維度字段生成一個_tsid（時間線 ID）內部字段，用_tsid 和 timestamp 去做 index sorting。

• 最下面可以看到一個 @timestamp 的字段，如果設置了 index.mode=time_series 時，這個字段是無需設置的，索引會自動生成一個 @timestamp 的時間字段。

• 中間 Mapping 裏面還有一個**” {"_source":{"syntheic":true}}” 的設置**，這個設置可以告訴 ES 可以無需存原始數據_source。需要看明細數據時，ES 內部使用列式存儲的 docvalues 數據生成原始的_source，這樣就可以極大地節省了 ES 的存儲空間。

ES 的另一個優化，是使用 TSDS 作爲時序場景的使用方式，TSDS 全稱是 Time Series DataStream。DataStream 是對 index 做的一層封裝，主要解決的是 ES 索引無限膨脹，以及無法過期歷史數據等問題。TSDS 相比普通的 DataStream 主要區別是時間分區的優化，普通的 DataStream 索引在寫入數據的時候，無論是新數據還是老數據，寫入的時候始終都是寫入最新的是索引。這樣在時序引擎場景中就會帶來一個問題，當要對數據按時間分桶的時候，桶內的數據可能會出現在所有的索引中。這裏 ES 對時間分區做了優化，效果是寫入的數據按照時間字段進行索引分區。

實現方法如下：

• 索引 Settings 增加了 index.time_series.start_time, index.time_series.end_time 兩個配置。start_time 用來標識索引的起始時間，end_time 標識結束時間，索引只允許在時間範圍內的數據寫入，其中 start_time 是 final 類型不能修改，end_time 可以動態修改，但是隻能修改爲比當前值大的 value。

• DataStream 發現索引模板中配置的是 time_series 索引，則會自動生成索引的 start_time 和 end_time。DataStream 做 rollover 的時候，上一個索引的 end_time，設置爲下一個索引的 start_time，這樣索引不斷增加時，索引之間在時間上是無縫銜接的。

TSDS 有了時間分區，在做時間範圍查詢時，只要查詢對應時間範圍的索引即可，而且 TSDS 的時間分區，相比普通按天、月、年等固定分區，它是一個彈性分區，可以更好地控制索引元數據數量。

04 阿里雲 Elasticsearch TimeStream 介紹

下面介紹一下阿里雲 ES TimeStream 如何解決 ES 做時序引擎的問題。

阿里雲 ES TimeStream，是阿里雲基於 ES 自研的時序引擎，其核心目標主要有下面三個：

• 進一步降低了 ES 用做時序引擎的使用門檻

• TimeStream 結合阿里雲 ES 內核來進一步的降本增效

• TimeStream 能夠和更多的系統直接集成。

在 TimeStream 內部定義了時序模型，包括：labels，metrics 和 timestamp 三種類型的字段，在創建 TimeStream 索引的時候直接使用命令 “PUT _time_stream/{name}” 即可，如果想做更復雜的配置可以使用 ES template 的語法。如果想自定義時序模型，那麼在創建 TimeStream 索引時也可以自定義 labels 和 metrics。

TimeStream 索引讀寫數據的方式跟正常索引一樣，直接使用 ES 原生 API 即可。

再來看一下 TimeStream 如何降本增效。

前文提到 ES 存儲空間是 InfluxDB 的 74 倍，我們進一步分析 ES 數據存儲的佔比是怎麼樣的，發現了兩大可以優化的點：

• 首先是在 ES 做時序場景的數據壓縮方面有所欠缺，所以 TimeStream 在數據壓縮上可以極大地降低佔用空間。

• 另一點我們發現 ES 存儲時序數據時，存儲空間主要來自於元數據字段，如_id, _source 等，把這些字段去掉，再通過一些自動生成的方式滿足查詢需求。

通過數據壓縮和減少元數據存儲可以極大的降低存儲空間。

來看一下做了這兩部分優化的效果：

存儲空間在使用了壓縮之後直接從 1900 多 MB 降到了 1100MB 多兆，這降低的 800 多 MB 的空間，基本上都是元數據的開銷了。我們再將_id 和_source 去掉之後，又進一步降低到了 200 多 MB，可以看到 ES 經過優化以後存儲空間已經和 InfluxDB 接近了，在某些場景上會表現的比 InfluxDB 更好。

降本增效另一大關鍵特性是支持 DownSample（降採樣），DownSample 功能通過降低數據的精度，達到降低存儲容量，提升查詢性能的目的。TimeStream 內部直接集成了 DownSample 功能，在創建索引的時候直接指定 DownSample 精度，圖上示例中給出的精度包括 1 分鐘，10 分鐘，60 分鐘，用戶在寫入原始數據的時候，TimeStream 內部還會生成相應的三種精度索引。

用戶在查詢原始數據的時候，TimeStream 內部會根據 interval（DSL 中 date_histogram 的 interval 參數）決定到底該使用什麼索引，這時候用戶查到的並不是原始索引，而是 interval 能滿足的最粗精度的索引。由於數據量比原始精度小了很多，查詢速度也快了很多。

DownSample 能降低存儲空間，原因是使用 DownSample 後，原始索引就不需要保存那麼長時間了，這樣整體存儲空間就能得到極大的下降。

下面我們來看一下 DownSample 的查詢效果：

圖中有 4 個查詢 Case，可以看到，如果查詢到了 DownSample 的索引，性能相比原始索引有了質的提升。圖中也對比了 CK 和 InfluxDB 的查詢性能，可以看到 ES 的查詢性能是比 InfluxDB 好的，跟 CK 相比，部分查詢性能優於 CK。

TimeStream 的第三大特性是集成方面，目前 TimeStream 支持了跟 Prometheus 和 Grafana 的集成，TimeStream 支持了 Prometheus 的 remote write 接口，這樣可以直接將 Prometheus 數據同步到 ES，作爲 Prometheus 的一個分佈式、高可用的遠端存儲來使用。然後在 Grafana 直接使用 Prometheus 的數據源來訪問 ES。

下面看一些示例，用戶在選擇 DataSource 的時候，需要選擇的是 Prometheus 的 DataSource，地址填寫的是 ES 對應的集羣地址。這樣可以直接像訪問 Prometheus 一樣訪問 ES。

如果用戶用了一些開源的 Exporter 導入數據，在 Grafana 直接導入開源 Exporter 對應的 Dashboard 即可訪問這些數據，與訪問原生 Prometheus 的體驗是一模一樣的。下面的截圖也可以看到 ES TimeStream 可以支持非常複雜的 PromQL，目前時序場景絕大部分的 PromQL，常用的 function，aggregation 都支持。

以上就是阿里雲 ES TimeStream 的介紹，目前 ES TimeStream 已經在官網上線，更多詳細的功能大家可以在阿里雲 ES 官方文檔中看到。

官方文檔：

https://help.aliyun.com/document_detail/436120.html

最後總結一下用 ES 做時序引擎。ES 時序引擎項目補齊了 ES 存儲和查詢時序數據的短板，讓 ES 可以作爲專業的時序引擎使用。

ES 還不止於時序引擎，其優勢主要在以下三個方面：

• 系統方面：它是分佈式、高可用、高可靠、彈性、分層存儲、數據備份等功能非常健全的系統；

• 產品方面：整個 Elastic Stack 技術棧是一個非常完善、豐富的產品；

• 領域方面：支持搜索、可觀察性和安全三大領域。

今天的分享就到這裏，謝謝大家。

分享嘉賓

魏子珺

阿里雲 Elasticsearch 內核專家

阿里巴巴技術專家，阿里雲 Elasticsearch 內核專家，Elasticsearch Top 100 Contributer。

DataFun： 專注於大數據、人工智能技術應用的分享與交流。發起於 2017 年，在北京、上海、深圳、杭州等城市舉辦超過 100 + 線下和 100 + 線上沙龍、論壇及峯會，已邀請超過 2000 位專家和學者參與分享。其公衆號 DataFunTalk 累計生產原創文章 700+，百萬 + 閱讀，14 萬 + 精準粉絲。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fbcMOQm4eseBpTx8M3hHfw