本篇內容是阿里巴巴集團技術專家魏子珺帶來的阿里雲Elasticsearch雲原生內核
分享人：阿里巴巴集團技術專家魏子珺
關於阿里雲Elasticsearch雲原生內核，本文將通過三個部分展開介紹：
- 阿里雲Elasticsearch內核概覽
- 雲原生Elasticsearch定義
- 阿里雲原生Elasticsearch實踐
一、阿里雲Elasticsearch內核概覽
（一）阿里雲ES的優勢
下面這個對比圖可以很好地說明阿里雲ES相比開源ES 的優勢。
先看內圈，開源ES針對通用硬件設施，而阿里雲ES內核則是針對阿里雲基礎設施深度定製的內核，可以最大地發揮阿里雲基礎設施的性能，以及成本方面的優勢。然後，看最外圈，開源ES內核爲了適應ES豐富的使用場景包括搜索，可觀察性等，無法做到功能和性能兼顧，而阿里雲ES內核依託於阿里雲ES的服務可以做很多場景化的優化和功能增強，在搜索和觀察性等方面會比自建的ES更有優勢。內核在中圈，向下運行在阿里雲基礎設施，向上依託於阿里雲ES服務。可以看到，阿里雲ES內核相比開源ES自建集羣，不論在成本、性能、穩定性和功能上都會更具優勢。
（二） 基於用戶需求的內核建設
用戶對阿里雲ES內核的需求，主要是以下三個方面：
1、簡單
存儲容量能夠不斷擴充，計算有足夠的彈性，用戶不需要操心資源的問題。
2、好用
開箱即用，不用進行一系列複雜的部署和配置，直接根據場景提供最優的配置即可，還要有豐富的檢索功能可以使用。
3、性價比
阿里雲ES做到價格足夠低，性能足夠好，足夠穩定。
結合上述的需求，我們從下面四個方面展開內核建設。
1、成本節約
第一，我們提供計算存儲分離的增強版ES，成本上節省了副本的開銷，保證足夠的彈性，可按需使用。第二，支持冷熱分離，成本更低地存儲介質。第三，Indexing Service，這是我們全新發布的產品，對寫多讀少的場景有很大的成本節約。第四，索引數據壓縮，我們新增的壓縮算法可以比默認的壓縮方式提升45%的壓縮率。
2、性能優化
第一，我們研發的ElasticBuild相比在線的寫入能有三倍的性能提升。第二，我們還研發了物理複製功能，從最早支持計算存儲分離到現在的支持通用版的ES，物理複製通過segment同步而不是request同步的方式，減少了副本的寫入開銷，所以有一個副本的情況下，寫入性能能有45%左右的性能提升，副本越多，提升越明顯。第三，bulk聚合插件，在協調節點聚合下載的數據，降低分佈式的長尾效應，在寫入吞吐高、分辨數多的場景寫入吞吐能有20%以上的性能提升。第四，時序查詢優化，針對range查詢，可以直接跳過不在range範圍內的segment，結合時序策略可以獲得更好的查詢性能提升。
3、穩定性提升
第一，我們研發了集羣限流插件，能夠實現索引，節點，集羣級別的讀寫限流，在關鍵時刻對指定的索引降級，將流量控制在合適的範圍內。第二，慢查詢隔離池的特性，它避免了異常查詢消耗資源過高導致集羣異常的問題。第三，協調節點流控插件，它集成了淘寶搜索核心的流控能力，針對分佈式環境中偶發節點異常導致的查詢抖動，能夠做到秒級切流，最大程度降低業務抖動概率，保證業務平穩地運行。第四，monitor插件，它採集了集羣多維度的指標，可以提供全方位的監控。
4、功能增強
第一，向量檢索插件，是基於阿里巴巴達摩院Proxima向量檢索庫實現，能夠幫助用戶快速地實現圖像搜索、視頻指紋採樣、人臉識別、語音識別等等場景的需求。第二，阿里NLP的分詞插件，它是基於阿里巴巴達摩院提供的阿里NLP的分詞技術，支持阿里內部包括淘寶搜索、優酷、口碑等業務，提供了近1G的海量詞庫。 第三，OSS的Snapshot插件，它支持使用阿里雲OSS的對象存儲來保存ES的Snapshot。 第四，場景化的推薦模板，可以針對不同的業務場景提供成本、性能的優化。
以上的這些特性都能在我們阿里雲ES官方文檔中看到，歡迎大家使用。
二、雲原生ES的定義
（一）雲原生Elasticsearch如何定義
首先看一下什麼是雲原生。阿里巴巴雲原生公衆號前段時間推出了一篇文章《什麼是真正的雲原生》，總結了雲原生的定義：第一，彈性、API自動化部署和運維；第二，服務化雲原生產品；第三，因雲而生的軟硬一體化架構。
上圖是雲原生架構的白皮書封面，這是由阿里雲二十位雲原生技術專家共同編寫，已經正式對外發布，歡迎大家閱讀。
那麼，什麼是雲原生ES？
- ES的雲服務，開箱即用，能用API自動化部署和運維
- 計算存儲分離，彈性可伸縮
- 能充分利用雲基礎設施，網絡、存儲和算力等
以上三點就能對應最開始提到的三個圈： 服務，內核，和基礎設施，這樣纔是雲原生ES。
（二）雲原生 Elasticsearch如何設計
第一，它必須是計算存儲分離的架構，這樣才能提供更加彈性的計算能力和無限的存儲空間。第二，可以支持冷熱分離，冷熱的節點都要是計算存儲分離的架構。冷節點使用高性價比的對象存儲，相比熱節點可以有90%的成本節約。第三，Serverless的用戶真正關心的是索引的使用，而不是ES集羣的維護。Serverless讓用戶的關注點從集羣的維度可以下沉到索引維度。
（三）雲原生Elasticsearch內核挑戰
實現這樣的雲原生內核，挑戰是非常大的，主要的挑戰分爲下面三個方面：
1、熱節點的分佈式文件系統
第一，分佈式文件系統自身的穩定性保證，ES對Latency非常敏感，它提供性能和穩定性與本地盤相當的分佈式文件系統，這個挑戰本身就非常大。第二，ES在實現一寫多讀時，如何防止出現多寫的情況。ES數據是在內存，讀寫需要的內存狀態數據、數據是如何保持一致性的，這些都是很大的挑戰。
2、冷節點的對象存儲
對象存儲提供的是HTTP接口，所以需要去適配。另外，對象存儲的單次IO Latency非常高，所以只有在冷節點相對Latency不敏感的場景纔有機會使用。如何解決Latency最高的問題也是很有挑戰。最後是對象存儲無法使用到操作系統的pagecache和預讀能力，所以要用對象存儲，這些能力必須在ES側實現。
3、Serverless
最難解決的就是多租戶的共享和隔離的平衡問題，如果不同索引直接產生相互的影響，在雲上是不可接受的。如果不共享，就意味着資源無法充分利用。如何平衡共享和隔離的問題，這是Serverless最大的挑戰。 第二是體驗，基於索引的使用如何提供和雲原生ES一樣的體驗也是需要考慮的問題。 第三是資源監控，如何評估索引的使用資源也是一個挑戰。
三、阿里雲原生Elasticsearch實踐
1、計算存儲分離
計算存儲分離核心的訴求是彈性，它不只是像雲原生ES那樣支持動態的添加節點、自動Shard搬遷，而是徹底的彈性。對於ES來說，它的核心訴求是兩點：Shard秒級搬遷和Replication秒級增加。這樣才能解決熱點的問題，和高低峯快速的動態擴容的問題。如果擴縮容還要遷移Shard的數據，彈性是不夠的。徹底的彈性一定是Shard搬遷，Replication擴充，數據是不動的，只是調整DataNode對Shard的映射。要實現這樣的彈性，就必須做到計算存儲分離。
阿里雲對ES存儲分離內核的實現如下：
- 數據存儲在分佈式文件系統上，由分佈式文件系統保證數據的可靠性
- 同一個Shard的多個副本數據只保存一份
- 一寫多讀的場景，這樣就不再依賴於ES自身的replication，可以減少寫入的開銷。
- 索引擴Shard，無需複製數據，秒級增加只讀Shard
- Shard搬遷無需遷移數據，秒級切換DataNode
核心技術之一：內存物理複製，實現replica的近實時訪問
Segment同步的實現細節：
圖中描述的是ES物理複製的狀態機，核心是爲了解決segment同步亂序的問題。通用的物理複製功能也是一樣的實現，主要區別在於計算存儲分離只需要複製實時生成的segment，對於後續產生的segment，強制提交commit，確保segment落盤，來防止大的segment進行復制。而通用的物理複製，外界的segment也是需要複製的，這種segment往往會比較大。所以這裏有一個關鍵的優化，爲了防止大segment複製導致的主從可見性差距過大，主shard在從shard複製完成後纔會打開最新的segment。
下圖介紹了物理複製保證數據一致性的方式。
核心是保證checkpoint的一致性，通過將主shard的checkpoint同步到從shard來實現。結合這張圖可以看下流程，當數據寫進來的時候，主shard會更新checkpoint，在第二步刷新segment時，第三步將segment複製到從shard時，會帶上checkpoint，第四步從shard會用這個checkpoint更新自己的local checkpoint來保證主從shard使用了相同的checkpoint，這樣就實現了數據一致性的保證。
核心技術之二：兩階段IO fence
核心要解決的問題是防止多寫。通過分佈式文件系統的管控側將異常節點加入黑名單，直接從根本上防止了異常節點的顯露。
上圖展示了整體的流程，在主Shard節點異常的時候，MasterNode 首先發現主Shard的異常，然後將主Shard所在的節點加入黑名單。第三步，這個節點切斷了IO的權限，徹底失去了寫的能力。第四步，master通知從Shard晉升成主Shard。第五步，從Shard晉升成主Shard後，就開始正常地讀寫數據。
我們的計算存儲分離的架構通過阿里雲增強版進行售賣。計算存儲分離除了彈性的特點外，由於一寫多讀的特點，在性能、成本上都有顯著的提升。我們測試了線上阿里雲增強版ES和原生ES在同樣規格配置的性能對比情況，從表格的最右一列紅色的標識可以看到，不論在translog同步還是異步的場景，一個副本的情況下，性能都有超過百分之百的提升，副本越多，性能提升越明顯。
總結一下計算存儲分離的特點：首先它是秒級彈性擴縮容；第二，由於不寫副本，所以寫入性能能有100%的提升；第三，由於多個副本存儲一份數據，所以存儲成本呈倍數降低。
計算存儲分離——熱節點
想要使用我們計算存儲分離的ES集羣，可以選擇圖中所示的日誌增強版，歡迎大家使用。
計算存儲分離——冷節點
熱節點通過分佈式文件系統實現了計算存儲的分離，冷節點也需要實現計算存儲分離才能實現彈性。冷節點這部分我們還在研發階段，所以這次分享給大家的是一些思考的內容。
冷節點的成本是第一要素，所以對象存儲成了首選。對象存儲相比分佈式文件系統和塊存儲等特點非常鮮明。劣勢，大都在挑戰中提及到，這些劣勢相比其他存儲，無論從易用性和性能上都無法跟分佈式文件系統和塊存儲相比，所以這些熱節點很難直接使用對象存儲。但是冷節點不同，冷節點核心考慮的是成本，因此它也有一些優勢。它的成本比SSD雲盤便宜近90%，可以真正的按需使用，不用預先準備存儲空間。另外可以提供12個9的可靠性，所以也可以不用存儲副本，這又是一半以上的成本節約。基於這些優勢，對象存儲成了最好的選擇。
如何最大減少它的劣勢帶來的影響，這要從ES的特點說起。ES在可觀察性、安全的方向上，冷熱數據明顯，日誌長期存在SSD上成本過高，所以可以考慮冷熱架構。第二，ES在search的時候很消耗CPU，因此可以利用計算時異步地扒取對象存儲的數據，減少IO等待的時間。第三點是冷數據基本上無寫入，所以對寫入性能要求也不高。以上的三點就是ES冷數據使用對象存儲的原因。
Indexing Service
Indexing service是我們即將重量級發佈的新產品，這是我們在serverless嘗試的一個產品，是針對寫入方面的性能優化。相比查詢的多樣性，寫入會相對簡潔明瞭。Indexing service，從功能方面，提供了寫入托管服務，滿足高併發持續數據寫入，降低了業務集羣的CPU開銷，它適用在日誌、監控、APM等時序場景，它解決的最大痛點是寫多讀少，而且很多時序場景下寫遠多與讀，業務需要消耗大量的節點資源來滿足寫入。Indexing service 可以極大的降低這部分場景的成本開銷。
Indexing service 有以下三個方面的特點：
1、完全兼容原生的 API
2、按量付費，按寫入吞吐和QPS實際需求付費
3、寫入能力可秒級快速彈性擴縮
下圖展示了Indexing service是如何實現的：
1、第一，請求轉發，請求發到用戶ES集羣，用戶使用雲原生API操作ES，ES內核會將開啓託管的索引寫入請求，轉發到Indexing Service。這裏可以展開再縮小，對於不再寫入的索引，用戶就可以取消協助託管，釋放存儲成本。Indexing service結合Data stream和over功能可以有非常好的用戶體驗，因爲新生成了索引後，老索引就不再寫入。我們在內核上做了優化，在生成新索引的時候就會自動取消託管。
2、第二步，在寫入 Indexing service 後，內部會經過分佈式的 QoS 模塊，進行寫入的流量控制，來阻止資源的過度消耗。
3、第三步，跨集羣的物理複製， Indexing Service 構建的索引是通過物理複製到用戶集羣的。
4、最後是 Indexing Service 內部會持續地運行原數據同步的 task ，實時地同步用戶集羣託管的索引 metadata。
Indexing Service將於2021年2月全新上線，實現ES在時序日誌場景的降本增效。 Index server 可以解決時序日誌數據高併發寫入瓶頸，優化集羣寫入計算資源成本，降低運維的複雜度。Indexing Service 無論從寫入性能，成本節約，還是彈性伸縮的能力方面都能帶來不一樣的體驗，大家可以敬請期待。
本文爲阿里雲原創內容，未經允許不得轉載。