本文作者：廣富 — 阿里巴巴 Elasticsearch 高級開發工程師
簡述：
阿里雲 Elasticsearch 雲服務平臺（以下簡稱“阿里雲ES”）是阿里雲依託於雲上豐富的雲計算資源，向用戶推出的託管的 Elastic Stack 服務，目前已在全球部署了17個地域，存儲了 PB 級以上的數據量。本文將揭祕阿里雲在面對 PB 級數據量挑戰下所做的內核優化實踐。
一、阿里巴巴 Elasticsearch 雲服務平臺
阿里雲 Elasticsearch 主要包括開源系統和自研系統兩部分。開源系統依託於阿里雲豐富的雲計算資源，如 ECS, VPC, SLB 等，在此基礎之上不僅向用戶提供了 Elasticsearch, Kibana, Logstash, Beats 等 Elastic Stack 相關組件，還與 Elastic 官方合作向用戶提供 免費白金版 X-Pack 商業套件， 用戶可以在商業套件上體驗如 Security, Altering, Monitoring, Graph, Reporting, MachineLearning 等高級特性。
在開源系統的基礎之上， 阿里雲ES還提供了自研系統。自研系統部分主要包括 Elasticsearch 增強優化，Eyou 智能診斷系統和 ElasticFlow 離線數據處理平臺等。其中 Elasticsearch 增強優化是阿里雲在原生 Elasticsearch 基礎之上，藉助雲計算和自研能力，為 Elasticsearch 集群增加了彈性伸縮，冷熱數據分離，高可用，向量檢索，中文分詞等功能，可以幫助用戶輕鬆應對業務壓力，集群成本，數據可靠性，查詢效果等問題。智能診斷系統 Eyou 可以智能地對用戶的集群進行診斷，及時發現集群潛在隱患，並對用戶集群給出合理的優化建議。
ElasticFlow 離線數據處理平臺致力於解決如全量數據寫入和複雜處理邏輯實時寫入等情況下的業務瓶頸，為用戶集群遷移，數據再處理，實時寫入性能優化等提供了新的解決方案。
阿里雲 Elasticsearch 致力於打造基於開源生態的，低成本的，場景化的雲上 Elasticsearch 解決方案，源於開源，又不止於開源,目前已經覆蓋了全部阿里雲數據中心，並支持本地化專用雲交付和混合雲方案。
二、阿里雲 Elasticsearch 內核優化實踐
阿里雲在內核優化方面的實踐主要分為通用增強和場景化內核兩部分。通用增強針對於通用的Elasticsearch場景進行優化，主要包括性能優化，高可用方案，穩定性保障和成本優化等。場景化內核當前已經提供了對日誌場景，搜索場景，時序場景進行的優化，後續會不斷持續地推出更多場景優化方案。
三、通用增強 - 性能優化
離線數據處理平臺
為了解決全量數據寫入和複雜數據處理邏輯實時寫入等場景的業務痛點，阿里雲ES推出了離線數據處理平臺ElasticFlow。
原生Elasticsearch集群在進行數據導入，集群遷移等全量數據寫入操作時，集群的讀寫性能會受到較大影響，且由於全量寫入數據較多處理時間較長，當面臨海量數據時，耗時往往無法接受。 Elastic Flow 針對於這種場景推出了全量 ElasticBuild。
當用戶需要將數據從 RDS, ODPS, SLS, KAFKA, ES 等其他數據存儲組件遷移到新的 Elasticsearch 集群時，可以先將數據流接入 ElasticBuild。ElasticBuild 底層使用 Blink，對導入的數據進行併發索引構建。接著將構建好的索引文件存儲在 OSS 中。目標集群通過原生 Elasticsearch 的 Snapshot restore 操作即可快速地完成數據導入。
全量 Elastic Build 由於在集群外部進行，因此索引構建過程對集群讀寫性能無影響，且由於使用 blink 將索引構建過程並發起來，並通過內存索引合併減少磁盤IO, 從而大大降低了索引構建時間，加快索了引構建速度，對於解決海量數據全量導入耗時過長問題效果顯著。
將索引構建操作移到集群外部進行，雖然解決全量數據寫入的性能問題，但無法使用 Elasticsearch 原生的 translog 來解決 failover 問題。對此， ElasticFlow 使用了 Blink 的 checkpoint 來實現
failover，相對於 translog 降低了一倍的 IO 開銷，並可以實現 At Least Once 數據準確和秒級 Failover。
針對於複雜處理邏輯實時寫入場景，ElasticFlow 推出了增量 ElasticBuild，通過將處理邏輯移至集群外部進行，減少 client node 的計算和網絡開銷。
Elastic Flow 離線數據處理平臺充分利用阿里雲在大數據處理的優勢，通過優化全量 Build 相對於在線 build 性能提升3倍，增量數據 build 相對於實時寫入性能提升了30%。
通用物理複製
原生 Elasticsearch 在進行寫操作時，主副分片都需要進行寫 translog 和寫索引操作。寫 translog 是為了保證數據的高可用，主副分片都需要單獨保證。但是索引構建和 segment merge 等操作不一定需要主副分片分別重複執行。基於這種思想，我們推出了物理複製功能。
物理複製的基本原理是：Elasticsearch 主分片寫入機制與原生 Elasticsearch 一樣，既寫索引文件也寫 translog，而副本分片只寫 translog 以保證數據的可靠性和一致性。主分片在每次 refresh 時，通過網絡將增量的索引文件拷貝到副本分片，在主副分片分配可見性延遲略增加的情況下，大幅度提高了集群的寫入性能。我們使用 esrally 自帶的 nyc_taixs 數據集對 8 核 32GB 5 節點+2TB SSD 雲盤集群進行測試，與原生 Elasticsearch 相比，阿里雲 Elasticsearch 在開啟了物理複製功能後，寫入性能提升大於 45%。
四、通用增強 - 高可用方案
起新下老與讀寫分離
原生 Elasticsearch 在進行集群升級操作時有一些限制，如集群升級前要進行升級檢查，本地升級集群中有不同版本節點容易出現兼容性問題，跨大版本升級要先升級到中間版本，不支持回滾等。為了解決平滑升級等問題，我們推出了起新下老和讀寫分離功能。
如下圖，當需要升級集群 cluster1 時，我們先創建一個新版本的集群 cluster2，然後在 cluster1 和cluster2 的 client 與集群之間引入 nginx 實現讀寫分流，client 的讀請求仍然落到原集群，寫入請求落入一個異步數據處理服務。該異步數據處理服務可以接收對 Elasticsearch 的寫入請求，並將寫入操作存儲在消息隊列等數據儲存組件，最後消費數據雙寫到 cluster1 和 cluster2。對於 cluster1 存量數據可以使用 ElasticFlow 全量 build 等方式同步到 cluster2。引入該架構後，cluster1 和cluster2 可以實現近實時數據同步，用戶可以在 cluster2 上驗證新版本功能，如果 cluster2 符合預期，則將 cluster1 下線，實現平滑升級，當 cluster2 不符合預期是，將 cluster2 下線，實現業務回滾。
起新下老和讀寫分離架構，在不影響原有集群業務的前提上，通過引入異步數據鏈路實現了新老集群的數據同步，對業務影響小，可以實現業務平滑升級和回滾，解決了 Elasticsearch 版本升級中面臨的多種業務痛點。
、
數據備份
為了保證數據的高可用，阿里雲 Elasticsearch 提供了數據自動備份功能。用戶可以在阿里雲 Elasticsearch 官網控制檯通過簡單配置，開啟數據自動備份功能。開啟後，Elasticsearch 集群會定時將數據快照備份到 OSS 倉庫中。一旦集群出現異常，用戶可以從 OSS 倉庫中恢復數據，快速恢復業務。
跨可用區部署
阿里雲 Elasticsearch 支持用戶將集群部署在多個可用區。當單個可用區由於自然災害或其他原因導致不可用時，阿里雲 Elasticsearch 會自動檢測可用區異常，並快速將故障可用區隔離。可用區故障期間，阿里雲 Elasticsearch 會保障用戶集群的可用性。若短期內故障可用區可以正常恢復，則集群會自動將故障節點加回集群，若故障可用區無法短期恢復，阿里雲 Elasticsearch 會在其他可用區為集群創建數量及規格相同的節點恢復集群。採用跨可用區部署的集群可以實現自動的故障可用區檢查，隔離及恢復，期間業務零影響，可以幫助用戶在無感知的情況下平穩度過可用區故障。
五、通用增強 - 穩定性保障
Master 調度優化
原生 Elasticsearch 當集群分片數過多時，集群索引創建和刪除耗時會顯著增加。我們實際中遇到的一個典型用戶集群有 3 個專用主節點，10 個熱節點，2 個冷節點，超過 5 萬個 shard， 索引創建和刪除耗時超1分鐘。通過對集群性能瓶頸和ES實現邏輯分析，我們最終發現原生 Elasticsearch 的 reroute 邏輯是性能瓶頸存在優化空間。通過引入新的數據結構，我們將 reroute 的調度算法複雜度從O(n^2) 降低到了 O(n), 萬級分片集群索引創建和刪除時間也降低到了 1s， 當前該PR已經提交併作為 co-author 合併
(https://github.com/elastic/elasticsearch/pull/48579)。
阿里雲 QOS
為了幫助用戶 Elasticsearch 集群更好地應對業務流程高峰，阿里雲ES提供了阿里雲 QOS 功能。使用該功能用戶可以對集群的節點和索引級別的流量進行限流配置。當業務流量突增時，可以將流量控制在設定的範圍內，保證集群穩定性。用戶可以對不同的索引和節點設置不同的限流配置，在流量高峰時優先保證核心業務。該功能支持動態開關調整及動態限流規則調整，可以幫助用戶在業務流量高峰時及時靈活地調整限流規則。
六、通用增強 - 成本優化
數據壓縮
為了降低存儲成本，原生 Elasticsearch 會對 store filed，doc_values 等進行數據壓縮，以降低這些數據的存儲空間。原生 Elasticsearch 提供的壓縮算法是 LZ4 和 best-compression, 其中 LZ4 有較好的壓縮性能，best-compression 有較高的壓縮率，用戶可以根據業務的情況選擇符合業務場景的壓縮算法。為了進一步提高數據的壓縮率，阿里雲 Elasticsearch 引入了 brotli 和 zstd 兩種壓縮算法。這兩種壓縮算法在保證讀寫性能的基礎之上進一步提高了數據的壓縮率，相對於 LZ4 提供了45%， 相對於 best-compression 提升了8%。
下表是使用 esrally 自帶 nyc_taxis(74GB)，對 16 核 64GB 3 節點 2TBSSD 磁盤集群，使用不同壓縮算法的測試結果。
彈性伸縮
通過對大量 Elasticsearch 集群的分析，我們發現相當一部分集群存在明顯流量的高/低峰情況。業務高峰時，集群承受較大的壓力，集群的性能和穩定性面臨挑戰。業務低峰時，節點資源閒置，出現資源浪費。針對有明顯高/低峰期規律的集群，阿里雲ES近期新推出了彈性伸縮功能。該功能允許用戶在創建集群時除了購買常規的集群節點，還可以額外購買一種新的節點類型——彈性節點，並可以指定彈性節點的擴容和縮容時間。通過這種方式創建出來的集群會根據用戶設定的時間擴容彈性節點和縮容彈性節點。對於業務存在明顯流量高峰和低峰的集群，可以使用該類型集群，在業務高峰時擴容出彈性節點，保證集群的性能和穩定性，在業務低峰時縮容彈性節點，降低集群成本，防止資源浪費。
六、場景化內核 - 場景化推薦模板
Elasticsearch 的優勢之一是上手快，集群搭建簡單，初學者即可通過簡單的配置快速拉起一個 Elasticsearch 集群，這一優勢得益於 Elasticsearch 合理的默認配置。這些默認配置不僅幫助用戶簡化集群搭建成本，集群在功能和性能上也都會有不錯的表現。然而 Elasticsearch 的默認配置是針對所用場景通用的，在特定使用場景下並不一定是最優的。基於這種思想，阿里雲 Elasticsearch 推出了場景化推薦模板功能。
場景化推薦模板基於阿里雲 Elasticsearch 豐富的 Elasticsearch 使用，運維和內核優化經驗，根據用戶的使用場景為用戶推薦符合其使用場景的集群配置，索引模板和索引生命週期管理策略等。用戶只需要在創建集群時指定其使用場景，其創建出的集群就會將上述推薦模板自動配置到集群中。用戶還可以在後續使用中根據業務的實際情況對推薦模板進行調整。
七、場景化內核 - 日誌場景
日誌場景是典型的寫多讀少場景，數據量較大，對存儲成本比較敏感，為此我們主要針對存儲成本進行優化，包括計算存儲分離和冷熱分離等。
計算存儲分離
原生 Elasticsearch 通過多副本的方式來保證數據高可用。然而在雲計算環境下，集群節點底層存儲通常使用雲盤，雲盤為了保證數據高可用已經對數據保存了三副本。這樣對於開啟一副本的索引，雲計算環境下相當於保存了六份數據，這對於存儲空間是一種巨大的浪費。基於這種思想，阿里雲 Elasticsearch 推出了計算存儲分離功能。
計算存儲分離功能使用 NFS 共享存儲作為節點底層存儲，多個節點共享一份底層存儲。主分片使用 ReadAndWriteEngine 既可進行寫操作又可以進行讀操作。副本分片使用 ReadOnlyEngine 僅提供讀操作。集群寫入文檔時，只對主分片進行寫操作，主分片定時將增量 segment 拷貝到副本分片的臨時目錄保證副本分片的實時性。
計算存儲分離架構多節點底層共享一份數據文件，實現了一寫多讀，在將寫入性能提升 100% 的情況下，成倍降低了存儲成本。數據的高可用由底層 NFS 的三副本來保證。另外由於多個節點共享一份存儲，擴縮新節點時不需要進行數據的拷貝操作，因此可以提供秒級彈性擴縮容能力。
冷熱分離
相當一部分 Elasticsearch 的集群存在明顯的數據熱點情況。用戶的讀寫操作往往只集中在部分數據集上，其他數據的讀寫頻率很低。對於日誌場景，這種情況尤其明顯，用戶的讀寫操作主要集中在最近一段時間的索引，對於歷史索引的讀寫操作很少。針對於這種情況，阿里雲 Elasticsearch 推出了分熱分離功能。
使用冷熱分離功能，用戶可以在創建索引時除創建正常數據節點外，額外指定一定數量的冷節點。數據節點使用計算資源和磁盤性能較好的機器，如核數內存較大的SSD磁盤機器，冷節點使用計算資源和磁盤性能較差的機器，如核數內存小的SATA磁盤機器。接著用戶在 Elasticsearch 集群中為索引配置索引生命週期管理策略，即可實現新創建的索引落在熱節點上，當索引創建超過一定的時間，會被遷移到冷節點上。這樣一方面保證了熱點數據在性能較好的節點上，數據讀寫性能得到保障，另一方面冷數據存儲在性能較差的節點上，降低了集群成本。
8、場景化內核 - 搜索場景
向量檢索庫
阿里雲基於達摩院高性能向量檢索庫為用戶提供了向量檢索功能，該功能已成熟應用於手淘猜你喜歡、拍立淘、優酷視頻、指紋識別等大規模生產應用場景。該功能使用 Elasticsearch Codec 機制將高性能向量檢索庫與 Elasticsearch 結合，完美兼容 Elasticsearch 分佈式能力。基於 Hnsw 算法，無需訓練，查詢速度快，召回率高。
下表是使用阿里雲6.7.0版本ES對向量檢索功能的測試結果：
機器配置：數據節點16c64g*2 + 100G SSD雲盤
數據集：sift128維float向量
數據量：2千萬
阿里分詞
阿里雲基於阿里巴巴 alinlp 分詞技術推出了阿里分詞功能，該功能支持多種模型和分詞算法包括
CRF、結合詞典的 CRF、MMSEG 等，應用於多種業務場景包括淘寶搜索、優酷、口碑等，提供近1G 的海量詞庫，並且支持熱更新分詞能力。
下圖是幾種分詞器的分詞效果對比
在對"南京市長江大橋"進行分詞時，standard 分詞器直接按照單個漢字進行分詞，雖然有較高的查全率，但是查準率和查詢性能很差，基本沒有分詞效果。中日韓文分詞器 cjk 和 ik_max_word 雖然可以將短語切分為中文分詞，但是其分詞結果中出現瞭如"市長"等錯誤分詞，雖然有較好的查全率和查詢性能，但是查準率較差。ik_smart 分詞器將短語分詞為”南京市“和”長江大橋“，沒有將”南京“，”長江“，”大橋“等作為單獨分詞，在查全率上表現不佳。而阿里分詞將短語分詞為”南京“，”市“，”長江“，”大橋“， 在查全率，查準率，查詢精度等方面均有不錯表現。
aliyun-sql
阿里雲 Elasticsearch 最新還推出了 aliyun-sql 功能，該功能基於 Apache Calcite 開發了部署在服務端的 SQL 解析插件，使用此插件可以像使用普通數據庫一樣使用 SQL 語句查詢 Elasticsearch 中的數據，從而極大地降低學習和使用ES的成本。
下表是 x-pack-sql， opendistro-for-elasticsearch, aliyun-sql 的功能對比圖。可以看到，X-pack-sql 不支持 join 操作，也不支持 Case Function 和擴展 UDF。opendistro-for_elasticsearch 不支持分頁查詢，也不支持 Case Function 和擴展 UDF。而 aliyun-sql 對分頁查詢，Join，Case Function, UDF 等均有較好支持，功能更為全面。
阿里雲 Elasticsearch 將阿里雲豐富的雲計算能力與 Elastic Stack 開源生態相結合。在為用戶提供原生 Elastic Stack 服務的同時，不斷地在 Elasticsearch 內核上進行優化實踐。我們源於開源，又不止於開源，將不斷地在內核方面做出更多的優化，回饋開源，賦能用戶。
【阿里雲Elastic Stack】100%兼容開源ES，獨有9大能力，提供免費 X-pack服務（單節點價值$6000）
相關活動
更多折扣活動，請訪問阿里雲 Elasticsearch 官網
阿里雲 Elasticsearch 商業通用版，1核2G ,SSD 20G首月免費
阿里雲 Logstash 2核4G首月免費
