Elasticsearch架構與原理是什么

本篇內(nèi)容介紹了“Elasticsearch架構與原理是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一、引言

隨著移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、云計算等信息技術蓬勃發(fā)展，數(shù)據(jù)量呈爆炸式增長。如今我們可以輕易得從海量數(shù)據(jù)里找到想要的信息，離不開搜索引擎技術的幫助。

作為開源搜索引擎領域排名第一的 Elasticsearch，能夠讓我們無需深入了解背后復雜的信息檢索原理，就可實現(xiàn)基本的全文檢索功能，在數(shù)據(jù)量達到十億，百億規(guī)模仍然可以秒級返回檢索結果。

對于系統(tǒng)容災、數(shù)據(jù)安全性、可擴展性、可維護性等用戶關注的實際問題，在Elasticsearch 上也能得到有效解決。

二、Elasticsearch介紹

Elasticsearch（ES）是一個基于 Lucene 構建的開源分布式搜索分析引擎，可以近實時的索引、檢索數(shù)據(jù)。具備高可靠、易使用、社區(qū)活躍等特點，在全文檢索、日志分析、監(jiān)控分析等場景具有廣泛應用。

由于高可擴展性，集群可擴展至百節(jié)點規(guī)模，處理PB級數(shù)據(jù)。通過簡單的 RESTful API 即可實現(xiàn)寫入、查詢、集群管理等操作。

除了檢索，還提供豐富的統(tǒng)計分析功能。以及官方功能擴展包 XPack 滿足其他需求，如數(shù)據(jù)加密、告警、機器學習等。

另外，可通過自定義插件，如 COS 備份、QQ 分詞等滿足特定功能需求。

1. Elasticsearch 架構與原理

基本概念 ：

• Cluster「集群」：由部署在多個機器的ES節(jié)點組成，以處理較大數(shù)據(jù)集和實現(xiàn)高可用；

• Node「節(jié)點」：機器上的ES進程，可配置不同類型的節(jié)點；

• Master Node「主節(jié)點」：用于集群選主。由其中一個節(jié)點擔任主節(jié)點，負責集群元數(shù)據(jù)管理，如索引創(chuàng)建，節(jié)點離開加入集群等；

• Data Node「數(shù)據(jù)節(jié)點」：負責索引數(shù)據(jù)存儲；

• Index「索引」：索引數(shù)據(jù)的邏輯集合，可類比關系型數(shù)據(jù)的DataBase；

• Shard「分片」：索引數(shù)據(jù)子集，通過將分片分配至集群不同節(jié)點，實現(xiàn)數(shù)據(jù)橫向擴展。以解決單個節(jié)點CPU、內(nèi)存、磁盤處理能力不足的情況；

• Primary Shard「主分片」：數(shù)據(jù)分片采用主從模式，由分片接收索引操作；

• Replica Shard「副本分片」：主分片的拷貝，以提高查詢吞吐量和實現(xiàn)數(shù)據(jù)高可靠。主分片異常時，其中一個副本分片會自動提升為新的主分片。

為了便于大家理解ES里的數(shù)據(jù)模型，將它與關系型數(shù)據(jù)庫 MySQL 做類比：

從上面架構圖可以看出，ES 架構非常簡潔。內(nèi)置自動發(fā)現(xiàn)實現(xiàn) Zen discovery，當一個節(jié)點啟動后，通過聯(lián)系集群成員列表即可加入集群。

由其中一個節(jié)點擔任主節(jié)點，用于集群元數(shù)據(jù)管理，維護分片在節(jié)點間的分配關系。當新節(jié)點加入集群后，Master 節(jié)點會自動遷移部分分片至新節(jié)點，均衡集群負載。

分布式集群難免有節(jié)點故障。主節(jié)點會定期探測集群其他節(jié)點存活狀態(tài)，當節(jié)點故障后，會將節(jié)點移出集群，并自動在其他節(jié)點上恢復故障節(jié)點上的分片。

主分片故障時會提升其中一個副本分片為主分片。其他節(jié)點也會探活主節(jié)點，當主節(jié)點故障后，會觸發(fā)內(nèi)置的類 Raft 協(xié)議選主，并通過設置最少候選主節(jié)點數(shù)，避免集群腦裂。

除了集群管理，索引數(shù)據(jù)讀寫也是我們關心的重要部分。ES 采用 peer-to-peer 架構，每個節(jié)點保存全量分片路由信息，也就是每個節(jié)點均可以接收用戶讀寫。

如發(fā)送寫入請求至節(jié)點 1，寫入請求默認通過文檔 ID 的 Hash 值確定寫入到哪個主分片，這里假設寫入到分片 0。

寫完主分片 P0，并行轉發(fā)寫入請求至副本分片 R0 所在節(jié)點，當副本分片所在節(jié)點確認寫入成功后返回客戶端報告寫入成功，保障數(shù)據(jù)安全性。并且寫入前，會確保 quorum 數(shù)量的副本數(shù)，避免網(wǎng)絡分區(qū)導致寫入數(shù)據(jù)不一致。

查詢采用分布式搜索，如請求發(fā)給節(jié)點3后，請求會轉發(fā)至索引的主分片或副本分片所在節(jié)點。

當然如果寫入、查詢均帶有路由字段信息。請求只會發(fā)送給部分分片，避免全量分片掃描。這些節(jié)點完成查詢后將結果返回給請求節(jié)點，由請求節(jié)點匯聚各個節(jié)點的結果返回給客戶端。

2. Lucene原理

介紹完 ES 集群基本原理，下面簡單介紹下ES的底層存儲引擎 Lucene。

首先 Lucene 是一款高性能的信息檢索庫，提供索引和檢索基本功能。ES 在此基礎上解決可靠性、分布式集群管理等問題最終形成產(chǎn)品化的全文檢索系統(tǒng)。
Lucene 解決的核心問題便是全文檢索。與傳統(tǒng)的檢索方式不同，全文檢索避免在查詢時進行全部內(nèi)容掃描。

比如數(shù)據(jù)寫入后，首先會對寫入的文檔字段內(nèi)容分詞，形成詞典表和與它關聯(lián)的倒排表。查詢時由關鍵詞分詞結果直接匹配詞典表內(nèi)容，并獲取關聯(lián)的文檔列表，快速獲取結果集。并通過排序規(guī)則，優(yōu)先展示匹配度高的文檔。

Lucene 為了加快索引速度，采用了 LSM Tree 結構，先把索引數(shù)據(jù)緩存在內(nèi)存。當內(nèi)存空間占用較高或到達一定時間后，內(nèi)存中的數(shù)據(jù)會寫入磁盤形成一個數(shù)據(jù)段文件（segment）。段文件內(nèi)包含詞典、倒排表、字段數(shù)據(jù)等等多個文件。

為了兼容寫入性能和數(shù)據(jù)安全性，如避免內(nèi)存緩沖區(qū)里的數(shù)據(jù)因為機器故障丟失。ES 在寫內(nèi)存的同時也會寫事物日志 Translog。內(nèi)存里的數(shù)據(jù)會定期生成新的段文件，寫入開銷更低的文件系統(tǒng)緩存即可打開和讀取實現(xiàn)近實時搜索。

三、ElasticSearch應用場景

ES的典型使用場景有日志分析、時序分析、全文檢索等。

1. 日志實時分析場景

日志是互聯(lián)網(wǎng)行業(yè)基礎廣泛的數(shù)據(jù)形式。典型日志有用來定位業(yè)務問題的運營日志，如慢日志、異常日志；用來分析用戶行為的業(yè)務日志，如用戶的點擊、訪問日志；以及安全行為分析的審計日志等。

Elastic 生態(tài)提供了完整的日志解決方案。通過簡單部署，即可搭建一個完整的日志實時分析服務。ES 生態(tài)完美的解決了日志實時分析場景需求，這也是近幾年 ES 快速發(fā)展的一個重要原因。

日志從產(chǎn)生到可訪問一般在 10s 級，相比于傳統(tǒng)大數(shù)據(jù)解決方案的幾十分鐘、小時級時效性非常高。

ES底層支持倒排索引、列存儲等數(shù)據(jù)結構，使得在日志場景可以利用ES非常靈活的搜索分析能力。通過ES交互式分析能力，即使在萬億級日志的情況下，日志搜索響應時間也是秒級。

日志處理的基本流程包含：日志采集 -> 數(shù)據(jù)清洗 -> 存儲 -> 可視化分析。Elastic Stack通過完整的日志解決方案，幫助用戶完成對日志處理全鏈路管理。

其中：

• 日志采集：通過輕量級日志采集組件FileBeat實時讀取業(yè)務日志文件，發(fā)送數(shù)據(jù)至下游組件如 Logstash。

• 文本解析：利用正則解析等機制，將日志文本數(shù)據(jù)轉換成結構化數(shù)據(jù)?？墒褂锚毩⒌腖ogstash 服務或 Elasticsearch 內(nèi)置的輕量級數(shù)據(jù)處理模塊 Ingest Pipeline，完成數(shù)據(jù)清洗和轉換。

• 數(shù)據(jù)存儲：通過 Elasticsearch 搜索分析平臺進行數(shù)據(jù)持久存儲，提供全文搜索和分析能力。

• 可視化分析：通過功能豐富的圖形界面，即可對日志數(shù)據(jù)進行搜索分析，如可視化組件 Kibana。

2. 時序分析場景

時序數(shù)據(jù)是按時間順序記錄設備、系統(tǒng)狀態(tài)變化的數(shù)據(jù)。典型的時序數(shù)據(jù)有傳統(tǒng)的服務器監(jiān)控指標數(shù)據(jù)、應用系統(tǒng)性能監(jiān)控數(shù)據(jù)、智能硬件、工業(yè)物聯(lián)網(wǎng)傳感器數(shù)據(jù)等。

早在2017年我們也基于ES進行了時序分析場景的探索。時序分析場景具有高并發(fā)寫入、低查詢時延、多維分析的特點。

由于ES具有集群擴展、批量寫入、讀寫帶路由、數(shù)據(jù)分片等能力，目前已實現(xiàn)線上單集群最大規(guī)模達到 600+節(jié)點、1000w/s 的寫入吞吐、單條曲線或單個時間線的查詢延時可控制在 10ms。

ES提供靈活、多維度的統(tǒng)計分析能力，實現(xiàn)查看監(jiān)控按照地域、業(yè)務模塊等靈活的進行統(tǒng)計分析。另外，ES支持列存儲、高壓縮比、副本數(shù)按需調(diào)整等能力，可實現(xiàn)較低存儲成本。最后時序數(shù)據(jù)也可通過Kibana組件輕松實現(xiàn)可視化。

3. 搜索服務場景

搜索服務典型場景有像京東、拼多多、蘑菇街中的商品搜索；應用商店中的應用APP搜索；論壇、在線文檔等站內(nèi)搜索。

這類場景用戶關注高性能、低延遲、高可靠、搜索質(zhì)量等。如單個服務最大需達到 10w+ QPS，請求平均響應時間在 20ms以內(nèi)，查詢毛刺低于 100ms，高可用如搜索場景通常要求 4 個 9 的可用性，支持單機房故障容災等。

目前云上 Elasticsearch 服務已支持多可用區(qū)容災，故障分鐘級恢復能力。通過 ES 高效倒排索引，以及自定義打分、排序能力與豐富的分詞插件，實現(xiàn)全文檢索需求。在開源全文檢索領域，ES 在 DB-Engines 搜索引擎類別持續(xù)多年排名第一。

四、騰訊ElasticSearch服務

騰訊內(nèi)外部均有大量的日志實時分析、時序數(shù)據(jù)分析、全文檢索需求場景。

目前我們已聯(lián)合 Elastic 公司在騰訊云上提供了內(nèi)核增強版 ES 云服務，簡稱CES，其中內(nèi)核增強包括 Xpack 商業(yè)套件和內(nèi)核優(yōu)化。

在服務公司內(nèi)部以及公有云客戶過程中，也遇到了較多問題和挑戰(zhàn)，比如超大規(guī)模集群，千萬級數(shù)據(jù)寫入，以及云上用戶豐富的使用場景等。

下文將介紹我們在內(nèi)核層面，從可用性，性能，成本等方面進行的優(yōu)化措施。

1. 可用性優(yōu)化

可用性 問題表現(xiàn)在三個方面：

（1）ES 內(nèi)核系統(tǒng)健壯性不足 

這也是分布式系統(tǒng)共性難題。例如異常查詢、壓力過載集群容易出現(xiàn)雪崩。集群可擴展性不足，比如集群分片數(shù)超10w會出現(xiàn)明顯的元數(shù)據(jù)管理瓶頸。以及集群擴容、節(jié)點異常后加回集群，存在節(jié)點、多硬盤之間數(shù)據(jù)不均問題。

（2）容災方案欠缺

需保障機房網(wǎng)絡故障時可快速恢復服務，自然災害下防止數(shù)據(jù)丟失，誤操作后快速恢復數(shù)據(jù)等可靠性、數(shù)據(jù)安全性問題。

（3）系統(tǒng)缺陷

另外也包括在運營過程中發(fā)現(xiàn)的一些 ES 系統(tǒng)缺陷 ，比如說 Master 節(jié)點堵塞、分布式死鎖、滾動重啟緩慢等。

針對上面的問題，在系統(tǒng)健壯性方面，我們通過服務限流，容忍機器網(wǎng)絡故障、異常查詢等導致的服務不穩(wěn)定問題。

通過優(yōu)化集群元數(shù)據(jù)管理邏輯，提升集群擴展能力一個數(shù)量級，支持千級節(jié)點集群、百萬級分片數(shù)。集群均衡方面，通過優(yōu)化節(jié)點、多硬盤間的分片均衡，保證大規(guī)模集群的壓力均衡。

容災方案 方面，我們通過擴展 ES 的插件機制實現(xiàn)數(shù)據(jù)備份和回檔，可把 ES 的數(shù)據(jù)備份到 COS，保障數(shù)據(jù)安全性；通過管控系統(tǒng)建設支持跨可用區(qū)容災，用戶可以按需部署多個可用區(qū)，以容忍單機房故障。采用垃圾桶機制，保證用戶在欠費、誤操作等場景下，集群數(shù)據(jù)可快速恢復。

系統(tǒng)缺陷方面，我們修復了滾動重啟、Master 阻塞、分布式死鎖等一系列 Bug。其中滾動重啟優(yōu)化，可加速節(jié)點重啟速度 5+倍。Master 堵塞問題，我們在 ES 6.x 版本和官方一起做了優(yōu)化。

2. 性能優(yōu)化

性能問題，比如以日志、監(jiān)控為代表的時序場景，對寫入性能要求非常高，寫入并發(fā)可達 1000w/s。然而我們發(fā)現(xiàn)在帶主鍵寫入時，ES 性能會衰減 1+倍。

壓測場景下發(fā)現(xiàn)CPU 存在無法充分利用的情況。通常搜索服務對查詢性要求非常高，一般要求 20w QPS, 平均響應時間小于 20ms，并且需盡量避免 GC、以及執(zhí)行計劃不優(yōu)等造成的查詢毛刺問題。

為了解決這些問題。寫入方面，針對主鍵去重場景，我們通過利用段文件上記錄的最大最小值進行查詢裁剪，加速主鍵去重的過程，寫入性能提升 45%，具體可參考 Lucene-8980[1]。

對于壓測場景下 CPU 不能充分利用的問題，通過優(yōu)化 ES 刷新 Translog 時鎖粒度，避免資源搶占，提升性能提升 20%，具體可參考ES-45765 /47790[2]。我們也正在嘗試通過向量化執(zhí)行優(yōu)化寫入性能，通過減少分支跳轉、指令 Miss，預期寫入性能可提升 1 倍。

查詢方面，我們通過優(yōu)化段文件合并策略，對于非活躍段文件會自動觸發(fā)合并，收斂段文件數(shù)以降低資源開銷，提升查詢性能。

根據(jù)每個段文件上記錄的最大最小值進行查詢剪枝，提升查詢性能 40%。通過 CBO 策略，避免緩存較大開銷的 Cache 操作導致產(chǎn)生 10+倍的查詢毛刺，具體可參考Lucene-9002[3]。

另外還包括優(yōu)化 Composite 聚合中的性能問題，實現(xiàn)真正的翻頁操作，以及優(yōu)化帶排序場景的聚合使得性能提升3-7倍。此外，我們也在嘗試通過一些新硬件來優(yōu)化性能，比如說英特爾的 AEP、Optane、QAT 等。

3. 成本優(yōu)化

成本方面主要體現(xiàn)在以日志、監(jiān)控為代表的時序場景對機器資源的消耗。結合線上典型的日志、時序業(yè)務統(tǒng)計數(shù)據(jù)發(fā)現(xiàn)，硬盤、內(nèi)存、計算資源的成本比例接近 8:4:1。

可以得出硬盤、內(nèi)存是主要矛盾，其次是計算成本。而這類時序類場景有很明顯的訪問特性，也就是數(shù)據(jù)具有冷熱特性。

時序數(shù)據(jù)訪問具有近多遠少的特點，比如近 7 天數(shù)據(jù)的訪問量占比可達到 95%以上，而歷史數(shù)據(jù)訪問較少，并且通常都是訪問統(tǒng)計類信息。

硬盤成本方面，由于數(shù)據(jù)具有明顯的冷熱特性，我們采用冷熱分離架構，使用混合存儲的方案來平衡成本和性能。

由于歷史數(shù)據(jù)通常只是訪問統(tǒng)計信息，我們采用預計算 Rollup 換取存儲和查詢性能，類似物化視圖。對于完全不使用歷史數(shù)據(jù)，也可以備份到更廉價的存儲系統(tǒng)如 COS。其他一些優(yōu)化方式包括多盤策略兼容數(shù)據(jù)吞吐與數(shù)據(jù)容災，以及通過生命周期管理等定期刪除過期數(shù)據(jù)等。

內(nèi)存成本 方面，我們發(fā)現(xiàn)特別是大存儲機型，存儲資源才用了 20% 內(nèi)存已不足。為了解決內(nèi)存不足問題，我們采用 Off-Heap 技術，來提升堆內(nèi)內(nèi)存利用率，降低 GC 開銷，并且提升單個節(jié)點管理磁盤的能力。

將內(nèi)存占比較大的 FST 移到堆外管理，通過堆內(nèi)存放堆外對象地址，避免堆內(nèi)外數(shù)據(jù)拷貝。通過 Java 弱引用機制實現(xiàn)堆外對象內(nèi)存回收，進一步提升內(nèi)存使用率。

實現(xiàn) 32GB 堆內(nèi)內(nèi)存可管理 50 TB 左右磁盤空間，較原生版本有 10 倍提升，并且性能持平，而 GC 優(yōu)勢提升明顯。
除了內(nèi)核層面的優(yōu)化，在平臺層通過管控平臺，支持云上服務資源管理、實例實例管理等實現(xiàn)服務托管。方便快捷進行實例創(chuàng)建和規(guī)格調(diào)整。

通過運維支撐平臺中的監(jiān)控系統(tǒng)、運維工具等保障服務質(zhì)量。并通過正在建設的智能診斷平臺發(fā)現(xiàn)服務潛在問題，實現(xiàn)了對內(nèi)外部提供穩(wěn)定可靠的 ES 服務。

“Elasticsearch架構與原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！