本文字數：1435
預計閱讀：3~5分鐘
您将了解：
1、資料寫入導緻的高并發叢集打爆問題，如何解決？
2、TB、PB級資料如何降低存儲成本？
3、原生Elasticsearch在時序查詢上的瓶頸如何突破？
4、峰谷差異大，如何避免閑置成本？
【全鍊路雲上Elastic Stack 全景圖】100%相容開源，9大獨有能力
----> 直播回顧 | 請點選觀看 ：
阿裡雲Elasticsearch日志增強版介紹尋根問源
日志場景面臨的問題
日志場景是Elasticsearch使用中較為常見的場景，而大量日志資料讓企業在追求經濟效應與性能效應的同時，對産品本身提出了更為苛刻的要求。
1、高并發寫入問題：
Elasticsearch在日志資料寫入過程中，會同時對主副分片同步寫入，還會去寫開銷較大的trancelog，進而造成Elasticsearch在高并發寫入的時候，對機器CPU以及I/0的性能開銷提出了更高的要求。
2、高存儲成本問題：
日志資料的存儲，往往需要對海量的資料進行存儲，起步資料量都是在TB級别，有的企業甚至達到了PB級，而為了資料容災性，還需要儲存至少一個副本，這将對存儲帶來進一步的成本壓力。
3、時序分析性能差
由于Elasticsearch的查詢特征，會查一遍所有的segment，當你做較大範圍range以及複雜聚合時，他的性能瓶頸就會立馬凸顯出來。
4、彈性可伸縮問題
日志随着業務變化，往往伴随峰值、均值和谷值的出現，且差異較大，企業通常為了解決峰值問題，會堆較多的機器已便滿足峰值需求，那麼“均值”、“谷值”期間就會造成機器資源大量浪費。
對【症】下藥
1、計算存儲分離：大幅提升日志高并發寫入能力
計算存儲分離的前提是将Elasticsearch的所有節點存基于NFS共享存儲。【如圖】資料流的寫入請求，會先寫到主分片，再寫入到共享存儲，而NRT segment會拷貝到臨時目錄，那麼主分片與副分片在讀取時就會存在差異，主分片僅讀取commit segmen A，和refresh segment B，副分片讀取的A’、B’。
計算存儲分離的【核心思路】
1、 索引分片一寫多讀，且僅保留一個副本資料，降低存儲成本，提升寫入性能。
2、 依賴雲存儲保證資料可靠性：CTF底層具備三副本備援機制，對雲業務是透明的，保障資料不丢失。同時阿裡雲在面對極端情況下，備有分鐘級的OSS自動備份機制，進一步提升資料可靠性。
3、 狀态與索引分離。
4、 通過IO fence機制保證資料一緻性，避免主程序僵死情況下雙寫的問題。
5、 記憶體實體複制降低主備延遲，從分鐘級，降低至毫秒級。
2、秒級彈性擴縮容：避免因日志峰谷導緻的“資源閑置”
3、實體複制狀态機：不寫實時索引，也能保證資料時效性
最佳應用實踐
案例展示（部分叢集）
案例背景：在阿裡雲搜尋業務線上，有很多集團内、外的客戶，會使用我們各種底層服務。為了保障各個業務之間不受影響，我們會對這些服務做一系列的監控，通過采集大量複雜的Metric做大量聚合，建立Dashboard。但除了做Monitor，相伴而生一定會有告警，也就是Alarming，那麼這樣一套監控、告警平台，底下使用的就是我們量身定制的日志增強版Elasticsearch。
架構解讀
1、運用MetricBeats采集大量Metric資料，通過Gateway，向Elasticsearch叢集去傳輸資料，寫入量大概是40W docs/s。
2、傳輸資料中，有冷、熱資料的區分，就需要将冷、熱資料做切配置設定置。
3、由于需要對資料容災處理，我們将資料自動快照到OSS裡。
案例說明
我們通過計算後發現，如果用開源的Elasticsearch做同樣的事情，所付出的成本将是該方案的一倍之多。因為不光是阿裡雲Elasticsearch增強版存儲更便宜，同時為了時序Metric的場景更高的聚合效率，我們對阿裡雲核心也做了一些優化。
你如果是基于開源自建的ES叢集，為了能夠在聚合查詢時有更好的性能，最直接的方式是備援更多的datenote，來保證性能，當然這樣會帶來更高的費用，阿裡雲日志增強版針對性的解決了這個問題，不需要備援過多的datanote，舉這個例子是為了更好的幫助大家了解阿裡雲Elasticsearch日志增強版的能力
這套服務在阿裡雲内部是适用的，我們也對外提供同樣的能力，供大家選擇。
“宗師級”能力對比
資料來源：真實POC資料，開源Elasticsearch與日志增強版對比
- 同樣性能，費用節約24%
- 同樣客戶需求，性能優越140%，成本減少43%
- 綜合能力彰顯“宗師級”
相關活動
掃碼關注公衆号‘Elasticsearch技術’，收獲大咖最佳行業應用經驗